Beware of using the VERA inside IRQ

[The 8-Bit Guy]

During my conversion of Petscii Robots over to the X16, it was relatively smooth until I added sound support.   So, I thought I'd talk about the one big issue I ran into, which I wasn't expecting due to my previous experience coding for Commodore machines.

Because the Vera has it's own video RAM, you have to set the VERA_L, VERA_M, and VERA_H every time you are about to write something to video RAM.  It's a little more cumbersome than the way things are done on other Commodore computers, but not terribly so.  In fact, in about 25% of cases, I found it easier to use this than the C64, depending on what I was trying to modify on the screen.

So, In my sound/music routine, I'm using the VERA's built-in PSG.  Which means my sound routine is changing VERA_L, VERA_M, and VERA_H every time the IRQ routine runs.   And the IRQ can run right in the middle of your writes to VRAM.  And unless you want to add an SEI and CLI before and after every routine that writes data to VRAM, you'll need to backup the VERA address registers in your IRQ routine.  So, I did this:

LDA VERA_H

PHA

LDA VERA_M

PHA

LDA VERA_L

PHA

***insert IRQ code here ***

PLA

STA VERA_L

PLA

STA VERA_M

PLA

STA VERA_H

Now, while this may sound obvious to some people, I wasn't accustomed to dealing with this sort of thing when writing to sound registers in the SID or VIC-20 or whatever, since they were their own separate registers.   Anyway, hopefully this piece of advice will help somebody else not pull their hair out in the future.

 

[Guybrush]

You could possibly set your code up in such a way that VRAM access uses port 1 and sound register access uses port 2.

[VincentF]

Had this exact same problem and this exact same solution just yesterday ?

[JimmyDansbo]

I ran into the same issue (and solution) when I created the IRQclock program...

https://github.com/JimmyDansbo/cx16stuff/blob/master/irclock.asm#L109

[TomXP411]

Funny... I was just thinking about this yesterday, as well... but from a different perspective. Someone was talking about using conio commands in C, and it occurred to me that ISRs (interrupt service routine) might write to VERA while you're in the middle of another process. 

So I guess it's doubly important to make sure interrupt handlers always back up the VERA registers before making any changes - not just for their own use, but to protect running software and protect the transparency of ISRs. 

 

[m00dawg]

47 minutes ago, Guybrush said:

You could possibly set your code up in such a way that VRAM access uses port 1 and sound register access uses port 2.

This is what I decided to do, although I'm not sure this would completely solve it in all cases. It's solved it for me - so far anyway. Of note, VERA PSG does require a lot of CPU support to make chippy sounds (due to software envelopes) so I can see communicating with VERA to be a very common occurrence as a result.

[The 8-Bit Guy]

1 hour ago, Guybrush said:

You could possibly set your code up in such a way that VRAM access uses port 1 and sound register access uses port 2.

Excellent idea.  I hadn't considered this.  It would still require changing the data port before and after the IRQ runs, but that's probably less code and CPU cycles than backing up the registers.  

[Guybrush]

17 minutes ago, The 8-Bit Guy said:

Excellent idea.  I hadn't considered this.  It would still require changing the data port before and after the IRQ runs, but that's probably less code and CPU cycles than backing up the registers.  

It would only require changing the CTRL register's ADDRSEL bit to set the active port while reloading the address registers but that's just one register instead of three.

If you don't use any of the KERNAL's graphics functions then you have complete control of the VERA and you can be sure that nothing else is touching the address registers and the CTRL register. Then you can simply do LDA #$01, ORA $9f29 when you enter the interrupt handler and LDA #$FE, AND $9f29 before exiting. That's just 12 cycles  instead of 15 when using the stack.? I know that's not that important on Commander X16 compared to C64, but I just can't help myself ?.

[Greg King]

48 minutes ago, Guybrush said:

It would only require changing the CTRL register's ADDRSEL bit to set the active port while reloading the address registers, but that's just one register instead of three.



If you don't use any of the KERNAL's graphics functions, then you have complete control of the VERA, and you can be sure that nothing else is touching the address registers and the CTRL register. Then, you can simply do LDA #$01, ORA $9f29 when you enter the interrupt handler, and LDA #$FE, AND $9f29 before exiting. That's just 12 cycles instead of 15 when using the stack.? I know that's not that important on Commander X16 compared to C64, but I just can't help myself ?.

You don't need even that much.  Just do "inc $9F25" when starting the ISR.  And, "stz $9F25" when leaving the ISR.  (The DCSEL bit is irrelevant.)

[DusanStrakl]

Yup had the same problem when I wrote music library for BASIC programs. Of course I had to back up registers because I had to allow the default IRQ handler to take over after I was done playing with PSG (pun intended ? ) and of course BASIC programs print, draw, scroll, etc.