VDP_loadTileData CPU vs DMA differences?

SGDK only sub forum

Moderator: Stef

Post Reply
KillaMaaki
Very interested
Posts: 84
Joined: Sat Feb 28, 2015 9:22 pm

VDP_loadTileData CPU vs DMA differences?

Post by KillaMaaki » Sat Dec 22, 2018 7:51 am

So I'm back on my experimenting with MD homebrew bullshit :D

Trying to write some custom graphics handling routines to handle custom data blobs. Was having issues getting tilesets loaded in. This particular tileset has 293 unique tiles in it.

What I have is a pointer to the raw data as a u32*, the tile index in VRAM to store it at, and the number of tiles to store.
When I try and use the CPU mode of VDP_loadTileData, it only loads *some* tiles. It appears to just give up partway through.

Code: Select all

VDP_loadTileData( dataPtr, destVRAMIndex, numTiles, CPU );
Here's what I get:
Image

There's supposed to be way more tiles here, but it looks like it just gave up...?

BUT, if all I do is switch this over to DMA...

Code: Select all

VDP_loadTileData( dataPtr, destVRAMIndex, numTiles, DMA );
It works. The missing tiles are all here now.
Image

What gives? I mean I guess I can just use DMA but this seems kinda broken and I want to make sure there's no underlying issue I've caused that's going to bite me in the ass on hardware later (something that just switching to DMA is *hiding* rather than actually fixing)
I get the exact same results on every emulator I've tried this on (Gens KMod, Fusion, Regen, and Exodus). I also know for a fact that dataPtr is aligned on a 4 byte boundary for whatever that's worth.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: VDP_loadTileData CPU vs DMA differences?

Post by TmEE co.(TM) » Sat Dec 22, 2018 1:00 pm

DMA doesn't cross 128KByte boundaries but wraps around within 128KB block.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

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

Re: VDP_loadTileData CPU vs DMA differences?

Post by Stef » Sat Dec 22, 2018 5:12 pm

DMA methods in SGDK does take care of that so that should not be the issue.
I've to admit that i wonder what happen here, i need to investigate but it looks like DMA isn't completed when in CPU mode copy.

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

Re: VDP_loadTileData CPU vs DMA differences?

Post by Chilly Willy » Sun Dec 23, 2018 11:28 pm

Just by eye, it LOOKS like it's copying half the data. Maybe an issue about scaling for words/longs, and then not actually doing words/longs.

EDIT: That can't be it, the code just transfers 32 * num of tiles worth of data.

Code: Select all

    subq.w #1,%d3

.L6:
    move.l (%a0)+,(%a1)
    move.l (%a0)+,(%a1)
    move.l (%a0)+,(%a1)
    move.l (%a0)+,(%a1)
    move.l (%a0)+,(%a1)
    move.l (%a0)+,(%a1)
    move.l (%a0)+,(%a1)
    move.l (%a0)+,(%a1)
    dbra %d3,.L6
That's a weird one, all right.

EDIT 2: New theory - using DMA in vblank. The CPU transfer gets interrupted by the vblank which does its own transfer, leaving the cpu transfer in the wrong state to finish when the vblank is done.

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

Re: VDP_loadTileData CPU vs DMA differences?

Post by Stef » Wed Dec 26, 2018 5:08 pm

The software copy is ok, I would had meet many troubles in past with a wrong software implementation ;)
But yeah, the problem can be interrupt, DMA can't be interrupted while CPU copy can be.
Use try to use SYS_disableInts() / SYS_enableInts() around your tile loading method.
It'*s very important to always protect your VDP accesses from interruptions in the main methods as VInt handler from SGDK will also access to VDP and can corrupt yours.

KillaMaaki
Very interested
Posts: 84
Joined: Sat Feb 28, 2015 9:22 pm

Re: VDP_loadTileData CPU vs DMA differences?

Post by KillaMaaki » Wed Jan 02, 2019 12:31 am

Yep, I'm willing to bet that's what it was. Encountered a few areas where I was not disabling interrupts and it didn't bite me in the ass until today when the timing of some things changed just enough to blow up my DMA writes and corrupt entire sections of VRAM ;)

Post Reply