Commander X16

Hi all,

Here some interesting observation for others trying to use the VIA#1 timer.

As mentioned elsewhere, I am currently trying out one of the VIA#1 timers (as you may guess, for Conerto), which uses the NMI. It works very well, except for one issue: keyboard and mouse are working very unreliably. Many key presses are dropped and the mouse jumps all over the screen.

The problem goes away if the NMI service routine (ISR) is small enough, less than around 130-140 instructions (500 ish cycles).

This points strongly into the direction of the NMI interfering with the PS/2 communication. The NMI can interrupt the normal VSync ISR, while the PS/2 port is being polled. When the NMI ISR takes too long, bytes get dropped at the PS/2 port and data gets corrupted, hence the weird keyboard and mouse behavior.



Now, I know well that ideal interrupt service routines are very concise and only do the minimum required to get the job done. Hence, not the system is to blame, but rather my own ISR.

I am currently unsure how to solve it. Not asking for help, though ? Rather putting this out here so others don't have to make the same mistake. Took me quite a while to figure out what was going on.

Thanks for the headsup .... especially since VIA#2 and the maskable IRQ is no longer going to be on the board.

Is it possible to use one of the other timers in the system? I was under the impression that there is a timer in the FM chip and a timer in the RTC chip. Maybe one or both of those can generate an IRQ interrupt rather than an NMI, so you would wrap the Kernel VBlank ISR routine with a routine that returns to poll for your timer IRQ having happened while the VBlank interrupt was being serviced.

 

On 10/20/2022 at 12:53 PM, BruceMcF said:

I was under the impression that there is a timer in the FM chip and a timer in the RTC chip. Maybe one or both of those can generate an IRQ interrupt rather than an NMI, so you would wrap the Kernel VBlank ISR routine with a routine that returns to poll for your timer IRQ having happened while the VBlank interrupt was being serviced.

Doesn't the RTC chip come in on the same I2C connection as the PS/2 connectors? Well, at least, routed through the same microcontroller. My money would be on the FM chip as being slightly more likely to support being able to generate/trigger an IRQ instead of an NMI.

At least in the emulator code, the Vera and the two VIAs are the only sources of interrupts.

On 10/20/2022 at 7:53 PM, BruceMcF said:

you would wrap the Kernel VBlank ISR routine with a routine that returns to poll for your timer IRQ having happened while the VBlank interrupt was being serviced.

That might be part the solution to my problem, actually, with some additional logic. Will report here incase it works ...

On 10/20/2022 at 4:45 PM, kliepatsch said:

At least in the emulator code, the Vera and the two VIAs are the only sources of interrupts.

Yes, I do not know whether that's the emulator not extending to the timer in the FM chip and to full emulation of the RTC, or whether they are not tied into the IRQ line. But if they are tied in, then like the VIA#2, I'd expect it to be through the IRQ line rather then NMI line.

On 10/20/2022 at 5:23 PM, kliepatsch said:

The problem goes away if the NMI service routine (ISR) is small enough, less than around 130-140 instructions (500 ish cycles).

130 instructions at 2 cycles/opcode at 8 MHz = 32.5 µs

140 instructions at 3 cycles/opcode at 8 MHz = 52.5 µs

So there's something that needs to be serviced within 32.5 - 52.5 µs.

The VIA #1 is at 0x9F00:

https://github.com/commanderx16/x16-docs/blob/master/X16 Reference - 07 - Memory Map.md

PS/2 port hangs of the VIA #1 port bits PA0 and PA1:

https://github.com/commanderx16/x16-docs/blob/master/X16 Reference - 10 - IO Programming.md

The minimum cycle time for a PS/2 data bit seems to be 60 µs.

https://retrocomputing.stackexchange.com/questions/15607/why-is-the-clock-frequency-of-the-ps-2-keyboard-protocol-so-high

Each key corresponds to 12 bit cycles to transmit. (720 µs)

https://de.wikipedia.org/wiki/PS/2-Schnittstelle

It seems like the keyboard scancode handler is polling the PS/2 bus bits using bit-banging inside an IRQ service routine. And because CB1 isn't wired? it has to be bit-banged.

By connecting PS/2 clock to CB1 and PS/2 data to CB2 maybe it's possible to use "burst" mode to read the bits? Or an external plain 16-bit shift register.

(I hope the VIA used doesn't suffer from the 6522 errata..)

Btw, the documentation memory map specify VIA #1 at 0x9F00, while the I/O programming specify it at 0x9F60..

 

Maybe some of the hardware cracks on this forum know whether the YM2151 is tied to IRQ?

Anyway, thanks @neutrino that is interesting.

And yes, I too have noticed the discrepancy in the docs. 0x9F00 through 0x9F0F works in the emulator. The other info seems outdated.

On 10/21/2022 at 12:59 AM, neutrino said:

130 instructions at 2 cycles/opcode at 8 MHz = 32.5 µs



140 instructions at 3 cycles/opcode at 8 MHz = 52.5 µs



So there's something that needs to be serviced within 32.5 - 52.5 µs.



The VIA #1 is at 0x9F00:



https://github.com/commanderx16/x16-docs/blob/master/X16 Reference - 07 - Memory Map.md



PS/2 port hangs of the VIA #1 port bits PA0 and PA1:



https://github.com/commanderx16/x16-docs/blob/master/X16 Reference - 10 - IO Programming.md



The minimum cycle time for a PS/2 data bit seems to be 60 µs.  ...

If that's the problem then it may clear up with the actual hardware, since the PS/2 port is moving to the ATTiny microcontroller (similar to the way the original IBM-PC's were handled).

 

How will the ATTiny microcontroller attach to the computer? which MCU model is it?