1200xl keyboard question

[yorgle]

ME WANT!!! I'm afraid I can't be of much help as far as coding, but if you need any testing done, I've got a pile of 1200xl's sitting here.

[+mytek]

ME WANT!!! I'm afraid I can't be of much help as far as coding, but if you need any testing done, I've got a pile of 1200xl's sitting here.

 

I think this will be a fun project

 

And on the surface it looks a lot easier than what the TK-II was originally intended to do, and can likely benefit from some of the subroutines already written to interpret the Pokey's count vs. a key press. So instead of pulling the key response lines low when a certain count matches a key I wish to send to the Atari via Pokey, I'll be looking for a key response line to go low instead (key pressed on 1200XL keyboard) and then see what the count is. The count value can then be used as an index for a 'Look Up Table' (LUT) to give me a matching PS2 key, which I can then send to the PC via my PS2 Send Routine (originally used to manipulate the PS2 keyboard's status LEDs). Of course there is a bit more to it than that, but that's the essence of it.

 

Already got a 1200XL (as well as several other compatible systems). And it already has a TK-II-PiggyBack board installed. Just need to find the time to start re-coding and testing.

 

- Michael

 

EDIT: Just to be clear, this idea will work with all A8's, not just the 1200XL. Thus turning them into PS2 keyboards.

Edited October 6, 2016 by mytekcontrols

[yorgle]

Well, I tested my switching circuit today and I think it's going to work. I've verified that using the 4053 to trip the keyboard 4051s into inhibit mode, eliminates interference with the PC encoder. Now I need to figure out a clean way to connect the circuit into the four GTIA lines. For testing, I just bent the four pins upward slightly so they don't slide into the connector and temporarily soldered my leads directly to the pins. The wires from the other side of the switch are just pushed into the Leyboard connector.

[yorgle]

Ok, not so fast... it seems I've got an issue with my circuit that only affects the GTIA lines (Reset, Start, Select and Option). In order to pull the inhibit pins on the 4051's high, the keyboard has to share a ground with the ps/2 encoder. While that doesn't bother the encoder as far as matrixed inputs are concerned, apparently the encoder can't deal with the shared ground as input. I think the only way to address that would be to physically break the traces on the keyboard PCB so they can be switched on/off or otherwise isolated. I hate to lose 4 keys, but I really don't want to get into that much physical modification. The TransKey solution is looking better and better.

[+mytek]

Ok, not so fast... it seems I've got an issue with my circuit that only affects the GTIA lines (Reset, Start, Select and Option). In order to pull the inhibit pins on the 4051's high, the keyboard has to share a ground with the ps/2 encoder. While that doesn't bother the encoder as far as matrixed inputs are concerned, apparently the encoder can't deal with the shared ground as input. I think the only way to address that would be to physically break the traces on the keyboard PCB so they can be switched on/off or otherwise isolated. I hate to lose 4 keys, but I really don't want to get into that much physical modification. The TransKey solution is looking better and better.

 

Speaking of which, just as you have seen the complexity grow in what you are trying to handle from a hardware aspect, I too have seen my project getting more involved. Basically I need to implement in software what Pokey does in hardware. So this means creating a synchronized key scan/de-bounce routine. So to make this happen, I have implemented this as a State Machine using the 'Switch' function of FlowCode, which is very similar to the 'Case' structure in other languages.

 

KEYscan State Machine Diagram (Main Routine that is in constant play --- called within endless loop)

 

Macros (FlowCode Sub-Routines) utilized by KEYscan routine.

 

NEWscan Macro KEYconvert Macro --- LUT implemented in 'C' Block to convert from Atari KeyCode to PS2 Key

 

 

So far I am getting somewhat erratic operation, but I am hopeful that this approach will eventually work

 

 

BTW, Here is what the Atari scanned key matrix circuit looks like

 

 

 

- Michael

Edited October 14, 2016 by mytekcontrols

[yorgle]

Michael- thank you SO MUCH for posting your thought process on this project.

[+mytek]

Michael- thank you SO MUCH for posting your thought process on this project.

 

You are very welcome

 

This is just part of my thinking out loud process, and I also put it out there in case someone sees something that I missed. As for the problems you are seeing with electrical conflicts between the two systems (PC and Atari), I found that running my circuit from the +5V supplied via the PS/2 cable, and only having a common ground seems to work fine. Although I would imagine an even safer bet for my approach would be to incorporate opto-isolators for the PS/2 clock and data lines, since the PS/2 interface is meant to work with open-collector (tri-stated) devices anyway. That way neither +5V or ground need to be shared between systems.

 

- Michael

[yorgle]

After messing with my circuit further, I realized that the Hagstrom encoder is the problem, not the shared ground. The firmware can't recognize a ground as an input so I'm dead in the water. I'm going to contact Hagstrom to see if there's a way to reprogram it to get around this limitation. Again, this only affects the four GTIA keys so it's not really that big of a deal except that it would be nice to have the extra functions.

[+mytek]

So what was your thinking on mapping those keys to the PC. Or in other words what will Start, Select, Option, Reset, and Help do on the PC end of things? And I presume that the 1200XL's F1-F4 will simply be the PC's F1-F4. And how did you plan on supporting the PC's F5-F12 keys? All of this is pertinent to what I am attempting to do as well, so any help in specifying this stuff will be helpful

 

- Michael

[yorgle]

Obviously, using the Atari keyboard means giving up a lot of key functions. 99% of my use is creating/editing documents so I don't really need that many keys. I have an Atari numerical keypad to help out. Right now, I have the F1-F4 keys mapped to cursor duty just like stock. The BREAK key is my close window key. The Inverse key is ALT and Help is Line end. Before adding on my switching circuit, RESET was mapped to ctl-alt-del, START pulled up the Windows start menu, OPTION was the Windows key and SELECT was select-all.

[+mytek]

I like the F1-F4 assigned to cursor moves, but since I'll be trying to make something that will also work on other models besides the 1200, perhaps I'll also have the CTRL+Arrows work for this as well (makes sense, same as what the A8 expects). Also your other key assignments look good as well, so I'll probably mimic those. Trying to provide a means to re-map the keys would be tricky, but likely doable at some point. Although I'll be satisfied just to get the basic functionality for now, and then worry about that other stuff for a future firmware revision.

 

I had to re-work my KEYscan routine, since the the original just wasn't doing it. It was originally based on the flowchart specs given in the Pokey datasheet, but what worked in hardware wasn't panning out for me in software. Also I do believe there are some major mistakes on that flowchart relating to the decision blocks for the KR1 line. Anyway I took a new direction and came up with this, which works well, but still needs a non-repeat timer that will allow one and only one key to be sent unless the timer times out (key being held down). Next I'll need to tackle SHIFT, CTRL, and Break which luckily don't need to be de-bounced.

 

 

The SCANcnt macro is very flexible, controlled by parameters passed to it when called. So for instance if I pass it a '1' for ScanNumber and a '1' for LoopEnable it'll produce a wait state for exactly one entire key scan period (clock out all 64 keys in the matrix) starting from wherever the Pokey counter is presently at. If on the other hand I wish to do something while waiting, I can set the LoopEnable to '0' and then create an external loop, placing whatever actions I wish to do inside this loop (SCANcnt will flag completion by bringing SCANdone from '0' to '1' which is used to terminate the external loop). So by changing the ScanNumber parameter, I can wait for however many key scan periods I wish. BTW a full keyboard scan takes approximately 1 millisecond.

 

- Michael

Edited October 15, 2016 by mytekcontrols

[yorgle]

Key mapping is not too critical because it can always be rearranged with software at the PC side.

[+mytek]

Key mapping is not too critical because it can always be rearranged with software at the PC side.

Sounds like a plan.

 

BTW, on that last State Machine diagram I was missing a 'state=0' equate under the KR1=0 'NO' decision in State 1. So the basic idea is to first detect a key in State 0, wait for 5 milliseconds, jump to State 1 where one keyboard scan period is allowed to confirm the key, and if not go back to State 0, else if true move on to State 2 and send it.

 

- Michael

[yorgle]

For the F1-F4 keys, how about using the inverse key with the number keys to simulate the PC function keys, e.g., Inv+1=F1, Inv+2=F2, and so on. That would give you at least the first ten. Then maybe Inv+ the AtariF1, F2, etc. would give you the PC version of F11-F14.

[+mytek]

For the F1-F4 keys, how about using the inverse key with the number keys to simulate the PC function keys, e.g., Inv+1=F1, Inv+2=F2, and so on. That would give you at least the first ten. Then maybe Inv+ the AtariF1, F2, etc. would give you the PC version of F11-F14.

 

I like it

 

- Michael

[yorgle]

Ok, I give up. With the 4051s inhibited, (triggered by power from the ps/2 connector) the encoder works as it should, but the shared ground that is needed to switch the inhibit pins from high to low and vice versa apparently prevents the keyboard from working with the Atari. The Trans-key II option is looking better and better.