Tänzer, a "ninja" game (Dev Diary thread)

[mix256]

Turns out that the original ROM I sent behaves the same for notaz. So it's not a problem with the ROM being burnt or a cart issue.
Anyone have any suggestions here? Would be highly welcome!

In the video one can see that the graphics for the spinning sword is corrupt. This can be seen jut before the bkg layer tiles are filled with wrong data. Either a faulty DMA transfer is made over the tiles or over the tileset data.
I thought first it was during an overload situation but since the sword gfx is already corrupt it can't really be that.
And also, I can see now, the sword gfx are corrupt for both swords. And those swords have individual DMA transfers (ordinary SGDK addSprite) which means that both DMA transfers get corrupt data from the ROM.

I'm at loss here at what to do here.

[Stef]

What you can try is to turn these flags ON (set 1) into SGDK config.h file :

Code: Select all

#define HALT_Z80_ON_DMA     1
#define HALT_Z80_ON_IO      1

Recompile the library, then your game and test the new ROM to see if it makes any difference.

[mix256]

Thanks Stef!
HALT_Z80_ON_DMA is already in there, so could the halt on IO fix this? I will try that when I get home and send notaz a test-ROM.

[notaz]

In the video one can see that the graphics for the spinning sword is corrupt.

Hmm yeah in seems without addons it hangs completely just before the sword shows up, not when the bg corrupts with addons.

[Stef]

Thanks Stef!
HALT_Z80_ON_DMA is already in there, so could the halt on IO fix this? I will try that when I get home and send notaz a test-ROM.

Yeah the second can help too (but to be honest that is quite rare).

[mix256]

Ok, so I downloaded the latest SGDK and by god there was a lot of changes.
And to top it off, everything has became a complete corrupt mess. Sprites don't seem to work as all, for instance. Going to be a long, long night.

[mix256]

Seems like I need to rerun rescomp? But when I do I get lines like these:

Code: Select all

ending_bad_font_animation0_frame0_vflip_sprite9:
    dc.b    4
    dc.b    0
    dc.b    12
    dc.b    288

Yeah, that 288 won't fit into a byte.

Edit: Ah, I see, I get errors regarding this when doing rescomp. Well, it's going to be a loooong night.

[Chilly Willy]

Sounds like one of those "old MD1" problems. Certain older console revs seem to have issues that were later fixed. I've seen them talked about over on discord.

[Stef]

Ok, so I downloaded the latest SGDK and by god there was a lot of changes.
And to top it off, everything has became a complete corrupt mess. Sprites don't seem to work as all, for instance. Going to be a long, long night.

Oh you're using sources from repository ?!! You should be careful as repository can be in a "WIP" state, you really need to stick with the "release" packages normally to avoid issues. You may get everything working with the WIP SGDK (by doing full rebuild both for the library and your project) as i try to not put completely broken stuff but sometime it happen :-/ At least you should know the rescomp tool is now a java program so you need to have Java correctly installed on your computer (LZ4W compression was already using it before), also SPRITE resource specifications changed a bit (max supported sprite size is now 128x128 for instance, allowing to use byte offset to spare ROM space, before it was word offset).

[notaz]

So I was sent a build with HALT_Z80_ON_IO and it corrupts and hangs at the usual corruption spot.

I'm really curious what's going on and tried some ROM hacking.

• I've noticed that to start DMA, SGDK writes to reg23, reg21 and then the control word. Almost everything else writes to r23 as the last reg before control, so I tried hacking in a swap instruction before the move.l, verified it on the emulator -> no change on hardware.
• Tried adding busreq wait loop before the DMA (right now it lacks one, just writes and forgets) - still broken, but slightly differently I think.
• Replaced the instructions that do busreq before the DMA with nops (in a function that looks like DMA_queueDma) -> success! The demo loop runs without problems.

So I really don't know what to make of it - doing DMAs with busreq set is unsafe on this MD1?
Or my MD is broken, but I still haven't found anything else that is broken on this machine (well except the Overdrive2 effect using VDP debug reg, which is expected with some VDPs).

[mix256]

So I was sent a build with HALT_Z80_ON_IO and it corrupts and hangs at the usual corruption spot.

I'm really curious what's going on and tried some ROM hacking.

• I've noticed that to start DMA, SGDK writes to reg23, reg21 and then the control word. Almost everything else writes to r23 as the last reg before control, so I tried hacking in a swap instruction before the move.l, verified it on the emulator -> no change on hardware.
• Tried adding busreq wait loop before the DMA (right now it lacks one, just writes and forgets) - still broken, but slightly differently I think.
• Replaced the instructions that do busreq before the DMA with nops (in a function that looks like DMA_queueDma) -> success! The demo loop runs without problems.

So I really don't know what to make of it - doing DMAs with busreq set is unsafe on this MD1?
Or my MD is broken, but I still haven't found anything else that is broken on this machine (well except the Overdrive2 effect using VDP debug reg, which is expected with some VDPs).

Some serious hacking there!
Thanks for taking the time to get to the bottom of this!
So, do I understand this right that if I turn off "halt z80 on DMA" it will work on your MD? Because I think the bus req is coming from that flag, isn't is Stef?

(max supported sprite size is now 128x128 for instance, allowing to use byte offset to spare ROM space, before it was word offset).

It's the max width of the sprite image file as well? Seeing that the font sprite generation failed.
How much ROM is saved by setting this limit? Is is worth the extra complexity for the user?
I ended up just patching with the joy.c and config.h when sending the new version to notaz.

[Stef]

[*]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.

Replaced the instructions that do busreq before the DMA with nops (in a function that looks like DMA_queueDma) -> success! The demo loop runs without problems.

So I really don't know what to make of it - doing DMAs with busreq set is unsafe on this MD1?
Or my MD is broken, but I still haven't found anything else that is broken on this machine (well except the Overdrive2 effect using VDP debug reg, which is expected with some VDPs).

O_o ??? Well done in finding that ! But i definitely don't understand why this happen
I think that may be caused by the way i'm taking the Z80 BUS or maybe the way i'm setting the DMA. It's true that most game enable DMA on VDP only when doing the DMA but SGDK let DMA bit always enabled (i never observed issue with that). Could that be the reason ?
Anyway nice finding ! I hope we will find you the source of the issue..

[Stef]

So, do I understand this right that if I turn off "halt z80 on DMA" it will work on your MD? Because I think the bus req is coming from that flag, isn't is Stef?

Yeah, from what i understand that should fix the issue, but normally we do the opposite

It's the max width of the sprite image file as well? Seeing that the font sprite generation failed.
How much ROM is saved by setting this limit? Is is worth the extra complexity for the user?
I ended up just patching with the joy.c and config.h when sending the new version to notaz.

It's just the maximum size for 1 sprite cell (meaning sprite size itself is limited to 128x128 and/or 16 internal hard sprites max).
If you have many sprites then the gain can be important on ROM space as i generate many of these VDP sprite offset structures (i generate them for normal, hflip, vflip and hvflip version). I agree that bring a bit of complexity (need to split sprite which are over 128px size).

[mix256]

Awesome! I'll send you notaz a version with that flag off. And if you're satisfied with it I'll burn you a special cart.

It's just the maximum size for 1 sprite cell (meaning sprite size itself is limited to 128x128 and/or 16 internal hard sprites max).

But what is this then? Each of the sprite frames here are 1x1 tiles, where's the 288 coming from?

Code: Select all

ending_bad_font_animation0_frame0_vflip_sprite9:
    dc.b    4
    dc.b    0
    dc.b    12
    dc.b    288

[Stef]

that's a bug
it's said it found 4 tiles here (4x1 sprite) and so the X coordinate look like it was -32 wrongly encoded.
I wonder how this happened (rescomp tool made a mistake here). Can i have your input SPRITE resource definition with the used source image to make some tests ?