Untested territory?
MSX2+ allows for VDP commands in screen 4 (and lower), by setting the CMD bit in VDP(26).
I read that it should work like screen 8 (coordinates, I guess).
I have deployed VDP commands in screen 4 on MSX2, in WebMSX.
This gets results. Coordinates follow the tile structure. Lines are 8 pixels and are filled 8 bytes down and next. It zig zags.
I have just tested this on hardware. MSX2 does not seem to swallow this.
I have used a string of out commands in basic to set it up. Near machine language.
I have also read that it is not possible to use them in this mode.
I have not exhausted all options for notation. I say it's a nope.
So the emulator lacks constrains here, it seems.
Would be nice had it worked on hardware. I hacked the emulator into a better MSX2.
Here is the twist:
I coded it for the weird (faulty?) zig zag and tile line numbers configuration to fill and copy. The bug, it seems.
So I go to the MSX2+ and run it with VDP(26). VDP commands allowed.
I get the same results where I expect a different handling: like screen 8.
So the question is: how does a real MSX2+ handle VDP commands in screen 4? Straight forward, like screen 8. Or does it maintain the line structure of tiles / characters? This means that the line command (VDP command) yields unsatisfying results by default, messing up the 8 bit width.
What I have shouldn't work. I can do a fill in screen 4 on an MSX2 with VDP command with tile-coordinates, in the emulator.
If I run this on MSX2+ I get the same result.
So is the MSX2+, with screen 4 allowed, correct in the emulator? Similar to hardware?
Are the coordinates expressed in line numbers and does the fill/copy follow the character structure, eight down and next?
MSX hardware says no, it seems.
MSX2+ handles similar to faulty MSX2 situation, with or without VDP(26).
It seems messed up.
VDP commands in screen 4 are pretty neat. Limited color scheme but fast handling of compact information.
But I don't know what I'm looking at. I have a simple engine to fill up a screen. Copy/paste tiles on an unchanged name table (0-255). Straight forward. Simple concept. But do these coordinates even work on real hardware?
Maybe a challenge the figure it out with limited availability of MSX2+ hardware. Do copy/paste actions handle similar to the emulator, which handles it now under all conditions.
Tricky. I thought: that's cool for an MSX2. Suspicious me: does not work on hardware. Bummer. I hacked the emulator.
Now I want to run it on MSX2+. I get strange results. No constrains. No effect from VDP(26). It always works. What coordinates?
EDIT:
Short:
Is the MSX2+ VDP(26) CMD-bit always on on ALL systems? Inherently it has no effect on MSX2+/Turbo R.
If that's the only problem then the implementation of tile-coordinates is correct. But there might be an issue there.
Untested territory?
MSX2+ allows for VDP commands in screen 4 (and lower), by setting the CMD bit in VDP(26).
I read that it should work like screen 8 (coordinates, I guess).
I have deployed VDP commands in screen 4 on MSX2, in WebMSX.
This gets results. Coordinates follow the tile structure. Lines are 8 pixels and are filled 8 bytes down and next. It zig zags.
I have just tested this on hardware. MSX2 does not seem to swallow this.
I have used a string of out commands in basic to set it up. Near machine language.
I have also read that it is not possible to use them in this mode.
I have not exhausted all options for notation. I say it's a nope.
So the emulator lacks constrains here, it seems.
Would be nice had it worked on hardware. I hacked the emulator into a better MSX2.
Here is the twist:
I coded it for the weird (faulty?) zig zag and tile line numbers configuration to fill and copy. The bug, it seems.
So I go to the MSX2+ and run it with VDP(26). VDP commands allowed.
I get the same results where I expect a different handling: like screen 8.
So the question is: how does a real MSX2+ handle VDP commands in screen 4? Straight forward, like screen 8. Or does it maintain the line structure of tiles / characters? This means that the line command (VDP command) yields unsatisfying results by default, messing up the 8 bit width.
What I have shouldn't work. I can do a fill in screen 4 on an MSX2 with VDP command with tile-coordinates, in the emulator.
If I run this on MSX2+ I get the same result.
So is the MSX2+, with screen 4 allowed, correct in the emulator? Similar to hardware?
Are the coordinates expressed in line numbers and does the fill/copy follow the character structure, eight down and next?
MSX hardware says no, it seems.
MSX2+ handles similar to faulty MSX2 situation, with or without VDP(26).
It seems messed up.
VDP commands in screen 4 are pretty neat. Limited color scheme but fast handling of compact information.
But I don't know what I'm looking at. I have a simple engine to fill up a screen. Copy/paste tiles on an unchanged name table (0-255). Straight forward. Simple concept. But do these coordinates even work on real hardware?
Maybe a challenge the figure it out with limited availability of MSX2+ hardware. Do copy/paste actions handle similar to the emulator, which handles it now under all conditions.
Tricky. I thought: that's cool for an MSX2. Suspicious me: does not work on hardware. Bummer. I hacked the emulator.
Now I want to run it on MSX2+. I get strange results. No constrains. No effect from VDP(26). It always works. What coordinates?
EDIT:
Short:
Is the MSX2+ VDP(26) CMD-bit always on on ALL systems? Inherently it has no effect on MSX2+/Turbo R.
If that's the only problem then the implementation of tile-coordinates is correct. But there might be an issue there.