Hi!
First post, first question .. sorry ... I was looking for information about how to connect a PC keyboard (PS/2) to an Amstrad CPC. I found CPCKey MF-2 Keyboard interface for Amstrad CPC (http://soeren.informationstheater.de/cpc/Index.html) Is there something newer out there?
Thanks!
P.S.: Ahhh ... something about me .... Amstrad CPC was my first computer: CPC664. I still have it up and running (drive belt was changed for a couple of years). I would like to learn something more about it and, as I see, there is a lot of information out there. Thanks for this great place an for keeping the platform alive.
Hi,
welcome to the forum. There's this too: CPCKey - CPCWiki (http://www.cpcwiki.eu/index.php/CPCKey) a DIY PS/2 replacement for the keyboard,but it's just as old. Unfortunately, the way the CPC reads key inputs means that the hardware is always relatively complicated too.
Bryce.
Thanks Bryce. As I see there is nothing else ::) ...... I will try to mount it. I was thinking it could be good for CPCs which keyboard does not work anymore ....
Joss
Were you just asking out of general interest or is there a problem with your 664?
Quote from: Bryce on 22:38, 27 August 12
Hi,
welcome to the forum. There's this too: CPCKey - CPCWiki (http://www.cpcwiki.eu/index.php/CPCKey) a DIY PS/2 replacement for the keyboard,but it's just as old. Unfortunately, the way the CPC reads key inputs means that the hardware is always relatively complicated too.
Bryce.
Perhaps we need a Bryce twist on this?
a new idea which is more simple?
would a PIC or something really chip do it?
Quote from: Joss on 18:42, 27 August 12
Hi!
First post, first question .. sorry ... I was looking for information about how to connect a PC keyboard (PS/2) to an Amstrad CPC. I found CPCKey MF-2 Keyboard interface for Amstrad CPC (http://soeren.informationstheater.de/cpc/Index.html) Is there something newer out there?
Thanks!
P.S.: Ahhh ... something about me .... Amstrad CPC was my first computer: CPC664. I still have it up and running (drive belt was changed for a couple of years). I would like to learn something more about it and, as I see, there is a lot of information out there. Thanks for this great place an for keeping the platform alive.
...it seems that the post ABBA switch, the other way (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/abba-switch-the-other-way/msg48872/#msg48872)
gerald has build up some kind of ps/2 keyboard adapter (Don't know if it's the same as mentioned above)? Maybe you can ask him?
Geralds solution looks like a very neat method. He does it properly by interfacing directly to the 8255 instead of using the Keyboard inputs / outputs. However, this could only be used on the Classic CPC as the Plus doesn't have an 8255, you'd need to interface to the ASIC.
Bryce.
Quote from: Bryce on 09:34, 28 August 12
Geralds solution looks like a very neat method. He does it properly by interfacing directly to the 8255 instead of using the Keyboard inputs / outputs. However, this could only be used on the Classic CPC as the Plus doesn't have an 8255, you'd need to interface to the ASIC.
Bryce.
I forgot about that one.
Nice.
I eventually need to build one myself as well, since one of my CPCs has a defect membrane.
My plan is to connect a microcontroller to the keyboard connector on the PCB. It'd need to have 2 x 10 pins dedicated to the keyboard pins and a few for the ps2 keyboard (perhaps even usb?), so a ATtiny or ATmega with 2-4kb and high IO-pin count would suffice.
However, this project has no priority, so it might take me a year or so to actually start it.
That's the complicated way of doing it. If it's a classic CPC, you can connect the µP to the 8255. That way you only need to monitor the 4 bits going to the 74LS145 and BDIR / BC2 and feed the result back to PORT A of the 8255. 14 pins instead of 20 and a lot less hardware.
Bryce.
Quote from: Bryce on 10:10, 28 August 12
That's the complicated way of doing it. If it's a classic CPC, you can connect the µP to the 8255. That way you only need to monitor the 4 bits going to the 74LS145 and BDIR / BC2 and feed the result back to PORT A of the 8255. 14 pins instead of 20 and a lot less hardware.
It's a CPC+ board, but in its current state, it's not usable.
It think connecting to the keyboard connector is an elegant solution as it assures that you can always switch back to a normal keyboard membrane, should you find one. And you don't accidentally damage the board while soldering the connections directly ... I can cope with destroying a puny uC but damaging a CPC board ... an unbearable thought.
Yes, i've done my own PS2 adapter years ago (2004), when I wanted to have a UK keyboard on my French 6128 :D .
It's made of on Atmel 89c2051 and on 74hct138 (under the 8255).
The 74hct138 detect write to the 8255 register C, used to control the PSG and therfore the keyboard matrix scan.
The 89c2051 handle the PS2 keyboard, does the PS2 keycode conversion to CPC matrix and update it on every key press change and access to 8255 C register.
Original keyboard CPC can still be used.
But that's the easy part ;)
The tight integration was possible thanks to the unmounted resistor network near the 8255 that give access to the keyboard itself column.
The tricky part is the PCB itself (picture of the solder side of the 1st in-place prototype)
[attach=2]
I am using what I had available at that time and all decoupling capacitiors are 0402/0603 ::)
I did a 2nd proto (the one in the 6128) where the only difference is the use of a 8/10 epoxy PCB instead of 16/10. The 8/10 allow proper soldering of socket from the upper side, and give some clearance to the original keyboard. This is mandatory for 6128.
Now, should we consider this as a recent project ?
1. The controller is outdated, and I have to check if I still can compile code for it, at least to check that my code base is still correct ::) . The compiler I used was a 1996 DOS C compiler :laugh:
2. PCB would need to be modified to accomodate more human solderable capacitor.
Ideally porting it to a more recent controller would be better. Atmel ATtiny2313/4313 are pin compatible with the 89c2051 and may be fast enough with they embeded oscillator. That would save the 24MHz (yes !!!) quartz, and free 2 pins on which we could either add a mouse port or control an ABBA switch (the other way ;) ) and a side switch.
@Badstarr: my 664 is working fine ... at least last time I was using it ::) I won't try to touch it, just in case I make something wrong ..... I was getting a couple of CPCs from ebay and one of them has the problem.
@Gerald: since you use microcontroller and not and "old" (but powerfull ;-) 8-bit CPU, i would say: your project is "recent".
Your project looks fine, but I want to use the standard CPC keyboard interface. It should be easy for people who only want to test his/her CPC after a couple of years. You could try to put every information you have about your project and put it in the cpcwiki. It can help other people who are more braver as I am.
I think I will try to build the CPCKey project, just to test if it works and as it uses the standard keyboard interface the CPC should not be broken in the process ..... (it's my first HW project) ...... I will use a Schneider. The Interface can be "hacked" without modification of the components .... I think.
[dreamer on]
Thinking about the project and looking at the schematic of the CPC ... could it be possible to read the reading messages for the keyboard from the expansion port? As I see they are put in the data/address bus and they are read by the PPI. The feedback signal could perhaps come from the joystick port.
If it works, you need an micro controller which host a PS/2 keyboard and read the messages from the expansion port, and give the CPC the feedback about keystroke over the joystick port. You don't need to open the CPC and it can be used with other CPCs.
[dreamer off]
Thanks everyone for your answers.
Nice dream, but not a chance. There are quite a few signals you'd need, that don't go to either the expansion port or any other port for that matter.
Bryce.
May i even reverse the question ?
My brother would like to pute a Raspberry inside an Oric Atmos... (but I guess you could fit it inside a CPC...)
What kind of stuff would be needed to turn those old school keyboards (membrane CPC style or other) into a workable USB raspberry friendly awesomness ?
Considering the Raspeberry is quite small sized, I guess you could even put it inside a CPC or PLUS without even removing the Amstrad motherboard.
There could perhaps even be some interesting possibilities with such Raspberry-enhanced Amstrad CPC/PLUS.
Could such Raspberry get a proper OS/App so it could help to display the CPC on a modern monitor through the Raspberry in a "Hardware emulation " mode... like the CPC become a Card to sort of emulate (not emulation but real job actually) the CPC... then the raspberry... well...nevermind. :D
Quote from: MacDeath on 22:07, 28 August 12
May i even reverse the question ?
I have a BeagleBone (http://beagleboard.org/bone/) and I'd like to stick it inside a CPC..... it runs Linux, so I can run an emulator perfectly okay within it.... but can I get the keyboard of the CPC to play nicely - like MacDeath is asking about Raspberry? anyone got any pointers on whether this is possible / feasible? (I think I may have asked a similar question like this a couple of years ago! ;D )
I guess such sort of thing would need :
=a Hardware converter "old Keyboard matrix to USB standard", need some chips and solderings, a few appropiate connecters too.
=Some drivers : would it be software (from the OS) or already integrated into the converter (programable chips...). Probably a bit of both.
Hey i didn't knew about this BeagleBone, I guess it is some sort of RarspduinoBerry ?
Those look ice but as I told, I would prefer a solution where you can actually connect those computers with the CPC, giving some good new options more than just emulating old CPC on them.
The best CPC emulator remains the CPC itself.
And those "computers on a small card" surely have enough process power to perform many conversion things to help a CPC...
like :
=emulating DiskDrive or HDD or Tape ?
=be used as a display solution for modern Monitors ?
This must be only sweet dream I guess.
Would need another whole card full of components, and also some lot of soldering right on the CPC motherboard/Connectors too.
Solid point is that such Machine could just be some nice replacement for 3" disk drives...
But I suppose those boards are not 5V friendly (= CPC voltage)
This said, at 149$ or 89$, those machines are not that cheap, and a "CPC shield" would add up a lot on this.
@Bryce: I had to try ::)
@MacDeath: old computers keyboards with membrane are switches connected direct to the mainboard, and new computers keyboards are ...... switches too with logic to make it PS/2 or USB compatible. Perhaps can you use an old PC keyboard with a couple of keys which do not work anymore and take the logic to adapt it to the old computer keyboard.
I found this funny project which can be used as example :D :
Hacking a toy guitar to make a "Frets on Fire" controller (http://www.craxor.com/foftar/)
Use the Ory keyboard instead of the guitar.
@Ynot.zer0: nice gadget, I didn't know about it!
Quote from: MacDeath on 22:07, 28 August 12
Could such Raspberry get a proper OS/App so it could help to display the CPC on a modern monitor through the Raspberry in a "Hardware emulation " mode... like the CPC become a Card to sort of emulate (not emulation but real job actually) the CPC... then the raspberry... well...nevermind. :D
When I get my raspberry pi.. which will now be in october because of delays from RS components, I will convert my wip arnold emulation to it.
then I will have cpc on my hd 1080p television :)
I already borrowed one from a friend, and I compiled Arnold on it and it ran but slowly :(. So I need to work to make emulation faster.
The guy asked for it back.. so now I must wait for mine.
welcome Joss!
Quote from: MacDeath on 22:07, 28 August 12
Could such Raspberry get a proper OS/App so it could help to display the CPC on a modern monitor through the Raspberry in a "Hardware emulation " mode... like the CPC become a Card to sort of emulate (not emulation but real job actually) the CPC... then the raspberry... well...nevermind. :D
Raspberry runs linux. it has a proper OS and can run many emulators already (snes, spectrum, mame...).
Quote from: Ynot.zer0 on 23:44, 28 August 12
I have a BeagleBone (http://beagleboard.org/bone/) and I'd like to stick it inside a CPC..... it runs Linux, so I can run an emulator perfectly okay within it.... but can I get the keyboard of the CPC to play nicely - like MacDeath is asking about Raspberry? anyone got any pointers on whether this is possible / feasible? (I think I may have asked a similar question like this a couple of years ago! ;D )
When I've done some more optimisations, I think my wip of arnold will work on it.
I see it's a SOC, with ARM cpu, some kind of graphics chip in it.
If it does OpenGL/OpenGL ES/SDL it'll work fine.
Connecting a real CPC keyboard to other devices is really easy. A simple µP (PIC/AVR) can easily scan the keys. The only slightly difficult part is the interface to the new device. If it's a USB connection, the device would need to emulate USB HID, but if it was something like an Arduino or Beagle bone, the device could simply produce an 8-bit value on the TTL inputs available. Then the entire hardware would be a PIC and a few resistors / capacitors. Could be made for under €10.
Bryce.
Quote from: arnoldemu on 09:30, 29 August 12
Raspberry runs linux. it has a proper OS and can run many emulators already (snes, spectrum, mame...).
Don't get me wrong, I was eye-ing up the Raspberry Pi recently.... and then I stumbled upon the BeagleBone.
The BeagleBone is like an Arduino on steroids, it has 66 pins that you can play with and do a lot with. It has capes (http://beagleboardtoys.com/wiki/index.php?title=Main_Page)(same sort of thing as Arduino shields), so you can plug daughter boards into it. For instance a 3/7" touchscreen LCD. Or you can build your own daughter board - perhaps for handling the processing of the CPC keyboard key presses and passing these to the BeagleBone?
OOTB the BeagleBone comes with Angstrom Linux and is pretty powerful as it is. It's the full blown latest 32-bit Linux (probably the same sort of thing as the Raspberry Pi offers?)
With a little bit of investigation (and time) I've got it to also run Debian Linux at a very good speed, in fact I can code Java in eclipse on my laptop and get it to compile and build and run directly from the board.
It will also run Android 2.3.5 and Android 4.0.3 (I found an Android JellyBean (http://code.google.com/p/rowboat/wiki/JellybeanOnBeaglebone_WithSGX) beta out in the wild, but I'm not too interested in it at the moment). If you boot the BeagleBone into Android, it is just that, a full blown Android device running on a 3/7" touchscreen LCD, so if you have any apps that already run on Android they should work as-is. Not bad for an $89 board..... but, hey it also allows you to tap into all those pins too, so that's where the "it's more than an Arduino / Raspberry Pi" comes from. My longer term goal is to use it with OpenCV (http://opencv.org/) for object recognition in a robot project....
...but as a short-term goal, I like the idea of potentially using one of my old CPC 6128 cases (with no m/board inside), mounting the BeagleBone where the 3" drive bay is, connecting up the existing CPC keyboard as input, work out a way for the 3" or 7" LCD to 'slide' out of where the edge connectors on the back originally were and flip upwards to give a mini-laptop type of feel.... I can then use the power cape to provide power to the BeagleBone and contain it all within the CPC 6128 case itself. The BeagleBone would boot into linux and then fire up a CPC emulator and have access to the Gbs of .dsk files I have on the microSD card too.... now, if we could just figure out the CPC 6128 keypress translation part.... 8)
[edit: I just saw Bryce reply..... wow, looks like the rosetta stone part can be solved!?! I'm no electronics hardware engineer, I plug & plug and write code.... any assistance on how to cobble the PIC / resisters / capacitors together is most appreciated!)
When I get time I'll put together a simple schematic. Generally any PIC with 3x 8bit ports + Port A will do. 10 bits output a binary sequence and another 10 then check what bits came back. A lookup table then decides what key was pressed and this ASCII value gets put on the 8bit port going to the Beagleboard. Other than a few pullup resistors (/MCLR pullup) and a few capacitors for the supply, nothing else would be required. You could probably even get away with using the internal PIC clock so that no external crystal is required.
Bryce.
Weren't chips like the AY used to manage keyboards in addition to produce sounds ?
I mean, those Soundchips were mostly produced to be put into keyboards synthetisers/electronic pianos...
Well they offered generic i/o ports that could be used be used for anything. But if you were to build a keyboard scanner today, there are so many other more easily available ICs that will do the job just as well.
Bryce.
As I see there are two interesting projects:
- adapt CPC keyboard to be used as a PS/2 keyboard
and (for me useful)
- connect a PS/2 keyboard to the CPC. The second one perhaps can be done through another machine: raspberry, android-box ..... ;D .... an old and cheap android phone with extra logic over the USB port? .....
Quote from: Bryce on 11:31, 29 August 12
Connecting a real CPC keyboard to other devices is really easy. A simple µP (PIC/AVR) can easily scan the keys. The only slightly difficult part is the interface to the new device. If it's a USB connection, the device would need to emulate USB HID, but if it was something like an Arduino or Beagle bone, the device could simply produce an 8-bit value on the TTL inputs available. Then the entire hardware would be a PIC and a few resistors / capacitors. Could be made for under €10.
Or simply use a Teensy 2++. It's pretty cheap, easy to program and can emulate keyboard, mouse and joystick HIDs with ease. I've used these to convert Atari keyboards to USB and PS/2. Several people are using this in "Atari PC's" - Atari ST's with the guts replaced with small PC motherboards.
Connecting PS/2 keyboards to a CPC shouldn't be a problem either, as long as the user is prepared to do some soldering. You can save a few $$ if you shop around, but when a complete Teensy 2 is around $20 I don't see the point.
Quote from: Joss on 19:55, 29 August 12
- connect a PS/2 keyboard to the CPC. The second one perhaps can be done through another machine: raspberry, android-box ..... ;D .... an old and cheap android phone with extra logic over the USB port? .....
Or one of these: PJRC Store (http://www.pjrc.com/store/teensypp.html)
These can be programmed with the Arduino tools. Use the Arduino PS/2 library to read a PS/2 keyboard, and translate the PS/2 scancodes to matrix events. Should be quite easy for someone with basic programming and electronics skills.
Teensy++ 2.0 ordered. Next week I'll have to look into how to connect the CPC 6128 keyboard to it and read the keys pressed... will share the progress (if I make any!)
A few tips:
- Use the Teensy's internal pullup-resistors on all the matrix lines. This prevents the inputs from floating, which could cause false readings.
- Scanning the keyboard is relatively simple - you loop around the rows, pulling down the rows one by one and read the state of each column for each row. Now, if you put the row number in the upper nibble and the column number in the low nibble, you'll have an 8 bit number that identifes the key. Use this number to look up the corresponding HID scancode in a translation table.
- Every time you scan the matrix, store the state of each key in a table. So when you scan the matrix, you can detect if the state of a key has changed. You'll need this as you'll only send scancodes when a key is pressed or released.
- The Teensyduino USB HID-library takes care of key repeat, no need to worry about that :)
This is the part of the code that handles the matrix in my Atari Stacy keyboard controller:
// Define the pins that connects to the matrix
int rowpins[] = { 10,11,12,13,14,15,16,17 };
int colpins[] = { 19,18,40,41,42,43,44,45,20,21,22,23,24,25,26 };
// Key state is stored in this array every time the matrix is scanned
uint8_t matrix[128];
// Translation table. You will need a 256 byte table with the CPC using this technique.
uint8_t scan[128] = {
0,0,0,0x1d,0,0,0,0,
0,0,0x2a,0x1d,0,0,0,0x3b,
0,0x38,0,0,0,0,0,0x3c,
0x36,0,0,0,0,0,0,0x3d,
0x2c,0x60,0x1e,0x10,0x0f,0x02,0x01,0x3e,
0x2d,0x20,0x1f,0x12,0x11,0x04,0x03,0x3f,
0x2f,0x2e,0x21,0x14,0x13,0x06,0x05,0x40,
0x31,0x30,0x23,0x22,0x15,0x08,0x07,0x41,
0x32,0x25,0x24,0x17,0x16,0x0a,0x09,0x42,
0x39,0x33,0x26,0x19,0x18,0x0c,0x0b,0x43,
0x3a,0x34,0x27,0x1b,0x1a,0x29,0x0d,0x44,
0x35,0x28,0x1c,0x2b,0x52,0x53,0x0e,0x62,
0x70,0x6d,0x4d,0x50,0x4b,0x47,0x48,0x61,
0x71,0x6e,0x6b,0x6a,0x68,0x67,0x54,0x63,
0x72,0x6f,0x4e,0x6c,0x4a,0x69,0x66,0x65
};
// Set up the matrix pins.
void keyboard_init(void)
{
for (int i=0; i < 8; i++)
{
// Rows as output, status HIGH.
pinMode(rowpins[i], OUTPUT);
digitalWrite(rowpins[i], HIGH);
}
// Columns as INPUT, pullup-resistors enabled.
for (int i=0; i < 15; pinMode(colpins[i++], INPUT_PULLUP));
for (int i=0; i < 128; matrix[i++] = 0);
}
// Scan the matrix once.
void keyboard_scan(void)
{
for (int i = 0; i < 8; i++) // Rows
{
digitalWrite(rowpins[i], LOW); // Pull the row low...
for (int j = 0; j < 15; j++) // ...and read the state of every column.
{
uint8_t iscan = i + (j << 3); // Create an internal scancode by combining the row and column numbers.
uint8_t key = !digitalRead(colpins[j]); // Read the state of the key
if (key != matrix[iscan]) // Has the state changed since the last scan?
{
// Look up the scancode translation table to find the key's IKBD (Atari) scancode.
uint8_t scanc = (key ? scan[iscan] : (scan[iscan] | 0x80)); // High bit indicates press or release
matrix[iscan] = key; // Store the new state for the next scan.
convert_ST_USB(scanc); // Convert the IKBD scancode to USB HID.
}
}
digitalWrite(rowpins[i], HIGH); // Finished with this row, pull it HIGH again.
}
}
The HID stuff is well documented on the Teensyduino webpages, you should have no problems with that.
Nice.
For the cpc you would need to remember the up/down state of every key internally.
Then when the cpc requests a specific keyboard "line", send it the state of those keys on that line.
It'll be interesting to see a usb keyboard hooked up to a cpc :)
Quote from: arnoldemu on 17:54, 30 August 12
...
It'll be interesting to see a usb keyboard hooked up to a cpc :)
me too :) it looks nice and I didnt know about it
Bryce told in this post it is not possible to read and write the keyboard from expansion port and joystick port. Could it be possible to do it through the pins of the Z80? It is more difficult. The instructions to read the keyboard which are send by CPU have to be decode ..... I mean it because I don't want to touch much the CPC with soldering, it can go broken and the keyboard could be changed quickly to other CPC.
Quote from: arnoldemu on 17:54, 30 August 12
It'll be interesting to see a usb keyboard hooked up to a cpc :)
The code I presented was for the opposite application - connecting a CPC keyboard to a PC/Mac via USB.
Connecting a USB keyboard to a CPC would be more difficult, but not impossible. And many USB keyboards also supports the PS/2 protocol, in this case it would be relatively easy.
I would add a keyboard using the EXP-port and a patched OS. Nice use for the LowerROM board. But no, I'm fine with CPC's keyboard too :)
That would be too much traffic for the EXP bus. Any other expansions (MegaFlash etc) may not work or work really slow. As the MegaFlash, SF2 and any floppy controller are very time sensitive, a delay like that would probably cause timing errors and malfunction.
Bryce.
Quote from: Bryce on 20:07, 30 August 12
That would be too much traffic for the EXP bus. Any other expansions (MegaFlash etc) may not work or work really slow. As the MegaFlash, SF2 and any floppy controller are very time sensitive, a delay like that would probably cause timing errors and malfunction.
What would be too much traffic for the EXP bus?
The existing keyboard routines that talk to the 8255 and indirectly to the AY sound chip all happen over the same data bus that appears on the EXP bus under interrupt control, there isn't a seperate external data bus. The MegaFlash, SF2 or floppy controller all probably turn off interupts (I know my flash programming routines do) during any time critical events.
It uses the same address and databus, but everything external are addressed as I/0 with the /IORQ signal. Is it possible to poll the keyboard and write to the DDI-1 without timing out on the µPD ? I didn't think you could call an I/O address on every cycle. And if you could, wouldn't that slow the CPC down?
Bryce.
Quote from: Joss on 18:07, 30 August 12
I don't want to touch much the CPC with soldering, it can go broken and the keyboard could be changed quickly to other CPC.
On which CPC model you need to use the PS2 to CPC keyboard adapter?
The highly integrated version on 6128 was dictated by the lack of height between the PCB and the keyboard.
On 464, you can just piggypack the adapter (using a socket) on the 8255 and only solder the 10 needed pins (A0(A8), A1(A9), CSn(A11), WRn(IOWRn), C[3:0], VCC, GND).
The keyboard matrix part (X[7:0]) can be either soldered on PSG directly or on original keyboard connector.
Note that the adapter I did is usable in parallel with the keyboard.
Now to a bit of teasing :D
Quote from: Bryce on 20:07, 30 August 12
That would be too much traffic for the EXP bus.
I would say it sill be too much capacitive/current load on the addr/data/control bus that may exceed drive capability of Z80 and other bus drivers, and cause timing or voltage issue. :P
Very nice solution. Simple and to the point, although the µP seems a bit over the top for what it needs to do. Couldn't you have got away with using something smaller?
Bryce.
Well, a tiny2313 does the job as current code is 1.8k byte with one keymap. One keymap is about 190 bytes.
Since i've freed 2 pins compared to the previous incarnation (AT89C2051), more code/ram/eeprom space is welcome. 8)
Talking of space, AT89C2051 is 10% smaller with 2 keymaps :o .
By the way, for 6128+, one just need to add a 4bit latch controlled by PPICWRn signal to catch the LINE value.
Well you could use an external shift register and produce the output sequence with just one pin of the µP.
Bryce.
Timing requirement is quite tight. OS keyboard scan take about 6.5us from setting the line (falling edge of WRn) to reading the row (rising edge of RDn).
The ISR response time is the most important there, and is currently 4.5us. If you do not answer fast enough, you just get garbage.
Using a shift register may require a faster clock speed, and a shift register ;D , so more space on board.
With a Tiny4313 costing something like 2 Euros, I do not think using a smaller device with a shift register is a good idea.
Quote from: Bryce on 20:56, 30 August 12
It uses the same address and databus, but everything external are addressed as I/0 with the /IORQ signal. Is it possible to poll the keyboard and write to the DDI-1 without timing out on the µPD ? I didn't think you could call an I/O address on every cycle. And if you could, wouldn't that slow the CPC down?
Internal/external, it's all the same, on the 464 the floppy interface was external, it's the same circuit on a 6128, but it's inside the case. The 8255, Gate array, Printer port, CRT conroller all use the IORQ signal.
You read or write to I/O address, can you explain what you mean by "call an I/O address"?
Yes, but other (non-standard) bits that are connected externally, are they limited to how often they could be called? My problem is that I have no idea about the Firmware routines or restrictions, I've never looked that deeply into it. So I've no idea what's allowed and what's not in the firmware.
Bryce.
Quote from: Bryce on 20:07, 30 August 12
That would be too much traffic for the EXP bus. Any other expansions (MegaFlash etc) may not work or work really slow. As the MegaFlash, SF2 and any floppy controller are very time sensitive, a delay like that would probably cause timing errors and malfunction.
Bryce.
Hmmm. Well, I didn't intend to simulate the CPCs keyboard on a hardware level. I thougt more about transferring a byte only when a key is pressed.
QuoteIt'll be interesting to see a usb keyboard hooked up to a cpc
Then comes the main problem...
Locomotive Basic is done for specific keyboards... and doesn't manage all those Extra keys... could it ?
I guess you will have to kustomise the keys, while the average square letter key can be swaped, others would need to get new "sticker" on it.
Also as told, modern "PC (or Amiga or ST...16bit+) keyboard has a lot of extra keys...
Perhaps a patched Locobasic ROM would be needed, or the Extra keys simply "discarded" ?
What is the theoric limitation in the number of keys a CPC can handle ? does the official CPC keyboard use the maximum or not ?
Extra bonus : manage to kustomise the USB keyboard to get the 464 or 664 (über!) colour theme.
Cyan keys FTW !
Quote from: gerald on 21:02, 30 August 12
On which CPC model you need to use the PS2 to CPC keyboard adapter?
I was trying to understand a little more about the HW on the CPC. I thought such a project should be a good DIY-first project ::) and I thought there were plenty of solutions out there .... but I was wrong .... I don't need it, is only nice-to-have.
I will TRY to do it first in a Schneider CPC464. The keyboard socket/cable there is very easy to hack. If it works I will try to take it to the expansion port. I have a 664 with keyboard problems and it would be nice to easy change it from a CPC to another.
As I write this post I see a Amstrad CPC464 motherboard and I see the connector which are use in the Schneider are in the Amstrad too but unused. They can be use to solder (people like me w/o experience need a lot of room ...... )
And ... when I think about using the expansion port for the keyboard I mean I use the expansion port ONLY with the keyboard extension and it only has to read there the bus. No other stuff attached. I think now it should not be a problem ..... ::) .... I think ;-) I don't have much know-how about it but trying to buffering what is attached to the CPC with his own power supply should not be extra load for the CPC.
Quote from: MacDeath on 22:25, 30 August 12
Then comes the main problem...
Locomotive Basic is done for specific keyboards... and doesn't manage all those Extra keys... could it ?
.....
What is the theoric limitation in the number of keys a CPC can handle ? does the official CPC keyboard use the maximum or not ?
It is like the solution of Gerald. USB/PS2 keyboard is attached to a MCU who act as a host for the keyboard. The microcontroller will have on the other side the pins which are attached to the connector of the original keyboard. You dont have to patch the ROM. Extra keys are not used ... I see it so ..... ;D
I agree, implementing the CPC keyboard matrix on a microcontroller is relatively easy and 100% compatible with all software.
Btw with a little creativity the extra keys can be used. There's enough pins on the Teensy 2++ to connect to the joystick port too, so the joystick with two buttons can be emulated by the keyboard. It's also possible to connect a PS/2 mouse in addition to the keyboard and emulate the AMX mouse.
It's also possible to assign keystroke sequences to the unused keys, so pressing e.g. F5 would "press" the keys R, U, N, Enter in sequence. I do this in my Atari->USB adapter, which emulates Ctrl+Z when the UNDO-button is pressed.
I like the macro idea Joska :)
@MacDeath: Due to the fact that the CPU reads a single byte to read the keyboard input, the theoretical limit would be 256 keys, but the CPCs matrix only scans 10x10, so the CPC keyboard connectors can only handle 100 keys at most (including the joystick inputs).
Bryce.
Quote from: Joss on 22:46, 30 August 12
If it works I will try to take it to the expansion port.
A solution with expansion and joystick port only is possible:
- you need to use IORQn and WRN connected on G2A/G2B of 74HCT138 instead of IOWRn to G2A only.
- add a DFF (74xx574) that will capture low part of C register from data bus. This DFF will be clocked by the same signals that trigger the uC. That is the same as for a CPC+.
Quote from: Joss on 22:53, 30 August 12
It is like the solution of Gerald. USB/PS2 keyboard is attached to a MCU who act as a host for the keyboard. The microcontroller will have on the other side the pins which are attached to the connector of the original keyboard. You dont have to patch the ROM. Extra keys are not used ... I see it so ..... ;D
Yes, most of the uC SW is doing the re-mapping of PC keyboard to CPC matrix. Unmatched key does nothing.
CPC FW is scanning 10 of the 16 possible lines. We may use the 6 free one to either add some more key or implement a comunication protocol with the uC for Keymap update or other function.
Obviously, all added feature will need SW support on CPC (ROM?)
Quote from: joska on 19:03, 30 August 12
The code I presented was for the opposite application - connecting a CPC keyboard to a PC/Mac via USB.
Connecting a USB keyboard to a CPC would be more difficult, but not impossible. And many USB keyboards also supports the PS/2 protocol, in this case it would be relatively easy.
I was hoping it was the other way around, because I have at least 1 cpc with a bad keyboard :(
Most if not all wired USB keyboard works as PS2 keyboard as well (need a small widget to adapt the connectors).
This is not true for all USB wireless one, Logitech Unifying does not :(
Same with USB Mice. Many of them will work on PS/2, but gaming mice with loads of extra buttons / features or Bluetooth Dongle mice won't work.
Bryce.
Quote from: arnoldemu on 09:06, 31 August 12
I was hoping it was the other way around, because I have at least 1 cpc with a bad keyboard :(
Both my CPC's has working keyboards, so I don't need this myself. But it's perfectly possible. You read the PS/2 keyboard, and convert the scancodes to matrix state by looking up a table. The matrix rows are monitored, whenever a row is pulled down by the CPC you update the column states accordingly.
Using a PS/2 keyboard with a Teensy/Arduino is very simple: Arduino playground - PS2Keyboard (http://www.arduino.cc/playground/Main/PS2Keyboard). The PS/2 keyboard is handled by an interrupt routine, so you can simply poll the rows continously.
Here's an outline of how this can be done with a Teensy/Arduino. As you see it's not very complicated, as the Teensy/Arduino takes care of all the PS/2 stuff and all the low-level stuff.
/*
Completely untested, unfinished code to attach a PS/2 keyboard
to a CPC keyboard connector.
Lots of assumptions are made here The following must be investigated
and the code adapted:
- All pin assignments are bogus! Refer to a real Teensy/Arduino here.
- From memory: The CPC keyboard connector has 9 rows and 10 columns. Must
be confirmed.
- Assumption: The CPC writes to the rows and read the columns. Could be the
other way around, must be checked.
- Assumption: The CPC matrix lines are pulled up by default.
- The update_matrix()-function is empty. This is the function that converts
the PS/2 scancodes to matrix state. I don't have time to look up all the
scancodes and the CPC matrix, I'm supposed to be working
*/
#include <PS2Keyboard.h>
#define KBDATA 1 // Bogus value, adapt this to your selected Arduino/Teensy
#define KBCLOCK 2 // Same here. Remember to use an interrupt pin, see library docs.
PS2Keyboard keyboard;
#define ROWS 9 // Number of rows in the CPC keyboard matrix.
#define COLUMNS 10 // Number of columns.
// Store matrix state in this array.
byte matrix[ROWS][COLUMNS]; // Should initialize this to sensible values!
// Use correct pins here!!
byte rowpins[] = {1,2,3,4,5,6,7,8,9};
byte colpins[] = {1,2,3,4,5,6,7,8,9,10};
void setup(void)
{
// Initialize the PS/2 keyboard
keyboard.begin(KBDATA, KBCLOCK);
// Set up the datapins for the matrix connections.
for (byte i = 0; i < ROWS; pinMode(rowpins[i++], INPUT));
for (byte i = 0; i < COLUMNS; pinMode(colpins[i++], OUTPUT));
}
void loop(void)
{
monitor_matrix();
if (keyboard.available())
update_matrix();
}
void monitor_matrix(void)
{
for (byte i = 0; i < ROWS; i++)
if (digitalRead(rowpins[i]) == LOW) // Row pulled low?
for (byte j = 0; j < COLUMNS; j++) // Yup. The CPC is scanning this row, lets update the columns.
digitalWrite(colpins[j], matrix[i][j]);
}
void update_matrix(void)
{
// In this function you convert the PS/2 scancodes to
// matrix state. The matrix state is stored in the matrix[][] array,
// each cell is either HIGH or LOW to indicate whether the key is
// pressed or not.
}
For those not familiar with the Arduino way of complicating C: Arduino "sketches" doesn't have a main(), this is added by the Arduino framework during the build. main() just calls setup() first and then loops around loop().
Edit: I just noticed that you only got something like 6us from the row is pulled down to the columns are read. Using digitalWrite() and a loop will be too slow I think. It's better to encode the row in two bytes in update_matrix() and just write these directly to the output ports.
Quote from: IanS on 21:52, 30 August 12
Internal/external, it's all the same, on the 464 the floppy interface was external, it's the same circuit on a 6128, but it's inside the case. The 8255, Gate array, Printer port, CRT conroller all use the IORQ signal.
I just took a proper look at the schematics and Z80 Datasheet. Seems I was confusing it with a different 8-bit architecture, which I also develop hardware for, but I won't mention it here :-X Calling the keyboard externally wouldn't have any negative effects on the speed of other devices. That's assuming that the modded firmware code reads and reacts to the keyboard at the same speed.
I'd still prefer a solution that wouldn't involve modding the firmware though. I prefer things to be completely Plug & Play.
Bryce.
Quote from: joska on 15:53, 30 August 12
- Use the Teensy's internal pullup-resistors on all the matrix lines. This prevents the inputs from floating, which could cause false readings.
Further, I'd set PORTx to 0 for the output lines and use DIRx to change between pullup and driven low as this guards you against a short when the corners of the matrix are pressed.
I would definitely second the recommendation to use a teensy or similar. I've used the ATMEGA32U4 in a number of designs and it's a great chip and being flashable over USB is great... There are enough IO pins to easily drive the matrix directly without relying on external chips too.
Quote from: ralferoo on 12:10, 31 August 12
Further, I'd set PORTx to 0 for the output lines and use DIRx to change between pullup and driven low as this guards you against a short when the corners of the matrix are pressed.
Good point, I didn't think of that.
Quote from: gerald on 08:52, 31 August 12
A solution with expansion and joystick port only is possible:
- you need to use IORQn and WRN connected on G2A/G2B of 74HCT138 instead of IOWRn to G2A only.
- add a DFF (74xx574) that will capture low part of C register from data bus. This DFF will be clocked by the same signals that trigger the uC. That is the same as for a CPC+.
perhaps to connect the output from uC to joystick need extra stuff (buffer and so) to protect the PSG port, just in case it is not protected.
If the uC works with a higher frequency as the CPC (today it can be done easily, I think) I don't think there should be problems with the timing.
Quote from: Joss on 16:55, 31 August 12
perhaps to connect the output from uC to joystick need extra stuff (buffer and so) to protect the PSG port, just in case it is not protected.
The joystick side quite save. The uC is driving the row bits in an open collector way. It only drive the line low, as will the keyboard membrane or a joystick swich do. When the key is release, the uC stop driving the row bits low, and the pullups within the PSG drive them high.
Quote from: gerald on 17:05, 31 August 12
The joystick side quite save. The uC is driving the row bits in an open collector way. It only drive the line low, as will the keyboard membrane or a joystick swich do. When the key is release, the uC stop driving the row bits low, and the pullups within the PSG drive them high.
Good to know :) thanks!!
Hi chaps,
It's weekend time so if you have a bit of spare time, you may try to do your own PS2 keyboard adaptor ;)
Here are the source and schematics of my own interface. Feel free to play with it.
There is no real documentation, but schematic should be self explanatory, as well as the code.
Code is compiled with avrgcc (WinAVR-20100110) using the provided makefile.
Schematic and sample board using DIL component and trough hole resitor/caps is provided in EAGLE 6.2.0 format
Random notes :
uC : Schematic is using a Tiny4313, but code will fit in a Tiny2313a (Tiny2313 should work as well, but I do not have any to check)
Pullup resistor on keyboard signal should not be needed (I do not have any on my boards). These are in the keyboard itself.
SV1 and R1 are not needed by current SW. These allow a single bit configuration using the embeded analog comparator.
QuoteMacDeath: Due to the fact that the CPU reads a single byte to read the keyboard input, the theoretical limit would be 256 keys, but the CPCs matrix only scans 10x10, so the CPC keyboard connectors can only handle 100 keys at most (including the joystick inputs).
I guess it would need to rewire some stuff on the motherboard/chips then ?
And also modify the firmware/Locobasic/OS....
As told, the extra keys could be rewired into Joystick or "Mouse" or even other stuffs... perhaps even a few comands for an Hxc Floppy emulator or Kustom MP3 reader (=tapes)...
Nice Gerald!
Now the question. Are you using the connections direct to the PPI pins at SV4? Is it possible to use the keyboard pins?
Thanks!!!
Quote from: MacDeath on 18:22, 31 August 12
As told, the extra keys could be rewired into Joystick or "Mouse" or even other stuffs... perhaps even a few comands for an Hxc Floppy emulator or Kustom MP3 reader (=tapes)...
MacDeath ... imagination is your limit ;D it can be adapted to your needs and the original keyboard can be save for the future ......
Quote from: Joss on 18:29, 31 August 12
Now the question. Are you using the connections direct to the PPI pins at SV4? Is it possible to use the keyboard pins?
These are easier to get on PPI, but are also on the main board (address/IOWRS runs everywere ;) ).
Line 4 bits however are only on PPI and the 74LS145 that then drive the keyboard matrix.
For a solderless solution you need to add the DFF as discussed in previous posts and use the exp port. I did not have time to do a schematic for this.
Hello!
My alternative is to go straight for USB keyboards.
I recently tried the USB ATMEGA, more specifically with a pair of Micropendous-A boards. Thanks to the LUFA libraries I have read in raw USB keyboards.
I hope to have some positive results in the future, but I'm too busy trying to wire a W5100 for hardware TCP / IP on the CPC (See Spectranet and Denyonet on the Spectrum and MSX...) :D
Hi my friend
Very good construction. We will try to fix it myself. It's easy you tell me the frequency Function and fuses for Tiny2313a.
Sorry for my English.
THANKS.
Fuses setting are the factory defaults : internal 8Mz oscillator + 1/8 ratio.
At start, the code switch itself to 8Mhz.
hi
Thank you so much for your prompt reply
2 gerald
Hi pal! I have build your PS2CPC controller but can`t make it work. Some questions please:
1. Fuse bits - default (CKDIV8, SUT0, CKSEL0, CKSEL2, CKSEL3 enabled), but how about CKOUT? It must be enabled too cause of receiving frequency to keyboard CLK input, i think so... May be I`m wrong? Please place your fuses configuration in the thread.
2. I use Tinny2313 without index A. May be this is the reason of malfunction?
3. Can you place here compiled hex?
4. Schematic and your board on photo have some difference. On schematic signal A11 goes to pin3 of HC138 but in photo it`s connected to pin36 of 8255 (IOWR). What connection is correct?
Sorry for disturbing and hope for quick answer! Best regards! Alexey.
Hi Alexey,
One of my collegue used to say "everithing not tested does not work", and I did not test the standalone version of the PCB >:(
There is a naming error on the connection of A8/A9 to the HC138 and these have to be swapped. In fact, the net label in eagle are correct but are wrongly positioned.
So you have to connect SV4 pin 9 to A8 and SV4 pin 8 to A9.
Regarding the Tiny2313, you can check that the code is running by using the numlock key to toggle the numlock LED. The code will switch the led on after the keyboard reset and then toggle it when you press the numlock key.
Quote from: n_sonic on 12:34, 27 November 12
1. Fuse bits - default (CKDIV8, SUT0, CKSEL0, CKSEL2, CKSEL3 enabled), but how about CKOUT? It must be enabled too cause of receiving frequency to keyboard CLK input, i think so... May be I`m wrong? Please place your fuses configuration in the thread.
The Keyboard clock is generated by SW. Enabling CKOUT fuse will prevent proper keyboad clock control and PS2 protocol.
Quote from: n_sonic on 12:34, 27 November 12
2. I use Tinny2313 without index A. May be this is the reason of malfunction?
3. Can you place here compiled hex?
Tiny2313 should be OK. Hex file is attached
Quote from: n_sonic on 12:34, 27 November 12
4. Schematic and your board on photo have some difference. On schematic signal A11 goes to pin3 of HC138 but in photo it`s connected to pin36 of 8255 (IOWR). What connection is correct?
The prototype is slightly different than the final version and A11 was connected to pin 3 of HC138. I later swapped A11 and IOWR so A11 does not have to slalom between other pins.
Thank you for the fast, full and complete reply! I can make my cpc6128 alive again with help of your board!Regards from friendly forum zx-pk.ru Thanks again! Alexey.
You're welcome !
Thanks to you for pointing the error :)
It's me again... Unfortunately all is not so easy. Controller don't want to start. I have tried two chips and two different programmers, checked all lines and connections. May be some errors in code, cause attiny don't reset the keyboard and don't generate keyboard clk without ckout enabled... :( Any ideas?
Here are the fuse configuration I am using. These are read from the device that is used in my CPC6218
[attach=2]
Questions :
1. What is the state of the keyboard clock/data lines (with the CLKOUT fuse disabled) ? Both are expected to be high unless there is a ongoing communication with the keyboard. If these are low all time, the keyboard may not have integrated pullups.
2. Did you mount the pullup resistors on the keyboard clock/data? if not, can you try with them ?
3. Are you using a true PS2 keyboard or a USB one with an adaptor ?
If you mean PS2 keyboard serial lines - both (clk and data) are in high level voltage (logic "1"). I'm using pull-up resistors 10k each in this lines. Without them the result is the same (high level and no reaction). Keyboard have PS2 interface, not USB. I think that the program isn't starting at all. Fuses are right. To program ic i use two programmers with parallel and serial programing. In ISP mode i program with modified AVRdude sw (with window interface) by USBasp programmer. Fantastic... :o Data memory should be empty or not?
Quote from: n_sonic on 22:47, 27 November 12
Data memory should be empty or not?
EEPROM is not used.
Can you check the following :
- reset pin (pin 1) is not shorted to vcc
- keyboard clock and data are not swapped ?
- Have you tried with an other keyboard ?
Also, do you have access to any debugging equipment (oscilloscope ?)
Can you also post a picture of your board and setup ?
Hi
Sorry for the late post on this topic,
I was searching too how to attach a ps/2 keyboard to our beloved CPC, i thing that is very interesting to preserve the cpc keyboard and for use on programming, testing, office jobs (anyone?) and for games like conversational games or the ones that don't need perfect timing pressing a key, i suposse that the ps2 to cpc adapter will produce some lag or input lag that in any games will not work well?
anyway i found a very very interesting project for spectrum "imar3" using the expansion port of the 48k/48k+, the adapter doesn't work on other speccy's, i suspect that it's the same problem with our cpc, not all the signals from the keyboard are on the expansion port.
What i like about the project it's that he is using old school electronic to make the adapter not last generation hardware that i think it's not the way to make expansions for the cpc, i like to stay with the same technologiy all the time, it's more cool with our cpc's :) and always will be replacements in the junk rooms of the world XD
here is the project (in english):
Adaptador de teclado PC para Spectrum (http://trastero.speccy.org/cosas/droy/imar3/imar3_e.htm)
And I like the Gerald solution that it's going directly to the PPI 8255, seems that is more simple and much more compatible.
Will be possible to adapt de imar3 project with Gerald idea to our amstrads?
@Joseman (http://www.cpcwiki.eu/forum/index.php?action=profile;u=135): But remember how the CPC keybard is read. The keyboard is attached to the AY and the Z80 only can access to the AY through the PPI. While in the ZX 48 is only attached to the $FE i/o port that you can capture easily from its expansion bus.
Then the complexity of your circuit will depend where you attach your new keyboard: AY is the most direct, because only needs to understand how the AY get the keyboard bytes (the zx interface is most similar about what is need at this level... but you are going to sweat for putting all those old and big ICs inside of a CPC); PPI needs understand how the PPI reads from the AY; Z80 will need sniffer the i/o ports used for write/read the PPI from the expansion bus during the read keyboard protocol.
With respect to not use "modern" technology in 2014, well CPLDs and FPGAs were born in 1984 and the only reason they were not used in 8 bits computers then, was cost and size. And for the old nerds justifying the lack of control with respect to use TTLs, they have not seen the modern tools for designing circuits, because you can draw your circuit using the TTLs you want and then the software generate a "binary" file for you can flash your exact design in the IC (even although it's not a bad thing learn a little of VHDL).
What do you prefer solder 15 TTLs or 1 CPLD? Or compare the size of a DK Tronics 256 KBs RAM Expansion with the 512 KBs RAM / 512 KBs ROM X-MEM? My philosophy is use the tools that make my work easier for giving the best i can, we are in 2014 and i doubt any want uses Brunword or Protext for write a text :P
Quote from: Joseman on 08:43, 15 June 14
What i like about the project it's that he is using old school electronic to make the adapter not last generation hardware that i think it's not the way to make expansions for the cpc, i like to stay with the same technologiy all the time, it's more cool with our cpc's :) and always will be replacements in the junk rooms of the world XD
here is the project (in english):
Adaptador de teclado PC para Spectrum (http://trastero.speccy.org/cosas/droy/imar3/imar3_e.htm)
So, I'm confused. This project requires the use of the PIC 16F84, essentially an entire computer on a chip, that was introduced over a decade after the 6128 was released. For comparison, FPGAs were available commercially at the time the 6128 was released and CPLDs even earlier still (they were the next intermediate stage after ULAs, PALs and GALs before FPGAs).
In what way is that more like "old school technology"? ;D
Much as SyX said, you can be sure if these techonologies made economic sense, Amstrad would have used them. You can see a GAL being used in the 6128 to control the RAM banking and the cost-down CPCs were Amstrad's testbed of using ASICs before they made the plus range.
Ok guys the two are right :P
the pic is nearly a decade over the cpc and it's right that amstrad made use of the (bugged) ASIC, it emulate various chips, but i hate emulators, i don't like the cpc+ range :P , and it's nearly impossible to be 100% accurate with the original chips (again, bugs on the asic).
I know, it's me, I don't like emulators and hardware emulating ancient consoles (the new fashion), if i want to play with an old computer or console, i use the original hardware, because it's the best accurate mode to use. Syx i know that i'm ¿beating around the bush?.
Talking about expansions i understand your point of view, and i agree with the use of modern hardware for this. But the idea to use "old" spares and chips it's for an idea that i have in mind since last year but i will not say anything about it ;) .
the real point for me is, can the hardware of the imar3 (with modifications) be attached to the ppi like Gerald's project and make a solution 100% compatible with the original cpc keyboard?
Quote from: Joseman on 20:02, 16 June 14
the real point for me is, can the hardware of the imar3 (with modifications) be attached to the ppi like Gerald's project and make a solution 100% compatible with the original cpc keyboard?
TBH, I'm not sure which side of the PPI Gerald's project attaches. It'd be relatively simple to hook something like this up to the keyboard matrix, assuming you have an old style 464 with easy to connect headers.
It'd be harder (probably not impossible, but harder) to do this as an add-on board on the PPI, as the keyboard matrix inputs go into the AY chip (where they could just be pulled low on input) but between the AY and PPI, you'd have to keep track of the AY's register state. You also
shouldn't just pull this data bus low, although if the AY chip is NMOS you will probably not cause too much damage if you did. So, really, you'd also have to intercept the control signals to the AY chip (fortunately, these do come from the PPI).
on the keyboard matrix side of the PPI, especially as there'd not really much much to worry about timing wise. It'd probably not be impossible on the CPU side of the PPI if the
So, overall, it'd be a bit of a pain. :-X
BTW, my CPC FPGA project uses a PS/2 keyboard. Personally, I find it takes a little bit of getting used to as when you're typing punctuation, it's easy to think "PC keyboard" and not type the same keys you would instinctively on a CPC. I guess it's the same problem as with a PC-based emulator too though.
Quote from: ralferoo on 20:24, 16 June 14
TBH, I'm not sure which side of the PPI Gerald's project attaches.
The interface is just hooked to the line number output of the PPI and Z80 signals that are used to write to the PPI register.
The interface is basically two chip : one 74LS138 and a microcontroller.
The 74LS138 is used to detect a write to the line port and generate an IRQ to the microcontroller.
The Microcontroller (89C2051 for the original version, AtTiny2313 for the later version) manage the PS2 keyboard and does the translation to amstrad keyboard matrix. Keyboard row update is done each time a key is pressed/release or when line changes.
The row ouput of the microcontroller is then connected to the AY input, which on the 6128 is also available on a unmounted resistor network, just between the PPI and the AY. So piggypacking the interface on the PPI was the obvious choice ;)
Quote from: Joseman on 08:43, 15 June 14
Will be possible to adapt de imar3 project with Gerald idea to our amstrads?
There is no need to adapt the imar3 ;) , my interface works the same way : a microcontroller to handle the PS2 keyboard, glue logic to interface with the CPC.
And if you want to have my interface on the CPC expansion connector, you just need to add a 4 bit buffer to emulate the PPI register and connect the row output to the joystick port. While there is no schematic of this, I've described it earlier in this thread.
Regarding using old/new ICs, I used only old LS ICs on the MegaFlash just so that it looks more retro. I could have put it all in a CPLD, but I thought it looked better with real Logic in DIP packages. The Flash obviously doesn't match as flash wasn't around back then.
@Gerald: Nice solution, how does it handle PC keyboards with a different language?
Bryce.
Quote from: Bryce on 08:35, 17 June 14
@Gerald: Nice solution, how does it handle PC keyboards with a different language?
The keyboard translation is handled by a set of conversion tables. The download version only include a UK PS2 layout to UK ROM CPC. But I also have PS2 US layout to UK CPC and PS2 FR layout to FR CPC. Obviously these tables can only be changed by recompiling the whole code.
The original design could deal with two keymap, selected by a jumper. The 'modern' version with AtTiny could handle more thanks to the free oscillator pins.
That's good. Maybe some simple solder-bridges could be added to the PCB to select the language? Real jumpers aren't really needed as this choice would probably only ever be made once.
Bryce.
I can't understand what the 3 pin header is for on the schematic?
That's probably the jumper to select which keyboard layout you are using.
Bryce.
Quote from: Munchausen on 13:55, 17 June 14
I can't understand what the 3 pin header is for on the schematic?
As Bryce just said, it is the jumper used to select the keyboard layout.
By slightly loading one bit or the other, the internal comparator will be 0 or 1. That was the only way to get one bit for configuration from the old design (with AT80C2051). It is currently not used by the release code.
I'm following this thread closely, I'm highly interested; I wonder if someone will sell the pcb?
Hello, i assembly this interface but:
When i run my CPC464 with interface and connected ps2 keyboard, ps2 keyboard not working. If i run cpc and connect ps2 keyboard later all is ok. I check two diffrent keyboards, with and without pullup resistors. Any idea?
I use attiny 2313A and 74LS138 in prototype board.
A8 to pin 1 ls138,
A9 to pin 2 ls138
A11 to pin 3 ls138
IOWR to pin 4 ls138
amstrad CPC 464 ps2 keyboard interface test - YouTube (https://www.youtube.com/watch?v=KWDoPz1ggIw&list=UUq0qTOm1ux2WOhEDPbe0Ofg)
Anyway i design small pcb for this interface ;)
(http://images54.fotosik.pl/584/d858df3cd18215d3m.jpg) (http://www.cpcwiki.eu/forum/%5BURL=http://www.fotosik.pl/pokaz_obrazek/d858df3cd18215d3.html)](http://images54.fotosik.pl/584/d858df3cd18215d3m.jpg) (http://www.fotosik.pl/pokaz_obrazek/d858df3cd18215d3.html)
You don't know how many time i've been waiting for something like this!
The board is powered with the same source that the cpc?
I don't understand the attiny 2313A but... perhaps the keyboard detection doesn't work well because the board doesn't initialize fast enough (for some reason) but if you have the board totally working, then connect the keyboard, the autodetection is fine?
How about the game compatibility?
thanks for this project!!!!!!!!!!!!!
Regards
Jose
Well but is Gerald project i only assembly it and made PCB design. Nothing special. If Gerald give me permission i can made some boards assembled or not. But this still need some work.
Quote from: Piotr on 06:08, 02 January 15
When i run my CPC464 with interface and connected ps2 keyboard, ps2 keyboard not working. If i run cpc and connect ps2 keyboard later all is ok. I check two diffrent keyboards, with and without pullup resistors. Any idea?
That's strange, I've never had problems with the keyboard connected at powerup, however I only tested it with 3 or 4 different one in 2 CPC (464 / 6128).
If the keyboard is working when you plug it after power up, the connection to the CPC is OK and this is only a SW issue.
Could you try by removing the capacitor on the reset line (C1) so the microcontroller only use its internal power on reset. I suspect a race condition in the keyboard and microcontroller reset.
Quote from: Piotr on 10:26, 02 January 15
Well but is Gerald project i only assembly it and made PCB design. Nothing special. If Gerald give me permission i can made some boards assembled or not. But this still need some work.
Permission granted ;)
But as you say, we need to check that there are no other blocking issues like the one you have.
Also, people need to know that the public project only support UK keyboard on UK CPC.
New keymap (new FW) are needed for other configuration. I have US to UK and FR to FR available, but we may need german and spanish support as well.
Quote from: Joseman on 10:00, 02 January 15
How about the game compatibility?
Game compatibility is limited by the following :
- you cumulate PS2 matrix clash with CPC matrix clash
- you have a added lag compared to the native CPC keyboard (matrix -> PS2 -> uC -> CPC matrix convertion ).
Gerald i sit on it all night ;) But i start with it on previous evening . To be honest i think use this interface for my CPC464 new mainboard what i plan do. If i made pcb and send one or two to you can you take time to check? And thank you for this.
Quote from: gerald on 10:44, 02 January 15
Game compatibility is limited by the following :
- you cumulate PS2 matrix clash with CPC matrix clash
- you have a added lag compared to the native CPC keyboard (matrix -> PS2 -> uC -> CPC matrix convertion ).
Well, i use 2 playstation pads for gaming on the cpc, but sometimes there is need to pause the game or some special static key like (i)nventory, (m)ap, etc... or text adventure games where there is not need of ultra full speed on this keys and there isnt' keyboard clash problem with that, i think that this project is really the last chain for the cpc-at users...
Regards
Jose
Quote from: Piotr on 11:29, 02 January 15
Gerald i sit on it all night ;) But i start with it on previous evening . To be honest i think use this interface for my CPC464 new mainboard what i plan do. If i made pcb and send one or two to you can you take time to check? And thank you for this.
I could test it, but not before 2 weeks. I just hope this is no a keyboard induced problem.
No panic ;) We all busy ;)
I redraw pcb for easier fit. My idea:
Solder ic socket piggyback on AY chip, (lines X0 to X7 ,VCC and GND done) , insert PCB using goldpins to socket , connect rest of signals via wire to pcb.
(http://images54.fotosik.pl/587/7b77b918f80661bam.jpg) (http://www.cpcwiki.eu/forum/%5BURL=http://www.fotosik.pl/showFullSize.php?id=7b77b918f80661ba)](http://images54.fotosik.pl/587/7b77b918f80661bam.jpg) (http://www.fotosik.pl/showFullSize.php?id=7b77b918f80661ba)
Nice Idea, but the AY is usually solder in. Pity there's no socketed IC with these signals.
Bryce.
Quote from: Bryce on 22:45, 05 January 15
Nice Idea, but the AY is usually solder in. Pity there's no socketed IC with these signals.
Bryce.
Is there any electronically problem with socketing the cpc chips? more impedance on the signals? perhaps any noise on the signals if the socket is low quality or something like this?
No, at those frequencies you won't have issues with noise and the (extremely low) additional impedance on a 5V system isn't critical. Over time sockets can cause problems due to dirty contacts, chips coming loose from vibration or whatever, but otherwise the CPC will work fine with sockets. I have a fully socketed 6128 somewhere and I always use sockets when I repair peoples CPCs, no matter what IC I needed to change. If possible I always use the more expensive "turned-low-profile" sockets, rather than the cheaper "dual-wiper" type.
Bryce.
Quote from: Bryce on 13:54, 06 January 15
If possible I always use the more expensive "turned-low-profile" sockets, rather than the cheaper "dual-wiper" type.
Bryce.
with turned low profile you say something like this?:
http://au.rs-online.com/web/p/dil-sockets/0801796/ (http://au.rs-online.com/web/p/dil-sockets/0801796/)
have you any trusty online store with quality on that?
Yes, that's the type. You should be able to buy them from almost any local or online supplier. I buy mine here: IC-Sockel bei reichelt elektronik (http://www.reichelt.de/IC-Sockel/2/index.html?&ACTION=2&LA=2&GROUPID=3215)
Bryce.
Ok yesterday i sent PCB to factory. I expect it approx 29 january.
Good to know that
i'm keeping an eye on this project
Boards on the way,
(http://images52.fotosik.pl/606/111856b659e99f20med.jpg) (http://www.cpcwiki.eu/forum/%5BURL=http://www.fotosik.pl)](http://images52.fotosik.pl/606/111856b659e99f20med.jpg) (http://www.fotosik.pl)
Are these all spoken for or would one be left over? I quite fancy a towerised Cpc lol.
I don't think that these are reserved because i want 2 and nobody told me nothing!! :P
Just an idea: Open a new tread for it and explain exactly what it is and what you want for one. Somehow all these things are hard to find in all the posts here. :)
Sure, i do it first when i assembly working board, now is somewhere beetween China and France (DHL courier) , i expect PCB delivery in wenesday-thursday.
Board,
(http://images53.fotosik.pl/611/c7e5bd4847c3c237m.jpg) (http://www.cpcwiki.eu/forum/%5BURL=http://www.fotosik.pl/showFullSize.php?id=c7e5bd4847c3c237)](http://images53.fotosik.pl/611/c7e5bd4847c3c237m.jpg) (http://www.fotosik.pl/showFullSize.php?id=c7e5bd4847c3c237)
In CPC 464,
(http://images52.fotosik.pl/611/8a6a3432aab3a380m.jpg) (http://www.cpcwiki.eu/forum/%5BURL=http://www.fotosik.pl/showFullSize.php?id=8a6a3432aab3a380)](http://images52.fotosik.pl/611/8a6a3432aab3a380m.jpg) (http://www.fotosik.pl/showFullSize.php?id=8a6a3432aab3a380)
But is problem again, interface not detect keyboard correctly.( i check few Attiny) I run CPC and CPC don't see PS2 keyboard, i uplug it and plug it back on running system, keyboard start working.
Quote from: Piotr on 17:07, 31 January 15
But is problem again, interface not detect keyboard correctly.( i check few Attiny) I run CPC and CPC don't see PS2 keyboard, i uplug it and plug it back on running system, keyboard start working.
Did you check with a AtTiny2313A ? That the one I've used on the original design.
I check with attiny 2313 in THT , attiny 2313 smd, 2313A smd, and bigger attiny 4312. Also pullup res in, and out, effect is as i say before.
Quote from: Piotr on 17:07, 31 January 15
But is problem again, interface not detect keyboard correctly.( i check few Attiny) I run CPC and CPC don't see PS2 keyboard, i uplug it and plug it back on running system, keyboard start working.
Are you passively listening to the PS/2 keyboard or sending it commands?
Some keyboards are quite fussy about this kind of thing and like being told to change to mode 2 before they work. You could also try sending it a reset command.
Quote from: ralferoo on 01:17, 01 February 15
Are you passively listening to the PS/2 keyboard or sending it commands?
Some keyboards are quite fussy about this kind of thing and like being told to change to mode 2 before they work. You could also try sending it a reset command.
The keyboard is explicitly reset at power up by the microcontroller :
- 0xFF : reset command
- wait for end of self test (keyboard should return AA)
- 0xF6 : set default, should reset to mode2
- 0xED 0x02 : num lock led ON
- 0xF4 : enable scanning
What is interresting is that Piotr keyboad only works if it get unplugged an plugged after power up. This could mean that it does not like the reset sequence.
@piotr : is the capslock led on after power up ?
The keyboard set the 3 led on during reset, then reset them all. The microcontroller will only light the numlock once the reset is done.
Hello, sorry for delay so:
Attiny 2313A AVR studio 4, 2 keyboards, one UK layout second one French.
Power up Amstrad and interface and keyboard connected, computer don't see keyboard, i unplug and plug back, interface start working. On both keyboards.
If i press numlock key, keyboard hanging again and i can't write. Led from numplck noty working.
Ok, Gerald i go to post office right now and i send you interface.
Quote from: Piotr on 15:45, 02 February 15
If i press numlock key, keyboard hanging again and i can't write. Led from numplck noty working.
Ok, it seems we got something to look at.
Pressing numlock will make the uC to toggle the numlock led, and it looks like your keyboards does not like it. The init sequence does that as well.
What are the exact model of your keyboard ?
Quote from: Piotr on 15:45, 02 February 15Ok, Gerald i go to post office right now and i send you interface.
Finger crossed that it's not only keyboard related ???
One is Noname China UK layout, second is Logitech k120 French layout. I try also connect USB keyboard but without sukcess. Ok, we see. For now i finish next floppy interface to ZX Spectrum and i'm very busy assembling it for people.. Ufff.
Ok, today next keyboard arrived, and working fine. I open second topic about this interface.
Quote from: Piotr on 14:25, 05 February 15
Ok, today next keyboard arrived, and working fine.
Good and bad news ;D . We still don't know why the other do no work.
True, but i do mistake, my second french keyboard is also China noname. I order HP from Amazon and HP keyboard working nice.
Quote from: Piotr on 19:49, 05 February 15
True, but i do mistake, my second french keyboard is also China noname. I order HP from Amazon and HP keyboard working nice.
Could you try this updated version on you noname keyboard ?
O, thank you i check it in wenesday. Tomorrow i need jump to London. Crazy life, no time for anything.
OK,i back to topic ;) Sorry for delay but life is life.
I flash interface with new hex but now effect is:
On my HP keyboard all ok but
ON my noname keyboards( both )efect is like i pres 1 and hold so computer print on screen 1111111111111111111111111111111111111...
Also important thing, where is this sign what allow call DRIVE in parados, or call futureos? In amstrad keyboard is under @.
Quote from: Piotr on 09:45, 21 February 15
I flash interface with new hex but now effect is:
On my HP keyboard all ok but
ON my noname keyboards( both )efect is like i pres 1 and hold so computer print on screen 1111111111111111111111111111111111111...
That's better ;D , but expected!
Is the keyboard always issuing 1 when you press a key ?
Is the numlock led working and can you toggle it ?
Quote from: Piotr on 09:45, 21 February 15
Also important thing, where is this sign what allow call DRIVE in parados, or call futureos? In amstrad keyboard is under @.
Are you using a french keyboard ? whith a french ROM ? If so you need the proper code of the AtTiny : PS2CpcFR.hex. On french ROM, the | is mapped to ù.
If you are using a UK keyboard with the UK rom, the | is located between the left shit and Z.
The SW convert keypress from the PS2 keyboard to the CPC matrix according to the symbol (or equivalent, like @ and à on a french layout). Mixing layout will not give you what you want ;)
Quote from: Piotr on 09:45, 21 February 15
Also important thing, where is the sign "|"which allows to call FutureOS? In amstrad keyboard is under @.
On my laptop keyboard (US version) it's on the key over the large "Enter", on the key it's written "|" and "\". Hope this helps. :)
Ok, back to topic .
NONAME keyboard connected, i switch on CPC,dont press any key but CPC start print 111111 on screen (always) , numlock not working.If i press keys nothing change.
Hi there,
i am interested using this PS/2 Converter. Nice work!
I have a plain CPC 464 Mainboard without case and i want to make a PC case mod.
Is it possible to get a PCB like showed in the pictures above?
Schematic for use without PPI port available (as in Plus)
Not tested ;D
Gerald you are master, Just CPC 6128 plus is one step closer ;)
Quote from: Piotr on 15:58, 20 June 15
Gerald you are master, Just CPC 6128 plus is one step closer ;)
Hmmm, OK, SO we have sorted the lack of spares for the ACID, who (if anyone) is working on a full reverse engineering of the ASIC? LOL
Or are you thinking about emulating it somehow.. in which case I guess it is not a "
Just" anything.
Craig
Why emulate if i have orginal Asic's?
Quote from: Piotr on 08:42, 21 June 15
Why emulate if i have orginal Asic's?
I was unaware of that. If a remake of the plus is on the cards, count me in ;)
The whole conversion is really amazing, and the keyboard board just great. I have been thinking for a long time what to do in case of keyboard failure in one of the Plus and this could be the answer :) . There is always the possibility of substituting the Plus keyboard with one coming from a "normal" 6128 but it seems a bit painful to disassemble a computer just to give life to another.
Quote from: Piotr on 08:42, 21 June 15
Why emulate if i have orginal Asic's?
Really? How much did you get? Where to get em? :o
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250), how would you connect this circuit to a CPC+?
EDIT: sorry I just saw your post on the previous page!
Very old topic... Gerald, hi! I do not know when you will read this post, but i have a small question to you. How about a mistake in schematic? IC2 pin 13 and IC3 pin 7 connection? May be IC3 pin 7 must be connected to pin 14 of IC2....? ;)
Quote from: n_sonic on 23:32, 27 January 16
Very old topic... Gerald, hi! I do not know when you will read this post, but i have a small question to you. How about a mistake in schematic? IC2 pin 13 and IC3 pin 7 connection? May be IC3 pin 7 must be connected to pin 14 of IC2....? ;)
The 74HCT138 detect writes to PPI port C (F600 = xxxx 0x10 xxxx xxxx). PPI only see A11 (used as chip select) and A9-A8 (used a A1-A0).
Since 74HCT138 input are wired as follow :
A = A8 = 0
B = A9 = 1
C = A11 = 0
You want to detect CBA = 010 = 2, So I am using Y2 on pin 13
Anyway, i don't want to injure you, dear Gerald, but in my one it works fine realy in this wariant 14-7. Working with all my keyboards, brand and noname china. May be it's mystical, but it works... Some time ago i decided to reanimate this (after four years :) )project. Two days of hard work, replacing avrs and hct138, cheking all wires and contacts... It starts working. I can place hear bios rom rp23256 and your hex files correctly operating in my case. May be it will help to some members of this forum...
Quote from: n_sonic on 12:33, 28 January 16
Anyway, i don't want to injure you, dear Gerald, but in my one it works fine realy in this wariant 14-7. Working with all my keyboards, brand and noname china. May be it's mystical, but it works... Some time ago i decided to reanimate this (after four years :) )project. Two days of hard work, replacing avrs and hct138, cheking all wires and contacts... It starts working. I can place hear bios rom rp23256 and your hex files correctly operating in my case. May be it will help to some members of this forum...
No injure ;)
14-7 variant will work if you swap A8/A9, which was the case on the 1st released schematics (label were wrongly placed) : Is there any recent project to connect a PC (PS/2) keyboard to the CPC? (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/is-there-any-recent-project-to-connect-a-pc-%28ps2%29-keyboard-to-the-cpc/msg53712/#msg53712)
BTW, here is the latest version, which should work with all keyboards.
I've fixed the PS2 protocol errors that cause some keyboard to fail (Thanks to @Bryce (http://www.cpcwiki.eu/forum/index.php?action=profile;u=225) for sending one of these keyboard)
I've also slightly optimised the code for AVR
Thanks Gerald! You`re the best as always! Great wishes from "well-known" Crimea, Sevastopol city... :D
Folks, I wonder if you could help me with this project :) I've built it on a piece of perfboard, using the bits and pieces I had at hand (SMD ATTiny2313 and DIL HCT138). It was a challenge to make it work, as I based my work on the 'wrong schematic' with A8/A9 swapped, but logic analyzer and a bit of brain work gave me the hint.
Now, it sort of works, but a single keypress usually results in two different CPC keys being emulated - e.g., pressing 'w' on PS/2 keyboard results in 'wq' or 'qw' displayed on the screen. My first idea is that the ATTiny is somehow slow or whatever. Is there any specific change needed for ATTiny2313 (other than makefile target change)?
Thanks!
Quote from: zrusavpt on 20:38, 20 April 17
Folks, I wonder if you could help me with this project :) I've built it on a piece of perfboard, using the bits and pieces I had at hand (SMD ATTiny2313 and DIL HCT138). It was a challenge to make it work, as I based my work on the 'wrong schematic' with A8/A9 swapped, but logic analyzer and a bit of brain work gave me the hint.
Now, it sort of works, but a single keypress usually results in two different CPC keys being emulated - e.g., pressing 'w' on PS/2 keyboard results in 'wq' or 'qw' displayed on the screen. My first idea is that the ATTiny is somehow slow or whatever. Is there any specific change needed for ATTiny2313 (other than makefile target change)?
Thanks!
The 2313 is fast enough for the task.
The double key may be due to the connection to the keyboard itself. This may happen if the capacitance of the connection is high enough to prevent the keypress to go up fast enough between 2 rows.
Did you try to add pull-up on the keyboard rows (about 4k to 2.4k)
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!
Quote from: zrusavpt on 18:19, 21 April 17
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).
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?
Quote from: zrusavpt on 10:01, 23 April 17
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.
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:
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 :)
Quote from: zrusavpt on 19:18, 23 April 17
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:
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.
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 :) )
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
Quote from: The Equalizor on 22:14, 30 July 17
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.
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
Quote from: The Equalizor on 10:18, 08 August 17
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 ?
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
You should have aligned the outputs with the CPCs Mainboard connector, then you could have directly mounted it on pin headers.
Bryce.
Everyone's a critic :p
But seriously the pins will probably line up with cp03 anyway so that might be doable anyway.
Regards
Rob
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.
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
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 (https://youtu.be/QKIwnlv2PhQ)
Regards
Rob
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
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250),
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
Quote from: The Equalizor on 14:55, 17 October 17
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.
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.
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?
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 ?
Quote from: gerald on 10:50, 27 February 22According 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. :o 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 8)..
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.
Quote from: megatronuk on 13:01, 27 February 22A1/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 8)..
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
A=0=PPI_A0
B=1=PPI_A1
C=0=WRN
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
\ /
Quote from: gerald on 13:30, 27 February 22The we use 74138 Y2 output to detect write to register C of the PPC which whould be
A=0=PPI_A0
B=1=PPI_A1
C=0=WRN
According to the diagram included in the PS2Cpc 1.0b zip file, A1 and A0 are flipped compared to that, and C on the 138 is actually CS, not WRN.... and that's how the board was made and how it's connected up. Are the diagram and board schematics incorrect? :(
If I change the PS2Cpc connections so that the 138 is connected as per your table above (pin 1=A0, pin 2 = A1, pin 3 = WRN ... and I therefore assume pin 4 = CS?) the keyboard reverts to no input other than the number pad enter key.
Quote from: megatronuk on 13:51, 27 February 22Okay, 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
\ /
Everything is shifted by one line. That's usually a side effect to the interrupt handler being too slow to update the output when selected keyboard line change.
Can you retest with the original HEX file ?
You also seem to have a issue on AY bit 3 that was not there before.
Sure, I'll give it a go with a reflash from the original hex file from the 1.0b sources.
Both the original .hex file you provided in the 1.0b source as well as the same code recompiled with the 'inline' attributes defined produce the same behaviour and same key mapping.
The inline version is built with:
$ avr-gcc --version
avr-gcc (GCC) 5.4.0
Copyright © 2015 Free Software Foundation, Inc.
Quote from: gerald on 16:25, 27 February 22You also seem to have a issue on AY bit 3 that was not there before.
I haven't changed any of the connections to the AY chip - they have all been left as-is and I'm 100% certain that continuity between them all is perfect - but to be sure I've just re-checked each of the 8 pins now; they all check out, no loose connections, no bridges.
I Hope the solution can be found, and I'm sure it will be.
Looking Forward to a re-release of confirmed circuit diagram and Firmware :D
Quote from: Graham on 18:02, 28 February 22I Hope the solution can be found, and I'm sure it will be.
Looking Forward to a re-release of confirmed circuit diagram and Firmware :D
Yeah, I hope so! I really do need a working PS/2 keyboard I/f to be able to use this CPC... I have incredibly tight restrictions on what I can have out at any time, so the only way I can use it is if it is up on a shelf out of the way, so a KVM switch is my only option for almost all of my retro computing kit. I think the only system I'm missing a remote keyboard for now is my BBC Master... Speccy, Atari XE, MSX, ST, Amiga are all working through a Belkin PS2 KVM!
im trying to build this up on a breadboard currently...
it seems the keyboard is active (num led is lit)
but most the keys dont work.. some keys (very few) are pumping out multiple characters...
im using a US keyboard... im guessing the key codes that the US keyboard sends are different to the UK keyboard key codes..
does anyone know if that sounds right?!... i could try adding the US keyboard layout to the code...
edit: update...i resoldered everything.. and now it works perfectly! no issues whatsoever!
no matter.. sorted..
..anyone help me get the | key to show up!
my ps2 keybaord has the | key next to the backspace key.. pressing it gives # ...and shifting that key gives nothing...
if i press " i get '
if i shift " i get @ ( " is ps2 key near enter.. i know its swapped to 2 key for cpc)
i cant seem to get the pipe | to show up no matter what i do....every other key is fine...
hmm.. seems if i hold shift... hold L and press ' the | shows up... but with the L in front!...strange!
edit: seems i can even jsut hold shift, hold space and press ' makes it show up... ..i might be able to live with that!