About VDP command operation code = 0

Страница 5/6
1 | 2 | 3 | 4 | | 6

By PingPong

Prophet (4093)

Аватар пользователя PingPong

18-06-2011, 18:25

so, how long does it take to become safe setting register 18 after command has been stopped?
unfortunately i've not determined this, it's a matter of test.
Honestly, i've not determined this, but consider this:
in machinecode, after i see that vdp is free, i set default status reg0 for reading then i pop de then "ret". After this i set r18.
this is not enough.

By hit9918

Prophet (2927)

Аватар пользователя hit9918

19-06-2011, 14:13

so, how long does it take to become safe setting register 18 after command has been stopped?
unfortunately i've not determined this, it's a matter of test.

My model of the glitch is that an R18 write triggers some recalculation in multiple steps. Between the two steps, the blitter works on some wrong base address or something like that.

The question is how far are these steps separated in the worst case.
If we are unlucky, it is one vblank.
If we are lucky, it is one rasterline.
I would not expect a result like "needed delay is 3 rasterlines".

I would try this delay of one rasterline AFTER setting R18:

  ld b,16
loop:
  djnz loop

about a delay needed between BEFORE setting R18, I got no idea.
maybe start with using a rasterline delay as well.

By hit9918

Prophet (2927)

Аватар пользователя hit9918

19-06-2011, 14:24


1) if a command is about to complete, one can write a 0 to stop it, but in the middle the command end. next , one try to restart the command (because at the time was about to end, but still in progress), the command restarts, with wrong parameters in registers, instead of just keeping stopped.

This one does really worry me. Does this also happen when NOT playing with R18? Smile2
If it only happens with R18 poke involved, there is a hope for fix by delaying.

By PingPong

Prophet (4093)

Аватар пользователя PingPong

19-06-2011, 19:08


1) if a command is about to complete, one can write a 0 to stop it, but in the middle the command end. next , one try to restart the command (because at the time was about to end, but still in progress), the command restarts, with wrong parameters in registers, instead of just keeping stopped.

This one does really worry me. Does this also happen when NOT playing with R18? Smile2
If it only happens with R18 poke involved, there is a hope for fix by delaying.


It does happen always, unfortunately. I've not seen this at first, because it's unlikely to happen if one set twice vdp(46) on vblank. (first time 0 then the command)

But it's easy to test in basic.
1) do a copy command (copy half-height screen, from 0,0 on page 1 to 0,0 on page 0)
2) wait for completion
3) vdp(47)=144

result: another command restart from the middle to the bottom of the screen
that's because the DY counter is altered after the end of the command.

By hit9918

Prophet (2927)

Аватар пользователя hit9918

19-06-2011, 19:46

is this possible:

STOP blitter
wait 1 rasterline (just to be sure)
set R18
wait 1 rasterline
check whether the completion-flag is set. if blitter already finished, do not poke 144.

or is there a worse quirk, like a STOP at the last pixel not setting the completion flag
even though the thing is already finished?

By PingPong

Prophet (4093)

Аватар пользователя PingPong

19-06-2011, 20:11

is this possible:

STOP blitter
wait 1 rasterline (just to be sure)
set R18
wait 1 rasterline
check whether the completion-flag is set. if blitter already finished, do not poke 144.

or is there a worse quirk, like a STOP at the last pixel not setting the completion flag
even though the thing is already finished?

@hit9918:
if you stop the blitter, the completion flag goes 0 saying "completed". So, the last step (poke 144) will never be executed.

By mth

Champion (507)

Аватар пользователя mth

21-06-2011, 03:06

I'm guessing the corruption when changing R18 has something to do with the time slot allocation for accessing VRAM. If so, it should not occur if display is disabled (blanking), since then VRAM does not have to be read to produce the output image. This might offer a way out by having one blanked line where the screensplit occurs:

1. wait for end of top area
2. enable blanking
3. change R18
4. wait for end of blanked line
5. disable blanking

Does the R18 change cause corruption no matter what direction you move in, or only when reducing the left border width? I remember David (turbor) saying he ran into an issue like that when making Sand Stone, but I don't remember all the details.

What is the value of ASX (S8/S9) at command completion? Is it equal to SX+NX-1, to SX+NX or to SX? It would be worthwhile to check if that value can also occur if you abort a running command. If the value is unique, it would be a way to test whether a command was completed or not before it was aborted.

A workaround could be to cut big copies into smaller ones and simply restart the aborted copy from scratch by re-writing SY, DY, NY. That does require periodic checking for command completion though, because you don't want the VDP to be idle too long. It's a real shame the V9938 does not have a command completion interrupt.

By mth

Champion (507)

Аватар пользователя mth

21-06-2011, 03:18

Another possible workaround: create a test program measure how many display lines a copy takes for non-blank lines. Then in your game, set line interrupts slightly after the completion point to start the next copy. That way you know exactly which display line is being output at the moment and you know with roughly how far along the copy is on each display line. Therefore, you can tell in which of these three situations you are:

1. the copy will certainly finish before the next screen split
2. the copy will finish roughly at the same time as the next screen split
3. the copy will certainly finish after the next screen split

In situation 1, there is no risk of corruption. In situation 3, you could abort and resume the copy without running the risk of resuming a completed copy. In situation 2, you could set a line interrupt a few lines down and on that interrupt you'd be in situation 3.

Note that we don't have an accurate model yet of how long a copy will take. So this approach will only work if your copy sizes are fixed, so you can experimentally determine its duration using a separate test program.

By Hrothgar

Champion (479)

Аватар пользователя Hrothgar

21-06-2011, 09:14

Why would a command complete interrupt be so essential: don't we have mostly two situations for copies in games?:

1) Large band copies, e.g. for a smoothscrolling game copying the whole screen in a limited number of bands (or columns) - think Manbow2 (I assume);
2) Small copies, e.g. 8×8 or 16×16 (think CoreDump) or even 1 or 2 px strips for border masking/filling.

In case of 1) I don't see the problem of issuing the large copy commands exactly between the screen splits; you'll have to make sure the total screen copy finishes in at most the x scroll steps you have anyway; if that doesn't fit, the game won't work period. Verifying that R18 in Vblank doesn't cause corruption is a good thing though.

In case of 2) you have loops with large numbers of small copies; it doesn't sound too wasteful to redo one single copy after a R18 change in such a case.

Which use case am I missing? Is it common to create (smoothscrolling) games where the large copies occur in random phases of the display?

By ARTRAG

Enlighted (6923)

Аватар пользователя ARTRAG

21-06-2011, 15:38

Why would a command complete interrupt be so essential: don't we have mostly two situations for copies in games?:

1) Large band copies, e.g. for a smoothscrolling game copying the whole screen in a limited number of bands (or columns) - think Manbow2 (I assume);
2) Small copies, e.g. 8×8 or 16×16 (think CoreDump) or even 1 or 2 px strips for border masking/filling.

In case of 1) I don't see the problem of issuing the large copy commands exactly between the screen splits; you'll have to make sure the total screen copy finishes in at most the x scroll steps you have anyway; if that doesn't fit, the game won't work period. Verifying that R18 in Vblank doesn't cause corruption is a good thing though.

In case of 2) you have loops with large numbers of small copies; it doesn't sound too wasteful to redo one single copy after a R18 change in such a case.

Which use case am I missing? Is it common to create (smoothscrolling) games where the large copies occur in random phases of the display?

Having one single large command is by far more efficient than slicing the copy in smaller chunks
Consider that in this latter case the overhead (and the waiting time) is multiplied by teh number of chunks you have decided

Страница 5/6
1 | 2 | 3 | 4 | | 6