IBM PC-DOS Weirdness

[Bas]

Hey all. IBM does something unexpected when formatting a drive from DOS 2.00. There's a whole bunch of bytes written just before the second copy of the FAT at hex offset 0x1000 from the partition start. I see no recognizable strings in there, it doesn't look like a directory block and it's not part of the FAT either. So given that MBR and VBR bootcode are both accounted for, does anyone know what this is? It looks like assembly but I can't find anything on what it is in any docs.

[Bas]

When testing with a different size hard disk, I imagined to find these bytes in a slightly different place maybe or to have a few of them changed because of different locations/offsets and whatnot. But.. there's a completely different set of bytes located at a different distance away from the second FAT copy. This time the sequence does contain recognizable ASCII. There's a set of mostly commands, most of theminterspersed with a sequence of 4 other bytes: CD, CHDIR, MD, MKDIR, RD, RMDIR, BREAK, VERIFY, SET, PROMPT, PATH, EXIT, CTTY, ECHO, Y, GOTO, SHIFT, V, IF, P, FOR, h, CLS, S.

These appear when I format a 15MB disk. None of this appears when I format a 10MB disk.. and now I'm stumped. I didn't use FORMAT /S so the disk is not bootable nor should it hold a boot loader or system files of any kind just yet.

This does kind of cramp my mission of formatting drives 100% identically to what IBM/MS did in the day. So if anyone has any clue what these could be, I'd be very grateful.

[Bas]

Ah.. fudge.. Just noticed. I tried the PCXT core to run PC-DOS but that wouldn't boot of the 360k floppy image. So I tried AO486, and that created a disk with the wrong geometry using 63 sectors per track. Those didn't exist yet when DOS 2.00 was around. Back to the drawing board (and PCEm) for some more testing.

[Bas]

..right.. PCEm does similar but subtly different things yet again. It's the FORMAT utility that puts the weird bytes there. No idea why though..

[pgimeno]

Sounds like it's writing something from RAM without initializing or cleaning it up first. That's pretty common in disk operations, e.g. very often, when looking at the sectors of a file with a length that isn't a multiple of the cluster size, in the last sector you can see garbage after the end of the file.

If I'm right, writing a byte-by-byte accurate formatted disk would be a fool's errand. Do you get the same bytes every time you format, even if you use a program that fills up most of the RAM and that performs file access, between formats?

[Bas]

Both the length and the contents of the sequence are different every time. I guess it's a bit late to report a bug to IBM now, but this does seem to be one. This may become a thing when the disk gets filled to near capacity.

Norton Utilities doesn't like these disks much either. Ah well, the things we unearth from the depths of digital archaeology.