• Please review our updated Terms and Rules here

Terminal program that handle reader run signal?

MattisLind said:
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?
Click to expand...
Yes. Reader run is really TTY receiver empty. Their is no separate IOT that you can use to control it. Its set when you read the character out.

MattisLind said:
So there is no way of copying a paper tape on the ASR33 reader to a some other device?
Click to expand...
That works fine. You don't turn the reader on until the PDP-8 is ready to read the tape. I've used PIP to copy tapes to disk.
 
MattisLind said:
Do you mean from a software point of view? Is that true for all 8 operating systems there is or just OS/8?
Click to expand...
There are basically two instructions to read a character. KRS reads the character, but does *not* fetch the next, and later reads will re-read the same character. KRB will read the character and initiate a fetch (with reader run) of the next character. Subsequent reads after KRB are undefined, until the next character is fully assembled in the TTL UART.

Technically. KRB is "KCC KRS", which is to say it does KCC to fetch the next character and KRS to read the current character, at the same time.

Most input loops are coded with KRB, and as a practical matter reader run must togg;e for every character in every PDP-8 program.

Vince
 
djg said:
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.
Click to expand...
Hmm. The 16554 has it, but apparently the 16550 doesn't, which means the 16554 isn't just a quad 16550-style UART.

I also found this, for modern FTDI USB-to-serial chips:

"If CTS# is logic 1 it is indicating the external device cannot accept more data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer."

Vince
 
vrs42 said:
Most input loops are coded with KRB, and as a practical matter reader run must togg;e for every character in every PDP-8 program.

Vince
Click to expand...
Aha. Now I understand. A PDP-11 need to set bit 0 of the RXCSR to enable reader run.
I guess that it is done only when needed.

For the PDP-8 perhaps sending BREAK could be used for displaying tha menu rather than the reader run signal.
 
MattisLind said:
For the PDP-8 perhaps sending BREAK could be used for displaying tha menu
Click to expand...
PDP-8's don't officially support sending BREAK. I think for at least some of the interfaces repeatedly writing to transmit while the current character is being sent can be used to generate a break.
 
daver2 said:
So 'modern' is not necessarily 'better'...

Dave
Click to expand...
Well, 3 characters isn't *that* bad for worst case. Applications involving leader-trailer might be OK with the hardware dropping up to three characters. (The BIN loader comes to mind.)

Certainly a POSIX application responding a a CTS event would be hard pressed to stop output anywhere near that soon.

Vince
 
If you look at the manual for the Zilog SCC you will see that the /CTS input pin can control the transmitter itself (providing Auto Enables for the transmitter is active).

This means that no software is actually involved in handling /CTS. The software can also read the status of the /CTS pin if it wishes before outputting a byte - but the actual transmitter control signal is /CTS.

Dave
 
daver2 said:
If you look at the manual for the Zilog SCC you will see that the /CTS input pin can control the transmitter itself (providing Auto Enables for the transmitter is active).

This means that no software is actually involved in handling /CTS. The software can also read the status of the /CTS pin if it wishes before outputting a byte - but the actual transmitter control signal is /CTS.

Dave
Click to expand...
Cool. I thought this would be the obviously correct thing -- to move the control into the UART chips as a harware feature, with enable bits controlled by software. The last thing you'd want is to burden the host CPU with yet more interrupts about trivial events, especially if it isn't possible to do anything useful about them. Apparently most of the world went in a different direction.

Vince
 
djg said:
PDP-8's don't officially support sending BREAK. I think for at least some of the interfaces repeatedly writing to transmit while the current character is being sent can be used to generate a break.
Click to expand...
The idea was not that the PDP-8 should send the BREAK. Rather that the ASR33 send the break and that it is filtered by the device and the device return the menu to the ASR33.
 
MattisLind said:
... I have been contemplating using a microcontroller that reacts to the reader-run signal and emits characters form a small SD-card or similar.
Click to expand...
Are you thinking of building a custom board for this? I ask because I wonder if it could be designed to subsume the functionality of my 11/05 console adapter? E.g. provide support for both a traditional TTY connected via RS-232 or a computer connected via USB. Also it would be great if it had an IDC40 header that could be connected directly to the 11/05's SCL port.
 
I envision a small box with a couple of LEDs on the front for showing activity on the serial ports and then on the back a RS-232 connector, one connector for current loop from the host (which type for current loop? a DIN-6 jack?) and then a current loop jack for the ASR33.

It would then be possible to interface both a standard serial terminal without CL or computer and also an ASR33. The host is connected over current loop. The device does buffering of serial data so if the host is connected over 2400 bps there is some amount of buffering to allow for printing at 110 bps. It should be possible to have two terminals connected simultaneously. If I press BREAK on the ASR33 or the reader run gets activated the device type out a menu. This menu allows for selecting file to send, if the reader-run should activate the menu or not, perhaps setting baud-rates (auto-baud?) . Another feature would be to capture a file that is uploaded through the ASR33 interface.

To make it it easy I would design it as a small board that has a STM32 blue pill board. On the board there are level converters and current loop drivers. There would be a small transformer for a PSU that would give about +/- 12 V for driving the serial ports and current loop and then a 5V using a 7805. To connect to external jacks on the rear of the box there would be a number of headers on the board.

I prefer a crimped cable over a bulky flat-cable, but I can add a 40 pin connector on the board for connecting to the host. Then it can be a choice to populate this connector. Since the blue pill has USB built in it can be connected to USB if that is a wish, but it is not my main target.
 
For a current loop connection DIN-6 would be my last choice; actually DIN-anything wouldn't be on my list. I really think a terminal block -- either screw terminal or the plug-in style -- would be a better general solution. My two cents ...
 
Right. But three two pole 1/4" jacks then for each current-loop connection or are there 6-pole 1/4 inch jacks available? I would prefer something less clumsy. DEC used a mate-n-lok but that is unobtanium.
 
Well, personally I think mounting a barrier strip of any size on the outside of a case with feed-thru holes to the interior for the applicable lugs is "no problem". I just don't think a Teletype and a DIN-plug go together :-}.
 
You must log in or register to reply here.
Back
Top