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.



Leave a Reply

Your email address will not be published. Required fields are marked *