About VDP command operation code = 0

صفحة 3/6
1 | 2 | | 4 | 5 | 6

بواسطة PingPong

Prophet (4093)

صورة PingPong

07-06-2011, 20:07

@horthgar: there is no pratical diff. between stop and aborting a command from the point of view of vdp
vdp cmd engine or blitter itself is driven by the main clock (is a state machine). writing 0 acts as by suspending the clock for the engine itself. writing other value enable the state machine.

And of course the vdp itself (i've verified) can be stopped even in a middle of a scanline. i think the stop is in effect as soon as the vdp command register is set to 0, regardless of the completion state of the command.

easy to check also in basic

10 screen 7
20 copy (0,0)-(511,211),1to(0,0),0
30 vdp(47)=0: ' STTTTOOOOOOP
40 t$=input$(1)
50 vdp(47)=144: ' gooooooo
60 t$=input$(1)
70 goto 30

run and press a key. every time you press a key the vdp stop, the next key the vdp resume, then stop, then resume, etc.

TongueTongueTongueTongueTongueTongueTongueTongue

بواسطة ARTRAG

Enlighted (6923)

صورة ARTRAG

07-06-2011, 20:44

This code is not working under emulators
We should point the issue to the teams who develop openmsx and bluemsx

بواسطة PingPong

Prophet (4093)

صورة PingPong

07-06-2011, 21:17

This code is not working under emulators
We should point the issue to the teams who develop openmsx and bluemsx

i agree, but now further investigations should be done.

Another thing i found not related to vdp.
if i change the copy command with a line ,BF command (that should map into a logical fill), there is no way to stop the command. it's not a vdp issue, simply the basic rom code, wait until command end, then execute the vdp(47)=0, but now it's too late......

my guess is: why a copy command can work in parallel with basic interpreter, and a line bf command not?
a bug?

you can test this by adding a beep command before the vdp(47) command: if you are copying you can hear the beep before the copy is completed, if you are executing line,BF then the beep is sounded only after the line command is completed...

بواسطة Hrothgar

Champion (479)

صورة Hrothgar

07-06-2011, 21:26

Heh, works fine in NLmsx v0.48 from 2003. So much for state of the art emulators that aim for perfection LOL! Perhaps OpenMSX and BlueMSX can beg for some code?

بواسطة Hrothgar

Champion (479)

صورة Hrothgar

07-06-2011, 21:33

Alternatively, is the registered patent http://www.patents.com/us-4731742.html for the VDP 9938 something that would help developers implement more exact emulation? I can't access the attached schematics and the whole thing is extremely difficult to read, but probably for someone who has implemented an emulator this all makes much more sense.

بواسطة ARTRAG

Enlighted (6923)

صورة ARTRAG

08-06-2011, 14:40

usually the style of writing of patents is very cryptic: this is for avoiding that other developers understand/copy/work around the patent, nevertheless allowing the owner of the patent to claim their rights on the ideas
IMHO it cannot help a lot

بواسطة hit9918

Prophet (2927)

صورة hit9918

08-06-2011, 15:45

It works on openMSX 0.8.1 !

@PingPong

TongueTongueTongueTongueTongueTongueTongueTongue

This is so cool, the issue got lots consequences for making use of blitter bandwidth, and you show it with a short BASIC program Big smile

@sd_snatcher:
I wonder: if the STOP command only pauses the blitter, is there a way to actually abort a command in progress?

An "abort" works like this: after the STOP, you change blitter state like you always do. My model of it:

There is a bunch of registers. After every pixel (or line?) the VDP reads the command byte like an opcode and then operates on the registers according to the opcode. The STOP opcode practically is a NOP opcode. Poke STOP in the commandregister and it goes NOP NOP NOP.

And the blit commands are like LDI commands. Like, poke LDI in the commandregister and then it goes LDI LDI LDI LDI. HOWEVER there is one difference: the LDI of the VDP does nothing if the counter register has reached zero. It then also does not change the counter register.

@PingPong, all those coordinate registers, can they be read, do they change while the blitter is running? If after a STOP all state can be saved and restored later, this means this blitter can do preemptive multitasking, WOW! The background copy of a scroller could be one single blit, using all DMA!!!

OpenMSX stops in the middle of a line, i.e. goes on a per-pixel-basis, the real thing too?
Just a brainstorming idea: maybe there too is some VDP delay thing.

As you poke a STOP opcode, the thing may still have some outstanding read/write waiting for next DMA slot. That time even a STOPed blitter may get hit by set adjust.

So maybe some waiting needs to be done, STOP : wait : set adjust : wait : RUN .
Who knows, maybe in invisible area only sprites get DMA (to be suspected as turning
them off changes so much), so then the wait would have to be like halve a rasterline.

Just something to try if the first attempts with set adjust fail.
To be sure about that theory, the test would not have to be done from a line interrupt,
but in an unsyncronized loop stop : set adjust : run.

Does the BASIC set adjust too hurt the blitter? If no, then there is the code to prevent it!

بواسطة PingPong

Prophet (4093)

صورة PingPong

08-06-2011, 17:36

Quote:
@PingPong, all those coordinate registers, can they be read, do they change while the blitter is running? If after a STOP all state can be saved and restored later, this means this blitter can do preemptive multitasking, WOW! The background copy of a scroller could be one single blit, using all DMA!!!

OpenMSX stops in the middle of a line, i.e. goes on a per-pixel-basis, the real thing too?
Just a brainstorming idea: maybe there too is some VDP delay thing.

Does the BASIC set adjust too hurt the blitter? If no, then there is the code to prevent it!

Unfortunately, the regs, change, but cannot be read. the v9938 manual say how they change after the execution of a command, like you guessed, for example nx, ny reach zero, for example. (the former is reloaded, in area command multiple times)

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.

بواسطة ARTRAG

Enlighted (6923)

صورة ARTRAG

08-06-2011, 17:53

This code is not working under emulators
We should point the issue to the teams who develop openmsx and bluemsx

humm
sorry I misunderstood the results under bluemsx
I think the test works under this emulator

بواسطة Metalion

Paragon (1622)

صورة Metalion

08-06-2011, 19:10

If after a STOP all state can be saved and restored later, this means this blitter can do preemptive multitasking, WOW! The background copy of a scroller could be one single blit, using all DMA!!!
Could you explain a little more your idea ?

صفحة 3/6
1 | 2 | | 4 | 5 | 6