Question to Atari 400/800 owners about keyboard behaviour

[rubeon]

Hi, Atari Age

 

tl;dr: When you boot up your trusty ol' Atari 800, can you type at speed without losing keystrokes?

 

I've noticed an issue when using some Atari 800 emulators and the otherwise excellent MiSTER Atari800 FPGA core:

 

When you type quickly, keystrokes tend to get lost.  This only seems to happen when touch typing. My theory is that key-down and key-up events overlap, for example when typing "the" you'll hit the "h" before you've completely released the "t" key.

 

This is admittedly sloppy typing but something that modern keyboards and OS's have no issue with. Interestingly, this affects the venerable atari800 emulator but not the Atari800MacX emulator on macOS.

 

I've opened up a GitHub issue for the MiSTER Atari 800 core, but can't be sure how the original hardware behaved without some input from people who actually have it!

 

 

 

[Sugarland]

Yes one can type reasonably fast on real hardware. There is a one keystroke buffer if the computer is not yet asking for input. I think PC's back in the day had a six keystroke buffer and would beep if the buffer tried to overfill.

[Rybags]

The problem is how the key scan works.  2 keys simultaneous is invalid but pretty rare, generally one will strike first and be registered.  But unlike other keyboards you need to relase a key before the next one is detected.  For really fast typing this can become an issue.  But it's much less prone to ghosting like some others e.g. C64.

[rubeon]

Thanks for the feedback, all.  I would be very interested to hear what (if anything) @atarimac might have built into Atari800MacX to address this, and whether that could be useful for the MiSTer Atari 800 core devs. 

[thorfdbg]

Actually, atari++ has a "typeahead" input buffer to address this issue. The emulator collects keystrokes, but then feeds them one by one into the virtual machine at the speed it can take them.

 

[Rybags]

The lack of buffering on real machines is probably secondary to the limitations of the hardware scanning.

As for feeding keystrokes - there's a limitation there as well since the generated keyclick is done in software and uses 100% of the foreground CPU - in addition to the expected lag of E: processing.

 

I did a key buffering program once but in the days of low Ram which meant it wasn't very useful.