TransKey-II in development

[+mytek]

2 hours ago, flashjazzcat said:

Is it not possible to completely abstract TK-II key assignments from the core code by using an indirection table (i.e. the firmware acts on tokens derived from a look up on the translation table)?

That would have been nice if I had been better at organizing the code in that way, but unfortunately I never anticipated moving the base F-Key stuff, so its not exactly straight forward at this point. Also I have almost no program space left, so even if I wanted to, it could likely take a lot of refactoring to find enough space to change how things are done. If I did have the room, the best way to approach this would be to abstract it as you suggested and then have a non-volatile setting that could be used to select from the original F-key mapping over to a DarkAKI version. So a person that's used to it the way it is, has a choice.

 

For something I make no money from (and has been a drain financially speaking), I just can't see putting in the required work to change the fundamental F-Key arrangement at this time, or probably ever. Besides it works quite well the way it is and seems to be bug-free at V2.4, so why tempt fate .

 

[+MrFish]

On 8/16/2015 at 5:30 PM, mytek said:

As for making this work with a MegaST keyboard. I'm sure it's possible, just need to look at the actual situation, since I've never thought of doing that. Can you link me to a schematic?

A little late on my reply here.  

 

Here are some schematics for the 1040ST keyboard.

 

Not too hi-res, but sufficient, I think.

 

 

Edited April 30, 2020 by MrFish

[+mytek]

If you have SDrive-MAX and want it to work better with a PS/2 keyboard, I have modified the original sdrive.atr file that came with my SDrive-MAX so that it takes advantage of the special navigation keys present on a PC keyboard. I think anyone using a TK-II (or a 1088XEL/XLD) will find this much more intuitive in operation when navigating the file list.

 

I only modified the one SDRIVE.COM default file, and that's all that's in this ATR: sdrive.atr

 

Just replace (over write) the original, or rename it to sdrive.xxx if you wish to restore it later. And here are some instructions showing the new key assignments (based on original image from Mr. Robot's website).

 

 

 

Enjoy .

 

Warning: this will not work as well with a stock Atari keyboard, you will be required to hold down control with the up/down arrow keys, and will no longer have use of the left/right arrows or < > key actions.

 

Edit: PageUp and PageDn are more specifically going a page at a time through the list, and will get reflected in the page count in the upper left.

 

Edit: Information and download now also available at: https://ataribits.weebly.com/tk-ii-control.html

 

[cbelcher]

I just put a TK-II v2 into a 400 - did not hook up the console keys yet but in Memo Pad all I get is the 3 lights on the PS/2 Keyboard flashing every few seconds.  Any ideas on my error?  The keyboard works with the TK-II built into by 1088XEL

 

Thanks!

[+mytek]

You are seeing a watchdog timeout in the PIC chip, which then does a reset and re-initialization of the PS/2 keyboard. Usually this is the result of the PIC chip not seeing the Pokey counter. As to why that's happening, I'm not really sure without having your setup in front of me. Does the 400's stock keyboard work without the TK-II? Are you hearing the start-up sound when powering up with a Basic cart?

 

[Mr Robot]

On 12/18/2019 at 12:27 PM, mytek said:

Now that Lotharek has brought out the DarkAKI PS/2 Interface, should I rearrange the function keys on the TK-II to somewhat match?

 

It would be a lot of work, since it's just not firmware changes only, but also would create a considerable amount of document changes (i.e., TK-II Manual). And of course it introduces the possibility of creating new bugs in the code. Also keep in mind that the present code methodology was not meant to be rearranged easily, and has hooks for some of the other features associated with those keys that could get affected by the move (more potential bugs).

 

And of course anyone that has gotten used to the present layout, would have to relearn the new arrangement, although if they use emulation they would probably welcome that .

Did anything ever come of this thought process? Interested for 'reasons'

On 12/18/2019 at 12:36 PM, mytek said:

F1 as HELP for the Atari. And I believe this is the same on the ATARI800 emulator.

atari800 uses F1 as the main menu button, I don't know what it does on the win/mac ports.

Atari++ also uses F1 as the main menu button

xformer uses F1-F4 as 1200 function keys

as fjc said, Altirra F1 is turbo mode (but it can be remapped)

EclaireXL and Mist/Mister use the DarkAKI layout which according to this is the atari800win layout

 

[+mytek]

2 hours ago, Mr Robot said:

Did anything ever come of this thought process? Interested for 'reasons'

atari800 uses F1 as the main menu button, I don't know what it does on the win/mac ports.

Atari++ also uses F1 as the main menu button

xformer uses F1-F4 as 1200 function keys

as fjc said, Altirra F1 is turbo mode (but it can be remapped)

EclaireXL and Mist/Mister use the DarkAKI layout which according to this is the atari800win layout

 

Console key remapping is available on the latest TK firmware V2.5J through the use of CTRL+ALT+E toggling between what had been standard from the beginning to something more like the DARK AKI firmware in Lotharek's PS/2 Adapter.

 

I opted to stick with my decision to have F1 be the HELP key (same as Dark AKI), and still retained the now redundant F10 HELP key. I'm also used to F1 representing HELP in many Windows programs, so that made sense to me and likely influenced the creator of the Dark AKI firmware as well.

 

Because Altirra chose a different assignment for F1 wasn't a good enough reason for me to change it, or to move HELP to F6 to match it. My greater concern was to mimic what Lotharek's new keyboard adapter had these keys mapped to, since that is the alternative hardware adapter to my TK-II. And when it comes to emulators, there is absolutely no consistency between them in this regard, which is unfortunate (everyone did their own thing).

 

Since I mapped many of the 1200XL F1-F2 assignments to PS/2 key equivalents where it made sense (PageUp, PageDn, Home, End, arrows), support was dropped for a one-to-one F-key assignment. However wherever a 1200XL function wasn't reassigned, then SHIFT+ALT+F1-F4 will bring those to life (see the manual for more info about this).

 

 

Note: the upcoming 576NUC+ board will default to the new F1-F5 mapping and not provide a fall back to the original TK-II standard.

 

[cbelcher]

Found a bad wipe (or 2) in the POKEY socket on the 400 motherboard - new socket fixed it - thanks!

[_The Doctor__]

On 7/29/2020 at 8:20 PM, cbelcher said:

Found a bad wipe (or 2) in the POKEY socket on the 400 motherboard - new socket fixed it - thanks!

This is becoming more common these days,

One of the reason I still suggest pushing in slightly before pulling out...

clean the legs clean the swipes...

[+mytek]

There will be yet another firmware update coming for the TK-II that will be to correct another long standing, but unseen issue. I say unseen, because I just noticed the problem for the first time in a recent project I was working on, and have not seen any reports by existing TransKey users related to it (of course now that I bring it to light, those reports will probably be forthcoming).

 

Apparently when people including myself have been installing Transkeys into their systems, they rarely if ever go back to using the stock Atari keyboard afterwards. The reason I say this has to do with the fact that the stock keyboard's CTRL and SHIFT functions will become noticeably erratic, and the BREAK key will issue more then one key press when used. None of this affects the PS/2 keyboard, so if you no longer use the stock keyboard you will not have noticed the problem.

 

I discovered the line in the firmware's code that is responsible for this happening, and once corrected appears to solve the problem. However I'm not yet ready to issue an official update before doing a bit more testing, or before I've had a chance to reevaluate the need to have two different firmware builds being offered on my website. I would really like to either integrate them into only one package, or make a decision to leave the dual PS/2 keyboard version in the archives and move on without it. However no matter my decision, I will at least correct this latest bug in the dual PS/2 version firmware as well, even if it is decided to relegate it to the archives and lose future support.

 

Integration into one single firmware package is not an easy thing to do, since the amount of available program space in the PIC chip I use is down to a few free bytes. This is mainly the result of using a high level visual code development package which is unfortunately wasteful in some regards, thus creating bloated code when compiled. However it is not something I can simply change direction on at this point, since it would require starting all over again from scratch and rewriting the code in an entirely new way, not something I am willing to do.

 

I will make a future announcement when the new firmware is ready for download.

[+mytek]

NEW TK-II FIRMWARE UPLOADS ARE NOW AVAILABLE

 

The stock keyboard interference problem has been corrected in both the 'classic' and the newer 'universal' TK-II firmware. For the full details go HERE.

 

People with the following boards, upgrades, or systems do not need to update to this latest version...

TK-II-GS, TK-II-XEGS, 1088XEL, 1088XLD, ARROW2JOY-XLD, 576NUC+, or any system which is no longer utilizing the stock Atari keyboard.

[_The Doctor__]

can't hurt to upgrade them all, I tend to move upgrades around as things come and go. Thanks for the fix!

[RBlanche]

Hi, I know it’s an old topic. but I’m experimenting with the construction of the TK2.

 

I had it working for a moment, but after a few reboots the PS/2 Keyboard doesn’t work anymore. Is there an error code in the blinking lights ok the keyboard? I’m using last version 2.7J

 

(later i tested the KB in a PC and works OK)

[+mytek]

No error codes. When the keyboard's LEDs blink it's just indicating that a reset command was sent to it from the PIC16F1847 chip. So if you are still seeing that, then it means the PIC is still communicating with your keyboard. Since there's very little involved circuitry-wise, I would say check all your solder joints and connections. Otherwise it might be a marginal PIC that decided to bite the dust.

[wildstar87]

Mytek, I just built one of these, and am using a Pickit3 to program.  This is more of an issue with MPLab that I thought you might know the answer to.  I'm using the MPLab IPE to program, and it passes Programming/Verification step, but when I manually Verify, it always fails.  I did find this note, https://microchipdeveloper.com/faq:2334, however I don't see any settings to add a delay, I'm guessing this is part of the firmware code itself.  Any other way to fix this verify failure?  I've never seen this work ever, even in the lab I work in, where we use the programmers with more features and more expensive.  The checksums are the same between the hex file and what is read off the device, and it usually works, so I'm not too horribly worried, just wanted to know if you have a trick, or just don't worry about it, if it passes the Programming/Verify step.

[+mytek]

10 minutes ago, wildstar87 said:

Mytek, I just built one of these, and am using a Pickit3 to program.  This is more of an issue with MPLab that I thought you might know the answer to.  I'm using the MPLab IPE to program, and it passes Programming/Verification step, but when I manually Verify, it always fails.  I did find this note, https://microchipdeveloper.com/faq:2334, however I don't see any settings to add a delay, I'm guessing this is part of the firmware code itself.  Any other way to fix this verify failure?  I've never seen this work ever, even in the lab I work in, where we use the programmers with more features and more expensive.  The checksums are the same between the hex file and what is read off the device, and it usually works, so I'm not too horribly worried, just wanted to know if you have a trick, or just don't worry about it, if it passes the Programming/Verify step.

I also use the Microchip IPE Programming App with a PICkit2 when developing code, and if I recall correctly I think it too fails a manual verify. Never seems to affect the end result, and the chip works fine. Don't know what the deal is, but I guess if it works, no sense in trying to fix it.

 

For all of the PIC chips used in my projects I eventually create an Atari xex or atr file to program it via the JOY2PIC programming hardware, and then from that point forward use that with an A8 to flash the chips instead.

[wildstar87]

Yeah, I have programmed other TK-II chips for 1088XEL, and the 130XE Remake board, so I know it works, just wanted to see if you knew a way.  Thanks!

[wildstar87]

So I've run into a problem.  The function keys don't seem to work.  The main keys are fine, inverse works.  The F-EMU is TK-II.  Any ideas?

[+mytek]

3 hours ago, wildstar87 said:

So I've run into a problem.  The function keys don't seem to work.  The main keys are fine, inverse works.  The F-EMU is TK-II.  Any ideas?

If you want the function keys to be more like Altirra, then toggle it to AKI. The TKII selection was for legacy, as in how it was first defined in the very early days, but probably not very useful now days.

[wildstar87]

15 minutes ago, mytek said:

If you want the function keys to be more like Altirra, then toggle it to AKI. The TKII selection was for legacy, as in how it was first defined in the very early days, but probably not very useful now days.

I think RTFM is what I needed, I didn't notice the specific installation instructions, just the picture with wiring on the main TKII page.  I had assumed that the function keys would be picked up by the TKII directly, but it seems I missed the part that the Function keys actually have to be tapped into, in order for TK-II to control those.  Just doing the piggyback isn't enough, correct?  I have to run wires to those header locations for the function keys, and tap into traces on the motherboard.  The other two boards that I had these in, were designed with TKII in mind, so already have those in the layout.  This is the first time I put it in a stock motherboard.  The example pictures showing the install in the 1200XL threw me off, because I thought the function key header locations didn't seem to be used there, helps if I count pins, they are being used, it's the three pins that are part of the PIC programming pins that aren't connected.  Still appreciate the replies, even though it was my dumb ass mistake..

Edited June 1, 2023 by wildstar87
Another stupid mistake..

[+mytek]

11 hours ago, wildstar87 said:

I think RTFM is what I needed, I didn't notice the specific installation instructions, just the picture with wiring on the main TKII page.

Aww so what you were actually referring to were the Console keys: Start, Select, Option, and Reset. When you said Function keys I automatically assumed you were referring to the PS/2 keyboard's F1-F12 keys.

 

11 hours ago, wildstar87 said:

Just doing the piggyback isn't enough, correct?  I have to run wires to those header locations for the function keys, and tap into traces on the motherboard.

Yes those do need to get wired to the appropriate connection points on the motherboard.

 

If you go to to the Installation page and scroll down, you'll find some older examples for installing the TK-II Stereo Board which show where to connect the Console keys for any TK-II version.

 

 

EDIT: Some day I need to update the installation to reflect where things go on the newer TK-II boards.

[wildstar87]

I'm running into another problem.  I've been using the TK-II on the 130XE Remake board, and it's been working fine with PS/2 Keyboard.  I'm working on putting in a new mechanical keyboard into the 130XE from @ScreamingAtTheRadio, and I was having issues having the keyboard working at all.  All the function keys other than Help seem to work, all other keys don't.  It seems that if TK-II is installed, it blocks the inputs from the physical keyboard, but if I remove the PIC chip entirely, the keyboard does work.  I hadn't been using the built-in keyboard, since I've been fiddling with upgrading it, so never used it along with TK-II, which is why I never saw this before.  Doesn't seem to matter if the PS/2 keyboard is plugged in or not. 

 

I also tried using the plug-in board, in place of using the built-in, with the same results, both were using the the 2.7J firmware.  I know you mentioned some issues using the built-in keyboard with TK-II in the past, but thought you had fixed those with later firmware.  Just to make sure, I also did try with the stock 130XE keyboard, and got the same results.  I did try the XEGS mode, though it didn't seem like the same issue.  Any ideas?

[chevymad]

TKII turns off the stock keyboard. There's a key combination you need to press on the ps2 keyboard, then the stock keyboard will work. It only needs to be done once and then the function will be retained. I forget the combo though. 

[chevymad]

Found the post I was remembering.   "It defaults to PS/2 only keyboard mode on first power-up of the PIC. Needs a PS/2 keyboard to toggle that function (CTRL+ALT+X) which is a nonvolatile setting (only have to do it once). Since a person who buys the TK-II usually would do so for the purpose of using a PS/2 keyboard, I never thought of this as being a problem."

 

[wildstar87]

That was it, thanks!  I was really close, it was specifically XEGS mode off, I was trying it on.  I read through the manual, but for some reason, completely missed the note.  Note: If the stock keyboard is to be used in parallel with the TK-II, then the XEGS Mode should be set to OFF. This feature is toggled by pressing CTRL+ALT+X, with the last setting retained in non-volatile memory.