PDP8E Friden Code Converter

[Mike_Z]

A year ago or so, I was working on a code converter for my Friden Flexowriter to be able to communicate with my PDP8E. At that time I had the circuit built on a few breadboards with an RPI. The entire mess seemed to work rather good. Since then I developed a PCB from my KICAD drawing and sent away for a PCB board. Amazingly, my PCB board only had one mistake on it. For some reason, the back side edge card connector was covered with mask. I had copied the front pads to the back and forgot to change the front masks to back. So, I scraped the mask off, installed the parts and the board worked. Will wonders ever cease? This past week, I have been 'tuning' the RPI code to allow the Friden to work better. I had to slow the byte rate down a little, because the key lock would lock out the Friden on occasion. This Friden circuit is used to block two keys from typing at a time. I think the RPI was sending key codes to the Friden too fast. Well, after adding a 15 millisecond delay, the majority of the lockouts vanished. I still get maybe one lockout per full page of text.

I have found the when asking the PDP8E to type a file 'TYPE MPH.FT'. This particular file would lockout at the same point in the file every time. It would occur at the end of the file. This makes me think that maybe there is a particular character causing this problem. Is there a way I can look at each character in a DEC file? Seems that this character is not a printable character. I'm going to make a text file with all the ASCII characters 0-127 and see if one of those causes this problem, but I'd still like to see what the PDP8E is sending to the RPI code converter. Thanks for the help, Mike

 

[Mike_Z]

I believe I have it. Added a short routine in the RPI code to show me what the PDP8E is sending as it sends it. Apparently, my key lock is coming from a b'\t' which is a TAB. Now I have to check to see how fast the tab is working or if it is actually a bunch of spaces? Thanks, Mike

 

[MauriceH]

Have you read this site about the differences and the code program to ASCII.
Also: if you follow that Program link you read this.
For underscore (and vertical stroke) the Flexowriter SFD had keys that didn't result in carriage movement. Parity checking, effectively reducing the number of useful bits per frame to 6, could be realized without sacrificing the availability of both uppercase and lowercase letters, as the Flexowriter used two special punch codes, one for entering uppercase mode, and one for entering lowercase mode.
These peculiarities make translation of Flexowriter code into ASCII code less than straightforward.

May be that will help you further in the trouble shoot.

 

[Mike_Z]

Thanks for the references. Had not seen those. My conversion code is basically a look up table. I have a list of Friden codes, listed in ASCII order. So when an ASCII character is encountered the integer value of that ASCII code can be used as the index to the list, resulting in appropriate Friden code. I've added a ninth bit to the 8 bits of code to represent the case. Then keeping track of the current case condition of the machine, I compare the machine case to what the incoming character has for case. If they are similar nothing is done, if different then the case is change accordingly. The TAB is one of the special characters and has it's own code, but for some reason it is currently locking up my keyboard. I have either a RPI coding problem or maybe something else. The Friden TAB key works, so the code that picks that key should also work. But something between the PDP8E and the RPI must be wrong. My biggest problem is my own failing memory, but that is another challenge. Thanks for the help, Mike

 

[Mike_Z]

Well..... I've at least verified that my problem is with the TAB character. I removed it from the TYPE file using the R EDIT. Now the TYPE command will complete the file typing. Now I have to look over my RPI code to see what the trouble is with TAB. Thanks for the help, Mike