Super VDP

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

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

Post by Chilly Willy » Tue Oct 28, 2014 7:35 pm

You need to either avoid using the 68K->SH2 "DMA" channel, or add error detection to it as it's buggy. Real games that use the 68K->SH2 DMA do retries for when the transfer fails. My own experiments have shown it's really damn buggy. I go with a processor polled exchange of data through the communication registers instead.

Redesigning the software might be better. Instead of transferring the data from the 68000 side, perhaps it might be stuck into the 32X framebuffer instead. Have code to manage the frame buffer memory, allocated space for the tiles and tile map, fill it from the 68000 or SH2, and then just send commands to the SH2 side for things like scrolling and palette changes.

ehaliewicz
Very interested
Posts: 50
Joined: Tue Dec 24, 2013 1:00 am

Post by ehaliewicz » Wed Oct 29, 2014 3:33 pm

Chilly Willy wrote:You need to either avoid using the 68K->SH2 "DMA" channel, or add error detection to it as it's buggy. Real games that use the 68K->SH2 DMA do retries for when the transfer fails. My own experiments have shown it's really damn buggy. I go with a processor polled exchange of data through the communication registers instead.

Redesigning the software might be better. Instead of transferring the data from the 68000 side, perhaps it might be stuck into the 32X framebuffer instead. Have code to manage the frame buffer memory, allocated space for the tiles and tile map, fill it from the 68000 or SH2, and then just send commands to the SH2 side for things like scrolling and palette changes.
Yeah, re-trying DMA requests sounds like a pain, but the second idea seems like it's worth a shot. I'll post results once I have time to try it out.

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

Post by Chilly Willy » Wed Oct 29, 2014 7:52 pm

I've thought about trying my hand at a SuperVDP implementation as well, but have been swamped with other things.

Anywho, there's two modes for the 68K->SH2 DMA channel in the 32X IO chip. The first mode is meant for carts, and uses the 68000 to store data to the FIFO to trigger DMA operations. This works somewhat... you need to keep lengths short (no more than a couple hundred bytes), checksum the data sent, use a timeout on SH2 DMA, and retry on checksum errors and timeouts. The second mode is meant for CD32X games, and uses a MD VDP DMA operation to read the CD word ram (when switched to the MD side); you set the VDP increment to 0 so that it doesn't actually write more than one word of vram. The 32X IO chip then recognizes the DMA read to trigger DMA operations. This doesn't work at all... Sega engineers couldn't get the timing right before time for the production run of the 32X chipset, so all you get is garbage. I suspect that in trying to get the timing for CD transfers to work, they slightly screwed up the timing for 68000 transfers, which is where the corruption comes from.

In any case, existing CD32X software uses the 68000 transfer as well since the mode meant for the CD doesn't work.

Post Reply