Autor
| VDP illegal modes
|
manuel
msx guru
Mensajes: 3447 |  Publicado: Mayo 16 2007, 19:50 |
I just ran it on my 8250 with V9958: no vertical bars indeed... Weird! Must be some timing issue anyway.... I guess...
|
|
PingPong
msx professional
Mensajes: 982 | Publicado: Mayo 16 2007, 22:02 |
@manuel: it's sooo strange.... it's a very simple 'c' program with no other special things....
|
|
dvik
msx master
Mensajes: 1312 | Publicado: Mayo 16 2007, 22:21 |
After looking at the code I can't understand how it can be a timing issue either. Perhaps you can post the code here PingPong and let more people look at it.
|
|
manuel
msx guru
Mensajes: 3447 | Publicado: Mayo 16 2007, 22:46 |
I attached the code (and binaries) to the bug report in the openMSX bug tracker, if you can't wait for PingPong to send it  |
|
mth
msx freak
Mensajes: 192 | Publicado: Mayo 17 2007, 00:02 |
It's possible the diagonal stripes pattern is not related to the illegal modes at all. If you write to port 0x98 too fast, some of the values written will be ignored. What "too fast" is depends on the video mode, whether sprites are enabled and probably also whether the command engine is doing something. In any case, please add some delays between sending bytes through port 0x98 and check if that makes a difference.
openMSX does not emulate the dropping of bytes that are written to the VDP too fast. To be able to implement that, we would have to have an accurate model of what "too fast" is, which could prove quite tricky to determine, since we don't even have an accurate timing model of the command engine yet.
|
|
ARTRAG
msx master
Mensajes: 1681 | Publicado: Mayo 17 2007, 00:14 |
maybe, it is like u say: too many
outp(0x98,b);
outp(0x98,b);
outp(0x98,b);
outp(0x98,b);
outp(0x98,b);
outp(0x98,b);
outp(0x98,b);
outp(0x98,b);
without being in vblank
|
|
dvik
msx master
Mensajes: 1312 | Publicado: Mayo 17 2007, 00:19 |
Looking at the screenshot again, this sounds like a quite likely scenario.
Just add two or so nops between each outp and you'll probably get it to run correctly on real msxes.
As openMSX, blueMSX doesn't emulate timing on bus reads and this is a common user error. I thought it was ok on MSX2 but apparently thats not always the case.
|
|
PingPong
msx professional
Mensajes: 982 | Publicado: Mayo 17 2007, 02:00 |
Quote:
| Looking at the screenshot again, this sounds like a quite likely scenario.
Just add two or so nops between each outp and you'll probably get it to run correctly on real msxes.
As openMSX, blueMSX doesn't emulate timing on bus reads and this is a common user error. I thought it was ok on MSX2 but apparently thats not always the case.
|
Not sure... i write too fast, i should miss some bytes, OK?
In that case why i'm able to fill the entire screen?
anyway, i will prepare the same with the suggested delay.
jltursan can you test the new version, when i've updated the actual, please? |
|
flyguille
msx master
Mensajes: 1198 | Publicado: Mayo 17 2007, 02:42 |
maybe you are not filling all the screens
maybe not reaching the last line...
|
|
jltursan
msx professional
Mensajes: 873 | Publicado: Mayo 17 2007, 10:21 |
Quote:
| jltursan can you test the new version, when i've updated the actual, please?
|
Ok, no problem; but if I'm not wrong you're coding it using C, right?. If so, I don't think that the compiled code was enough optimized to flood the VDP...  |
|
ARTRAG
msx master
Mensajes: 1681 | Publicado: Mayo 17 2007, 10:45 |
Not sure about this. Hitech C can surprise you  |
|
PingPong
msx professional
Mensajes: 982 | Publicado: Mayo 17 2007, 21:26 |
Quote:
| Not sure about this. Hitech C can surprise you
|
you are right, ARTRAG, looking at the assembly you see
ld a, something
out(0x98),a
out(0x98),a
out(0x98),a
out(0x98),a
out(0x98),a
out(0x98),a
out(0x98),a
out(0x98),a
PS=ARTRAG, great job with the encoder, and of course great baby! |
|
|
|
|
