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.
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.
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.
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:-
- ON – Auto Baud is disabled. Baud rate is set to 9600.
- ON – Line clock is disabled.
- OFF – Enable the DRAM refresh.
- OFF – Disable the test mode.
- 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.
So another Retrochallenge comes to a close.
What did I do lately?
Well, in the last 24 hours I have tested all of the 74 series chips, with the exception of the 74LS163 (my tester won’t touch them). All were fine, no problems at all.
I swapped the 74LS 163s around to see if the fault moved. It didn’t.
I swapped the 81LS97s, again to to see if the fault moved. It didn’t.
Where are we?
It’s hard to tell.
My newest addition is still not playing ball and I’m stumped as to why, but, that’s not the point of Retrochallenge. The point is to dust off this old kit and have a play and I’ve certainly done that 🙂
Roll on RC2018/4
Well progress has been slow but thanks to some helpful and knowledgeable people (here), progress has been made.
So what do I know now that I didn’t know before? Well, I burned a ROM that just tried to access an imaginary I/O port. When I ran that and watched the _IOREQ_ line, I saw it going up and down which suggests that the program is running correctly from ROM. I put one of my screen-filling ROMS in that just access ROM and screen RAM and didn’t see any _IOREC_ activity so I think I can safely say that the processor is up and running.
About a screen.
I wanted to see if the screen output I’m seeing is coming from video RAM or is being created on the fly by the hardware fault.
So I pulled out a video RAM chip. When I powered on the machine and reset it, the pattern on the screen was different to what I had seen previously. I took another RAM chip out as well and saw a different pattern. Each RAM chip on the Nascom-1 is 1 bit wide and so unfilled sockets will make the corresponding bit float high when accessed.
I think this means that the video RAM is being read correctly or at least feasibly by the video circuitry.
So now I’m looking at the memory addressing and swapping chips to see if the symptoms change. I’m also waiting for some spare 74LS chips to arrive so I have some contingency.
So here we are, two thirds of the way through the month and the Nascom-1 is looking just as it did when I started 🙂
But now, take a look at this picture…
This is the Nascom with a ROM in it that fills the screen with NULLs. I’ve just pressed reset.
Now look at this photo…
This is a different ROM. This one fills the screen with ‘*’s. Again I’ve just pressed reset.
Their behaviour with these ROMs after reset is pretty consistant but not guaranteed.
But what does it mean?
I don’t know, but I’m sure it means something. It could mean I’ve mucked up the ROMs. As 2708s are hard to find and program, I’m using a 2716 in a little adapter that I made myself but they look fine.
With the alternative ROMs in place, we’re only using the screen RAM and the addressing logic, buffers etc.
So here’s a thing. I recently met up with an old acquaintance who I hadn’t seen in years and as we’re both retro-computing fans we were talking about old machines.
I have just received an email from an old acquaintance of mine who is a dedicated retro-computing fan and has spotted my plight in these pages after following me on Twitter (@acollins22 if you’re interested).
He mentioned that he had had a similar problem on a Nascom a few years ago and it was caused by a buffer failing. Now I know this is wishful thinking but it’s worth a look.
The chip in question was an 81LS97, a 3-STATE Octal Buffer.
I’m not the most familiar with this to be honest, a keen amateur. My take on this is that Y1 will equal A1 when _G1_ is low. At other times it will be tri-stated. The other pairs (A2-Y2, A3-Y3 and A4-Y4 will do the same).
Is this right.
I wired up my old Blackstar logic analyser to IC47, the 81ls97 as follows…
- CH0 – _G1_
- CH1 – A1
- CH2 – Y1
- CH3 – A2
- CH4 – Y2
- CH5 – A3
- CH6 – Y3
- CH7 – A4
It’s set to trigger on CH0 being low. This is what we get.
What I see here is CH0 going low and so the outputs are enabled. Surely that means that CH4 should echo CH3 but as you’ll see, it doesn’t.
Does that mean I have a faulty 81LS97 or a faulty understanding of what’s going on. It seems a coincidence that a friend tells me how he fixed his Nascom and mine has the same fault but the trace above suggests just that.
Having checked the clocks and finding things look well, it’s time to see if the ROMs are OK.
The Nascom uses 2708 EPROMs. These are 1k by 8 bits and must have been one of the first EPROMs available. The problem with them is that they need three different voltage rails and most modern EPROM programmers can’t do that. Even my old Stag won’t. :-(.
I can program 2716s however as these only need a single 5V rail and thanks to tkc8800 I was able to make a couple of plug in adapters so I can use the bottom half of two 2716s to replace the 2708s.
I have now put Nassys3 in the two 2716s and tried that.
Still the same… Arrgghhh!
In my last post I was suspecting the clocks.
Now I’m not so sure there is a problem with the clocks. Having traced them through everything looks fine. I’m not sure what I was doing wrong but the symptoms haven’t changed but I’m seeing bus activity now and also the _CS_ on the main 2708 EPROM is wiggling around as I suspect it should.
I’ll see if I can read the EPROM and see if it has bit-rot.
EDIT…. It turns out my programmer can’t read 2708s. Doh.