Category Archives: Nascom-1

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.



RetroChallenge 2017/10 – Slow progress

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.


More soon.

RetroChallenge 2017/10 – Mid challenge – all the red herrings.

Oh now this is getting a bit disappointing.

It was a bit too much to think the tri-state buffers had failed and changing them one by one made no difference. Hmm.

I think that the screen memory is OK because the noise on the screen shows each of the bits both set and cleared so no sticky bits either high or low.

I wrote a noddy program and blew ROM just to clear the video RAM and nothing else. It didn’t fix anything but, on reset it tends to look a bit different. I’m not sure what any of this means.

Sometimes I do wish I could get an old machine and it would just work.

Never mind. More next time.


RetroChallenge 2017/10 – Purely by coincidence

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.


RetroChallenge 2017/10 – More things it’s not

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!


RetroChallenge 2017/10 – Still looking for clues

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.

RetroChallenge 2017/10 – and the beat goes on

Yesterday I checked the voltages with my DMV and everything looked OK. Today I checked with the ‘scope just to check for ripple and they all look pretty clean to me.


I also saw that there was a running clock but overnight I became increasing worried that it wasn’t a very good clock.

Here’s the circuit…

It doesn’t look too tricky.

Check with the scope.

A scope trace shows it’s a bit funny. I’m not sure quite what the Z80 needs but I thought it should have a better back edge than that.

More thought needed.

RetroChallenge 2017/10 – Let’s see what we’re up against

So, it starts.

In my last post I said that I intended to fix my newly acquired but already much loved Nascom-1.

Up until now I hadn’t even powered it on but the time has come.


So that’s it, random nonsense. The reset button makes the screen flicker but the nonsense doesn’t change.

The previous owner said that he had tried a new CPU, cleaning all of the tarnish of the chips and the 74LS139 and 74LS11 associated with the video RAM address decoding.

He’s clearly better at this than I am but I’m still going to try and get this old one going.

First things first

Out with the multimeter and check the power supply. There are three rails; 5V, -5V, 12V and -12V. Helpfully there are four LEDS on the PSU board and they are all lit up. Also, the meter confirms that all are present and correct.

The bits on the bus go up and down

Sadly actually most of them don’t. I fired up the oscilloscope and looked at the signals on the pins of the Z80 CPU. There is very little activity. There is a clock signal on pin 6. MREQ is toggling. There is little else. There is no activity on M1 that signals the start of an instruction. The data pins are all high as are the address pins.

Surely there should be activity on the address bus?

That’s it for Today. I will read up on bus access and try to see why the address lines aren’t changing.