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?
// fade out
// disable rendering
// dma new tiles in
VDP_loadTileSet(&blah, blah, 1);
VDP_waitDMACompletion();
// write new tile map
for (y = 0; y < 28; y++) {
for (x = 0; x < 40; x++, i++) {
VDP_setTileMapXY(PLAN_B, attr, x, y);
}
}
// enable rendering
// fade in
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.
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).
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 ?
HELP. Spanish TVs are brain washing people to be hostile to me.
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.
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.
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.
