@onyxtheone

its been a week since my last devlog, i dont have much new to add because with school and other responsibilities i dont have much time for actuall progress on this project. still i accumulated some 9 hours (sorry gizzy) by doing small changed, linting, updating forgotten banners and version numbers and so on. EHCI/USB still fails on the same issues as before. i will be reverting to a superfloppy boot because right now i cant even get debug to write to the disk which is annoying. then once i get the usb driver with all its issues working (sometime next decade) i can give usb boot another shot.

i am (still) putting in work on the usb driver, this is proving to be very complicated especially because my hardware is not cooperating. im thinking about switching back to floppy-emulated mode which would be more practical for debugging but at the same time probably introduce new issues i dont even expect yet.

i started working on layouts, placements, and routing. i made it extra hard on myself by deciding to have a 25x25mm board minus whats taken by the antenna keepout. ill probably have to make the board larger because i forgot to take into account the devkit gpio headers and im already dying of lack of space.

the first part was doing some schematics in KiCAD. that took me about an hour and a half, including all research and electrical calcualtions. i know, its not the prettiest schema but its more than sufficient for a quickie like this, so i can move on to the next part which will probably be the layouts, then routing and so on.

the port resets work on the laptop now. the bit we were waiting on (port-enable-changed) was being acknowledged by the bios’s smm ghost before we ever saw it, so we stopped waiting on the status bit and just read the port state, which can’t be acked away. also fixed before it bit us: two devices answering address 0 at once (enumeration is per-port now, and every device gets a real address before the next port wakes up). the next failure was prettier: every OUT transfer works, every IN transfer dies. the stick takes its orders but can’t talk back. that’s the signature of the qtd buffer list, the one place real ich silicon is strict where qemu is forgiving, so all dma buffers are page-aligned now and the error reports name whichever endpoint stalled. also everyone gotta apreciate the blahaj!

the stick is a disk now, no bios involved: usb grew enumeration and bot/scsi, fat12 picks whichever backend came up. qemu took the whole chain first try. the laptop found the stick on port 0 and then refused to reset it (my fault), the 50ms delay was port-0x80 writes that only cost real time inside qemu, so there’s a pit-based clock now. plot twist from the log meanwhile: the bios path worked on the laptop, because the toggles that “didn’t help” had quietly moved the stick to floppy emulation, and that path survives the mode switch. so it (partially) boots by accident while we fix it on purpose. also caught in a self-audit: a stall burned a full second, and a short read could report success with half a sector. readme rewritten as i was told to by sw.

im still working on getting a usb driver to work. ehci seems to work kinda but its a loop between giving false data, partial data and occasionally seemingly true data but then usb decides it doesnt like it and ideally fat12 fails durning cache load too, WHICH I FIXED LONG AGO BRUH. but it came back for some reason. so im trying timing, msd, stall handling everything. this may take another decade.

debug spew is a file now. every checkpoint from the first instruction onward (entry asm, the real-mode thunk letters, all the [DEBUG] lines) lands in a buffer, and once the fs proves it can write, the buffer becomes LOG.TXT and the screen clears to the banner. the trick is the default: echo stays on until the file is safely written, so a boot that dies early still shows everything live. the fallback isn’t a code path, it’s just never getting to the quiet part. LOG=0 in CONFIG.TXT keeps the old wallpaper. and the log already caught its first bug: a missing [EZTG] tattled on a stale version entry.asm. debugging is too important to leave on the screen.

the stick talks, and for the first time it’s talking to us, not the bios. this part was the transfer engine: queue heads and transfer descriptors, little linked-list structs the ehci controller fetches out of ram and executes on its own. a control transfer is three of them chained by hand (setup, data, status), data toggles set manually per stage because high-speed lets you. link the queue head into the async ring, poll the active bit, unlink, then ring the doorbell (an actual doorbell bit) so the controller formally forgets the whole thing before the structs get reused. first exchange: GET_DESCRIPTOR at address 0, and the stick answered with its vid/pid like a civilized device. qemu’s stick goes by 46f4:0001; the real one can introduce itself when the laptop’s back. next: scsi over bulk, and fat12 stops caring what a disk is. moral: usb devices are polite, they just want to be asked in struct form.

the laptop’s bios has a party trick: as i described before, int 13h works fine until the cpu enters protected mode, then it never returns, not even for a no-transfer disk reset. bios toggles didn’t help, so borealis is growing a native usb driver. first part: find the ehci controller over pci, do the formal ownership handshake (there’s an actual semaphore register in config space where the os and the bios’s smm ghost take turns. set our bit, wait for theirs to clear, then kill every smi source so the ghost stops getting summoned), reset the controller, spin up an idle async schedule, scan the ports. no packets yet, just a controller that’s officially ours. dev loop is qemu with a stick image on an emulated ehci, boot still from floppy, so the laptop only has to show up for the one hardware-specific part. moral: if the firmware won’t share the hardware, take the hardware.

instrumented the thunk to print a letter per step so a hang names its own murderer. result: Rer, then nothing. R entered real mode, e entered the EDD read, r was about to issue a disk reset, ah=00h, the simplest int 13h call there is, no transfer, and it never returned. if even a no-op reset hangs after the PM excursion, the bios’s whole disk service is dead post-protected-mode on this machine, full stop. so the fix is a native usb driver. helix talks EHCI directly, bios for boot and native for runtime, as it should be, but that’s pci + ownership handoff from the very SMM that broke us + enumeration + BOT/scsi, and you don’t bring that up blind, one teletype letter per reboot, right before losing the hardware. deferred until the laptop’s back on hand; qemu remains unaffected.

working theory: the bios’s legacy usb support, and specifically system management mode. coil runs in pure real mode and its EDD reads work, the bios reads the stick happily at boot. but helix runs in protected mode, and calling the bios means dropping back through a thunk, and that round-trip is where it dies. on a machine this age legacy usb lives in SMM: the bios traps disk interrupts and does the transfer in a mode invisible to the os, assuming a clean real-mode cpu, and our PM excursion breaks that assumption. the tell: teletype (int 10h) works from the thunk, disk (int 13h) hangs. teletype doesn’t touch usb, disk does. photo is the bios setup screen, where i went hunting for a legacy usb toggle which i did not find ;3c

next wall, immediate: the machine hangs at fat_cache_load, the step where helix reads the FAT and root directory into RAM. in qemu this works instantly but on the laptop the disk read goes out and never comes back. no error, no status, no return. debug output narrows it to exactly the transfer call: everything before prints, everything after doesn’t.

borealis booted on the laptop for the first time. not qemu but actual silicon, a core 2 duo, off a usb stick. coil came up, loaded helix, and the machine made it to the banner plus three debug lines, which is the whole chain working on real firmware: stage1 > stage2 > kernel > protected mode. CHS disk was already known broken cos this bios won’t talk cylinders/heads/sectors to a stick with no real geometry, fair enough — so coil booted over EDD, but helix’s disk layer still assumed CHS and the filesystem never came up. still: it boots, on real hardware. just doesnt get far enough to be useful (yet).

im still working on real hw boot issues. coil doesnt guess geometry anymore, it brutes it: the new stage2 tries every plausible CHS geometry against a buildtime checksum of the kernel’s first sector and prints the one that actually works. no more “trust the BIOS” and no more “reject the BIOS”, just prove it. on a sane machine it prints g(18.2) and boots like nothing happened. on the laptop it either prints its real geometry and boots, or prints G! plus what the BIOS claimed. either way i finally get an answer instead of a silent reset. in the meantime ill be working on some features like arrows, logging, etc. attached photo of my testing setup

boot splash is in and shipping on the image. CONFIG.TXT decides, SPLASH.BAS plays on boot, keypress skips. the hook was “just two lines” and then reality happened: config.c wasnt in the makefile, the loader was static, and the first boot loaded the splash then sat at the prompt waiting for me to type RUN myself. three one-line fixes later: coil letters, banner, aurora, prompt. also fixed make pack details. the machine has a boot vibe now next up is proper scrollback, logging, and arrow key support.

the system has a config file now. CONFIG.TXT on the boot disk, key=value, one per line, read at boot. the fun part: the parser tolerates leading line numbers, so EDIT CONFIG.TXT just works with zero new editor code. the editor only speaks numbered lines, so i taught the config reader to ignore them instead (and officially, just use the numbered lines in there its not that hard, but you dont have to for it to work). SPLASH=0/1 is the first key, persistence is free because its a file on the FAT12 disk. the whole reader is ~75 lines, no allocation, no subsystem. config systems should be files, not frameworks ;3c

SCREEN 13 works, SCRTEST passes end to end, palette cycling is smooth, and as a bonus the fix also killed a stack-vs-bss collision that was waiting to happen. wrote AURORA.BAS to celebrate, it does a starfield and a sine curtain with the classic palette-cycling trick so it stays fast even interpreted. next up (probs): making it the boot splash, config.txt for persistence, then directories and much much more to be excited for!

ITS THE MEMORY MAP. gfx_is_active sits at 0xA12C0 which is past 0xA0000 aka inside the VGA framebuffer window. reads from there always return 0xFF in text mode, writes vanish into the void. the kernel bss grew past 640k and parked a variable in video memory. the “graphics thunk situation” was never the thunk. it was never even the graphics. one line in the linker script moves bss to 1MiB and everything works. i want to scream (affectionate). theres some more to be done before its usable in practice (because it never really was i guess) but SOON.

spent the whole night inside the realmode thunk with a fine comb. it is NOT the thunk. SCREEN 0 actually switches modes fine, which makes SCREEN 13 doing nothing even weirder. also found out my kernel thinks graphics is already on before i ever turned it on?? the flag says 255. TWO HUNDRED FIFTY FIVE. its supposed to be 0 or 1. memory corruption somewhere (see kpan 7), or im losing my mind. probably both.