|
Ok, after some break, i'm looking this issue again.
According to compatibility list and user feedback, it seems that this happens with each port of genesis plus (MAC, dreamcast also) so I think the problem is somewhere in the original code (please note that it occurs only in some particular games). Btw, softdev (who mades the original GC port) and I didn't modify these part of the code (i mean, busrequest mechanism , memory access handling, cpu core, etc).
Here's the portion of code which deals with BUSREQ mechanism, please tell me if you see something weird
In reply to:
int gen_busack_r (void) { return (zbusack & 1); }
void gen_busreq_w (int state) { zbusreq = (state & 1); zbusack = 1 ^ (zbusreq & zreset);
if (zbusreq == 0 && zreset == 1) { z80_execute (extraZ80cycles); } }
void gen_reset_w (int state) { zreset = (state & 1); zbusack = 1 ^ (zbusreq & zreset);
if (zreset == 0) { if (snd.enabled) { YM2612ResetChip (0); }
z80_reset (0); z80_set_irq_callback (z80_irq_callback); } }
After reading the well known Genesis Technical Doc, I have 2 questions about this:
1/ usually, it seems that after the 68K completed Z80 access, Z80 is reseted (zreset set to 0), the bus is released (zbusreq set to 0) and only THEN, the reset mechanism is stopped (zreset set to 1). S0, in this case, when busreq is set back to 0, reset has not been yet set to 1 and the few extra Z80 cycles are not executed (see the "gen_busreq_w" function)
Do you think that adding the z80 execution cycles when reset mechanism is stopped (zreset set back to 1), and only if z80 has the bus (zbusreq=0) will be more accurate ?
2/ in this doc, it is also written that:
CONFIRMATION OF BUS STATUS This information is in $A11100 bit 0 0 - Z80 is using 1 - 68K can access
However, in this code (and in most emulator code i checked), we return 0 when bus can be acceded (zbusreq=1 and zreset=1 => zbusack = 0)
Did I miss something somewhere ?
EDIT: ok, for this last one, i found that sega published some correction note (known as Technical Bulletin ) to correct this
|