• Please review our updated Terms and Rules here

Need a bit of help resurrecting my PDP-11/73

If you had something important on the disk you wanted to save you would dump it to the Emulator. Then you could run using this as your disk but being emulated by the MFM emulator. But I believe you have stated that there is nothing really important on this disk besides some software from back then and maybe some stuff from work. Still might be good to at least make a copy if you can. I have never used a QBone but it looks interesting. I have one of the boards from Decromancer but it is the MFM emulator as I have an RD53 that I plan to try dumping and then emulating a completely new RD53.
 
The QBone replaces the hard disks AND the RQDX3 controller. It sits in a QBUS slot and emulates various devices.

As such, your option #1 doesn’t exist.

QBone doesn’t replace the CPU, but it can be used to replace memory - but I wouldn’t.

Dave
 
Dave, so I would still be running the original DEC CPU and memory (thus limiting me to 12 mhz and 4 mb of ram) and the BeagleBone just serves as the brains behind the disks and disk controllers? So I wouldn't be running RSX under simh.

Do I have that right?
 
You have that correct.

So it is still a ‘real’ machine - just with emulated I/O devices.

I have a UNIBONE for my 11/45 (a retirement project). I have the CPU and FPU board set for the real machine with the UNIBONE emulating the RAM, serial ports and disk devices.

As I locate/fix some of my I/O devices (e.g. my TU56 tape drive), I will attach those real peripherals and deconfigure them from the UNIBONE as appropriate.

Dave
 
Today's saga... My anti-static kit and Deoxit arrived. I carefully removed everything and cleaned all the dust off (small model paintbrush to loosen, then a vacuum) every board, followed by Deoxit. Got the backplane nice and clean. Reassembled everything and started her up.

So as of now, it's hanging here:


Testing in progress - Please wait
Memory Size is 4088 K Bytes
9 Step memory test
Step 1 2 3 4 5 6 7 8 9

Starting automatic boot


It's not failing, which tells me (though I could certainly be way off base) that now the controller is able to attempt to control the drive, it just can't get it to do what it wants so the boot is just hanging.

Reluctantly, I opened up the RD53 case again and sure enough, after only a few days, the heads were stuck again. I gently freed them up and exercised them a few time, reinstalled the cover, then put the drive back in and am getting the same end result.

I could be wrong but I think I hear some sounds from the drive occasionally.

I tried a Ctrl-Z after letting it sit at Starting automatic boot for a while, received this:

Boot in progress - Please wait - Type CTRL C to exit

I'll leave it untouched for a while.
 
More testing and more manuals read. So boot isn't even getting to the point where it would try the hard drive. It's getting stuck at octal code 1, which means CPU ROM Boot in progress.

So I'm guessing something's up with the cpu card. I pulled it and reseated it, no change.
 
Is it possible the boot roms have been corrupted somehow? Are they in EPROM? I know you can add your own to those supplied on the CPU board. I will have to go read about that.
 
Is it possible the boot roms have been corrupted somehow? Are they in EPROM? I know you can add your own to those supplied on the CPU board. I will have to go read about that.

It only started doing this after I removed everything from the backplane, cleaned all the boards, and put everything back in.

I did use an anti-static mat and wrist strap. I wonder if reseating the actual chips on the board would help, maybe an iffy connection opened up when I pulled the CPU board out.

Or maybe it's just done.
 
Can I make a suggestion?

Please look at running the XXDP diagnostics for the boards you have got rather than guessing.

The initial ROM tests are passing - so they aren’t finding anything problematic with the CPU board.

I suspect the RAM test has been bypassed to save time on boot, and I did suggest reenabling it again a while ago to include the testing of the RAM in the short term.

Also, if memory serves me correctly, you can tell the boot EPROMs to continuously test the CPU and RAM for long-term issues.

You can extract and run the individual BIC files from XXDP if memory serves me correctly.

You can’t infer from code 1 whether it is the CPU, disk controller or disk that is at fault without any further data.

Dave
 
Yes, I can enable RAM testing, I know you suggested that but I'm a little gunshy about FUBARing the boot configuration.

To attempt to boot an xxdp image (I have it on TK50 tape), after loading and telling the system to boot from the tape drive, how long should I expect it to take to boot?

I noticed yesterday that the system seems to be running really slowly. For instance, when at the "Boot, List, Map, Test etc." prompt, it took way longer to move through the Map function. WAY longer than it did before my cleaning job. And I ran a continuous test; after about 45 minutes I cancelled it; it had only completed 1 pass. Previously it would have done 20 to 30 in that amount of time.
 
This is new information...

Remove the RQDX3 and the tape controller and see if that is any better.

Let’s start off trying to get a minimal system that works reliably. We can then start adding one controller at a time to see if/when we get a problem.

Dave
 
After some testing this morning, I can report that any time the RQDX3 controller is installed, the system goes into "slow mode" where everything runs really slowly, including the Map and Test functions. I pulled everything out except that one and only with that board in do I have an issue.

I also noticed a small red LED on the RQDX3 controller that lights briefly at startup, then goes off. Haven't read what that indicates yet.

I had removed the RQDX3 and slid the TK50 controller up into its slot hoping that it would see the TK50 drive MU0: and at least give me the ability to try and boot a tape. Didn't work though, would not see MU0:

This slowness problem didn't occur before... I am not sure if something I did messed up the drive controller maybe?
 
Last edited:
Yup - as DDS has stated (and I have also previously) now is the time to get XXDP up and running using a serial line.

Either use one of the tu58** tools, or find the requisite BIC files from XXDP and load them via the serial line from a terminal emulator.

Obviously, start of with the CPU ones first and then migrate to the memory and then the I/O controllers.

Dave
 
I also noticed a small red LED on the RQDX3 controller that lights briefly at startup, then goes off. Haven't read what that indicates yet.

The red LED is on at power-up whilst it does an internal self test and goes off if the self test is successful. I am reasonable sure mine goes off pretty quickly (seconds) after power up.
 
If you have a second working serial port, it might be time to boot into XXDP via either TU58EM or TU58FS and start running some hardware diagnostics.

https://www.ak6dn.com/PDP-11/TU58/tu58em/

http://www.retrocmp.com/tools/tu58fs

The authors of both are frequent posters on this site.

I just took a look at tu58fs and downloaded it.

I'll have to get a 2nd USB-to-Serial cable. Is there (in 2021 now) a recommended one, I read in the tu58em documentation that cables that use a Prolific chip don't handle Breaks correctly.
 
Back
Top