strange behaviour of the VDP command engine on bluemsx

Por ARTRAG

Enlighted (6687)

Imagen del ARTRAG

16-03-2010, 01:44

I have found that resetting register 14 while the VDP is doing a byte copy vram to vram will disrupt the current command
Is this normal in the real HW?

The copy command is moving data in pages different from 0 when i do:

xor a
out (0x99),a
ld a,14+128
out (0x99),a

I had no chance to test the thing on my TR but it seems quite strange.
Can anyone confirm that real HW has the same odd behaviour ?

ps
openmsx has the same oddness

Login sesión o register para postear comentarios

Por wouter_

Champion (470)

Imagen del wouter_

17-03-2010, 20:32

This seems very strange and unexpected to me. Can you clarify what you mean with "disrupt the current command"?

I checked both the openMSX and blueMSX source code, but I couldn't see any connection between writing to VDP register 14 and VDP command execution.

I also tried to reproduce the problem with the following BASIC program:

10 SCREEN5:SETPAGE,3
30 FORI=0TO255:LINE(I,0)-(I,211),IAND15:NEXT
40 COPY(0,0)-(255,211),3TO(0,0),0
50 OUT&H99,0:OUT&H99,142
60 GOTO60

But I didn't see anything strange. (I verified that the write to reg 14 happens before the command is finished.) I know that this is doing a pixel copy instead of a byte copy but (again from reading the emulator source codes) that shouldn't make any difference.

Can you explain your test case in more detail? Or even better send a test program that demonstrates the problem?

Por ARTRAG

Enlighted (6687)

Imagen del ARTRAG

17-03-2010, 22:38

can i mail you the code?

Por wouter_

Champion (470)

Imagen del wouter_

18-03-2010, 19:36

Sure, wouter.vermaelen@scarlet.be. Or join #openmsx on irc.freenode.net.

Por ARTRAG

Enlighted (6687)

Imagen del ARTRAG

18-03-2010, 22:41

mail sent

Por wouter_

Champion (470)

Imagen del wouter_

21-03-2010, 19:28

We've resolved this problem. It was not related to writing to VDP register 14 at all. The problem was caused by switching to a non-bitmapped mode while there was still a VDP command in progress. Both blueMSX and openMSX will stop executing the VDP command in this case.

For anyone who's interested, here's an openMSX script that can detect this type of problem (as always, feel free to tweak this script for your needs):

set old_mode [get_screen_mode]

proc write_99 {} {
        set new_mode [get_screen_mode]
        if {$new_mode != $::old_mode} {
                set ::old_mode $new_mode
                if {[debug read "VDP status regs" 2] & 1} {
                        puts stderr "Mode change detected while a VDP command is in progress"
                }
        }
}

debug set_watchpoint write_io 0x99 true write_99

Por Yukio

Paragon (1540)

Imagen del Yukio

12-05-2010, 16:09

Maybe, this is the problem with test that are not made on the *REAL* thing ...