Remind me about the keyboard glitch?

[+therealbountybob]

I might (might be something else I've done) have an issue with the pause routine: keyboard input (space) crashing the display list/game (Ski-It - vertical scroller). I seem to remember this being an issue - Is there something I need to do? I'm currently leaving the VBI/DLI active while paused but flagging off the scroll.

 

Thanks

[Wrathchild]

have you switched out the O/S and providing your own $FFFx values whilst that is happening?

[+therealbountybob]

have you switched out the O/S and providing your own $FFFx values whilst that is happening?

as I don't know what that is I'm guessing not!! fire away

[Rybags]

If the key press IRQ occurs just before VBlank then the stage 2 VBlank processing can be skipped which means most of the shadow register processing is also skipped.

 

Some Display Lists will falter - I don't know if it's some bug in Antic or otherwise but even a perfectly valid DList will sometimes not properly loop back to itself but it goes unnoticed since the OS usually takes care of it in the VBlank NMI.

 

An alternate method could be to just disable keyboard IRQ and process key input by reading the KBCODE register in conjunction with doing key down/up/debounce processing via the SKSTAT flag indicating if a key is pressed.

[flashjazzcat]

Doesn't the OS keyboard click hit WSYNC? Not sure if that's a factor here, but mainline code writing to that register can mess up DLIs if things happen at just the right (wrong) moment.

[phaeron]

Keyclick only hits WSYNC on OS-B. XL/XE OS uses VCOUNT.

 

Stomping POKMSK by accident is another way to introduce a bug like this. It won't be noticed until an IRQ fires, usually the keyboard, after which the timer IRQs go hot and fireworks ensue.

[+therealbountybob]

Thanks everyone - I've had a quick look at this,

my original pause routine checked CH compated it to $21 (space) etc

 

using KBCODE in the same way and then checking it for another value (another key) to exit works ok - without using SKSTAT - is this ok?

 

What about the "disable keboard IRQ" bit?

 

I'll check if I'm doing anything with POKMSK too thanks.

[Rybags]

KBCODE holds the keycode until it changes by another keypress or disabling key scan.

 

The problem there is you can't detect extra presses of the same key without using SKSTAT.

[+therealbountybob]

I've just tried using SKSTAT only as I could see that KBCODE could not be cleared (unlike with CH) so someone could press pause on the title screen and the key would be carried.

 

SKSTAT <>255 (any key) pause, delay loop so key has been released, then check it again to exit. This works fine (still leaves the slow motion effect if held).

 

Still leaves the question about disabling the keyboard IRQ? Mapping the Atari's index has IRQ Keyboard controller @ 54016 ($D300) but this is PORTA and doesn't seem to be the right thing?

 

Thanks

[StefanD]

If you don't use POKMSK for your own purpose, you can do this:

 

LDA POKMSK ; $10
AND #$BF
STA POKMSK
STA IRQEN ; $D20E

 

This clears bit 6 of IRQEN, which disables the keyboard IRQ.

Edited August 9, 2018 by StefanD

[phaeron]

The reference to the keyboard controller for PORTA in Mapping the Atari is for the mini-keyboards like the CX-50 that plug into the joystick port, not the main keyboard on the computer. They're pretty neat devices, by the way; you can reliably detect two simultaneously pressed keys on them.

 

There are other bits in SKSTAT besides the key down bit, so checking against 255 is a bit unsafe. At the very least, make sure you write to SKRES ($D20A) at least once at startup to make sure that the keyboard and serial error bits are reset. You'll still have to put up with the Shift key bit. If you're using assembly, there's no reason not to test only the key down bit.

 

If you're going to disable the keyboard IRQ, consider whether you want the break IRQ either, or any IRQs at all. A viable option is to mask all interrupts on the CPU but leave them enabled on POKEY; this still allows your main loop to periodically check for key downs without missing any.

[Rybags]

Also forgot to mention - if doing keypress by KBCODE and SKSTAT you'd also want to do debounce processing.

Essentially that is, keep a copy of "previous" keydown condition's keycode and compare with "current".

If they're the same, then ignore the keypress if it's less than 4 frames after the previous one.

[R0ger]

Can someone confirm the debouncing is really needed ? I know everybody says it is. But we did some tests, and couldn't really encounter situation where it would be needed, tested on like 5 machines, both XL and XE. Is there some more info on it ?

[+therealbountybob]

Can someone confirm the debouncing is really needed ? I know everybody says it is. But we did some tests, and couldn't really encounter situation where it would be needed, tested on like 5 machines, both XL and XE. Is there some more info on it ?

Can you expand on this please?

 

The reference to the keyboard controller for PORTA in Mapping the Atari is for the mini-keyboards like the CX-50 that plug into the joystick port, not the main keyboard on the computer. They're pretty neat devices, by the way; you can reliably detect two simultaneously pressed keys on them.

 

There are other bits in SKSTAT besides the key down bit, so checking against 255 is a bit unsafe. At the very least, make sure you write to SKRES ($D20A) at least once at startup to make sure that the keyboard and serial error bits are reset. You'll still have to put up with the Shift key bit. If you're using assembly, there's no reason not to test only the key down bit.

 

If you're going to disable the keyboard IRQ, consider whether you want the break IRQ either, or any IRQs at all. A viable option is to mask all interrupts on the CPU but leave them enabled on POKEY; this still allows your main loop to periodically check for key downs without missing any.

OK

I've written to SKRES in my game setup and disabled the anykey IRQ

My pause routine is now check the SKSTAT bit for a key press - pause if pressed - quick delay loop, check it again to exit pause - quick delay - resume game. this works fine, not using KBCODE at all. I'm not concerned which key is pressed.

 

Not that I need it for this game but Is there a performance benefit from disabling these IRQs?

[Rybags]

I've done stuff without debounce and got annoying double registrations sufficient to make it worth the effort to add it.

 

Check the OS key IRQ and code in the VBlank - it's not much extra work and could be made shorter. Also note the OS key IRQ is bloated as they left in the 1200XL F-key processing.

[phaeron]

Need for debounce varies between systems, probably largely on the condition of the key contacts. I've never had a problem with regular keys, though I have managed to just barely detect some bouncing on console buttons -- false bounce maybe 1 out of 20 attempts. POKEY already does some debouncing itself on the regular keyboard, which helps reduce it there. Doesn't hurt to add it.

 

As for IRQ performance, they'll eat a couple of scanlines when they run, but with only the keyboard IRQ active the user can't spam keys fast enough to make any real difference. The keyboard scan hardware can't flag keys faster than about once a frame. Your mainline code should be able to tolerate that small amount of variance anyway as different OSes vary slightly in interrupt overhead.