RSS
Website| Wednesday, December 6, 2006 |
  New Z80 emulator | ||
Posted - 12/6/2006 7:08:02 AM | ||
 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. | ||
|
Comments
|
Journal of benryves | |
 | MaximZhao
Member since: 11/22/2006 From: London | |||
Posted - 12/6/2006 7:35:23 AM | ||||
| 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. | ||||
| ||||
 | benryves GDNet+
Member since: 9/4/2003 From: Purley, Greater London | |||
|
Posted - 12/6/2006 8:07:16 AM | ||||
Quote: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: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: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. | ||||
| ||||
| MaximZhao
Member since: 11/22/2006 From: London | |||
|
Posted - 12/7/2006 4:23:30 AM | ||||
| 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? | ||||
| ||||
| benryves GDNet+
Member since: 9/4/2003 From: Purley, Greater London | |||
Posted - 12/7/2006 5:50:15 AM | ||||
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: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.  | ||||
| ||||
| |
All times are ET (US) | |
| S | M | T | W | T | F | S |
1 | 2 | 3 | 4 | |||
6 | 7 | 8 | 9 | 10 | 11 | |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 |
OPTIONS
Track this Journal
ARCHIVES
September, 2010
August, 2010
July, 2010
June, 2010
April, 2010
March, 2010
February, 2010
January, 2010
December, 2009
November, 2009
October, 2009
August, 2009
June, 2009
May, 2009
March, 2009
February, 2009
January, 2009
December, 2008
November, 2008
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
May, 2007
April, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
September, 2005
August, 2005
April, 2005
February, 2005
January, 2005