TELEPIC - a replica TELEKIT

[Realtime]

Hi, I'd like to get some input on this project please.

Now that the TELEKIT investigation has pretty much concluded, I want to create a replica design but I'm very aware of the cost and availability of SC/MP processors and the unavailability of the NOVUS calculator. Having built a version of Karen's MK14 emulation (PIC14) in the past I decided to have a go at modifying her source code to run the TELEKIT firmware on a PIC16F877(A) or PIC16F876(A). Telekit only needs the following SC/MP signals:

• nRESET
• SENSE_B - TTY_IN (110baud - even at 110baud it's quite difficult to read the display as it shifts characters along. Anything faster would make it unreadable.)
• FLAG0 - TTY_OUT
• SIN - Key matrix scan input
• SOUT - Key matrix and display scan output
• nADS - used to clock SIN / SOUT at external shift registers
• FLAG1 - Shift register mode control

I've added nADS to Karen's code, expanded Phil's SIO code to do both SIN and SOUT, re-mapped the PIC pinout to use just ports B & C (common to both the 877 and 876 parts) and commented out such features as file transfer. External RAM is not required as the PIC's 256 bytes EEPROM can be used instead, eliminating the need for an Address/Data bus. I'm happy to say the TELEKIT code is now running on the SC/MP emulation and generating the right kind of signals at it's outputs (I've hooked up a single shift register to demonstrate the display multiplexing part) . But I'm now at a fork in the road and need to decide which way to go. I see 2 options:

Option 1: Retain all the external logic and shift registers needed to drive the display and sample the key matrix (that's 8 LS logic devices and buffers). This maintains the TELEKIT concept as much as possible and is the closest you'll get without using a real SC/MP

Option 2: Create additional PIC code to emulate the shift registers internally and use ports A, D and E parallel outputs to directly drive the display and keys. It's a "one chip" solution (although probably needing a external buffer to drive the display, as per PIC14). It would be restricted to the 877, as the 876 doesn't bring PORT D and E out to pins.

There are a few other things to ponder, like

• Maintaining the 20mA current loop interface, with an option for a TTL interface
• Design the PCB to fit in a NOVUS calculator case, but in reality use a 3D printed case to replace the original
• New key matrix PCB using miniture switches
• Separate Shift and CTRL keys rather than using a slide switch, which is the biggest drawback in the TELEKIT design I think
• Use a 9 digit calculator display or 9 x individual 0.28" 7 segment displays, requiring a slightly wider case

Obviously all of this leads to something that is not a true replica, but would allow you to experience what it was like to write code and debug it using a TELEKIT.

I would be very interested to get your thoughts on the above or any other aspects of it.

BTW, I use TELEKIT with KITBUG+ running at 110 baud and it's a joy (mostly)

[Phil__G]

Excellent, well done Ian. Its a dilema, the pic could do it all, but external ttl would be more 'Telekit'. The only answer, is to do both . Similarly a tiny calculator display would be more 'Telekit' than a bigger display...
20mA, RS232 or TTL serial could be off-board.

Which base emulation did you use, the one from the KO2019?

[Timbucus]

Nice - I have a Dead Novus and a lot of 877's so a PCB that fits inside sounds amazing. As the keyboard matrix is likely hosed on real ones and you would need something on a 3D printed one, the approach that would allow a small replacement key matrix to be created or used if needed/always required anyway is also a great idea.

[Mark1960]

If using a pic instead of an sc/mp or sc/mpII then it doesn’t really matter if you keep the same interface using shift registers or handle this inside the pic, just do whatever is easiest. You might use 74hct instead of 74ls if the same functions are available.

For the keyboard there are smt tactile switches with very low profile, equivalent to a metal dome on a plastic carrier, that might help to keep the assembly similar to the calculator keyboard, assuming you are intending the 3d printed case and keys to be similar size as the original.

[Phil__G]

On the other hand, if the pic purely emulates the SC/MP, the original circuitry can be authentically reproduced, so the end product is a real Telekit - this is the dilema!
But yes I agree, I think I'd let the pic do it
The timing will be the challenge, display, keypad and serial, especially if the baud rate is upped

[ortek_service]

Originally Posted by Realtime

Hi, I'd like to get some input on this project please.

Now that the TELEKIT investigation has pretty much concluded, I want to create a replica design but I'm very aware of the cost and availability of SC/MP processors and the unavailability of the NOVUS calculator.
>>
>>

Originally Posted by Phil__G

Excellent, well done Ian. Its a dilema, the pic could do it all, but external ttl would be more 'Telekit'. The only answer, is to do both . Similarly a tiny calculator display would be more 'Telekit' than a bigger display...
>>

Well there could also be a third option: To replicate the original PCB virtually as it was - But use a very-similar pinout SC/MP-II NMOS processor as these are still rather more available than the original PMOS SC/MP (Only listed by Cricklewood and nearly £100). Plus it is likely that most who would want to build one of these already have at least one SC/MP-II around (even if it means borrowing it from another different-product replica etc).

Although would have to decide if to stay with original PMOS 2-rail supply and proprietary pinout MM5204 EPROM (TVsat in Poland were about the only place to have these still listed, and were quite reasonably-priced. But would normally involve building a programmer for these / getting one programmed by someone with a suitable programmer) or change it to a more-conventional JEDEC-standard pinout single-rail supply EPROM like the 2716.

If the Novus calculator case is being made as a 3D-printed replica then lack of original ones of those should be too much of an issue (assuming suitably small switches / display are used, for it all to fit inside).

[Phil__G]

Ah, but then it wouldnt be a 'Telepic'

[Realtime]

Thanks for your feedback Just picking it up again.

Originally Posted by Phil__G

Which base emulation did you use, the one from the KO2019?

Karen's original PIC14 code, although now with quite a lot of mods to align it with the TELEKIT hardware. I know there's a couple of errors in the decimal add instructions, so I'll put your corrections in for those (although I don't think they are used by TELEKIT).

Originally Posted by Timbucus

Nice - I have a Dead Novus and a lot of 877's so a PCB that fits inside sounds amazing.

Nice, that means you have a 9 digit display and frame available too. Is that a 6025 or a 4515 calc? I think the bodies must be the same, as the PCB in my 6025 is marked NOVUS 4515, presumably just fitted with a different calc chip.

Originally Posted by Mark1960

If using a pic instead of an sc/mp or sc/mpII then it doesn’t really matter if you keep the same interface using shift registers or handle this inside the pic, just do whatever is easiest.

Originally Posted by Phil__G

The timing will be the challenge, display, keypad and serial, especially if the baud rate is upped

I don't intend changing the Baud rate, but you are right about the timing being a challenge. I started by using the PIC's EEPROM as a RAM area - 256 contiguous bytes. However I had neglected to think about the long time it takes to write a byte to EEPROM (~4ms) and because the RAM is continuously being written to it made the TELEKIT code execution run very slowly. That took me a while to fathom, but I have now changed the PIC14 emulation to put RAM at 0x200 (instead of 0xF00) using the PIC's register/RAM banks and it now runs at about 80% of the required speed. Karen does point out in her PIC14 manual that the SC/MP emulation is cycle perfect when running programs from RAM but slower when running from PROM. I'm running the TELEKIT code out of PROM so that probably accounts for the slightly slow execution. No worries. I've changed the PIC crystal from 10MHz to 12MHz and I now get 110 baud serial being produced.

Originally Posted by ortek_service

Well there could also be a third option: To replicate the original PCB virtually as it was - But use a very-similar pinout SC/MP-II NMOS processor as these are still rather more available than the original PMOS SC/MP (Only listed by Cricklewood and nearly £100). Plus it is likely that most who would want to build one of these already have at least one SC/MP-II around (even if it means borrowing it from another different-product replica etc).

Originally Posted by Phil__G

Ah, but then it wouldnt be a 'Telepic'

I don't think Cricklewood has had the PMOS part in stock for quite some time now. There is one on eBay for about $200 but no guarantee that it works. TBH I'm seeing this as a bit of a challenge to learn PIC programming and understand Karen's code (I wish she had added some comments along the way ) - so PIC it is!

Originally Posted by Timbucus

As the keyboard matrix is likely hosed on real ones and you would need something on a 3D printed one, the approach that would allow a small replacement key matrix to be created or used if needed/always required anyway is also a great idea.

I think one of the more challenging parts of the project will be developing a replica keypad with appropriate silk screen that can be hosted in the original case (or a 3D printed one, of course). If anyone has any experience of ordering small feature screen printed overlays I'd welcome some advice.

[Phil__G]

One thing that might ease the timing would be to do the async-serial I/O in PIC code rather than emulated SC/MP code, thats what the PICL does, with two new SC/MP pseudo-opcodes representing GECO & PUTC.
The Telepic will be 110bd of course but just as an example in PIC-speak 9600 is easy whereas the SC/MP isnt really fast enough unless you use SIO like my Aliexpress printer at 9600 - but your SIN/SOUT are occupied arent they...
Of course you could drop the emulation altogether and have the PIC do all the Telepic stuff directly without involving any SC/MP code...

Teasing! But a serious question - can the original Telekit do FDX, ie can it send whilst receiving & vice versa?

[SiriusHardware]

Ref: Using EEPROM as 'RAM' - I could definitely be wrong but this memory area in PICs may belong to the class of writable memory devices which can only be successfully written to a finite number of times, although if it is one of those then you have to write to it something like hundreds of thousands of times before it starts to be a problem.

I think it is originally really meant more for storing static but user-alterable settings, configurations, and so on.

[Realtime]

Originally Posted by Phil__G

One thing that might ease the timing would be to do the async-serial I/O in PIC code rather than emulated SC/MP code,

I'd prefer not to touch the TELEKIT code if possible but instead modify the emulation to look like TELEKIT HW.

Originally Posted by Phil__G

can the original Telekit do FDX, ie can it send whilst receiving & vice versa?

It appears to do both simultaneously but it is really 2 separate processes. A keypress generates a character out, which does not get displayed so needs the receiving equipment to echo the character back. And likewise the only action on TELEKIT receiving a character is to display it.

[Phil__G]

Originally Posted by Realtime

It appears to do both simultaneously but it is really 2 separate processes. A keypress generates a character out, which does not get displayed so needs the receiving equipment to echo the character back.

...and when talking to the LCDS, since GECO echoes received characters bit-by-bit, ie a Telekit keypad character is echoed back by the LCDS almost in real time (ahem!) delayed by just half a bit, the Telekit must be processing tx & rx simultaneously, whilst they are staggered by half a bit - that in itself is some very clever bit-banging
Unless...
We're sure it doesnt just pass the transmitted character to the display routine, ignoring the incoming echoed bits from GECO until the key from the Telekit keypad has been fully sent?
That would be so much easier as each transmitted character is the perfect length to 'mask' the echoed bits, and the display routine being 'somehow' passed each transmitted character is expected behaviour (?)
...in which case the receive routine would just pass received characters to the display routine, as it can only be LCDS output (for example) ?
Kinda like hdx local echo. Sorry I should read the Telekit source again.

[Realtime]

Originally Posted by Phil__G

...and when talking to the LCDS, since GECO echoes received characters bit-by-bit, ie a Telekit keypad character is echoed back by the LCDS almost in real time (ahem!)

.

Originally Posted by Phil__G

delayed by just half a bit, the Telekit must be processing tx & rx simultaneously, whilst they are staggered by half a bit - that in itself is some very clever bit-banging

Yes, you're right there is a 1/2 bit delay between the LCDS receiving (yellow trace) and re-transmitting a character (blue trace). When telekit is receiving multiple characters (say when Kitbug+ is displaying a block of memory) keypresses are simultaneously output by Telekit.

[Realtime]

Originally Posted by SiriusHardware

Ref: Using EEPROM as 'RAM' - I could definitely be wrong but this memory area in PICs may belong to the class of writable memory devices which can only be successfully written to a finite number of times, although if it is one of those then you have to write to it something like hundreds of thousands of times before it starts to be a problem.

I think it is originally really meant more for storing static but user-alterable settings, configurations, and so on.

That's a very good point. Microchip state a minimum of 10000 write cycles per location, with a typical life in excess of 1 million cycles, so shouldn't be relied upon for long term use as processor RAM.

[Mark1960]

Originally Posted by Realtime

I think one of the more challenging parts of the project will be developing a replica keypad with appropriate silk screen that can be hosted in the original case (or a 3D printed one, of course). If anyone has any experience of ordering small feature screen printed overlays I'd welcome some advice.

Probably easier to have jlcpcb make a thin pcb with black solder resist and white screen printing. 0.8mm thick is probably still within the low cost option. Put solid copper on the side with the printing or they might not add the solder resist. Internal corners on routing holes for the buttons will probably be 1mm radius.

[SiriusHardware]

Microchip state a minimum of 10000 write cycles per location, with a typical life in excess of 1 million cycles, so shouldn't be relied upon for long term use as processor RAM.

I don't know in what context it would be used here, but if (for example) the EEPROM memory was used to 'be' the standard MK14 RAM in an MK14 emulation, one or two of the first few bytes of RAM are continually written to by the MK14 OS while it maintains the display whenever the monitor is in 'waiting for input' mode.

If used in that way, it wouldn't be long before you started to get close to the theoretical maximum number of writes.

[Realtime]

Originally Posted by Mark1960

Probably easier to have jlcpcb make a thin pcb with black solder resist and white screen printing. 0.8mm thick is probably still within the low cost option.

Thanks. I like that idea. I'll take a look.

[Realtime]

Originally Posted by SiriusHardware

I don't know in what context it would be used here, but if (for example) the EEPROM memory was used to 'be' the standard MK14 RAM in an MK14 emulation, one or two of the first few bytes of RAM are continually written to by the MK14 OS while it maintains the display whenever the monitor is in 'waiting for input' mode.
If used in that way, it wouldn't be long before you started to get close to the theoretical maximum number of writes.

Karen's code uses the PIC register banks for the MK14 RAM at $F00, so no wear and tear problems there. I only used the EEPROM because I didn't understand her code well enough to be making changes initially. Once I realised the error of my ways I dug in and remapped the SRAM from $F00 to $200, so no longer need the EEPROM.

[Phil__G]

Re ram for the sc/mp, unless every byte is needed, I found it easier to use just 80 bytes from offset 0x20 in each bank, so the FSR has the same fixed range to address in each bank. This gives 320 bytes without having to treat each bank differently and without stepping on any actual PIC registers In the case of the Telepic, maybe 80 bytes of ram (banks 1 or 2) would be enough (or 96 bytes in 3 or 4), avoiding bank switching altogether?

I think the premise that "it must run the standard Telekit rom image" is a very good one, meaning the Telepic is a true hardware emulation

[Realtime]

Here are the TELEPIC PCBs, so far. I'm getting close to ordering an initial batch of boards. I decided to keep the 20mA loop I/F and also provide alternate TTL signals for an FTDI converter. The keyboard switches are low profile disc types (about 1mm high, as Mark suggested). In theory it should all fit in the Novus calculator case. Time will tell.