CreatiVision Console re-Creation
Re: CreatiVision Console re-Creation
Great to see your methodical design process paying of with positive results, looking forward to see more. Its nice to see a led twinkle when the keyboard is initialised by its host though without caps lock it would be of little practical use.
Re: CreatiVision Console re-Creation
Hi David. I might ask for some help here. 
I’m pretty much happy with my bidirectional PS/2 software implementation, so far, and the scope measured operation.
I now get pretty much identical commands and response handshake, when comparing my CreatiVision keyboard to my generic PS/2 keyboard, when my attached computer (Host) is reset.
This is what my Host to generic PS/2 keyboard handshake looks like after a computer reset:
i.e. The generic PS/2 keyboard (that I have) seems to only respond with a “resend” when asked for it’s ID. With the Host giving up after 6 attempts. But the generic Keyboard then operates perfectly. I've also tried responding correctly from the CreatiVison Keyboard (0xAB & 0x83), as well as duplicating the generic Keyboards "Resend" only (0xFE) response.
I also get virtually identical key-press Scancode transmission, when comparing (on the scope), between the CreatiVision keyboard and my generic PS/2 keyboard, when connected to the Host
In fact, the only real difference, is that the CreatiVision Keyboard connection is very clean (nice!), whereas my generic PS/2 keyboard is quite noisey, but the levels are identical etc.
Below are scope captures of the ‘Q’ key (0x15 Scancode), from both the generic PS/2 keyboard (first), and the CreatiVision keyboard (second), when connected to my Computer (Host).
As you can see, essentially an identical transmission! Despite the apparent clean and tidy transmission, I was still getting random character errors and repeating keys registering when using the CreatiVision keyboard with my retro PS/2 input computer.
So… this lead me back to the electrical interface. Just measuring the unpowered interface’s apparent pull-up resistance, from the Clock / Data lines to the PS/2 connection 5V line, I was seeing: 1.2M on the generic Keyboard, 4.7K on the Computer (Host), and my current 10K pull-ups on the CreatiVision Keyboard!
This lead me to think that the generic keyboard perhaps infact had no pull-ups? And the Host computer appears to have it's own 4.7K pull-ups.
This, leading to the combination with my CreatiVision Keyboard 10K pull-ups, perhaps being too strong a pull-up for the Host to consistently register the signal low levels? (assuming some series resistance also in the Host computer's interface).
So… I’ve snipped my 2x 10K pull-ups to take them “out of circuit” on my CreatiVision Keyboard, and I’m now getting a lot closer!
I now have significantly improved character accuracy, but still getting occasional random incorrect characters and repeats (perhaps key release code not interpreted?).
I noticed the Clock / Data edge timing has altered a bit with the 10K pull-ups removed, meaning only the Host's 4K7 pull-ups are in play.
I will experiment further with fine-tuning the Data level transition timing, although this timing may also potentially vary with different Hosts?
But, this is where I need some help. I currently only have the one retro PC with a PS/2 input. So only one “Host” to test with!
I’m curious if you were to also take the 10K pull-up resistors out of play, whether you’d see any difference with your PS/2 host tests? (albeit, still a unidirectional interface, with the original code).
It really shouldn’t be this hard, but I do like a good challenge. I’m now off to read more on the appropriate PS/2 interface pull-up implementation (Host? / Device? / Values etc.). Perhaps only the host device should implement the Open Collector pull-ups?
Anyway, tomorrow is another day.
I’m pretty much happy with my bidirectional PS/2 software implementation, so far, and the scope measured operation.
I now get pretty much identical commands and response handshake, when comparing my CreatiVision keyboard to my generic PS/2 keyboard, when my attached computer (Host) is reset.
This is what my Host to generic PS/2 keyboard handshake looks like after a computer reset:
Code: Select all
Host - Reset (0xFF)
Device - Acknowledge (0xFA)
~380ms delay
Device - BAT Success (0xAA)
~150ms delay
Host - Set Key Type Typematic - Disable Break Codes (0xFB)
Device - Acknowledge (0xFA)
Host - Read ID (0xF2)
Device - Resend (0xFE)
Host - Read ID (0xF2)
Device - Resend (0xFE)
Host - Read ID (0xF2)
Device - Resend (0xFE)
Host - Read ID (0xF2)
Device - Resend (0xFE)
Host - Read ID (0xF2)
Device - Resend (0xFE)
Host - Read ID (0xF2)
Device - Resend (0xFE)
I also get virtually identical key-press Scancode transmission, when comparing (on the scope), between the CreatiVision keyboard and my generic PS/2 keyboard, when connected to the Host
In fact, the only real difference, is that the CreatiVision Keyboard connection is very clean (nice!), whereas my generic PS/2 keyboard is quite noisey, but the levels are identical etc.
Below are scope captures of the ‘Q’ key (0x15 Scancode), from both the generic PS/2 keyboard (first), and the CreatiVision keyboard (second), when connected to my Computer (Host).
So… this lead me back to the electrical interface. Just measuring the unpowered interface’s apparent pull-up resistance, from the Clock / Data lines to the PS/2 connection 5V line, I was seeing: 1.2M on the generic Keyboard, 4.7K on the Computer (Host), and my current 10K pull-ups on the CreatiVision Keyboard!
This lead me to think that the generic keyboard perhaps infact had no pull-ups? And the Host computer appears to have it's own 4.7K pull-ups.
This, leading to the combination with my CreatiVision Keyboard 10K pull-ups, perhaps being too strong a pull-up for the Host to consistently register the signal low levels? (assuming some series resistance also in the Host computer's interface).
So… I’ve snipped my 2x 10K pull-ups to take them “out of circuit” on my CreatiVision Keyboard, and I’m now getting a lot closer!
I now have significantly improved character accuracy, but still getting occasional random incorrect characters and repeats (perhaps key release code not interpreted?).
I noticed the Clock / Data edge timing has altered a bit with the 10K pull-ups removed, meaning only the Host's 4K7 pull-ups are in play.
I will experiment further with fine-tuning the Data level transition timing, although this timing may also potentially vary with different Hosts?
But, this is where I need some help. I currently only have the one retro PC with a PS/2 input. So only one “Host” to test with!
I’m curious if you were to also take the 10K pull-up resistors out of play, whether you’d see any difference with your PS/2 host tests? (albeit, still a unidirectional interface, with the original code).
It really shouldn’t be this hard, but I do like a good challenge. I’m now off to read more on the appropriate PS/2 interface pull-up implementation (Host? / Device? / Values etc.). Perhaps only the host device should implement the Open Collector pull-ups?
Anyway, tomorrow is another day.
Re: CreatiVision Console re-Creation
Ok Greg, happy to oblige. I can try that easily enough on a few systems and let you know what happens. David.
Update, the signal lines look ok with pull down to zero whether the 10k pull-up is in circuit or not. master board also has 10k pull-up fitted.
I tried hot swapping again and this time it worked, the master interface neds the initial handshake to get going, sometimes hot swap from PC to MECB keyboard doesn't work.
Top view is PS2 keyboard, bottom view is MECB keyboard without pull-up resistors.
Update, the signal lines look ok with pull down to zero whether the 10k pull-up is in circuit or not. master board also has 10k pull-up fitted.
I tried hot swapping again and this time it worked, the master interface neds the initial handshake to get going, sometimes hot swap from PC to MECB keyboard doesn't work.
Top view is PS2 keyboard, bottom view is MECB keyboard without pull-up resistors.
Re: CreatiVision Console re-Creation
Yes, my research so far seems to suggest 10K is indeed the suitable pull-up value (as I'd originaly ascertained), and this is common to both controller and keyboard implementation (making for a combined 5K pull-up resistance on the line). This also sounds reasonable, considering 4K7 was the common pull-up value used in the 5V TTL days.
I'm begining to suspect that my Retro F256K2 computer's "modern" PS/2 interface may be leading me up the wrong path. The fact that it uses apparent 4K7 pulll-ups, and being FPGA based, I suspect it is internally interfacing to a 3.3V port pin (with possibly a 5V tolerant series interface resister). This would potentially lead to a stronger than expected pull-up perhaps affecting the low level detection reliabilty.
This is good news to hear. It at least confirms I'm not going crazy! It also suggests that my new code / bidirectional interface probably will resolve the issue.
But, I think I now need to find another PS/2 Host to test with. I'll dig around in my storage for an old PC with PS/2 input. Or, perhaps I should build a @lenzjo MECB_SYS_IO board, so I can directly replicate your PS/2 host setup?
Re: CreatiVision Console re-Creation
Well, I think I'm pretty much all done with CreatiVision Keyboard v2.0 
After digging out an old 386 PC with a PS/2 keyboard port, a lot of analysis, testing, and code optimisation, I’m now finally happy with my full-blown bi-directional PS/2 keyboard.
It’s been a fun project, and a great PS/2 protocol implementation detail “learning experience”. So, thank you to David, for prompting me with this interesting challenge!
I’m just about to “sleep on” my final PCB changes, before submitting a v2.0 PCB for manufacture.
The PCB changes just involve removing the redundant pull-up resistors (as we now have internal pull-ups), and routing Port C0 & C1 of the AVR as the new PS/2 port input sense lines.
To use the new v2.0 firmware with an existing v1.x PCB, will just require a couple of jumper wires (to hook-up the port pins), and removal of the existing pull-up resistors. And, of course, re-programming the AVR microcontroller with v2 firmware (requiring a UPDI programmer).
When using the v2 keyboard with my 386 PC, I’m seeing an initial Host "Reset" command (0xFF) from the BIOS, which I respond with an Acknowledge (0xFA), followed by a BAT Success (0xAA).
Later, I get a Host "Read ID" command (0xF2), which I correctly respond to with an Acknowledge (0xFA), followed by the correct Device ID of (0xAB) and (0x83).
Finally, the PC Host sends the "Set LEDs" command (0xED), which the keyboard responds with Acknowledge (0xFA), and then receives Num-Lock only ON (0x02), which I respond to with a final Acknowledge (0xFA).
Since I have no LED’s on the Keyboard (no Num-Lock, Scroll Lock or Caps Lock keys), I don’t of course have a Num-Lock LED to turn on!
Finally, I re-tested the Keyboard with the CreatiVision Controller, and all still works (as expected), with the original unidirectional CreatiVision Controller PS/2 Host.
So, I’ve just got to update the Github project repository with the v2.0 code, and also update my Tindie Store listing (once the new PCB’s arrive).
Then, back to my project backlog!
After digging out an old 386 PC with a PS/2 keyboard port, a lot of analysis, testing, and code optimisation, I’m now finally happy with my full-blown bi-directional PS/2 keyboard.
It’s been a fun project, and a great PS/2 protocol implementation detail “learning experience”. So, thank you to David, for prompting me with this interesting challenge!
I’m just about to “sleep on” my final PCB changes, before submitting a v2.0 PCB for manufacture.
The PCB changes just involve removing the redundant pull-up resistors (as we now have internal pull-ups), and routing Port C0 & C1 of the AVR as the new PS/2 port input sense lines.
To use the new v2.0 firmware with an existing v1.x PCB, will just require a couple of jumper wires (to hook-up the port pins), and removal of the existing pull-up resistors. And, of course, re-programming the AVR microcontroller with v2 firmware (requiring a UPDI programmer).
When using the v2 keyboard with my 386 PC, I’m seeing an initial Host "Reset" command (0xFF) from the BIOS, which I respond with an Acknowledge (0xFA), followed by a BAT Success (0xAA).
Later, I get a Host "Read ID" command (0xF2), which I correctly respond to with an Acknowledge (0xFA), followed by the correct Device ID of (0xAB) and (0x83).
Finally, the PC Host sends the "Set LEDs" command (0xED), which the keyboard responds with Acknowledge (0xFA), and then receives Num-Lock only ON (0x02), which I respond to with a final Acknowledge (0xFA).
Since I have no LED’s on the Keyboard (no Num-Lock, Scroll Lock or Caps Lock keys), I don’t of course have a Num-Lock LED to turn on!
Finally, I re-tested the Keyboard with the CreatiVision Controller, and all still works (as expected), with the original unidirectional CreatiVision Controller PS/2 Host.
So, I’ve just got to update the Github project repository with the v2.0 code, and also update my Tindie Store listing (once the new PCB’s arrive).
Then, back to my project backlog!
Re: CreatiVision Console re-Creation
Further to my post above…
Note, that I said I was going to “sleep on” my v2.0 PCB changes, before ordering!
Well, this is because, without a doubt, I always wake up the next morning with some changes I want to make.
I've learnt that you can pass something over to your subconcious to work on, while you're asleep, and you'll often wake up knowing exactly what you should do next.
So, after last night's sleep, I awoke with the clear thought of just getting rid of the open-drain MOSFETs as well, and just using the AVR's port controls to simulate an open-collector PS/2 interface.
This all works amazingly well in testing, and also resolves the last compatibility niggle I had. This was with some inconsistent reliability with my F256K2 retro computer's modern PS/2 interface, even though it was working 100% reliably with my 386 PC PS/2 port.
For some reason the F256K2 wasn't happy with the clean MOSFET based open-drain PS/2 line drivers.
Now it works faultlessly!
So, I've now progressed to v3.0 firmware and v3.0 PCB design.
Today, I'll finalise the changes for my v3.0 PCB, and, you guessed it, I'll "sleep on it" tonight, and order the new v3.0 PCB's tomorrow.
I'm pretty confident I'll then be fully done (and 100% happy), with my CreatiVision inspired PS/2 Keyboard design!
Note, that I said I was going to “sleep on” my v2.0 PCB changes, before ordering!
Well, this is because, without a doubt, I always wake up the next morning with some changes I want to make.
I've learnt that you can pass something over to your subconcious to work on, while you're asleep, and you'll often wake up knowing exactly what you should do next.
So, after last night's sleep, I awoke with the clear thought of just getting rid of the open-drain MOSFETs as well, and just using the AVR's port controls to simulate an open-collector PS/2 interface.
This all works amazingly well in testing, and also resolves the last compatibility niggle I had. This was with some inconsistent reliability with my F256K2 retro computer's modern PS/2 interface, even though it was working 100% reliably with my 386 PC PS/2 port.
For some reason the F256K2 wasn't happy with the clean MOSFET based open-drain PS/2 line drivers.
Now it works faultlessly!
So, I've now progressed to v3.0 firmware and v3.0 PCB design.
Today, I'll finalise the changes for my v3.0 PCB, and, you guessed it, I'll "sleep on it" tonight, and order the new v3.0 PCB's tomorrow.
I'm pretty confident I'll then be fully done (and 100% happy), with my CreatiVision inspired PS/2 Keyboard design!
Re: CreatiVision Console re-Creation
That's good to know Greg, I need to find a programmer for the AVR32EA28 not sure if I have anything suitable. would usb-asp or J-Link work I wonder?
I'm struggling with getting the IDE to create a suitable project atm, it needs the appropriate DFP installing before it can continue and the loader freezes.
Best regards, David
I'm struggling with getting the IDE to create a suitable project atm, it needs the appropriate DFP installing before it can continue and the loader freezes.
Best regards, David
Re: CreatiVision Console re-Creation
All I can advise is that I've been through a few progammers, and in the end I got an official Mcrochip PICkit5, which I now highly recommend!
If I'd just bought that first, I would have saved a lot of money on various 3rd party alternatives.
It's not the cheapest, but certainly a lot cheaper than the previous PICkit4! It also "just works", and is compatible with both AVR and PIC microcontrollers. Whatever you end up using MPLAB X to program.
e.g. This: PICkit5
I'm guessing you're referring to MPLAB X IDE? I'm currently using v6.20 under Windows 10. All problem free.
I imagine the best path for you would be to get to the point where you can re-program the existing AVR chip (via the UPDI header), then you'll be ready to program the v3.0 code.
In terms of your PCB, the upgrade has turned out to be even easier. No PC0/PC1 jumpers required!
In fact all you have to do is snip out the 2x Resistors and the 2x 2N7000 MOSFETs, and link the both MOSFET pads closest to the PCB edge (so PF0/PF1 AVR pins just connect directly to the PS/2 header).
Hopefully I'll get around to making a video for the CreatiVision Keyboard v3 upgrade soon. I think making my next video should be next on my agenda!
Re: CreatiVision Console re-Creation
Just thought I'd mention that I just did a clean install (new directories) of the updated MPLAB X IDE v6.25 and XC8 v3.00 on my Windows 10 system, and all installed and operates without problem. I've also updated my project to now use the latest AVR pack (2.11.221), and XC8 v3.00, and compilation / testing was successful.
Re: CreatiVision Console re-Creation
Thanks, I think I made a bad decision with the installation option choices, I'll try again with a full install next time. I'm using Linux Mint, if all else fails I'll try WIndows 10.