About VDP command operation code = 0

Page 4/6
1 | 2 | 3 | | 5 | 6

By flyguille

Prophet (3028)

flyguille's picture

08-06-2011, 20:01

hmmm if the vdp don't updates the registers in real-time, so then, you can't to:

STOP the current command: saves all the status -> execute another ---> back to the previous command

anyway, adding overhead don't helps in a multi-process O.S.

By hit9918

Prophet (2925)

hit9918's picture

08-06-2011, 20:30


also the real thing stop in the middle of a line. i suspect as soon as a next "clock" is received.
set adjust DOES hurt the blitter, but why using set adjust? just poke vdp(19).....

the basic program could be modified to show the reg18 glitch and one can see if vdp(47)=0 solve....
however a more precise test could be done only with asm.

I had this idea that BASIC set adjust might have some code to prevent blitter wreck, just phantasy.

This one does random bomb R18 without sync to the screen, maybe no asm test is needed:
removing the VDP(48) assignment should result into some garbage in the blit.

10 SCREEN 7
20 FOR N=0 TO 3
30 LINE (0,N*8)-(511,191-N*8)
40 LINE (0,191-N*8)-(511,N*8)
50 NEXT N
60 COPY (0,32)-(511,211) TO(0,0)
70 FOR Y=-7 TO 8
80 FOR X=-7 TO 8
90  VDP(47)=0
100 SET ADJUST (X,Y)
110 VDP(47)=144
120 NEXT X,Y
130 A$=INPUT$(1) : GOTO 10

By PingPong

Prophet (3911)

PingPong's picture

08-06-2011, 20:35

hmmm if the vdp don't updates the registers in real-time, so then, you can't to:

STOP the current command: saves all the status -> execute another ---> back to the previous command

anyway, adding overhead don't helps in a multi-process O.S.
dont' update?
those register are write only.
so there is no way to restore a previous command.

By hit9918

Prophet (2925)

hit9918's picture

08-06-2011, 20:47


Could you explain a little more your idea ?

As it turned out that reading blitter registers does not work, the multitasking idea failed Crying
If there only were a way to tell how many pixels the blitter has processed.

What still holds true is that if the R18 glitch can be fixed,
in a game which sets scrollregisters multiple time per frame,
you can actually use the blitter normaly, especially with large blits.
That is the thing I hoped would be the result of the blitter stop issue.

What still can be done is to stop the current blit, do something more important, and then from RAM variables redo the whole blit. So that would be the hi priority menu redraw in a multitasking OS while the blitter is into some other job of long duration. But the thing is not so interesting for games.

By wouter_

Champion (486)

wouter_'s picture

08-06-2011, 21:13

Hi,

I ran some test on a real machine. This is what I found out:

When you abort a command it can indeed stop in the middle of a (horizontal) line. But when you later restart that command it does NOT continue where it stopped. Instead it restarts at the beginning of the current line (at least that's close to where it stopped, it doesn't redo the whole command).

I've confirmed that openMSX behaves in exactly the same way. I didn't test but probably blueMSX also behaves like this.

It can be explained with the following pseudo code. This is more or less how VDP block commands are emulated in openMSX. And, to the best of our knowledge, also how the real hardware works (and reconfirmed by the stop/restart tests I just did):

Pseudo code for internal operation of the LMMM command,
ignoring details like logical operations and DIX,DIY
    do {
        ASX = SX
        ADX = DX
        ANX = NX
        do {
            pset(ADX, DY, point(ASX, SY))
            ASX += 1
            ADX += 1
            ANX -= 1
        } while(ANX != 0)
        SY += 1
        DY += 1
        NY -= 1
    } while (NY != 0)

The variables SX, SY, DX, DY, NX, NY directly correspond to the VDP registers. So while the command is executing, the values of those VDP registers change (and from this pseudo code you can derive what the values are when the command finishes).

The variables ASX, ADX, ANX are extra internal VDP registers. At the start of the command, and at the start of each horizontal line, those registers are initialized with the corresponding SX, DX, NX values. Within one line only these extra registers are changed.

So if you stop and later restart a command (actually *RE*starting is really the same as simply starting a command) the registers ASX, ADX, ANX are also reinitialized and the command continues at the beginning of the current horizontal line.

BTW: the extra register 'ASX' is not completely hidden. It can be read via VDP status registers S#8 and S#9. This makes sense if you think about how the VDP SRCH command works. But it also works for the other block commands! This behavior is implemented in openMSX, but AFAICS not yet in blueMSX.

By hit9918

Prophet (2925)

hit9918's picture

08-06-2011, 23:01

EDIT: I think I misunderstood.

So it does not start in the next line, but restart at ASX=SX in the current line?
So a plain copy can be restarted without any problems, right?

By wouter_

Champion (486)

wouter_'s picture

09-06-2011, 08:37

So a plain copy can be restarted without any problems, right?
Yes. So some of the pixels of the whole block are copied twice.

By PingPong

Prophet (3911)

PingPong's picture

18-06-2011, 14:31

Hi, all.
I've done some other little tests:

unfortunately the vdp had some oddities that prevent a true use of the "stop and go" command.

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.

2) my code does a vdp(46)=0 then wait for vdp busy flag then r18 update then resume command. the r18 corruption is still there.
However, if i do the same with basic, no corruption at all, maybe the slowness of basic allow for a longer delay, but i cannot determine how much

In all situations, copy commands must not contain logical operators, otherwise one get some other strange effects

(High speed command works, with (1) and (2) limitations, Logical copy has (1) and (2)+ no logical operations)

Pratically useless.

:-(

By PingPong

Prophet (3911)

PingPong's picture

18-06-2011, 14:41

Hi,

I ran some test on a real machine. This is what I found out:

When you abort a command it can indeed stop in the middle of a (horizontal) line. But when you later restart that command it does NOT continue where it stopped. Instead it restarts at the beginning of the current line (at least that's close to where it stopped, it doesn't redo the whole command).

that is explaining the oddities with logical copy commands and xor logical operation that i've seen. doing twice the same operation, after a restart, give the effect i've seen. Of course a OR or AND command, or others commands that does not change the result if repeated, appear to work. the same for an high speed copy command, that does not have logical operations at all.

The reason of the R18 oddity remains ( almost for me ) unexplained.

Question

By ARTRAG

Enlighted (6864)

ARTRAG's picture

18-06-2011, 18:16

so, how long does it take to become safe setting register 18 after command has been stopped?

Page 4/6
1 | 2 | 3 | | 5 | 6