Messing with busreq code changes how the corruption looks like and whether the corruption place also hangs, or does it continue like in the video. For example, if I replace the z80 un-reset write with nops (your original busreq code first writes to busreq and additionally to the reset register), the corruption starts to look different. But it looks quite consistent on multiple runs of the same ROM.Stef wrote: Fri Apr 05, 2019 8:33 amWhat you mean by different ? It's true that i don't wait for BUS to be taken because normally the operation is fast (require 2 or 3 68000 at max) and the BUS should be taken when DMA actually start.notaz wrote: Thu Apr 04, 2019 10:54 pm Tried adding busreq wait loop before the DMA (right now it lacks one, just writes and forgets) - still broken, but slightly differently I think.
I don't know, maybe these changes allow z80 to run less or more and hides some real issue that happens elsewhere. It would be interesting to try with z80 driver that doesn't do anything, but it requires more hacking because SGDK waits for the sound driver to respond. In general I don't see anything unusual going on with the game on an emulator...