What is max bandwidth for DMA to VRAM in HBL?

[greatkreator]

What is max bandwidth for DMA to VRAM in HBL?

Has anyone tried to transfer anything to VRAM using DMA in HBL area while the screen is off?
I have tried a bit and it seems that bandwidth is lower than expected.
For example DMA to CRAM transfers 48 colors per the same time period and the same DMA code.
But DMA to VRAM is able only to transfer 32 bytes however 48 bytes were expected.

[Sik]

VRAM transfers one byte per slot, CRAM and VSRAM transfer one word (two bytes) per slot. So yeah, loading stuff to VRAM is twice as slow. (this is true in vblank as well, mind you!)

[greatkreator]

Yes I know. You are right.
But CRAM 48 colors != VRAM 32 bytes. I hoped to have 48 bytes.

Maybe something hidden in HBL steals VRAM bandwidth (and doesn't touch CRAM bandwidth)?

[Sik]

First of all I'd like to know how you get 48 colors in hblank when a single scanline (in active scan) only has 18 slots at most (and nearly all of them are in the visible portion of screen, not in hblank). Or is it over multiple scanlines? (in this case, maybe your real issue is overhead from the 68000 code and nothing to do with the VDP - meaning you're missing out on several slots)

[greatkreator]

1. Write effective asm.
2. In the visible part prepare a DMA call.
3. At some right point turn the screen off and start the prepared DMA.
4. At some left point on the next scan line turn the screen on.

Turning the screen off increases DMA bandwidth to its max value.

I do the same for DMA transfer to VRAM and it works 1.5 times slower than could by my expectations.

[Stef]

48 colors during HBlank even with by disabling Screen is *a lot* but might be achievable, still doing that you lost many sprites...
However you are right, you should be able to achieve 48 bytes of VRAM transfered then, i have no idea why you observe different results here.

[greatkreator]

Do you have any assumptions what can it be?
All the interruptions are turned off.
Maybe some VDP activity in HBLANK?

[Stef]

Normally you have VDP activity but as you are disabling VDP before HBlank it should also turn off VDP activity.
Maybe a part of the activity remains... for instance it looks like the HScroll values are fetched during HBlank period, still even if you disable the VDP the HScroll values appears to always be correctly fetched (hopefully ^^) ! So that definitely means some VDP activities remains (and by that i mean some internals VRAM accesses) when you disable it during the active period and that explain why you have lower transfer capabilities on it.

[Sik]

48 colors during HBlank even with by disabling Screen is *a lot* but might be achievable

It's not, the limit is 23 before you run into the visible area (we confirmed this while developing the 512 colors screen in Overdrive).

Of course transferring that much also leaves you completely sprite-less. Overdrive changes 16 colors per line in this screen, leaving about 30 sprites (more or less depending on the exact timing). This is also why that screen is a good way to test how accurate an emulator is or whether a clone is based on the original hardware (too few sprites makes the scroller go missing, too many sprites makes the "YOUR EMU SUXX" message show up - amusingly some otherwise rather good clones end up showing that message, I wonder how they handle their bandwidth o_o).

EDIT: also thinking some more about it

for instance it looks like the HScroll values are fetched during HBlank period, still even if you disable the VDP the HScroll values appears to always be correctly fetched (hopefully ^^) !

Or it could be just reusing the last value it fetched and you wouldn't notice unless some serious linescrolling is going on.

Going to look into this... I know for a fact that Overdrive disables display before hblank even starts (yes, during visible area). This works on real hardware because display only gets disabled at the next 16 pixel column, but for whatever reason the TCT-6705 configuration used in the Mega 3 causes video output to become black during blanking period (probably to remove the border color) and this seems to have pixel granurality so you can actually see display getting disabled a few pixels early at the right of the screen. It's the only difference Mega 3 has from Sega's hardware when running Overdrive.

EDIT 2: right, Overdrive also reenables display while still in the hblank period (even if rather late) so technically the VDP could just be fetching hscroll right when display gets reenabled.

[Stef]

It's not, the limit is 23 before you run into the visible area (we confirmed this while developing the 512 colors screen in Overdrive).

Well i didn't meant HBlank exactly, my fault, i meant outside active period which is quite different.
I guess greatkreator is using the whole interval from last visible pixel (pixel 319) to first visible on next line (pixel 0) to transfer as much color it can. In this case i think 48 colors is doable.. and actually he did it
I think doing that result in some colors artifacts into border though...

Or it could be just reusing the last value it fetched and you wouldn't notice unless some serious linescrolling is going on.

Indeed it could cache the last HScroll value, that would be a good test to do... use a line scrolled plan and see if disabling the VDP during the whole H inactive period (everything outside the 320 pixel region) affect something else aside sprites.

Going to look into this... I know for a fact that Overdrive disables display before hblank even starts (yes, during visible area). This works on real hardware because display only gets disabled at the next 16 pixel column, but for whatever reason the TCT-6705 configuration used in the Mega 3 causes video output to become black during blanking period (probably to remove the border color) and this seems to have pixel granurality so you can actually see display getting disabled a few pixels early at the right of the screen. It's the only difference Mega 3 has from Sega's hardware when running Overdrive.

Yeah some games does it, Mickey Mania is doing that in the Moose Hunters pursuit stage. It uses HV counter to disable VDP and trigger DMA before HBlank period actually start... and i think that is not a big deal, it's just affecting sprites, at least from what we know

EDIT 2: right, Overdrive also reenables display while still in the hblank period (even if rather late) so technically the VDP could just be fetching hscroll right when display gets reenabled.

Some reasons to re-enables it that soon ? To preserve enough sprite maybe ?

[Sik]

Welp, forgot that the textured twister code is doing exactly the same thing as the 512 colors screen and that one linescrolls like a mofo. Either hscroll gets fetched the moment display is reenabled or there's something else going on =P I assume it's perfectly possible for the timings to get shifted by disabling display because otherwise it'd expect sprites from the beginning of the table to go missing (or the whole table to break), not sprites from the end as if it had just shrunk it.

Some reasons to re-enables it that soon ?

Because it's done loading the colors for that line and there's no point in keeping it turned off =P (the idea of also showing sprites came later)

EDIT: in hindsight, you also want to avoid reenabling display too late because otherwise you risk breaking the first column of the tilemap planes as well (as they get fetched 16 pixels early). But maybe that just results in the whole leftmost column remaining disabled? (remember, the display enable bit takes effect every 16 pixels)