Terminal program that handle reader run signal?

[MattisLind]

Is there a terminal program that can handle the reader run signal and send just one character per reader run pulse? The reader run signal can be connected to the DSR signal.
I think I have read that someone had such a program but I cannot find it now.

 

[NeXT]

On a teletype machine?
I was under the impression it's CTRL + S and CTRL + Q (XON/XOFF)

 

[gnupublic]

Wasn't that GTTY (HERE)? But only together with a modified tty card? ((Modification).

Have fun,
Volker

 

[djg]

Is there a terminal program that can handle the reader run signal and send just one character per reader run pulse? The reader run signal can be connected to the DSR signal.
I think I have read that someone had such a program but I cannot find it now.

Its not really the terminal program. Any terminal program that can handle hardware flow control will work. The serial adapter is more the issue. I've had good luck with USB serial adapters. The one I normally use is pl2303 trendnet TU-S9.

It was a long time since I've looked at the details but memory is the standard PC serial port has a FIFO but doesn't directly handle the flow control so needs driver to stop sending. The delay causes multiple characters to be sent.

 

[Dare]

Not exactly what you're asking for, but I did implement support for READER RUN in my PDP-11/05 Console USB Adapter.

With READER RUN tied to DSR I suspect you could pretty easily create such a program in Python using the pySerial library.

 

[vrs42]

Wasn't that GTTY (HERE)? But only together with a modified tty card? ((Modification).

Have fun,
Volker

I thought so, though I have to admit I haven't tested the flow controlled mode very thoroughly.

Vince

 

[MattisLind]

Thanks for all input!

It was the GTTY program I was looking for. Let's see if that solves my problem.

I tried to use the flow control option in Realterm but wasn't very successful. Perhaps I was doing something wrong? But what I wanted was that it only used the flow-control when I was sending a file. Not when I was just using the terminal for entering commands and such.

I have a FTDI dongle and it appear to be able to sense the DSR signal which I currently have been trying to use. I could try to use CTS if that would make any difference.

Much like the Console USB adapter that Dare designed I have been contemplating using a microcontroller that reacts to the reader-run signal and emits characters form a small SD-card or similar. I really like to have a stand alone box that could juggle a bunch of virtual tapes while still using my good old TTY for console.

 

[Dare]

Teensy 4.0/4.1 has multiple UARTs plus a USB host interface. Teensy 4.1 also includes a SD card socket. So you could set up the UARTs to pass characters back and forth between the console and the TTY by default. Then, when the user plugs in an SD card, or a USB flash drive, the system switches into READER RUN mode and feeds characters from a file on the drive. Extra credit: automatically display a menu on the TTY to select the file to be sent.

OR, use a Teensy 4.1 with an Ethernet port, and have it switch to READER RUN mode when you TFTP a file to it over the network.

Actually sounds like a fun project.

 

[MattisLind]

I am mostly used to the STM32 chips so I will probably use onevof those. A STM32F103 has three which is perfect.

That menu idea is really good. I was thinking that it will print the menu automatically whenever it senses the reader run signal. The menu displays all files on the SD-card and then one extra option for pass through if I want to use the TTY to feed in the tape.

An extra feature would be to be able to store the file in pass-through mode as a file on the SD-card.

 

[Dare]

I was thinking that it will print the menu automatically whenever it senses the reader run signal.

That would be slick. I guess you'd have to decide when to exit the send mode, in the event that the system didn't consume the entire tape. Maybe after a certain amount of time with no READER RUN signal.

one extra option for pass through if I want to use the TTY to feed in the tape

In this case are you thinking of a TTY with an actual paper taper reader, or a terminal program running on a computer? If the latter, you could implement XMODEM or Kermit which would make it straight-forward to use with many terminal applications, and give you a clear indication on the device of when the tape transfer was complete (not to mention some level of reliability).

For those of us with 11/05s it would also be great if the device supported external baud rate generation like my console adapter.

Again, fun to noodle on.

 

[djg]

That menu idea is really good. I was thinking that it will print the menu automatically whenever it senses the reader run signal.

On 8's reader run is active for any input including normal command input. Don't know what 11's do.

 

[davidrg]

C-Kermit for Windows might work given suitable serial hardware. Its based on Kermit 95 which is based on C-Kermit for OS/2 so it was being actively developed and sold commercially when all sorts of weird serial connections were still in active use.

 

[Chuck(G)]

I run my paper tape reader with an STM32F103C6 (the 32K flash, 10K SRAM version--the cheapest "blue pill" I could find at the time--about $1) Works fine with USB--no FTDI intermediary involved.

 

[jlang]

You will need to do something other than CTS DSR handshaking. Most (all?) UARTS or serial ports are double buffered.
This makes sending a single character problematic. The transmit empty bit will set before the receiving device can negate reader run.

You can put a delay after sending one character to give the receiver time to negate reader run.
Or use a GPIO to sample reader run.
Transmit a character when reader run asserts then loop waiting for reader run to negate then go back to waiting for reader run to be asserted.

joe

 

[daver2]

It depends upon the UART device.

In some UARTS it is a status bit only. In other UARTS it is sampled before transmitting a byte of data by the UART itself, so the internal buffering should be inconsequential.

Dave

 

[vrs42]

You will need to do something other than CTS DSR handshaking. Most (all?) UARTS or serial ports are double buffered.
This makes sending a single character problematic. The transmit empty bit will set before the receiving device can negate reader run.

You can put a delay after sending one character to give the receiver time to negate reader run.
Or use a GPIO to sample reader run.
Transmit a character when reader run asserts then loop waiting for reader run to negate then go back to waiting for reader run to be asserted.

joe

I don't quite see how that would matter. I don't care if the output is buffered in the UART chip or is still on the host system. As the receiving "UART", I only care that the sending UART honors the requested hardware handshaking, rather than over-run my input buffer.

"Changing tapes" will presumably require a way to discard the pending output from the sending UART, along with any unsent host buffers.

Vince

 

[djg]

As the receiving "UART", I only care that the sending UART honors the requested hardware handshaking, rather than over-run my input buffer.

That's the problem with some UARTS such as the standard PC serial port. It has a hardware FIFO in the chip for transmit and receive but doesn't handle the flow control directly. The chip continue to send the data in the FIFO no mater the state of the hardware flow control signal. The computer has to get the signal state change interrupt and act on it to stop sending data. Not sure if it can stop the data in the FIFO going out. You can disable the FIFO but its still double buffered for transmit so it will send the character in the buffer register after the current character finishes transmitting. Standard OS drivers are written for low overhead not quick response to flow control.

 

[vrs42]

You can disable the FIFO but its still double buffered for transmit so it will send the character in the buffer register after the current character finishes transmitting. Standard OS drivers are written for low overhead not quick response to flow control.

That would seem to imply that hardware flow control is broken almost everywhere, and the world is compensating with big input buffers. No wonder folks complain that their VT100 terminals don't work.

Then I agree with jlang, what is probably needed is a gizno with a large input buffer, that can bit-bang a properly working UART that actually understands flow control on the PDP end. I'm not sure how to properly inform it about "flush" events, though. Perhaps DTR or CD can be used to signal "connection OK", and the flush for tape change can be done by essentially "hangin up".

Why, in this day and age, are there not UARTs that do flow control?

Vince

 

[djg]

Why, in this day and age, are there not UARTs that do flow control?

Their are. The 16554 does flow control in hardware. Haven't looked at the details on too many to see what common non IBM PC ones do now. The USB serial adapter I use seems to do flow control quickly which I assume is in the device. Don't think I checked if it stops before sending the next character but it worked for what I needed.

 

[MattisLind]

On 8's reader run is active for any input including normal command input. Don't know what 11's do.

Do you mean from a software point of view? Is that true for all 8 operating systems there is or just OS/8? Does this imply that as soon as you enable the reader on a ASR33 will start try to read a byte from the paper tape as you are entering commands? So there is no way of copying a paper tape on the ASR33 reader to a some other device?

From a hardware point of view the pdp-8 and pdp-11 is behaving the same. The Reader run flip-flop is cleared after power up and then on first bit of incoming read data. The flip flop is set by either an instruction in the 8 or writing a 1 to bit 0 in the RX CSR. My Intel Intellec 8 (which is my target application for this device) is behaving identical.

PDP-11 (KL11):

PDP-8 (KL8 / M865)

Intellec 8:

The Intellec 8 is not cleared at power up otherwise they essentially behave the same.

If the pdp-8s always keep reader run enabled it has to be re-enabled directly after reading a character. On a PDP-11 with M9301 board you can boot from the TT device which I think means that you put tape in the reader and press TT at the prompt and then it reads the tape. Since my ASR33 is not yet operational I haven't verified this yet.

The Intellec 8 monitor enables the reader only directly after commands that is supposed to read from the paper tape device. While waiting for the reader to get active it is sending endless loop of reader-run pulses, so for the Intellec 8 printing a menu on the ASR33 giving the operator a choice of selecting a file to upload to the Intellec 8 would work just fine.