CPC interrupts, frame flyback, keyboard scanning and... overscan

[zhulien]

I have a couple of questions i hope someone just knows the answer from the top of your head.

Let's say I wanted to code a terminal in overscan without using firmsare for keyboard scanning.  I can understand the hardware keyboard scanning examples on CPC Wiki, but they are more detecting keypresses than typed keystrokes. What is the best way to detect two of the same keypresses vs holding a key down? I am guessing to sample the keyboard periodically, note when i got zero bits, then sample it again, but that is fine, for when keys are not held down. Maybe I can get away with that.

For overscan, what is the most efficient overscan resolution from a fast sprite drawing perspective (or even fast text drawing), or am I best to lookup a 16bit value from a table as to when the line address starts?  I'd like to use a form of compiled sprites.

For interrupts, if the CPC has them disabled for a prolonged timeframe and re-enables them, what is the timeframe for the first one to come in after re-enabling, is it random or immediately, or approximatly the same?

With frameflyback, let's say interrupts are disabled and I want to periodically check for frame flyback, let's say at the start of a game loop - i test no frame flyback, should i wait until I get one, or continue with non-paint logic if there is none? If waiting, it is only the first wait period that I waste CPU time correct? If I get almost a 50th of a second processing done between checks, then I would minimise CPU wastage?  If I skip frame flyback then I regain no wastage for that cycle but risk screen tearing depending on what I am doing with the screen?

[McArti0]

What is the best way to detect two of the same keypresses vs holding a key down?

You must count the time you press each key.

[McArti0]

For interrupts, if the CPC has them disabled for a prolonged timeframe and re-enables them, what is the timeframe for the first one to come in after re-enabling, is it random or immediately, or approximatly the same?

GA counts hsync pulses. When it reaches 52, it interrupts. If you execute the DI command you do not turn off the counter in GA. Thats all. Almost.

[arnoldemu]

1. keyboard. As McArti0 has said. You detect when the key up/down state changes and count the number of frames/times you check. A key held down would be up->down followed by x frames of your choice depending on how it feels responsive to you. Two key presses will be up->down for 'a' frames->up for 'b' frames->down for 'c' frames->up for 'd' frames. So you decide if the number of frames you count determines a press or hold (plus based on up/down state).  If key is held then you can decided how many frames it is down for before repeating starts and how many frames for each key repeat. So you handle ALL how nice it feels to type etc.

2. Depends on how you do overscan. If it's 32kb method then set the screen base to be a value so that the transition from one 16kb bank to the next is on the left or right most side of the screen and store a table of each scanline. It depends on the screen width you choose (48 is best for all crtc). to find out best offset poke the last byte and line that up with left/right. e.g. if 32kb screen is c000-ffff and 0000-3ffff, poke &ffff,&ff and you will see where the transition to the next 16kb will happen.

3. if you hold it long enough the interrupt request will be pending, as soon as you enable ints again it'll happen but the next int may be offset by some lines time. You will end up with less ints per frame so if you are counting them for timing take that into account.

4. that is your choice. Personally I wait until it starts. yes if you do all the work within 50th of a second you can minimise cpu wastage, but also if that's not enough fit it all within 25th of a second. yes if you skip the frame flyback check you risk things going to fast and potentially things being uncontrollable and timings will be off (depends on how much you are doing), you risk potentially any animation frames not being shown if you happen to draw multiple before it's scanned to that point. If you are not double buffering you always risk tearing and flickering, but one way is to erase a line in old place and draw a line in new place that will minimize the flicker.

[zhulien]

Let's say in a terminal case, I guess it's u likely I would need to update very fast anyhow, either due to a new character typed or a scroll.  Probably I am best to keep a dirty flag and refresh the screen after x freshest (x being what feels reasonable) as I would be doing full screen redraw but irregularly (compared to a game).

[Bread80]

Section 3.1 of the firmware manual explains the debounce strategy it uses:

3.1 Keyboard Scanning.

The keyboard is completely software scanned. This scan occurs automatically every fiftieth of a second (see KM SCAN KEYS). The keyboard hardware is read and a bit map noting which keys are pressed is constructed. This bit map is available for testing if specific keys are pressed (see KM TEST KEY). As the bit map is constructed keys that are newly pressed are noted and markers are stored in a buffer until needed. If no newly pressed keys are found then the last key pressed may be allowed to repeat if it is still down (see section 3.5). The keyboard is 'debounced' in that a key must be released for two consecutive scans before it is marked as released in the bit map. This 'debouncing' hides multiple operations of the key switch as it opens or closes.

At this stage only four keys are treated specially. The two shift keys and the control key are not stored in the key buffer themselves. Instead, when any other marker is stored the states of the shift and control keys are noted and put into the buffer as well. The escape key generates a marker as normal but may also have other effects depending on whether the break mechanism is armed (see section 3.6).

There is a problem with scanning the keyboard. If three keys at the corners of a rectangle in the key matrix are all pressed at the same time then the key at the fourth corner appears to be pressed as well. There is no way to avoid this problem as it is a feature of the keyboard hardware. All key combinations used by the firmware (and the BASIC) have been especially designed to avoid this effect.

[zhulien]

Thanks, quite heavy processing for just a typable keyboard. Thr scan to generate the bitmap is reasonable. Maybe I can forgot the auto repeat to simplify scanning a lot.

[Anthony Flack]

It might sound complicated but it doesn't actually have to do very much on any given frame. And the keyboard matrix itself is only ten bytes long.

Are any keys being pressed?
NO> Done.
YES> compare the new keyboard matrix to the previous frame's keyboard matrix:
Are there new keys being pressed?
YES> Type any new letters. Zero the counter. Store the last letter. Done.
NO>Has the counter reached max?
NO>increment counter. Done.
YES>Retype the last letter. Done.

That should be pretty fast; it does almost nothing on most frames.

[andycadley]

By the time you do everything else that's necessary to make typing work well (debouncing, handling multiple key presses at once, mapping key presses onto the correct symbols etc) the logic required to make key repeats work is pretty trivial.

[McArti0]

Each keyboard scan is 10 times writing to F6ff,0-9 and 10 times reading the F4ff byte from AY IOA and it needs to be written XOR of reading from memory and the F4ff IOA port. XOR means changing to a key bit, pull up or down. This XOR and AND last mem value means pull- down

Ps. Keyboard scan in Amstrad firmware does not interpret key numbers.