Does somebody have some assembler code that selects screen mode 7 without using any bios calls (#5f). My own code isn't working. It puts the msx vdp in to a very strange mode that keeps repeating the first 32 scanlines over and over again. In the openmsx emulator its a little bit different. In that emulator it repeats the scanlines in blocks of 8 scanlines.
solved,...
ld a,%00001010
out (#99),a
ld a,128+0
out (#99),a
ld a,%01100000
out (#99),a
ld a,128+1
out (#99),a
ld a,%00101010
out (#99),a
ld a,128+8
out (#99),a
ld a,%10000000
out (#99),a
ld a,128+9
out (#99),a
ld a,%00011111
out (#99),a
ld a,128+2
out (#99),a
It puts the msx vdp in to a very strange mode that keeps repeating the first 32 scanlines over and over again. In the openmsx emulator its a little bit different. In that emulator it repeats the scanlines in blocks of 8 scanlines.
If you can recreate that code you should report the difference to the openmsx developers.
While it might seem pointless to emulate a mode like that I am pretty sure they want to make the emulator as accurate as possible.
It puts the msx vdp in to a very strange mode that keeps repeating the first 32 scanlines over and over again. In the openmsx emulator its a little bit different. In that emulator it repeats the scanlines in blocks of 8 scanlines.
This actually sounds like the value of vdp(2) was wrong...
The difference between the repeating of 8 and 32 scanlines is then caused by the fact if you start your program from screen 1 or screen 0. That startcondition will have set the vdp(2) to an other value.
I hope you didn't forget to add a DI and EI around your code or the interrupt might cause it to be interrupted and your init maight go haywire because of it.
The difference between the repeating of 8 and 32 scanlines is then caused by the fact if you start your program from screen 1 or screen 0. That startcondition will have set the vdp(2) to an other value.
Ahh I see that would explain…
turbor wrote:
I hope you didn't forget to add a DI and EI around your code or the interrupt might cause it to be interrupted and your init maight go haywire because of it.
Also I think it’s better to read the register values from their mirrors in the system RAM, and then only modify the bits that you need to modify… E.g. your current code hardcodes the display frequency to 60 Hz, which will mess up the video output for people who connected their monitor via composite video.
