Stef wrote:AamirM wrote:notaz wrote:
I can confirm original Musashi handles all 3 cases correctly (i.e. the way docs say).
Don't know how you got this idea, but I've looked at this too, and it surely doesn't do trace. In fact, I haven't encountered any game which would do that.
Hi,
Yes, no trace. I was going in the wrong direction. Still haven't figured out the correct solution. I have very less time these days.
stay safe,
AamirM
Don't search on 68000 core, problem is timing and specially interrupts timings. I spent *many* time with them on Gens. I adjusted them probably more than hundred time, a single cycle can fix more 1 or 2 games but break 3 others :-/ Today i know my timings are almost completly wrong, i had just luck with all my adjustements and fudges...
I think I figured out this one (Pacman 2's pause bug):
it is indeed a timing issue, more precisely a VINT timing issue:
when you hit START button, the following subroutine ($50158 if you want to look in the disassembled code) will execute, approx. at the middle of
line 237.
This routine does the followiing:
1/ request Z80 bus and cancel Z80 reset
2/ fill up ZRAM from $A01000 to $A01FFF
3/ modify Z80 data from $A00000 to $A04AC (Z80 program ?)
4/ reset Z80, release Z80 BUS then cancel Z80 reset (Z80 restarts)
5/ reset $FFC000-$FFC4AA WRAM area (datas used later)
6/ once it is done, set $FFC016-$FFC018 with a particular ROM address (used later in the program)
This routines takes quite a long time (quite a whole frame) and will obviously be interrupted by VINT on line 224 of the next frame.
When this happens, 2 issues could occurs:
(a) if VINT triggers between part 5) and part 6), sound issues happens: indeed, the ROM address stored in $FFC016-$FFC018 is read by VINT for later use. If this address is still 0, bad data wil be read later, this will end up in messing some other flags, and finally shut off sound output (one of the messed flag is polled by the z80 in his sound routine)
(b) if VINT triggers between part 1) and part 4), another problem occurs. Indeed, VINT also want to access Z80 bus to write into ZRAM and so, will request access to the bus. Once it's done, it will (as usual) release the bus ... but when the main routine returns to his execution, all further Z80 RAM writes will failed since the bus has been released by the VINT callback.
This issue is described in one of the Sega Tech Bulletins, where they advised to disabled interrupts before accessing Z80 from the main loop, which this game obviously does not. Strangely, this ends up in a corrupted Z80 RAM but did NOT shut of sound output as above.
Now:
. issue (a) is what happen in all emulators when using common timings.
. if, like AamirM originally did, you increase the number of cycles used by the dbf instruction , the several write loops inside the subroutine will be delayed , VINT will be triggered sooner during the execution and issue (b) will occur. However, as explained, this does not shut off sound output as in issue (a), giving the impression you fixed the problem, which you haven't. Anyway, the dbf instruction timing are correctly handled by the 68000 core so this is not the correct solution.
. modifying the timing occurence of VINT on line 224 by some cycles does not work though, because VINT will still trigger during WRAM initialization (the loop takes approx. 0x4AA / 4 * 22 cycles = 6556 cyles = 13 lines to fully initialize the $FFC000-$FFC4AA area)
.a viable solution would be that the subroutine started a few lines earlier but I didn't find any way to do that. It starts at line 237 whatever you do with instruction timings.
The solution that I found is to add one cycle delay each time the 68000 access the Z80 RAM.
Indeed, I imagined that there could be some kind of bus latency in this case since this is not a "direct" access (z80 bus data is "copied" somehow on 68k data bus through the IO chip)...
I don't know if it is correct from a hardware point of view (please tell me if i'm wrong) but this makes the timings perfecly fit together, Z80 ram is not corrupted and sound output does not stop after pause.
quite a long post for a small problem but this bugged me for some time and found better to write everything down here
I've succeeded improving performance ~5-10% for all games, just need to do some more polishing before release.
Should have a working OSx86 install soon. 
. Hopefully I will get some free time soon. Comments on port are welcomed.