VOGONS


First post, by videogamer555

User metadata
Rank Member
Rank
Member

I was reading about how to get 32-bit memory access in real-mode, and discovered there's a hidden mode called "unreal" mode, that's not actually an official mode. It works like this. You set up the global descriptor, load the GDT, switch to protected mode, set the data segment register so that it uses the GDT, then switch back out of protected mode, and make sure you don't do anything to set the data segment register again. It then retains its use of the 32-bit data segment, letting you access 4GB of memory without needing to keep setting the data segment register to reference the specific 64kB block of memory that you want at a given time.

However I'm not sure if this mode is supported by DosBox. At least the debugger version of DosBox seems to not support it. 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.

Can anybody tell me here tell me if officially DosBox is supposed to support this mode? I'd like to know, because I have a number of ideas of games or apps I could develop using this mode. It would make memory access a LOT easier.

Reply 2 of 14, by TrashPanda

User metadata
Rank l33t
Rank
l33t

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.

Oh noes, the cap let the shmooo out 😁

Reply 3 of 14, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 4 of 14, by TrashPanda

User metadata
Rank l33t
Rank
l33t
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.

Oh noes, the cap let the shmooo out 😁

Reply 5 of 14, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

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.

--/\-[ Stu : Bloody Cactus :: http://kråketær.com :: http://mega-tokyo.com ]-/\--

Reply 6 of 14, by TrashPanda

User metadata
Rank l33t
Rank
l33t
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)

Oh noes, the cap let the shmooo out 😁

Reply 7 of 14, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 8 of 14, by videogamer555

User metadata
Rank Member
Rank
Member
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.

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

Reply 9 of 14, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Reply 10 of 14, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 11 of 14, by videogamer555

User metadata
Rank Member
Rank
Member
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.

Reply 12 of 14, by videogamer555

User metadata
Rank Member
Rank
Member

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.

Reply 13 of 14, by javispedro1

User metadata
Rank Newbie
Rank
Newbie

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

Reply 14 of 14, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie
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.

--/\-[ Stu : Bloody Cactus :: http://kråketær.com :: http://mega-tokyo.com ]-/\--