Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
02742 Crash/Freeze Critical (emulation) Always Dec 15, 2008, 18:56 Dec 30, 2008, 17:00
Tester LastNinja2 View Status Public Platform MAME (Official Binary)
Assigned To Mamesick Resolution Fixed OS Windows XP/Vista 32-bit
Status [?] Resolved Driver xain.cpp
Version 0.128u6 Fixed in Version 0.129 Build Normal
Fixed in Git Commit Github Pull Request #
Summary 02742: xsleena and clones: Game freezes
Description Game freezes immediately after landing on a random planet - usually within a couple seconds on the timer
Steps To Reproduce
Additional Information
Github Commit
Regression Version 0.128u4
Affected Sets / Systems xsleena and clones
Attached Files
There are no relationship linked to this issue.
User avatar
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?
User avatar
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...
User avatar
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.
User avatar
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.
User avatar
Dec 17, 2008, 14:31
and a higher value of ATTOTIME_IN_USEC(20)?
User avatar
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.
User avatar
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.
User avatar
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.
User avatar
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).