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…
It’s likely that the only way to answer this question is to find out who worked on DOS 3.20 MSDISK and ask them and hope they remember what that was about after 30+ years. Otherwise the code’s true purpose will remain a mystery like the CDh 21h CBh (INT 21h/RETF) “portable method of system call” in the PSP at 50h which was supposedly added for something planned but never implemented. Perhaps that’s what happened with the MSDISK code.
The system to look at would be the Tandy 2000: an 80186 system that MS was heavily involved in promoting. The other 80186 machines tend towards very obscure like Durango Poppy, Pronto Series 16, and MAD-1.
I tried examining a Tandy 2000 disk image but I had trouble parsing out the Teledisk header to find the boot sector. Tandy 2000 used its own format and had some issues reading IBM PC formatted disks despite having a version of DOS that was supposed to handle both.
Yes, it could be something that never panned out, and it’s quite possible that no one even remembers. Speaking of the alternative system call, IBM DOS 2.00 reference (6936752), page D-16 says that a DOS “function may be invoked in one of these ways: 1) Place the function number in AH and execute a long call to offset hex 50 in your Program Segment Prefix. Note that programs using this method will not operate correctly on DOS Versions 1.00 and 1.10. 2) Place the function number in AH and issue interrupt type hex 21. 3) There is an additional mechanism provided for pre-existing programs that were written with different calling conventions. This method should be avoided for all new programs. […]” The first one is the mysteriously useless call to offset 50h. The third one is the CP/M CALL 5 method. The far call method was listed first and at least implicitly recommended. Did anyone bother? Who knows…
It is highly doubtful the 69h byte was for a 80186 system since 69h is IMUL on a 80186/80188. Presumably the “direct jump” comment in MSDISK has some meaning but that meaning is thus far lost to time.
The MS-DOS Encyclopedia also mentions the far call to PSP:50h but doesn’t say why it exists in the first place:
“PSP:0050H (New MS-DOS Call Vector) Many programmers disregard the contents of offset 50H. The location consists simply of an INT 21H instruction followed by a RETF. A .EXE program can call this location using a far call as a means of accessing the MS-DOS function handler. Of course, the program can also simply do an INT 21H directly, which is smaller and faster than calling 50H. Unlike calls to offset 05H, calls to offset 50H can request the full range of MS-DOS functions.
That would be indeed a good candidate. The Tandy 2000 disk format was different, but should be readable on PCs. The one Tandy 2000 disk image I could quickly find (winworldpc) had a standard jump at the beginning of the boot sector, nothing unusual at all. I can decode Teledisk images, if you can point me at some.
Other candidates would be Zenith Z-100, HP-150, some weird Olivetti perhaps. But there’s a lot more, there were probably dozens of those DOS compatibles in 1982-1983.
Here’s a thought: is it possible that the 69h was used for debugging in 8086/8088 ICE software ? Since the 60h-6Fh range was undefined on the 8086/8088 perhaps they were used by a debugger for special functions (like perhaps a “direct jump”).
Another non-PC platform using FAT disks……MSX-DOS. There is also the relatively obscure MINDSET.
Back around 1984 the company I worked for sold HP and Canon computers.
Some MS-DOS / non-IBM compatible machines from HP were the HP150A (TouchScreen), HP150B (TouchScreen II), HP110 (Portable 16-Line display) and HP110 Plus (Portable Plus 26 line display). The portables booted from ROM.
This is a link to a Teledisk Demo for the 150. I don’t know if this is bootable. There isn’t an MS-DOS boot dosk listed.
http://www.hpmuseum.net/display_item.php?sw=68
We also had the Canon AS-100C/M (Color or Monochrome) an MS-DOS machine. It used 8″ or 5 1/4″ Quad-Density 96TPI disks. The format program did not do a low level format, you had to buy Canon pre-formatted disks. Eventually we found we could image copy them and then format would work.
The Old Computer Museum has an Teledisk image of the MS-DOS disk for the As-100.
oldcomputers.dyndns.org/public/pub/rechner/canon/canon-as.100/images/AS100IMG.ZIP
I don’t know if that image would help in this discussion.
FWIW, the FM Towns (and X68000) floppy format (360 RPM, 77 tracks, 8 sectors of 1024 bytes) comes from the PC-98.
That format goes way further back, to the late 1970s. It’s the 8″ DSDD format, or at least one of them. I’m pretty sure NEC used it on their old 8″ drives and I guess they moved it as is to 5.25″ drives. Capacity-wise it’s very similar to the 80 tracks, 15 sectors of 512 bytes 5.25″ HD format. Slightly better actually, but potentially with more space wasted due to the overhead of larger sectors (i.e. less efficient for lots of small files).
I’ve got a big repository of floppy images in a miriad of formats. Around 20.000 or so.
Some time ago i extracted the boot from all .IMGs, delete dupes and got around 3000 boot sectors images (this could be futher reduced by eliminating some things, but i prefered to keep them unmodified).
I’ve just checked everything looking for 0x69 in first byte, found nothing. This is not unexpected because i assume .IMG floppies are msdos stuff. But i got tons teledisk (specially) and other formats, Kryoflux, Supercard, etc, etc. Many of these are not msdos for sure (cp/m, etc) so maybe i could convert everything to IMG (a not easy task as i am sure you already know) i try to find this in the set. I’ll report if i do it and found something interesting. Thanks for great articles (and sorry my english)
I have checked a few of the HP 150 images from the HP Museum, but they actually start with a standard JMP instruction. The Canon AS-100 images are all in CP/M format, not FAT, so that can’t be it (and they start with a regular JMP instruction).
Conversion is not easy, no 🙂 Not everything can be converted, there are lots of weird formats out there and also some sketchy images (for example I ran across an image of a single-sided disk which was clearly made from a double-sided floppy and contained data on the unused side).
Although if you reduce the problem to extracting the first sector, it’s a lot easier. The thing we’re looking for is FAT-formatted and almost certainly 5.25″ media but beyond that it could be anything.
Another thing to consider (and I’ve done some work in this field) is Bios boot sequence examination. It’s easy to obtain a large collection of PC bioses for all brands (in part thanks at the huge effort of preservers) and look there for other appareances of this 0x69 byte.
It could be correcting for a mistake in an early assembler or the high bit being stripped off during one of the electronic transfers between Boca and Bellevue. Wasn’t be the first time that working code continued to be supported even if it did not use the expected instructions.
I did look at a few of the stranger MS-DOS variants I have and haven’t seen anything using 0x69.
Stripped high bit is definitely an interesting possibility. It is also possible that the code doesn’t make any sense and never did. This discussion is actually a good illustration of why no one would want to remove such code — it’s impossible to tell what it might break.
Okay, what about this: programmer gets stripped stuff, assumes this is
the new ‘DOS 2.0’ jump, jumps to add code to handle it, finds out that
it’s stripped stuff, scrambles to get a new, correct copy, and forgets
he added the code.
And indeed, everyone coming after the poor fellow would’ve carefully
preserved the error, just in case removing it might break something…
Michal – The Canon AS100 had both MS-DOS and CPM/86 available. Sorry that this was the CPM variant. The disks I had for the AS100 went up in a fire 9 years ago.
It was initially introduced when MS-DOS was ported to the PC-98 in 1983. (At the time of the PC-98 launch in 1982, only standalone NEC N88-BASIC and CP/M-86 were available.)
You are correct, it was originally for 8″ DSDD diskettes, but your timeframe is a bit off. The initial format was the 256 byte one, used by standalone NEC N88-BASIC and CP/M-86. It, IIRC, technically came from the NEC N5200 intelligent terminal/PC hybrid introduced in 1981, which the PC-98 was vaguely related to. The APC is an export version of the N5200, whereas the APC III is an export PC-9801F version.
The timeline is from Wikipedia (not a reliable source of information, I know!). The 8″ DSDD format with 1024-byte sectors was supposedly used by IBM in the late 1970s, also supported by Shugart drives. I’m by no means an expert on 8″ drives or early NEC PCs. What’s certain is that the 8 sectors of 1024 bytes format is mentioned in the NEC uPD765 datasheet from 1978. So definitely not new.
If I understand it correctly the APC used 8″ drives and the APC III used 5.25″ drives. I found a few APC MS-DOS disks but not much for APC III.
Yes, the APC uses 8″ disks. The APC III most likely uses the PC-98 “640k” DSQD format, 8 sectors of 512 bytes. The PC-98 BIOS is capable of booting from all supported uPD765 sector sizes, both MFM and FM.
Brief rundown on PC-98 disk drives, formats, and interfaces:
1982-1983: systems came with a “5.25” FDD” and “8” FDD port”. The 5.25″ one was really an 8255 based parallel port that communicated with the “intelligent” DSDD drives used on NEC 8 big machines. Very rarely used. The 8″ port was driven by a uPD765, as you’d expect. I believe 8″ DSDD was the most common format at this point.
1983: NEC offers “640kb” 5.25″ DSQD diskettes and drives, using an optional controller board. This format did not seem to gain much steam.
1984: NEC introduces the PC-9801M with a built in 5.25″ DSHD diskette drive. This drive is fully logically compatible with the 8″ DSDD drives. This becomes the standard PC-98 5.25″ format. The 9801M and later rename the “8” FDD” port to “1 MB FDD”.
1985: NEC introduces the first “small form factor” machine, the PC-9801U. This machine has 3.5″ DSDD drives. Logically compatible with aforementioned DSQD drives.
1986: NEC supersedes the PC-9801U with the PC-9891UV, which introduces a 360 RPM 3.5″ DSHD drive, logically compatible with the 8″ DSDD and 5.25″ DSHD drives. This becomes the standard 3.5″ format.
1986?: due to the RPM difference, early DSHD drives could not read DSDD or DSQD diskettes. NEC’s solution is to add host RPM control. The 3.5″ drives use the media density hole to select RPM instead.
1993: PC-9821A series introduces “3 mode 3.5″” drives, which support reading and writing “standard” 1.44 MB formats. This is again accomplished using host-based RPM control.
@techfury90: can you comment on http://www.os2museum.com/wp/is-it-so-hard-to-document-things/
I left a comment just now with a link to a Japanese reference stating that it is a function in PC-98 DOS 3.30. It appears to be stuck in moderation for now, though.
Actually, the link in addition to the bit of Japanese got it flagged as spam. So good job making me check the spam queue.
Oh, I sent this comment to the other article, by mistake…
I think I wrote it somewhere else… There’s a possibility that a bad quality printed E9 or e9 (which is a JMP) and/or a bad quality scanner and/or a bad quality OCR turns into a 69 and nobody noticed a char was changed.
Probably not since the code checks for E9h and then EBh xx 90h. Also later versions of DOS have additional comments mentioning the 69h again and referencing existing commercial products; I believe it says something about Symphony diskettes.
So where are those Symphony disks now 🙂
For reference: MS-DOS 3.21 OAK has the 69h check in there, including the weird “direct jump” comment. MS-DOS 2.11 does not, and in fact DOS 2.x has no similar code — back then PCs only had low density 5.25″ drives, and the BPB validation logic isn’t there at all AFAICT.
A bit of disassembling indicates that the 69h check was not there in PC DOS 3.1, but was added in PC DOS 3.2. PC DOS 3.1 IBMBIO.COM (March 1985) had the 0x55AA boot sector signature check, but nothing else. DOS 3.2 IBMBIO.COM (December 1985) added the 69h/E9h/EBh checks on the first byte.
So we’re probably looking for something from 1985, definitely no later than ’85, though possibly a bit earlier.
I assume that Symphony referred to Lotus Symphony, perhaps some sort of data disk it created ? I don’t know when the additional comments were added to MSDISK, only that they were in PC DOS 6.3. I would guess they were added in MS-DOS 5.0 or 6.0.
I really doubt the 69h check has anything to do with non-PC software. What would be the point of having DOS read disks from a non-DOS system even if it was FAT-based ? Obviously any executables on the disk wouldn’t work.
Someone mentioned MSX-DOS. I hunted down a MSX-DOS boot disk image, and while it is indeed FAT12, the starting bytes are EB FE 90.
It has to be a boot disk or it wouldn’t have any type of jump there.
Yesterday’s storm provided an incentive to search on the topic though without any real success. I did find two interesting occurrences during the 1984-85 timeframe that might have had some bearing.
1984 had a number of suggestions replacing IBM’s short jumps with a different start up method relying on 0xE9 long jumps. There is a net.micro.pc posting from Feb 1985 regarding “Fastboot” using it which also refers to other postings and an article on the same topic. None of which were given enough details for me to locate. Frustrating because those could be sources to clear up whether ox69 was a mistake, simple copy protection, or someone trying undocumented instructions.
Probably unrelated but the cause of some changes between DOS 3.1 and 3.2 was a 1985 bug involving DOS 3.1 and external hard drives. Drives from Tallgrass, Emerald, and Falcon would not work under DOS 3.1. I have never used any of those drives limiting my knowledge of them.
The boot sector is the same, non-bootable disks have executable data in the boot sector too! In fact if they didn’t, they’d just hang the system instead of printing a message that they’re not bootable.
Do you have a reference to the net.micro.pc post?
The DOS 3.1 bug is something I need to do a bit of research on. I’ve seen it mentioned, and I believe that yes, that’s why the extra checking code was added in DOS 3.2. But I didn’t quite understand the exact problem that was meant to solve. There was also a check on the OEM signature in the boot sector.
Actually I’m lying, the check for bad BPBs created by DOS 3.1 was apparently only added in DOS 3.3. But DOS 3.2 already contained other checks (including the 69h one).
One of the problems was single-sided floppy disks whose BPB incorrectly indicates 2 sectors per cluster (in reality 1 sector per cluster was used).
The following link should match up to Google Groups entry for the relevant post:
https://groups.google.com/forum/#!search/net.micro.pc$20%22fastboot%22/net.micro.pc/3lJFdwEUMgo/IAYcHbQZR18J
Otherwise, a search on Google Groups for “net.micro.pc” and “fastboot” should lead to it.
It was mostly of interest to me as a hint that a sudden surge into reworking DOS boot methods was occurring.
@meself: By this time me of course realizes that me story cannot hold
up as such, as meappears to have confused the code comments.
With a little twist, though, it’s still plausible: if the comments were
only added later, or the code ‘cleaned up’ by someone who didn’t know
its purpose in the first place (a more common occourence than we’d like
to think), it might still be a simple (yet compounded) misunderstanding.
Mesupposes the point me’s trying to make is that it might not’ve been
one event, but multiple subsequent ones, that led to the code as it is
now. Me apologies if this is obvious.
Not to discourage anyone, but me’s really starting to feel that we won’t
get much further w/o contacting the programmers. Then again, me’s fairly
sure that M$ (at least at the time) didn’t diligently keep track of
every little change, so it might not be feasible to even track them
down.
Meofcourse hopes me’s wrong, and that there’s still a simpler
explanation. Wish mecould help with that.
The code was added probably late 1985. We have the comments from no later than early 1987. If the comments were added later, it was not much later.
Because it was a change in a point release, there probably was a specific bug behind it. How well Microsoft kept track of those I don’t know, but in general they did keep track.
PC DOS 3.2 was released in April 1986 though the file timestamps are Dec 30, 1985 so that code must have been added in late 1985. Presumably there was some software that had the 69h boot sector that was important enough to warrant adding the check. What that software was and why the 69h was termed a “direct jump” we may never know. Theoretically some software could have used the fact that 69h was the same opcode as 79h (JNS) on the 8086/8088 and relied on the fact that the sign flag was clear when the boot code was executed as part of some questionable code obfuscation. Of course using undocumented opcodes is generally a bad thing to do since they may go away in later processors or even later revisions of the same processor but that didn’t stop people from using them anyway.
Can this check be a workaround for bad floppy reader?
The format was always right. Maybe there was a floppy hardware that got the first bit of the first byte wrong (in some cases).
I have little experience with hardware bugs, but at least on first sight there is no contradiction in the above scenario.
Unlikely. The data is protected with a CRC, so such bit flips should not go undetected.
Could 69h as a jump possibly have been something planned (and made known to Microsoft) but ultimately left implemented, but included in the disks just in case (like how LINK recognises four x86 instructions that have never been implemented in any mass=produced CPU)?
Doubtful. At the time the code was added (late 1985) 69h was already defined as IMUL on the 80186 and 80286.
Probably this is nothing but the MSX-DOS article of Wikipedia (as reliable as that can be) has this text:
One major difference between MSX-DOS and MS-DOS 2.x was that MSX-DOS did not use the “boot sector” on the floppy to boot, but booted using the BDOS ROM routines.
It doesn’t say what is in the boot sector of MSX-DOS, if it is Z-80 code or something else.
The timeline (1985-ish) would match, but the Wikipedia article also says MSX-DOS did not use the BPB at all.
Afaik MSX-DOS would run on Z80.
How about Spectravideo pre-MSX disks? (I.E. for the SVI-318/328) Those machine is the forerunner of MSX, with about the same hardware but earlier and with an incompatible adress map. (Afaik if you change the adress decoding and ROM contents you could probably make it MSX compatible).
I’m not sure what format they used. Afaik this machine can boot CP/M if it’s equiped with an 80-column add-on video card, but the disk drives must also be usable from Basic and then it probably used something else than CP/M. With a Basic from Microsoft it might aswell have used some pre-MSX format.
The Spectravideo disk formats before the MSX emulator (and related MSX DOS were added) can be found http://samdal.com/svdiskformat.htm The DISK BASIC format will give the IBM PC fits. It includes a single density track 0 with the remaining 39 tracks being double density. Notice how the initial program load routine starts at the byte 1 of sector 14 of track 20 (all values start include a zero byte, sector, and track). This is definitely not the disk MS-DOS was correcting for.
Unless a former MS or IBM employee sees this and remembers the story behind it or an original disk with the unusual jump code is found, the truth may never be determined.
Right, the Spectravideo disks can’t possibly be it. The MSX-DOS disks shouldn’t be it either since they reportedly didn’t have a BPB.
Efforts are currently underway to find someone who might remember the story. We’ll see.
Vol verwachting klopt ons hart…
Okay, a more recent discussion got me thinking: meoften uses 0x69 (and
0x71, from George Carlin via ‘fortune -o’), as placeholder values.
Mewonders if that isn’t just the case here.
Poking around, on the 68000 69h is a conditional branch instruction (Bvs – Branch on Overflow Set) which includes the displacement in the encoding. Even if that is the case it’s an odd choice as there is a BRA (Branch Always) with a value of 60h which handles the displacement the same.
I’m doubt this is the right answer in this case as it’s a odd choice of instruction, but it is an interesting coincidence.
69 could be a typo of 60 though as 9 and 0 are next to each other. (Any computer user old enough would type numbers on the alphanumeric part of the keybard as there were no numeric part of the keyboard on a bunch of the various machines that people might had first started using computers with (or even first started typing using a keyboard). Everything from the old Teletype ASR 33 to a Commodore 64 lacked a numpad).
So it’s not unlikely that it’s refering to Atari ST.
No, it is very unlikely. Presumably whatever disk had a 69h as the first byte in the boot sector was tested at the time so a 60h typo wouldn’t have worked. Also why would Microsoft have possibly cared about reading Atari ST disks on DOS ? Completely different architecture.
Because the Atari ST used FAT-formatted floppies, so for data exchange they might have cared. I don’t know if that’s what it really was, but it’s not impossible.