6522 VIA partial shifts?

[gfoot]

AndersNielsen wrote:

Edit3: This actually seems to work. My debug pin tells me it's sampling SR right before the 10th rising edge. (Which is later than what I would expect with PB6 count being set to 9 and not 10)

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.

[AndersNielsen]

BillG wrote:

If you must juggle bits, avoid doing it in the ISR if at all possible. Do it in the code putting it into the buffer or retrieving it from the buffer instead. Try to make your ISR as short and fast as you can.

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.

gfoot wrote:

AndersNielsen wrote:

Edit3: This actually seems to work. My debug pin tells me it's sampling SR right before the 10th rising edge. (Which is later than what I would expect with PB6 count being set to 9 and not 10)

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.

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

[AndersNielsen]

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?

Code: Select all

        
t2_irq:
        lda #$81
        sta $5000 ; Ouput only register debug
        LDA #%01100000
        STA ACR               ; T1 continuous - disable Shift register
        lda SR1 ;
        sta $0b ; LSB is in MSB :/

        ;No loop to save cycles
           rol $0b ; MSB to C
           ror $0c ; C to MSB
           rol $0b ; MSB to C
           ror $0c ; C to MSB
           rol $0b ; MSB to C
           ror $0c ; C to MSB
           rol $0b ; MSB to C
           ror $0c ; C to MSB
           rol $0b ; MSB to C
           ror $0c ; C to MSB
           rol $0b ; MSB to C
           ror $0c ; C to MSB
           rol $0b ; MSB to C
           ror $0c ; C to MSB
           rol $0b ; MSB to C
           ror $0c ; C to MSB

        lda #1
        sta $5000 ; OOR debug
        LDA #%01101100
        STA ACR             ; T1+T2, reenable Shift register
        lda #10 ; If we count 11(10 + one we miss?) falling edges we should end up at the same index in the shifted data
        sta T2CL
        lda #0
        sta T2CH
        pla
        rti

[gfoot]

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.

[AndersNielsen]

gfoot wrote:

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

Quote:

t2_irq:
lda #$81
sta $5000 ; Ouput only register debug
LDA #%01100000
STA ACR ; T1 continuous - disable Shift register
lda SR1 ;
sta $0b ; LSB is in MSB :/

;No loop to save cycles
; rol ; MSB to C
; ror $0c ; C to MSB
; rol ; MSB to C
; ror $0c ; C to MSB
; rol ; MSB to C
; ror $0c ; C to MSB
; rol ; MSB to C
; ror $0c ; C to MSB
; rol ; MSB to C
; ror $0c ; C to MSB
; rol ; MSB to C
; ror $0c ; C to MSB
; rol ; MSB to C
; ror $0c ; C to MSB
; rol ; MSB to C
; ror $0c ; C to MSB

lda #1
sta $5000 ; OOR debug
LDA #%01101100
STA ACR ; T1+T2, reenable Shift register
lda #10 ; If we count 11(10 + one we miss?) falling edges we should end up at the same index in the shifted data
sta T2CL
lda #0
sta T2CH
pla
rti

[gfoot]

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.

[AndersNielsen]

gfoot wrote:

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

Quote:

;kbshift initialized to $0A

t2_irq:
txa
pha
lda #$81
sta $5000 ; Ouput only register debug
LDA #%01100000
STA ACR ; T1 continuous - disable Shift register
lda SR1 ;
sta $0b ; LSB is in MSB :/

;No loop to save cycles - temporary measure until I remap the keymap.
rol ; MSB to C
ror $0c ; C to MSB
rol ; MSB to C
ror $0c ; C to MSB
rol ; MSB to C
ror $0c ; C to MSB
rol ; MSB to C
ror $0c ; C to MSB
rol ; MSB to C
ror $0c ; C to MSB
rol ; MSB to C
ror $0c ; C to MSB
rol ; MSB to C
ror $0c ; C to MSB
rol ; MSB to C
ror $0c ; C to MSB

lda kbshift ; If we count 11(10 + one we miss?) falling edges we should end up at the same index in the shifted data
sta T2CL
lda #0
sta T2CH


lda #1
sta $5000 ; OOR debug
LDA #%01101100
STA ACR ; T1+T2, reenable Shift register

;pla
;rti

keyboard_interrupt:
; Convert scancode to ascii and add to buffer here

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

[gfoot]

AndersNielsen wrote:

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.

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.

Quote:

I still need to disable the shift register to make it work though.

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.

Quote:

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.

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.

Quote:

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.

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.

[AndersNielsen]

gfoot wrote:

AndersNielsen wrote:

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.

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.

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

Quote:

Quote:

I still need to disable the shift register to make it work though.

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.

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?

Quote:

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.

Quote:

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.

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.

Code: Select all

        
        tax
        lda reversebits, x
        sta $0c

[AndersNielsen]

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.

Code: Select all

        
t2_irq:
        lda SR1 ;
        tax
        lda reversebits, x
        sta KEYBOARD

        LDA #%01100000
        STA ACR               ; T1 continuous - disable Shift register  - Seems to prevent spurious clocks 
        LDA #%01101100
        STA ACR             ; T1+T2, reenable Shift register
        lda kbshift ; If we count 11(10 + one we miss?) falling edges we should end up at the same index in the shifted data
        sta T2CL
        lda #0
        sta T2CH
; Fall through to scancode -> ascii parsing -> key buffer

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.

[plasmo]

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

[AndersNielsen]

plasmo wrote:

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.

[AndersNielsen]

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

[BigEd]

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

Quote:

Let this be a reminder: Don't spend hours trying to save one microsecond. You might be able to save the microsecond - you will never get the hours back.

[AndersNielsen]

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