Hi all,
wasn't sure whether to post this in hardware or here, but most likely the bug is with my code so here it goes
I have a 6522 connected to a PS/2 keyboard. The PS/2 clock is on CB2 and the PS/2 data on PB7.
The VIA PCR is set to $00 so that I should get an interrupt on a negative edge on CB2. However I'm also sometimes getting interrupts on a positive edge on CB2, and I'm struggling to figure out why. My code only sets the PCR in the initialization and never touches it again. In case it's relevant, CA1, CA2 and CB1 are not connected to anything.
Does any one have any idea what could cause what I'm seeing ?


The blue signal is the PS/2 clock (CB2), yellow is PS/2 data (PB7) and the red one is the VIA interrupt. You can see the interrupt on the positive edge of the clock right about the middle of the image.

And here is a little bit of the interrupt code :


Thanks

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

Hmm, your scope is reading 1.2µS - that is, 1200 ns - for a rise time. I'm not sure which signal it's measuring them on, but I'm assuming it is on the CB2 line. But that is out of spec for using CB2 as any kind of an edge trigger: I interpret the datasheet figures here to mean "signal must rise or fall in one Phi2 cycle time", regardless of the Vcc voltage the system is built around; this makes sense because the VIA samples CB2 once per Phi2 cycle.

To speed up the edge, put the signal(s) from the PS/2 device through a Schmitt trigger buffer or two Schmitt trigger inverters. That will eliminate the slow rise time in which a CMOS input may ambiguously interpret the level.

Actually that's the data line (PB7) but I reckon it's similar on CB2.

Yep that's where my problem comes from, for sure.


I do not seem to have any schmitt trigger chips in my box. I will think of another way, but thanks for pointing to the cause !

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

After thinking about it I cannot put buffers or inverter on the line since the VIA sometimes has to pull the clock line low, so the hardware would get more complex than I would like.

The cable is very flimsy so I shortened it to 20 cm to try and speed up the rise and fall times (this keyboard is very bad anyway, I'm waiting for another one). I then measured the fall time on the clock at a higher resolution. It is around 100ns, which is still to high.

I will try and implement a software solution by going out of the interrupt as soon as possible if it occurs too soon after the last one.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

You can still pull the clock low by connecting it directly to a VIA port pin as well as, through the buffer, to CB2. Set the port pin to "input" when you don't need to pull the clock line, and to "output 0" when you do.

Right. All the PORTB pins are in use, though so I'll just have to be careful how I manage it on the software side.

For the time being I did the stupidest thing possible: a delay in the ISR that causes it to take longer than a PS/2 clock half period
When my 74HC14 arrive, and if the new keyboard has the same problem, I'll implement your solution.
Thanks again!

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

Hmmm, right... except you said the PORTB pins are already all in use. But there's probably a way to economize. For example: on this page, see how much functionality Garth was able to collapse onto just one VIA? (If you'd like some suggestions then tell us how your Port B lines are presently employed. I expect you can make another line available. )


Well, if you can make another Port line available then you can connect it as Chromatix suggested.
But you can also attach it without the Schmitt buffer.
Having eliminated the Schmitt buffer, you'll now condition the noisy and sluggish CLK input using software instead. At the entry to the ISR you'd have a short delay (much less than the half-cycle delay you mentioned), and its purpose is to allow a little more time for the CLK input to settle. After the delay expires you use the port line to test the level on the CLK line. If it has settled to the low state, fine -- you process the incoming bit. But if it has settled to the high state then you exit the ISR without doing anything because you know the interrupt was spurious.

Adding delay within the ISR has a cost in terms of the impact on other processing. But if circumstances make that impact easy to tolerate (compared to the cost of adding hardware to solve the problem) then you may deem the tradeoff a win.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

They are, but I use CB2 in manual output mode to set it low when necessary.



Oh yes I read this very carefully, but I do not have the 6502 assembly experience that Garth has and managing all this sounds pretty complex.

But basically I have 1 line for the PS/2 data, 3 for SPI clock and data, 3 for SPI slave selects, and 2 for i2c (the spi clock doubles as the i2c clock, so I can't use both SPI and I2C at the same time).

However the CA2 pin is free, and that also has a manual output mode. So I could use CB2 as a clock input with the schmitt buffer and CA2 as the clock output.



That's an interesting idea. And I just had the thought that since I'm not doing anything related to I2C or SPI in the interrupt handler, and since the 6502 is the SPI and I2C master, I can probably reuse their common clock pin as an input to check the level of the PS/2 clock line.

But now that I have some schmitt trigger inverters in my drawer, I will try them out first, with CA2 as a PS/2 clock output.

I don't really have time to work on it these days, but will update the thread as soon as I'm able!

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.