This blog has previously examined a very very strange code fragment in the BIOS module of DOS. To recap, when deciding whether a boot sector might have a valid BPB, DOS checks whether the first byte is a relative jump (opcode E9h) or a short jump (opcode EBh), both used by different DOS versions. But it also checks for a “direct jump” with 69h opcode.
The code looks like this in the MS-DOS 3.21 OAK, source file dated May 1, 1987:
cmp byte ptr cs:[DiskSector],069H ; Is it a direct jump? je Check_Signature ; don't need to find a NOP cmp byte ptr cs:[DiskSector],0E9H ; DOS 2.0 jump? je Check_Signature ; no need for NOP cmp byte ptr cs:[DiskSector],0EBH ; How about a short jump. jne BadDisk cmp byte ptr cs:[DiskSector]+2,090H ; Is next one a NOP? jne BadDisk
The code is not materially different in the MS-DOS 3.3 OAK, source file dated July 24, 1987:
cmp byte ptr cs:[DiskSector],069H ; Is it a direct jump? JE Check_bpb_MediaByte ; DON'T NEED TO FIND A NOP cmp byte ptr cs:[DiskSector],0E9H ; DOS 2.0 jump? JE Check_bpb_MediaByte ; NO NEED FOR NOP cmp byte ptr cs:[DiskSector],0EBH ; How about a short jump. JNE INVALIDBOOTSEC cmp byte ptr cs:[DiskSector]+2,090H ; Is next one a NOP? JNE INVALIDBOOTSEC
The labels are different but the logic is identical. But of course there is no such “direct jump” on x86, and the 69h opcode (undocumented on 8086, IMUL on later CPUs) makes no sense whatsoever. So what is it?
A reader previously floated the idea that the code might have been intended to support Atari ST floppies. That sort of makes sense, and sort of not. Let’s start with how it does not make sense.
The Atari ST used the Motorola 68000 CPU (ST refers to Sixteen/Thirty-two, referring to the 68k CPU’s external and internal data width) and while boot sectors started with a jump instruction (BRA.S), its opcode was 60h and not 69h.
But there are numerous ways in which Atari ST does make sense. Atari ST was one of a handful of non-PC, non-x86 platforms that used FAT-formatted floppies. The Atari ST used the same 3.5″ DD (initially) media used by PCs. It was actually possible to exchange data between Atari ST and DOS on 3.5″ floppies.
The Atari ST was introduced in 1985. When was the mysterious opcode 69h check added to DOS? As it happens, we can pin down the timeline fairly accurately. Examining IBMBIO.COM in PC DOS 3.1 and 3.2 clearly shows that the 69h check was added in DOS 3.2. The IBMBIO.COM file in PC DOS 3.1 is dated March 1985, while in PC DOS 3.2 it’s December 1985. In other words, Microsoft must have added the 69h check sometime during 1985.
From the timeline perspective, adding support for Atari ST media in 1985 makes good sense. It also just so happens that PC DOS 3.2 was the first to support 3.5″ media.
The “direct jump” comment is less obvious but makes at least some sense. The 68k BRA instruction is direct in the sense that the relative offset is part of the instruction’s opcode sequence. Unlike 68k JMP, the BRA instruction does not support any kind of indirect addressing.
The opcode mismatch could also be explained. It could be a typo since ‘9’ and ‘0’ are right next to each other on the keyboard. It could also be a misreading; especially on handwritten text, a sloppily written zero might look like a nine. In addition, 8086 programmers might well not know 68k opcodes and thus would not spot the mistake.
What’s more, the incorrect check might easily have escaped testing. To begin with, Atari ST bootable floppies do start with 60h opcode (not 69h), but non-bootable ST floppies have no such requirement anyway. Except DOS does not require a valid BPB to work with a floppy disk. If a 720K floppy were formatted on an Atari ST, its boot sector would not be recognized, but its FAT media byte would be. DOS would be able to work with it just fine, and testers would not notice that the BPB validity check failed.
Note that the above is not true for Atari ST 800K floppies. DOS will not correctly deal with those unless they have a valid BPB (i.e. boot sector). That however is something which may not have been tested.
In summary, even though it’s actually wrong, adding the 69h check to support Atari ST disks is not as implausible as it seems. It’s by no means a solid proof but it’s not crazy. And if, as circumstantial evidence shows, the check was added to support some non-x86 platform in 1985, then Atari ST is a good explanation as any.