Nat Semi SC/MP Low Cost Development System

[Realtime]

I've been a bit quiet on this (been pulling my hair out trying to understand the code). I decided to strip the code back to almost nothing, just a routine to service the display and even that didn't do anything. So I made a harness to use the MK14 as an EPROM emulator for the TELEKIT. I was originally going to use Coolsnaz2's dual port ram VDU card for this but settled on the MK14 for 2 reasons. 1) as most of the TELEKIT functionality is based on SIO and FLAG activity I would be able to load the code into the MK14, see how it runs on the MK14's processor and then switch over to see how it compares on the TELEKIT processor (albeit at half the speed). 2) the MK14 has Coolsnaz2's fast loader so the turn around time for making and testing changes is short.

One thing I found is that ENIN has been left floating on the TELEKIT. There's no indication in the ISP/8A-500 datasheet that that's allowed so I have added a pull up resistor. I've replaced both SRAMs as one was definitely faulty and also replaced the 74LS04 as the logic levels looked weird on some pins.

And now, I can write to the display and see the keypad scan happening That's a relief as that alone tests about 90% of the card.

Unfortunately loading up the full (original) code still results in a blank display but at least I have a means of building the code up again to see what's going astray.

[circuitryboy]

Excellent advance there. It's good to see the display in action.
Yes, the firmware does seem to be something of a Mare's Nest. The original pic shows the MM5204Q labelled
'TELEKIT' without any version/level number. Had the window been taped and then cut away?
Suggests reprogrammed - work in progress.

Did you find any high-resistance contacts within the keypad matrix?

[Realtime]

Originally Posted by circuitryboy

Excellent advance there. It's good to see the display in action.
Yes, the firmware does seem to be something of a Mare's Nest. The original pic shows the MM5204Q labelled
'TELEKIT' without any version/level number. Had the window been taped and then cut away?
Suggests reprogrammed - work in progress. Did you find any high-resistance contacts within the keypad matrix?

Definitely was a work-in-progress. As for the keypad I haven't reconnected it yet. I don't want to keep stressing the flexi each time it's moved out of the way.

Originally Posted by circuitryboy

. ...... Right at the end before cycling back to $0001. Looks like a Bug!

Yes, I'd been wondering about that jump to START and it really didn't make sense. So I changed it to JMP LAB002, which is the start of the main loop. That resulted in some random looking but repeatable characters being displayed when a message was received over the TTY interface from the LCDS. A bit more digging and I found the timing variable for the received TTY baud rate. +$45(P2) was set to 9 - a bit of experimenting led to a value of 6 being used. Now the TELEKIT correctly receives and displays the message from the LCDS, namely CL 0001 <CR>.

I've captured that in the very short attached video. I added some code to initialise the display to -tELEKit- at power on. This then gets shifted out to the left as new characters are received from the LCDS.

Phew. Next is to figure out how keypresses should be handled, but that's enough progress for this weekend. My wife thinks I left home Friday afternoon!!

[Timbucus]

Ah that is lovely to see some text moving- well done on the effort involved there and the risks to marital bliss taken in the name of retro archaeology

[circuitryboy]

Originally Posted by Realtime

As for the keypad I haven't reconnected it yet. I don't want to keep stressing the flexi each time it's moved out of the way.

Of course. I understand your concern.
In the pics it looks like the flexi contacts are 0.1in spaced.
Would it be possible to improvise a 'ZIF' connector where the contacts are gently clamped against flat 'Vero' strips,
gold edge connectors, whatever? Then the disconnected matrix could be mapped, assuming keypresses are detectable.

[Realtime]

Originally Posted by Timbucus

Ah that is lovely to see some text moving- well done on the effort involved there and the risks to marital bliss taken in the name of retro archaeology

. I forgot to say that the video is slowed down to 40% of full speed to make it easier to read as it shifts along.

Originally Posted by circuitryboy

Would it be possible to improvise a 'ZIF' connector where the contacts are gently clamped against flat 'Vero' strips, gold edge connectors, whatever? Then the disconnected matrix could be mapped, assuming keypresses are detectable.

I really like that idea. I’ll give it a go at the weekend.

[Realtime]

On the Old Computers Introkit forum page, at the bottom of the page, is a chap called Frank Boehm (Germany) who stated back in 2007 "Just received a "Telekit" - made by National Semiconductor, datecode 7618. This is pretty much the same electronics, but built into one of their larger pocket calculator cases (looks like the Mathematician PR 4640 with different key mappings). It has an external cable probably to attach it to a tty terminal".

Does anyone recognise Frank from this or other forums? It would be really interesting to contact him and see what he knows.

[circuitryboy]

I found this. But digging deeper fails.
I think perhaps because it's "archived" and gone missing?

[Mark1960]

I saw that too, he doesn’t seem to have been active since about 2013.

It might be worth asking about the telekit on any active forum for collectors of calculators. Frank might not reply but someone else might have seen one or collected one.

[Realtime]

A combination of work, holiday and other MK14 code development has diverted me from this for a while but I finally got back to it today. By way of a recap:

• Telekit handset is connected to the LCDS
• MK14 being used as an Eprom Emulator in place of the Telekit EPROM.
• Digital oscilloscope is decoding and displaying the 110 baud TTY messages
• In message #103 Telekit was receiving messages from the LCDS but not responding to its own keypad.

In the latest setup I've replaced the Telekit keyboard with a 16 way key matrix, so I can be sure key presses are occuring. I now see the following:

Each key press results in the following message format being transmitted to the LCDS and echo'd back to the Telekit for display.
[Keycode] <LF> ? <CR> <LF> -


The keycodes are always greater than $80 so perhaps indicates the keypress is interpreted as a control key?? or just that the code to map keypresses to ASCII is incorrect.

I've attached the latest code listing for anyone that want's to take a look. Within the code I've expanded the comments and identified some as

• NEW: means I've added new code to the original build
• CHANGE: means I've made a tweak to existing code

Not a great deal of change overall but it's definitely getting closer to working.

[Realtime]

A slight clarification. The key press gets sent to the LCDS and the LCDS responds with
[Keycode] <LF> ? <CR> <LF> -
The question mark indicates it doesn’t recognise the character sent. The dash is the start-of-line prompt

[Mark1960]

Is it possible the telekit is sending 7 bit ascii and the lcds is expecting 8 bit? Then the lcds would see the stop bit as high bit set.

[Realtime]

Originally Posted by Mark1960

Is it possible the telekit is sending 7 bit ascii and the lcds is expecting 8 bit? Then the lcds would see the stop bit as high bit set.

Thanks. That’s an interesting thought. I can set the scope to decode 7 bit serial so will take a look tomorrow.

[Realtime]

Made some good progress this evening. I reviewed all the variables to ensure they were initialised before first use. 4 were not so I set them all to zero at the start of the program. As a result I can now enter characters, via the attached mini keypad, that are recognised by the LCDS and echo'd back to Telekit to be displayed So that looks like all the main functions are now working. Here is a valid LCDS command H<Address> used to set a halt address (breakpoint). The , , indicates it was accepted as valid.


So I reconnected the original (calculator) keypad and .... not a sausage. As previously, none of the keys are functioning (but I can still use the mini keypad to send characters). It looks like I need to remove the heads off all the heat-formed 'rivits' on the rear of the keyboard to get to the membrane. Does anyone have experience of doing this? I'm of the opinion that if it all goes pear-shaped then I'll create a new matrix using tiny click switches, but it would be nice to repair the original if possible.

[SiriusHardware]

If you carefully cut off the flat 'rim' of each rivet leaving only the central part of it projecting through the PCB hole you should be able to pull the PCB off while leaving just enough projecting material to flatten back down after you have had a look at it. There is probably only enough projecting material to allow you to do this once, though.

I had a problem with the spacebar on a relatively modern Lenovo netbook where the keyboard layers were held together the same way and after doing as I have suggested - cutting off the thin flattened 'rim' surrounding each hole on the PCB while leaving as much 'nubbin' as possible sticking through the hole - there was enough 'nubbin' material left projecting through the holes for me to flatten them one more time, but probably never again.

Sorry to have to ask, but you have looked for key-on resistances all the way up into the tens and hundreds of K range? These 'rubber bobble' type contact keys - if that is what they are - never exhibit a zero-ohm 'on' resistance, new ones would be more in the tens or hundreds of ohms or low Kohms.

[Realtime]

Originally Posted by SiriusHardware

Sorry to have to ask, but you have looked for key-on resistances all the way up into the tens and hundreds of K range? These 'rubber bobble' type contact keys - if that is what they are - never exhibit a zero-ohm 'on' resistance, new ones would be more in the tens or hundreds of ohms or low Kohms.

No that's fine. I tested on all ranges but knowing that the Telekit shift register has 10K pull downs on it's inputs means it could only be a couple of K at most. I've started removing the plastic rivit heads so will post a photo when I know a bit more.

[Realtime]

Keypad is now dismantled. The layout is a lot more complex than I was expecting.

The rubber actuators on the keypad push the flex circuit tracks in the middle of the hexagons to make contact with the ridged PCB. They are only about 10 thou wide. I thought they were gold plated but not so sure as there is quite a bit of green corrosion in the tracks.
There are 2 broken tracks on the flexi, but by co-incidence they both relate to the slide switch. The keyboard is stuck in 'normal' mode as a result.

The flexi circuit connects to the columns (9 off) and the ridged PCB connects to the rows (6 off).

Not sure where to go next with this one. Maybe I need to wait until I find a compatible Novus calculator for sale and hope I can swap out the keypad.

[circuitryboy]

That flexi layout is amazing. Designed by Elves? To fail?
You'd think they would put a disk in each octagon to improve contact.
What are the 'eyelets' down 'level' with keys 0/1 and 1/4?

[Realtime]

Originally Posted by circuitryboy

That flexi layout is amazing. Designed by Elves? To fail?

I know - it's quite something

Originally Posted by circuitryboy

What are the 'eyelets' down 'level' with keys 0/1 and 1/4?

They are the pads that make contact with the rigid PCB (there are 6 on total, 2 in the top right of the photo, connecting to the 6 inputs to the read back shift register). But again, designed to fail as it's only a copper-copper pressure contact, no spring or anything. By co-incidence I was just preparing a post on the same subject. I've made some progress getting it working - not fully but enough to show Telekit is working.

[Realtime]

Having decided that a 100% non-functional keypad can't be made any worse, I made some repairs, hardwired the Row connections out to the edge connector and re-assembled and superglued the keypad. As a result about 50% of the keys now work. Not fantastic but it was enough to identify that the key matrix lookup table needed to shift by 1 byte in memory to produce the proper mapping. I've now been able to manually test every row/column combination and create the full key translation table including the CTRL characters. I should say that circuitboy's initial mapping of the keypad (here) based on the the MM5762 calculator chip was spot on.

Thanks to everyone that contributed their experience and time in decoding the initial EPROM dump and all the help along the way. I believe the SW is now functioning in the way that was originally intended (v11 attached). There's still some stuff left to do before putting this down, e.g. finish the schematic; source a replacement keypad; get the original MM5204 EPROM re-programmed; post something on YouTube to capture the journey. I'm probably going to make a simple 5 x 8 keypad matrix and then adjust the key mapping table to produce the correct output codes. Might also be useful if anyone wants to create a Telekit replica. It will also allow the Shift and CTRL keys to be proper keys rather than a slide switch.