• Please review our updated Terms and Rules here

DOS mysteries

P

pcdosretro

Experienced Member
Joined
Jun 23, 2019
Messages
162
Location
San Francisco Bay Area
There are a few questions that even after working on DOS and seeing all of the source code I was unable to find an answer for:

2.0+ Why was INT 21h/RETF (CDh 21h CBh) added to the PSP at 50h ? Described as "portable method of system call" in the DOS source code (inc\pdb.inc) - portable to what ? Some people speculate it was intended for DOS/Xenix portability.

2.0+ What was the purpose for the undocumented INT 2Eh COMMAND.COM backdoor which executes a command as if it was entered from the command line and did any software actually use this ?

3.2+ In the floppy disk boot sector validation code why is 69h checked for as a valid first byte ? The DOS source code (bios\msdisk.asm) refers to 69h as a "direct jump" and in later versions also as a "long jump". Of course opcode 69h is IMUL on 80286 and later and undefined on 8086/8088 (likely functioning as an alias for opcode 79h JNS) so the comment makes no sense. The 69h could instead be part of a signature (69h = 'i') and the comment is wrong but since no disk has ever been found which uses this it is unknown why this check was added in DOS 3.2.

3.0+ Why was INT 21h function 62h (get current PSP) added when function 51h already existed ?
4.0+ Why was INT 21h function 6Ah (commit file) added when function 68h already existed ?
 
PSP:50h Besides Xenix, HandHeld DOS might be the other possible target of a portable system call. HHDOS differs from MS-DOS by using INT 42h for the interface. I haven't seen any shared code generator for either Xenix/DOS or HHDOS/MSDOS that went to PSP:50h.

INT 2Eh has a long discussion in Undocumented DOS. OPENDos lists Novell menus as a reason to upgrade Int 2eh support specifically to launch batch programs from within the menus.

New public functions that duplicate old undocumented functions: of course, those will be listed at the end. No one checks through the old API list to see what functions have newly become visible. Funny, Undocumented DOS first edition lists 6Ah as being unknown.
 
The 69h boot sector thing has been the subject of many discussions over the years, with no solid resolution.

I suspect a typo--the 69h should be E9h.
 
krebizfan said:
INT 2Eh has a long discussion in Undocumented DOS. OPENDos lists Novell menus as a reason to upgrade Int 2eh support specifically to launch batch programs from within the menus.
Click to expand...

Interesting book but nothing there would be official.

krebizfan said:
New public functions that duplicate old undocumented functions: of course, those will be listed at the end. No one checks through the old API list to see what functions have newly become visible. Funny, Undocumented DOS first edition lists 6Ah as being unknown.
Click to expand...

Whomever added the duplicate functions had to know they were duplicates. The undocumented functions were clearly marked as such in the source code. In the case of function 62h, my best guess is that they didn't want to mention any of functions 50h-53h so they just added a duplicate even though function 51h was already there since DOS 2. I can't imagine why function 6Ah was added when function 68h was already there since DOS 3.3 and documented. Another foolish thing done in DOS 4.

Chuck(G) said:
The 69h boot sector thing has been the subject of many discussions over the years, with no solid resolution.

I suspect a typo--the 69h should be E9h.
Click to expand...

Definitely not a typo, the code explicitly checks for all three: 69h, E9h and EBh.
 
Chuck(G) said:
That doesn't mean anything, in my opinion. The DOS code is littered with kludges that deal with prior errors.
Click to expand...

The 69h check wasn't there in DOS 3.1 so it was specifically added to deal with something. I remember there was also a comment about Symphony diskettes in that part of the code, presumably referring to Lotus Symphony.
 
krebizfan said:
PSP:50h Besides Xenix, HandHeld DOS might be the other possible target of a portable system call. HHDOS differs from MS-DOS by using INT 42h for the interface. I haven't seen any shared code generator for either Xenix/DOS or HHDOS/MSDOS that went to PSP:50h.
Click to expand...

I had never heard of HHDOS. Apparently a Tandy 600 specific thing. That Tandy 600 actually seems less PC compatible than the PCjr. Anyway it is from 1985 and the PSP:50h stuff was added in DOS 2 which came out in 1983.
 
pcdosretro said:
I had never heard of HHDOS. Apparently a Tandy 600 specific thing. That Tandy 600 actually seems less PC compatible than the PCjr. Anyway it is from 1985 and the PSP:50h stuff was added in DOS 2 which came out in 1983.
Click to expand...

Not just the Tandy 600. The Zenith ZP150 from 1984 is a more expensive version of a similar machine. And there may have been some Oki prototypes predating that. It would seem the idea of a MS-DOS variant sitting on a different interrupt would have been available in 1983. PSP:50h needs something that handles parameters the same as MS-DOS since all it does is pass control to the interrupt. With something like HHDOS code intended to also run on MS-DOS, it could make the call to PSP:50h and then get sent to the correct interrupt for the OS it is running on.

I should check Xenix function calls more carefully but I am fairly certain that a shared library would need to do a lot of work turning Xenix calls into MS-DOS calls, so much work that one might as well include the INT 21h call in the process.
 
krebizfan said:
Not just the Tandy 600. The Zenith ZP150 from 1984 is a more expensive version of a similar machine. And there may have been some Oki prototypes predating that. It would seem the idea of a MS-DOS variant sitting on a different interrupt would have been available in 1983. PSP:50h needs something that handles parameters the same as MS-DOS since all it does is pass control to the interrupt. With something like HHDOS code intended to also run on MS-DOS, it could make the call to PSP:50h and then get sent to the correct interrupt for the OS it is running on.

I should check Xenix function calls more carefully but I am fairly certain that a shared library would need to do a lot of work turning Xenix calls into MS-DOS calls, so much work that one might as well include the INT 21h call in the process.
Click to expand...

DOS 2 development began in 1982 so it seems unlikely the PSP:50h far call was for a system which used different interrupts for the DOS API. Did the Tandy 600 BIOS use INT 21h for something else ? Intel originally reserved interrupts 05h-1Fh for future use but IBM went ahead and used a bunch of them anyway.
 
Anent PSP:50h, probably a dead-end development. It would be interesting to see the internal PCDOS 2.0 design documents.

Discussion on the 69h thing here

As noted, the comment in MSDISK doesn't make any sense; 69h is not a direct jump; EAh is.

Code: 
               ; put a sanity check for the boot sector in here to detect
                ; boot sectors that do not have valid bpbs. we examine the
                ; first two bytes - they must contain a long jump (69h) or a
                ; short jump (ebh) followed by a nop (90h), or a short jump
                ; (e9h). if this test is passed, we further check by examining
                ; the signature at the end of the boot sector for the word
                ; aa55h. if the signature is not present, we examine the media
                ; descriptor byte to see if it is valid. for dos 3.3, this
                ; logic is modified a little bit. we are not going to check
                ; signature. instead we are going to sanity check the media
                ; byte in bpb regardless of the validity of signature. this is
                ; to save the already developed commercial products that have
                ; good jump instruction and signature but with the false bpb
                ; informations
                ; that will crash the diskette drive operation. (for example, symphony diskette).

         cmp    byte ptr [disksector],069h      ; is it a direct jump?
         je     check_bpb_mediabyte             ; don't need to find a nop
         cmp    byte ptr [disksector],0e9h      ; dos 2.0 jump?
         je     check_bpb_mediabyte             ; no need for nop
         cmp    byte ptr [disksector],0ebh      ; how about a short jump.
         jne    invalidbootsec
         cmp    byte ptr [disksector]+2,090h    ; is next one a nop?

Note that a "long jump" is called 69h in the commentary. But it isn't. Tell me that it's not an error!
 
Last edited:
Chuck(G) said:
Anent PSP:50h, probably a dead-end development. It would be interesting to see the internal PCDOS 2.0 design documents.

Discussion on the 69h thing here

As noted, the comment in MSDISK doesn't make any sense; 69h is not a direct jump; EAh is.

Code: 
               ; put a sanity check for the boot sector in here to detect
                ; boot sectors that do not have valid bpbs. we examine the
                ; first two bytes - they must contain a long jump (69h) or a
                ; short jump (ebh) followed by a nop (90h), or a short jump
                ; (e9h). if this test is passed, we further check by examining
                ; the signature at the end of the boot sector for the word
                ; aa55h. if the signature is not present, we examine the media
                ; descriptor byte to see if it is valid. for dos 3.3, this
                ; logic is modified a little bit. we are not going to check
                ; signature. instead we are going to sanity check the media
                ; byte in bpb regardless of the validity of signature. this is
                ; to save the already developed commercial products that have
                ; good jump instruction and signature but with the false bpb
                ; informations
                ; that will crash the diskette drive operation. (for example, symphony diskette).

         cmp    byte ptr [disksector],069h      ; is it a direct jump?
         je     check_bpb_mediabyte             ; don't need to find a nop
         cmp    byte ptr [disksector],0e9h      ; dos 2.0 jump?
         je     check_bpb_mediabyte             ; no need for nop
         cmp    byte ptr [disksector],0ebh      ; how about a short jump.
         jne    invalidbootsec
         cmp    byte ptr [disksector]+2,090h    ; is next one a nop?

Note that a "long jump" is called 69h in the commentary. But it isn't. Tell me that it's not an error!
Click to expand...

I agree the comment is wrong but the check had to be put there for some reason. I asked about it when I was at IBM and no one there knew what it was for.
 
pcdosretro said:
DOS 2 development began in 1982 so it seems unlikely the PSP:50h far call was for a system which used different interrupts for the DOS API. Did the Tandy 600 BIOS use INT 21h for something else ? Intel originally reserved interrupts 05h-1Fh for future use but IBM went ahead and used a bunch of them anyway.
Click to expand...

The Tandy 600 does nothing with interrupts below 40h. 40h to 4Fh were used by the HHOS while INT 50+ was for hardware use with a large number of skipped INTs. The work on HHOS started early enough that improved cassette support (INT 53h) was part of the design specification.

INT 42h was used for the standard functions. The ones I checked used the same parameters as the matching function number for MS-DOS. Basically, a lot of MS-DOS source code could be made to work under HH-DOS through the complicated effort of changing a reference from the original INT 21h to INT 42h. The executable is considerably different though so there can't be a dual use executable.

PSP:50h doesn't make much sense unless it was expected to have the possibility of referring to different interrupts for different implementations of DOS. Why waste the time with an unnecessary look at the PSP when the code could simply call the interrupt directly?
 
Chuck(G) said:
Were there any non-x86 architectures that wrote DOS-format floppies? (I already checked 68K (GEM))
Click to expand...

Atari TOS (Atari ST) came up in that thread. While the timing matches (1985) and TOS uses a version of the FAT file system, 69h on the 68000 is also a conditional jump which makes it unlikely as the first instruction of a boot disk.
 
Native? The 3B1's Convergent Unix could write FAT floppies, but it wasn't the native format. Likewise Apollo Domain/OS. Wasn't SunOS able to write FAT on floppy? And I know on the TRS-80 the Hypercross program could read and write FAT floppies. But that wouldn't explain the 69H.
 
Last edited:
Whatever the 69h boot sector check was for had to be around in 1985 when MS-DOS was in development and important enough for Microsoft to put that check into DOS. Perhaps the MS-DOS 3.20 OEM Adaptation Kit would mention why this was added in its update log. I know the MS-DOS 3.21 OAK is around but not the MS-DOS 3.20 OAK.
 
No, the system in question would have to write FAT12-format floppies routinely. So none of the non-Intel *nix would apply. Perhaps the iAPX 432, which, in 1981 was a hot topic? I've never seen a 432 boot floppy, myself.
 
pcdosretro said:
Whatever the 69h boot sector check was for had to be around in 1985 when MS-DOS was in development and important enough for Microsoft to put that check into DOS. Perhaps the MS-DOS 3.20 OEM Adaptation Kit would mention why this was added in its update log. I know the MS-DOS 3.21 OAK is around but not the MS-DOS 3.20 OAK.
Click to expand...
FWIW, MSX DOS uses the FAT12 format, but 69h is not a jump instruction on Z80 and MSX boot sectors actually begin with an EBh (ie. an x86 JMP)
 
So, for me, here's the $2⁶ question: Does any one have or has anyone seen one of these mysterious 69h floppies? I certainly haven't.

If one crops up, I'd like to see the boot sector.
 
You must log in or register to reply here.
Back
Top