Is there any recent project to connect a PC (PS/2) keyboard to the CPC?

[gerald]

Thanks, Gerald Actually, it did not help, but while adding the resistor net, I did realize I have completely ignored blocking capacitors. I have added one 470uF across the PS/2 keyboard power, and 100nF across the ATTiny and HCT138 power pins.
Now one key press generates just one letter on the screen, however, it's a wrong letter: F produces D, B produces C etc etc I believe I have shifted the keyboard rows by one. Could you possibly tell me what AY pin should go to what ATTiny pin? The CPC schematics I have uses X1-X8 for the AY pins, while your schematics uses X0-X7. I assumed AY X1 corresponds to your X0, but it doesn't seem to be the case. Thanks!

According to the key swap, it looks more like an error on the line connection from the PPI to the uC (L[3:0] on the schematics).

[zrusavpt]

Thanks, Gerald. I am reasonably sure the connection corresponds to the schematic, but just in case:
PPI pin 14 goes to ATTiny pin 2
PPI pin 15 goes to ATTiny pin 3
PPI pin 16 goes to ATTiny pin 8
PPI pin 17 goes to ATTiny pin 9
Is that correct?

[gerald]

Thanks, Gerald. I am reasonably sure the connection corresponds to the schematic, but just in case:
PPI pin 14 goes to ATTiny pin 2
PPI pin 15 goes to ATTiny pin 3
PPI pin 16 goes to ATTiny pin 8
PPI pin 17 goes to ATTiny pin 9
Is that correct?

That right.
Do you have any other wrong key binding to show.
F -> D and B -> C are indicating a wrong line mapping. F and B are on line 6 but line 7 get activated. Rows are OK.

[zrusavpt]

Thanks again, Gerald!

I have found better CPC schematic and I agree with you, it looks like the row mapping is wrong. I am constantly getting keys from the next row.
(In my schematics, rows are coming from the 74145 decoder while colums are going to AY).

I have reviewed the source code and my recompiled binary, and I can see that UpdateKeyboard isn't inlined, which is most likely the problem. As CPC scans the keyboard row by row, ATTiny spends too much time processing the interrupt, and outputs the value too late. That means that CPC will pick the value up when reading next row.

I suggest to add the following line before the UpdateKeyboard function:

Code Select Expand

static void UpdateKeyboard(void)  __attribute__ ((always_inline));

That should increase the chance that compiler will actually make the UpdateKeyboard inline.

I didn't test this on a real hardware yet - programming my adapter is a bit complicated (due to SMD components), but I believe this will fix the problem. Sorry for bothering you with that, it was my fault... but at least we can prevent others from doing the same mistake

[gerald]

Thanks again, Gerald!

I have found better CPC schematic and I agree with you, it looks like the row mapping is wrong. I am constantly getting keys from the next row.
(In my schematics, rows are coming from the 74145 decoder while colums are going to AY).

I have reviewed the source code and my recompiled binary, and I can see that UpdateKeyboard isn't inlined, which is most likely the problem. As CPC scans the keyboard row by row, ATTiny spends too much time processing the interrupt, and outputs the value too late. That means that CPC will pick the value up when reading next row.

I suggest to add the following line before the UpdateKeyboard function:

Code Select Expand

static void UpdateKeyboard(void)  __attribute__ ((always_inline));

That should increase the chance that compiler will actually make the UpdateKeyboard inline.

I didn't test this on a real hardware yet - programming my adapter is a bit complicated (due to SMD components), but I believe this will fix the problem. Sorry for bothering you with that, it was my fault... but at least we can prevent others from doing the same mistake

If the IRQ is not inlined, that could be the problem. The inlined version takes 6.875us, the Z80 requires update in less than 7.4us
Which version of AVRGCC are you using ? I've only tested this code with the latest (oooooold) version of winavr.

[zrusavpt]

According to "avr-gcc --version":

avr-gcc (AVR_8_bit_GNU_Toolchain_3.5.0_1662) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

I have no clue where did I get it. I used to have WinAVR 20100110, but this is obviously newer.

The non-inlined code has a lot of pushes and pops around the call to UpdateKeyboard(). There's 8 more registers pushed and popped, plus the call and return. If I am counting right, that's 23 more cycles, which is almost 3us, and that definitely gets the interrupt duration over 7.4us.

(It reminds me my attempts to generate VGA video with 25MHz pixel clock I was one cycle too long )

[The Equalizor]

Hi Gerald et al.

Can I just firm a few details up here Gerald?

I'm building the Plus version of this Interface from your Schematic and I just wanted to confirm the pin assignments.

SV3  Connector X0-X7 goes to the Keyboard X connector CP103?
On SV4 PPIA0_z80a8 goes to the Z80 pin 38?
On SV4 PPIA0_z90a9 goes to the Z80 pin 39?
On SV4 PPIA0_z80a8 goes to the Z80 pin 1?


I'm not sure about where PPIWRN_IOWRN goes though. Is that to pin 55 of the ASIC? Is that the line that says /IOW?

Would really appreciate some guidance on this as I'd rather not kill a rather elderly Plus machine!

Regards

The Equalizor

[gerald]

Hi Gerald et al.

Can I just firm a few details up here Gerald?

I'm building the Plus version of this Interface from your Schematic and I just wanted to confirm the pin assignments.

SV3  Connector X0-X7 goes to the Keyboard X connector CP103?
On SV4 PPIA0_z80a8 goes to the Z80 pin 38?
On SV4 PPIA0_z90a9 goes to the Z80 pin 39?
On SV4 PPIA0_z80a8 goes to the Z80 pin 1?


I'm not sure about where PPIWRN_IOWRN goes though. Is that to pin 55 of the ASIC? Is that the line that says /IOW?

Would really appreciate some guidance on this as I'd rather not kill a rather elderly Plus machine!

Regards

The Equalizor

IOWRN is a signal that is found on CPC range, it's just Z80_IORQn OR Z80_WRn. I did not pay attention that it does not exist on the Plus.
For the Plus just connect Z80_IORQn (pin 20) and Z80_WRn (pin 22) to respectively G2A and G2B of the 74LS138 instead of IOWRn and GND. Order does not matter, these inputs are equivalent.

[The Equalizor]

Okay, the keyboard interface is finished and works pretty darn well, apart from an odd glitch sometimes with the | key which sometimes adds a ' onto the command.


Way too much wiring on the underside of the veroboard but the top looks neat enough. I'm actually considering getting some PCBs made up as I have a couple of mates with Plus machines and dead keyboards.

Gerald, I'd just like to say thank you for your help and for designing this great and much needed project,

Regards


Rob

[gerald]

apart from an odd glitch sometimes with the | key which sometimes adds a ' onto the command.

As you say, that's odd. I don't know how this can happen. | share the same key as \ on UK keyboard which have nothing to to with ` or ' place wise on the CPC patrix.
May be due to the long wires you have ?

[The Equalizor]

Yes, that's probably the problem. That was a prototype anyway, I've redesigned the board in Altium and sent the files away to be turned into 10 PCBs :-)


Regards


Rob

[Bryce]

You should have aligned the outputs with the CPCs Mainboard connector, then you could have directly mounted it on pin headers.

Bryce.

[The Equalizor]

Everyone's a critic :p


But seriously the pins will probably line up with cp03 anyway so that might be doable anyway.


Regards


Rob

[Bryce]

They'll line up if you install the PCB with the components facing down (if there's space to do that). I would have added a ground plane too, just because it's best practice, but it's not really required.

Sorry for being a critic, it is a very well laid out PCB and you've managed to keep the via count extremely low, despite it all being SMD. Of course geralds choice of pin designation probably helped this too.

Bryce.

[The Equalizor]

Yeah the layout is partially down to altium but it's autorouter is a little unintelligent so I spent about an hour tidying up the routing so it was more sensible


I'm by no means an expert and don't claim to be but I'm defiantly an enthusiastic hobbyist I just needed something quick and dirty and that seemed to fit the bill.


Hope it works now. Pcbs should be here in a week or so


Regards


Rob

[The Equalizor]

Well, I royally screwed that PCB up! I accidentally tied one of the nets that connects 3 chips to VCC on the Schematic so the boards didn't work out of the box but can be coaxed into life and seem to work fine. I'm might have them remade now I've corrected the schematic if theres enough interest, so please PM me if interested.

The machine is done, I have pasted a link below to a video I took of it on YouTube.


https://youtu.be/QKIwnlv2PhQ

Regards


Rob

[The Equalizor]

And, direct from Pcbway in china in less than 7 days(!) this is my final interface.


Nice black soldermask and the CP03 header is now a 1-1 mapping with the one on the Plus, enabling it to be plugged straight into the mainboard if you fit a pin header onto the Interface, as below.


Regards

Rob

[The Equalizor]

@gerald,


Weirdly enough I still have that issue with the | key  |' if you lift the | key too soon before the | key. It's definitely some sort of interaction between the Shift and | key...Any ideas?


This is with a different keyboard *and* the newest Interface as above.


regards


Rob

[gerald]

Weirdly enough I still have that issue with the | key  |' if you lift the | key too soon before the | key. It's definitely some sort of interaction between the Shift and | key...Any ideas?

I can confirm the bug
But I am not sure I can fix it (I've already tried).
The issue comes from the handling of the shift key by the PS2CPC.
Basically, shift is only passed to the CPC when an other key is pressed to deal with keys that are  shifted on PC but not on CPC.

[megatronuk]

I have recently built 1.0b of the PS2Cpc board and whilst it works (to the extent that the original keyboard is unaffected and the NumLock light on the external keyboard lights up correctly), it doesn't produce any of the correct key codes.

I have tried the pre compiled hex file in the 1.0b zip file, as well as recompiling after adding the inline keyword as discussed above (plus one or two more fixes to get it to build cleanly on latest gcc-avr tooling)... But both firmwares show exactly the same result.

Like others, I assume that the connections are to use x0-x7, as labelled on the ay chip, rather than x1-x8 as per the diagram? I am.pretty sure my connections are correct, but attach an image here anyway.

This is on a UK 464 with a UK PS/2 keyboard.

If anyone has any suggestions I'd be really appreciative - getting working remote keyboard is the last thing preventing me from getting this CPC up and working.

[megatronuk]

I have mapped out all of the keypresses that I am getting and this is the result:

PS/2 key / Result on CPC (n/a for no effect)
1, n/a
2, [
3, n/a
4, n/a
5, 3
6, 4
7, n/a
8, n/a
9, -
0, (prints up cursor)
-, n/a
=, j
backspace, n/a
q, ]
w, n/a
e, n/a
r, e
t, w
y, n/a
u, n/a
i, p
o, @
p, n/a
[, 7
], y
\, j
a, n/a
s, n/a
d, n/a
f, d
g, s
h, n/a
j, n/a
k, :
l, ;
;, n/a
', j
enter, u
z, n/a
x, n/a
c, n/a
v, x
b, c
n, n/a
m, /
,, .
., n/a
/, n/a

Special keys
Caps Lock, \
Control, (space)
Alt, (prints down cursor)
Cursor Up, (moves cursor left)
Cursor Down, 7
Cursor Left, (prints up cursor)
Cursor Right, (moves cursor right)
Del, 8

Number Pad
*, j
/, n/a
-, n/a
1, Z
2, n/a
3, 31
4, h
5, X
6, 65
7, (prints left cursor)
8, (prints right cursor)
9, 98
0, (backspace)
., .0
enter, (enter/newline)

If anyone has any suggestions, or used the PS2CPC board in the version 1.0b version unmodified, can you help? 

[gerald]

According to the mapping you did, I can at least say that the connection to the AY is mostly OK.
Mostly because some are odd, which i put on listing error or effect of PPIA0/A1 swap.

However, the connection to the PPI lines are not correct.
From the picture, it looks like you swapped the lines bit (PPIC0 on PPI is connected to PPIC3 on card, PPIC1 on PPI is connected to PPIC2 and do on)
PPIA0/PPIA1 also look swapped ?

[megatronuk]

According to the mapping you did, I can at least say that the connection to the AY is mostly OK.
Mostly because some are odd, which i put on listing error or effect of PPIA0/A1 swap.

However, the connection to the PPI lines are not correct.
From the picture, it looks like you swapped the lines bit (PPIC0 on PPI is connected to PPIC3 on card, PPIC1 on PPI is connected to PPIC2 and do on)
PPIA0/PPIA1 also look swapped ?

You are absolutely right. I have been staring at this for the past two days and C0-C3 are indeed flipped; that was an easy one to resolve by flipping the connector upside down.

A1/A0 also was swapped, you were correct there too - I've swapped those two pins to their correct location (A1 on SV4 pin 9, A0 on SV4 pin ..

However, when I do both of these changes just now I get no response from any keys others than enter on the number pad and the up/down cursor keys (none of which are correct key codes, though). The keyboard led's still flash and num lock still toggles on/off as before.

[gerald]

A1/A0 also was swapped, you were correct there too - I've swapped those two pins to their correct location (A1 on SV4 pin 9, A0 on SV4 pin ..

What happen when you swap them back. Look like the schematic is wrong there (did I forgot to fix that ?).
The we use 74138 Y2 output to detect write to register C of the PPC which whould be

Code Select Expand

A=0=PPI_A0
B=1=PPI_A1
C=0=WRN

[megatronuk]

Okay, swapping A1/A0 back to the original position brings the keyboard back to approximately the same state as before, the new key mapping with C0-C3 correctly connected is:

1 (up arrow)
2 (down arrow)
3 2
4 1
5 3
6 4
7 5
8 6
9 7
0 8
- 9
= :9
q (no output)
w (no output)
e break
r e
t (no output)
y (no output)
u r
i (no output)
o u
p (no output)
[ -
] (no output)
enter @
a Z
s right arrow
d a
f d
g s
h g
j f
k j
l h
; l
, :5
# :2
z backspace
x z
c (no output)
v X
b C
n B
m N
, space
. ,
/ M
\ /