so i would like to look after this issue, but i need a starting point, where is the Dos Interrupt handling stuff, i couldn't find anything yet 😖

i added some code for debugging. I was wondering why it isn't possible to set AH for example. So i added that stuff. imho it's quiet usefull. 😀

Well, I've noticed that Under A Killing Moon reports all mounted drives as network drives. Does not prevent it from working though but could be the same issue.

f8f8 would indicate a mounted C and D drive ? I assume you talk about
the DS:BX pointer.

(as dosbox points to the table where these are stored.... maybe they need to be copied to a location and then point to it. Dunno.)
They are stored for all drives in onetable.

yeah true DS:BX sorry!
if i mount my cdrom to E:\ it works to! 🤣
after int21:1C there is 02 in BL
then he mov BX, [BX]
then he got F8F8 (with C:\, D:\) and 00F8 (with C:\ E:\)
if there is a floppy in D:\ -> F0F8

so i think your are right. Increasing the media to 16bit ?

edit: i think i have the sucker

Boot Sector (since DOS 2.0) […]
Show full quote

Boot Sector (since DOS 2.0)

Offset Size Description
...
13 word number of total sectors (0 if partition > 32Mb)
15 byte media descriptor byte

the silly question is this cmp a bug or a feature 😉
so the game is only installable on partitions bigger then 32MB.
But the game only need 8MB 😵

hmm. I don't know.
I'm not sure if that is the actual byte used by that call. (as that isn't the bootsector the call inquiries about.)

I think wd knows it, as the location of the dos tables was determined by him to get windows runinng.

I think the returned id-byte is part of the dpb (which
is not present in dosbox, just the byte itself) so
the assumption that the id-byte is followed by a zero
might be correct, it's something like "drive accessed".

sounds familiar. Isn't that the byte people can use to see if the floppy got changed as well ? as the dpb needs to reread from disk in that case.

we talk about this:
http://www.clipx.net/ng/dos5/ng38fd8.htm

right ?

dpbMedia db ? ; Media descriptor
dpbFirstAccess db ? ; 0FFh = medium in drive not accessed

yeps those 2
The first is your number.
the second can be 0. (better said if FF then medium not accessed. Some way to detect a diskchange)

what make no sense for disks... at least for ide disks 😲

for fixed disks it does indeed make little sense, however for floppies... (I might be confused with a different Call, but I remember having read somethink like this once.)

I don't think it serves too well to detect floppy changes,
as it (should?) report disk/floppy access only, not the
changes.
But either way, reserving words for the id-byte with the
high part set to zero might work well.

now a stupid question, wouldn't it be better to implement the hole dpb thing? because i think there are some other calls point to it ?

we only implement stuff if it's actually used.

ok here a fix for it...

I don't think that will always go allright. As you essentially change what's on ds:bx.