currently dosbox sets ah=86h if int 15h is called with an unimplemented number in ah/ax. Some calls, among them is ax=E801, should return with carry flag set instead. Couldn't this be added in dosbox, at least for ax=e801h (get extended memory for > 64 MB configs)
Where do you need this?
Carry flag clear says that this function is known, and the
ah=0x86 says the function is not supported, so this shouldn't
cause problems.
> and the ah=0x86 says the function is not supported
ah=86h indicating an error is valid for some int 15h, ah=8x functions (and interestingly int 15h, ax=e820h), but not for ax=e801h, which just has the carry flag to indicate an error.
> Where do you need this?
It's just for some self-written debug tools, so no big deal, I can easily add a work-around for dosbox, but it still is an error in the emulation.
> but it could be changed for machine=vga some time
good to hear. I just want to make the dosbox maintainers aware. I'm experienced enough to make small changes to the dosbox source myself. I don't use dosbox for games much but recently have found out that it is a good test environment for a (self-written) dpmi host.
The dosbox implementation is correct for the old bioses (cga/tandy etc.),
but it could be changed for machine=vga some time.
Int 15h is not in the XT/Tandy BIOS, except for turning the cassette motor on/off. These are XMS calls, so your argument isn't valid. That said, the original poster should I think use E820h instead of E801h, since this is what Ralph Brown has to say about it:
1Phoenix BIOS v4.0 - GET MEMORY SIZE FOR >64M CONFIGURATIONS 2AX = E801h 3Return:CF clear if successful 4AX = extended memory between 1M and 16M, in K (max 3C00h = 15MB) 5BX = extended memory above 16M, in 64K blocks 6CX = configured memory 1M to 16M, in K 7DX = configured memory above 16M, in 64K blocks 8CF set on error 9 10Notes: Supported by the A03 level (6/14/94) and later XPS P90 BIOSes, as well as the Compaq Contura, 3/8/93 DESKPRO/i, and 7/26/93 LTE Lite 386 ROM BIOS. Supported by AMI BIOSes dated 8/23/94 or later. On some systems, the BIOS returns AX=BX=0000h; in this case, use CX and DX instead of AX and BX. This interface is used by Windows NT 3.1, OS/2 v2.11/2.20, and is used as a fall-back by newer versions if AX=E820h is not supported. This function is not used by MS-DOS 6.0 HIMEM.SYS when an EISA machine (for example with parameter /EISA) (see also MEM F000h:FFD9h), or no Compaq machine was detected, or parameter /NOABOVE16 was given.
So yes, DOSbox is wrong in not setting the carry and setting AH to 86h for this call, but it's a depricated BIOS call anyways. RB says this about E820h:
1Newer BIOSes - GET SYSTEM MEMORY MAP 2AX = E820h 3EAX = 0000E820h 4EDX = 534D4150h ('SMAP') 5EBX = continuation value or 00000000h to start at beginning of map 6ECX = size of buffer for result, in bytes (should be >= 20 bytes) 7ES:DI -> buffer for result (see #00581) 8Return:CF clear if successful 9EAX = 534D4150h ('SMAP') 10ES:DI buffer filled 11EBX = next offset from which to copy or 00000000h if all done 12ECX = actual length returned in bytes 13CF set on error 14AH = error code (86h) (see #00496 at INT 15/AH=80h) 15 16Notes: Originally introduced with the Phoenix BIOS v4.0, this function is now supported by most newer BIOSes, since various versions of Windows call it to find out about the system memory. A maximum of 20 bytes will be transferred at one time, even if ECX is higher; some BIOSes (e.g. Award Modular BIOS v4.50PG) ignore the value of ECX on entry, and always copy 20 bytes. Some BIOSes expect the high word of EAX to be clear on entry, i.e. EAX=0000E820h. If this function is not supported, an application should fall back to AX=E802h, AX=E801h, and then AH=88h. The BIOS is permitted to return a nonzero continuation value in EBX and indicate that the end of the list has already been reached by returning with CF set on the next iteration. This function will return base memory and ISA/PCI memory contiguous with base memory as normal memory ranges; it will indicate chipset-defined address holes which are not in use and motherboard memory-mapped devices, and all occurrences of the system BIOS as reserved; standard PC address ranges will not be reported
So E820h should also set the carry to indicate error.
the problem with e820 is that it is not implemented on older bioses (first half of 1990). Of course one can implement a fallback strategy (e820 -> e801 -> 8800 but this requires at least that the bioses return the expected error codes/carry flags.
the strategy is not perfect, however. Many bioses return the values in CX+DX instead of AX+BX (ax and bx are 0 then). And the Carry flag often is untouched, although the function was successful.
so it would be better if dosbox actively sets the carry flag as well.
no, the e820 code is deactivated in the dpmi host. That's because when the HX host's int 15 memory interface was developed - or better, when it was extended to support more than 64 MB, I found the E801 being implemented more reliable.
And yes, I started this thread because the host didn't run in int 15 mode first in dosbox, but I changed this in the meantime. Now it runs perfectly (btw, it also works the other way, that is, dosbox running on hx's win32 emulation, but this is not stable yet, and it is just for fun)
Last time i tried hx in dosbox in raw mode it didn't work because it
called some ints that pointed to 0:0 (debugger/net), and because
one of the int15 functions didn't set the CF. The latter will/should be
changed, but not too soon as it deserves some testing.
yes, the hx dpmi host called int 68h in real-mode without testing if it is 0:0. To my knowledge the vectors 68h - 77h should always have been set in a real machine (to at least an IRET), but may be I'm wrong. Anyway, I implemented a check .(int 68h is used for a real-mode interface to wdeb386, the MS kernel debugger).
A lot of those bios interrupts point to irets, including int68+, but they are
set to 0:0 as long as no game makes use of it, so it can be tracked if
it needs an implementation of the int handler (which might be as simple
as pointing it to an iret, but can be much more as well).
If you are the author of HX then that is an amazing piece of work. Not sure if the HXGUI is going to be used by anyone for any real-world purposes but the ability to run console win32 utilities in MS-DOS is very nice.
(heh. I guess now people are going to complain that if MS-DOS can run Windows apps via "emulation" that no on will write pure MS-DOS utilities anymore just like the Wine vs Linux debates...oh wait DOS is dead so I guess not. 😉 )