Category Archives: Retro Computing

Consolidated Computer Inc. PDP-8 Clone – Part 3 PSU refurbishment.

A photo of the back of the rack showing three power supplys, one on top of the other.
Here are the three PSUs in situ.

It’s time to take a look at the PSUs and see what state they are in. There are three PSUs in this unit, two are the same, the third is different. All are big and heavy.

One of the PSUs removed from the machine showing the dirt.
A grubby PSU

From the photographs you can see a big transformer, two massive capacitors, two lesser capacitors and sundry bits and bobs. So what we have here is a pretty standard, if somewhat large, linear power supply.

This PSU has been sitting for possibly decades and so it the capacitors may need reforming as they can degrade with time. In the next photo, I’ve popped them out and given them a clean. There is no signs of leaking or bulging so it’s so far so good.

One of the larger caps connected to the capacitance meter which is showing 211,000 MFD.
The meter shows there is a lot of capacitance there.

Out with the trusty capacitance meter… All four are giving plausible values so the signs are good. Time to get some power onto them. At this point I connected the capacitors, one at a time, to a variable voltage power supply that had an adjustable current limit. I set that limit to about 20mA and the voltage to about 3v and gave the capacitor some power. At first the current limit came on. This is to be expected. Then the voltage rose to 3.5v and the current limit went off. Next I increased the voltage by a volt or two. The same thing happened. I steadily, over the course of a few minutes, increased the voltage to the full 15v these capacitors are rated at. There were no surprises and no incidents. Few!

One of the two PCBS from the power supply.

Next, I removed the two PCBs, on at a time and cleaned up the terminals and fuse holders with a brass wire brush. These had a layer of corrosion on them and it’s a good idea to get rid of that.

Having cleaned up the terminals and given the whole thing a clean, it was time to put it all back together.

With it all back together it’s time to see if we’ve got a good power supply of a machine for making smoke.

As this PSU is supposed to kick out about 10v (unregulated) I got a couple of 12v car bulbs and added spade connectors so I could use them to put a bit of a load on the PSU. With a linear supply, this is not stricktly needed but it’s a good idea.

Ready for testing.

At this point I admit I was a little scared that I might let the smoke out and so the first test was done in my workshop with the PSU on the end of an extension cable and with me in another room with my finger on the mains switch.

Flick… All is well. A cheery glow through the crack in the door showing that the bulds were lit. I left it like that for 20 minutes before switching it of and moving it back inside for the photos you see below.

Tadaa!

I have measured the voltages and both sides of the PSU are giving a smidge over 10V and according to my ‘scope, there is very little ripple.

Well done our side, just the other two to go now 🙂

To give a clue of the size. A drinks can next to one of the caps

Consolidated Computer Inc. PDP-8 Clone

CCi PDP-8 clone in 19 inch rack along side is a 9 track tape drive in a  similar 19 inch cabinet.

Sometimes friends with machines they no longer need will get in touch to pass them on to me. Sometime they have friends who have something they want to get rid of but can’t bear to throw away and so again, I get a call.

I got a message from an old friend of mine, John, to say that a friend of his had a PDP-8 clone that he no longer had space for and was loathed to scrap so asked if I would like it. Of course I said yes please.

At this point all I knew was that it was a PDP-8 clone and it was Canadian. I searched the web for clues but didn’t find anything.

John sent me some photos over and my jaw dropped. I was expecting something like a PDP-8a; A 19″ rack about a foot high. I didn’t expect two chest high 19″ racks, one with the computer, the other with a 9 track tape drive.

Have I been a bit hasty in saying yes?

I did have second thoughts but it’s not everyday someone offers you a PDP and so I couldn’t really turn it down. Luckily I have more than one friend and another, rather generous one, said I could store it in his storage unit for a bit.

The identity plate inside the cabinet. It shows the CCI logo and text.
The identity plate inside the cabinet. It shows the CCI logo and text.

From the photos I could see that it was badged as a Consolidated Computer Inc, machine but a lot of searching on the web turned up very little. I found that CCI had been a computer company in Canada and that they were well know. I found that they did indeed make their own computers but I haven’t been able to find anything about the computers themselves. Not even the name of one let alone the specifications.

A close up of the 9 track tape drive.
A close up of the 9 track tape drive.

The important thing was to get the machine first. I’d worry about the rest later.

After a brief visit to see the machine in the flesh, I hired a van and got some friends together and we got both cabinets into the back of a van and into the storage unit.

No one was harmed in the making of this journey.

Nascom-1. Back on the workbench – Part 2.

In the last post about the Nascom-1 I showed a photo of the screen whilst it was running some test software. At first glance it looks good (don’t be put off by the fact that the top line is very different to the bottom, that’s due to the way the screen is mapped).
If you look a little more closely you will see that about half way across and two thirds down there sits a spurious ‘2’. I blame my excited state for not spotting it myself and for having to have it pointed out to me.
This raises a little doubt as to how well things are actually working. A few more tests are called for.

Reset.

Before I start some more tests let me explain a little about the power on reset circuitry on the Nascom-1. There isn’t any power on reset circuitry on the Nascom-1.
The first image is the reset circuitry of the Nascom.

The second is that of the Sharp MZ-80.
 
You can see that there is just a pull-up resistor on the Nascom but a more elaborate scheme on the Sharp. The upshot on this is that you get no sense out of the Nascom until you press the reset button.
When I talk about power cycling or powering on, there will always be a manual reset involved. This has become evident 🙂

and more tests.

I did a few test cycles. Each cycle comprised of powering on the machine, pressing reset 10 times and looking for any unexpected characters.

  • Cycle 1, no abnormalities.
  • Cycle 2, fine.
  • Cycle 3, perfect.

Hmm.

A variation on a theme.

Neal suggested a variation on his VDU_test program which was to build the image in ordinary user RAM and copy it across to video RAM.
Over to the editor. crank over the assembler. Fire up the Stag.
Here are two photos showing the results.

This is what I did…

  • Powered up the Nascom.
  • Pressed reset.
  • Took the photo.
  • Pressed reset.
  • Took the photo.

You can see the distorted pattern. As the difference between this and the previous screen dumps is that the image is built in user RAM and copied to video RAM using  LDIR, I’m thinking there seems to be a problem copying from user RAM to video RAM. Perhaps some of the buffers are a bit iffy?!?

Have another think.

 
 

Nascom-1. Back on the workbench – Part 1.

It’s been a long time since I tried to fix my Nascom-1. In fact is was my Retrochallenge project for October last year.
A little while ago I got the offer of some help with this underrated (outside the UK) marvel and with the PDT-11/150 awaiting new drive belts and a new floppy disk, I decided to get it back on the bench.
You may remember that I picked up a PCB for Grant Searle’s Multicomp from Neal, a fellow retro enthusiast and all round “good egg”.
It is Neal who has again come to my aid.

Let’s look at the video.

In a previous post I took out one of the single-bit video RAM chips to see what happens. It showed that the screen data was coming from the RAM (or at least the socket) rather than being invented further down stream by a fault.
We’ve taken that approach a bit further.
Remove all of the video RAM. Now, without those RAMs the screen should fill with 0x7f (actually 0xff of course but it’s 7 bit video). It does.
Next, try grounding pin 12 of each of the sockets for ICs 21-27. Pin 12 is data out. As the pin floats high with no chip present, me grounding it pulls it low and so we should see…

  • IC21 0x7e
  • IC22 0x7d
  • IC23 0x7b
  • IC24 0x77
  • IC25 0x6f
  • IC26 0x5f
  • IC27 0x3f

And that’s exactly what I see. This means no shorts on the data bus.
Next the standard ROM is replaced by a special I wrote that just fills the whole screen with 0x00 and stops by looping back on itself.
Repeating the above test but but substituting one RAM chip for tapping the wire I should get exactly the same results.
Nope. IC25 and IC26 didn’t work as expected but the others did.

A slight change of tack.

But only slight. More an investigation based on matters arising.
I need a new ROM. Neal has a little piece of code that should generate this…
Let’s break out the Stag programmer…

Let’s go round again.

This time, we’re going to try Neal’s test code but with all of the video RAMs in but a number of other chips removed.

IC28 (video RAM read buffer) IC47 (user RAM read buffer), IC35 (PIO), IC40 (kbd rd) and IC29 (UART).

Power on and we get…
Excuse the reflections, I was excited!

Put a few things back – UART and PIO.

I put back the UART and the PIO as I figured these two were unlikely to be the cause. Sure enough the picture came up just as before.
Now IC40, kbd read. Still fine.

Replacing the buffers.

I put back IC28 the video RAM read buffer and it’s still fine. The reason that the picture is different to the previous is that the software reads back the fist byte of video RAM as a seed value. Without IC28, the video RAM read buffer, it can’t see what’s going on and so always starts with the same byte.
With the RAM buffer in place, each time it’s reset, it increments the first value so that successive presses of the reset button cause the pattern to creep. I don’t know if it’s significant the the first byte read without the buffer appears to be 0x08. I was expecting 0xff.
Next up is IC47, the user RAM read buffer. That’s working too!?. All of the chips are back in and the little video test is working fine.
Hmm…

The test is working. Now what?

Back to my zero fill ROM.
I now get the same character in each position but it’s not zero. It seems to be either ‘I’ or ‘K’ with each power on. It didn’t do that before. The screen was split before.
This doesn’t make sense. Time to check the code again.

Confession time.

It seems I’ve mucked it up a bit. Here’s my code.

 org 0x0000
start: ld hl, 0x0800 ; Start of the screen
ld e, l
ld d, h
inc de
ld bc, 0x0400 ; Size of screen memory
ld a, 0x00
ldir
loop:
jp loop
end

See how I carefully load the accumulator with 0x00 and then forget to put it into (HL)? Doh!!
The intention was to clear the first byte of screen RAM and then copy that throughout the memory. Without the first byte being set, we’re just filling with whatever is in that first byte. It could be anything.
It doesn’t explain why the screen is filling completely now.

Keep testing – single char fill.

I power cycled it again and it’s back to its old tricks. More power cycles and it’s variations on this theme.

Neal’s video test.

So back to Neal’s video test ROM again, still with all of the chips in.
It’s completely reliable.
Hmm.
 

DEC PDT-11/150 – Part 8. Try new media.

So the belts I fitted in the previous post got the drives spinning but the only floppy disk I had wouldn’t read.
The retro computing community is a wonderful thing and a quick post in the vcfed forums got me two offers of help from members keen to try and get the old thing up and working again.
I now have a fresh copy of the much needed boot disk but sadly, no improvement in the symptoms.
More thought needed.

DEC PDT-11/150 – Part 7. The disk drive belts.

I ordered a pair of 590mm belts from http://www.beltingonline.com/ and  they arrived very quickly. The original belts were 588mm so 590mm should be fine. However, they are too small and don’t fit.
How can a belt that is 2mm bigger than the original be too small? The answer is in the detail or more specifically the tolerances. It says on the website the belts between 500mm and 980mm can be out by +-1.5%. So there’s the problem. The bigger belts may actually be smaller and these ones are.
The motors in the drives are mounted on slides and so can be adjusted to compensate for belt variation but even with the motor adjusted as far as it will go, the new belts still wouldn’t fit.
Back to the supplier. Next I ordered two 600mm belts and these too arrived very quickly.
These fit just fine.

Try again.

So how are we doing now? Mixed results I’m afraid.
The in depth software test is still telling me that there is a problem with drive 1. However, things are a little different with drive 0.
With no disk in drive 0 I see the image on the left, “Read error”. I also see it with an unformatted disk in drive 0 and even with the only PDT disk I have. There are differences however.
With either no disk or an unformatted disk, the message appears very quickly. With the system disk, it retries seven or eight times before showing the message.
I am reasoning then that the drive is able to read something but doesn’t like what it’s reading. I am taking this as progress.
 

DEC PDT-11/150 – Part 6. Looking at the disk drives.

I am now at the point where the disk controller is passing the RAM test but is hitting another fatal error. The Manual says there is a problem seeking to track 0 and I should replace the defective drive.
That’s more than a little harsh and frankly isn’t an option.

Take a look inside.

When I unscrew the rear cover on the bottom disk drive I am greeted with this image..
It seems unlikely that someone packed a spare drive belt 😉
There is nothing so obvious looking in to the top drive but on removing the drive I get a similar story.
This is the top drive bay with the drive removed.
You can clearly see that both drive belts have fallen off their respective pulleys.
So what has happened is that the belt have lost their condition over the thirty or so years that they’ve been on the drives and just don’t grip any more.

What to do next?

As you can imagine, new belts from DEC are not an option, so I need to improvise a little.
Snipping through one of the belts and measuring gives a length of 588mm and so a diameter of 558/pi which equals 188mm.
Record deck belts are available around that diameter and I have one on order but the suggestions on-line say they aren’t a good option as they tend to be stretchy.
I have also found a flat industrial belt at 590mm length and so I’ve ordered a couple of those.
I’ll let you know how I got on.
 
 

DEC PDT-11/150 – Part 5. The new disk controller RAM arrived.

In the last post I had found a faulty RAM chip on the disk controller board and ordered a replacement from a supplier on ebay.
Well, the part arrived Today and one fitting, the error lights on the disk controller went out… For a while.
I can confidently say that we are past the RAM errors and it is trying to boot but the drive makes a lot of stepping type noises and doesn’t settle down for quite a while. Then the some LEDs on the main board and the controller board light up.
This is what we have this time.
This time, according to the manual, they don’t mean RAM error. This time they mean.

1, 4&5 on the main board.

This manual says that this “Verifies that the second pass of the disk drive diagnostic was successfully completed. If an error is indicated, refer to Table 5-4 for the possible fault indicators on the Disk Controller module test phase 2.”

1 on the disk controller.

The manual says “Verifies the position of the disk drive 0 head after a restore command is issued.” and the course of action is “Replace defective drive 0 or module.”.

Replacement isn’t an option so I’m going to have to go in and see what’s occurring.
 

DEC PDT-11/150 – Part 4. Self tests and the drive controller

I have been running some tests and learning a lot about this little machine and its ways.
It has two layers of self-test. The first is a mandatory Power On Self Test (POST). The second layer is an optional interactive test made available by setting switch 4 on the main DIP switch block and activated by the toggle on the back panel (replaced in part 1)
In my second post I couldn’t get to the optional test no matter how I set switch 4 inside and the toggle switch on the back. Instead I was getting an octal number and being dropped into the ODT.
I naively thought that this was some kind of RAM value. It wasn’t. This was in fact an error code from the POST. The value I was given, 170732 means there is a RAM fault on the main board. I have spent some time re-seating all of the socketed chips and I think that’s what fixed this.
So the reason I couldn’t get to the optional test suite was that the POST was failing.

Past the POST.

Now that the basic POST is passing, I can get beyond that to the attempts to boot I showed in the last post.
At this point it doesn’t make any obvious attempt to access the disk drives. I would expect a little graunching to find track 0 or something similar but there is nothing.

Test mode.

I can now try setting the DIP switch and toggle to enable the test mode. With this done and a reboot I get nothing on the terminal at all. Flick the toggle for normal mode and it’s back to the boot prompt. Set the toggle to test and nothing.
The PDT-11 has a number of status LEDS on both the main board and the disk controller. Setting for test mode again, opening up the lid and separating the boards shows us a number of clues.
The main board switches are showing 01111 which means “1 Disk controller module” or “2 Cable G1”. The cable looks fine so it’s the disk controller module.
A look across to the disk controller and its lights are showing 0011 which means  that the LSB RAM IC is faulty. If that’s true, switching the two RAM chips over should move the problem to the MSB.
A quick switch later and the error code on the LEDs has changed to 0010 which means the MSB is now faulty.
These chips are 4bit x 256 bits and some new ones are on order. 🙂

DEC PDT-11/150 – Part 3. Healing hands.

I was preparing to share with you all my efforts driving the ODT with PDP11GUI.
I have been using it to assemble Marco-11 assembler code and squirt it across to the PDT’s ODT. The problem is that when I came to fire up the machine to do a bit more and maybe take some screenshots I can’t get to the ODT because the machine is now asking for a boot floppy!
So that’s how you get it to try and boot. You write about it on your website and shame it into trying. I am part delighted and part deeply suspicious. Computers don’t heal by themselves.
I kind of miss the ODT to be honest. At least with that I could make some progress and fire octal code at it.

So what happens now?

Not much. It doesn’t seem to touch the disk drives when I answer its question. It just tells me there is “No boot on volume” and asks me again. It doesn’t even seem to rattle the disk.
The funny thing is, when it only went to the ODT, it seemed to get the drives to seek to track zero and it’s stopped doing that now. Curious.