I wonder when was the last real-mode commercial game released.

Jepael wrote:

superfury wrote:

I'm pretty sure it's a protected mode game:
http://www.cdaccess.com/html/shared/dott.htm

It does say the minimum is a 80286. Also, during UniPCemu's debugging, I see it using protected mode(CR0 bit 0=1). Since it's minimum is a 80286, it must be made for 16-bit protected mode(80286 doesn't support 32-bit protected mode).

I find it hard to believe it is a protected mode game, but I'll believe it when given enough proof.

Are you absolutely sure it was the game that sets it, or was it memory manager (himem handling extended memory or emm386 that has set up vm86) or BIOS (int15 extended mem functions)?

Don't know about BIOS. HIMEM.SYS is loaded, though. EMM386 so far refuses to install in UniPCemu(simply says it's not installed when ran, haven't checked as driver(config.sys) since fixing protected mode errors yet(Compaq Deskpro 386). Everything AT and up using XT-IDE BIOS in AT mode giving up on hard disk boot(and fails at floppy boot too, oddly enough) due to unknown error(simply executes ATA-1 IDENTIFY command, retrieves result using REP INSW and says not detected for some unknown reason).

Edit: EMM386.EXE loaded in CONFIG.SYS after LTEMM.EXE and HIMEM.SYS seems to run, but give imcorrect results(55MB memory when actually only 4MB is installed on the Compaq Deskpro emulation? That cannot be correct.). LTEMM.EXE is for the XT EMM board, but it aborts(only usable on XT emulation). They wouldn't be biting each other, would they? Executing mem.exe crashes into reboot(triple fault?).

If EMM386 is loaded then the processor is in protected mode, and DOS is running in VM86.

That is correct (though EMM386 by design doesn't give any memory protection), and the explanation I figured for his observation. The game indeed, even shown by the source he linked to, uses expanded memory (EMS) which makes no sense in protected mode. It could not use XMS (indicating design for 386+ only) but according to one source would run on a 286 in conventional memory only (as Wolfenstein 3D could).

As to your question about the last real mode game, that would be interesting to nail down. I know there were many in 1994, but haven't found any later than that year. The switch from real-mode to 32-bit protected mode for DOS games seems to have been rapid, contained entirely (or nearly) within the years 1992 to 1994. Windows 3.x games seem to have adopted 32-bit features a bit more slowly, and it's quite possible the last game to run on a 286 was a Windows, not a DOS, game. (But remember that for either 32-bit instructions could be used at will, forcing a 386+.)

That's excluding educational 'games' which would probably make it a slam-dunk; those purely benefit from low system requirements while (unfortunately) conventional games actually sell partly based on their high system requirements, at least since Quake and probably before, because of course the average 'gamer' needs to boast of running the latest piece of crap at 80 bazillion FPS ...

koverhbarc wrote:

[..]uses expanded memory (EMS) which makes no sense in protected mode.[..]

Lollypop requires EMS*, too, despite beeing a "32bit" game.
(*checked with a real AST Rampage on a 386-PC)

What happens when, on a 80386+, the I/O privilege table needs to be checked(IOPL>CPL) in protected or virtual 8086 mode, while no task register is loaded(NULL task register; uninitialized or through LOADALL)? That seems to be the case here: TR is 0x0000(uninitialized or through LOADALL) during this particular case(protected mode should except or never thow an exception in that case?).

Also, I don't even see the software and BIOS (Compaq Deskpro 386 emulation with XT-IDE XT BIOS(AT BIOS doesn't recognise the harddisks, for some unknown reason) execute a LTR(Load task register) instruction, thus no active task.

Jo22 wrote:

Lollypop requires EMS*, too, despite beeing a "32bit" game.
(*checked with a real AST Rampage on a 386-PC)

I just mentioned the possibility of a real mode game requiring a 386, and this may be an example (as may also be AITD 2 and 3 from the other thread that happens to be active right now). I assume you understand why EMS makes no sense from protected mode. '32-bit' was a vogue marketing term at this time and so I'm not surprised by it.

koverhbarc wrote:

Jo22 wrote:

Lollypop requires EMS*, too, despite beeing a "32bit" game.
(*checked with a real AST Rampage on a 386-PC)

I just mentioned the possibility of a real mode game requiring a 386, and this may be an example (as may also be AITD 2 and 3 from the other thread that happens to be active right now). I assume you understand why EMS makes no sense from protected mode. '32-bit' was a vogue marketing term at this time and so I'm not surprised by it.

Sorry, I didn't meant to criticize you. What I said was just an observation I made a few years ago when I got my EMS board.
I can imagine one reason as to why they did use EMS: Unlikey XMS, EMS memory is not constantly beeing copied.
It is bank-switched, which may results in an impoved perfomance under certain circumstances
(for examples, if all graphics data was uploaded to the EMS board during the game's start-up).
So perhaps Lollypop uses EMS, because is does a lot of screen scrolling and EMS supports DMA or something along these lines.

You're probably right as to why EMS would be chosen over XMS - but neither bank-switching nor copying is necessary from protected mode, even pure 16-bit, that was my point. Any game designed to run well on a 286 would have to support XMS as much as EMS, because memory managers could not be run.

Well, I was wrong. I thought this was the problem that applied to Build engine games, but rather it's that Build's SVGA support appears not compatible with NTVDM (and of course univbe can't be used here) - it gets my video card set to timings my monitor physically can't sync to! They will work at 320x200.

Of course DOSBox does work (seemingly), but 640x480 is a bit slow and 320x200 is out of the question being the wrong aspect ratio.

A long time ago I remember us doing comparisons between different videos cards in NTVDM and VESA as well as modifying vga.sys. Holy crap 14 years!

Here's some info:

patch for WinXP/2000 monitor issues
Interesting VESA info from a user
Re: let's compare our PCI-E cards in terms of DOS modes and compatibility
Re: Possible fix for : Some Nvidia cards can't make dos graphics with NTVDM

http://www.rayer.g6.cz/download/videoprt.zip
https://web.archive.org/web/20070817233552/ht … z/martin.sulak/
http://www.nomissoft.com/newsflash.html

I want to say this is around the time protected mode became supported in DOSBox so there wasn't much interest here in having to deal with yet another hack to get games running in NTVDM.

koverhbarc wrote:

but rather it's that Build's SVGA support appears not compatible with NTVDM (and of course univbe can't be used here)

I'm not sure if you know this already, but I recall Ken Silverman would recommend NOLFB (or NOLFBLIM) precisely to work around such problems. (It disables VESA 2.0 support, which is lacking in NTVDM, and forces the games to drop down to VESA 1.2.)

As shown here : http://www.mobygames.com/game/maniac-mansion- … CoverId,348475/ the game requires a 286 and supports (disk) or requires (CD-ROM) EMS Expanded Memory. If it is using Protected Mode, it isn't using its main feature of allowing direct access to more memory.

Yes, I think we've agreed that is a real-mode game - one of the many late real-mode games that required a 286 or 386 processor (Note that quoted system requirements are nowadays not necessarily the minimum to run the game at all, but in these cases they probably were).

DosFreak, Jorpho: Thank you for the prompt reply to my new subject. I had just read about others running Build games on XP and re-investigated it. I hadn't heard about those old issues. I got nolfblim, which works, and videoprt, which gives me all the VESA modes I get under DOS (The other utility doesn't recognise my vga.sys, but I don't think it could do any better.) I can't see how either could do any harm, anyway.

I can see that both of those are really defects in Microsoft's implementation. Even the LFB should be supported, because it can be mapped to any virtual address; a program could not hardcode it to a particular address, and further, DPMI-compliant programs should use it as a separate segment, which can of course have any base address. Still NTVDM isn't necessarily worse than the 'DOS boxes' under earlier versions of Windows, and at least gives us sound emulation capability, which is mostly why we want to use it in the first place.

Does the Day of The Tentacle run on a 8086 or 80186 CPU? If it doesn't, it needs a 80286 to work(since it won't run 80286+ instructions on those CPUs). The 80286 only adds new instructions for entering and managing protected mode, so if it doesn't use Protected Mode, it should run on a 8086 or 80186(NEC V20/V30) CPU. Using UniPCemu's NEC V30 emulation(actually 80186) with EMS memory should work if it doesn't use protected mode(the only non-0F opcode added on a 80286 is an instruction that only works in protected mode, after all).

Edit: Just tried it on UniPCemu's 80186 with the current commit and bugfixes:

Although, this could also be a bug in the CPU. Does this happen on a real PC XT as well?

superfury wrote:

Does the Day of The Tentacle run on a 8086 or 80186 CPU? If it doesn't, it needs a 80286 to work(since it won't run 80286+ instructions on those CPUs). The 80286 only adds new instructions for entering and managing protected mode, so if it doesn't use Protected Mode, it should run on a 8086 or 80186(NEC V20/V30) CPU. Using UniPCemu's NEC V30 emulation(actually 80186) with EMS memory should work if it doesn't use protected mode(the only non-0F opcode added on a 80286 is an instruction that only works in protected mode, after all).

At least it does not work on a 8086/8088, as it uses for example SHL register by 3.

I bet they put the 286 CPU as requirement, as for normal people, they were called 286 instructions.
So, it might work on CPUs implementing the 80186 instruction set such as V20/V30 as well, but people having those CPUs would be marginal, and it would not run it that well.

Game requirements also said the CD-ROM version requires a 386, but in reality it looks like it works on a 286 as well, so these might be suggestions for adequate performance, not hard requirements. I mean, they suggest 2MB of EMS as well, but it also appears to work without EMS.

Thinking about it, the 80386 might only be needed for the CD-ROM interface? Otherwise, a 80286/80186(NEC V20/30) should work as well.

Well, I know UniPCemu still has little CPU bugs, but I can't seem to find them(other than a few 80186(EPC) testsuites failing the MUL and two other tests, for some unknown reason(mostly flag errors). The 'Unknown flag: uFriSat' on the screen is odd as well. Some weekday error? Or CPU emulation messing up royally.

Icelordetherea wrote on 2017-06-09, 07:21:

I always ALWAYS had to keep a cwsdpmi* or something like that in the same folder as several DOS exe files just to be able to run those properly, because else it would straight up refuse, like DBOY emulator.

It should be enough if your PATH variable points to a folder containing cwsdpmi.exe
Therefore, cwspdmi.exe does not need to be included in every folder, which has a DOS exe that requires cwsdpmi.exe

The easiest quick and dirty way should be to simply copy cwsdpmi.exe into your DOS directory.
A more elegant way, without messing up your DOS directory, would be to create a new directory for your own binaries, then put it there, and then add it to your PATH variable.
I recommend the latter.

So something like this in your AUTOEXEC.BAT

1PATH=C:\DOS;C:\MYTOOLS