Four years ago we pondered why on Earth a DOS floppy boot sector might start with 69h, supposedly a “direct jump” opcode. Which is the IMUL instruction on 80186 and later, and not documented on 8086. In the meantime, it turned out that one of the basic assumptions was invalid: The boot sector does not have to begin with executable code, and in fact need not contain any executable code at all.
This goes back to a distinction which used to be important but over time got all but forgotten: There is a difference between a “DOS compatible” and an “IBM compatible” (or PC compatible) machine. DOS-compatible systems are a superset of IBM-compatible ones. In the early to mid-1980s, there was a fairly large class of 8086/8088 machines which used DOS (and therefore, FAT-formatted floppies) but were not PC compatible. In fact DOS-compatible machines came first, in the form of SCP’s S-100 bus systems running MS-DOS, née 86-DOS, predating the original IBM PC.
It was far from obvious in the early 1980s just how dominant the IBM PC and derived designs would become. A number of vendors offered 8086/8088 machines running DOS (often DOS 2.11) but not using IBM-style ROM BIOS and not necessarily using even remotely IBM-compatible hardware and peripherals. Some of the better known examples were the DEC Rainbow 100 (dual-chip Z80/8088), the Apricot PC, or the NEC APC-III.
Most of the DOS-compatible machines quickly gave way to PC-compatible ones, simply because of the immense wealth of software and hardware produced for PCs (and not for the DOS compatibles). One of the notable exceptions was the NEC PC-98 series whose last model was introduced in 2000. NEC’s PC-98 served the Japanese market, to a significant extent insulated from most of the rest of the world until the Windows 9x era. Another Japanese DOS compatible system was Fujitsu’s FM Towns, introduced as late as 1989 and built until 1997.
There was of course yet another, even more distant class of a system, which one might call “FAT compatible”. For example the Atari ST was built around a Motorola 68000 CPU, but its operating system (TOS) used FAT-formatted floppies.
What does this have to do with DOS boot sectors? A lot. All these systems used FAT-formatted floppies, either optionally or exclusively. They also showed that the FAT filesystem is reasonably flexible. Around 1981, SCP used 8″ single-and double-sided FAT floppies with 128-byte and 1024-byte sectors. Apricot used single-sided 3½″ floppies with 512-byte sectors and 70 tracks. FM Towns used 3½″ floppies with 1024-byte sectors. There were lots of possibilities.
SCP’s older floppies did not even use a BPB (as they predated DOS 2.0), only a FAT media descriptor byte. Older variants also had two tracks (52 sectors) reserved at the beginning, not just a single sector.
Apricot used a BPB, but at offset 50h in the first sector, not at offset 11. There was no executable code. The first sector might start with an ASCII string such as ‘VR 1.3’ or ‘VB 1.5.0’, or just with a sequence of zero bytes.
FM Towns disks had a BPB at the usual offset, but the boot sector started with an ‘IPL4’ signature, followed by a jump instruction at offset 4. As mentioned, the disks used 1024-byte sectors.
So where does that leave us? The previously referenced MSDISK.INC source file (from the DOS 3.21 OAK) which includes the curious 69h “direct jump” check is all 8086 assembler, so certainly not intended for non-x86 systems. And it contains IBM style BIOS invocations (INT 1Ah, INT 13h), which means it is in fact intended to run on a PC compatible.
But that does not necessarily mean the code is only intended to read disks created on a PC compatible. However, the MSDISK.INC code is only prepared to deal with 512-byte sectors, and can be assumed to be only able to read disks that a PC compatible can read.
Unfortunately that still leaves a rather large set of potential suspects. Despite the “direct jump” comment, the first byte of a boot sector on a FAT-formatted disk need not be an 80×86 instruction. It could be literally anything.
What we’re looking for is then a 5¼″ or 3½″ floppy using a physical format reasonably close to IBM’s, and formatted with FAT file system, but probably not created on a PC compatible system, and potentially not even created on a system with an x86 CPU.
We know what it’s not. It’s not FM Towns—wasn’t even around in DOS 3.21 times, and uses 1024-byte sectors. It’s not Atari ST—boot sectors starts with BRA.S instruction, opcode 60h. It’s not Apricot PC—boot sector did not start with any particular value, certainly not 69h. It’s not the Rainbow 100—there were two reserved tracks and software-visible interleaving, and the boot sector didn’t start with 69h anyway. It’s not the old NEC APC—that used 8″ floppies (256- or 1024-byte sectors), although I could not find any NEC APC III media (those were 5¼”).
That leaves a lot of possibilities, including the one that the code in MSDISK.INC is simply erroneous. Maybe we’ll find out in another few years…
The Atari ST wasn’t nearly significant enough for Microsoft to have cared about it. Anyway 69h is a conditional jump on 68000 so it doesn’t really make sense that it would be used as the first byte of the boot sector. 60h which is an unconditional jump would make sense there.
Keep in mind there is no reason to believe that whatever disk used the 69h was actually bootable. It could have been used for a data disk as part of some short signature (69h = ‘i’).
dosfan: at the time Atari ST were being developed, it might not had been decided who would to the software. DR saw their chance to be relevant for a while more. Microsoft couldn’t had been ruled out as a choice though, as they were a part of the MSX standard that formed at about the same time. If there were some ideas of Microsoft making the software for Atari ST they might aswell have had a conditional jump on the disk, with some information from the rom telling the disk boot code something.
Or as I wrote earlier, it might just had been a typo. 9 and 0 are next to each other. It’s not unlikely to be a typo and then something never tested (especially as Microsoft never made software for Atari in the end).
69h in 68000 is BVS (branch if overflow set) so that’s unlikely. Checking the carry flag or zero flag would seem to be much more likely conditions to check. I also find it unlikely that it was untested since the 69h check was specifically added in DOS 3.2 and it would have been easy enough to setup an appropriate boot sector with a disk editor to test the code. Also the comment says “direct jump” but doesn’t mention 68000 which you would think would be a very important detail to mention. Later versions of MSDISK.ASM additionally refer to 69h as a “long jump” and specifically say “69h” in the added comments. If it was a typo then this would have likely been corrected when the new comments were added.
Why would the V flag be more unlikely than the C or Z flags?
On 68000 you set, clear och toggle flags using AND, OR and EOR to the condition code register (=flag register in other CPU’s terminology).
But still, a typo seems more reasonable and since Microsoft ended up having nothing to do with Atari ST they had no reason to spot / correct the typo.
I’m not saying this is super plausable, but it seems like the most plausable explanation yet.
I’ve done quite a lot of assembly language programming and the overflow flag is rarely checked via a conditional branch (e.g. x86 JO/JNO, 680×0 BVS/BVC). Heck there is an x86 opcode INTO (interrupt if overflow) which I have never seen used.
I find the idea that it’s a typo highly unlikely. That would mean something just put some new code in without testing it all, didn’t catch it later and no one else noticed this curious check and asked about it.
Anyway it’s pointless to speculate, the only way to known for certain what the check was for is to find a disk which actually has it, find internal documentation from the time or have someone who worked on MS-DOS 3.2 say what it was added for.
My guess is that it’s simply a typo. Someone looked up a print copy of an 8086 opcode map and mistook the digit E for 6 (which may have been a misprint; the glyphs are quite similar, which lends this some credibility). Later they (or someone else) noticed the check doesn’t work on some actual floppies, so they copied the correct value from the disk… but left the previous check in, since ‘the manual can’t be wrong’.
Note how there is no check for a following NOP opcode if the first byte is 69h, unlike with EBh. This suggests that 69h is supposed to be a three-byte instruction, like E9h.
That is amazing timing given that I just published this.
The typo theory is as good as anything at this point. However, I’m leaning towards the non-x86 explanation. I just can’t believe that none of the people reading that code would miss the fact that 69h isn’t any kind of a jump instruction in the 8086 instruction set. Remember, we’re talking about 1985, and I’d bet at least some of the guys on the DOS team were able to read machine code well enough that they’d notice.