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.