How to change the R18 value while the VDP is running a command

Page 2/2
1 |

By sd_snatcher

Prophet (3551)

sd_snatcher's picture

26-12-2012, 02:18

So just don't drop any frames. Wink

By ARTRAG

Enlighted (6862)

ARTRAG's picture

26-12-2012, 09:17

The horizontal scrolling works already, anyway the isr has to plot borders, so you miss an important bit in the scrolling routine

By PingPong

Prophet (3901)

PingPong's picture

26-12-2012, 19:19

For now, it appears that is fine to change R18 while a command is running, but you need to do this just after bit 5 of status reg 2 (HBLANK) goes 1.
Changing in others situations, including VBLANK does make garbage.

My guess is that during HBLANK the vdp does not execute any command. the memory bandwidth is allocated to z80 & to the task of SAT parsing, to know which 8 sprites to display. After vblank, the vdp restart the command synched with r18
In all others situations the engine is running so changing R18 does make vram corruptions

By Pat

Expert (68)

Pat's picture

26-12-2012, 22:25

Reading the thread indeed hints that the bottleneck is a classical one: shared memory being accessed from different resources. The dining philosophers is a nice link on how to solve it. But actually we (I) still do not know what the vdp is doing in HBLANK.

One way to actually find this out is to trace the actual address being used on the VRAM bus. A logic analyzer to capture the addresses used in combination with a know test program on the Z80 would be a way to find it out. It could prove the SAT parsing assumption (will do probably). Though using a logic analyzer would be cumbersome I think. A modern small uC with some software to sniff the VRAM address bus might be more convenient in combination with some analyzing software on a PC.

Any die hard here that has time left? Smile

By hit9918

Prophet (2925)

hit9918's picture

27-12-2012, 02:26

I forgot, did the idea "turn off sprite DMA for 2 scanlines but leave display DMA on" not work?

@PingPong, about sprite DMA in hblank area:

display area, hblank area, the areas are not so clear:
R18 makes the scanline up to 15 pixels shorter (from a vram acess pattern point of view, the monitor scanline is still same length)

So there are practically three areas:
hblank area, delay area, display area.

but the order of things is unclear. it could also be this:
delay area, hblank area, display area.

I am focusing DMA areas.
where monitor starts a new line and where DMA starts a new line, that may be two different points.
and where does hblank bit get high, may be a third point.

By hit9918

Prophet (2925)

hit9918's picture

27-12-2012, 03:20

@sd_snatcher,
you mention tiles, but there is no drawing of tiles,
the blitter makes one big run of a column copy.

a way was found to change R18 across one big blitter run, with blanked scanlines.
this keeps cpu time free for the game,
the search going on now doesnt want to split the blit into multiple pieces.

maybe some more about the inside of VDP can be found,
maybe one can do the R18 acess with less blank scanlines in the display.

By hit9918

Prophet (2925)

hit9918's picture

27-12-2012, 03:25

The situation is: Scroll game with panel works perfectly.
All the further questions is curiosity about the VDP,
and maybe there lurks a method with zero blanked lines, for parallax games.

By PingPong

Prophet (3901)

PingPong's picture

27-12-2012, 10:20

@hit9918:

hit9918 wrote:

I forgot, did the idea "turn off sprite DMA for 2 scanlines but leave display DMA on" not work?

this is not clear. I've verified that there is no corruption even with sprites+display on.
So disabling sprites/screen does not change nothing.
Maybe that disabling screen make even worse the situation, becase from the vdp perspective is like VBLANK.
IMHO the sprite enabled/disabled is somewhat a legend. (Does not change nothing)

Quote:

@PingPong, about sprite DMA in hblank area:
display area, hblank area, the areas are not so clear:

So there are practically three areas:
hblank area, delay area, display area.

Yes, three areas. I meaning:
display area= when the vdp access pattern/color/attribute or bitmap data to generate the image
delay area=are you meaning the VBLANK?
VBLANK area = the bottom and top "bands" of the screen
HBLANK area = the right and left border "bands"

As said, guess the cmd-engine is not running during HBLANK area. If one change R18 at the beginning of HBLANK (just after a scanline is generated), this change does not make corruption. I also think the VDP does in this time a full scan of SAT and require almost the max bandwidth available. Later when the next scanline is generated, the new R18 value is synched with cmd-engine.

So pratically the cmd-engine is (re-)synched/(re)started/stopped several times in a frame

Different situation is during VBLANK. I think the VDP in this area does not need to start/stop anything because:
- there are no sprites to display
- there are no screen image to display, only a solid border color.
So i think the cmd-engine here run always. This situation made changing R18 a risk, we can get corruption.

My test showed this: Corruption is max if you change during VBLANK, at a lower level during active area, 0 if you sync to HR bit before changing R18.

Quote:

I am focusing DMA areas.
where monitor starts a new line and where DMA starts a new line, that may be two different points.
and where does hblank bit get high, may be a third point.

the exact timing is obscure and hard to find with sw tests. i think it's needed some kind of diagnostic/monitoring device to go more in depth

Effectively, all i'm telling here is just a theory, that tests appear to confirm. Nothing more.

IMHO knowing exactly when the blitter start running, when HR goes high/low exactly is outside of what we can do with simple test programs.

(If anyone know some V9938 engineer maybe we can get more light ;-) )

By PingPong

Prophet (3901)

PingPong's picture

27-12-2012, 10:28

Pat wrote:

Reading the thread indeed hints that the bottleneck is a classical one: shared memory being accessed from different resources. The dining philosophers is a nice link on how to solve it. But actually we (I) still do not know what the vdp is doing in HBLANK.

I do not fully agree with you Pat, we are using a feature not made to be used in this way. I think is not a bottleneck rather an "almost-expected" behaviour.
the R18 display adjust register is here to allow a TV set to center optimally the vdp image.

Page 2/2
1 |