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.


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.


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.


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


jp loop


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.



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 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.


DEC PDT-11/150 – Part 2.

In the last post I described the PDT-11/150 a little bit and the state of play. It was showing signs of life but not talking to me.

It turns out the cable wasn’t right. Switch to a new cable, fire up GtkTerm and we’re on the right lines.

What we have here is the ODT display. It doesn’t look much but it shows us that the machine is alive and conscious.

Main switch settings.

There is a five switch DIL pack on the top board that sets various options for the machine. The manual gives the following explanations:-

IT seems a little odd that the switch labelled “Auto Baud” should be set to off to turn Auto Baud on. Really? Ah well.

Mine are set as follows:-

  1. ON – Auto Baud is disabled. Baud rate is set to 9600.
  2. ON – Line clock is disabled.
  3. OFF – Enable the DRAM refresh.
  4. OFF – Disable the test mode.
  5. OFF – Disable manufacturer mode.

Setting the switches this way I can get to the prompt you see above.

I have tried getting into the test mode but it doesn’t seem to work on my machine. I wondered if the self test at power up is failing and dropping me into the ODT but the error light on the front goes out so I guess not.

I haven’t turned on the line clock as I don’t know yet if I need an interrupt handler for it. Clearly we need DRAM refresh and fixing the Baud rate at 9600 is just A Good Thing (TM).


Now here’s a thing. I can’t find any information about how to get this thing to read a floppy. The manual describes setting the switches to get test mode. It says how to insert a floppy and how to handle them safely but nothing on how to boot the machine.

I’ve looked at both the technical manual and user guide (thanks to Bitsavers) but there is nothing.

A little test.

Although I can’t boot from floppy, I can fire in code using the terminal and things are starting to look brighter.

Here is an example from the ODT page on wikipedia.

This fires the letter ‘A’ at the console port as fast as it can and only stops when you press the reset switch.




DEC PDT-11/150

This is an unusual one. The PDT-11/150 is one of a series of “smart terminals” based on the PDP-11/03’s LSI-11 chip set and so is basically a little PDP-11 atop a pair of massive 8″ disk drives.

It came to me from a friend who presides over a massive collection but is still, like the rest of us, unable to keep everything. His collection is mostly home machines and quite game focused and this business machine doesn’t fit and so I got a message.

This is just the kind of thing I love. The left-field, unloved and under appreciated machines like this are just the cut of my jib.


Looking on the net there is not a lot of details on this one but according to the manual has 16 or 30 (sic) k-words of RAM, 2ย  8″ floppy drives and 6 serial ports. The processor is the LSI-11 in 3 chips.

From the front the machine is dominated by the floppy drives. The processor and all it’s additions are under the small “lid” and behind the smart label…

The state of things.

It’s not working… I don’t think there is much wrong with it as when I apply power, the disks make moving noises, the LEDs on the front light and go out but I can’t get any life out of the serial port and onto my PC that’s running a serial terminal.

Things to do.

The run mode switch on the back had been bent and become a bit flaky. I’ve replaced it with a new one (RS part number 7109551) but it didn’t make it run properly. It did give me a feeling of satisfaction though ๐Ÿ™‚

A short step from where you are.