Maybe someone has already experimented with that.

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Maybe someone has already experimented with that.

Post by greatkreator » Fri Nov 27, 2015 10:10 pm

Maybe someone has already experimented with that?
I do the raster effect and it transfers more colors than it's possible to fit in the invisible HBLANK area.
They of course become visible as artifacts but sometimes it is possible to make those artifacts very stable (not flickering) just standing at the both sides of the screen.
However those that appear at the left side(where the display turns on) have random flickering artifacts.
The right side artifacts are usually stable and not annoying.

Does anyone know what reason makes them to be so stable sometimes?
Do I fit any timings of VDP or anything else?

The purpose is to have 61 colors per a scan line sacrificing few columns of tiles at the borders of the screen.
But I cannot stabilize those artifacts to be at least not annoying.

here how it looks:
https://www.youtube.com/watch?v=NFqGNTFUceM

in the middle tiles that change their colors each scan lines. in the extreme sides groups of DMA to CRAM artifacts. and those line-artifacts that i want to overcome at the left side of the tiles. flickering randomly.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Maybe someone has already experimented with that.

Post by Mask of Destiny » Sat Nov 28, 2015 8:44 am

So the big problem with trying to do anything that requires tight synchronization between the 68K and the VDP is that they have different clock dividers that aren't neat multiples of each other. The 68K is /7 and the VDP is /5 in H32 and mostly /4 with a bit of /5 in H40. This is exacerbated with periodic refresh delays on the 68K side that have a weird period. You can sync them up for a little while by filling up the FIFO and doing a write that blocks, but they drift apart.

Any particular reason you're trying to replace 61 colors each line?

greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Re: Maybe someone has already experimented with that.

Post by greatkreator » Sat Nov 28, 2015 10:14 am

Thanks a lot Mask (sorry I don't know your name so I had to use Mask)!
Actually that was a problem!
Thanks for the luck and Tiido I fixed that.
I played a bit with sync NOPs and they did their job.
I added one instruction having 6 clock length and something inside VDP an CPU matched in the context of sync.

I sync at the beginning of the frame with the code used in the direct color DMA method.
Then use NOPs to make an offset to the start point and duplicated the same DMA code for each line.

Such 61 colors replace each line helps to have hundreds of colors per image.
I found it quite impressive. Isn't?

Post Reply