Need some help with my Mextel Autokey 40

[kbTinker]

I’m looking to replace a faulty logic IC on my Mextel Autokey 40. I googled 74LS32 and a whole bunch of options came up. I am unsure what do specifically look for when it comes to buying a replacement logic IC. I want to avoid buying the wrong one. Can anyone shed some light on my issue? I have attached a photo of the original IC.

[kbdfr]

I might be able to provide you with a replacement taken from another Mextel Autokey 40,
provided you can explain exactly how the Mextel works, as I have been unable to use it.

[Mazian]

The 74xx series chips are widespread and generic - many manufacturers make near-identical versions of those chips. Any other 74LS32 in that form factor will be a drop-in replacement.

One to three extra letters at the front are a manufacturer ID code, an extra letter or two at the back is the packaging type. Something like this SN74LS32N would do the job.

[kbTinker]

I might be able to provide you with a replacement taken from another Mextel Autokey 40,
provided you can explain exactly how the Mextel works, as I have been unable to use it.

The one I purchased came with user instructions printed on the tops of the macro reference tabs that attach to the three plastic rings above the keys. Using those instructions, I was unable to get mine to work as designed. However I have a running theory that the memory module that is used to store the macros requires a new battery. The autokey uses a common 2325 3v lithium coin battery. I do not think that the memory uses power provided by the computer. I say this because in the old advertisements I was able to find on the AutoKey, they stated that it came with a battery so that you wouldn't lose all of your stored macros if the AutoKey was unplugged.

If you would like, I could post some pictures of the flip tabs.

[kbTinker]

The 74xx series chips are widespread and generic - many manufacturers make near-identical versions of those chips. Any other 74LS32 in that form factor will be a drop-in replacement.

One to three extra letters at the front are a manufacturer ID code, an extra letter or two at the back is the packaging type. Something like this SN74LS32N would do the job.

Thank you for your help! I know absolutely nothing about electronics hardware besides how to solder and de-solder.

[kbdfr]

[…] If you would like, I could post some pictures of the flip tabs.

Please do!

[kbTinker]

[…] If you would like, I could post some pictures of the flip tabs.

Please do!

There you go! I also did some research on the board and found out that the boards firmware was mostly likely stored on a EPROM chip, on the Autokey it is on the right side of the motherboard

[kbTinker]

I might be able to provide you with a replacement taken from another Mextel Autokey 40,
provided you can explain exactly how the Mextel works, as I have been unable to use it.

I have been doing a lot of research lately on the components of the motherboard of the AutoKey, specifically the EPROM chip with the quartz window on the top of it. With the autokey fully assembled, the quartz window is accessible via the plastic removable cover on the right side of the board. The quartz window is covered by a sticker that I think lists the type of firmware that is stored on the chip, essentially the coding that makes the board operate as it supposed to.

Now, I think the reason you and I are running into issues with getting the board operate properly is due to the fact that parts of the programming stored on the chips has been slowly erased over time. I say this because EPROM chips can be entirely erased simply by exposing the quartz window to UV light for a certain amount of time, some sites say 30 minutes, others say other times. However, those sites also say that any kind of passive UV light can slowly erase the stored programming on the chip over time even though the chip may be covered by plastic and/or a paper sticker, as is the case with the AutoKey. This is because UV light can pass through plastics and paper and with enough time, can cause the stored programming to be entirely erased.

In conclusion, I think the issue with our AutoKeys is that the operating firmware coding has been entirely erased due to prolonged UV light exposure. The only solution I can think of is to some how re program the EPROM chips with firmware that will allow the board to function like it is supposed to. I have no idea how to do that, nor do I possess the proper tools or software to do something like that.

If you perhaps know someone that could possibly take a look at your AutoKey, in order to understand how it is supposed to function, and has the knowledge required to reprogram the EPROM chip inside of of it and/or to check if the chip still is in fact programmed, you may be able to get yours to work. I am going to try to find forums and groups that tinker with old programmable hardware and see if they would be able to shed some light on our issue.

Below I have posted a picture of the EPROM chip in my board and the plastic removable cover on the right side of the top case.

[pandrew]

I got one of these, and just tried it.
I connected a model M with SDL to DIN cable to it, and on the PC side I tried both a common PS/2 to USB adapter with a DIN to PS/2 passive adapter, and I also tried a Soarer's adapter.

The result, in both cases, is that it sortof kinda almost works, but:
* It's intermittent, sometimes even the Model M keypresses are not forwarded.
* When it works the last key of the macro that is played back is kept held down for long enough that the OS repeats it many times.
* Apparently I can't use the same key twice in a macro. If I record "hello" it plays back as "helo"
* After I play back a macro I can't immediately play it back again. But I can play it back again after I disconnect and re-connect.
* After I just boot it up no keypresses are lost from the Model M. Any intermittent issues happen only after I try to play back a macro. Almost like it's not done playing back the macro, and it can't pay attention to forward all keypresses, while it's trying to work on the macro.

I probably could extract the EEPROM content, although it will take me some tine since this is not high priority for me. If the eeprom really contains firmware (and not just macros), and it has degraded, we could probably recreate the original firmware from scratch if we dump it from multiple eeproms containing the same firmware. It's unlikely that the same bits would degrade on multiple EEPROMs. But I only have this one keyboard.

EDIT: My EEPROM has a sticker saying "Autokey40 REV. 3.74"

[pandrew]

Just a follow-up on this:

I just got a programmer, and I have read out the EPROM from two different Mextel Autokey 40 keyboards, both have Rev. 3.74. stickers on the EPROMs. (interestingly it's printed correctly, unlike the hand-corrected sticker on kbTinker's picture)
The two binaries i have read are equal, so there is a very high probability that the image is correct and the EPROMs have not degraded.
See attached binary.

Just running the unix utility strings on it already yields some interesting results:

Code: Select all

...
 FREE BYTES, MENU -
MEXTEL CORP.  312-595-4146
   SCAN SET-
 MODE - PC,XT
 MODE -AT    
AUTO BUFFERING       - 
OFF CODE SUPPRESSION - 
DATA RETENTION STATUS- 
SENDING RATE         - 
...

So by the looks of it, it may be possible to access a menu where you can change some settings to get things working. since there's no other obvious place to print these strings, I guess they are probably sent as keypresses.

It would be interesting if we could find a manual for this keyboard.

Otherwise, since these keyboards contain a Z80 CPU, this could be a prime learning project for someone interested who would want to get into reverse engineering, since you have a chance to understand the entire system, and 8K is really not a lot of Z80 code, great learning opportunity. I don't have much time or energy to do this myself right now.

On another note: when debugging this keyboard, it would be a good idea to check the health of the SRAM chip next to the EPROM, those can also go bad. (And of course check the battery health too, to make sure it remembers macros, it's most likely dead by now)