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.
What 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.
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.
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...
Since you will be getting a special build, with a ROM soldered by me to a different PCB, do you want it signed as well?
Speaking of special things. I've been refactoring the engine code (read: totally rewritten the whole god damn thing) for the last couple of weeks, since my next game will (most likely) be a shmup.
I've been thinking of converting Tänzer (not that much job) to it and doing a Black Label version. Even harder and with more enemy bullets and a slight change in the palettes.
(since the refactored engine can handle quite a bit more interactive-on-screen-objects)
Oh, that sounds quite interesting
By the way, dd you were able to fix your issues with the WIP SGDK or you reverted to older 1.34 build ? The WIP SGDK (if it working for you) should provide better performance when dealing with sprites as better ROM usage (you won't see a big gain but still you should see a difference ).
Stef wrote: Mon Apr 08, 2019 8:41 am
Oh, that sounds quite interesting
By the way, dd you were able to fix your issues with the WIP SGDK or you reverted to older 1.34 build ? The WIP SGDK (if it working for you) should provide better performance when dealing with sprites as better ROM usage (you won't see a big gain but still you should see a difference ).
I reverted and just lifted the joy.c and config.h from the master. But I've reverted that now as well.
There are a lot of sprites being bigger than 128px wide in Tänzer, so that game will never be lifted to the newer versions of SGDK. Would be too much work. But my next game will certainly use newer versions.
).