- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
PDP-12 #435 at the University of Minnesota Duluth
- Thread starter pahp
- Start date
pahp
Experienced Member
We are using minicom, not a TTY (someday...). We send at 19200 8N2.
@jnowaczek reminded me today that in the past we had more luck getting things to load when we used single step, auto + continue and slowed down the machine during sending. I'll going to try the echo tests and/or re-sending the OS/8 bootloader when slowing the machine down.
@vrs42 -- there's a way to reduce the baud rate on the serial cards, right? Is that something I should try, in your opinion?
Finally, @vrs42 are the two serial cards interchangeable? Do you think it's worth swapping our pty card with our "disk" card, or is there a way to modify the RIM loader to try to read from the other card, just to rule out an issue with one of the serial + tty card subsystems?
Thanks as usual.
pahp
Experienced Member
Thanks @DougIngraham . We will try to find a minimum test case using the ideas that have been suggested -- thank you.
You're welcome in Duluth any time! If you give me enough warning I may be able to get you a key to the lab so you can come and go as you please while you're around.
DougIngraham
Veteran Member
I see that this has already been answered but yes, MA is Memory Address, MB is Memory Buffer.
I would verify that all the bits in the MA and MB seem to be working. Looks like you can do this by walking a 1 through the left switches and pressing exam. the corresponding indicator in the MA should be the only one lit. Try single bits on and then try single bits off. The idea is to verify no bits are stuck on or off and all of them work independently. Of course if you have any bulbs burned out then you won't be able to see that bit.
You can then check the MB using the right switches and the fill switch in a similar manner. If that all seems ok then punch in my little program at zero. It will set that location to its address or to its complement. DEC has a memory address test that does this four ways to catch different kinds of problems.
From re-reading your notes I think Vince might be right that you have a serial port issue. Running an echo test would help find if you have a stuck bit in there somewhere. The shortest console echo program looks like this.
I would write a program to run on your PC that sends a character and then waits for the 12 to echo it back. Then checks the echoed character to make sure it is what was sent.
You should not have to run two stop bits if everything is working properly. I have seen problems on these old systems when one side was set to 2 stop bits and the other set to 1. The early uarts wanted to enforce the 2 stop bits when they were receiving characters. They could get confused if a start bit showed up during what they thought was supposed to be stop bits. It would resync when enough ones in a row would be received but this might be in the middle of a character and that didn't end well. You would get junk when sending at what you thought was maximum data rate but it was fine if you sent a character at a time because of the extended stop interval.
I will certainly let you know if I am headed your way. I would not feel right being unsupervised in your lab so no key for me.
I would verify that all the bits in the MA and MB seem to be working. Looks like you can do this by walking a 1 through the left switches and pressing exam. the corresponding indicator in the MA should be the only one lit. Try single bits on and then try single bits off. The idea is to verify no bits are stuck on or off and all of them work independently. Of course if you have any bulbs burned out then you won't be able to see that bit.
You can then check the MB using the right switches and the fill switch in a similar manner. If that all seems ok then punch in my little program at zero. It will set that location to its address or to its complement. DEC has a memory address test that does this four ways to catch different kinds of problems.
From re-reading your notes I think Vince might be right that you have a serial port issue. Running an echo test would help find if you have a stuck bit in there somewhere. The shortest console echo program looks like this.
Code:
LOOP, KSF /WAIT FOR A CHARACTER
JMP LOOP
KRB /READ THE CHARACTER
TLS /ECHO THE CHARACTER
JMP LOOPYou should not have to run two stop bits if everything is working properly. I have seen problems on these old systems when one side was set to 2 stop bits and the other set to 1. The early uarts wanted to enforce the 2 stop bits when they were receiving characters. They could get confused if a start bit showed up during what they thought was supposed to be stop bits. It would resync when enough ones in a row would be received but this might be in the middle of a character and that didn't end well. You would get junk when sending at what you thought was maximum data rate but it was fine if you sent a character at a time because of the extended stop interval.
I will certainly let you know if I am headed your way. I would not feel right being unsupervised in your lab so no key for me.
m_thompson
Veteran Member
The lightning storm that killed the PDP-9 apparently also killed the PDP-12 and the PDP-8/I. I will be joining your PDP-12 restoration quest soon.
NOOOOOO!
vrs42
Veteran Member
It's possible that 19,200 baud is too fast, if your cabling is poor and particularly if you slow the CPU. In general, that usually isn't a problem for the software, since the loaders don't try to echo and do vary little between characters. So, if the hardware can reliably move the characters, the loaders (at the least) ought to work.
If minicom is fibbing about honoring your request for two stop bits, you can get a situation where the echo test passes, but bursts of data don't work. Basically, the number of stop bits output by the sender must always be equal to or greater than the number of stop bits for the receiver, or character bursts won't be received properly.
The baud rate cards have DIP switches to set the baud rate. I believe that the two card sets should be interchangeable if the baud rate cards are set to the same baud rate. Device address and such are set over on the M706 and M707, IIRC, as is the character width and the number of stop bits.
The RIM loader is very simple, so we could patch the IOT address bits to match the second card if we had to.
Vince
pahp
Experienced Member
Oh man I am so sorry. Not sure how I can help, but if you ever need us to test anything out on our machine for comparison don't hesitate to ask.
pahp
Experienced Member
Thanks. We may try swapping the serial cards. I'm pretty sure that Warren is the one who set up our stuff to do 8N2, but it sounds like I should check the teletype cards to make sure that they are actually configured for that. The thing is that we have successfully used minicom in the past to send files and receive teletype data. So I'm pretty sure it's not a minicom issue.
I'm off campus tomorrow, but if I can find time on Friday I will do some of this testing and report back. Thanks to all for your help and ideas!
pahp
Experienced Member
All I had time for today was walking the bits through the MA and MB and they looked good. More next week.
pahp
Experienced Member
I had some time to work on #435 today and got to show the machine off to a friend's dad who used to work for Control Data back in the day.
As you may recall, we're having some weird issues with the serial.
Next time, I'll try the program @DougIngraham suggested in his post above. Today though, we ran two "punch in programs" we had on paper here. They are:
When we run that program, whatever we type in minicom appears on that line, and we can see the last character in the accumulator (plus the 8th bit of the byte is always lit). When we hit enter, it returns to the beginning of the line. Here's an example pic of the output:
Next, we tried this console print test:
When we run that program, it appears to print the full character set (on one line) in a loop. This is what we see in minicom:
One thing that's weird is that minicom gets completely confused by this and I am unable to quit minicom normally, even after stopping the program on the PDP-12. I'm not sure if this is normal, or not.
The other weird thing about the computer is that the instantaneous buttons like FILL, START LS, I/O PRESET, etc., seem to be very sluggish. We have to hold them for some time before they "react" -- I don't know if this just means that they need cleaning, or if this could be a sign of some other kind of issue. To clean them, do I just pop off the grate, vacuum things out, and then spray deoxit in there? I did not do this the first time it was done (when Dawson and Warren originally got the machine up and running).
Thanks as always for all the help!
As you may recall, we're having some weird issues with the serial.
Next time, I'll try the program @DougIngraham suggested in his post above. Today though, we ran two "punch in programs" we had on paper here. They are:
When we run that program, whatever we type in minicom appears on that line, and we can see the last character in the accumulator (plus the 8th bit of the byte is always lit). When we hit enter, it returns to the beginning of the line. Here's an example pic of the output:
Next, we tried this console print test:
When we run that program, it appears to print the full character set (on one line) in a loop. This is what we see in minicom:
One thing that's weird is that minicom gets completely confused by this and I am unable to quit minicom normally, even after stopping the program on the PDP-12. I'm not sure if this is normal, or not.
The other weird thing about the computer is that the instantaneous buttons like FILL, START LS, I/O PRESET, etc., seem to be very sluggish. We have to hold them for some time before they "react" -- I don't know if this just means that they need cleaning, or if this could be a sign of some other kind of issue. To clean them, do I just pop off the grate, vacuum things out, and then spray deoxit in there? I did not do this the first time it was done (when Dawson and Warren originally got the machine up and running).
Thanks as always for all the help!
jnowaczek
New Member
For what it’s worth, I’ve noticed similar behavior using minicom at work with much more modern serial devices!
The only pattern I’ve been able to discern is it seems to happen more when lines exceed the width of the terminal.
vrs42
Veteran Member
That seems OK. A Control-J should probably line-feed.
That's almost right, but the line feeds didn't happen. On my terminal emulation each repetition is on a separate line, since there should be a bell, a tab, a line-feed and a carriage-return which should arguably be detectable.
Not sure what's going on there.
Vince
pahp
Experienced Member
I'll try that tomorrow.
I'll make the terminal larger to see what's happening in minicom.
Then I may also try it in MTTTY just to get a second opinion.
I still have not tried reducing the baud on the cards to (say) 9600.
I'll report back.
Can I just vacuum out and deoxit the contacts from the top or do I need to do more disassembly to clean the console switches? If there's a resource on the right way to do this I would be happy to follow it...
Thanks again!
thunter0512
Veteran Member
I wonder if some special (non-printable) characters cause minicom to lockup.
SpaceHobo
Experienced Member
Yeah, given that you're probably iterating through the entire ASCII set in order, you're going to start at the control characters. Something is going to send an ESC and then follow up with other control characters that may tell whatever VT102 emulation you're in that it's time to go into a special mode.
pahp
Experienced Member
Ahhh, of course! Thanks. Definitely time for a non-VT terminal to listen on the com port. I never thought about that, thanks @SpaceHobo !