PC-DOS 2.00 junk bytes in the FAT area

📅 2025-06-22  · ✍️ Bas v.d. Wiel  ·  🏷 documentation

This is something of a journal entry. I’m preparing to start work on implementing PC-DOS 2.00 compatibility, which means creating a bunch of pristine floppy and hard disk images to base my implementation on. 86Box is my friend here, as is the ghex utility for looking at every single byte. While trawling through a disk image, sometime I discover something intriguing. Apparently, PC-DOS 2.00 injects a bunch of stuff into the area of the disk where the FAT’s live but these bytes have nothing at all to do with the FAT’s. In fact, should the disk get enough files and subdirectories, these bytes would get mercilessly clobbered by the growing FAT. So, what gives?

Right now I’m noticing this behavior with 360KB floppies that I format using FORMAT /S. What I’m expecting is a first sector filled with a standard boot sector, which we get. The boot sector now also gets terminated with the 0x55 0xAA bytes. After this, you’d get two copies of the FAT which would each take two sectors so four sectors of FAT space altogether. And that is indeed what happens. DOSContainer’s analyzer mode detects the FAT without issue. That surprised me a little because the analyzer code is hardly up to snuff right now and I half expected it to just error out on me.

What threw me for a loop, initially, was a FAT that starts with 0x33 which is not a FAT ID I had ever seen. There was a whole block of bytes there, and it occurred twice so I mistook it for a weird FAT that was also much too big. Three cheers for my trusty LLM, which is a lot better and reading bytes than I am, and which figured out that there was in fact a FAT hidden in the fragment I fed it. And indeed, there was. The disk dutifully contained two FAT copies in the exact locations where you’d expect them.

The strange bytes appear at the end of each FAT area and are identical between those areas. My LLM rubber ducky has all sorts of wild fantasies about stub boot loaders and jump code, but would even Microsoft be so dumb to put a critical piece of boot-loader infrastructure in a place that could get clobbered when a user puts a lot of files and subdirectories on the disk? I’d hope not! The user would get brutally punished for making good use of a disk.

I decided to copy the disk image, and zero out all the bytes that had nothing directly to do with the FAT’s at all. As I already expected, the system boots up fine without those strange bytes in there. This rules out the idea of a completely undocumented second stage in the boot-loader. Funny how an LLM lacks all historical context and confidently tells me that I may have made a revolutionary discovery in one of the world’s most studied bits of code.

Ah well… my personal hypothesis for now is that it’s just junk code, much like the crud earlier DOS versions' COPY command stuffs into the slack space between too files when the last cluster of the first file doesn’t completely fill out. To test this hypothesis I’ll be creating more disk images from scratch under different circumstances so that memory will have been shuffled around and exercised for a bit. If the bytes turn out to remain identical across disk images, I’m going to check the contents of the FORMAT command itself for this sequence. If they vary, I’m going with the idea that FORMAT just gunks up the place by dumping the contents of an uninitialized buffer into the second sector of a new FAT.

To be continued, though.. it’s late, and there’s work to be done tomorrow!