• Please review our updated Terms and Rules here

Friden Flexowriter terminal

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,713
Location
Near Milwaukee Wisconsin
A few years ago, I acquired a Friden Flexowriter SFD-V. After a year or so, doing a lot of cleaning, adjustments and replacing the drive platen, my Friden is working. I would like to connect the Friden to my older computers. I started out by making a level converter. The Friden logic uses 100 Volts DC and only has contacts and magnet coils. Next I made a Raspberry PI to convert the Friden code to ASCII code. The Friden is a 1959 machine, from some of my reading ASCII code was not used until the early 1960's. Anyway, I have successfully made a circuit that will take a RS232 signal, supply that to the Raspberry PI, which converts the ASCII to Friden code and finally convert the logic levels from 5 volts to 100 Volts for the Friden.

My first problem is that the Friden Code does not have many of the ASCII codes, but I think I can get around that. For example there is no ESCAPE code or exclamation point. The exclamation point can be printed, using an Apostrophe, backspace, period. The Friden code contains many punch tape/card control characters some of which are actual keys on the key board. I think I can just convert some of these keys in the PI code conversion.

The second problem is whenever a key is pressed, the Friden code is sent to the PI AND the typing machine will independently print that character. If I connect this circuit to the RS232 comm port of my DEC PDP8E, a key press, the Friden will print the character and the PDP8E will send back that character. The key pressed character will be typed twice.. I'm a little confused on how the Friden could be used as a terminal with any computer that has a full duplex comm port, as the PDP8E. There is no way to stop the Friden from typing a character when a key is pressed. Is there a way to convert the comm port or operating system to half duplex? If that can not be done, I suppose the Friden could be just used as printer. Thanks, Mike
 
Is there a way to convert the comm port or operating system to half duplex?
Most (all) of the 8/E software is expecting full duplex. Better would probably to have the Pi cache the last character sent, and ignore (not print) the echo if the same character is sent back. When it receives any character it should clear the cached character so that all other recieved characters are printed. (No need to "print" NULs anyway.)

Vince
 
Hi Mike.

There is no general way to stop the PDP-8 from echoing the character. There is no operating system call to read a character from the console which means every program handles I/O to the console itself and they all expect full duplex operation. So you would need to change every program that talks to the console to eliminate the echo.

Vince's idea is probably the best that can be done.

There is one advantage to half duplex operation and that is that there is less latency. For example a teletype at 110 baud full duplex there is considerable delay from the time you depress a key to when it is echoed. A little over 0.2 seconds. There is additional latency in the mechanism but that is minor compared to the communications latency.

Can you post a picture of your setup?
 
Doug, here is the hardware. This is the 1959 Friden Flexowriter. The level converter and finally the RPI. Mike
For some reason the pictures were posted in a mixed up order. The top is the RPI, the middle is the Friden and the bottom is the level converter.
RPI.JPG
Friden.JPGLevelConverter.JPG
 
So far my RPI software will take an RS232 signal from my CIT-101 monitor and send it to the Friden for typing. Going the other way, I only have the ability to accept a character from the Friden and the RPI will display the received Bits on the RPI screen. I need to make another look up tablet or use the one I have to convert the Friden code back to ASCII, then have the RPI send it out to the RS232 port. Then I'll have to fix the front end software to monitor the RS232 port to see if the Friden has a key press or if the Friden should print. AND add Vince's suggestions. I figure that having a RS232 comm port on this thing I can connection it either the PDP8E, my SOL terminal, my CPM machine or what have you. Keeps an old man busy on cold snowy days. Mike
 
I know this isn't exactly DEC stuff, but kinda related. I have written some software for my Raspberry PI to read the selector code contacts from my Friden Flexowriter. These contacts close for a key press and present that code through some level converters to my PI. The converter circuit is very basic. A Friden contact closure applies 130 volts DC to an optical isolator LED. The other side of the isolator outputs a 3.3 volt signal to the PI. Over the past week I was using an old linear regulated power supply for the 3.3 volts. The circuit worked fine and allowed me to DBug my software, while waiting for a Mean Well switching 3.3 volt power supply. The other significant part of this circuit is that there is 25 feet of DB25 cable between the level converter and the raspberry PI. Yesterday the Mean Well arrived in the mail. I replace the linear supply with the Mean Well and started testing again. Everything went haywire. I suspected the Mean Well supply. I read that a switching power supply that is lightly loaded can be unstable. My circuit only loads the power supply when there is a contact closure. Even then the loading is low. I loaded the supply up to 100 ma and that didn't change anything. I removed the Mean Well and tested it on my bench. Unloaded the Mean Well (RS-15-3.3) put out 3.38 volts and the output appeared to be nice and flat as viewed on my scope. I did not see any oscillations or spikes. I tried to set up the scope to capture any transients and could not find any. I loaded the power supply up to 100 ma again and the tests came out the same. So, I reconnected the linear power supply to my project and once again my project worked fine, just as before. So my problem is with the nice little compact switching power supply. What can I do to find out what is wrong. Does it need some decoupling cap's, more load (it's 15 watts), any ideas. I appreciate the help, Mike
 
Mike, most Mean Well supplies provide nice isolated outputs. This allows you for example to tie +V to "circuit" ground to provide -V to the rest of the "circuit". If you don't tie any of the two outputs (+V or -V) to ground then both will be floating relative to everything in the "circuit".
 
The only reason I posted this was, I have little experience with switching power supplies. I have tested and tried a number of different things in the past hour or so. The MW was on the bench and back in the project a few times. I loaded the MW to a couple of amperes, added some capacitors etc. I was on what I had thought was a ground loop problem. Seems that the Friden and the level converter were on a 120 VAC circuit and the Raspberry PI, CIT-101 etal were on another 120 VAC circuit on the other leg of the 240 VAC. Seemed that when the Friden and/or the level converter (with the MW power supply) was ungrounded the problem vanished. Then unexplained, the problem vanished entirely. So, I'm led to believe that the problem may have been self inflicted as a poor connection or something along these lines. Well... time will tell. Back to enhancing my software. Thanks, Mike
 
Well.... I'm making progress, all be it slow. The last few days I connected my Friden code converter project to the PDP8E and it would not work at all. I pulled out my hair horsing around with crossed RS232 cables etc. Then there was a failure in the Friden. Seems that when working with old stuff, they seem to fail a little more often then other stuff. Anyway, I figured out why this didn't work. I knew that the PDP8E was getting the key presses and was responding, but the Friden was not typing anything. Turns out that the data byte the PDP8E was sending to my RPI, always had the 8th bit (MSB) set to a ONE. The RPI only recognizes the first 128 bytes of the ASCII code, so it would ignore everything the PDP8E was sending. I changed the RPI serial to accept a 7 bit byte and then the Friden started to type characters.
I was sure that M8650 sent one start bit followed by 8 data bits and two stop bits. All the doc's I have, seem to indicate that this is correct. Am I correct in thinking this? Could there be a failure on my UART card? Maybe I have another failure to investigate prior to moving on with my RPI software, Thanks, Mike
 
Are you sure that your PDP8 isn't set to send 7 data + Mark parity and not 8 data + no parity?
If you want isolation, you may want to configure your Flexowriter to use a current-loop interface--it's isolated and far less prone to interference and line-length issues.
 
Not 100% sure. The only things that I know that can be set on the M8650 UART card is one or two stop bits and the baud rate. I don't see or remember anything that sets parity or byte size. Looking at the schematic there is an eight bit shift register that takes DATA 04 though DATA 11. I'm leaning toward a failure either in the shift register or the loading gate. Thanks, Mike
 
Well, given that the PDP8 uses 7-bit ASCII, the content of the 8th bit can be anything, I suppose.
There are much better UARTs than the very primitive MC6850, but I guess you go with what you've got.
 
The convention in PDP-8 land is that the hardware is 8-n-1 or 8-n-2. This gives a clean data path when sending binary data.

However, when sending ASCII, which is a 7 bit code, the convention is to add MARK parity, effectively using the physical channel as if it were 7-M-1 or 7-M-2. The extra bit, as you have observed, is conventionally set. The historical reasons for this have to do with the way it was handled for the ASR33, which has a hardware setting for the extra bit when the keyboard is used, and they jumpered it high. (The reader had an 8 bit path, convenient for binary paper tapes.)

Many PDP-8 programs can accept data with the extra bit in either state, but a few require it set. Most of the programs will set the bit on output characters, as those are often being reconstructed from packed 6 bit strings and such anyway.

Hope this helps.

Vince
 
Thanks, Vince. I think I proved this to myself.
I entered a short program that read the SR and outputted it to the terminal.
Code:
0000  7604 load AC from SR
0001  6046
0002  6041 skip
0003  5002 loop until char
0004  5000 start again
I caught the serial string, with the SR set to 0100 0001, a cap A.
Here I saw that D4 (MSB) was a ZERO
Did this again with the SR set to 1100 0001
Here I saw that D4 (MSB) was a ONE
This told me that the circuit was OK, D4 was following the SR switch. I then thought that maybe OS8 was doing something to cause the 8th bit to always be a ONE. I started OS8, typed an 'A' and caught the PDP8E reply string it was 1100 0001, D4 was a ONE. I tried a couple other letters and found that D4 is always one. So the PDP8E is OK (and I will not have to trouble shoot it). The problem is with my understanding of how OS8 works. I will have to change the RPI programming so that it works. Now onto other problems in my RPI program. Having trouble with upper and lower case. The Friden expects a code to raise or lower the carriage before a character. Let you know how things go. I appreciate the help, Mike.
 
Sounds good. Basically you just need
c &= 0177;
when converting to 7 bit ASCII, and
c |= 0200;
when getting ready to send "ASCII" to the PDP-8.

Vince
 
Well..... last night I stayed up late, at least for me, to work on my Raspberry PI Python program. Once I got past the serial data string problem I was a little anxious. I'm still relatively new to Python, but have had some luck with it. Anyway, I cajoled the Friden and the Python to type out a couple of OS/8 commands. I'm still having a little trouble keeping the Python indents, routine calls and returns straight and having some trouble with DBUGing. Seems the only DBUG tool I have learned to use is 'print'. BUT, here is the result of my late night.
FirstTypeSmall.JPG
So far, the Friden is just working as a printer. The input to the PDP8E is coming from my CIT-101 terminal. I'm still having trouble separating the PDP8E full duplex echo back and the Friden insistence of outputting contact closures for any typing function, whether it be a key press or a typed character. I'm working on some code to ignore a Friden contact code that occurs a millisecond (the RS-232 is operating at 9600) after a PDP8E response. I also trying to save the Last Key Pressed and Last Character Typed to do comparisons. Right now I'm having some trouble with the Python data types. Time will tell. Thanks for the help, Mike
 
The last few days, I've been working on a Python routine to convert the Friden Key presses to ASCII and send them to the PDP8E. To avoid the full duplex echo back problem, I just connected the Friden key board to the PDP8E and the PDP8E output to the CIT-101. The problems that needed addressing were the Upper/Lower case keys. Keeping track of the case is essential. The Friden selector code is 8 bits and I'm using a 9th bit for the case. The typing basket is physically moved up for Upper case and moved down for Lower case. My method seemed to work well for all the keys except the comma and period. The case doesn't make any difference for the period or comma, yet there is an Upper case period and comma, along with a Lower case period and comma. My ASCII to Friden Code table doesn't have an Upper case period or comma. Had to add some extra checking for the upper case. There were also some timing issues to address. All this mechanical hardware takes a LOT more time to occur compared to a CRT terminal. The last perplexing issue came with the Friden carriage return key. I made a special routine for this CR, because I thought I needed to send a CR and linefeed to the PDP8E. This resulted in a double command being displayed on the CIT-101. A version command looked like this.
Code:
VER [CR] Friden key presses

VER  PDP8E to CIT-101
VER

OS/8.......

.
I either had forgotten or didn't know that a linefeed to the PDP8E caused the line to repeat to the terminal. This took me an hour or two to figure that out. Anyway I think I have the Friden keyboard and typing routine worked out. Now for the hard part, and this may take some time, attempting to ignore the PDP8E full duplex echo back while not ignoring a PDP8E output. Mike
 
Well.... at long last! I believe I have the Python3 RPI program that connects my Friden SFD to my PDP8E. For a long time I was attempting to make the Friden code to ASCII code conversion work on a character by character basis. I was pulling my hair out trying to keep everything straight and not doing a very good job of it. Last week I decided to convert my program to work on a Command Line basis. The program would wait for a user input and collect Friden key presses in a buffer. Once the user pressed a carriage return the program would convert the Friden Code to ASCII and send it to the PDP8E. Then the program would wait for the PDP8E to respond. Again collecting the PDP8E ASCII in a buffer. Once the prompt CRLF - PERIOD was detected this buffer would be converted from ASCII to Friden Code and sent to the Friden to type. I had some trouble with Python programming syntax, some other programming items and keeping track of ASCII code that is unknown to the Friden and a lot of mechanical timing problems, BUT I think I may have it. I have not done any extensive testing, but so far the VERsion command, DIRectory command and the TYPE command work as I would expect them to. The Friden, in action, is kind of mesmerizing, hammering away. I've seen some other guys post videos, but I don't know how to make one in the first place (but I think I can get my son to help me with that) and second I'm not sure of how exactly to post such a thing here. AND is there a size limit to a video like there is with pictures? Thanks, Mike
 
Back
Top