• Please review our updated Terms and Rules here

TRS-80 PT-210 Data Terminal - keyboard repair, ROM dump, RS-232 board reproduction ... ROM hacking?

FalconFour

Experienced Member
Joined
May 22, 2017
Messages
72
Location
San Jose, CA USA
Well, I did it, I got my hands on a PT-210 of my own.

IMG_9172.JPG

First thing I did was tear into it and check for problems. Robust power supply, looks to be linear - no potential problems there I can see. Paper was old and gnarly, but that's an easy fix with a stop by Staples and picking up a roll of fax thermal paper, I'm sure.

The keyboard, though, was all non-functional. The design of the keyboard appears to be "carbon pad and rubber dome, but with spring and keycap above it". So it suffers from contact corrosion - but it also suffers from the deep trouble of disassembling to clean those pads. All the solder pads needed to be desoldered to access each key switch's internal contact pads. So I did. It took 3 hours.

IMG_9158.JPGIMG_9159.JPGIMG_9163.JPGIMG_9165.JPGIMG_9160.JPGIMG_9166.JPGIMG_9164.JPG

I used a fiberglass scratchy-brush with gusto, to scrub the hell out of the contact pads. I discovered (while testing technique) that I should decidedly _not_ try to scratch-clean the carbon black dome pad. I have some "contact fix" stuff that might fix up that busted key though. All the others worked 100%, first try, after doing this cleaning/reassembly work.
I also shot a bit of WD-40 into the motors to loosen them up. They feel strangely tight, but pushing the shaft side-to-side reveals that the tightness may be part of the motor design - it's not bound-up bearings, it's just an oddly tight motor.

Next, I found that the pressure mechanism (solenoid and arm, rotating a bar that lifts/presses the head against the paper) was strangely out of alignment -- there's 2 set screws on the shaft, and the shaft has a key notch in totally the wrong place! If "set" where the notch is, it sets the head way too far away from the paper, and the tension spring flops around loosely. I adjusted it such that only the top set screw (round top of bar) is engaged; the keyed part would push it out of alignment, so I left it loose. Now it works perfectly, with relatively-clear-enough print (for this old paper).

Next, I played some YouTube 300-baud modem samples into the acoustic coupler. Actual MAGIC flowed out of the print head, as I played the robot screeching bleep-bloops into the microphone, the "Carrier" LED lit up, and it began printing a BBS session, same as was being displayed in the YouTube video. That's exciting. The speaker portion of the acoustic coupler also bleeped with a carrier tone, it appears it's not capable of being a "host", which I find a bit weird (who wouldn't want to hook one terminal to another over a phone call and just, ... chat? lol)

Finally, I plugged my reproduction RS-232 card into the slot (surprising... no screws, no retention whatsoever!), it slot right in... not too shabby for having designed it without a reference machine, only going on photos/docs online! And sure enough, after setting the switches properly (full duplex, 300 baud, "TERM" switch mode, RS232 switch mode, online mode), I was now able to type on the PC and it appeared on the printer... and vice versa.

IMG_9174.JPG
(the "TERM/COMM" switch is simply a null modem switch... I removed the Null Modem adapter shortly after realizing the "tower" could be shorter, lol)

Great. Now I have a fully working PT-210. Now what?

Well, ... it's a bit useless without lowercase support. That strikes me as a MASSIVE limitation. It means you can't interface with *nix systems (which are all case-sensitive). Can't enter a path, can't really TYPE WITHOUT YELLING. I was struck that, when pressing Shift+letter, nothing comes out - it not only can't print lowercase (it converts to uppercase), but it can't send lowercase either!

I thought that was silly, and started investigating whether the ROM could be disassembled and extended to, AT LEAST, send shift+character as lowercase (the same as when pressing Shift+0...9 sends punctuation). There seems to be a lot of room in that ROM for more code/functionality/lookup tables. The microcontroller is reportedly an Intel 8039 or derivative - an interesting architecture to try to develop for, but very common in keyboard controllers, it seems.

Here's that ROM dump, for starters:

And here's the details of that RS-232 card development -- https://forum.vcfed.org/index.php?t...rs-80-pt-210-data-terminal.74829/post-1355427 -- and to buy it (figured I'd better get this up now, since I can't edit later - will try my hardest to keep it available long into the future!) - https://www.ebay.com/itm/266656146667
 
Well, ... it's a bit useless without lowercase support. That strikes me as a MASSIVE limitation. It means you can't interface with *nix systems (which are all case-sensitive).
Unix is an old, old system and maintains its ancient roots, including special support for upper-case only terminals in the tty drivers.

Try stty iuclc xcase to have all upper-case input converted to lower case and activate backslash as the prefix character to enter upper case. (You can also add olcuc should you ever encounter a terminal that doesn't display lower case at all, rather than converting it to upper case.)
 
Oh jeeze the same switches as the trs-80 model III. What a pain. Guess i now know what to do to fix the 3 broken switches on my PT-210.

Congrats! And a new char rom with lowercase would make this thing amazing.
 
For what it's worth, it'll be hard to do anything to that code without a schematic or service manual to know what all the I/O pins do.
 
Well, aren't we all in luck then ;)


That's where I got the board layout/schematic for the RS-232 card as well.

BTW, the RS-232 cards sold out in under 24 hours... I've got another batch of boards/parts on the way. They'll be back!

Next on my todo list is a direct USB-UART interface board, instead of dealing with adapter/dongle silliness with RS232. Bypass the RS232 stage entirely by just level-shifting TTL signal to whatever logic levels (TBD) that the RS232 card gives to the system board. I'll keep both available, but I still need to stay focused and actually build the thing. haha.
 
This is Great @FalconFour. This gives everyone a chance who has this Paper terminal to really use it! If we can get these puppies with an expanded character set or more so we can connect to linux.. That would be a dream come true.

Put me down for the usb board!
 
Last edited:
Being experienced in MCS-48 for many years, I had some plans to look into disassembling the ROM to see if lower case can be implemented. Technically there should be no problem but who knows how gnarly the code is. But I have a long backlog of things to work on so it will take me a long while. I hope someone with a shorter backlog picks it up and figures it out.

My PT-210 needs the full keyboard rebuild...only two keys work and neither are alpha so I can't tell if letter-key and shift-letter-key sends lower/upper ASCII.

@FalconFour If your machine is still apart, I'd sugget lubricating the motor shafts and other parts with machine oil or grease. WD40 only lubricates until it evaporates, which is pretty quickly. Its main purpose is dispersing water, removing rust, cleaning and getting parts moving again. It doesn't leave much behind that acts as a sustained lubricant so using a grease or oil afterwards is necessary.
 
Last edited:
I can definitely answer two of those:
1) My backlog is fairly short and constantly evolving, haha
2) It doesn't send anything with shift+key (at least it seems not to).

If you've got any insight to an entry point to disassembly, I'd probably be able to figure a lot out from there - I can hack my way around assembly. I just don't know what software is good to work with - I've dumped it into IDA Pro and it crunched through the ROM, but its output needs a lot of help that I'll need to figure out how to give it (e.g. marking out clearly obvious data vs. code areas - I'm sure the bitmap character set is all spelled out in there too).
 
I started trying to make out how this processor makes its initial ROM address jump - i.e. where to start reading code...

1707334969379.png

Excuse me? The ROM address & data are related through a flip-flop? And half its address lines come from I/O port pins?

Oh.

I may be in over my head 😭
 
The PT-210 is on my list of systems to add to the trs80gp emulator. I did a dump of the ROM some time back which matches yours exactly so that's nice to know.

Haven't done much looking into it but did find the character set in the ROM at offset $620. Wrote a little program to dump it.

A quick glance at the ROM suggests there is plenty of space for lower-case character glyphs and the extra code.

Just for fun, here's the character set:

Code:
.....
.....
.....
.....
.....
.....
.....

..#..
..#..
..#..
..#..
..#..
.....
..#..

.#.#.
.#.#.
.#.#.
.....
.....
.....
.....

.#.#.
.#.#.
#####
.#.#.
#####
.#.#.
.#.#.

..#..
#####
#.#..
#####
..#.#
#####
..#..

##...
##..#
...#.
..#..
.#...
#..##
...##

.#...
#.#..
#.#..
.#...
#.#.#
#..#.
.##.#

..#..
..#..
.#...
.....
.....
.....
.....

..#..
.#...
#....
#....
#....
.#...
..#..

..#..
...#.
....#
....#
....#
...#.
..#..

..#..
#.#.#
.###.
..#..
.###.
#.#.#
..#..

.....
..#..
..#..
#####
..#..
..#..
.....

.....
.....
.....
.....
..#..
..#..
.#...

.....
.....
.....
#####
.....
.....
.....

.....
.....
.....
.....
.....
.##..
.##..

.....
....#
...#.
..#..
.#...
#....
.....

.###.
#...#
#..##
#.#.#
##..#
#...#
.###.

..#..
.##..
..#..
..#..
..#..
..#..
.###.

.###.
#...#
....#
..##.
.#...
#....
#####

.###.
#...#
....#
..##.
....#
#...#
.###.

...#.
..##.
.#.#.
#..#.
#####
...#.
...#.

#####
#....
####.
....#
....#
#...#
.###.

..###
.#...
#....
####.
#...#
#...#
.###.

#####
....#
...#.
..#..
.#...
.#...
.#...

.###.
#...#
#...#
.###.
#...#
#...#
.###.

.###.
#...#
#...#
.####
....#
...#.
###..

.....
.....
..#..
.....
..#..
.....
.....

.....
.....
..#..
.....
..#..
..#..
.#...

...#.
..#..
.#...
#....
.#...
..#..
...#.

.....
.....
#####
.....
#####
.....
.....

.#...
..#..
...#.
....#
...#.
..#..
.#...

.###.
#...#
...#.
..#..
..#..
.....
..#..

.###.
#...#
#.#.#
#.###
#.##.
#....
.####

.###.
#...#
#...#
#####
#...#
#...#
#...#

####.
#...#
#...#
####.
#...#
#...#
####.

.###.
#...#
#....
#....
#....
#...#
.###.

###..
#..#.
#...#
#...#
#...#
#..#.
###..

#####
#....
#....
####.
#....
#....
#####

#####
#....
#....
####.
#....
#....
#....

.####
#....
#....
#....
#..##
#...#
.####

#...#
#...#
#...#
#####
#...#
#...#
#...#

.###.
..#..
..#..
..#..
..#..
..#..
.###.

....#
....#
....#
....#
....#
#...#
.###.

#...#
#..#.
#.#..
##...
#.#..
#..#.
#...#

#....
#....
#....
#....
#....
#....
#####

#...#
##.##
#.#.#
#.#.#
#...#
#...#
#...#

#...#
#...#
##..#
#.#.#
#..##
#...#
#...#

.###.
#...#
#...#
#...#
#...#
#...#
.###.

####.
#...#
#...#
####.
#....
#....
#....

.###.
#...#
#...#
#...#
#.#.#
#..#.
.##.#

####.
#...#
#...#
####.
#.#..
#..#.
#...#

.###.
#...#
#....
.###.
....#
#...#
.###.

#####
..#..
..#..
..#..
..#..
..#..
..#..

#...#
#...#
#...#
#...#
#...#
#...#
.###.

#...#
#...#
#...#
.#.#.
.#.#.
..#..
..#..

#...#
#...#
#...#
#.#.#
#.#.#
##.##
#...#

#...#
#...#
.#.#.
..#..
.#.#.
#...#
#...#

#...#
#...#
.#.#.
..#..
..#..
..#..
..#..

#####
....#
...#.
..#..
.#...
#....
#####

#####
##...
##...
##...
##...
##...
#####

.....
#....
.#...
..#..
...#.
....#
.....

#####
...##
...##
...##
...##
...##
#####

.....
.....
..#..
.#.#.
#...#
.....
.....

.....
.....
.....
.....
.....
.....
#####

.....
.#...
..#..
...#.
.....
.....
.....
 
I can definitely answer two of those:
1) My backlog is fairly short and constantly evolving, haha
2) It doesn't send anything with shift+key (at least it seems not to).

If you've got any insight to an entry point to disassembly, I'd probably be able to figure a lot out from there - I can hack my way around assembly. I just don't know what software is good to work with - I've dumped it into IDA Pro and it crunched through the ROM, but its output needs a lot of help that I'll need to figure out how to give it (e.g. marking out clearly obvious data vs. code areas - I'm sure the bitmap character set is all spelled out in there too).
It's an MCS-48, it's always reset at 0000, irq at 0003 and 0007

This is what I've picked at so far using my own disassembler...
 

Attachments

  • 80556803.bin.lst.zip
    13.5 KB · Views: 2
Well, that's enough for one night. Referencing the schematic, datasheets, and burning my head tracing logic steps so-very-slowly, I think I'm starting to piece that disassembly together - and it's making logical sense. It looks like you shortcut a lot of the work for me - jumping right to the routine that handles interrupts from the keyboard controller, and leaving breadcrumbs :)

I now know a lot more about MCS-48 assembly... that "page 3" thing caught me off guard, and spent a chunk of time assuming that accesses to P2 were making address inputs to the program ROM. All that fixed up, and...

1707397647306.png

Kinda seems a lot like this could be as simple as rewriting the scan code translation table, here in "page 3" of the ROM ;) Still need to figure out exactly how it's packed though, and I won't quite make the mistake of saying this could be "simple" yet. Still a long way to go if we want to be able to print lowercase, but maybe I can get _sending_ lowercase done pretty quick.

(also hmm, where does it implement the "num lock" translation too? I see it's at the bottom of the table, ... hmm, more schematic prodding)
 
Dealing with MOVP3 is an essential part of any MCS-48 program. It's special because all other data has to be loaded from code on the same page, so with page 3 you can have a full unbroken 256 byte table. What surprised me was how pages 6 and 7 were set up. The data crossed the page mid-character, which is not a normal thing. I had to find both lookup code blocks to reassure myself that they were two branches of the same code flow.

I also thought it was funny when I looked at the schematic and found that the NUM switch simply forced both shift and ctrl.

Kinda seems a lot like this could be as simple as rewriting the scan code translation table
I think the main problem would be what you do about the keys that are "overloaded" for things like the curly braces, that already have something in all four shift/ctrl combinations. But it's cool that space for the lowercase bitmaps is already there, just remember to set bit 7 when appropriate. (it seems to be some kind of "we need more powah" hint when there are a lot of pixels set in that column)

It would also be cool to do something useful with shift-zero, since they kept the original TRS-80 layout with parens on 8 and 9. Using it as a shift lock could be a way to select a different encoding table with lowercase vs the standard one with special characters, maybe with the special characters moved to ctrl-digit. None of the digits have a ctrl mapping, so I guess you could do a key mapping like c1=| c2=~ c3={ c4=} c5=\ c6=^ c7=_ c8=[ c9=] c0=@ That covers all eight of the special char mappings plus two more that were missed.

There's plenty of space to patch it, all of pages 2 and F are empty, and a few more other smaller chunks. I think it's actually possible to upgrade it for lowercase once the key mapping problem is solved, and without getting too fiddly with details of how the code works.
 
It couldn't be that easy. Could it?

IMG_9206.JPG

... It could be. The keyboard appears to map some extended characters under Shift+Key combinations, like Shift+L = "\" (backslash), Shift+P (@), etc... which is like, ?? :D ?? Excuse me? Y'all wasted a huge opportunity!

I shoved those combinations up to Shift+Ctrl (Numlock, or just hold both buttons, to access the symbols formerly Shift+__), and clobbered over the standard (non-shift) with lowercase ASCII, and added uppercase to the SHIFT+ character set. I also added the missing characters tilde ~ to Shift+Ctrl+1, backtick ` to Shift+Ctrl+2, and pipe | to Shift+Ctrl+3 in order to, you know, be more *nix-console friendly. You can now transmit every character on a standard US keyboard.

It really was that easy. Those characters are still non-printable (it translates now both sent AND received lowercase to uppercase), but at least they can be transmitted now!

IMG_9207.JPG

Mod is attached. Consider it a first draft, as we might be able to get this thing to dance even more beautifully in the near future.

I wrote mine onto the original chip by erasing it first with a UV EPROM eraser (same vintage!), then reprogrammed it using a MiniPro TL866 programmer I've had for years.
 

Attachments

  • Lowercase - 80556803.zip
    2.4 KB · Views: 0
  • Like
Reactions: cjs
Wow, that's great progress! I have no doubt that adding the character bitmaps to the table along with the minor code changes to eliminate the translation to upper case will produce the desired results. This will be one of those milestone moments in retrocomputing history where something otherwise relegated to collector status will suddenly become a useful hobbyist device. Nice work!
 
Eh, it's still a 300-baud terminal that literally prints on paper and doesn't understand any but the most primitive control characters, so I wouldn't quite place myself on any throne... I just changed some bits. haha. Still though, it's good progress :)
 
IMG_9212.JPG

It also struggles a bit with double-printing parts of the buffer when data comes in fast, as well as some double line breaks. Did a lot of experimentation to get a print this clean - it tends to be a fair bit worse. The double-prints are basically unpredictable, can't tell if it's a hardware issue or software issue - I tried it at 110 baud as well as trying disconnecting the head-retract solenoid (in case it was causing spikes). Nothing changed the symptom of randomly reprinting part of the last line, or a blank line, when it reaches EOL.

For those that aren't familiar, that's a popular copypasta mixed with a popular meme, for the lulz.
 
There was a gap in the bitmap font table that directly corresponded to the lowercase characters of the ASCII character set. I am now convinced that somewhere along the development, someone said "no lowercase", a developer said "but--", "NO LOWERCASE", and the guy just rolled his eyes and said "fine" and took whiteout to a sheet of code that was already printing both lower and uppercase text... the whole ASCII table, in fact.

Yeah, so let's bring that back. I took a closely-matching font (that matched almost every bit of the existing font), and added its lowercase characters. The new character set fit exactly in the empty space in the map.

1707560563806.png

Now, the fun part: locate and patch the part of code that remaps lowercase to uppercase. The rest of the table is just a straight ASCII table. Just need to figure out where it's doing the substitution. Workin' on it...
 
Now, the fun part: locate and patch the part of code that remaps lowercase to uppercase.
I just found this:
Code:
L0A44:  MOV     A,R7            ; (R7 is char code)
        ANL     A,#0E0H         ; mask off high 3 bits
        JNZ     L0A4B           ; jump if non-zero (code >= 20H)
        JMP     L0AD5           ; jump if control code

L0A4B:  MOV     A,R7            ; check for lowercase
        ADD     A,#9FH          ; 9FH = 100H - 61H
        JNC     L0A5A           ; jump if A < 61H
        CLR     C
        MOV     A,R7
        ADD     A,#85H          ; 85H = 100H - 7BH
        JC      L0A5A           ; jump if A >= 7BH
        MOV     A,R7            ; R7 = R7 - 20H (convert to uppercase)
        ADD     A,#0E0H
        MOV     R7,A
L0A5A:
So basically just NOP out 0A4B to 0A59 should work. Or just the one byte at 0A59 if you're lazy.

How much work would it be to implement a secondary keyboard input/ps2 port? Just a thought.
Probably more work than it's worth. For one thing, there's really no free input pins, and I think the host has to keep watching a PS2 input. I suppose with a switch matrix from 14 (?) transistors, you could make a microcontroller fake the keyboard.
 
Last edited:
Back
Top