• Please review our updated Terms and Rules here

pdp 11/04 assembly from parts

Thanks Dave,

I'm a mechanical engineer by trade, so I have no excuse there. There's actually a lot for a mechanical person to appreciate on vintage big iron. On this 11/04, the cooling airflow path is quite interesting and will not work properly without the lower and upper sheet metal covers.

Another of my next projects is to restore two RK05s and an RK8E. I always get a kick out of seeing the different ways to position disk drive heads. Anyone who has ever seen the head positioner on an RK05 will understand why I would be amused. In a way, it reminds me of the carriage on my 1950's DeWalt radial arm saw. Just with a big voice coil at the end.

Lou
 
Last edited:
Lou,

I hope you don't think I'm hijacking this thread to much :)

I opened up the faulty RL01 today and watched what happened when I press LOAD. ( I also tested with another disk pack, same thing, but I don't know if that pack is good )

1. The drive spins up.
2. The head moves out a little bit and stays there
3. nothing.

So it looks like it finds the guard track but not track zero? Is this an indication that I need to do a head alignment? which actually sound quite fun :)

I also tried to boot the PDP-11/23, but it halts with an error code which just indicates generic RL-disk problems, so it just confirms that something is not right with the disk.

Cheers
 
Pontus,

If you have a dual trace scope it will be easy to see where the head is ending up. One channel will trigger the scope on and display the sector index pulse. The other channel goes on the output of the head amplifier. Over the guard tracks, there is only one servo burst. Over data tracks, you'll see two servo bursts, then the sector header data. This is actually what is displayed on my scope in the earlier photo of the RL01 with the guts hanging out. The head is out over data in the photo.

The appropriate test points and what to look for are all detailed nicely in the RL01/RL02 techncial manual volume 2 (EK-RL122-TM-001) Chapter 3.

When the head loads, it should seek track 0. In the manual, you will see what needs to be jumpered to defeat the positioner motor and seek timeout timer. Then, you can manually move the positioner with your hand. Withdrawing the heads radially outward, the very next track should be the outer guard track, which will only have one servo burst. If you're not over track zero, you can count the tracks to figure out where you were. I might do this a few times to see if it's ending up at the same track each time.

If you weren't over track zero though, the seek timeout timer should expire eventually and the fault light come up. I wonder why it doesn't do that.

When you say that the heads come out a little bit, can you roughly measure that? I'm wondering if the heads are ever actually leaving the ramp (that lowers the heads onto the surfaces) and loading onto the disk.

As for head alignment, there are actually two alignments, the radial alignment of the positioner (is it really radial, or is it off to one side or cocked at some angle), then the head alignment (heads with respect to each other). I only needed to perform the latter after replacing the upper head because the former was good. Head skew does not appear to be adjustable and would require head replacement if it was off.

I have a feeling there is something else up and that a head alignment won't help (but I am only a novice at this.)

Lou
 
Last edited:
Lou

Thanks for the detailed answer :)

I will have to get a better scope I think, I only have a small 20MHz scope my dad bought ages ago.

I estimate that the heads went out about one inch, I'll have to get back in there to make a more accurate measure. I sounds like the heads are landing (I can hear them brush against the disk), I believe they actually are supposed to touch the surface of the drive in these beasts, otherwise that might be my problem.

This problem occurred after I removed and reinserted the SLU, perhaps I have a controller or cable problem. I could try replacing the RLV11 (I have spares), but I'm uncertain if the READY light depends on a working controller (the manual you pointed to indicates that its all in the drive). You do get a fault unless you have a cable attached.

Pontus.
 
Again from the "because I could" file, I put a DEUNA in this 11/04. http://www.vintage-computer.com/vcforum/album.php?albumid=77&attachmentid=4670

I extended the unibus to the 4-slot expansion backplane and put the dual hex height card set in there. I then sysgenned RT-11 appropriately and installed the RT-11 telnet / FTP package. I moved a nice big file from an FTP server in the garage (on a PC). With only two nodes on the network, the 11/04 was downloading a file by FTP at 6.2 kbytes / second and writing it out to RL02. http://www.vintage-computer.com/vcforum/album.php?albumid=77&attachmentid=4669

I think the only thing crazier would be to get a UDA50 and put that in too, then connect it to the RA72. A computer with 32kW of core and 1GB of disk space.

I think the T-11 on the DEUNA might be more powerful than the 11/04 itself.

Next, we probably add the TA11 controller and connect it to the TU60.

Lou
 
Hi Lou,

I somehow managed to miss this project but photos like these always bring a smile to my face. All those open cases and wires all over the place - great stuff! Makes me want to get back to tinkering with my 11/35 again...

Do you have any tapes for the TU60? I heard they can rip regular audio cassettes to shreds!
 
Steve,

It's certainly good fun. Fortunately I have half the garage to "spread out" in. I am impressed by folks that are able to work in very tight spaces.

My TU60 has never shreaded any tapes. However, any old tapes, like real dec TU60K media are no longer readable. The oxide comes right off onto the heads. The tape in a compact cassette is nowhere near as robust as dectape (which is encapsulated on both sides). The old cassette tape has no encapsulation. So, I do use audio cassettes. I wrote something about this in a post to alt.sys.pdp8 when I first restored the TU60. Basically, high quality audio tape with a clear leader and a notch added to the cassette housing, works fine. I think I had the best result with some tape from BASF.

I would be intersted to find anyone else with a working TU60. The heads between the two transports in my TU60 are aligned differently (tapes written in one are not interchangable with the other.) I would like to get a tape from someone who thinks their heads are aligned properly and try it in my transports. Then I will re-align to match.

Lou
 
I don't believe any hard disk head should ever touch the disk surface. A floppy disk sure. But a hard disk spins much
faster. Back in those days 3600 rpm was common. If the heads touch the disk and there is any type of debrib (fingerprint, hair, etc) you have a major problem. You can often hear the high pitched tinging of particles hitting the heads as I did
on my RK05 after I had cleaned them but still missed minor particles. Clean the heads good also.
Tim R
 
TU60 is the DECassette right? The computer club has one, but I have no idea about function or if we even have a controller.
 
Pontus,

Yes, TU60 is the decassette drive. It uses Philips compact cassettes. If it hasn't been used in a long time, all of the rubber tires will be dried out and broken. I had to rebuild my tires.

Last night I found the XXDP diagnostics for the TA11 and most of the listings. We are making progress.

Lou (and my overflowing mailbox is now fixed.)
 
Well, the TA11 is installed and cabled to the TU60. The four controller checkout and tape motion XXDP maindecs pass. However, the data integrity maindec hangs after an initial rewind as it waits for the ready signal from the drive. It looks like my drive is flakey and there is a problem coming ready after a programmed rewind. Both transports behave the same.

Under RT11 I can initialize and take the directory of a cassette. I can copy files to the cassette, but cannot get copy/verify to work. I also cannot copy files back from cassette. It finds each of the file gaps, but passes right on to the next file until the end of the last file, when it rewinds and then RT11 gives a "channel not open" error. But somehow it can take a directory, which means data can be read off the cassette.

Amusingly, it can take a directory of CAPS-8 / OS/8 cassettes. I also don't understand why, but the XXDP block-by-block tape duplication maindec runs without errors, supposedly even verifying the copy! But alas, something is truly wrong, because when reconnected to the 8/e, OS/8 MCPIP hangs right when trying to access the tape, right after a rewind, just like the XXDP data integrity maindec does.

So, the TU60 will come out of the rack and go on the bench while we scope this out.
 
One step backward, two steps forward

One step backward, two steps forward

A lot has happened over the last four weeks or so. When I put the TU60 back on the TA8E, it didn't work there either. After a bunch of weeks of troubleshooting (and finally buying some card extenders from Douglas Electronics) the TA8E / TU60 is back to working condition. The IOT decoder 7442 on the TA8E was broken and two 8640s in the TU60 were bad. It turns out that 380 and 8640 have the same pinout, so I used 380s. So tonight, for the first time in a long time, I booted CAPS-8 from the original bootable cassette that I built by hand almost four years ago now.

While waiting for my card extenders to come, I fixed up an MI8E diode bootstrap loader. I have no idea what the original diode configuration was for, but I changed the diodes to the RX01 bootstrap. Now the SW switch on my 8E does something! Of course, the MI8E was broken too, but the problem was a 2N3009 that drives the Pulse LA H line. I actually had the replacement. So, now it's the end of an era - I no longer have to fat finger a bootstrap on the 8/E. I can use the rom bootstrap loader to load the RX01 bootstrap, then run OS/8 and use the boot command there to load whatever strap I want (which at the moment is only the cassette.)

Now I need to clean up a bit, and put the TU60 back on the TA11 11/04 and try that again. At least now I know that the TU60 is good!

Lou
 
Lou - N2MIY said:
A lot has happened over the last four weeks or so. When I put the TU60 back on the TA8E, it didn't work there either. After a bunch of weeks of troubleshooting (and finally buying some card extenders from Douglas Electronics) the TA8E / TU60 is back to working condition. The IOT decoder 7442 on the TA8E was broken and two 8640s in the TU60 were bad. It turns out that 380 and 8640 have the same pinout, so I used 380s. So tonight, for the first time in a long time, I booted CAPS-8 from the original bootable cassette that I built by hand almost four years ago now.

While waiting for my card extenders to come, I fixed up an MI8E diode bootstrap loader. I have no idea what the original diode configuration was for, but I changed the diodes to the RX01 bootstrap. Now the SW switch on my 8E does something! Of course, the MI8E was broken too, but the problem was a 2N3009 that drives the Pulse LA H line. I actually had the replacement. So, now it's the end of an era - I no longer have to fat finger a bootstrap on the 8/E. I can use the rom bootstrap loader to load the RX01 bootstrap, then run OS/8 and use the boot command there to load whatever strap I want (which at the moment is only the cassette.)

Now I need to clean up a bit, and put the TU60 back on the TA11 11/04 and try that again. At least now I know that the TU60 is good!

Lou
Click to expand...

Congrats,
It must feel good. How did you manually create the CAPS-8 bootable though? Also it's nice to have a bootstrap board.
Manually toggling in a bootstrap a few times is fun, but not for long.
Tim
 
Last night I put the TU60 back on the 11/04. I have two TA11 controllers that are "close" to working. One has a stuck high receiver for the MSB data bit, the other "seems" to be working fine. The seemingly good looking one does not run the most complicated maindec, still hanging after the initial rewind. It's stuck in a loop waiting for a flag. The controller with the stuck data bit does the same thing. The time has come to start scoping the TA11 controller now.

The problem is that the TA11 controller print set is nowhere to be found in the internet.

Pontus or Steve or any of you fellows with connections, can you check your computer clubs for the schematics for the M7892 TA11 controller? I would be very appreciative.

Pontus, the dual height extender (without socket connector) was ~$19.50USD each. I had connectors desoldered from junk boards from Tim. They are really handy! Now I have the TA11 raised up out of the 11/04.

Tim, as for the CAPS-8 cassette, I posted on alt.sys.pdp8 on Dec. 12 2006 the long story. If you search google groups for CAPS-8 alt.sys.pdp8, it will come up.

Thanks for your help guys,

Lou
 
Lou - N2MIY said:
Pontus or Steve or any of you fellows with connections, can you check your computer clubs for the schematics for the M7892 TA11 controller? I would be very appreciative
Click to expand...
Well, we have a TU60, so there is a chance there is documentation. But it will take some serious archeology to dig it out! We are very cramped up in our storage, so it might take me a while.
 
We figured out why the most complicated TA11 maindec would not run. The maindec in question is DZTAEB0. The B0 version is the only one I could find anywhere. It was on an image of an RK05 pack on bitsavers. The listing I have, also from bitsavers, is for revision C0.

I thought there was a problem with interrupts, and I was right. The B0 version is missing a CLR PS (clear the processor status word) early in the code that is present in the C0 version. I only saw that by doing a bunch of examines and comparing the code in the machine with my listing. The missing CLR PS sets the processor priority to 0, allowing it to be interrupted by any interrupt. Without the CLR PS, it was stuck at priority 7, thus ignoring the priority 6 interrupt that the TA11 was setting after finishing the initial rewind back to the clear leader.

I say that without the CLR PS that the processor was stuck at priority 7, but that may be a function of the machine I am using. My 11/04 has no proper programmers console, so I rely on using the console emulator in the M9312. In this mode of operation, the machine never halts, since the M9312 is sort of running a monitor. When under monitor control, it would make sense that the processor be at priority 7 so that no other devices could interrupt the monitor. Maybe on a machine with a real blinkenlights programers console, the PSW does not get reset to priority 7 on a halt, and so long as it is 6 or lower, the B0 version runs fine.

So, I inserted a NOP and CLR PS into the code (overwriting a little bit of code that I don't need to use that allows the user to set a nonstandard CSR, vector, and BR level). Now the B0 version is running good. (For the record, starting at location 002010, I deposited 000240, 005067, and 175760 as the patch. The maindec must be started at location 200 or 204 and NOT 210 since the patch destroyed the code called by 210)

Now we have to figure out why RT-11 doesn't work properly with the CT: handler. It must be a software problem, since all the hardware maindecs now pass.

Lou
 
You must log in or register to reply here.
Back
Top