SpritesMind.Net

Someone sent a video of a rom misbehaving on Tectoy's (latest) clone. It looks like DMA writes to VRAM apply correctly, but those done via the fifo/cpu interface have a massive delay. I can't find anything on this in google. Have any of you hit this?
Everything is written during forced blanking. It works correctly on all emulators and on genuine Sega hardware. On Tectoy's, the DMA'd tiles show correctly, but the tile map updates only appear after 60 frames/one second of writing them. That is, for the duration of the fade (half a sec) and half a sec afterwards, the new tiles are shown with the old tilemap.

The new tilemap data snaps in entirely during one frame, as if the fifo was massive, but I can't think of any reason for the delay.

Looking into "why then", there is a DMA update exactly 30 frames after the fade in (partial frame for animation, so it does not update everything). So it appears their clone buffers all cpu vram writes made during blanking, and only syncs them upon a sync point.

I'd like to find out what things it considers sync points, and what happens with cpu writes made with rendering on (in vblank or not). Anyone have such a device and a flashcart?

Miniplanets will eventually crash randomly after playing for a while (you won't make it further than a few miniplanets before it crashes). Nobody knows why, and it never happens on any real console.

So huh, I'd just say to lose all hope on this because this hardware makes no sense at all.

There is inside the vpd enough memory for storing 30/40 shorts (2bytes) for several frames? No.
So it must be a program issue, then.

The clone may be caching stuff for its own purposes, though. It's not real hardware (which doesn't exhibit this issue).

Actually wait, kind of confused when I try to read: the DMA'd data is transferred immediately, but not the data written manually? I wouldn't be surprised if it's stuck at VDP_waitDMACompletion() in that case. Probably the DMA flag is being reported incorrectly and it went overlooked since there's no reason to wait after a DMA transfer as the 68000 gets halted (only DMA fill and copy need you to wait for it).

the DMA'd data is transferred immediately, but not the data written manually

Exactly.

The program is not stuck, since the fade happened, and the program flow continued.

Oh right forgot about the fade.

OK I give up. The clone is just that trash.

ups! my mistake, is one of those "console on a chip" machines.
Knowing that you can purchase an original machine for next to nothing, is there a reason to bother ?

Distribution on the Brazilian market, since they are more common there.

Do you know how Brasilian video game marked works? Is like back to the spectrum era.

As in wide piracy? Sure, but it doesn't tend to spread, and more sales are more sales. I don't count piracy as a loss for someone who wouldn't have bought in the first place either, that'd be free advertising.

Tried a few workarounds, nothing worked. Still, that does rule out some things, like sane chip design

- read the vram after writing it
- DMA write one tile
- DMA write a few tiles
- DMA queue one tile
- draw an invisible sprite

Whatever they were smoking, it must be good stuff.

Just a suggestion - maybe waiting until the vblank to re-enable the video after the DMA. Another thought - do another (small) DMA operation after the video is turned on. Whatever the issue is, it's really weird.

The DMA queue operation happens after rendering is on, so that one was tried already.

One of the bug i had with SGDK is that the MD Tectoy requires the 68000 requesting Z80 BUS before issuing DMA otherwise you have great luck to have lot of bugs with your DMA transfer, i specifically added a flag in SGDK for that behavior... Note that it does that for game that work from SD card as memory timing are different in that case, so games working from cart port shouldn't have issues here.