Testing a 6502 CPU

 It's relatively easy to test the UK101's discrete TTL chips using a simple Arduino-based IC Tester, and the ROMs can be read by an EPROM programmer but what to do about the more esoteric chips, i.e., the CPU and ACIA?

As CPUs go, the 6502 is a masterpiece of simplicity. It turns out that you can have it run the most basic of programs with no support logic whatsoever! This is the well-known NOP test, in which the CPU is fed an endless stream of No-Operation instructions, see for example here.

Breadboard 6502 flanked by Clock Circuit (L) and Logic Analyzer (R)

The image shows the test-set-up. The board on the left is a Micro UK101 which is only used as a power-supply, reset switch and clock source. (This is a more rewarding way of testing CPU and ACIA, but only if they both work!)

The CPU does not need many connections to run the NOP test: its data-bus is hard-wired to EA (the opcode for NOP), it also has IRQ and NMI tied high, and the input clock and reset line from the Micro UK101.

 

The logic analyser on the right is a cheap 8-channel model which works with PulseView. It is triggered by the reset pin (high-to-low transition) and samples A0, A1, A2 and the output clock.

When powered up and reset, the 6502 reads its reset vector at $FFFC and $FFFD. Unsurprisingly it reads the address $EAEA and jumps there. It then reads an endless stream of NOPs at every address between $0000 and $FFFF. Its address pins will show this.

Or they would show this, if the CPU was working. The screenshot below shows what happens most of the time:

Dead

The top trace is the reset line and the bottom one is the output clock, which seems to be working. The three lines in the middle are A0, A1 and A2 with nada.

However sometimes the CPU shows signs of life. About every 10 resets, there would be a short burst of activity for a few microseconds:

Some signs of life

So it looks as if this CPU is a goner. It was made by Synertek in the 35th week of 1980 and spent the last 40-odd years in a cold damp attic, where it expired: RIP.

Update: Hans Otten has written about NOP testers here.

TommyPROM

Some time ago, I mentioned that I had been unable to test the various ROMs in the UK101, lacking an EPROM programmer. That has now been rectified, thanks to the fine work of Tom Nisbet, creator of TommyPROM. 

In addition to an Arduino sketch, the Github linked above hosts a couple of circuit boards, and I had them made as part of my last order from Seeed Studio.

TommyPROM with a very old 2716 EPROM

Populating this PCB cost under €10, quite the bargain. This version of the programmer can read 27-series EPROMs but can't manage the voltages required to program them.

Configuring the programmer requires editing the Arduino sketch for chip series and type, and uploading the modified sketch. This wouldn't pass muster in a commercial product but is absolutely fine for this project's target market: hobbyists on a budget.

Opening a serial port to the board shows the following menu:

Main Menu

Reading that EPROM, which is nearly 40 years old, produced the following output:

Amnesia?

Unsurprisingly, given its age, it seems to have lost its memory! Luckily it is not too difficult to find copies of UK101 (and Superboard) firmware online, Mark's Lab has copies for instance.

Burning old-school 27-series EPROMs requires more advanced hardware, and the second TommyPROM board I had made can do it, TommyPROM32. I will review that iteration when I have assembled it.

What the current version of TommyPROM can do is write to 28-series EEPROMs, e.g., an AT28C16. This is pin-compatible with the 2716 so once it arrives and has been programmed, the next step in testing the UK101 can be taken: hooking the board up to a logic analyser and spying on the data bus using another fine Open Source tool: 6502Decoder.

(I have several PCBs left over from that order. If you want one at cost, PM me.)

Update (April 2024): after some further investigation, it turns out that the basic TommyPROM can only handle 28-pin chips so any data retrieved from smaller chips (as above) won't be valid. TommyPROM32 is definitely the way to go here. Stay tuned for a review of that coming soon!

Bodge Wiring

A bodge wire is defined as a "wire added to a PCB to fix errors in the layout or broken traces." The first is as a result of a design fault while the second arises from mistakes made in maintenance of an existing PCB.

Bodge wires don't introduce new functionality, they only restore intended functionality. Therefore they should be as unobtrusive as possible.

When restoring an old computer, bodge wires are frequently necessary to fix traces which have broken due to excessive heat during the desoldering of defective parts for replacement, most often ICs and IC sockets.

Bodge wires

When a trace lifts or breaks, I mark the PCB on the top-side with Tipp-Ex as a reminder that a bodge will be necessary sometime in the future. The bodge is then later made on the bottom-side of the board, to keep things tidy.

Bodges required!

It can be useful to differentiate bodge wires from wires adding functionality by colour, or adding functional wires to the top-side of the board.

Kynar wire, Wire stripper and Magnifier

Essential tools for this are 30 AWG Kynar wire, a Wire Stripper and Eye magnification of some kind. Care is needed to ensure that the correct joints on the bottom-side are actually the correct ones. Check your work with a continuity tester!

Some useful additional tips in the EEVblog.

Testing ICs

It seems like about two years ago, IC testers made quite a splash, judging by reviews of the Retro Chip Tester Pro (Adrian's Digital Basement) and the BackBit Chip Tester Pro (Noel's Retro Lab). Nice products though they are, they are a little out of my price range for this project.

TTL testing

Luckily for my wallet, there are several DIY projects out there which can be assembled from commonly-available parts in not too long. Nick Gammon (who's excellent interrupt and power-saving pages were inspiration for my Interrupted project) has a super-simple one which can be assembled on a breadboard in about an hour for the cost of 16 resistors, some dupont connectors and an Arduino Uno!

It ain't pretty but it works!

Nick credits an Instructable by one "JorBi" for inspiration for his work. That project is more elaborate, using an Arduino Nano and a display --- Nick's just uses the Arduino serial port, nothing wrong with that. JorBi's project also provided the data file containing the actual chip tests: JorBi stores this in an EPROM while Nick puts it in the on-chip flash.

Another tester of note is the Smart-IC-Tester: an Arduino shield with TFT display. This stores the test database on an SD card, in a format very similar to JorBi's, just adding a one-line description to each part.

So? Well out of 34 74-series TTL chips on the UK101, Nick's tester flagged 7 as bad, 15 as good, 4 were unknown and 8 not tested, due to having wires soldered to them. Not bad for a day's work!

The bad chips were as follows:

• Two 74125s
• Three 74123s (all from the same batch)
• One 7403
• One 7404 (in bad shape, one pin broke off in the socket)

Note, it could be that the 74123 and 74125 tests are incorrect. I have none which tested good.

Update: After playing with the IC-Tester for a while longer, I managed to add tests for the hitherto-unknown chips. The latest score is 9 bad, 22 good and 3 not tested. My fork of Nick's repo is here.

Update 2: I built this circuit on a piece of vero board and piggy-backed it onto my home-brew Uno!

An improvement anyway!

Memory testing

In addition to the discrete TTL chips, the UK101 also had 32 2114 static RAM for main memory and another 4 for the display. Nick's tester is unable to test this IC. Luckily somone named "skjerk" has written a sketch for the Arduino Uno which does exactly this.

The 2114 has a pretty bad rep when it comes to living into old age so I didn't hold out much hope for my set. Rather incredibly however they all came up good!

Untested so far

Chips which I haven't been able to test yet:

• The 6502 and 6851
• The Basic ROMs and Character Generator ROM
• The monitor EPROM

Given an EPROM programmer, it should be possible to read the ROMs and compute their checksums. Stay tuned for that!

Of course the two commercial testers mentioned above can test all of these chips, out-of-the-box. But where's the fun in that?

Desoldering stuff

Progress? Maybe!

Last time, the next planned step was to remove all of the bodges and restore the machine to something resembling a "factory configuration". This aim has changed slightly: a lot of the bodges are gone but some remain:

• The 48x32 display mod was just too tricky to undo without a display to test it against.
• Similarly will leave the 300/600 baud and RS-232 mods until a later time.
• The monitor switch mod also stays until the EPROM has been verified to work.

So what has been done here?

• The piggybacked RAM and its decoding logic is history. New sockets were added where necessary.
• The 6522 VIA board is also gone.
• A new expansion socket was added to facilitate testing with a Logic Analyzer.

To replace the IC sockets I found the following tools essential:

• Soldering Iron and solder
• Desoldering pump
• Headband Magnifier
• Bench vise

Don't expect existing IC sockets to survive this process! 

1. Use the desoldering pump to remove most of the solder; this helps free some of the pins but others will probably remain attached. 
2. Gently lever the socket away from the board: it will likely break, leaving some pins in place. 
3. Desolder these one by one. 
4. Some VIAs will most likely remain at least partially full of solder. To clear them, mount the board vertically in the bench vise and heat each VIA from one side while applying the desoldering pump from the other. It may be necessary to fill the VIA with solder before attempting to clear it, counter-intuitive but it works!
5. When inserting a new socket do not use force. If it doesn't go in easily, repeat step 4 until it does!

To desolder an unsocketed chip:

1. Use the pump to remove most of the solder as before.
2. With a small screwdriver gently push each pin until a click is heard. This means the pin is mostly free of solder.
3. From the other side of the board, gently lever the chip away from the board. If it doesn't move, mount the board vertically as before, heat the pins on the chip side while applying the desoldering pump from the other. Repeat!

This all requires patience, and a steady hand! 

Flux pen, Desoldering braid and Pump

I also ordered a flux pen and desoldering braid which should be as good or better as the desoldering pump. However I wasn't able to get good results with it. Perhaps my soldering iron isn't hot enough?

Adrian's Digital Basement has a great tutorial on this subject. He also has better tools than I do!

Restoring a UK101

 

Yes children, computers looked like this once

This contraption is a Compukit UK101 built over 40 years ago by me from a kit. If I remember right, the kit cost £99 (so must have been one of the last ones) and was smuggled across the UK-Ireland customs border in my parents' car.

Its home is a case made out of aluminium by my brother in our school's metalworking shop. Until fairly recently it resided in my father's attic before being rescued in a clear-out.

An unusual feature (by modern standards anyway) was that its manual contained full schematic diagrams. This led to the proliferation of many third-party hardware modifications, in addition to the ones mentioned in the manual itself. I implemented several of the easier ones.

Under the hood.

Under the hood, it is quite a mess! This was a result of inexperience and lack of funds to "do things right". Looking at the board now, the modifications I seem to have made (or at least attempted) are:

• Switchable Monitor ROMs
• Double-speed CPU, to 2MHz
• Double height display, to 64x32 characters
• Double-speed tape interface, to 600 baud (or maybe even 1200?)
• RS-232 interface (used to communicate with a Sinclair QL)
• 8kB RAM expansion, from 1kB (below the UHF modulator and PSU)
• Extension ROMs 
• VIA-6522 board (above the keyboard, on the right)

Some time in the 1990s, I pulled all of the ROMs and read them to use as the basis for an emulator which has been described before here. This explains the empty sockets above the keyboard, on the left.

Whether it still works or not is anyone's guess but inspired by Usagi Electric's fine work on a Centurion mini-computer, I've decided it might be an interesting project. A rough outline of the steps involved might be:

• Verify the power-supply is working. Done!
• Remove all of the piggy-backed chips and other bodges; replace IC sockets where required; test RAM chips and leave 1kB system RAM and 1kB display RAM.
• Using a 16-channel logic analyser and the excellent 6502 decoder project, verify that the system boots by comparing the CPU trace to that from the UK101 emulator.
• Clean up the video circuitry by connecting to a video monitor, either by buying an old one second-hand, or using this adapter to connect to a modern (HDMI) one.

Once all that has been done, I can start to think about adding new hardware:

• 32kB static RAM chip (62256-80 seems to be suitable) and 16kB ROM (27C128). The former will occupy the lower half of the address space (0000-7FFFh) and the latter the next quarter (8000-BFFFh).
• Display modifications: double-height, colour.
• I/O board: disk controller, VIA

One very interesting possibility would be to build a "universal hardware module" out of an Arduino (e.g., an esp32). This would run a modified UK101 emulator and provide all of the missing hardware by listening on the address bus, data bus and CPU control lines. The CPU would initially have no RAM or ROM: it would all be provided by the emulator. (This idea is reminiscent of the ROMulator as featured on Adrian's Digital Basement but would be more flexible.)

Quite a laundry list there: stay tuned!

Tinysensors Redux

 

Raspberry Pi Zero-W with Tinysensor Hat

It is often instructive to revisit an old project: you never know what you might see with fresh eyes. Such is the case with Tinysensors, which has featured here several times over the years. Since it lives in Github I use that platform's Issues feature to collect ideas which pop into my head when I am otherwise occupied. This provides a nice context from which to start revisiting.

Among the issues addressed since the last time we featured this project are:

• Switching to the ATTinyCore. From my point of view, the most important feature of this great project is its support for Optiboot. This decreased the testing time for changes to the Tinysensor sketch by an order of magnitude. No more external programmers!
• Removing the RF24Network library. This supports a very versatile model of organising nRF24L01+ radios into a fully-connected 5-way tree. However it necessarily limits the number of leaf sensors to 5, requiring bridges to interconnect different levels. A star topology removes this limitation, and also reduces the code footprint enough to support debugging via SoftwareSerial.
• Reducing power-drain. With the above improvements in testability, it didn't take long before a gotcha in power consumption was spotted: a voltage divider made with a built-in pullup resistor consumes current even during SLEEP_MODE_PWR_DOWN!
• Moving the hub to Raspberry Pi Zero W. This has more memory and more processor for smaller footprint; in addition to built-in WiFi and Bluetooth. Once that was complete, a proper Hat was designed to hold the nRF24L01+ radio and status LEDs... and a power button, just 'cos.
• Outsourcing the RF24 library to nRF24. These guys have put a lot of work into improving the performance of Maniacbug's excellent original library, which means I don't have to!

Future work? A nice next step might be to redesign the sensor PCB for a coin-cell and surface-mount components. However I'm pleased enough with these changes to park it for another couple of years!