• Please review our updated Terms and Rules here

[DOS] How can I intercept "Insert disk in drive x: and press any key to continue"?

Krille

Veteran Member
Joined
Aug 14, 2010
Messages
1,104
Location
Sweden
[DOS] How can I intercept "Insert disk in drive x: and press any key to continue"?

On a single floppy drive system, A: and B: both point to the same physical floppy drive. So, for example, when the current drive is A: and you change to drive B:, DOS will print "Insert a disk in drive B: and press any key to continue" (or something along those lines). And vice versa of course (from B: to A:).

The problem is that this happens not only when you're changing drives on the command line but also in programs. I'm doing some improvements to XTIDECFG and I can't find a way to handle this in code - unless I filter out drive B: on single floppy drive systems but that feels like a hack and I would like to avoid that if possible - so having DOS print this message in the background really effs things up.

Is there a (simple) way to intercept this? I can't imagine I'm the first one to want to do something like this...
 
I was thinking of the DOS critical error handler, but that's probably not right.

It's a DOS message. If you hook INT 21 and look for accesses to the phantom drive (Drive B on single drive systems) that might work. But that's not something I would do from a BIOS ... having the BIOS reach in and hook 21 seems evil - you are violating the layering of the services when you do that.
 
I have a critical error handler in place but this happens before that is invoked unfortunately. Also, this is all in the configurator, not the actual BIOS. :)
 
In PCDOS 2, at least, there doesn't seem to be any sort of callback you can attach. Here's the code:
Code:
seg001:0727                 xor     si, si
seg001:0729                 mov     ds, si		;DS = 0
seg001:072B                 mov     ah, al		;AH = requested drive
seg001:072D                 xchg    ah, ds:504h		;Swap with 0:504 
seg001:0731                 pop     ds
seg001:0732                 cmp     al, ah		;Does requested=current?
seg001:0734                 jz      loc_70_74A
seg001:0736                 add     al, 41h		;If not, prompt.
seg001:0738                 mov     byte ptr aAAndStrikeAnyK, al
seg001:073B                 mov     si, offset aInsertDiskette
seg001:073E                 push    bx
seg001:073F                 call    sub_70_74D		;Print string using INT29
seg001:0742                 call    sub_70_1B7		;Flush keyboard input
seg001:0745                 xor     ah, ah
seg001:0747                 int     16h			;Wait for keypress
seg001:0749                 pop     bx
seg001:074A loc_70_74A:

About all I can suggest is:
* Save a copy of the byte at 0:504
* Hook INT29h and INT16h
* In the INT29h handler, if the byte at 0:504 has changed from your copy, then DOS is printing the "Please insert the disk for" message. SI will point at message+1. Display your own prompt, and drop all characters on the floor, until...
* INT16h is called, at which point the message has been displayed and DOS is waiting for the keypress.

That's only for DOS 2; I don't know if the idea would hold good in other DOS versions.
 
Last edited:
I'm looking at the MSDOS 6.0 source. File MSBIO2.ASM gives the answer.

Before a disk swap is requested, DOS issues an interrupt 2FH, AX=4A00H. You can hook that interrupt. If you set CX=-1 on return of your handler, it indicates that you've handled the issue and no message will be issued.

Ralf Brown's list confirms this for DOS 5 and above

Hope this helps.
 
Thanks guys! Great advice all around!

The way I have it working now is basically what I wrote in the original post; the B: drive is filtered out from the list of drives during drive enumeration if interrupt 11h says that this is a single floppy drive system (ie bits 7 and 6 in the equipment word are both zero). This is simple and would have worked great if it weren't for the fact that the user can start XTIDECFG with the "phantom" B: drive as the current floppy drive, then when loading a BIOS file, hit F2 and select drive A: from the list which would make DOS print "Insert a disk in drive A:..."

About all I can suggest is:
* Save a copy of the byte at 0:504
* Hook INT29h and INT16h
* In the INT29h handler, if the byte at 0:504 has changed from your copy, then DOS is printing the "Please insert the disk for" message. SI will point at message+1. Display your own prompt, and drop all characters on the floor, until...
* INT16h is called, at which point the message has been displayed and DOS is waiting for the keypress.

That's only for DOS 2; I don't know if the idea would hold good in other DOS versions.
So when I just now learned about the byte at 0:504h I thought "Great, I'll just check which drive is the current drive and then filter out the other drive." (it would look strange to have a drive B: but no drive A: in the list but I could learn to live with that). Except when I check this byte in a command prompt window under Windows 98 SE it's always zero regardless if the current floppy drive is A: or B:.

I'm looking at the MSDOS 6.0 source. File MSBIO2.ASM gives the answer.

Before a disk swap is requested, DOS issues an interrupt 2FH, AX=4A00H. You can hook that interrupt. If you set CX=-1 on return of your handler, it indicates that you've handled the issue and no message will be issued.

Ralf Brown's list confirms this for DOS 5 and above

Hope this helps.

This is exactly what I was looking for. The only problem is it needs DOS 5+ and I need something that will work from DOS 2. I suppose I could do what John suggested - hook interrupts 16h and 29h, then drop everything DOS tries to output via INT 29h. The problem will be to find out where the INT 16h calls comes from and preferably only "auto-respond" to this specific call from DOS since XTIDECFG itself issues calls to INT 16h. Aside from being a humongous hack, not a trivial thing to do. Also, I would need to hook interrupt 23h to ensure a clean exit (unhook the other interrupts) on ctrl-c/ctrl-break. Lots of coding to fix this annoyance.

Or I could just leave it as-is and call it a day! :D
 
Hmm curious, I've got to ask why would anyone start XTIDECFG from the phantom B drive in a single drive system and then load the Bios file from the A drive. :confused:
 
Hmm curious, I've got to ask why would anyone start XTIDECFG from the phantom B drive in a single drive system and then load the Bios file from the A drive. :confused:

I know it makes little sense but if it can be done then someone will do it. (This is just me trying to make XTIDECFG foolproof.) :) Also, XTIDECFG doesn't have to be started from the phantom B: drive, it could just as well be run from harddrive and the user decides to load a BIOS file from floppy drive A: (while the phantom B: drive for some reason is the current drive).
 
If it's DOS 2.x only, then you might consider plugging in your drive number before the swap is needed into 0:504h. I assume that there will be no files open for writing.
 
If it's DOS 2.x only, then you might consider plugging in your drive number before the swap is needed into 0:504h. I assume that there will be no files open for writing.

Just as an experiment I tried changing the byte at 0:504h using DEBUG under MS-DOS 6.22 and DOS stopped printing the "Insert disk..."-message altogether, even after changing it back to what it was originally, so it's clear that DOS keeps track of this byte somehow. This would be an easy way to fix the problem if it works in all DOS versions and I could be sure that it won't break anything...

Respectfully, I think this is over-engineering. That message is initially confusing to new users, but any user adding XT-IDE to their system probably has a modicum of smarts.

I agree, after all, adding XUB to a system is the smart thing to do... ;)

However, the problem isn't that the message is confusing (because it isn't really), it's that it breaks the user interface of XTIDECFG. Anyway, I've fixed it now. On DOS 5+ interrupt 2Fh/AX=4A00h is hooked (per Chuck's advice above) and on DOS versions prior to DOS 5 the "other" floppy drive is filtered out from the list during drive enumeration. Unfortunately, this doesn't fix the problem of Windows 98SE throwing up a bluescreen with the "Insert disk..."-message but I suppose there's no way around that.
 
Back
Top