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 still is an error in the emulation

The dosbox implementation is correct for the old bioses (cga/tandy etc.),
but it could be changed for machine=vga some time.

> 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.

wd wrote:

> but it still is an error in the emulation

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.

JAL

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.

Windows has the same fallback code, but it works fine there.
Will try to see what they're doing if i got some time.

Code in win9x looks like
mov ax,0xe801
xor bx,bx
stc
int 15
if (carry_set or bx==0) try next strategy

This works fine with the old bioses as well as with dosbox.

thanks for clarifying.

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.

do you know any game which gets the memory size incorrectly because of this ?

No.

> have found out that it is a good test environment for a (self-written) dpmi host.

HX? Are you using e801/e820 there as well in this manner?

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).

HX Dos works nicely in DOSBOX. Its author has implemented workarounds for the above mentioned DOSBOX problems.

There is a thread about HX DOS and DOSBOX in Milliways:
Bored? Try running Qemu inside of DosBox using HX Dos Extender and HXGui

Mirek

Still the cf/ah values should flag failure for the default case,
might be done some time...

japheth,

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. 😉 )