I approve of this. I approve of this greatly.

kazblox wrote:

They say it's unemulatable and breaks emulators....

I don't think we ever said it's unemulatable period. Merely that the state of PC emulators was quite poor, so none of the existing ones were able emulate it properly, and it would take quite a bit of work to update them to fix that.
I think you'll find that the plasma, Kefrens and end credits will be most difficult to emulate properly.

The plasma is difficult because it runs in 80 column textmode, and technically you should emulate CGA snow properly to make it appear exactly the same as on real hardware.
Kefrens and end credits are difficult because they are 'free-running', as in, the code is tuned to run at exactly the right speed on a real IBM PC. So you need to have cycle-exact emulation of not only the CPU, but also the rest of the system, so the PIT, CRTC and CGA memory wait states as well.

End credits has another difficult issue in that it exploits a characteristic of the prefetch-buffer. That is: if you modify an instruction that is already in the prefetch-buffer, the fetched instruction will not be updated, so you will execute the unmodified instruction.

Proper NTSC composite emulation was another thing that no emulator did correctly, but reenigne already fixed that.

Basically, you'd have to bring PC emulation up to the level of accuracy of emulators such as Vice and UAE, and then you can emulate 8088 MPH just fine.
It's good to see that some people are actually making an effort to do so!
I hope to see a 100% accurate PC emulator one day, and I hope it inspires more demosceners to do PC demos, because it would make the platform more accessible to a wide audience, and development will be more convenient.

Keep up the good work!

PS: I'm somewhat surprised that the Moire and Polygon parts don't work properly. These don't really do anything exotic in terms of timing or other special hardware tricks. In fact, I know for 100% that the Polygon part has always worked in DOSBox, because I used DOSBox a lot while I was developing that part.
Perhaps the problem is caused by the effect immediately in front of it, leaving the emulator in a poorly defined state?

Edit: OBattler implemented SALC in the interpreter. Moire now works.. Not ready to push to Git repository yet.

Polygon part still doesn't work though, might be an issue with the FDC issue or memory banking if the part can't completely load in memory.

Maybe you don't have enough conventional RAM 🤣

kazblox wrote:

Edit: OBattler implemented SALC in the interpreter. Moire now works..

Ah yes, I suppose the Moire effect ran, but just never exited? At least, that's what it did on a V20 CPU, which does not implement SALC. I made a new version of the effect that doesn't use SALC for V20-users.

kazblox wrote:

Polygon part still doesn't work though, might be an issue with the FDC issue or memory banking if the part can't completely load in memory.

I believe that part only needs about 350KB of conventional memory.
How exactly does it fail? If it doesn't even start, perhaps there's an issue with the libc. The part is written with OpenWatcom 1.9. Since there was a bug in the FPU detection routine of its libc, it locked up on real 8088 machines with no FPU. So I patched it.
It may be that this patched version breaks the emulator. If you can enable/disable FPU-emulation, perhaps you can experiment with that and see if it changes anything.

Scali wrote:

Ah yes, I suppose the Moire effect ran, but just never exited?

I think it was just exiting immediately (i.e. AL had the opposite value in PCEm-X than on a V20).

From https://www.youtube.com/watch?v=Vg2n8Fp7F2g (made before the SALC fix) it looks like the polygons, Kefrens and credits aren't working at all. Calibration, intro, plasma, sprite and mugshot basically work but have some graphical glitches.

- Scali: What is the expected behavior on an 8088 without FPU when one of the FPU prefixes is issued?

Battler wrote:

- Scali: What is the expected behavior on an 8088 without FPU when one of the FPU prefixes is issued?

FPU instructions are ignored.
The problem is that wait/fwait will lock up the machine. On 286+, the interface between CPU and FPU is different, and a wait/fwait will not lock up when there is no FPU.
The problem is that usually all FPU instructions automatically get a wait prefixed by the compiler/assembler.
So where a 286+ can just execute FPU instructions and generate an exception when no FPU is present (which can be caught by an emulator), an 8088 freezes, because there is no FPU to ever trigger the ready-signal to end the wait-instruction.
This is what happened in the OpenWatcom lib, so I patched it for 8088 MPH.
I have never tested this code on anything other than an 8088 without FPU though.

https://www.youtube.com/watch?v=-ZASZfOgsnw

Poof. The only thing needed to be done on now are the Kefrens and the Credits scenes, which will take some long time to figure out.
Also New CGA capture as a bonus.