Tectoy's weird VDP behavior

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

cero
Very interested
Posts: 223
Joined: Mon Nov 30, 2015 1:55 pm

Tectoy's weird VDP behavior

Post by cero » Tue Oct 03, 2017 5:31 pm

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?

Code: Select all

// 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.

cero
Very interested
Posts: 223
Joined: Mon Nov 30, 2015 1:55 pm

Re: Tectoy's weird VDP behavior

Post by cero » Tue Oct 03, 2017 5:48 pm

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?

User avatar
Sik
Very interested
Posts: 688
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Tectoy's weird VDP behavior

Post by Sik » Tue Oct 03, 2017 10:24 pm

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.
Sik is pronounced as "seek", not as "sick".

Miquel
Very interested
Posts: 293
Joined: Sat Jul 30, 2016 12:33 am

Re: Tectoy's weird VDP behavior

Post by Miquel » Wed Oct 04, 2017 10:58 pm

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.

User avatar
Sik
Very interested
Posts: 688
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Tectoy's weird VDP behavior

Post by Sik » Thu Oct 05, 2017 2:10 am

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).
Sik is pronounced as "seek", not as "sick".

cero
Very interested
Posts: 223
Joined: Mon Nov 30, 2015 1:55 pm

Re: Tectoy's weird VDP behavior

Post by cero » Thu Oct 05, 2017 8:18 am

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.

User avatar
Sik
Very interested
Posts: 688
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Tectoy's weird VDP behavior

Post by Sik » Thu Oct 05, 2017 4:03 pm

Oh right forgot about the fade.

OK I give up. The clone is just that trash.
Sik is pronounced as "seek", not as "sick".

Miquel
Very interested
Posts: 293
Joined: Sat Jul 30, 2016 12:33 am

Re: Tectoy's weird VDP behavior

Post by Miquel » Thu Oct 05, 2017 9:28 pm

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 ?

cero
Very interested
Posts: 223
Joined: Mon Nov 30, 2015 1:55 pm

Re: Tectoy's weird VDP behavior

Post by cero » Fri Oct 06, 2017 8:29 am

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

Miquel
Very interested
Posts: 293
Joined: Sat Jul 30, 2016 12:33 am

Re: Tectoy's weird VDP behavior

Post by Miquel » Sun Oct 08, 2017 1:34 am

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

cero
Very interested
Posts: 223
Joined: Mon Nov 30, 2015 1:55 pm

Re: Tectoy's weird VDP behavior

Post by cero » Sun Oct 08, 2017 7:48 am

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.

cero
Very interested
Posts: 223
Joined: Mon Nov 30, 2015 1:55 pm

Re: Tectoy's weird VDP behavior

Post by cero » Mon Feb 19, 2018 6:56 pm

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.

Chilly Willy
Very interested
Posts: 2572
Joined: Fri Aug 17, 2007 9:33 pm

Re: Tectoy's weird VDP behavior

Post by Chilly Willy » Mon Feb 19, 2018 7:31 pm

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. :?

cero
Very interested
Posts: 223
Joined: Mon Nov 30, 2015 1:55 pm

Re: Tectoy's weird VDP behavior

Post by cero » Tue Feb 20, 2018 9:39 am

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

User avatar
Stef
Very interested
Posts: 2757
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Tectoy's weird VDP behavior

Post by Stef » Tue Feb 20, 2018 9:57 am

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest