Changing Border during refresh

Practically busy loop is very bad idea because of 50Hz/60Hz difference + that you miss valuable time. In MSX2 this is trivial to do as there is line interrupt. On MSX1 it is better idea to use sprite collision flag or 5th sprite flag to poll the correct place. You still need to do some kind of busy loop, but you can more easily use the time for something useful (like playing music) as the code does not need to be cycle accurate.

It is definitely doable and I consider this kind of changing colors as "Hello World" example to VDP programming, but maybe I've been talking too much with demo coders. Usually programmers use this "trick" to measure time that their individual routines (like music player) takes... Think it as MSX version of Windows task manager's CPU meter.

Hi folks,

I have a first working example and a ton of questions...

This is my code: (the ASM syntax may be not accurate because I assembled it manually poking the opcodes on RAM)
(edit: I'll use the BlueMSX debugger to get the ASM listing)

9000:   ld     a,#01      
9002:   out    (#99),a    
9004:   ld     a,#8f      
9006:   nop               
9007:   nop               
9008:   out    (#99),a    
900A:   nop               
900B:   nop               
900C:   nop               
900D:   nop               
900E:   in     a,(#99)    
9010:   bit    0,a        
9012:   jr     z,#9020    
9014:   ld     a,#17      
9016:   out    (#99),a    
9018:   ld     a,#87      
901A:   nop               
901B:   nop               
901C:   out    (#99),a    
901E:   jr     #9028      
9020:   ld     a,#f4      
9022:   out    (#99),a    
9024:   ld     a,#87      
9026:   out    (#99),a    
9028:   ld     a,#00      
902A:   out    (#99),a    
902C:   ld     a,#8f      
902E:   nop               
902F:   nop               
9030:   out    (#99),a    
9032:   ret               
9033:   ret               
9034:   ret               
9035:   ret               
9036:   ret               

I used a few NOPs because openMSX complained about writting/reading too fast to the VDP, but the result is basically the same.

After poking this on RAM, I set the H.HEYI hook (&HFD9A) with call #9000 and then a ret. Once the hook is set up, I set VDP registers for line interrupt, first R#19 to line 40 (fifth character line on text mode) and finally set bit 4 on R#0 to activate the int signal generation.

Here's the video shot I made using OpenMSX, the emulated machine is a Panasonic FS-A1WX, and I used SETSCREEN to boot the computer to SCREEN 0:WIDTH 40

https://youtu.be/AdRgkHJtLt8

First thing is: the code takes a little more than 2 scanlines to change the screen color, but this is (almost) ok, I didn't expect the BASIC interrupt handler to dispatch a INT that fast, I don't mind setting the interrupt to fire 2 or 3 lines earlier at all. But I DO MIND with that flicker. when this happened the first time, I imediattely thought that was an issue with too fast VDP writes, and OpenMSX confirmed that I was poking the VDP port too fast, so I added a few NOPS (already on the ASM listing I provided) but it didn't stopped flickering. Is there any way to stop that flickering? or I just have to NOP it all way out of the screen?

Second thing: The video isn't showing but theres another color boundary right below the last text line of the screen. I suppose that there's another INT firing that moment and I don't have any idea where it is coming from, so I tried to place that routine under the H.TIMI hook (&HFD9F) so I could tell if the screen is redrawn before changing back the backdrop color register... but if I do such thing, OpenMSX tells me that it reached a DI; HALT and the emulation freezes. What's happening? I tried to reproduce the error on BlueMSX (because I don't have OpenMSX debugger set on none of my computers) and no matter what I do it doesn't hang (I used the Generic MSX2 machine configuration).

If I try to turn of the color-changing code the BASIC interpreter immediately stops working, no matter what I do. When I investigate this, apparently my code goes wild and start filling the RAM with garbage, which is an odd behaviour because I don't write to the RAM anywere, so I suppose that's an stack overflow. (or it jumped/returned to the middle of something that's make no sense, either code or data) No BIG deal here, but I don't think this should happen.

Hi folks,

I have a first working example and a ton of questions...

This is my code: (the ASM syntax may be not accurate because I assembled it manually poking the opcodes on RAM)
(edit: I'll use the BlueMSX debugger to get the ASM listing)

9000:   ld     a,#01      
9002:   out    (#99),a    
9004:   ld     a,#8f      
9006:   nop               
9007:   nop               
9008:   out    (#99),a    
900A:   nop               
900B:   nop               
900C:   nop               
900D:   nop               
900E:   in     a,(#99)    
9010:   bit    0,a        
9012:   jr     z,#9020    
9014:   ld     a,#17      
9016:   out    (#99),a    
9018:   ld     a,#87      
901A:   nop               
901B:   nop               
901C:   out    (#99),a    
901E:   jr     #9028      
9020:   ld     a,#f4      
9022:   out    (#99),a    
9024:   ld     a,#87      
9026:   out    (#99),a    
9028:   ld     a,#00      
902A:   out    (#99),a    
902C:   ld     a,#8f      
902E:   nop               
902F:   nop               
9030:   out    (#99),a    
9032:   ret               
9033:   ret               
9034:   ret               
9035:   ret               
9036:   ret               

I used a few NOPs because openMSX complained about writting/reading too fast to the VDP, but the result is basically the same.

After poking this on RAM, I set the H.HEYI hook (&HFD9A) with call #9000 and then a ret. Once the hook is set up, I set VDP registers for line interrupt, first R#19 to line 40 (fifth character line on text mode) and finally set bit 4 on R#0 to activate the int signal generation.

Here's the video shot I made using OpenMSX, the emulated machine is a Panasonic FS-A1WX, and I used SETSCREEN to boot the computer to SCREEN 0:WIDTH 40

https://youtu.be/AdRgkHJtLt8

First thing is: the code takes a little more than 2 scanlines to change the screen color, but this is (almost) ok, I didn't expect the BASIC interrupt handler to dispatch a INT that fast, I don't mind setting the interrupt to fire 2 or 3 lines earlier at all. But I DO MIND with that flicker. when this happened the first time, I imediattely thought that was an issue with too fast VDP writes, and OpenMSX confirmed that I was poking the VDP port too fast, so I added a few NOPS (already on the ASM listing I provided) but it didn't stopped flickering. Is there any way to stop that flickering? or I just have to NOP it all way out of the screen?

Second thing: The video isn't showing but theres another color boundary right below the last text line of the screen. I suppose that there's another INT firing that moment and I don't have any idea where it is coming from, so I tried to place that routine under the H.TIMI hook (&HFD9F) so I could tell if the screen is redrawn before changing back the backdrop color register... but if I do such thing, OpenMSX tells me that it reached a DI; HALT and the emulation freezes. What's happening? I tried to reproduce the error on BlueMSX (because I don't have OpenMSX debugger set on none of my computers) and no matter what I do it doesn't hang (I used the Generic MSX2 machine configuration). EDIT: Just figured this out: I destroyed the contents of A register. Added a PUSH AF before my code and a POP AF at the end of my code and now it runs on H.TIMI without hanging, but now I know that this isn't the best approach for a routine that isn't tied to the 50/60Hz refresh interrupt. I do need a different code here to handle the "alternate color status"... maybe this would improve the original code as well since I won't need the "else case" anymore.

If I try to turn of the color-changing code the BASIC interpreter immediately stops working, no matter what I do. When I investigate this, apparently my code goes wild and start filling the RAM with garbage, which is an odd behaviour because I don't write to the RAM anywere, so I suppose that's an stack overflow. (or it jumped/returned to the middle of something that's make no sense, either code or data) No BIG deal here, but I don't think this should happen.

You're very welcome!

Aw crap! really?

Sure will do it. Do anyone know how much time I have before the VDP begins to plot the next scanline?

Thanks. I'll have a look later.

Regards
Tiago