DMA transfer to CRAM visible however the screen is off.

[greatkreator]

I turn off the screen.
Then do a DMA transfer to CRAM.
And I see artifacts on the screen.
Why it happens? Is it possible to fix?
I thought if the screen is off then nothing must be visible.

[Mask of Destiny]

When the screen is off the VDP just displays the background color. The background color is in CRAM. The VDP has no functionality to avoid access conflicts between "external" accesses to CRAM like DMA and reads for display output. Whenever the VDP attempts to fetch a color at the same time that one is being written, the color being written gets displayed rather than the intended color. If you want to update CRAM without it being shown on screen you need to do the update during a period in which CRAM is not used (i.e. vertical and horizontal blanking intervals)

[greatkreator]

I guessed that it was so but thanks a lot Mask of Destiny for the confirmation!
I just hoped that there maybe would be any trick to overcome that.

I wanted to turn off one per two scanlines and reload a full set of new 64 colors for each 2 scanlines but unfortunately there was too much CRAM artifacts.
Before that I implemented CRAM reload in HBLANK and mistakenly had decided that it's possible to reload CRAM colour using DMA without the artifacts.
I thought I was doing something wrong but as you confirmed now I see that it's just impossible.

Anyway I had another application for my idea by using only 1 scanline of each 2.

[TmEE co.(TM)]

You can load around 1 palette each line with artifacts staying offscreen, but you need very well timed code.
Get a Hint, wait until the next line because it is already too late when your code runs and while waiting set up DMA and other stuff and when you reach end of line blank display and trigger DMA. You will lose most of the sprites for that line because sprite processing doesn't happen when display is being blanked. Blanking is necessary to get the needed VRAM bandwidth (one write every two pixels rather than every 16 or 32.

[greatkreator]

Thanks TmEE co.(TM)!

Already done! Currently 15 colors are transferred per a scanline (with not substantial artifacts at the borders of the screen).
I hope it will be enough for my purposes.

[LocalH]

A possible idea I had one time (but never implemented) was to "overlap" color changes. What I mean is, group together each set of two scanlines, and change half the colors per line (8 per line should be fairly easy from what I understand, although I'm a little rusty and my knoledge is a bit outdated). So, for example, assuming palette line 1:

First scanline - change colors $10-$17
Second scanline - change colors $18-$1F

Set VDP$07 to $10 so that you can actually make use of that entry, and design your pattern data properly, and you get 8 new colos per line, but also 8 common colors with the scanline above. Especially when using composite video (or RGB with very low sharpness), should at least be able to use up to the base 512 colors on one screen depending on the artwork, without using the direct color technique. Of course, direct color is the only way to get over 100 colors on a scanline

[Mask of Destiny]

A possible idea I had one time (but never implemented) was to "overlap" color changes. What I mean is, group together each set of two scanlines, and change half the colors per line (8 per line should be fairly easy from what I understand, although I'm a little rusty and my knoledge is a bit outdated). So, for example, assuming palette line 1:

I seem to remember experimenting with this at some point, but I can't seem to find an example anymore. My vague recollection is that there was an improvement, but it was not very noticeable with the images I was testing with.

Of course, direct color is the only way to get over 100 colors on a scanline

I have yet to find an image that looks better with direct color DMA than with 8 static colors + 8 colors replaced per scanline. I mean, it's easy enough to generate such an image I suppose, but if you just take a random photograph, the resolution loss looks way worse than the color loss.

As an example this source image:

Looks like this with direct color DMA:

And like this with 8 static + 8 replaced per line


I imagine the difference would be even greater if I had bothered to implement dithering. The one thing direct color DMA has going for it is you don't have to worry about DMA bandwidth constraints. In practice though it's hard to use either for anything other than still images, except perhaps on the Sega CD, so that limitation is not a big deal.

[LocalH]

I have yet to find an image that looks better with direct color DMA than with 8 static colors + 8 colors replaced per scanline. I mean, it's easy enough to generate such an image I suppose, but if you just take a random photograph, the resolution loss looks way worse than the color loss.

The best type of artwork for that would be the type of stuff seen in the IBM 5150 demo "8088 MPH" which uses CGA artifact color to generate over 1000 colors on the composite output.

[Mask of Destiny]

The best type of artwork for that would be the type of stuff seen in the IBM 5150 demo "8088 MPH" which uses CGA artifact color to generate over 1000 colors on the composite output.

Here's the 1K grafiti image
Direct color:

8 static + 8 dynamic


And here's the flower girl image
Direct color:

8 static + 8 dynamic


There's some minor color loss with 8+8 and since the images were already quite low-res you don't really lose anything with direct color, but I don't think they do a good job of selling the technique. Don't get me wrong. Direct color DMA is a really neat hack and it's certainly possible to create an image that looks great with direct color, but would look like crap with 8+8. It's just not advantageous for "typical" images.

[matteus]

I don't fully understand the magic behind this. Are you essentially having to up-scale the image by doubling the horizontal rows due to the limitations of DMA per line?

[Mask of Destiny]

Direct color DMA is a clever hack (discovered by Oerg866 IIRC) that effectively gives you a low-res bitmap mode by abusing DMA to CRAM. The DMA engine can copy one word to CRAM for every 2 pixels (except for during VRAM refresh, which is why you see some weird doubling). So if you sync the 68K to the VDP by filling the FIFO, disable the display and then start a long DMA to the background color entry in CRAM with auto-inc of 0 (so that all writes to go the background color), you can get a stable picture at roughly half horizontal resolution with no restriction on colors outside the palette entries being 9-bit.

The 8+8 images are just using standard per-line color replacement, but turn off the display to free up DMA bandwidth at the expense of sprite rendering.

[LocalH]

Direct color DMA is a clever hack (discovered by Oerg866 IIRC) that effectively gives you a low-res bitmap mode by abusing DMA to CRAM. The DMA engine can copy one word to CRAM for every 2 pixels (except for during VRAM refresh, which is why you see some weird doubling). So if you sync the 68K to the VDP by filling the FIFO, disable the display and then start a long DMA to the background color entry in CRAM with auto-inc of 0 (so that all writes to go the background color), you can get a stable picture at roughly half horizontal resolution with no restriction on colors outside the palette entries being 9-bit.

The 8+8 images are just using standard per-line color replacement, but turn off the display to free up DMA bandwidth at the expense of sprite rendering.

It should also be possible to double ROM usage over the normal direct color technique and switch between two data tables on each frame, adding color interlacing (as seen on the C64) to make use of blended colors. It would be especially nice if one could delay the DMA start by half of the "DMA clock" (in other words, half of a direct color "pixel") to gain similar resolution increase to the related C64 technique of shifting the screen back and forth one hires pixel when using multicolor (double-wide) pixels to increase apparent resolution and add a bit of natural horizontal blending (for even further color increase, with appropriate image data). I think the pixel shifting won't work though because of the existing pixel doubling problem. I think at best, even if one is successful at delaying the start of DMA by that small amount, the shift will be negated at the first DMA interruption.

I really wish it were possible to DMA to VDP registers. If that were the case, it would be possible to use a similar trick, be limited to 64 colors, but there would be no need to worry about pixel doubling due to VRAM refresh (as to the best of my knowledge, VDP$07 takes effct immediately, and completely independently of VDP RAM access, but I've never tried to test it in lockstep). It would also be nice if it were possible to disable VRAM or VDP RAM refresh - since the value in CRAM for the chosen backdrop color is only needed for the length of one word's DMA transfer, refresh seems kinda pointless within the context of direct color.

Anyone ever figure out if it's possible to use DMA to copy from VRAM to CRAM? If it were, then I wonder if that would make sense. Set VDP$0F to 0 as with normal direct color, but write the data to CRAM instead of VRAM. What made me think oftis (possibly useless) idea was reading through Charles' old VDP document:

In the case of a VRAM fill, the CD2-CD0 bits are set to the same value
required for a VRAM write. In the same vein, VRAM copies have the code
bits set to the same setting as a VRAM read. Maybe changing the code
register would allow copies within CRAM and VSRAM? Or perhaps the code
bits only select the source address? (Not that a CRAM > VRAM copy is
particularly useful, but there you go.)

Just trying to use unconventional thinking to eke (heh) more out of the MD. I still need to one day make some raster splits on the Genesis (even if I have to cover the split with sprites, sine I know lockstep is not perfect when the 68000 is involved).

[greatkreator]

Concerning the first: wouldn't it produce a lot of flickering?

Concerning the second: the architecture just doesn't allow it. Just impossible. Of course it would be good but if we would like just to dream about something then it's more reasonable to dream about some kind of modern GPU support for example (:

[LocalH]

Concerning the first: wouldn't it produce a lot of flickering?

Concerning the second: the architecture just doesn't allow it. Just impossible. Of course it would be good but if we would like just to dream about something then it's more reasonable to dream about some kind of modern GPU support for example (:

There would be a fair mount of flickering, but with judicious color choice, flicker could be minimized. The PAL C64 demoscene has a long history of using such interlacing, and flicker is worse in 50Hz than it is in 60Hz. The flicker won't be any worse than normal interlace flicker as per the NTSC and PAL standards, unless one tries to do something silly like have black and white in the same pixel position.

I still wonder if there are secrets left to unlock in the VDP. For years we didn't know the normal MD VDP has a 128KB VRAM mode, but it does

[greatkreator]

Clear!
I just experimented quite a lot with interlaced mode and couldn't get anything acceptable in the context of flickering.
And of course I didn't try to display black and white interlaced.
Even perfect combinations produced not comfortable for eyes image.
Maybe I am just not enough tolerant to flickering.

It has such a mode but it doesn't give anything useful on the majority of devices? right?