Not MSX, Either

Further examining the mystery of boot sectors supposedly starting with byte value 69h, I considered the possibility that the check could have been added for MSX machines. The MSX platform ticks a lot of boxes: It wasn’t 8086 (but rather Z80), used 3.5″ floppies, used FAT format, appeared around 1985, and Microsoft was involved in it.

But looking closer, MSX is quite unlikely for one simple reason: Microsoft was clearly concerned about data exchange with PCs, and solved the problem differently. MSX floppy boot sectors actually start with the usual 8086 instructions, and if they’re booted on an MSX machine, the boot sector starts execution at offset 1Eh.

Not only that, but the MSX BIOS in fact requires that the floppy boot sector must start with byte EBh or E9h to be considered bootable at all.

The above is clearly documented in the MSX Technical Data Book (published by Sony in 1984). Extant MSX floppy images confirm the documentation—MSX floppies use 8086 opcodes in the first three bytes.

But wait, there’s more…

More Mystery

A reader pointed out that although the FAT driver in Windows NT does not check for byte 69h, it does check for byte 49h. The check was added sometime around 1995 and did not exist in the original NT releases.

Unfortunately the 49h check in Windows NT is just as undocumented as the 69h check in DOS. Windows NT was adding support for additional RISC platforms in that time frame (DEC Alpha AXP, IBM/Motorola PowerPC) and the added check could have been related to that. Or not.

It is notable that 69h and 49h are ASCII codes for ‘i’ and ‘I’, respectively. When considering three-byte strings, ‘IBM’ certainly comes to mind; however that is pure speculation and no boot sector with such a signature is known to exist.

I also set out to examine the relevant OS/2 driver (OS2DASD.DMD) source code in the hope that it might reveal something. But no, IBM only checks for the usual EBh and E9h bytes. Which does not answer anything, but implies that boot sectors with 49h or 69h in the first byte must have been fairly exotic.

One day, those boot sectors will hopefully turn up and then we’ll understand why the mysterious checks were added.

This entry was posted in IBM, Microsoft, PC history. Bookmark the permalink.

15 Responses to Not MSX, Either

  1. Octocontrabass says:

    FM Towns boot sectors start with “IPL”.

    I have no explanation for why it would’ve taken Microsoft until 1995 to notice, if that really is the reason for the check.

  2. zeurkous says:

    @Ocotocontrabass:

    Leaving bugs unfixed is a time-honoured M$ practice.

    Especially if they break compat w/ inconvenient competitors.

  3. Michal Necasek says:

    Didn’t FM Towns use a different physical floppy format? 1K sectors or something? At any rate this would have been relevant in Japan, and I’m not sure how well the initial NT releases supported the Japanese market. I know they had Japanese support reasonably early on but not sure when exactly.

    That ‘IPL’ would certainly match…

  4. techfury90 says:

    IPL is also used as the magic number by the PC-98 BIOS on bootable HDDs, too- except you wouldn’t find that in the FAT boot sector, but rather in the reserved cylinder that holds the PC-98 partition table and boot menu code.

    I think the FM Towns cloned the PC-98 1.23M disk format (360 RPM, 77 tracks, 8 1024 byte sectors/track) as well.

    BTW, NT 3.1 allegedly exists for PC-98, but I haven’t found it. Have 3.51 and 4.0 here, though.

  5. bleuge says:

    I’ve been following this mystery with quite interest. I did something,
    – got many msdos floppy collections out there, initially I got simply plain .IMG/IMA files, but later take the work of converting many formats to try to find new boots.
    – I tried the best not to add files not related to x86-msdos, but there are many dumps of operative systems, AFAIK all for x86, games, commercial software, etc.
    – final floppy number was around 70.000, deduped them and got around 39.000 unique floppy dumps.
    – extracted the first 512 bytes of each dump, total deduped approx 21.200

    I know what are you thinking πŸ˜€ , is there any floppy out there that starts with a 69h?.

    No, I found ZERO. I really was thinking I was going to found something, there is many rare floppies in these collections, many protected games have weird boots, protected software, operative systems as Netware, many Unix variants for x86, cpms, etc… all those were in the collections.

    So for me, this mystery is even more interesting.

    If anyone needs a dump of those boots, the file is quite small and I think can be shared with any problems. Just ask. Collections uncompressed was around 80gb I think.
    For clarification, these are some stats of 20 most used first bytes by freq:
    dec;hex;count
    235 ; EB ; 20317
    46 ; 2E ; 262
    233 ; E9 ; 245
    9 ; 09 ; 190
    250 ; FA ; 142
    80 ; 50 ; 85
    85 ; 55 ; 73
    0 ; 00 ; 65
    64 ; 40 ; 63
    184 ; B8 ; 48
    2 ; 02 ; 41
    51 ; 33 ; 37
    232 ; E8 ; 27
    118 ; 76 ; 25
    65 ; 41 ; 23
    140 ; 8C ; 23
    47 ; 2F ; 18
    67 ; 43 ; 17
    234 ; EA ; 16
    253 ; FD ; 16

  6. bleuge says:

    I forgot to say, unique boot dumps could be greatly reduced a lot, clearing the label zone and maybe OEM zone, but I prefered to keep them intact. But could be done easily if anyone is interested in analyzing weird boot sectors, startup code, etc.

    Also, it’s easy to find original floppy dump just by filename, as these collections are indexed and hashed, if you find something interesting and want to analyze the floppy dump, not just the boot sector.

  7. Julien Oster says:

    So 0x2e is the second most common byte that boot sectors start with, even before 0xe9? Are there any bytes that commonly come after that? By itself, it’s just a CS segment prefix. This is a separate question from the one that’s being investigated here, but I think it was an interesting detail nonetheless.

  8. Michal Necasek says:

    I too am curious about the boot sectors starting with 2Eh. I assume those boot sectors do not have a BPB (it should be ignored if they did).

    Thanks for doing the stats. It’s too bad neither the 69h nor 49h byte showed up… but not exactly surprising, either.

  9. bleuge says:

    Here is the collection of boot files, 21.949 unique files.
    Filenames sometimes provide useful info of where this boot sector was.
    The origin of all these files are floppy collections found in some projects, as TOSEC, TOSAC, MESS PC files, Grubby’s Adventure sources, TGOD, etc, etc…

    https://www.mirrored.to/files/0JT1TMXO/

    Please if sharing this here is wrong, just delete this.

  10. Octocontrabass says:

    Your collection must not include any FM Towns disks if you didn’t find any boot sectors that start with 49h.

    The boot sectors on FM Towns floppy disks do contain x86 code, but it starts after the “IPL” signature. If the disk has a BPB, the jump instruction to go around it will be in the OEM name field.

  11. Richard Wells says:

    A number of the images have what appears to be boot sector viruses. The original boot sector is probably more interesting than another copy of an already well known virus.

  12. Julien Oster says:

    I forgot, did they usually save away the original boot sector to another sector, or did they just reimplement a common MS-DOS boot sector as part of their code? (Which would most likely limit them to very specific DOS variants, given that not all of them used files names IO.SYS and MSDOS.SYS.)

  13. Michal Necasek says:

    I don’t actually remember, even though I have a clear memory of analyzing a boot sector virus 25+ years ago (it was a lot more work without IDA). I believe the original boot sector was stashed away somewhere else on the floppy, but am not entirely sure.

    I will say though that even if the boot virus effectively destroyed the boot sector, it could still spread — if the boot virus just said “this floppy isn’t bootable, remove and press a key to retry boot”, it could stay installed in memory and boot off of a hard disk or a different floppy.

  14. Richard Wells says:

    The Stoned virus was famous for stashing a copy of the original boot sector in the last sector of the directory of a 360K floppy. Hard coded, of course, so it wrote to that sector even on other types of floppies where the sector might have been used for something else. I think most of the boot sector viruses did something similar, especially those that tried to conceal themselves by redirecting INT 13h away from the virus boot sector. Unfortunately, some of the virus strains indicated are not ones I have encountered before and I have no idea how those handled the boot sectors.

    This does show a source of incorrect boot sectors that I hadn’t considered before: buggy repair code in anti-virus software.

  15. Julien Oster says:

    Ah, good point with non-booting disks being infectious.

    Richard, I bet there’s a not too bad chance of finding the original boot sectors by just looking for the boot sector signature (55 AA) at the right offset in every sector. I don’t imagine false positives being overwhelming, and I don’t see why viruses would want to obfuscate the copy (other than maybe eschewing very ambitious heuristics for unknown viruses).

    I just looked up Parity Boot B, the one virus that managed to resurface on my disks for a surprisingly long time. It didn’t help for full detection that its damage routine (apart from the potential damage done during reproduction) seemed to be pretty unreliable (and rather benign): It was supposed to randomly lock up the machine displaying “PARITY CHECK” in 40×25 mode (pretty anachronistic I think), but I think I only remember that happening once. So it managed to stay around.

    That virus did save the original boot sector away, overwriting the last sector for root directory entries. It’s well possible that I never had an infected disk that had that many files in its root dir, or that I never noticed missing entries.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.