It's typical to need to subtract 2 from timer durations with the 6522 because the interrupts and automatic timer reloads happen during the clock cycle after the "-1" count - I've been using this in a BBC Micro recently to keep video special effects in sync with the vertical refresh.

So for example in this 50Hz video system, using timer 1 in free running mode I need to set the latches to 19998 rather than 20000 to wait a whole frame.

But looking at the datasheet this isn't meant to be the case for pulse-counting mode - the diagram clearly shows IRQB falling when the count reaches zero.

I'd still expect it to be delayed based on the system clock, but presumably the keyboard clock rate is much slower, so the system clock delay (and IRQ processing time) shouldn't be significant.

Note that if your IRQ handler is busy when the next interrupt arrives then it will respond to it late.

Agreed! Ben Eater's kb driver I'm using is doing way too many things in the ISR - and I bloated it with even more code to handle extended keys.. It's easier to handle if the scan code to ascii conversion happens in the IRQ but that does mean I have to do the juggling first. Or I can skip the juggling and reverse the keymap.
Until it works reliably I'll probably leave it the way it is.



My guess would be the "other" keyboard IRQ could be messing with it... Hmm...

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

I managed to simplify the code a bit but I'm still not getting 100% reliable data.
If I don't disable the shift register during the T2 ISR, the data doesn't match for some reason - I don't understand why.
I think I noticed the mode011-bug too and that only seems to happen 1/50 shifts (that's what it feels like anyway), so that doesn't explain why data isn't reliable. The ISR now consistently samples the SR at the same point of the same PS2 clock cycle - the SR just seems to contain bad data sometimes...
Could also be hardware/noise I guess? The PS2 lines have pullups but otherwise it's connected straight to the USB connector (and the clock line connected to both PB6 and CB1)

On a 6502 interrupts don't get interrupted, right?

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Going back to my question about edges, it sounds like the 6522 shift register samples the data signal somewhat after the rising edge of CB1, but the PS2 keyboard protocol requires you to sample at the falling edge of the clock. When the PS2 clock is high the keyboard will be transitioning the data line to the right state for the next bit, and the data that's shifted in will be inconsistent. You need to invert the PS2 clock to provide a good signal for CB1, with the rising edges in the right places.

The 6502 sets the interrupt disable flag when running an ISR, so further interrupts will be delayed until either your ISR returns, or you clear the flag explicitly. At that point, if the IRQB line is still low, the CPU will enter the ISR again.

Your ISR is quite long, with all the rotates - I think they cost something like 5 cycles each, so that's at least 80 cycles just for the rotates. (Rotating the A register instead of a memory location is faster.) The PS2 clock is about 15kHz usually, its period is probably 50-100us. So if your CPU clock is slower than a few MHz, bear in mind that these are comparable durations.

When the timer interrupt fires, you need to read the SR within that PS2 clock period, before it shifts again. If the CPU is stuck in another interrupt then it could miss this unless you keep all your ISRs very short.

The zero page ROL was a brain fart XD But if I go this way it won't matter as the keymap should match instead of juggling.
Inverting and without the long ISR sadly didn't make much of a difference. I'm still getting bad data - like 1 bit off every second or third keypress, more often than not only 1 nibble is incorrect(?).
Shifting and sampling seems to happen at the correct time, but the data doesn't agree (see screenshots attached).

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

What are the signals hooked up to the oscilloscope in each trace?

I would:

• not disable the SR - leave it active all the time
• read twice, capturing all the bits, storing two bytes separately
• read from the SR as soon as possible in the ISR, to reduce the chance that it shifts again before you read from it
• maybe initially just make the ISR read and store the bytes in a buffer so you can inspect them afterwards, check that works well first before you try to automatically check or decode them

On point 2, if the keyboard sends for example $74, I believe that's encoded as 0:00101110:1:1 so if you read the shift register after bit 8 and again after bit 11 then you should get 00010111 followed by 10111011, with five bits overlapping. You can check successful reception in a lot of ways based on this - the start bit, the stop bit, the parity bit, and the 5 overlapping bits between the two bytes.

One option for timing your reads is to let the SR interrupt fire after 8 bits, using that to trigger the first read, and use T2 to count 11 bits to trigger the second read. It may be simpler than resetting T2 in a hurry during the transmission and allows you to use two fairly separate routines for handling the two types of interrupt.

Something else to consider is framing - making sure you are reading the 11 bits in sync with the keyboard, not offset. You could deliberately skip an extra bit if the parity, start, or stop bit checks fail, for example, to make it self-correct. Another approach could be using T1 to flush the system after an appropriate delay, which would probably be quite a reliable catch-all solution.

First and foremost though, going back to point 4 above, I'd probably start by just setting up to read the SR based on its own interrupt after each 8 bits, make a simple ISR that just captures the first 256 eight-bit sequences into a buffer, and inspect the data by hand to make sure the electronics side is all sound. This will cover things like the clock edge issue, and perhaps the external clock bug in the 6522. Then you could go back to more complex processing.

Thanks for the help, G! I tried most of your suggestions but eventually decided to fix what I knew needed fixing anyway.

Turns out the mode011-bug was more common than I thought. Adding a 74'74 immediately solved the issue and since the bit is shifted in on the rising edge the inverter isn't needed - I believe PS/2 data doesn't change until somewhere near the end of the high time anyway.
I still need to disable the shift register to make it work though. If I remember correctly the IRQ flag is still set, even it is disabled and doesn't pull down ~IRQ - so maybe some other IRQ flags need handling. When doing a quick check I see CB1 and SR flags set even though they are disabled.

My SBC looks so naked with PORTA unpopulated XD



The scope capture is PS/2 clock and the debug bit 8 on the $5000 output register. The ISR is horribly long but when I convert the keymap to LSB in MSB the juggling is fixed.
It's a bit frustrating that the '74 also breaks sending data to the keyboard - now I need to add a 74'126 tristate buffer if I want two way transfer.. But I guess it's still better than two '595's a '14 and a few passives.

Still some grunt work to do...

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

That might depend on the specific keyboard model. But since you've got the 7474 in there, you can just use its inverted output to avoid needing a separate inverter.


That really shouldn't be necessary so long as you read the actual shift register data swiftly within the ISR. But I guess in your case you aren't interested in the following bits (the parity bit and the stop bit), so don't mind just turning it off and losing them. As I said if it were me I'd rather read all of the bits and use them to check for errors (they're there for a reason!) but it's up to you.


The flags in the IFR still get set even if their interrupts are disabled, so for example you can use them to poll for these events. Clear them by writing the corresponding bit back into the IFR. Note that what you write back is a mask listing which bits you want to clear - so to clear bit six (timer 1's bit) you'd write $40 to the IFR (the same value you AND or BIT with to test the flag when reading).

Most flags also have an alternate, more automatic way to clear them, e.g. for the shift register, any read or write of the shift register from the CPU side will clear its IFR bit.


Even when sending, the keyboard provides the clock signal. For host-to-device communication the device reads on the rising edge of the clock, not the falling edge - but that should make life easier for you because it means that the host should shift out new data on the falling edge, so that it's there in time for the rising edge. Essentially as far as I can tell all host activity should happen on the falling edge and all device activity happens on the rising edge.

Good point! No need to ignore spec when it's free



Well, actually I don't lose the bits - the SR is re-enabled before the next high edge anyway, so something funny must be going on. I could rely on the SR IRQ, read the 8 bits, use TM2 to fetch the last three bits and restarting but it seems a bit clunky unless I'm missing something obvious?




Interesting! So that's just mode111 with a prepopulated SR? Only downside I see is that CB1 needs to be pulled low by a third pin(PB6 I guess) to start the transaction and then immediately loading the SR to reset the SR counter. I guess that's not a problem when it's on the other side of the '74 if you know what I mean.

I decided to postpone the keymap rewrite to stay mostly backwards compatible - instead I went with 256 bytes for a reverse bits LUT. ISR just got a lot skinnier without the juggling.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Something irregular is certainly going on if I don't disable the SR and re-enable. It only happens after the first key's release command and only if the SR isn't disabled and reenabled - it looks like spurious clocks for no reason and breaks framing.



I will stop fighting this bug now and just use this workaround, but I wonder if anyone has an idea - I haven't tested if the spurious clocks are also coming from the KB or it's the SR suddenly clocking.

Either way the above code works perfectly - t2 is initialized with T2LL as 8 and kbshift is 10. Both are one count lower than I'd expect though.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

I interface to PS2 in hardware CPLD. I found it necessary to have a time-out logic where the internal state machine reset to state0 if PS2clock is high for more than 2ms. Otherwise the state machine may count spurious clock and latching in the wrong value. I also found it necessary to sample PS2Clock twice to 'de-glitch' the slow rising PS2Clock. Software implementation may also need the equivalent double sampling and reseting states.

PS2 keyboard is powered by mini-DIN connector over a long cable and PS2Clock is pulled up via 2.5K resistor over the same long cable, so noisy signal is not unexpected.
Bill

I was thinking something similar. However the glitch is too consistent to be noise - only after the second packet after 6502 reset and I think even the same clock count every time.
Maybe the KB is expecting to receive data and starts clocking - even though clk hasn’t been held low.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

This journey prompted a rant on my project log.

For those interested: https://hackaday.io/project/184725-abn6 ... in-sharing

Spoiler: Pin sharing was not the cause of the issues above in this thread

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

An excellent moral to that story - thanks for sharing it!

Turns out I'm not happy with this after all. When trying to actually write more than just a command or two it doesn't take long before an error creeps in - and resetting the keyboard isn't really possible without disallowing user input for a frustrating moment or two. Error detection is also a pain - sure, a character I haven't mapped is probably an error but it's just not reliable. I really need that parity bit after all.

New idea. PS/2 data is 11 bits that dont fit nicely into the SR. Interrupting after every bit is horribly inefficient. That won't work. And an IRQ after 8 shifts isn't horribly helpful when it's not the bits I need.
However... I don't really care about the stop bit - or the start bit - so instead.. maybe setting the PB6 counter to 5 instead of 11 will give me all the bits I'm interested in if I manage to waste the stop bit correctly.

Better idea? I hope so..

There's a bunch of ways to parity check but I'm not sure which I like better. Any suggestions?
https://archive.nes.science/nesdev-foru ... 3225.xhtml

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1