[Coco] CoCo 3 keyboard interrupt

[Joel Rees]

2018年10月26日(金) 8:04 William Astle <lost at l-w.ca>:

> 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.)
>

That sounds like a good possible description of a poor design.

Interrupts for unbuffered, undecoded keyboards is generally not a good
idea, really, even for using them as game controllers. If you were to have
a keyboard interrupt, you'd want it to interrupt on every transition of any
of the keyboard pins, but you'd want the transitions properly debounced so
that switch noise wouldn't tie up the CPU.

Not having the interrupt status cleared until every key is released will
prevent rollover. I'd hope that the port mode can be set to do something
else.

But, really, it makes the most sense to just poll the state once every
vertical blank, using three vertical blank periods for debounce, decoding
keypresses from a mapping table and memory of previous presses. But I don't
think that is what the BASIC ROM does.

Actually, for tight response time, the ideal blanking period would be about
half the vertical blank rate, but that would also increase the burden on
the CPU.

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.
> >>
> >>
> >
> >
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>