Managed to implement the two LFO signals into the MIDI synth.

Now all that's theoretically missing is just the initialFilterQ setting (on the generator/modulator part), which isn't emulated(and probably can't, since it's a basic RC filter)?
And of couse stereo samples are still ignored(it just plays the pointed (left/right only or mono only, ignoring the sample type) samples, with panning being applied as with mono samples.

Just fired up Windows 95 OSR 2.5 "C". It seems to properly enable the Removable Media Status Notification protocol now! 😁

I've also improved the CPU emulation to now support a Pentium Pro(i686) as well. It's the same as the Pentium without FPU, but with the non-FPU Pentium Pro opcodes implemented as well(and those new NOPs are still normal NOPs, they're not doing anything fancy to optimize).

One nice thing that's now noticeable is that the Modem is redetected, this time it should be for the last time. That's because the modem is now permanently moved to COM2 instead of COM1 where it was before when using a PS/2 mouse. COM1 is now just disconnected while a serial mouse isn't in use(and the PS/2 mouse is instead).

Edit: Also finally see Windows 95 "C" using the removable media status notification feature set! 😁

Just upgraded the CPU emulation a bit again. Now it supports the i786 instruction set(in other words, the SYSENTER and SYSEXIT instructions) on a newly implemented Pentium II (although it, like the Pentium and Pentium Pro, doesn't have a FPU). So those other two new instructions(FXSAVE and FXRSTOR) are also undefined(since they're FPU opcodes), throwing #UD exceptions.

OK. I've noticed something interesting:

- Windows 95 boots without issues until Pentium II (so on all emulated CPUs).
- Windows 95 reports Pentium Pro as Pentium Pro, but reports Pentium II as Pentium Pro?
- Windows 98 crashes on VPICD.VXD for Pentium Pro and Pentium II, but not crashing at all on Pentium?

Edit: OK. Having fixed and implemented all Pentium Pro MSRs(just placeholders, with basic masking of the data on writes for #GP(0) faults and ROM bits), Windows 98 boots now! 😁

Now the question, does the Pentium II have the same effect?
Edit: Not yet, at least. I still needed to implemented some 9 extra MSRs on the Pentium II emulation.

Edit: OK. After implementing the Pentium II MSRs and adding an extra(somehow needed to boot) MSR 17h (some kind of ID MSR apparently, according to Linux? ) without any filters or anything(I don't know anything about it), Windows 98 properly boots.
But it somehow reports the CPU as having MMX technology, which it obviously doesn't? (Also not implemented according to CPUID leaf 1 ECX/EDX result)
Edit: OK. Just found out something: Windows 98 on model 5 stepping 1 requires MSR 17h to boot and detects as a Pentium II "MMX technology". The same for model 3 stepping 3, which doesn't require said undocumented PII MSR(For the Pentium II at least? Linux knows of it? Some kind of ID?)?

Just added missing stereo sample support to the Soundfont synth. It should now be able to render the stereo samples, if they're present in the soundfont.

Although that means that some things get double as heavy to process now, mainly everything in the sample retrieval/looping of the samples and the low-pass filter (which already is relatively heavy on CPU processing).

Just implemented the Pentium-specific MSRs and their write-only(newly supported) and read-only bit definitions.

After adding and implementing the Pentium Pro's PAE extensions, I noticed that the paging TLB caching algorithm in UniPCemu had a bug. It was giving the most recent result instead of the valid flag(to indicate if the TLB lookup succeeded) and not filling the resulting address at all. So the TLB lookup would succeed depending on the address(it usually wouldn't) and give the most recent result left over in the result variable(or whatever was in it, probably garbage, since it's uninitialized data).
That's another bug now fixed 😁

Also just found a little bug in the PDBR that caused it to ignore the lowest 7 bits of the CR3 base address in PAE mode. So it would round the address down to 4KB while it shouldn't be rounding said register at all(only ignore the lower 5 bits, since they contain PCD, PWT and zeroes(which are always to be ignored)).

Having fixed the bugs up until now, it looks like WinEject is running better now. The settings can now finally be opened. But, when trying to open the CD's individual drive open/close submenu in the taskbar icon, it will crash the program?
Also, one of the SCSI_502.pdr (hard disk/CD-ROM driver) drivers managed to crash somehow when trying the software for the first time?

OK. With the latest bugfixes and a repair install of Windows 95 C(OSR 2.5), WinEject no longer crashes! 😁

Hmmm... What's causing Sandra 95 to crash on MFC42.dll at 0137:5F404FFC is reported as a Page fault("caused an invalid page fault in" in the error message), but is actually caused by a general protection fault instead? The dll is trying to access address 0xB6 incorrectly for a CALL(GRP5 /2) instruction?

This is the information I got so far:
CR2=5f41834d (last page fault address raised by UniPCemu)
CR3=004b6000(Current PDBR)
CS:EIP=137:5F404FFC(Faulting address)
TR=0018:C000AEBC(System task?)
Filename: MFC42.dll

This is what happens:
https://www.dropbox.com/s/6vg8ifmrrhrri3i/deb … 03_0055.7z?dl=0

It seems to be somewhere within the SEH handling it's crashing? I can't see anything going wrong myself?

Anyone knows more complete-ish CPU testing software like CheckIt? All the tools on Jiren's BootCD 7.8 pass diagnostics, as does CheckIt 3 for DOS and CheckIt 4 on Windows(the DOS bootdisk version gives a divide by zero error).

Just tried the old Windows NT 4 installation that was first stage installed on the hard disk from Windows 95. It now actually boots(on the i430fx)! Thus no longer bluescreens with the process1_initialization_failed ntdll.dll error!

OK. No more visible errors with NT 4 workstation after it's first booting the graphical setup from the hard disk. But it will somehow triple fault after loading the GUI(mouse is visibly working)? Or at least seems like it's triple faulting?
Edit: That's just when booted from the hard disk. The floppy disk (3 disk set) doesn't change and still gives the PROCESS1_INITIALIZATION_FAILED BSOD.

Edit: OK. The OS doesn't triple fault, but still reboots the machine?
Edit: Hmmm... Something is triggering a CPU reset for some weird reason?
Edit: It almost looks like the 8042 is receiving a 0xFA command, which would result in a CPU reset?
Edit: Nope. It's executing a 0xFE CPU reset pulse command to the 8042.

Edit: Just changed the 8042 enable second PS/2 port command to no longer give a 0xFA ACK response. Now Windows sets the PS/2 keyboard typematic rate/delay, after a HDD read and finally a HDD write it once again sends in a CPU reset command to the 8042.

So it really doesn't like something that's happening? Probably something to do with the CPU?

Hmmm... Something's weird? When creating the 3 Windows NT 4.0 setup disks from the CD-ROM, the second and third disk are containing junk? As in, all file names are random data it seems(according to WinImage)?
Edit: Seeing as the floppy disk emulation is barely changed since the last time I tried to make the disk images, there's a CPU issue causing this? Or perhaps the BIOS itself?

Just found a bug in the TLB invalidation function(used for INVLPG). It would stop handling any remaining TLB entries for a certain way (4-way on each of the sizes(2M/4M and 4K having seperated ways)) when it found an entry to invalidate and invalidated it. And entries that were older were ignored by the function (which they obviously shouldn't be). This was due to a pointer to the next entry being updated through deallocation pointing to the next unallocated TLB entry to check, instead of using the next allocated TLB entry to check(which would be the correct next entry to search). So if, for example, it removed the first allocated entry, it then would parse all deallocated entries instead of the allocated entries that are still in the TLB and that are more LRU, which obviously is incorrect behaviour.

OK. Windows NT 4.0 workstation now tries to reset the CPU by sending a 0xFE command to the 8042 after the GUI has started. That happens at location 80014390h (opcode EEh, which is OUT DX,AL).

The state is as follows:
CR2=C1B80000h
Last fault type=0x0Eh(page fault).
CR0=8001001Dh
CR3=1285000h
CR4=11h
GDTR=80036000h limit 3ffh
IDTR=80036400h limit 7ffh
EAX=FEh
EBX=80153226h
ECX=1h
EDX=64h
ESP=F750FE44h
EBP=F750FE78h
ESI=80014388h
EDI=1h
CS=8h
SS=10h
DS=23h
ES=23h
FS=30h base=FFDFF000 limit=1FFFh
GS=0h
TR=28h base=8001D000 limit=20ABh
LDTR=0h

Perhaps I should add a FS and GS segment filter to the debugger, to allow trapping specific Windows processes?
Edit: Just implemented FS segment breakpoint. So it will now be able to properly filter out Windows 9x and NT processes.
Unfortunately, Bochs is of little use here, since it cannot even start to boot the OS with i430fx BIOS with i430fx motherboard emulation?
Edit: Hmmm... Perhaps it's receiving a bit too many timer interrupts from the CMOS chip. I'll change it to the cycle-accurate mode(which makes it sync to the CPU timing like all other hardware instead). That should speed up the logging process, as it should be way faster now(due to instead of ~100+ interrupts per second it'll just produce 1 IRQ each second of emulated time(because realtime is running way faster because the emulation is running at a fraction of realtime speed)).

Edit: OK. With the cycle-accurate mode, results come in way faster. It's now:
CR2=C1E40000h
Last fault type=0x0Eh(page fault).
CR0=8001001Dh
CR3=01285000h
CR4=11h
GDTR=80036000h limit 3ffh
IDTR=80036400h limit 7ffh
EAX=FEh
EBX=80153226h
ECX=1h
EDX=64h
ESP=F750FE44h
EBP=F750FE78h
ESI=80014388h
EDI=1h
CS=8h
SS=10h
DS=23h
ES=23h
FS=30h base=FFDFF000 limit=1FFFh
GS=0h
TR=28h base=8001D000 limit=20ABh
LDTR=0h

OK. I've managed to make a full log from the last page fault until the 0xFE CPU reset command is sent to the 8042: https://www.dropbox.com/s/8kw0oa75oi8cali/deb … 12_1209.7z?dl=0

Anyone can see what's going wrong?

The last thing I see it do before triggering the reset in the log, is execute a C5 write multiple command to the hard disk?
The parameters are as follows(it's a 504MB HDD):
1F2=08h(thus a 4KB block being accessed)
1F3=30h
1F4=FFh
1F5=01h
1F6=A0h
1F7=C5h(write multiple).

That's found out by searching for "out " and "in " specifically in the log.

After that, port 1F7(the status register) reads 50h(which should mean that the drive is DSC, ready)?
It verifies that the write succeeded, and reaches 0008:8000312d.

One weird thing I also see, is that just before the reset, it writes 0xFE to CMOS register 15h, which should be the system base memory in KB LSB? So it's setting it to 254KB? That's according to http://bochs.sourceforge.net/techspec/PORTS.LST ?
It looks like it passed all tests, reaching 0008:800031e6.
Edit: Further down, it checks for AL=3, which passes again. It thus reaches 0008:80003440.
Edit: DRQ isn't set, so it reaches 0008:8000344a.
It loads something from a pointer, then loads ECX with it's value, finds it zeroed and jumps to 0008:800035aa.
It then checks some dword being 04h, not finding a match(it's 01h), then jumping to 0008:800035bc.
It then pushes something from the stack(03F6h)? It then calls the function pointer 80004c04, jumping to 0008:80014320.
It reads port 3F6 that was on the stack... It's 50h? So somehow, the drive/head register changed from A0h to 50h? So the top 4 bits somehow changed state after starting the command(without CPU intervention)?
So it looks like it somehow changed between CHS/LBA modes when executing the commands? Weird (bug???)?
It thus reaches 0008:800035c7 with the new drive/head register (50h) in the AL register?
Edit: So, it's changed from the master(boot disk) to the slave(not connected).
Edit: It compares BX with 1Eh(???) and finds it's not 1Eh. So it jumps to 0008:800035f6.
It checks the DRQ bit again, finds it not set. So it jumps to 0008:8000356f.
DI is set to non-zero, so it jumps to 0008:8000357b.
Some byte at [EDI+02] is not 02h, so it reaches to 0008:80003650.
ESI+49h is zero, so it jumps to 0008:800036ed.
EAX=0, so it jumps to 0008:80006614.
It loads EDX from the stack, then reaches 0008:80006617.
Don't have any time left right now. Need to resume checking the log later.
Edit: Resuming...
It loads ECX from EDX+Ch, loads said memory address data into EAX(10180h).
It then checks EAX bit 16. Finds it set and clears it. It then moves it back to said memory address(address 8076d254).
It then checks EDX+10h bit 4, finds it not 10h, thus jumping to 0008:80006658.
It sets up some parameters, then calls function 80008206.
Said function finds AL=FFh, thus reaching to 0008:80008211.
It pushes the equivalent of ECX from the stack(8076D200).
It then pushes said parameters once more and calls function 8000782c.
That function sets up it's stack frame, and loads the last pushed value into EAX.
It checks some parameter against 00h (02h). It finds that it's not lower or equal, thus reaches 0008:8000783c.
It looks said parameter up into a table(using EAX as a base), then finds it non-zero, thus reaching 0008:8000784e.
It does some more checks, thus reaching 0008:80007859.
Then one more check against the EAX memory address dereference itself, finding a match(00h), jumping to 8000786b.
This aborts the function?
It then checks EAX, finding it non-zero, thus reaching 0008:80008226. It then adds 40h to it, jumping to 80008251.
That aborts the function once again, reaching 0008:8000666e.
It loads ECX with ESI+CCh, then loads EDX from said address (807a91b4=>0h).
It then moves EAX(807aa3e8) into that location. So it's entering some kind of stack frame-like process?
It then jumps to 80006707.
That sets bits 2 of ESI+C8h.
It then returns to the caller, after restoring the ESI and EBP registers from the stack. It then reaches 0008:800036f7.
It then checks some byte against AL, reaching 0008:80003701 because it matches.
It saves ESI, then calls some function at [80004c18], at 0008:80003707, with parameter 01h at linear address f750e760.
This reaches the function at 0008:800065c4.
It sets up a stack frame, loads said 01h parameter into EAX, and sets up a stack frame. Thus reaching 0008:800065cb.
It finds EAX=01h(the function number pushes previously), thus setting 807a91B0(ESI+C8) bit 3.
Then it jumps to 0008:80006707, which sets bit 2 of said variable also.
It then returns to the caller, which resumes at 0008:8000370d.
That one cleans up, sets AL to 01h, then cleans up and returns once again. Thus reaching 0008:80006f61.
0008:80006f61 then checks bit 2, moves the result code into BL and because said bit was set reaches 0008:80006f68.
It then loads EAX from [EDI], adds 74h to it and pushes it on the stack(at f750e798). It then calls function pointer [80008778], which should be 0008:80116eae function 00h?
That pushes some more, then calling function pointer [80140bfc], jumping to 0008:80014410.
That loads al from the current thread ID low 8 bits(at 0008:80014412) from address FFDF024. The value of that is 0Dh.
It then changes that to 1Fh(which is the value of CL)? It then returns to 0008:80116ebd.
It stores the result in BL, then loads the process ID into EAX, which is ffdff120.
It the loads ESI, finds it zero, setting ECX to the process ID + 528h.
That's process ID ffdff648?
It then increases dword process ID+4F0 at 0008:80116ee2 by 1.
The same with process ID + 4E8.
It then stores ECX somewhere(807a90c0) at 0008:80116eee.
It then stores EBP somewhere(at 807a90b8).
It then sets EBP to process ID + 4E0.
It then clears EDX+18h by loading EDI there, at 0008:80116efa.
It then checks [EDX+03h] against 02h, which is 01h at 0008:80116efd. Finds it not 02h, thus jumping to 0008:80116f16.
It then loads EDI from the stack, becoming FFDFF600, storing at 807a90ac.
It then stores ECX at FFDFF600(at FS:600) at 0008:80116f21.
It checks [FS:60C] against zero, finds it zero, thus reaching 0008:80116f30.
Thus it sets EDI to ffdff5e0(FS:5E0).
It checks that location against zero, which it finds, ending up at 0008:80116f3a.
It checks 807a90a7 against 00h(CL), finds 01h. Thus jumps to 0008:80116f5b.
It then sets FS:5E0 to 01h. Then calls 0008:800149a4.
It sets FS:28h bit 2 at 0008:800149ad (Active RPC Handle).
The active RPC handle is now 04h. It loads something from address 8001575c+RPL handle low 2 bits into DL at 0008:800149c3.
It finds it's less or equal to 1Fh(CL) thus pops the flags and returns to 0008:80116f6c.
It then calls function 0008:80014440 after loading said limit(?) into EBX.
Thus it loads 0Dh into CX, masks it to 8-bits and switches the thread ID to 0Dh at 0008:80014448.
It then loads the RPC handle(04h) into and masks it using entry 0Dh(ECX), which is 0x3FFF0.
It finds it zero, thus reaching 0008:8001445d.
That returns to 0008:80116f74.
It eventually returns to caller because CL was 0, with AL=01h, reaching 0008:80006f78.
It then returns once again to caller, reaching 0008:8013f12a.
It then calls function pointer 80140c70, reaching 0008:80014494 after disabling interrupts.
It loads the RPC handle into EDX. ands it with ECX(0) entry at 80015680, which is FFFFFFFEh. Thus it stays 04h. Then it finds it non-zero and jumps to 0008:800144b4.
It then checks the Linear address of the thread-local storage array(FS:2C) mask FFFFFFF0 and finds it zeroed, thus reaching 0008:800144c0.
It finds said RPC handle highest bit set being 02h, which is less or equal to 02h, thus jumping to 0008:80014518.
It then jumps to the RPC handle? That's at 0008:8001451b, reaching 0008:80014b3b.
It saves the thread ID on the stack(00h). Then sets it to 02h.
It then clears the RPC handle bit 2, clearing it to 00h.
It then enables interrupts and calls function pointer 80015254 at 0008:80014b50, which is 0008:8013f470.
That loads the Environment Pointer into EBX.
It then adds 600h to it into EAX.
It compares it against that address(which reads 807A90A8), finds it not matching, reaching 0008:8013f481.
Ah well, after running the other thread(which should have been started with a MOV FS,BX(where BX=30h), thus reloading the current TIB?
It eventually calls a routine at 80006F80 at 0008:8013aaea?
And another subroutine is called at 0008:8013efd0, from 0008:80006fae.
So it's in the kernel somewhere now afaik?
Then another subroutine at 0008:80014410.
It then loads the thread ID into EAX again. 0Dh into CL and returns.
The caller stores it in stack address f750e728.
It then calls an address on the stack: 0008:80007722 from 0008:8013efee.
Well, it eventually tests the bitflags that had bit 2 and 3 set at 0008:80007732, reading from address 807a91b0, thus jumping to 0008:8000773e.
It then copies a block of memory (60 bytes) from 807a91b0 to f750e75c.
It then ANDs that flag(which was 0C) with 4180, thus it becoming zeroed.
It eventually calls routine 0008:8000782c.
And another zero check further down, reaching 0008:80007859, reaching 0008:8000785e.
Then once again zero, thus reaching 0008:8000786b.
It then checks CL from EDI+03(=01h) with 01h, which matches, jumping to 0008:800077d7. So something's changed now.
It sets CL to 1 and because EDI+08 was 0xFF, it jumps to 800077F5.
Because CL isn't zero, it reaches 0008:800077f9.
It checks if ECX is 64 ahead of EAX, which it is, reaching 0008:80007803.
It then sets EAX+30h to -1(all 32-bits set).
Then it jumps to 0008:80007818.
Then it loads ESI and finds it's zero, thus reaching 0008:80007823.
That sets AL(the result?) to 01h and returns to the caller at 0008:8013eff1.
It then calls function 0008:80014440.
It then sets the current thread ID to ECX, which is 2h.
Then the Active EPC handle(00h) into EDX?
It finds it's zeroed after masking, popping flags and returning to 0008:8013effc.
It then pops registers back, with EAX becoming EBX and returning to the caller using LEAVE and "RETD 0C".
The caller checks AL and finds it non-zero, reaching 0008:80006fb9.
It checks bit 4 of BP-40h, which isn't set, thus reaching 0008:80006fe9.
It then checks bit 5 as well, thus jumping to 0008:80007064.
It finds BP-3E bit 0 cleared, so jumping to 0008:800070b2.
It finds bit 3 of 0244e75c set, thus reaching 0008:800070b8.
It loads EAX from [ECX] ([807a90fc]) at 0008:800070bb, which is 1001h.
It masks DX with 1001h, and matches it, reaching 0008:800070cd.
It clears bit 0 and moves it back into [ECX].
It then checks bit 7 of said bitflags. It's cleared, reaching 0008:800070d7.
It then moves 0xFFFFFFFF into memory address 807a9104.
It then jumps to 0008:800070e8.
It checks bit 1 of a bitflag, finds it zeroed, jumping to 0008:800070f5.
And got no time left again. Need to resume the checking later.

It seems to be searching for a needle in a haystack. Perhaps I should do a reverse search: start at the bottom, tracing parent routine ('s parent routine etc.) execution until I hit something interesting?
So far backtraced to 0008:80011902. Then 0008:800118fd.
I find 0008:800118e7, which may be a trigger.
That's called by 0008:8015338b.
Then 0008:80153380.
Then 0008:80153371.
Then 0008:80153363.
Edit: That last one's a dead end. It's never written said memory address anywhere in the log?
When searching upwards for the return address being written, I do, however, find this:
0008:8015338b FF 15 D8 0B 14 80 call dword ds:[80140bd8]
It writes some different value there:

1	RealRAM(p):0015338b=ff(?); RAM(p):0015338b=ff(?); Physical(p):0015338b=ff(?); Paged(p):8015338b=ff(?); Normal(p):8015338b=ff(?); RealRAM(p):0015338c=15(); RAM(p):0015338c=15(); Physical(p):0015338c=15(); Paged(p):8015338c=15(); Normal(p):8015338c=15(); RealRAM(p):0015338d=d8(?); RAM(p):0015338d=d8(?); Physical(p):0015338d=d8(?); Paged(p):8015338d=d8(?); Normal(p):8015338d=d8(?); RealRAM(p):0015338e=0b(); RAM(p):0015338e=0b(); Physical(p):0015338e=0b(); Paged(p):8015338e=0b(); Normal(p):8015338e=0b(); RealRAM(p):0015338f=14(); RAM(p):0015338f=14(); Physical(p):0015338f=14(); Paged(p):8015338f=14(); Normal(p):8015338f=14(); RealRAM(p):00153390=80(?); RAM(p):00153390=80(?); Physical(p):00153390=80(?); Paged(p):80153390=80(?); Normal(p):80153390=80(?); RealRAM(p):00153391=33(3); RAM(p):00153391=33(3); Physical(p):00153391=33(3); Paged(p):80153391=33(3); Normal(p):80153391=33(3); RealRAM(p):00153392=c0(?); RAM(p):00153392=c0(?); Physical(p):00153392=c0(?); Paged(p):80153392=c0(?); Normal(p):80153392=c0(?); RealRAM(p):00153393=5e(^); RAM(p):00153393=5e(^); Physical(p):00153393=5e(^); Paged(p):80153393=5e(^); Normal(p):80153393=5e(^); RealRAM(p):00153394=5b([); RAM(p):00153394=5b([); Physical(p):00153394=5b([); Paged(p):80153394=5b([); Normal(p):80153394=5b([); RealRAM(p):00153395=c2(?); RAM(p):00153395=c2(?); Physical(p):00153395=c2(?); Paged(p):80153395=c2(?); Normal(p):80153395=c2(?); RealRAM(p):00153396=04(); RAM(p):00153396=04(); Physical(p):00153396=04(); Paged(p):80153396=04(); Normal(p):80153396=04(); RealRAM(p):00153397=00( ); RAM(p):00153397=00( ); Physical(p):00153397=00( ); Paged(p):80153397=00( ); Normal(p):80153397=00( ); RealRAM(p):00153398=64(d); RAM(p):00153398=64(d); Physical(p):00153398=64(d); Paged(p):80153398=64(d); Normal(p):80153398=64(d); RealRAM(p):00153399=a1(?); RAM(p):00153399=a1(?); Physical(p):00153399=a1(?); Paged(p):80153399=a1(?); Normal(p):80153399=a1(?)
20008:8015338b FF 15 D8 0B 14 80 call dword ds:[80140bd8]	RealRAM(r):00140bd8=dc(?); RAM(r):00140bd8=dc(?); Physical(r):00140bd8=dc(?); Paged(r):80140bd8=dc(?); RealRAM(r):00140bd9=18(); RAM(r):00140bd9=18(); Physical(r):00140bd9=18(); Paged(r):80140bd9=18(); RealRAM(r):00140bda=01(); RAM(r):00140bda=01(); Physical(r):00140bda=01(); Paged(r):80140bda=01(); RealRAM(r):00140bdb=80(?); RAM(r):00140bdb=80(?); Physical(r):00140bdb=80(?); Paged(r):80140bdb=80(?); Paged(w):f74ffe60=91(?); Physical(w):0217ae60=91(?); RAM(w):0217ae60=91(?); RealRAM(w):0217ae60=91(?); Paged(w):f74ffe61=33(3); Physical(w):0217ae61=33(3); RAM(w):0217ae61=33(3); RealRAM(w):0217ae61=33(3); Paged(w):f74ffe62=15(); Physical(w):0217ae62=15(); RAM(w):0217ae62=15(); RealRAM(w):0217ae62=15(); Paged(w):f74ffe63=80(?); Physical(w):0217ae63=80(?); RAM(w):0217ae63=80(?); RealRAM(w):0217ae63=80(?)
3Registers:
4EAX: 00000004 EBX: 80153201 ECX: 00000000 EDX: f74ffe44
5ESP: f74ffe64 EBP: f74ffe78 ESI: 00000001 EDI: f74ffe78
6CS: 0008 DS: 0023 ES: 0023 FS: 0030 GS: 0000 SS: 0010 TR: 0028 LDTR: 0000
7EIP: 8015338b EFLAGS: 00000246
8CR0: e001001d CR1: 00000000 CR2: c1ac0000 CR3: 01285000
9CR4: 00000091
10DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
11DR6: 00000000 DR7: 00000000
12GDTR: 00008003600003ff IDTR: 00008003640007ff
13CS descriptor: 00CF9B000000FFFF
14DS descriptor: 00CFF3000000FFFF
15ES descriptor: 00CFF3000000FFFF
16FS descriptor: FFC093DFF0000001
17GS descriptor: 000013000000FFFF
18SS descriptor: 00CF93000000FFFF
19TR descriptor: 80008B01D00020AB
20LDTR descriptor: 0000000000000000
21FLAGSINFO: 0000000000ipfavr0n00odItsZ0a0P1c 

0008:8015338b ends up at 0008:80153391, which is written on the stack. That's at ESP=f74ffe60. It's physical memory is 217ae60.
The weird thing here is that that very same physical memory address seems to have changed values in between the call and the return, without the code itself having anything to do with it directly? Or perhaps some other process stepped in and did something with it? That isn't logged?

Just throught I'd try Windows 2000 to compare with NT 4.0 Workstation. It seems to be in protected mode with paging enabled and executing some small loop at linear address 321A8E infinitely (it keeps jumping back from 008:00321AA6)?
That happens directly after the press F6 prompt for installing a SCSI device or other unsupported devices.

OK. I've managed to get some information about the page fault causing the NT 4.0 crash eventually(the last page fault that happens before the CPU reset happens, to Linear Addresss C15C0000):
CR4=91h
PDE=43163h.
PTE=472C34h
It's a write at kernel privilege.
The error code pushed is 0002h.
The instruction is a MOVSD at 0008:8010471e.
TR=28:8001D000.
CR3=30000h.
FS=30:FFDFF000.
Of course, TR and FS are noted as segment:baseaddress, as UniPCemu uses for it's debugger breakpoints.
Anyone can tell me more about what might be going wrong here?