Borealis

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.

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.

boot is finally stable, primes count to a million, so i tried the graphics. SCREEN 13 does nothing. no error, no letters, no mode change. GCLS nothing, LINE nothing, RECT nothing. PALETTE works??? which makes no sense because palette is the one that should be hardest. starting to suspect the video thunk is broken. ive got no idea. but at least im honoring my promise to keep devlogs shorter.

Fixed the boot (fr this time) the whole laptop reset thing turned out to be two bugs stacked on each other: the bootloader was trusting/rejecting BIOS geometry based on vibes, and the kernel entry point was jumping into a debug helper instead of _start, so the CPU executed one stray ret into the void and triple-faulted. coil now makes the BIOS prove its geometry against a build-time checksum before trusting it, and checksums the whole kernel before jumping in. Boot output is an actual diagnostic language now: gk = geometry truthful, gf = BIOS lied, C! = wrong bytes arrived, and nothing resets silently anymore. QEMU boots all the way to BASIC, audio included. Also cleaned up helix.c (boot debug spam now only speaks when something’s actually wrong, RIP “HELIX FAILIURE” typo), evicted BTBX from the prompt, it’s js => now, and am working the BASIC interpreter with a bit of a rewrite: dispatcher no longer depends on include order and prayer, dead duplicate file-I/O code confirmed gone, graphics.inc brace damage found and fixed. Laptop test tomorrow-ish, then the interpreter cleanup lands. see u next time!

hi people! this one’s a bit different. no new features, but a new name. the project is now called Borealis. the old name, BTBX, made sense when this was a tiny BASIC interpreter and nothing more, but it’s grown into a full bootloader, kernel, and proto-OS, and the name stopped fitting. the system now has three named layers: coil is the two-stage bootloader, helix is the kernel, and BOREALIS is the system as a whole. the names are deliberately scale-neutral. where the project goes from here shouldn’t be constrained by what it’s called. the rename itself was the easy part, the fallout was the real work. i went through every file updating references to the old name, plus the directory structure (boot/ became coil/, src/kernel/ became src/helix/), the build files, and the image name (borealis.img now). outside the repo, i also had to update hackatime and stardance so everything points at the right thing. the README on github is fully rewritten to match (may not be pushed at this time), and there’s a note in it about the old name for continuity. technically nothing else changed. same code, same features, same open issues, this was purely an identity update. that’s all for now!

hi people! im trying to get BTBX to boot properly on an ASUS F5RL laptop. unfortunately, it still isn’t booting correctly, but I managed to narrow the problem down further. I previously ran into issues involving EDD, DH, and a few other parts of the boot process. right now I’m getting the error S1>S2Agk(18.1)Drk{c2,h0,s2}R, which makes it look like the BIOS may be reporting bogus CHS geometry in a way BTBX is not expecting. there’s no working result yet, but I’ll keep investigating the boot and disk-handling path. i hope to get it running soon.

hi people! this time i worked on a v86-compatible version for the in-browser demo. it’s now possible to try the project directly in the browser, although there are still a few input-related issues, including with the shift key.

the browser version is mainly there as a quick way to look at the project without setting anything up. for proper testing, though, i’d still recommend using a local environment—the demo is mostly for anyone too busy to set one up. pong does work in it though ^^

hi people! recently i worked on adding proper graphics support to the project. instead of relying on text-mode attribute tricks, i went with direct pixel plotting, since it gives the system a much more flexible foundation for drawing things on screen.

i added a new Mode 13h framebuffer API with functions for entering and leaving graphics mode, clearing the screen, plotting and reading individual pixels, drawing lines, rectangles, and circles, and changing the VGA palette. the implementation writes directly to the linear framebuffer at 0xA0000, with palette updates handled through the VGA DAC ports.

on the BASIC side, there are now new statements for using these graphics features: SCREEN, GCLS, PSET, LINE, RECT, CIRCLE, and PALETTE. i also connected the new graphics code to the statement dispatcher and updated the built-in HELP text so the commands are documented.

finally, i cleaned up the build setup by adding the new graphics source files and removing an old ‘-display curses’ option from the run command.

this is a much more versatile approach than only the old text-based graphics, and it gives me a better base for anything visual i add later. that’s all for now!

hi people! i spent more time working on the graphics system. there still isn’t a finished result to show yet, but i’ve been continuing to work through the implementation and figuring out the pieces needed for proper pixel-based graphics support.

it’s taking a bit more iteration than expected, but the goal is still to have a solid graphics foundation rather than rushing in something limited. hopefully i’ll have the completed version ready to show soon. see y’all later!

hi people! i started working toward graphics support this time. i’m moving away from text-mode tricks and looking at direct pixel plotting instead, since it should be much more flexible to build on later.it’s still a work in progress, but i should have something more complete to show next time. what pmo is that 10 hour limit so i cant just devlog once i have a feature, i have to do it in the middle of nothing an wasting 3 hours anyways. see y’all later!

hi people! this time i added a set of bitwise operations to the language: AND(x,y), OR(x,y), XOR(x,y), NOT(x), SHL(x,n), and SHR(x,n). these work on values converted to 32-bit integers, and the shift functions keep large shift counts predictable by masking them to 31.

i also added HEX$(x) and BIN$(x) string functions for displaying numbers in hexadecimal and binary, without unnecessary leading zeroes. on top of that, the number parser now accepts hexadecimal and binary literals using &H… and &B….

finally, i updated the built-in HELP text so the new functions and literal formats are documented in the system itself. that’s all for now

hi people! this was mostly a behind-the-scenes work session rather than one with a major new feature to show off. i spent a lot of time working through the project, trying things out, and dealing with the smaller details that tend to take longer than expected.

there isn’t one big result for this devlog, but the time was still useful for getting a clearer picture of what needs attention next and making progress on the work that supports the larger features. sometimes development is less about a big visible change and more about putting time into the parts that make future work smoother.

that’s all for now!

hi guys! i took a short break from the project. first voluntarily to take care of my mental health, and then a bit longer than planned because i got sick.

after returning, i tackled a smaller but useful feature: RTC support via the TIME command. the command can now work with the real-time clock, which means the system has proper support for reading and handling time instead of relying on a manually managed value.

this was a fairly quick feature to work through, so it felt like a good way to get back into the project after the break. also, please excuse the old time shown in the photo, i hadn’t kept it up to date when I took it.

that’s all, see you later

hi people! this time, i mostly worked on cleaning things up after restructuring the working tree, and i also fixed a few issues with the text editor.

the biggest breakthrough was figuring out why the prime sieve computation kept failing. in the end, the problem had nothing to do with the math itself. instead, it came from the way the interpreter handled loops and writing to disk. those issues interacted in a way that caused the loop to stop after finding just one number.

that problem is now fixed, and while tracking it down i also ran into several other bugs, which i fixed along the way.

that’s all!

After my restructuring I was gonna ship the project but I just dont feel its finished enough so I wanted to add a few more features to make it a bit more standalone. Right now, you would in theory be able to use it on a computer without having to prepare programs on another computer because WE HAVE A TEXT EDITOR!!! finally. So you can write your BASIC and execute it, save the results and view them as much as you want!! There is a prime number sieve being edited on screen but it doesnt run yet because there are some issues in the way my BASIC is interpreted, some issue with loops or whatnot. Thats the next thing to work on.

Nothing incredible, except scut work right now. I was made aware by codefactor that my code was too complex in parts (complexity of 771) and so I cleaned up the file tree so its nice and organized, and I am most way through splitting stmt(), but I was made aware my devlogs are too long so here you go.

I started working on giving the system a voice. Yes, quite literally a dystopian, creepy voice synthetisation function. Originally I was only gonna do ‘BEEP freq, duration’ (which i managed in a good hour at most) but then I got invested in actual phoneme/allophone synthesys (Software Automatic Mouth style) and it turned into a lot more work. Sadly so far i’ve only ever gotten squeals out of it, or all quiet, so i am probably going to give up and do more important work like either a text editor or a directory support, or even a proper C compiler in-system (so far only precompiled binaries work).

I took a small hiatus (climbing in the caucas mountains for my mental health). Anyways i’m back and I added binary loading and execution support (for example precompiled C or whatever). I works, no too visible on the screenshot but look at the screen border (it was flashing). Also sorry for the long devlog but i had some time logged, and logged more now, and somehow ended up with 18 hrs.

I have finally fixed the floppy boot including its FAT12 init. There were many, many problems, I was running around in circles but I finally fixed it. The last thing I did was rewrote the EDD stuff front and back, and I assume that fixed it. I, honestly, am not sure. But anyways, now both HDD and floppy boot work including FAT12 init and all functions of BASIC that I have implemented insofar.

The floppy boot issue persists. I have moved past the FAT init failing visibly, but any read actions throw all zeros out. I came across the issue in the past, I feel like I am going in circles here,

At the moment I am still stuck on the same issue (floppy/HDD). I got the idea that the fs may be misconfigured so I am working a on that too. A lot of theories, and multiple issues i’ve fixed already, but on floppy FAT init still fails.

I dont have any major update, I am stuck fixing a regression where FAT initialization fails exclusively on QEMU floppy boots, while HDDs work fine. I always fix one thing and something else breaks, like EDD probing panics, false failiures, reset storms and others. The end result is always the same, the boot takes a long time (timeouts) and no disk is available.

I decided to put some work into booting in hard-drive (DL 0x80). That in itself wasn’t too big an issue, but it in turn made floppy boot (DL 0x00) nonfunctional. I went back and forth, fixing one, breaking the other, again and again. Right now there is some kind of silent failiure in floppy mode that causes it to take minutes to boot (I think its failing and retrying 3 times on every sector) and then it finds the root dir populated as all zeros. The issue is all the processes come back as successes when reading registers. So right now, only hard drive mode works, but this devlog is already wayyyy too long and I wouldnt want to lose all this time.

And we have a complete functioning FAT12! Reading and writing have been working smoothly. The fs writing wasn’t even that hard to implement, and I also added a few more mathematicals to to once again appoach GWBASIC. We have direct hardware access (PEEK/POKE into ram, etc), arrays, nonblocking input (INKEY$) and I also added 2 string functions.

After countless fixes I have managed to get a functioning FAT12 filesystem working, including listing and loading files. Saving (writing) is not functional yet. The key issues were: CHS mismatch, BPB was wrong, broken multisector loading, and other. Next I will try to make writing possible.

I’ve changed some kernel details, like that instead of straight crashing, it might tell you whats wrong before, design details, etc. I changed the approach to disk wiriting from straight dd to a python script that actually makes a mountable volume, and I am still working on getting filesystem working. There has been so so many issues ive been running into as the complexity of the system rises (and so does entropy, I guess). This will take an unprecedented amount of work to get even remotely to the level that is GWBASIC, much less what I aspired to (ISO/IEC 10279:1991).

I managed to implement longer variable names possible, a lof of trig/calc functions and overall perked up some details. Im heading towards Full BASIC instead of just Tiny BASIC but Im not sure how far I will go with this.

Ive gotten to the point where it actually boots from floppy in QEMU (no hd working) AND to an extent BASIC works. Its not perfect yet but ill get there soon.

What a poor choice this project. I wanna sleep so much and yet I cant fall asleep because I just have to get it running and it will definietly only be an hour or less.

I changed the approach. Instead of just messing around in assembly, I will do most of it in C and assembly is only for the bootloader. Yes, bootloader. Simplest way to keep this as bare-metal and universal as possible was, in my opinion, to just write a kernel, grub, crosscompile for i868 (in distrobox because the toolchain doesnt run on my distro) and boot via QEMU. I got far enough that it compiles and builds into an ISO, but doesnt actaully even boot, instead bugs out in SeaBIOS. Seems I bit off more than I could chew.

After an all-nighter i got it to assemble, but to call it functional would be a joke.