OSCA Emulator with added experimental goodness
Jan 05
Computer System Emulation, Emulation 2 Comments
So I did finally manage to spend some time looking at the video generation system in the OSCA emulator, and at the same time took the opportunity to split the CPU and video generation into separate threads to try to alleviate some of the performance problems for dual-core CPUs and better.
Yippee — Well, almost 😉
That upside is offset rather heavily by the extra strain on the emulation core incurred by adding emulation of the following:
1. LineCop video co-processor (should be 100% emulated, or thereabouts)
2. Dual-Playfield Legacy tilemap mode (no hardware scroll implemented yet)
3. Extended dual-playfield tilemap modes (16×16 and 8×8) with no hardware scroll yet
4. Improvements to the bitmap rendering to correctly support the modulo register (well, mostly heh)
5. Revision of the display window sizing – this doesn’t always work correctly yet, but is a step in the right direction longer-term
6. Sprites. All 127 (or 126) of them! (sans-xflipping, matte mode or priority interleaving for the moment)
7. Second palette bank added to allow palette tomfoolery
What this means is that it is (probably) an improvement on the previous version – certainly more runs now, provided your PC has the minerals for it!
First screenshot shows Phil’s Vectorballs demo running (which shows sprites and legacy dual-playfield):
Next screenshot shows the title screen of Phil’s Bounder remake (due to lack of joystick emulation, thats as far as it’s going for now!). There’s a weird graphical glitch during loading, but that’s a fairly minor annoyance:
Next screenshot shows the linecop doing the aforementioned palette tomfoolery autonomously from the main CPU (as well as the bitmap modulo in its special “re-use” mode and the odd sprite or plenty) in Phil’s “Pipes” demo:
Finally, a couple of screenshots showing some of Altair’s excellent Loopback demo which now plays through to completion on the emulator (albeit noticably dragging the emulation kicking and screaming over hot coals in the process!). Also worth mentioning is the graphical glitch during the twisting ribbons which I have no clue about other than it might be a missing reverse-blit operation on the blitter (only forwards blits implemented currently):
So now that’s all out of the way, you can grab an executable below. You’ll need the previous binary distribution already unpacked, and this can be unpacked to the same folder (it has a different filename for your convenience!) Due to the changes made to the threading, it is extremely strongly recommended not to try to resize the emulator main window, or to use the CPU controls/breakpoint in the debug window as this will almost certainly result in emulation carnage!
Good luck!
DT
OSCA Experimental Binary (519.1 KiB, 1,453 hits)
Daniel
Jan 12, 2011 @ 15:49:04
Great work Tony!
You’re right about the reason for the graphical glitch in the twister part -> backward blits. Also the logo on the title screen seems to have an one pixel offset to the left. The logo is displayed using sprites; I don’t know why the circles aren’t displayed correctly though. The code simulates horizontal scrolling for each individual plane (which isn’t supported in OSCA) by modifying the individual plane start addresses (AFAIR).
I think the reason for the incorrect displaying of the interlaced bug-picture is that the LineCop routines use double-buffered picture-start-registers.
Keep up the great work!
DialTone
Jan 13, 2011 @ 21:27:15
Thanks for the feedback 🙂 The sprites are probably offset because I don’t think I compensated for the different X/Y system (it’s offset by 1 as per the docs) yet.
I thought I had the plane start addresses working correctly but it’s possible there’s a bug there 🙁
As for the interlaced bug (which is deliciously ironic in that it exposes one nicely hehe) I don’t think I was aware of the possibility of double-buffered start registers, so that’s a great heads-up 🙂
I’d love to improve the performance some, but it’s tricky synchronizing 2 completely separate threads and maintaining CPU throughput (as semaphores/mutexes are a performance headache!) and emulating the display in a line-accurate way (to get linecop and raster irq working as intended) is also quite demanding due to the complexity of the OSCA display hardware.
I’ll carry on updating it anyway as I get time, but I would really love to try to find the time to “port” (rewrite) some old 8-bit (or better even) game for V6Z80. I have a couple on my wishlist but all takes time heh. Out of interest I’ve been considering either the platformer “Flimbo’s Quest”, SHMUP “Battle Squadron” or RPG “Captive”. My preference is Captive, as I have all the ripped graphics to use as a base but reverse-engineering the map generation (esp the RNG algorithm and its exact call sequence) is proving to be a headache 🙁
Tony