Nat Semi SC/MP Low Cost Development System

[SiriusHardware]

In this case I think the original code memory device is a mask programmed ROM, so not subject to bit-rot in the same way as EPROMs. The data read out will probably be right every time or wrong every time, if there has been a failure of one or more bits.

[circuitryboy]

The Introkit+KITBUG 'talked Teletype'. So I think looking at KITBUG source would provide pointers.
NS Germany might have reused code. (I can't find a listing at this moment! Will there be an ASCII lookup table?)
Obviously the TELEKIT monitor (what do we call it?) is also scanning the (unique to 6025 calculator) keypad matrix and LEDs.
Not sure what it will be outputting to the display.

[Phil__G]

Although we can see it does the full alphabet, it could work fully with just 20 keys... just the necessary characters for Kitbug, which is
0-9, A-F, T for type, M for modify and G for go, and an 'enter' (ascii CR) key.
I did a serial hexpad like this for my 6800 and Rc2014... (Arduino) but that was send-only, the Telekit would need to also convert
incoming async ascii to a 7-seg 'Message' type display...
(do I feel a 'Telekit-repro' project coming on...? )

[Realtime]

The KITBUG listing is in Appendix B of the user manual

http://www.bitsavers.org/components/...nual_Mar76.pdf

[circuitryboy]

I've sent an edit to previous post:-
CuriousMarc has the Introkit User Manual in his Documentation Cache and that is where the KITBUG listing can be found.
I'm looking at that now.

I have found another NS calculator, the 4515 'Mathematician, that has the same keypad layout as the 6025 so they might have
the same contact matrix inside the keypad subassembly. It would be helpful to know the matrix layout. Or the calculator IC.
Around 1975 NS were pioneering the 'black blob' technique ("COB") of mounting the IC dies directly to the back of the LED display.
Some of the calculators I've seen in this group don't have much inside the case. Presumably later in production.

Yes, TELEKIT can send alphanumerics into the LCDS so I'm expecting a table to convert keymatrix-byte to ASCII-code.
And it will be interesting to see how TELEKIT is set up to display (on 7seg displays) whatever's received from the LCDS.

[circuitryboy]

I believe I've located the calculator IC in a 1977 Nat Semi databook.
So keyboard matrix is 4x9.
The PR versions of those calculators have the extra slide switch.
There is a companion IC that adds the program storage option.

6025 & TELEKIT pics give matrix positions of TELEKIT keys.

[Phil__G]

Transmit is easy peasy but 7-seg lookup, scrolling and multiplexing is quite busy, so I'm guessing receive is interrupt driven...
although Kitbug is full duplex and sends concurrently as it receives (bit by bit, unlike a uart), so transmit cant be upset by receive & vv
I think the way I'd approach it is to have a timeout on the start bit detection, since all kitbug output is contiguous, a pause means its finished sending and
we can have 100% cpu for the display routine, which would only have to test SA for a start-bit edge, just a few cycles so v quick...
.... or another way would be to tailor the display scan to 4.5ms (maybe faster scans but more of them) so the display routine can be used for the 110 baud delays...
If its a big disassembly job, why dont we do a bit each?

.

[Mark1960]

Originally Posted by SiriusHardware

In this case I think the original code memory device is a mask programmed ROM, so not subject to bit-rot in the same way as EPROMs. The data read out will probably be right every time or wrong every time, if there has been a failure of one or more bits.

Post #16 shows uv eprom, with no label on the glass window, though it probably spent all its life inside the calculator case.

[SiriusHardware]

I confess I had assumed that all of the MM5 series memories were mask programmed devices. School day every day, etc.

[Phil__G]

The ETI article is particularly revealing:

[Timbucus]

Originally Posted by Phil__G

The ETI article is particularly revealing:

Ah wow I had read that but, at the time had not seen a Telekit so never made the connection - nice find.

For those interested the PROM SIMULATOR PLUG he talks about in the last paragraph is the seed of the idea for the SCRUMPI 1... which is why I know the article.

[Realtime]

Well I’m shocked. I found that ETI article when I was trawling the net for anything LCDS related but never read past the 1st page. Thanks Phil, that’s going to be a great help in debugging the TELEKIt.

[Mark1960]

Same here except I was actually searching for TELEKIT and still didn’t realise there was a block diagram included.

[circuitryboy]

Is it just me? I've been reading that second ETI page since it was in post #1, but I find the text in Fig.s 1 & 2
only 50% legible so didn't look for very long.
Of course it's exactly as given on Worldradiohistory.
I no longer have my hoard of old magazines. Does anyone have those pages on the original paper?

And it's only now filtering through to me: the TELEKIT will interface with anything that's expecting a teletype?
(With whatever limitations 9x[7-seg digit] will present.)

[Realtime]

Here at last is the TELEKIT source. Added some initial comments but please don't take them as gospel. Feel free to update with additional comments / insights and post back (with a revised version number in the filename).

A few things from inspecting the TELEKIT PCB:

• FLAG1 is used to control the shift registers. Currently it's permanently low and should be toggling. Not sure why.
• SOUT can be seen counting (on a 'scope) and feeds one of the shift registers
• SENSEA receives the TTY input from the optocoupler and SENSEB receives the same but inverted

I connected the LCDS TTY output to my scope which does serial translation and it turns out the baud rate is 250 not 110. The message that gets decoded on the 'scope is CL 0001, which is exactly as described in the LCDS user manual, showing the LCDS is behaving correctly. I assume that matches the TELEKIT baud rate, but might not.

[Phil__G]

Thats interesting, I'd always assumed in ignorance that the LCDS ran Kitbug.
250 baud is well weird, has the crystal been changed?
I need to do some reading
"CL 0001" ?

I wonder if somewhere in all the invalid instructions from 1F0 to 1FF theres a 7-seg translation table? it would be quite long to cover A-Z, 0-9, symbols etc
1FF minus 1D0 is 47 (decimal) entries so could be...

[Timbucus]

Yea that dawned on me as well about general teletype - sounds useful.

I will hopefully be able to do a better scan of the pages on the weekend as I have a copy on the way... I had been looking out for one for a while due to the proto SCRUMPI mention.

Anxious to see the ROM contents now for the character set and a disassembly - will be fascinating. (EDIT: crossed with post with source... oh nice - there must be a segment table in there)

For those looking out for a Financier PR there seems to be (the one I bought) a version with some of the keys marked - the numbers correspond but, may have to do some fiddling with the others...



This sounds like a great project to include one of Karen's PIC based SC/MP units in... at least until (hopefully) we can clone the PCB...

[Phil__G]

Ok as suspected, I've found the characters in 7-seg

Just drawing it up now

[Timbucus]

Ah you beat me too it... just understanding the rest of the code

[Phil__G]

; seven-segment display table. ASCII is used as an offset into the table from 0x01A0h
; byte at that offset is true (noninv) 7seg for the character
; eg ascii "H" is 0x48, 0x01A0 + 0x48 = 0x1E8, byte at that address is 6E, binary 01101110, segments bcefg = "H"
:
; segments oranised a b c d e f g dp
; bit               7 6 5 4 3 2 1 0
;
;     aaaaa
;    f     b
;     ggggg
;    e     c
;     ddddd  dp
;
01C0   00       ; start of ascii to 7-seg table and ascii 20h = space
01C1   41       ; "'."  hex 21 exclamation
01C2   44       ; "||" hex 22 quote marks
01C3   01       ; decimal point hex 23
01C4   01       ; decimal point hex 24
01C5   01       ; decimal point hex 25
01C6   01       ; decimal point hex 26
01C7   40       ; "'" hex 27
01C8   9C	; "[" hex 28
01C9   F0	; "]" hex 29
01CA   01       ; decimal point hex 2A
01CB   01       ; decimal point hex 2B
01CC   01       ; decimal point hex 2C
01CD   02       "-" hex 2D
01CE   01       ; decimal point hex 2E
01CF   01       ; decimal point hex 2F
01D0   FC	; "0" hex 30
01D1   60	; "1" hex 31 etc...
01D2   DA	; "2"
01D3   F2	; "3"
01D4   66	; "4"
01D5   B6	; "5"
01D6   BE	; "6"
01D7   E0	; "7"
01D8   FE	; "8"
01D9   F6	; "9"
01DA   01       ; decimal point
01DB   01       ; decimal point
01DC   01       ; decimal point
01DD   12       ; "="
01DE   01       ; decimal point
01DF   CB	; "?"  
01E0   FB	; "@"
01E1   EE	; "a" ascii 41h
01E2   3E	; "b"
01E3   1A       ; "c"
01E4   7A       ; "d"
01E5   9E	; "e"
01E6   8E	; "f"
01E7   BC	; "g"
01E8   6E	; "h"
01E9   20       ; "i"
01EA   78       ; "j"
01EB   4F       ; "k"  
01EC   1C       ; "L"
01ED   EC	; "M" (approximated)
01EE   2A	; "n"
01EF   3A	; "o" 
01F0   CE	; "P"
01F1   3B	; "q" (actually o. )
01F2   0A       ; "r"
01F3   B7	; "s"
01F4   0E	; "t"
01F5   39       ; "u."
01F6   38       ; "v" 
01F7   7E       ; "W" (cap A inverted)
01F8   28       ; "x"  ( || )
01F9   76       ; "y"
01FA   92	; "z" (3 horiz lines)
01FB   00	; " " space or end of 7-segment table
01FC   00	; " " space
01FD   00	; " " space
01FE   00	; " " space
01FF   00	; " " space

These big tables are great cos it means theres much less actual code to disassemble!

Originally Posted by Timbucus

just understanding the rest of the code

Go for it Tim, many hands make light work...


.