Televideo PT100 Terminal needs help, RS232 data can be received but not sent. Search Schematics

[IMSAI-Micha]

Hello, my name is Mikel, I'm also new in this forum . I'm in my mid-50s.

I just like old technology and especially terminals with baud rates of 300 to 19200 baud.
I recently bought a used TeleVideo PT100 Personal Terminal.

Unfortunately, it doesn't work properly anymore.
The keyboard itself works wonderfully. I also connected a WiFi modem for testing and data reception at 2400 baud also worked.

But every time I press a letter on the keyboard, the PT100 immediately freezes.
But only when I output data on the RS232 interface. As long as I'm in the parameter menu, every key can be pressed normally.

The 3V battery is of course empty (but I assume that this only saves the parameters when it is turned off)
I then tested the 6116 RAM with a chip tester. This RAM IC is OK.

then there are the RS232 ICs, the ICs U6+U7+U10
(as DS1489 and DS1488).
I thought that the DS1488 might be defective because it is responsible for data output.
I replaced U6+U10 (as they already had a socket), but unfortunately nothing changed.

There is another SRAM IC, SRM2016C12. I have just ordered this as a spare part.
Hence my question, does anyone know more about this device, and I am looking for the circuit diagram as schematics.


I am slowly running out of where to look: It is also not that easy to measure the operating voltages,
as the keyboard is sensitively wired and you have to turn the board over.
Otherwise I also have an oscilloscope here.

Thank you an greetings
Mikel

 

[Steve Toner]

What do you mean when you say it freezes? Can you provide more detail here?
My initial guess (and it's only a guess) is that you have it configured for hardware flow control (SET UP>COMM>PROTCL = DTR instead of X-ON).

There's a user manual for it here: https://drive.google.com/file/d/18qrZFRLbBO9y4jGV-K3McjFOG7Ek8Lw3/view
but I don't know of any place to find the schematics.

 

[NeXT]

Yeah I'm curious if it's hanging up on something like flow control being turned on when it's not needed.

 

[IMSAI-Micha]

I can rule out flow control software. It is 100% a hardware problem.
Otherwise I should at least be able to access the parameter menus using the function keys.
When it freezes, you simply can't do anything else.
No input is possible and no screen changes are possible.
As if the CPU processor stopped.
I suspect that the moment the serial interface wants to "output" something, a kind of short circuit occurs.
I suspect the driver ICs for DS1488 and DS1489.
What I also don't understand is why two DS1489s are installed?
I would have assumed that you need a DS1488 (RS232 output) and DS1489 (RS232 input) for the Main-RS232.
And a second DS1488 for the RS232 printer, which only outputs?? (the way PT100 to printer)
Perhaps it is simply incorrectly installed? the ICs look like they have been changed with the socket.

Can you please give me a photo your PT100 board where you can see these three ICs in the corner?


You can also see that the unsocketed IC is an MC1489, I hope the MC1489 and DS1489 are directly comparable when interchangeable?

Thank you very much

 

[NeXT]

Have you for the sake of simplicity just made a loopback to connect Rx and Tx at the serial port and tried typing things to see if it bounces back or still hangs?
What's got me curious is it's only happening in terminal mode and nowhere else.

 

[IMSAI-Micha]

Yes, I have connected 2+3 TX+RX.
Nothing comes out. (or nothing comes back) As soon as I press a button, it freezes:

I have now ordered MC1488N, maybe DS14C88N won't work. Apparently someone tried to replace them:
I'll take another closer look at the sockets for soldering errors.

 

[Steve Toner]

Have you tried continuously outputting data to the terminal and then pressing a key? Does the screen continue to update in that case? Is that what you mean by "no screen changes are possible," or does that just mean you can't get to the configuration screens?

1488 and 1489 are just level translators. They seem unlikely to be the source of the problem unless the terminal is configured for hardware flow control (DTR option). I'd be more inclined to suspect bit rot in the EPROM if it really is completely frozen...

 

[daver2]

Welcome to VCFED, as these are your first posts.

You will be under moderation until you have achieved 10 posts...

I agree. Hardware flow control is probably your first issue to rule out.

You have probably answered your own question regarding the extra 1488 and 1489 devices. They are probably RS232 level buffers fir the hardware handshake lines.

Yes, the MC and DS parts are compatible with each other. The first letters indicates the manufacturer.

Dave

 

[IMSAI-Micha]

Thank you very much for your efforts and patience.

Receiving data from external sources to the PT100 works, and as long as I don't press any key on the PT100 (for its own output) (except the menu keys, which work), it works for a long time without any problems. it send now 9kBytes of text from my laptop as ASCI-text to the PT100.
(even if I want to go back to the parameter menu, that works during reception).


But if I press any key "to output" the TX signal (from the PT100) in FDX or HDX Mode, (NOT Block-Mode) , the PersonalTerminal stops.
I can then no longer access the menus using the function keys.


I suspected that the level translator might be swapped or that perhaps (due to a defect) the -12V, for example, is coming to +5V?
YES, I would like to check the EPROM, but so far I haven't found anyone who could give me the contents to compare.

Thank you very much..

 

[IMSAI-Micha]

I am a new forum user, so my answers are always checked by an admin before they are shown, which is OK.

This means that my answers can sometimes be read a few hours later, please bear this in mind.

Thank you, according to my time zone I am going to sleep now too.. good night and thank you

 

[daver2]

You can measure the voltages on the 1488 and 1489 devices (against the data sheets) to ensure that (a) the voltages are within specification and (b) this will confirm whether the devices are in their correct sockets.

The 1488 is the driver (and has two supply rails). The 1489 is the receiver (and has only one supply rail).

For goodness sake don't swap the ICs around as an experiment, as you will damage the 1489 devices!

You still have not answered the question regarding the RS232 hardware handshake lines (RTS, CTS, DTR, DSR, etc.). This is not related to the XON/XOFF or full/half duplex configuration.

I assume your connector is a 25 way connector.

I would make up a dummy loopback plug consisting of the following links:

2-3
4-5
6-8-20

If that doesn't work, you likely have a problem with the terminal itself. But it should now be possible to test the RS232 buffers in circuit.

What test equipment do you have?

Dave

 

[Steve Toner]

OK, I opened mine up and here's what I know:
Mine is an earlier version - Rev B ROM dated 2 6 84 instead of Rev G. I'll try to dump it anyway, but don't expect it to match yours (and it may not even work properly in your terminal, as mine does not have that 132280 board).
The processor is U5, a National Semiconductor NS455 Terminal Management Processor. It contains the CPU, UART (only 1?), character generator and CRT controller all on a single 48-pin chip. An easy test would be to swap that out for another one, but good luck finding one.
The arrangement of 1488 and 1489 chips matches yours, but mine are not socketed.
My battery is good. It's a BR2325 and measures 3.0V. I have no idea when it was installed, as I had no idea the terminal even HAD a battery until I saw this thread.

The behavior you're described sounds to me like either the processor is in a tight spin loop waiting on the UART to become ready, or it has branched to some random code address when attempting to transmit the character. Probably with interrupts disabled in either case, as the receive process (I'm assuming this is interrupt driven) stops working... That makes me suspect either the processor (U5) or the EPROM (U1) as the most likely failure points, but not the RS-232 driver/receiver chips.

I'm off on other projects for the rest of the week, so probably won't be able to do any more on this until next week. But I'll try to get the EPROM dumped and posted this evening, in case that helps.

 

[Steve Toner]

Here are the ROM files from my Televideo Personal Terminal. Same file, 2 encodings: binary and hex. The EPROM is a 2764...

 

[g4ugm]

I was going to say flow as well! I would expect the menu keys to lock ... I´ll check the firmware in mine, but it will be next week as I am on holiday.

 

[IMSAI-Micha]

Thank you for sending me your EPROM.
I burned it into a 2764 and tested it.
The PT100 behaves in the same way as with my EPROM.
For comparison, I have attached my EPROM contents. It is also different, but not the problem.

I will now continue to check the output around the interface for short circuits.

I have just noticed that the computer is no longer accepting any inputs, I can no longer access the parameter menus,
but the cursor continues to flash.
I assume that the output module is "hanging":
I imagine the connection of the 1488/89 to be the same as Sander Wendell did with his card (picture below)

Is there a circuit diagram for the device?

 

[daver2]

Reading the user manual (referenced in post #2), and looking at the 'H' status display (in the first picture of post #1) indicates that your problem is related to the hardware handshake lines.

The manual indicates that the RS232 connector pinout is fairly bog standard.

It looks like you can configure the terminal -> computer handshake to be either hardware and/or software (XON/XOFF) but I see nothing about the other way (computer -> terminal).

Looking at the fault diagnosis and correction section it identifies an 'H' status as being 'the host computer is busy and cannot receive any data from the terminal right now' - check the cable between the computer and terminal.

I suggested making up a basic RS232 loopback connector. But, if you have not tested the terminal with that dummy connector, I don't think you will get anywhere.

The status line could indicate what the problem actually is - so use it.

However, if the terminal is now somewhat more dead than it was, you will have to backtrack what you have done so far to see where the problem was introduced.

Dave

 

[IMSAI-Micha]

I assume your connector is a 25 way connector.

I would make up a dummy loopback plug consisting of the following links:

2-3
4-5
6-8-20

If that doesn't work, you likely have a problem with the terminal itself. But it should now be possible to test the RS232 buffers in circuit.

What test equipment do you have?

Yes it try it,.. no data loopback from own data!

Hello Dave,
equipment: I also have digital voltmeters, fast digital oscilloscopes and I trained as an electronics technician 40 years ago.
My problem is not that no data comes out of TX, so the hardware handshakes are irrelevant anyway.

In addition, receiving also works perfectly (regardless of whether it is 2400 baud or 9600).

Anyone who has a personal terminal will certainly confirm that they can always get back to the parameters using the F keys, regardless of whether they can send data or not, i.e. regardless of the hardware (or software) handshake.

I can also set 2400 baud and the other PC 9600 baud.
Then the two devices cannot communicate but I can still press F5-F7 and change settings.

Here the PT100 simply freezes.

At the moment, a photo of another PT100 with the 1488 and 1489 and the capacitors in the area would help me.
Or even better, a proper schematic

I'll keep looking... if i had a second working device, you could quickly find the error by process of elimination.
At least now I know that the EPROM is innocent.

I'm now going to desolder the capacitors on one side and measure the resistance (short circuit) and check the values with a capacitor measuring device.

 

[daver2]

If you have an oscilloscope, you can check the transmit signal (from the output of the UART) and ascertain if the signal is there. You can then move through the circuitry in a logical manner.

You can do the same for the hardware handshake signals - do you get the correct signal at the input/output of the 1488 and 1489 buffers.

If the hardware handshake is faulty (and the terminal constantly senses that the host computer is 'busy') then the terminal will not send a character to the host computer anyhow - so you cannot necessarily determine whether it is the hardware handshake or the transmit signal that is faulty without checking the hardware handshake signals first...

Dave

 

[IMSAI-Micha]

yes.. I want to do all that..

but I need a schematic for that because the UART is not known in this device.
Nevertheless, the computer freezes, which it shouldn't. So it has nothing to do with the settings.

The simplest mistake would be if the previous owner swapped 1488 and 1489 when installing it, which is why I want a picture of another device because I don't have a circuit diagram of the board.

 

[IMSAI-Micha]

since I don't have a schematic, I measured signal from behind.

Pin3 of the SUB-D25 (RXD) of the PT100 goes to pin 1 of the MC1489, as in the example of the Apple1 serial card.
(so the IC 1489 is in the right place )


Pin2 of the SUB-D25 (TxD) as transmitter of the PT100 goes to pin 8 of the MC1488, so the TxD signal from the PT100-UART probably comes to PIN 9 or PIN 10.

What I still don't understand is why the PT100 has two MC1489 and only one MC1488 ?
(I think, the PT100 need a driver (1488) to control the PRINTER and not a receiver (1499) ?)

Without the schematic and the solution, I will probably only be able to use the beautiful device as a "display" monitor and unfortunately won't be able to use the keyboard. (as long as the error persists)...