SETVBV for VKEYBD

[flashjazzcat]

Quick question as I'm just smartening up some code. Which vector number does one load into the accumulator when setting VKEYBD using SETVBV (if indeed it's possible to set VKEYBD in this way)?

[drac030]

Why do you need SETVBV to change VKEYBD? This procedure is only needed to change VBL vectors.

[flashjazzcat]

Hmmm... I think I may have drank too much coffee today. I was trying to keep things ultra-tidy by not hacking any vectors while leaving the interrupts enabled, but thinking about it, I imagine the chances of anyone striking a key at the precise moment I'm mid-way between changing the LSB and MSB of the interrupt vector are slim at best. But, out of interest, can it be done anyway? VBI stage 1 and 2 have a vector number, as do - I assume - the timers. Does VKEYBD have a vector number?

 

...looking at Mapping the Atari, I guess it doesn't.

Edited September 14, 2009 by flashjazzcat

[Rybags]

SETVBV only deals with the VBlank Vectors and the vectors for the software Countdown Timers.

 

If you're changing the Keyboard vector (or any other IRQ vector for that matter), just use SEI, change the vector, then CLI.

[flashjazzcat]

Yup that's what I'm doing: just wondered about other ways of doing things, that's all.

 

...actually, on the subject of interrupts, I hadn't realized that DLIs can be kept rock steady during disk I/O by updating the hardware colour registers in the stage 1 VBLANK. No idea why I hadn't tried this before, but it means my 2 black status lines can show information during I/O. I wonder if there's a point at which multiple DLIs (mine is only one simple interrupt) cause problems with I/O activity? For some reason I was under the impression that SIO routines upset even short DLIs, but it's obviously not the case.

Edited September 14, 2009 by flashjazzcat

[Rybags]

There's also the "safe" save/restore method.

 

Sometimes we want to just "borrow" a vector for a time, then put it back how it was. The problem is, if the vector is already "borrowed", then we might just restore it back to the same thing.

 

I've found this approach to be pretty good: e.g. for the Immediate IRQ Vector.

 

 sei
 ldy vimirq+1
 cpy #$c0     ; is it within the OS?
 bcc dontsave ; If not, don't save the vector because we already own it.
 ldx vimirq
 stx save_vimirq
 sty save_vimirq+1 ; Save the vector contents so we can restore later
dontsave
 ldx #<new_imirq
 ldy #>new_imirq
 stx vimirq
 sty vimirq+1    ; Set VIMIRQ to our routine
 cli

; do our stuff which needs immediate IRQ service
; then put VIMIRQ back to what it was

 sei
 ldx save_vimirq
 ldy save_vimirq+1
 stx vimirq
 sty vimirq+1
 cli

[Rybags]

Looks like the single quote upsets [ code ] colours, must take it as a comment...

 

The XL OS actually stores the PF1 colour in the early VBlank, fairly sure the older versions don't.

I forget why it does that precisely, but pretty sure it's to do with the Fine Scrolling option for Gr. 0.

 

You should also note that the pre-XL OS doesn't allow DLIs during SIO. You can overcome that easily enough by just re-enabling them in a Stage 1 VBlank routine. Of course you might encounter a slight glitch where a single frame might miss a few DLIs in between.

 

The number of DLIs that SIO could cope with... depends on what SIO rate's in use, and how long the DLIs themselves are.

I'd imagine you could have a text screen with a DLI on every line, and it should cope as long as they're kept short.

 

I experimented a bit with it years ago, but decided against using them because I experienced the odd occurrence where the I/O would stop and you'd either need to hit Break to get it going again, or wait ages for it to timeout and retry.

[flashjazzcat]

Yes indeed: been doing something similar for a long time. My revised I/O-proof DLI didn't work for a time until I realized the custom immediate VBI wasn't being installed because the keyboard buffer that uses it was turned off. The revised code looks like this:

 

INITVBI ; SET UP VBI
LDA NMIEN
PHA
lda #0
sta NMIEN
sei
BIT BUFFERFLAG ; IS BUFFER ON?
BPL NOKEYBUFFER
lda VKEYBD+1
CMP #> KEYINT
BEQ NOKEYBUFFER ; ALREADY INSTALLED
sta KEYVEC+2
lda VKEYBD
sta KEYVEC+1
lda #< KEYINT
sta VKEYBD
lda #> KEYINT
sta VKEYBD+1
NOKEYBUFFER
LDA VVBLKI+1
CMP #> VBI
BEQ VBIDONE
STA VBIVEC+2
LDA VVBLKI
STA VBIVEC+1
lda #< VBI
sta VVBLKI
lda #> VBI
sta VVBLKI+1
VBIDONE
PLA
sta NMIEN
lda #0
sta KEYPTR1
sta KEYPTR2
cli
rts

I've always taken pains to adhere to the "borrowing" methodology because it makes applications live in harmony with TSRs and DOS extensions. Temporarily disabling the SDX TDline proved quite a challenge in this respect, but was eventually resolved by temporarily pointing the stage 2 VBLANK back to the OS routine.

[flashjazzcat]

The XL OS actually stores the PF1 colour in the early VBlank, fairly sure the older versions don't.

I forget why it does that precisely, but pretty sure it's to do with the Fine Scrolling option for Gr. 0.

 

You should also note that the pre-XL OS doesn't allow DLIs during SIO. You can overcome that easily enough by just re-enabling them in a Stage 1 VBlank routine. Of course you might encounter a slight glitch where a single frame might miss a few DLIs in between.

 

The number of DLIs that SIO could cope with... depends on what SIO rate's in use, and how long the DLIs themselves are.

I'd imagine you could have a text screen with a DLI on every line, and it should cope as long as they're kept short.

 

I experimented a bit with it years ago, but decided against using them because I experienced the odd occurrence where the I/O would stop and you'd either need to hit Break to get it going again, or wait ages for it to timeout and retry.

Fortunately the software isn't designed to run on the 800 anyway (sits under the OS). It amazes me that for twenty years I thought DLIs were more or less a no-go during SIO activity until I looked at the T-EDIT text editor today by pure chance. The author talked about keeping the DLI steady by updating the colour registers during the immediate VBI. Prior to today, my program had totally disabled DLIs during I/O and blanked out the area of the screen below the interrupt line. Removing this code has saved a hell of a lot of space, simplified the program, and improved presentation.

 

I guess as far as intermittent SIO freezing is concerned, I'll just have to test it some until I'm satisfied it's reliable. )

[Rybags]

LDA NMIEN

PHA

 

I don't get why you're doing that... NMIEN is Write-only.

[flashjazzcat]

LDA NMIEN

PHA

 

I don't get why you're doing that... NMIEN is Write-only.

I was going to ask about that too: I've left it in through habit (obviously borrowed from somewhere fifteen years ago). Now you mention it, it makes no sense.

 

...more to the point, is modification of NMIEN needed at all? Or will a SEI/CLI do?

Edited September 14, 2009 by flashjazzcat