TransKey-II in development

[+mytek]

A little history first...

 

In 1990 I created the TransKey Board, an IBM keyboard to Atari interface via POKEY/GTIA connection. Having never used an actual IBM PC, I made some presumptions about how things like Num Lock and Caps Lock were integrated in the PC environment. Well as it turns out, I got a few things wrong in my interpretation. In order to get the interpretation better, the original Transkey went through several firmware iterations finally ending at Version 2.4. Getting ever closer to how things worked on a PC, but not quite all the way there. And then life stepped in, and unfortunately I had to get a 'real' job, and time for Transkey was no more. It was at this point that Chuck Steinman of Dataque proposed that I sell him the rights to TransKey, and thus let him take over the reins of manufacturing and marketing of this product. I agreed and the rest of what happened is probably well known to all of you.

 

So here it is 2015 (25 years later), and although alternative products have been created (AKI and KRH) to do what TransKey was about, they along with the original TransKey are now difficult to find, and/or manufactured only when enough pre-orders have materialized (if ever). And I'm not saying that I will necessarily change that situation, but I figure having another variation of this product in the public domain certainly shouldn't hurt, and might possibly even help by reinvigorating the community around this product. Anyway with that said, it is my intention to create yet another keyboard interface board for your beloved Atari's. And then to share all the manufacturing data required in order to produce it. This will be a simple hardware design, utilizing only 1 integrated circuit, no crystal (internal oscillator) or external EEPROM (internal also), and no diodes. Could be easily bread boarded, although I will upload the PCB file(s) for a more professional version.

 

 

So what will it be ?

 

This go around I've decided to make it act more like an IBM keyboard was meant to be, while still providing all the key combinations that Atari 8 programs expect to be there. So this means that if I am in Caps Lock, when I press SHIFT and another alpha key, I should get the lower-case equivalent of that key. Letting go of SHIFT will once again render upper-case characters. And of course when not in Caps Lock, the opposite of this will be true. Num Lock mode will render 'numbers' when pressing a key in the Num Pad, and while still in Num Lock, pressing SHIFT will cause the keys to switch to their navigation equivalents. Of course when not in Num Lock mode the opposite of this will be true. Meanwhile the navigation section of the keyboard will be unaffected by Num Lock, and yield navigation actions only. Of course all the CONTROL, SHIFT, and CONTROL+SHIFT combinations will be represented, along with some CONTROL+SHIFT ones that never were before.

 

And now for something really cool. If you've ever used a PC to edit text, then you can probably appreciate the fact that as you enter new text it automatically inserts space, pushing the existing text to the right. And vice versa, when you backspace in the middle of a line of text, the text to the right of where you are backspacing is pulled left automatically filling in the space left by the deleted character. Well although the Atari 8 doesn't inherently support this method of editing, the new TransKey-II design will.

 

And there is more... There will be 4 supported macro keys, each able to store up to 63 keys in a non-volatile internal EEPROM. And if all goes well, there will also be mouse support, mimicking the actions of the Control-Arrow keys.

 

Link to Document Listing all Special Keys

 

Finally since all of what has been described is done strictly through the hardware interface with POKEY (and Start, Select, Option thru GTIA), there is no need or requirement to have any software drivers.

 

 

Two models planned

 

Transkey-II will be an internal version similar to what has been done in the past, having a POKEY piggy-back socket to acquire the necessary signals.

 

TransKey-II-XEGS will be external, plugging into the provided keyboard port on the XE Game System.

 

Both models will support PS/2 keyboards and mice.

 

 

Project Status

 

Keyboard code 99% completed.

 

Mouse support is next, looking at approximately 3-4 weeks to write the code, integrate it with the keyboard code, and fully debug.

 

PCB layout to follow successful mouse implementation.

 

Stay tuned for more info...

 

----

Michael

Edited July 19, 2015 by mytekcontrols

[+Larry]

Would it be possible to use the Atari keyboard and the TK-II mouse feature (rather than the PC keyboard + Mouse)?

 

-Larry

[+mytek]

Would it be possible to use the Atari keyboard and the TK-II mouse feature (rather than the PC keyboard + Mouse)?

 

-Larry

 

Hi Larry,

 

If I understand you correctly, yes the mouse will work in a stand-alone mode (actually either the keyboard or the mouse can be used as the only PS/2 device).

[morelenmir]

A little history first...

 

In 1990 I created the TransKey Board, an IBM keyboard to Atari interface via POKEY/GTIA connection. Having never used an actual IBM PC, I made some presumptions about how things like Num Lock and Caps Lock were integrated in the PC environment. Well as it turns out, I got a few things wrong in my interpretation. In order to get the interpretation better, the original Transkey went through several firmware iterations finally ending at Version 2.4. Getting ever closer to how things worked on a PC, but not quite all the way there. And then life stepped in, and unfortunately I had to get a 'real' job, and time for Transkey was no more. It was at this point that Chuck Steinman of Dataque proposed that I sell him the rights to TransKey, and thus let him take over the reins of manufacturing and marketing of this product. I agreed and the rest of what happened is probably well known to all of you.

 

So here it is 2015 (25 years later), and although alternative products have been created (AKI and KRH) to do what TransKey was about, they along with the original TransKey are now difficult to find, and/or manufactured only when enough pre-orders have materialized (if ever). And I'm not saying that I will necessarily change that situation, but I figure having another variation of this product in the public domain certainly shouldn't hurt, and might possibly even help by reinvigorating the community around this product. Anyway with that said, it is my intention to create yet another keyboard interface board for your beloved Atari's. And then to share all the manufacturing data required in order to produce it. This will be a simple hardware design, utilizing only 1 integrated circuit, no crystal (internal oscillator) or external EEPROM (internal also), and no diodes. Could be easily bread boarded, although I will upload the PCB file(s) for a more professional version.

 

 

So what will it be ?

 

This go around I've decided to make it act more like an IBM keyboard was meant to be, while still providing all the key combinations that Atari 8 programs expect to be there. So this means that if I am in Caps Lock, when I press SHIFT and another alpha key, I should get the lower-case equivalent of that key. Letting go of SHIFT will once again render upper-case characters. And of course when not in Caps Lock, the opposite of this will be true. Num Lock mode will render 'numbers' when pressing a key in the Num Pad, and while still in Num Lock, pressing SHIFT will cause the keys to switch to their navigation equivalents. Of course when not in Num Lock mode the opposite of this will be true. Meanwhile the navigation section of the keyboard will be unaffected by Num Lock, and yield navigation actions only. Of course all the CONTROL, SHIFT, and CONTROL+SHIFT combinations will be represented, along with some CONTROL+SHIFT ones that never were before.

 

And now for something really cool. If you've ever used a PC to edit text, then you can probably appreciate the fact that as you enter new text it automatically inserts space, pushing the existing text to the right. And vice versa, when you backspace in the middle of a line of text, the text to the right of where you are backspacing is pulled left automatically filling in the space left by the deleted character. Well although the Atari 8 doesn't inherently support this method of editing, the new TransKey-II design will.

 

And there is more... There will be 4 supported macro keys, each able to store up to 63 keys in a non-volatile internal EEPROM. And if all goes well, there will also be mouse support, mimicking the actions of the Control-Arrow keys.

 

Link to Document Listing all Special Keys

 

Finally since all of what has been described is done strictly through the hardware interface with POKEY (and Start, Select, Option thru GTIA), there is no need or requirement to have any software drivers.

 

 

Two models planned

 

Transkey-II will be an internal version similar to what has been done in the past, having a POKEY piggy-back socket to acquire the necessary signals.

 

TransKey-II-XEGS will be external, plugging into the provided keyboard port on the XE Game System.

 

Both models will support PS/2 keyboards and mice.

 

 

Project Status

 

Keyboard code 99% completed.

 

Mouse support is next, looking at approximately 3-4 weeks to write the code, integrate it with the keyboard code, and fully debug.

 

PCB layout to follow successful mouse implementation.

 

Stay tuned for more info...

 

----

Michael

 

This sounds like an amazing project and I look forward to see its future progress. Funds allowing, I think this will have to figure on my must-have list. Could I ask how it will interact with the various dual-pokey stereo mods?

[+mytek]

 

This sounds like an amazing project and I look forward to see its future progress. Funds allowing, I think this will have to figure on my must-have list. Could I ask how it will interact with the various dual-pokey stereo mods?

 

I have been researching the various mods that affect POKEY's availability, including the ones you mentioned. And although I can't guarantee that there wont be problems, I will try my best to design the board layout to work with as much stuff as possible. Obviously some concessions might need to be made, such as elevating one mod over the other by the use of an additional machine pin socket. Not ideal, especially when wishing to retain the metal shielding, but there are only so many ways to do this.

 

- Michael

[+David_P]

I think I speak for many here when I say

 

[+mytek]

Good one David

 

But I'm kinda hoping that once the design is finished, that someone else would grab onto it. And then they could take your money

 

When I've completed the design, it should be a cinch for someone else in the biz to add it too their manufacturing/product capabilities.

 

The thing is my day job pays me very well, so I don't personally need the extra cash (just don't tell my wife that), and not that the assembly would be all that difficult, but the hassle of boxing and shipping I'm just not interested in doing anymore.

 

- Michael

Edited July 20, 2015 by mytekcontrols

[lemiel]

Can it be installed not only as piggy-back socket? I am not sure about its high. It will be third piggy-back at some computers. First SIO2FIFO, second Stereo...

[Bill Loguidice]

Very cool. An external XEGS option would be fantastic.

[+mytek]

Can it be installed not only as piggy-back socket? I am not sure about its high. It will be third piggy-back at some computers. First SIO2FIFO, second Stereo...

 

Hi lemiel,

 

Unlike the original TransKey which consisted of two boards (piggy-back adapter was separately connected to main board), TransKey-II will be taking the simpler approach, and be more like the AKI/KRH board. So although the original TransKey was offered in a non-piggy-back version, thus requiring soldering to the POKEY or a place on the motherboard where the signals could be picked up. The new Transkey-II is aimed at easy removal and the least amount of possible harm to the computer. However with that said, there is no reason that the piggy-back socket couldn't be left off, and then have soldered connections between where it was over to the POKEY, thereby allowing placement where ever it could be squeezed in.

 

On the plus side, the board will be very small, since there are very few components required (basically it's down to only one chip, and some connectors).

[+mytek]

Very cool. An external XEGS option would be fantastic.

 

Hi Bill,

 

Yep that's what I thought as well

 

However in order to be able to have Start, Select, Option, Reset from the keyboard, it will require some jumpers be soldered internally to the D-SUB 15 connector. Minimally at least the reset capability should be added in this way, which is a very simple short distance jump. But it is not an absolute requirement, more for ease of use, since this key does tend to enter the picture often when developing code.

 

It really is too bad that these signals weren't routed out to the keyboard in the first place, since there were enough unused pins to allow for it, and the console switches do exist on the XEGS's keyboard (just no buttons). This also assumes that only one pin would have been dedicated to GND and another for +5VDC, unlike the doubling up that was done (kind of stupid considering that only two low power CMOS chips are used in the XEGS keyboard). This of course makes it more difficult to use these pins for other things, since the D-SUB 15 connector would need to be fully removed (desoldered) in order to cut the power trace connection on the top side of the motherboard. But like I said it is not a requirement that the extra signals be implemented for TransKey-II in order to work.

 

XEGS Keyboard Connector Pinout

 

Edit: Just to be clear, the TransKey-II-XEGS model will already have the connections for Start, Select, Option, Reset routed to its D-SUB 15 connector, two of which will be via on board limiting resistors, in case the XEGS has not been modified and the +5VDC and GND connections are still intact. Don't want to blow out the TransKey-II's I/O, if plugged into a friends unmodified XEGS.

Edited July 20, 2015 by mytekcontrols

[+mytek]

Now that I have the main keyboard code running and reliable, and including the special features already mentioned, I think it's time to collect some user input. For starters, would there be any interest in having dedicated hard coded macros such as 'RUN', or 'LIST', ect. ? If so I was thinking these could best be served by using the ALT key in combination with the first letter of the macro (i.e; ALT-R for 'RUN'). This makes it much easier to remember, as compared to a function key assignment.

 

So if this seems like a good idea, I would like to make a list of the most useful hard coded macros that could be included. Keep in mind the criteria of using the first letter combined with ALT. Lets hear a yay (yes) or nay (no) on doing this, and if it's a yay, suggestions on macros (these should be mainstream, as in most popular program commands).

 

BTW; the originally planned reconfigurable macros assigned to F9-F12 will still be included.

 

Thanks

 

-Michael

[+bob1200xl]

By hard coded, you mean burned into the code - not configurable? Can we re-program the chip easily or are we going to have to re-compile or whatever? Be nice to be able to edit the binary somehow.

 

Can we do mouse macros? (faster, slower, blink, etc...)

 

Bob

[Bumzyman]

Good one David

 

But I'm kinda hoping that once the design is finished, that someone else would grab onto it. And then they could take your money

 

When I've completed the design, it should be a cinch for someone else in the biz to add it too their manufacturing/product capabilities.

 

The thing is my day job pays me very well, so I don't personally need the extra cash (just don't tell my wife that), and not that the assembly would be all that difficult, but the hassle of boxing and shipping I'm just not interested in doing anymore.

 

- Michael

 

How about putting the design up on OSH Park or something similar so anyone interested can just order up a couple bare boards.

[+mytek]

 

How about putting the design up on OSH Park or something similar so anyone interested can just order up a couple bare boards.

 

Bumzy that sounds like a great idea !

 

First time I heard about something like this, but it does seem like the appropriate place to do what you are suggesting. Thank you.

 

-Michael

[+mytek]

By hard coded, you mean burned into the code - not configurable? Can we re-program the chip easily or are we going to have to re-compile or whatever? Be nice to be able to edit the binary somehow.

 

Can we do mouse macros? (faster, slower, blink, etc...)

 

Bob

 

Hi Bob,

 

Yes you are correct, these extra macros would be non-configurable in the normal sense, although they could be altered when programming (burning) the processor chip. That is why I suggested that they be commonly used commands by a fair percentage of people, like the two that I suggested thus far. Think of this as extra fluff, or thrown in for the heck of it, but something that could also be useful as well. Adding these extra macros is easy peasy at this point, and simply utilizes an existing routine in the code that translates and sends ASCII strings to POKEY, although I do need to modify it slightly to automatically accommodate different string lengths. So theoretically a search & replace could be done in the code, prior to burning (be cheaper than having to purchase the code development software I use).

 

BTW; The processor chip for this project will be a Microchip PIC16F88 (18 pin DIP), and the programming environment is FlowCode Version 4. I believe the trial software is fully functional for 15 days or so.

 

Now getting back to the topic of adding hard coded macros. I just had the idea of being able to add this feature on the cheap so to speak, and at least for the moment, don't want this to get too complicated or involved. Maybe later down the road I can revisit this and depending upon how people feel, maybe have these share the EEPROM allocation and let them be writable just like F9-F12 currently are.

 

As for mouse macros, nothing planned for now, kinda waiting to see how this really works in reality, and then take it from there. Although I'm still trying to figure out what you meant by 'blink' ?

[Kyle22]

Will Flowcode v5.4 work? If so, a full version is available as a torrent from "The usual Places", and I don't mean eBay.

[+mytek]

Will Flowcode v5.4 work? If so, a full version is available as a torrent from "The usual Places", and I don't mean eBay.

 

Hi Kyle, yes it should work fine. New versions tend to be able to read in older version files, but when saved as the new version will not be backwards compatible. Just be careful when getting software from those alternative ebay places, since often times the key generators can cause down stream system problems if you know what I mean. The fact that I'm still at version 4.5 tells you I got mine from the real deal, but can no longer justify the upgrade fee for what has been added. I started out with V3 and then upgraded that to V4 which had numerous improvements in the actual flow code and simulation aspects, as well as some very useful new components. But from V5-V6 they launched into this 3D simulator stuff, which for some folks might be very useful, but for me not.

 

Flowcode makes coding PICs, Atmel, or ARM's very easy, and also gives you a simple way to cross compile between these processor platforms. I always thought it might be cool to create something similar to this for the Atari 8, treating it like an embedded processor having digital I/O (joy stick ports), serial communications (SIO), and ADC (paddles). Could likely be done in graphics 8 mode, and a mouse would certainly help (hint,hint).

 

As an example, here is actual code from the TransKey-II project. It is what FlowCode calls a Macro, which is actually a compartmentalized chunk of code that can be called as a subroutine, or branched to by the main program loop. So basically when the code starts getting too big to easily see on screen (requiring excessive scrolling), cut it out, give it a sensible name, and make it into a Macro. This particular Macro is responsible for monitoring and synchronizing with POKEY, and then when appropriate, signal either a standard key send match (via KR1) or a Shift, Control, Break (via KR2). There is a lot going on in the decision and calculation boxes that can't be fully seen unless you double click on it (in FlowCode).

 

A little more background as to what this routine is doing,,,

 

Prior to entering this routine, an ASCII equivalent to the keyboard scan code has been translated to what I call POKEcode, basically this is the raw key matrix value for a given Atari key as scanned by POKEY. This is a 6-bit code. Then the Shift and Control status is encoded into the upper two bits of the POKEcode byte, with bit-6 = Control and Bit-7 = Shift. So now we have all the information required in the POKEcode byte to send out the proper keystroke(s) that will create the character on screen. So if we make POKEen = 1 and call this routine, a timed key send will be made. Keep in mind that this routine is called by an idle loop, and that the processing of the keyboard including; translation first to ASCII and then to POKEcode, encoding of Control and Shift, and the decision to send is all based on a key being pressed on the IBM keyboard. Once we are fully executing this routine (POKEen = 1), the 6-bit key is masked out of the POKEcode byte for sending, and the Control and Shift bits will be decoded into what POKEY needs to see in order to acknowledge these particular modifier keys and also sent. Break gets handled separately, and is not incorporated into the POKEcode byte.

 

Hopefully I haven't bored everyone to death with all the technical details

 

Oh and here is the POKEY Key Code Document referred to.

 

 

-Michael

 

Edit: To be a bit more clear; the PokeySend routine is part of an idle loop, always being passed through, with the only exception being a keyboard interrupt occurring, which would temporarily bypass this routine (leaving and then returning to the idle loop when the interrupt has been serviced). Only if POKEen = 1 will the sending part of this routine be accessed.

Edited July 22, 2015 by mytekcontrols

[+mytek]

FlowCode Stuff

 

Here is a more in depth look at the code responsible for telling POKEY that a modifier key such as Control, Shift, or Break has been pressed (I edited some of the comments and also added more detailed explanation text in red).

 

 

-Michael

Edited July 22, 2015 by mytekcontrols

[+mytek]

TransKey-II-XEGS Schematic

 

R1 and R2 are for current limiting purposes only. They protect the microcontroller I/O pins from excessive current draw in the event that this is used on an un-modified XEGS (not having START, SELECT, OPTION, RESET properly connected internally). They limit current to 15 ma, which is within the 25 ma capability of the I/O. This is only required on 2 of the 4 I/O pins, since the other 2 are going to what are normally unconnected pins on the D-SUB keyboard connector.

 

EDIT: There will be a second version (TransKey-II) documented very soon, which is for all the other Atari 8 computers.

Edited July 23, 2015 by mytekcontrols

[Fuji-Man]

Hi,

 

Nice to see this happening. I will definitely build a few when the PCB is available.

I have a TransKey in my 800 and I love it.

Mylars are probably getting hard to find, and I have a few machine in desperate need...

 

FujiMan

[+mytek]

Hi,

 

Nice to see this happening. I will definitely build a few when the PCB is available.

I have a TransKey in my 800 and I love it.

Mylars are probably getting hard to find, and I have a few machine in desperate need...

 

FujiMan

 

Hi Fuji,

 

I'm glad that you like your original TransKey, and that it is still working after all these years. As you might have already noticed this new version isn't going to support macros in nearly the same way or give you as many user programmable ones, but it'll have some extra features to make up for that.

[+mytek]

TransKey-II Schematic

 

This is the non-XEGS one, suitable for all the other Atari 8 computers.

 

J1 will accept a dual PS/2 harness having panel mounted connectors with a short pigtail. I found a good source for the panel mount connectors, which also come with full-height brackets for mounting into a standard PC case. details on this will be coming.

 

-Michael

Edited July 24, 2015 by mytekcontrols

[+bob1200xl]

Not going to get much simpler than that, is it? Looks great!

 

Are you setting up some kind of archive for this?

 

Bob

[+mytek]

Are you setting up some kind of archive for this?

 

Bob

 

Did you have anything in mind?

 

I was thinking perhaps GitHub might be suitable, but I am certainly open to suggestions. Currently I have been putting the stuff I have shared in my Public folder in DropBox, which allows me to do easy updates of the information.