Reply 40 of 113, by superfury
GloriousCow wrote on 2023-06-13, 14:45:root42 wrote on 2023-06-13, 14:03:Awesome project! Now if someone could fix area5150 so that it runs on my 286, that would be nice 😀 It runs pretty far, but crashes at some point late in the demo.
The 'Wibble' (Charlie Chaplin) and 'Lake' (End credits) effects will never run, unfortunately, as they are perfectly cycle-counted effects that will only run properly on an 8088. Even if they didn't crash, you'd just see spaghetti, if your monitor didn't refuse to sync at all.
Those ran somewhat on UniPCemu.
The output seemed stable, the images recognisable, but somehow it looked like the chaplin image was stretched somehow, like being mixed in a very specific way as a sprinkled ghost onto itself. Interestingly the elephant head image part (just the head) is somehow rendered at the top right correctly (with none of the later effects applied to it)? The effects seem to run, but the image looks like it's stretched or copy-pasted onto itself, kind of what happened in UniPCemu during it's early ET4000 VRAM banking formulas and CPU window misbehaving (causing window areas written/read to overlap the same 256K instead of 1MB (like masking off some address bits when reading/writing it shouldn't). Perhaps somehow a related issue? Is anything special wrt VRAM addressing (CPU window or renderer MA) new since 8088 MPH used here?
The credits and effects ran mostly with correct output (stable resolution) during the first UniPCemu test. The main thing there was the horizontal timing (start of scanline rendered it looks like) is off by what seems exactly 1 character clock depending on the scanline number on the screen (once again, the same on every frame). This is seen by output on the scanline shifting left on the screen in a deterministic pattern, same for all frames rendered. Nothing like shaking horizontal timings seems to happen in that part of the demo as far as I can see.
Although UniPCemu currently chokes on both parts, emulating at ~2% realtime speed per second (so 2% of 4.77MHz somehow), probably due to memory calculations and caches (UniPCemu's memory mapping being stressed on the real CPU, causing emulation to become even slower).
I think the original issue with the overscan should be fixed in the latest commits (the video card precalcs for the overscan color wasn't being applied because the parameter that was indicating to update all color registers (in reality the EGA/VGA attribute controller registers being exploited in the CGA) was being misdetected, thus always updating not a single precalc. I'd assume the same issue might have been with most palette changes on the CGA, but I'm not sure. I didn't have time to check the results yet, but it should have been fixed, as it's working just like on the VGA-compatible cards afaik (the main difference is just the color transformation and NTSC scanline color post-processing added in the CGA (mostly written by Reenigne) or simple 4-bit CLUT for direct colors (again on the whole scanline).
So if the overscan is applied now (it should, due to the precalcs fix), the vector image bouncing and 'getting rid of the overscan' should work fine now.
One interesting thing is I took a short audio capture during the credits and I think it sounded fine. So that should mean that indeed, parts of the credits related to rendering audio should be running correctly and in lockstep with the PIT and PC speaker at least? Perhaps something else is going wrong? What would cause specific parts (as in specific character clock on all frames, at the same CRT position each frame) to affect specific (same on each frame again) scanlines but not others?
Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io