Privateer's EMM manager is notorious.

Ultima Underworld, too.

Just took a Ultima Underworld disk image(which is apparently not 2048 bytes/sector) and converted it to an ISO file with WinImage. Then mounting it in UniPCemu and running uw.bat seems to do nothing(hang)?

Edit: No hang, just unresponsive non-inserted second CD-ROM drive? The MSCDEX driver says that drive E isn't ready? I responded with f(ail).

I only have one IDE hard disk on the primary master and two CD-ROM drives on the secondary master/slave(the secondary master containing the disk image, the secondary slave having no disk inserted).
Edit: Now trying again with only the second drive having a disk in it, with the first drive not inserted.
Edit: MSCDEX or the VIDECDD.SYS driver doesn't seem to like it(at least slowly starting up when loading MSCDEX, after displaying the disk drives that are found and their mounted volume endpoints).

Edit: Changing the Underworld disk to the second drive(inserting a dummy disk to the secondary master CD-ROM drive), I managed to fire up uw.bat correctly. It won't hang/have CD-ROM conflicts anymore(The three-option Abort, Retry, Ignore showing up for the first/second CD-ROM drive not being ready) that way. Now I still need to enable the MS-DOS EMS driver(for 80386+). It seems that Ultima Underworld doesn't run in protected mode but uses EMS instead? Or does it apply some weird mixture of both?

Does Ultima Underworld even use plain protected mode(other than what EMM386 uses)? Or is it just a MS-DOS mode program with EMS that happens to be implemented using protected mode?

Edit: I do see paging is enabled and something(which doesn't seem like EMM386, since it only uses segment selector 0x28 afaik) is running in protected mode. So is that Ultima Underworld itself?

Edit: It seems to run without problems, at least up until the main menu(where I found out I didn't load any mouse drivers). Then couldn't figure out how to quit the game(Ctrl+Q, Q etc. did nothing).

It seems to run quite well, with a mouse at least:

So as you can see, it seems to run fine!
Edit: Speed is still an issue, though(only ~20% realtime speed atm).

Edit: So that means there's no problem with basic protected-mode operation?

Just reinstalled Simcity 2000 Special Edition (for MS-DOS, although Windows 3.1 and 95 is also supported). It seems to try to run WillTV when starting up(after loading the univbe.exe before starting it), but then fail with a black screen, return to text mode and start loading the full game normally. Then when closing Simcity 2000, it tells me that it cannot find COMMAND.COM? Then the machine becomes unreponsive, only a hard reboot fixing things?

Edit: Interestingly, loading WillTV from Simcity 2000's main menu or quitting the application back to MS-DOS 6.22 gives a Cannot load COMMAND.COM message(system halted)?

Now giving WFW 3.11 a go. Since Windows 95 is running(until crashing with a BSOD) somewhat with paging and 3.1 is running correctly(except 3.1 386-mode and 3.0 with any protected mode), looking as 3.1 runs in protected mode while 3.0 fails in it, maybe 3.11 will run in 386 mode?

Edit: Interesting note on the hand of the WFW 3.11 setup(maybe Windows 3.X in general): pressing Alt-Gr(which UniPCemu uses for it's special keyboard&mouse (un)mounting) will cause the current window to have it's [-] box in the top-left of the window to be selected. And while said box is selected(or anything inside it's menu) will pause said program(even the file copy process of the setup. And there I was wondering why it took so long to copy one small dll file... 😖

Jazz Jackrabbit - it often crashes real machines with HIMEM + EMM386 NOEMS; i.e. it is somewhat particular about how you set up your memory management.

I’d also be interested to know how my game engine prototype runs on it, as it is also very touchy about memory management and I have not ironed out all the problems yet. I can send you a link if you want.

@keenmaster486: Yes please. Such a test would come in handy.

Just tried setting up Windows 3.11 on UniPCemu. I see two faults when it's booting. The first is the 80486+ CMPXCHG. But since it's a 80386DX, it throws an #UD.

Then I see some BT instruction at 0028:80002A83 instruction 0FBA2210 throwing a #PF(0) for offset 80401002. The PTE is 0. The PDE is 334227.

The previous instruction was some conditional jump.

Just tried running Jazz Jackrabbit with only himem. It finally runs! 😁

Although entering a safe filename when saving from there seems to have unresponsive input? Sound and visuals are still running, though.

crazyc wrote:

Privateer's EMM manager is notorious.

Do you mean Wing Commander: Privateer or Privateer 2: The darkening?

Here's the latest version of my game engine prototype. It's written in FreeBasic. It's a development version so it pauses at each step of the initialization process when you load it - just press enter to go to the next step. That way if something screws it up you know what it was.

It runs fine in DOSBox so you can test it there. Needs something like 8 megs of memory, might work with 4.

It will complain about there being no DPMI server. Load HDPMI32.EXE from the main folder, or you can try CWSDPMI. I'm experimenting with different DPMI servers but none of them give any differing results in PCem.

Based on my testing (in PCem and real hardware), there are two main problems:

1. On non-MMX Pentiums, the engine always crashes with an "Invalid Opcode".
2. Without an FPU, the engine does not work, even though I am compiling it with an FPU emulator. So for example it shouldn't work on a 486SX but you should try it anyway.
3. On a 386 (SX or DX) the engine will crash with a general protection fault.

None of these errors I have been able to fix. The engine seems to play well with 486DX, Pentium MMX (sometimes), Pentium II/III, etc., and DOSBox (no matter what CPU emulation you select).

It needs probably at least a 486DX/33 or 50 to run at full speed. It will be happier on a DX2/66.

Just tried Privateer. It gives me an error code "D002-FFFF"?

Edit: I did ran install, configuring both audio settings for SB, IRQ5, DMA1(as is used in UniPCemu).

I do see a #TS fault starting it, on an IRET from task 0xF0 to task 0x10?
Edit: Said fault is because, after loading CS(not loaded SS yet), TR's DPL isn't equal to CPL?

Edit: Said bug was a requirement for CPL==TSS.DPL, instead of CS.RPL==CS.DPL. And then it was even applying it to V86 mode(which it shouldn't, as it doesn't have CS.RPL).

Edit: Filtering out faults from V86 mode, I see no faults. But said crash still occurs. So there's a problem in V86 mode somehow?
Edit: The same with non-#GP faults from V86 mode. Hmmm...
Edit: All I see is #GP faults pointing to interrupt vectors(I bit in the error code being set)?
Edit: And #GP(0) errors.

Superfury, FreeBasic just released a new version. Compiling my engine with the new version seems to fix operation on plain Pentiums. Here it is:

https://drive.google.com/file/d/18sQYoeO2zA1d … iew?usp=sharing

One problem: My emulator only fully emulates up to a 80486SX(without FPU). The only thing added so far with the "Pentium(unfinished)" CPU is 4MB page support(this was to try running Minix 3). If it relies on an FPU it won't work(without software emulation of it). One of the reasons Linux 2.0.XX won't boot(Debian fully crashes, Purely compiled kernel using gcc on Windows resulting in a message it needs a FPU to boot). Although I've added software FPU emulation when compiling it(and it's supported as documented)?

1//FPU non-existant Coprocessor support!
2
3void FPU80287_OPDBE3(){debugger_setcommand("<UNKOP8087: FNINIT>");}
4void FPU80287_OPDFE0() { debugger_setcommand("<UNKOP80287: FSTSW AX>"); }
5void FPU80287_OPDDslash7() { debugger_setcommand("<UNKOP80287: FNSTSW>"); }
6void FPU80287_OPD9slash7() { debugger_setcommand("<UNKOP80287: FNSTCW>"); }
7
8void FPU80287_OP9B() {modrm_generateInstructionTEXT("FWAIT",0,0,PARAM_NONE); if (CPU[activeCPU].registers->CR0&CR0_TS) { FPU80287_noCOOP(); return; } /*if (CPU[activeCPU].registers->CR0&0x20) { THROWDESCMF(); return; / #MF Fault! / } */ /*9B: WAIT : wait for TEST pin activity. (Edit: continue on interrupts or 8087+!!!)*/ }
9void FPU80287_OPDB(){if (CPU[activeCPU].registers->CR0&CR0_EM) { FPU80287_noCOOP(); return; /* Emulate! */ } if ((CPU[activeCPU].registers->CR0&CR0_MP) && (CPU[activeCPU].registers->CR0&CR0_TS)) { FPU80287_noCOOP(); return; } CPUPROT1 byte subOP = params.modrm; if (subOP==0xE3){FPU80287_OPDBE3();} else{FPU80287_noCOOP();} CPUPROT2 }
10void FPU80287_OPDF(){if (CPU[activeCPU].registers->CR0&CR0_EM) { FPU80287_noCOOP(); return; /* Emulate! */ } if ((CPU[activeCPU].registers->CR0&CR0_MP) && (CPU[activeCPU].registers->CR0&CR0_TS)) { FPU80287_noCOOP(); return; } CPUPROT1 byte subOP = params.modrm; if (subOP==0xE0){FPU80287_OPDFE0();} else {FPU80287_noCOOP();} CPUPROT2 }
11void FPU80287_OPDD(){if (CPU[activeCPU].registers->CR0&CR0_EM) { FPU80287_noCOOP(); return; /* Emulate! */ } if ((CPU[activeCPU].registers->CR0&CR0_MP) && (CPU[activeCPU].registers->CR0&CR0_TS)) { FPU80287_noCOOP(); return; } CPUPROT1 if (thereg==7){FPU80287_OPDDslash7();}else {FPU80287_noCOOP();} CPUPROT2 }
12void FPU80287_OPD9(){if (CPU[activeCPU].registers->CR0&CR0_EM) { FPU80287_noCOOP(); return; /* Emulate! */ } if ((CPU[activeCPU].registers->CR0&CR0_MP) && (CPU[activeCPU].registers->CR0&CR0_TS)) { FPU80287_noCOOP(); return; } CPUPROT1 if (thereg==7){FPU80287_OPD9slash7();} else {FPU80287_noCOOP();} CPUPROT2 }
13
14void FPU80287_noCOOP() {
15	debugger_setcommand("<No COprocessor OPcodes implemented!>");
16	if ((CPU[activeCPU].registers->CR0&CR0_EM) || ((CPU[activeCPU].registers->CR0&CR0_MP) && (CPU[activeCPU].registers->CR0&CR0_TS))) //To be emulated or task switched?
17	{
18		CPU_resetOP();
19		THROWDESCNM(); //Only on 286+!
20	}
21	if (CPU_apply286cycles()==0) //No 286+? Apply the 80286+ cycles!
22	{
23		CPU[activeCPU].cycles_OP = MODRM_EA(params) ? 8 : 2; //No hardware interrupt to use anymore!
24	}
25}

I'm compiling my engine with "wm387" which is supposed to emulate the FPU - but I don't think it is working, for some reason. I had it working a while back but now the game seems to crash on an SX in PCem.

Did you notice that your SOUND folder has two Walk.raw files(with different extensions, .raw and .RAW), which are counted as one and the same when extracted under Windows/MS-DOS?

Running a boot with minimal configuration(no drivers), running hdpmi32.exe then ted.exe gives me a level prompt. I enter 1 and press enter. Then it says "Loading tiles: page number 1/19" and seems to hang?

Edit: It seems to be permanently HLTed, at 0000:000C. EFLAGS=7002. In Real mode.

Haha, yes I did notice the walk.raw thing. It’s fixed now but it shouldn’t affect the operation of the engine.

TED is the level editor, and is really only guaranteed to run in DOSBox, though theoretically it will also run on a 386. Run ENGINE.EXE for the main program.

keenmaster486 wrote:

Haha, yes I did notice the walk.raw thing. It’s fixed now but it shouldn’t affect the operation of the engine.

TED is the level editor, and is really only guaranteed to run in DOSBox, though theoretically it will also run on a 386. Run ENGINE.EXE for the main program.

Ran HDPMI32, then ENGINE. First #GP fault(segment write), then #GP fault->double->triple fault immediately after that on a memory operand(ModR/M dereference)?