Depends on what you mean by 32bit real mode, as real mode is 16bit per se
and partial 32bit functionality is only available through prefixes (only case i
remember is some demo that excessively uses 0x66/0x67).

I meant that they could be played basically on a 8086. If operand size prefixes would be used, then that would not be possible anymore, and one would have to create 32bit registers and operations etc.

I meant that they could be played basically on a 8086.

So what do you mean by "32bit real mode on an 8086" exactly?

Summarising:

Real mode: 16-bit only. Basically a compatibility mode for software written for the 8086 such as DOS. Has 16-bit cpu registers and a 20-bit address space and so can address 1MB of memory (on PCs, this was split into 640KB "conventional memory" + 384K ROM).

386 (32-bit) protected mode: Full access to the 32-bit address space, and also stuff like 32-bit registers and memory protection. Can't access DOS/BIOS functions directly from this mode.

286 protected mode: Not widely used. Allowed access to 16MB of RAM, but was difficult to switch back into real mode and like 386 protected mode, not possible to access DOS/BIOS functions from it.

XMS/EMS: Methods of accessing extended memory (memory after the first 1MB) from real mode either through mapping bits of extended memory into the real mode address space, or copying from extended memory. Needs XMS/EMS driver or hardware support. The drivers themselves may switch into protected mode and back to do this.

Unreal mode: This is the closest thing to a 32-bit real mode and is a bit of a hack which involves switching to protected mode and back in such a way that real mode can still access the full 32-bit address space. This is nice in a way because you can still use DOS/BIOS functions in this mode, unlike protected mode, but you do lose the memory protection and other features of protected mode. Some games used this instead of plain real mode or real mode with XMS/EMS until protected mode/DOS extenders caught on.

Why all these different ways of addressing memory? Blame Intel for trying to keep backwards compatibility with the 8086. 😀

Well, Intel tried to clean up the whole mess by introducing the Itanic (ahem, Itanium) which had little compatibility with x86 (the very original one had an x86 core, although it was dropped because of difficulty in operating system support on top of the fact that software emulation was faster than the hardware compatibility). And then AMD came out with the Athlon 64 which the workstation/desktop market preferred (Itanium still lives on in the server world) because of its x86 backwards compatibility (it's basically a 64-bit hack of x86 like the 80386 was a 32-bit hack of x86).

But yeah, that's a good summary of the situation... it also spreads some light onto how many headaches DOSBox has to code for, and how much of a miracle that it can even work 😀