• entries
    222
  • comments
    607
  • views
    588105

New Z80 emulator

Sign in to follow this  
benryves

1769 views



One chap I cannot thank enough is CoBB for all his hard work in the Z80 field.

I've rewritten the Z80 emulation from scratch; this time it uses an expanded switch block (the 'manual' way) to decode instructions. Rather than write every combination of instructions out by hand, the code making up the switch blocks up is generated by another program, reading instruction information from a table copied from an Excel spreadsheet.

At the cost of a significantly larger assembly (from 40KB to 140KB) I now get a 100% speed increase (from ~50MHz to 100MHz).

I still can't pass the port of ZEXALL I'm testing with (and the same instructions too - not bad for a 100% rewrite to end up with exactly the same bugs), but after comparing some of my offending tables against CoBB's ones I've isolated some of the hiccoughs. The only instruction group test I fail is, naturally, the one that takes the longest to execute - getting a hardware, or indeed emulator, comparison takes well over an hour.

Anyhow, rewriting the Z80 emulation seems to have been the right thing to do. As you might have guessed from the picture at the top of this entry, Sonic now runs.


My VDP (Video Display Processor) emulation is still rather rough-and-ready (I've really been concentrating on the Z80 bit) and the second column of background tiles is not updated correctly, so I apologise in advance for the distortion! It only appears in SMS mode (the display is cropped in Game Gear mode).


The fill colour (in the left column here) is incorrect in most games too.


I rather preferred Sonic 2, but maybe that's because you can pick up dropped rings and I'm rather lousy at it otherwise.


I accused the previous Wonder Boy III shot of not reading the start button. Somehow I also failed to notice the missing sprites (clouds and main part of the castle), which was part of the main problem. It now appears to play well.


Support for zoomed sprites seems to be missing in some emulators (at least, the versions of Dega and Pastorama I have to hand), but I use them so implemented them to let my programs work when testing - it's nice to see a commerical game use them too!


Gunstar Heroes runs, but flickers and jumps (not the visible sprite 'flicker' in those screenshots) - some bug in my CPU interrupt handling or VDP interrupt generation.


Psycho Fox runs insanely fast - even faster than The Flash as seen to the right - making an already difficult game to control virtually impossible. I'm really not sure what could be causing that, but the enemy sprites sometimes flicker up and back down quickly, so it could be one of the remaining CPU bugs.


Fantasy Zone demonstrates both the blanking colour bug (that left column should be green) and the distorted second column bug, but plays well. I tried to get a better screenshot of Maze Walker, but not handling 3D glasses makes looking at the screen a rather unpleasant experience (it flickers the left and right eye views in quick succession; the 3D glasses had two LCD shutters that opened and closed in sequence with the images on-screen).

I might add a Dega-esque red/green anaglyph filter, but I find those rather unpleasant to look at so might provide a stereo pair view.

In any case, the most important SMS game now runs -


I shall refrain from using the Terry Pratchett quote (just this once).


Some games look like the above, which makes me happy - it's the ones that do nothing at all that worry me. What with the CPU bugs, dodgy emulation of the mapper, missing (important!) hardware ports and hackish VDP, it's surprising anything runs. It's getting better.

EDIT: How are there so many spelling errors? Fantasy Start as opposed to Fantasy Zone, Video Display Hardware as the expansion of the VDP acronym... I should not write these so late at night.
Sign in to follow this  


4 Comments


Recommended Comments

I seem to remember Psycho Fox has an unusual VBlank handler that just sets a flag and exits; that may be related to the speed problems.

If you can figure out the ZEXALL test bitmasks, and can run a modified version on hardware, you can use that to narrow down your search to the failing opcodes. Or, you might try running alongside another emulator (that supports debugging) and trying to step through (maybe a frame at a time) until the running CRC differs.

Share this comment


Link to comment
Quote:
Original post by MaximZhao
I seem to remember Psycho Fox has an unusual VBlank handler that just sets a flag and exits; that may be related to the speed problems.
Interrupts are not handled correctly. Currently, EI sets both IFF1 and IFF2 to high instantly, rather than setting them after the next instruction has executed. When I had it set to add this delay, some games that hadn't worked then did, and some that had worked didn't. I'll bear that in mind, though!

Quote:
If you can figure out the ZEXALL test bitmasks, and can run a modified version on hardware, you can use that to narrow down your search to the failing opcodes.
I had done this to isolate which flag was being set incorrectly, but comparing the "wrong" checksum alongside one from an emulator. The real problem is that the only instruction group that fails - aluop b,c,d,e,h,l,(hl),a - takes the longest to test.

I'm currently using the state-leak free version of ZEXALL, maybe a leaky one would start reporting errors earlier.

Quote:
Or, you might try running alongside another emulator (that supports debugging) and trying to step through (maybe a frame at a time) until the running CRC differs.
I've tried this; Emukon can export a debug log, a chunky text file logging the status of all registers before each instruction is executed. Unfortunately, Emukon's debugger sometimes prints values as being two away from what they should be - at least, according to Meka and a hex editor - so this doesn't work too well. Slight differences in timing (for interrupts and so on) also put this testing out of synch.

I just remembered that none of the autocopy instructions perform the autocopy; I'm not sure if many pieces of SMS software use them, but that would muck things up quite seriously.

Share this comment


Link to comment
ZEXALL works by self-modifying code that is operating on data in a small chunk of memory. After every iteration (or maybe every outer iteration) it dumps the registers to RAM and passes it all into a CRC32 routine. At the end it compares the cumulative result to a stored "correct" value. Thus, it will always complete a test before showing an error.

Thus, there are a few options for debugging through it more quickly:

1. Replace CRC32 with a faster checksum. Adler32 might be a good option, if you can think of a good way to avoid overflowing 16 bits.
2. Figure out where in RAM the CRC is stored and try stepping through in large chunks of cycles (eg. 1 frame = 59736 cycles) alongside another emulator, until the CRCs differ; then do it again and only step through n-1 frames. Rather dependent on trusting the two emulators to execute exactly the same number of cycles and to have correct instruction timing.
3. Get a faster computer :)

Others have reported success by simply restricting the test range to effectively binary search for the first point of failure, although I admit that's not the easiest thing to do. Do you have ZEXALL compiling under Brass yet?

Share this comment


Link to comment
All good ideas, but it gets stranger; I pass another version of ZEXDOC, but not the SMS/SDSC port. I don't handle the undocumented flags properly yet, so can't really run ZEXALL. There's more likely a bug in the way some instructions are handled (that isn't related to the results of an instruction); my first implementation of DJNZ looped when B was zero and EXX ended up swapping everything via BC, yet some programs ran (including SDSC ZEXALL).
Quote:
Original post by MaximZhao
Others have reported success by simply restricting the test range to effectively binary search for the first point of failure, although I admit that's not the easiest thing to do. Do you have ZEXALL compiling under Brass yet?
I'm using WLA-DX.

I think at this point it's probably easier to test against other software - Bock's Birthday 2004 gets as far as difficulty selection, and when you pick one it appears to disable the cartridge and crashes; something as repeatable as that should be easily testable by stepping through what happens in a comparison emulator.

Thanks for the ideas, though. [smile]

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now