DOSBox doesn't do any segment limit checks so I don't see why it would need the mode switching in the first place.

Im going to go out on a limb here and suggest that what you are asking is beyond the scope of what DOSBox was developed for, as cool as it sounds I dont remember any DOS game requiring such a mode to function. DOSBox only has the functions it requires to run DOS based games, perhaps DOSBox-X would be better suited to such a mode if it was to be supported.

I do agree it sounds like something that would certainly make memory handling easier but there may be technical reasons it never actually caught on.

https://en.wikipedia.org/wiki/Unreal_mode

You can read in that article that Ultima 7 uses it, and that game works in DOSBox. So, yes, unreal mode is supported.

However, if you refer to "huge real mode", that is not supported.

ripsaw8080 wrote on 2022-10-09, 13:04:

https://en.wikipedia.org/wiki/Unreal_mode

You can read in that article that Ultima 7 uses it, and that game works in DOSBox. So, yes, unreal mode is supported.

However, if you refer to "huge real mode", that is not supported.

I thought you were joking about Huge Real Mode ....nope it actually is a real mode. Pun intended.

unreal mode is supported. many demos used it. it does have caveats with (this is going back a long time so my memory is out) calling interrupts, sometimes interrupts could reset you out of unreal mode. but you also couldnt use xms/ems etc or any other driver loaded. its a real pain actually.

BloodyCactus wrote on 2022-10-09, 13:45:

unreal mode is supported. many demos used it. it does have caveats with (this is going back a long time so my memory is out) calling interrupts, sometimes interrupts could reset you out of unreal mode. but you also couldnt use xms/ems etc or any other driver loaded. its a real pain actually.

Reading that wiki it seems the OP might be referring to Huge Real Mode since OP mentions 4GB of memory. (If I am understanding that wiki correctly)

videogamer555 wrote on 2022-10-09, 12:31:

Every time I try to use a 32-bit memory accessing instruction, it says "illegal opcode", because it thinks I'm trying to use a 32-bit memory access instruction in 16-bit real mode. It doesn't seem to realize that I've switched to what's basically 32-bit real mode.

You are still in a 16-bit mode, so to use a 32-bit address in an instruction you need to use the address size override prefix 67h, the same way you need 66h to use 32-bit registers in 16-bit mode.

Azarien wrote on 2022-10-09, 19:39:

videogamer555 wrote on 2022-10-09, 12:31:

Every time I try to use a 32-bit memory accessing instruction, it says "illegal opcode", because it thinks I'm trying to use a 32-bit memory access instruction in 16-bit real mode. It doesn't seem to realize that I've switched to what's basically 32-bit real mode.

You are still in a 16-bit mode, so to use a 32-bit address in an instruction you need to use the address size override prefix 67h, the same way you need 66h to use 32-bit registers in 16-bit mode.

Thanks for that info. When using NASM, it usually generates the required overrides. So for example I thought that the instruction "MOV [EAX],DL" (the use of [EAX] implying that a 32bit address is desired, because [EAX] means the memory address pointed to by the 32bit EAX register) would automatically cause NASM to set the required overrides. And since in this case the memory address is in fact the register value, I don't think a separate 67h override is needed, just the 66h override for the 32bit register. Though I could be mistaken. It may also need the 67h override. Can you clarify this?

Actually upon viewing the program I wrote in the DosBox debugger, it seems to in fact have the correct 67h override. But DosBox debugger is still saying that it's an illegal instruction. Here's text line copied directly from the debugger showing this instruction.

10000:017E  678807              mov  [edi],al               [illegal]

Can you explain why this might be happening? I've followed all the steps I was supposed to need to use, to make unreal mode work.
Maybe this would be recognized correctly by real hardware, but since DosBox doesn't explicitly recognize unreal mode, it thinks the instruction is invalid (though it executes the instruction correctly anyway).

The [illegal] indicates that the address is illegal, not that the instruction is illegal. In some situations, the debugger erroneously indicates an illegal address -- you can just ignore it. An address initially indicated as illegal may actually show as legal after the instruction is executed (stepped over).

videogamer555 wrote on 2022-10-09, 20:13:

since DosBox doesn't explicitly recognize unreal mode, it thinks the instruction is invalid (though it executes the instruction correctly anyway).

I don't know about DOSBox internals but you don't need any special mode to execute `mov [edi],al`. As long as edi is not too big (that is, edi == di), this is a valid instruction (on a 386+) in real mode.

Azarien wrote on 2022-10-10, 16:39:

videogamer555 wrote on 2022-10-09, 20:13:

since DosBox doesn't explicitly recognize unreal mode, it thinks the instruction is invalid (though it executes the instruction correctly anyway).

I don't know about DOSBox internals but you don't need any special mode to execute `mov [edi],al`. As long as edi is not too big (that is, edi == di), this is a valid instruction (on a 386+) in real mode.

Well the in the unreal mode "mov [edi],al" should work even when EDI > 0xFFFF. But when I try that with DOSBox Debugger, it seems to not recognize it's running in unreal mode, and calls it an illegal instruction (though for some reason it still executes it, and it behaves as expected). This leaves me wondering if there's something wrong with DOSBox here, or if my code is wrong in some way. The only way to clear that up might be to try to run it on real hardware.

Ok, so I tried it again on the latest version of Dosbox Debuger (which is posted at the top of this thread DOSBox debugger) and it doesn't seem to consider it to be an illegal instruction.

Note that himem.sys needs "unreal" mode to work, and dosbox can boot it just fine.
In fact, if I remember from some discussions on these forums, when using himem.sys dos itself spends most of the time running in unreal mode, with all descriptors having 4GB limit, since neither himem.sys nor the processor itself ever bothered to restore them to 64k...

videogamer555 wrote on 2022-10-18, 08:10:

This leaves me wondering if there's something wrong with DOSBox here, or if my code is wrong in some way. The only way to clear that up might be to try to run it on real hardware.

you have to remember, dosbox cheats, its not an cycle exact hardware emulator. it cuts corners for speed over accuracy. some of the gory cpu details are ignored for speed.