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

[VERAULT]

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.

Its more of a secondary option I had in mind as most folks are going to have bad keys as they turned out to be the single carbon pad key switches which are a huge pain to rebuild.

 

[FalconFour]

Incredible! They really did actually spend MORE bytes implementing a lowercase trap, than simply leaving lowercase intact. It cost extra bytes to remove bytes. What was that logic? All the space I used with the extra character set were simply blanks (gaps) in the ROM space - it cost nothing extra in its vintage. And to activate it, we just had to patch out some code - not even having to add any special lowercase handling.

Huge thanks to @Bruce Tomlin who I think deserves most of the credit here - without the disassembly and the analysis, I'd still be lost. I spent hours trying to trace through the code and was largely getting burned out (last night I was tracing R6 as the char code, largely - I'd pieced together where the UART CS pin gets asserted for data, but lost the plot as it went along).

Now, I just need to...


... to uhh, hmm. Hey, it was late at night. Counting pixels is hard.

One moment...



Great, that's a gorgeous g. Moving along...

I ran into a problem where the line-wrapping doesn't seem to work consistently - though any well-behaved terminal program ought to be aware of a default 80-column limitation, it does seem like this thing intermittently chooses to, or not to, wrap the line. Bug in the original ROM? Or just a newly created problem? I noticed it with the dashes (-) in the BBS print (from this video), it just slams the head past the 80th column and skips the motor. Weird! I'd think the limits would be more hard-coded. I also don't see any reason the code change should affect that (in my case, I jumped forward, hopefully compressing some cycles).



I'll check the original ROM and see if that happens there too. Of course this also opens the door wide-open to alternate fonts as well. In this case, I just tried to keep it as accurate as possible to the original.

(edit to add: right... the original ROM doesn't have this problem. It wraps properly every time. Hmm. OK, going to try a few different approaches. First, the "lazy patch", skipping the write back from A to R7...)

Anyway, here's the lowercase mod as it is now!

 

[Bruce Tomlin]

I think you need to squash the top of the 'g' down by at least one pixel if not two, it looks ugly.

I'm guessing they removed the lowercase because they didn't want to make the keyboard properly support mixed case without enough keys for the special chars. That's why I made that suggestion about putting all the special chars on ctrl-digit, which would free up all the alpha keys at the cost of the key caps being incorrect. I'm just glad they used a microcontroller with external ROM or we wouldn't have gotten anywhere. I'm putting a conditional in the source that I'm working on which will do the lowercase patches, I just need to do the keyboard maps.

As for bugs with line wrapping, I wouldn't be surprised. It's pretty tangled code, with lots of obvious in-place detour patches, rather than re-assembling from source. I'm sure that means they probably hand-assembled the code, with only a romulator or minimal ICE for debugging.

It wouldn't be their only thing with a bug. I know for sure (from having one back in the day) that the Line Printer VIII had a bug where when it times out and tries to print what it has buffered up, it does not move the print head to where it should be from the blanks in its buffer. But I checked its service manual, and it has an 8085, so it should be interesting to try fixing that code.

 

[FalconFour]

Indeed. I fixed the G - it was an error in the font translation I did. The proper font still has the "g" awkwardly high-sitting, because the descender has no lower pixels to drop to - the whole character sits up a bit over the others. It was just too far up the first time

I'm wondering if they're implementing the column counter as a timer somewhere, where somehow the timing got all messed up by not following the same path, but honestly, I have a real hard time following this code so it's likely I just have no idea.

Anyway, the lazy patch works perfectly! And it fits the theme of spaghetti.



It's done. It's beautiful.

Go buy some stock in companies that make fax machine thermal paper rolls, because it's about to pop off.

 

[Bruce Tomlin]

Okay, this should probably work. It's got the lowercase patch and a remapped keyboard to allow lowercase by default.

Probably @ should be moved to :* or ;+ (which don't have a ctrl assignment), then shift-0 set to be a caps lock, but that would require some actual code changes.

 

[Amardeep-AC9MF]

Nice work, fellas! I suspect it was a marketing requirement to make it upper case only. Very likely they didn't want to hurt the sales of some other product(s) in the catalog. Possibly printers.

 

[Bruce Tomlin]

I've done a lot of changes to my disassembly today, and probably not going to do much more for a while, so I'm uploading what I've got so far.

 

[mbliss11]

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.

I did a similar repair to my model 3 keyboard little over a year ago. Unfortunately, most of the keys have reverted back to being nonfunctional :/ I am going to attempt another repair using aluminum tape and a punch to make new contacts (saw a video of someone using this method). Hoping that this will be a more permanent fix for the keyboard.

Keep an eye on your keyboard after a bit you may need to crack all of them open again. Was a pain the first time it’s going to be a pain this time too

 

[VERAULT]

I did a similar repair to my model 3 keyboard little over a year ago. Unfortunately, most of the keys have reverted back to being nonfunctional :/ I am going to attempt another repair using aluminum tape and a punch to make new contacts (saw a video of someone using this method). Hoping that this will be a more permanent fix for the keyboard.

Keep an eye on your keyboard after a bit you may need to crack all of them open again. Was a pain the first time it’s going to be a pain this time too

you need carbon paint. These key switches fail from corrosion and they lose theier carbon. Once the switch is cleaned up a dot of carbon paint fixes them right up.

 

[FalconFour]

I just had some more fun with it today. Hooked it up to my Macbook, and with some terminal magic:

1. Open Terminal, screen /dev/tty.usbserial{tab} 300 (tab to fill-out the USB ID specific to your adapter)
2. Within screen, you should now be able to type and have it appear on the PT-210, and vice versa; set switches appropriately until it works
3. On the Mac, press Ctrl+A and type colon :
4. On the Mac, type exec ::: /usr/libexec/getty std.300 (exactly matching spaces). A login prompt will now appear on the PT-210.
5. Log in (Return as Enter), and then on the PT-210, type export TERM=dumb and press Return.
6. You now have a functional "dumb" terminal. Go play!

The "/usr/libexec/getty" pipes a shell session into the "screen" session at 300 baud. The "export TERM=dumb" tells the shell session, and everything running from then forth, to treat the terminal as "dumb", i.e. not to use any control characters (like [-codes).

To exit, on the Mac, press Ctrl+A, then "k" to kill the attached terminal, and then Ctrl+A and "k" again to kill the serial connection.

I was able to briefly "do work" and connect to a remote system, run some usual "work" commands, much to the delight of my flabbergasted coworkers. Quoth one of the infrastructure nerds, "what're we gonna do with you?"

Great fun - apologies to Lorax for the wasted paper! I picked up a 6-pack of thermal fax paper rolls at the Staples nearby - just hanging out on the shelf, located a store online that had them. The remains of the 40-year-old spool will stay unused for now.

Next, I need to figure out if I can add Tab as a control character (tab to autocomplete commands) - should be pretty simple; I hadn't even examined lower ASCII character mappings.

 

[VERAULT]

Any chsnce we can get some inside the terminal photos of you seapoing out The rom?

 

[desertrout]

I just had some more fun with it today. Hooked it up to my Macbook, and with some terminal magic:

1. Open Terminal, screen /dev/tty.usbserial{tab} 300 (tab to fill-out the USB ID specific to your adapter)
2. Within screen, you should now be able to type and have it appear on the PT-210, and vice versa; set switches appropriately until it works
3. On the Mac, press Ctrl+A and type colon :
4. On the Mac, type exec ::: /usr/libexec/getty std.300 (exactly matching spaces). A login prompt will now appear on the PT-210.
5. Log in (Return as Enter), and then on the PT-210, type export TERM=dumb and press Return.
6. You now have a functional "dumb" terminal. Go play!

The "/usr/libexec/getty" pipes a shell session into the "screen" session at 300 baud. The "export TERM=dumb" tells the shell session, and everything running from then forth, to treat the terminal as "dumb", i.e. not to use any control characters (like [-codes).

To exit, on the Mac, press Ctrl+A, then "k" to kill the attached terminal, and then Ctrl+A and "k" again to kill the serial connection.

I was able to briefly "do work" and connect to a remote system, run some usual "work" commands, much to the delight of my flabbergasted coworkers. Quoth one of the infrastructure nerds, "what're we gonna do with you?"

Great fun - apologies to Lorax for the wasted paper! I picked up a 6-pack of thermal fax paper rolls at the Staples nearby - just hanging out on the shelf, located a store online that had them. The remains of the 40-year-old spool will stay unused for now.

Next, I need to figure out if I can add Tab as a control character (tab to autocomplete commands) - should be pretty simple; I hadn't even examined lower ASCII character mappings.

This is timely! I've been poking at this for a couple weekends using screen/getty now, and can log in and use unix commands on my Mac via a variety of machines (none of them actual terminals; an Apple IIc using ProTerm, and a Toshiba T1100 Plus using Kermit 3.16), but I've got consistent issues I can't figure out:
- characters on the Mac are doubled (not that this really matters as commands are being executed as expected, unless it's symptomatic of an underlying problem)
- once I log in through the dumb terminal, I stop seeing characters on the terminal... it's fine while I'm logging in, but not after. No characters appear, sometimes new lines do

I've tried different baud rates and confirmed the other settings, played around with others, and this is the closest I can get. Is there something else on the Mac side I should be looking at?

 

[cjs]

- characters on the Mac are doubled

I'm not sure what "characters on the [host] Mac" means.

- once I log in through the dumb terminal, I stop seeing characters on the terminal... it's fine while I'm logging in, but not after. No characters appear, sometimes new lines do....
Is there something else on the Mac side I should be looking at?

Yes. Run stty -a, carefully examine the output, and understand what each setting currently is and what it does based on the stty(1) manual page. You'll also want to be looking at settings such as "local echo" on your terminal communications software.

 

[desertrout]

I'm not sure what "characters on the [host] Mac" means.

It means for every character typed on the terminal, the character is doubled in getty (e.g. if I type 'hello' into kermit on the Toshiba, 'hheelloo' appears in the Terminal window on the Mac).

Yes. Run stty -a, carefully examine the output, and understand what each setting currently is and what it does based on the stty(1) manual page. You'll also want to be looking at settings such as "local echo" on your terminal communications software.

Will do - thanks.

 

[cjs]

It means for every character typed on the terminal, the character is doubled in getty (e.g. if I type 'hello' into kermit on the Toshiba, 'hheelloo' appears in the Terminal window on the Mac).

Yeah, this is what's quite confusing me. getty is a program that runs on a terminal connected through three file descriptors: stdin (0), stdout (1) and stderr (2). Those could be connected to the serial port talking to Kermit, or to a "pseudo-tty" connected to a terminal window. But you seem to be talking about having two separate terminals here, Kermit on your PT-210 and a terminal window in your Mac GUI. Yet they are connected somehow?

So, e.g., when you run getty /dev/ttyUSB0 or similar, it will print to stdout a login prompt that will be sent out that (USB) serial port, and characters coming in that port will appear on stdin and be read by getty. (Presumably it will eventually get a successful login and exec a shell, which will also be reading from the same stdin and writing to the same stdout and stderr.) So why would any of these be appearing on a completely separate tty for a terminal window started in the GUI?

 

[FalconFour]

In my case, "solve all serial interface problems first" is a must. Start with a dumb terminal on both sides - one that, when you type characters, simply sends them over serial to the other side - and shows back to you what comes to the serial terminal. In the embedded world, this is a core function of UART terminals - the device will give you an interface over the serial terminal, and it's the terminal's job to just print what comes to it and send what you type. You should never see your own characters echoed-back to you when pairing two dumb terminals together. The PT-210 has a "half/full" switch that makes this happen ("half" mode) and it should be disabled (switched to "full") in the modern age.

OK, so about that ROM chip! I found a typo in my character map, so I took the opportunity to fix it while taking photos.


Start with the front screws - remove the handle, which are also the front case screws. They are Philips #2 head.


Remove the back case screws. They, too, are Philips #2.


There are 4 notches around the case, which are good for a small flat screwdriver to gently insert and pop the latches apart. On mine, it opens with a very satisfying click on each. It only takes 2 of the 4 corners to pop it open.


After opening the cover, hold/rest the cover aside and disconnect the modem acoustic coupler connectors. They're keyed and uniquely sized, so you can't put them in the wrong way or on the wrong connector. Unless you really try to mess it up.


The EPROM chip (remember kids: one E = "erasable" but two EE's = "electrically erasable" - you're gonna have to work to erase a single E through the window! E has a window; EE has no window, typically) is located under the printer mechanism on the main logic board.

(oops! I can only attach 10 files? Better hurry up! haha)



I use a thin, long handled flat blade screwdriver to work at applying even, direct upward leverage around the chip, through the space I have here, careful as not to bend the legs. The chip pops out, I fish it out. And on the return trip, I ensure all the legs are perfectly straight, then lay the chip over the socket's pins (ensuring none of them are caught on the rim of the sockets to be bent), and press down to seat it. Neat, they seem to have used a machined-pin socket here - peak quality.

Finally, I nuke the chip in an EPROM eraser... (I give it about 5-10 mins... effective at probably around 2min; suggestions are welcome)


And reprogram it with my MiniPro. I perform a "blank check" first, then set the program voltage to 21v (I have no idea how accurate it is, but it often seems to need to be maxed out). It seems to take a long time to do the first program pass, but I do a couple more passes for good measure (which go quicker - not sure why; maybe it sees that it's already valid and skips it?).


The whole process goes pretty quick once you've been through this rodeo a few times in your life. haha

 

[VERAULT]

Perfect thank you! I am pretty surprised they included a machine pin socket but the quality on this machine really shines through. What years was this model sold, does anyone know?

 

[FalconFour]

Oh! And about that typo... when keying the uppercase set in a dazed "this can't possibly be this easy, could it?" rush, I accidentally typed "TUVWZYZ" instead of "TUVWXYZ". So the uppercase X printed an uppercase Z instead, when using the keyboard input (serial input was of course unaffected). Anyway, one byte fixed, and this is my final answer for the moment.

Character map is simply "shift behaves as expected" plus "we don't need a numpad, so Ctrl+Shift = most of the alt characters on shifted letter keys". Some of the numpad assignments remain, where there were no shift-assigned special characters. Just didn't think it was worth nulling-out the existing numeric assignments. Lastly, Ctrl+Shift+1/2/3 (maybe 4?) map to previously-unkeyable characters like ~ ` and | . Amusingly, I also found that Ctrl+A...Z assign to lower ASCII characters - like Ctrl+I = 0x09 = TAB character! That was there from "stock", just there to be discovered. The whole lower-bit map corresponds to Ctrl+A (0x01) to Ctrl+X (0x1A) and then Esc (0x1B), < = > ? corresponding to 1C, 1D, 1E, 1F -- for whatever those characters may be worth.

 

[desertrout]

Yeah, this is what's quite confusing me. getty is a program that runs on a terminal connected through three file descriptors: stdin (0), stdout (1) and stderr (2). Those could be connected to the serial port talking to Kermit, or to a "pseudo-tty" connected to a terminal window. But you seem to be talking about having two separate terminals here, Kermit on your PT-210 and a terminal window in your Mac GUI. Yet they are connected somehow?

So, e.g., when you run getty /dev/ttyUSB0 or similar, it will print to stdout a login prompt that will be sent out that (USB) serial port, and characters coming in that port will appear on stdin and be read by getty. (Presumably it will eventually get a successful login and exec a shell, which will also be reading from the same stdin and writing to the same stdout and stderr.) So why would any of these be appearing on a completely separate tty for a terminal window started in the GUI?

I'm going to start a different thread in a more appropriate place.