[Coco] CoCo 3 keyboard interrupt

[William Astle]

Okay, this whole thing was bothering me so I dug out a real Coco3 and 
did some testing in Basic. I found some interesting behaviour which 
tells me the keyboard interrupt operation in the GIME is more 
sophisticated than write-ups indicate.

The program I used is:

10 POKE&HADEB,&H39
15 POKE&HFF02,0
20 POKE&HFF92,2
30 K=PEEK(&HFF92)
40 IF K AND 2 THEN PRINT ".";
50 GOTO 30

This prints out a "." every time the keyboard IRQ status bit is set in 
FF92. Naturally, it polls fairly slowly but one can learn some things by 
pressing and releasing keys.

Line 10 disables the BREAK check so that the BREAK check doesn't mess 
with FF02.

Line 20 is apparently required even if you aren't actually using the IRQ 
itself. Otherwise, it doesn't report the status. That means the results 
of reading the IRQ and FIRQ status registers are an "AND" between the 
interrupt sources and the enable bits. That means there's probably 
another bug in MAME if it doesn't do that, though such a bug would 
probably be harmless.

What I learned using strategic edits to the above program:

* Some strategic pokes into FF20 suggest that the comparator input (bit 
7 of FF00) isn't tested. However, I don't have a joystick so I can't 
test that properly.

* The setting of FF02 matters. If set to 255, the keyboard interrupt 
does not fire (except for probably the joystick buttons which read even 
if no columns are enabled).

* The keyboard interrupt fires exactly once after the keyboard bits in 
FF00 change. After the status is cleared (by reading FF92), the keyboard 
interrupt status is not reasserted, even if more keys are pressed, until 
ALL keys are released at which time it is asserted again. This assumes 
that FF02 is 0. If it's set to something other than 0, the subset of 
keys that count depends on which columns are enabled.

* Changing FF02 such that no columns are enabled (setting to 255) while 
no joystick buttons are pressed will fire the keyboard interrupt since 
FF00 will go to all ones. The same thing occurs when setting FF02 so 
that all active columns have no keys pressed. Thus, a keyboard scan will 
almost certainly cause the the keyboard interrupt status to be 
reasserted. This is probably why the ROM wasn't modified to use the 
keyboard interrupt.

The practical upshot of all this is that I think the keyboard interrupt 
works as follows:

The values of bits 0-6 of FF00 are ANDed together to form a status 
input. Then, the previous (latched) status input is XORed with that to 
decide if the keyboard interrupt should be asserted (in FF92/3). The new 
status is obviously then latched. (I expect that's easier done than said 
at the electronics level.)

On 2018-10-25 10:16 a.m., William Astle wrote:
> The one thing I don't have is a real hardware setup (that isn't in a box 
> on the other side of the city) to make sure my understanding of the 
> behaviour of the keyboard interrupt is correct. In particular, whether 
> bit 7 of FF00 triggers the keyboard interrupt if it goes low (the 
> joystick comparator input).
> 
> I also don't have a test case I can distribute, mostly because I can't 
> be sure I'm right without testing on real hardware.
> 
> On 2018-10-25 09:49 AM, L. Curtis Boyle wrote:
>>> 2018年10月25日(木) 8:21 tim lindner <tlindner at macmess.org>:
>>>
>>>> Does any one have code prepared to test the keyboard interrupt? Or
>>>> know of a program that uses it?
>>> I’ve heard reports it is broken in MAME. I’d like to fix it.
>>
>> Tim - William Astle in the Discord group has done some specific 
>> programming with the GIME keyboard IRQ, and recently, so he may be the 
>> best to ask, as he has some test code, as well as explanations on to 
>> properly set it up and use it.
>>
>>
>> On Oct 25, 2018, at 6:43 AM, Joel Rees <joel.rees at gmail.com> wrote:
>>>
>>> Did the Coco 3 have a keyboard interupt?
>> Yes, it does. It was one of the GIME interrupt sources, and can be 
>> either IRQ or FIRQ.
>>
>>
> 
>