 No.03316
Mamesick Senior Tester
Dec 16, 2008, 11:01
|
With the debugger and the error log window you can see a bunch of warnings about illegal opcodes when the game freezes. Is this caused by something wrong in the pointer-ization of M6809 happened in 0.128u4? |
|---|---|
 No.03318
Haze Senior Tester
Dec 16, 2008, 12:02
edited on: Dec 16, 2008, 12:02
|
IIRC the game needs pretty heavy CPU sync, have you tested to see if it just needs a much higher interleave level now? there are various hacks to work around this.. 172 static WRITE8_HANDLER( xain_sharedram_w ) 173 { 174 /* locations 003d and 003e are used as a semaphores between CPU A and B, */ 175 /* so let's resync every time they are changed to avoid deadlocks */ 176 if ((offset == 0x003d || offset == 0x003e) 177 && xain_sharedram[offset] != data) 178 cpuexec_boost_interleave(space->machine, attotime_zero, ATTOTIME_IN_USEC(20)); 179 xain_sharedram[offset] = data; 180 } (and the following comment) 128 Xain has a semi-bug that shows up in MAME - at 0xa26b there is a tight 129 loop that checks for the VBLANK input bit going high. However at the 130 start of a game the VBLANK interrupt routine doesn't return before 131 the VBLANK input bit goes low (VBLANK is held high for 8 scanlines only). 132 This would cause the emulation to hang, but it would work on the real 133 board because the instruction currently being decoded would finish 134 before the NMI was taken, so the VBLANK bit and NMI are not actually 135 exactly synchronised in practice. This is currently hacked in MAME 136 by raising the VBLANK bit a scanline early. chances are something broke with these... hacks are bad... |
|
No.03319
Mamesick Senior Tester
Dec 16, 2008, 18:56
|
I tried what you suggested. An high interleave value (1000 like in double dragon) doesn't fix the issue. A more "correct" interrupts implementation doesn't fix anything. The cpu boost interleave hack is necessary to boot the game, apparently. The game still encounters illegal instructions and freezes. |
|
No.03320
Haze Senior Tester
Dec 17, 2008, 07:30
|
well 1000 isn't actually very high, nowhere near perfect sync. that said, if it doesn't boot at all without those hacks, it could be a different issue, yes. |
|
No.03321
robiza Developer
Dec 17, 2008, 14:31
|
and a higher value of ATTOTIME_IN_USEC(20)? |
|
No.03322
Mamesick Senior Tester
Dec 17, 2008, 15:37
|
Already tried USEC(50) and USEC(100). Nothing changes. I also converted the driver to be fully scanlines based (using timers) hoping there was something wrong with interrupts.... no luck in this case too. |
|
No.03357
Mamesick Senior Tester
Dec 22, 2008, 17:41
|
I think I fixed it properly. It was a ROM banking issue. Though, is the game supposed to have slowdown when there are a lot of objects on the screen? I guess yes but since I converted the driver to be fully scanlines based I'd like to be sure. |
|
No.03358
Haze Senior Tester
Dec 22, 2008, 19:08
|
it's a game people have always complained is 'slow' and i believed somebody to have verified as correct. |
 No.03437
aaron Developer
Dec 30, 2008, 17:00
|
I went ahead and made this one run at "perfect" interleave. I don't see any issues once this is set, though a more thorough playthrough would be good. Marking resolved for now (I think Mamesick's banking fixes are responsible for the original issue). |