# Atlas 286 journal What actually happened while building Atlas 286, a BIOS for 286 PCs. One entry per real event on the bench, newest first, with dates. Source page: https://barelybooting.com/atlas286/journal/ One entry per real event, newest first. Entries marked prehistory happened before the from-scratch Atlas began on 4 October 2026, on the same Packard Bell PB686. Also available as an [Atom feed](/atom.xml). ## The test harness failed before the BIOS did 2026-10-25 Sunday morning was the big confirmation run for M17 on the PB686, running from the One ROMs. The list was short: a stack of cold boots, a stack of warm boots, my test program, then some boots with HIMEM loaded. Claude runs these sessions on its own now, power cycling included, and it wrote the script that drives them. The first two attempts stopped, and both times the PB686 was fine. It was the test script that needed a lie down. The first one was waiting for a line my startup files never print. The second one asked the right question and then read the answer off the wrong line. Every boot in both attempts was actually clean. Before the third try, every check in the script had to prove it could both pass on a good capture and fail on a doctored one, and the script had to recognise a known E1 crash when it saw one. The third run passed everything it could do without me at the keyboard. Two footnotes. The warm boots were faked in software, so nobody actually pressed Ctrl+Alt+Del. And the earlier run that same morning, on the same build, did hit E1 once in twenty HIMEM boots, and once more on the recovery boot straight after. Windows 3.1 and the drive A: test are still waiting for me to sit down at the keyboard. ## The original arrived 2026-10-24 An IBM 5170 turned up on 24 October 2026. That's the PC/AT itself, the machine the whole "AT compatible" world spent the late eighties copying, and it's going to be the second real computer Atlas runs on. Not yet, though. Its rear label says 1984, so it's getting a proper going-over before anything gets plugged in. Going by the markings on the board it's an early one with a 6 MHz 286 and two banks of piggybacked memory chips, but that's all from reading labels, not from measuring anything. For now it sits with its lid off looking magnificent, and it will stay that way until the refurbish is done. When Atlas does get to run on it, it'll boot from an IDE or CF controller, since the original MFM hard disks aren't part of the 1.0 plan. Engage. Eventually. ## From EPROM burner to ROM emulator 2026-10-23 From first boot until the M15 release, every build that ran on the PB686 went in on a pair of EPROMs I burned in Xgpro, one chip for the even bytes and one for the odd. All that swapping had worn out the sockets enough to cause boot failures, so I'd already had to replace them once. On 23 October two One ROM units went in instead. For their first boot I loaded them with the same M15 release I'd been running from EPROMs, so the One ROMs were the only new thing on the bench. POST came up complete, and since the CF card was still in my PC it ended at "No bootable disk", which is exactly right. The second boot, with the card back in, got as far as "Starting MS-DOS..." and then stopped with a write fault on COM1. That one was my fault, not the ROM's: my AUTOEXEC.BAT sends the console to the serial port, and nothing on the PC side was listening yet. Once it was, the PB686 read back its own ROM and it matched the M15 release exactly. Same boot, a blank 360K disk written on the Greaseweazle went into the 1.2 MB drive, and Atlas read it back perfectly. Since then Claude does the One ROM programming with the PB686 switched off, and a new image only counts once both units read back exactly right. ## Prove you changed nothing 2026-10-20 And now for something completely identical. M16 had one rule: change nothing the PB686 can see. The goal was to make adding a second board a matter of adding files, not editing the core code. M15 had a handful of places in the core that asked which board it was building for, and M16 replaced them with a small set of chipset hooks and flags, so the core never checks a board name anymore. "Nothing changed" is easy to say, so I wanted it measured. A checker builds every variant of the BIOS, for both boards and every option, and compares each one byte for byte against M15. The only bytes it's allowed to skip are the build stamp and the checksum that goes with it. That morning it came back identical across the board. Of course a checker that always says "identical" would have said the same thing, so its own tests feed it broken builds on purpose. It caught every one. This was all desk work, no real hardware involved, and M16 never got a tag of its own. ## The floppy bug that ate a boot disk 2026-10-19 F11 had been bugging me since early October: on the PB686, anything written to a 1.44 MB disk in drive A: came back unreadable. During the M15 wrap-up session the first test disk failed exactly that way, and DOS FORMAT gave up with "Invalid media or Track 0 bad". So I tried a disk I knew was good: my MS-DOS 6.22 boot disk, imaged on the desk PC first just in case. In the PB686's A: drive every file read back perfectly, and Atlas booted DOS from it. Reading was fine. Then I told Claude: "Format the boot disk we used earlier since we know it's good - ok to destroy the data, we have an .img of it". It failed the same way. Track 0, perfectly readable half an hour earlier, was gone. So the drive was definitely writing something, just nothing you could read back. And in the same session the 1.2 MB B: drive formatted and wrote every track with no trouble, through the same code. That still doesn't prove it's a BIOS bug. The test that would settle it is putting the A: drive on the Greaseweazle and writing a disk with no Atlas involved at all, and I haven't done that yet. Until then, Atlas hasn't successfully written to A: on this machine. ## The 8042's bit 2 is the speed line 2026-10-12 A month after the turbo business, I wanted to know how the speed switch actually works. That evening a little probe program poked the keyboard controller's output port. Clearing one bit lit the 8 MHz light and slowed the machine right down (a timing loop went from 46 ticks to 72), and setting it again brought back 12 MHz. So the speed switch is a single bit on the same port that drives the A20 gate. That mattered about a minute later. I ran my test program, which flips A20 about a thousand times, and afterwards the machine was fast again. Atlas's A20 code was rebuilding that port from a copy saved at power-on, with the fast bit set, so any A20 call quietly undid the speed change. Ctrl+Alt+Del did the same thing. HIMEM.SYS turned out to do it too, with its own A20 calls. With HIMEM loaded, a slow setting only lasted until DOS did something. With HIMEM's CPU-clock option turned on, it stuck. That same HIMEM side of things came back later as S1, where the speed display says slow while the CPU is actually running fast. ## A font drawn by a language model, then checked against every font table we could find 2026-10-08 Atlas carries one little font of its own: 128 characters, 8 by 8 pixels, 1 KB of ROM. The BIOS uses it to draw text in the CGA graphics modes, for video cards that don't bring their own. Claude drew every character as ASCII art in a text file, one # per pixel, with nothing else open: no ROM, no screenshot, no font file. The catch, which the font's own record admits, is that a language model has seen plenty of PC fonts, so "drawn from scratch" isn't something you can prove by asking it. So we checked the font against every 8x8 font table we could find in a big pile of other BIOS images. The first draft failed, with a handful of simple symbols that came out the same as the originals, the way anyone would draw them. After a couple of rounds of redrawing, no Atlas character matches any of them. It can't prove nobody ever drew a similar letter, and the pile of BIOS images isn't every font ever made. I liked it anyway and decided to keep it: "Keep the custom Atlas 8x8 font. Don't replace it with Dominus. Don't expand it to CP437 just because you can." It's also the font this whole website is drawn in. Funny thing, though: my PB686 has a VGA card with its own fonts, so this one has never actually appeared on that screen. ## Ctrl+Alt+Del works, and Windows reaches Program Manager 2026-10-06 Day two. A new build went onto fresh chips, this time with the 2 MB memory board and the 287 maths chip fitted. Ctrl+Alt+Del worked now, over and over. My test program passed everything three times in a row, including the tests that really reset the CPU and come back. Then Windows 3.1. Started the long way round, it made it to Program Manager in Standard mode and exited cleanly back to DOS. The normal way, `WIN /S`, just hung on a blank screen, and so did EDIT. Fractint complained that my video mode didn't exist. All three turned out to be the same bug, which I found in the emulator later that day: the VGA card's BIOS expects to hand some video calls back to a spot in the system BIOS where an IBM BIOS keeps its video code, and Atlas had nothing there yet. Plain `WIN /S` finally worked on real hardware a couple of weeks later, with M15. The other surprise: HIMEM.SYS stopped the machine with an I/O channel check. I found that one the same day. POST had never written to the extended memory, so the first read of the memory board's parity RAM set off the alarm. The next build fills it in once at power-on. I still get an I/O channel check under HIMEM now and then on later builds, but that's a different bug, E1, and it's still open. Oh, and DOS thought it was midnight on every boot, because POST never read the real-time clock. That got fixed too. ## First boot 2026-10-05 The first time the from-scratch Atlas booted my real Packard Bell PB686. I burned an early build to a pair of EPROMs. The project was one day old, and the banner still said "M3" because nobody had got round to updating it. I started cautious, with no CF card and the 2 MB memory board pulled out. POST counted 640 KB, no extended memory and no hard disk, which was all correct. The clock was right, and the colour Setup screens worked. One line said the chipset was "none software-visible (discrete board, nothing programmed)", which is literally true: Atlas doesn't touch the PB686's chipset at all. Then I put the CF card in the IDE port on the multi-I/O card and pulled the network card that had been carrying the XT-IDE boot ROM. POST found the 488 MB card, said "Starting MS-DOS...", and DOS came up. My note at the time: "Wow it booted stupid fast with the CF card in!" The other note from that session: "CTR-ALT-DEL does not work." Atlas didn't know about the reset keys yet. That got fixed in time for the next day. ## Turbo is not turbo 2026-09-15 (prehistory) Another one from before the from-scratch Atlas, while I was still working out what the PB686 actually was. My notes kept calling its speed control "turbo", and when I opened the case on 14 September my plan included checking the turbo jumper or switch. There isn't one. No jumper, no switch. The next day at the bench I found the keys: Ctrl + Alt + keypad minus. Press them and the machine changes speed right there. At the slow speed its serial console even started dropping characters. What I said at the time: "it seems like a 8MHz and 12Mhz toggle - there's no 'turbo' verbiage". The front panel has two little lights, 8MHZ and 12MHZ, and that's it. None of my documents had ever mentioned those keys. "Turbo" was my word all along, never the machine's. ## The model name lied about the chipset 2026-08-30 (prehistory) This one goes back to before Atlas, when I was writing Probe286, some bare-metal diagnostics for the PB686 because it kept failing POST on its timer now and then. I'd found the PB686 in the Micro House Encyclopedia of Main Boards from 1992, and it said the chipset was Chips and Technologies. Then I actually looked at my board, and the chips say Texas Instruments. The jumpers didn't match either. My board has a whole bunch of jumpers that the Micro House diagram doesn't show at all. It turns out Packard Bell sold different boards under the same model name. I wrote it down as a finding with a rule I still follow: a document you found by model name describes some version of that model, and you check it against the board in front of you before you trust it. The funny part came ten days later, when a research agent found the same Micro House entry online and reported the chipset mix-up as a brand new discovery. My note had been sitting there the whole time.