Okay, so it was time to deal with something that has been nagging at me for a while.
I have this Apatco kit 6502 breadboard computer kit and never quite got around to finishing the basic setup. It takes a lot of wiring. I just got tired, put it in a box and shoved it in the projects cupboard.
For months I’ve been feeling guilty about this. Then, when I finally sat down to make a final push to the finish, I found that I had only about another half-dozen wires to hook up. I’d been confused by all the wires left in the components box. But it turns out they give you lots of spares. Doh!
Programming the ROM
The next step was to program the EEPROM. In the basic kit, you’re supposed to do this early in the project. But I’d bought the extended kit with an LCD display and PS/2 keyboard interface. This comes with its own, pre-programmed ROM, so I’d skipped the programming step.
But before going on to wire up the advanced kit, I wanted to check that the basic setup was working. The best way to do this was to go back and program that EEPROM – an Atmel AT28C64B, for those playing along at home.
The way the instructions tell you to do it is to set the address and data pins on the EEPROM using jumper wires to the +5V and GND rails. With these wires setting the appropriate values on the buses for the first byte, you disconnect the /WE pin from the +5V rail and connect it briefly to the GND rail. Then you reconnect it to the +5V.
After that, you reconfigure all the address and data wires for the next byte.
It sounded horribly slow and tedious. There are 40 bytes to write and the manual says to allow 1.5 hours!
Instead, I rigged up something a little more comfortable. For the address and data lines I used DIP switches. On the lower side, they connect to the pins on the EEPROM and, via a 10kΩ resistor, to GND. The opposite sides of the switches are connected to +5V. When a switch is open (off), the pin on the EEPROM is pulled low via the resistor. But when the switch is closed (on), the pin gets a direct connection to +5V.
I also added an eight-segment bar LED to the data lines, to see what I was entering.
Finally, I added a tactile switch. On one side, this connected to the /WE pin on the EEPROM, which was also pulled high by a 10kΩ resistor. The other side of the switch connected to GND, so pressing the button would temporarily pull down the /WE, thus writing the byte set on the data pins to the address indicated on the address pins.
Entering the 40 bytes this way takes about 10 minutes. And most of them turned out fine. Well, some.
You see, when I plugged the EEPROM back into the breadboard and switched it on, nothing much happened.
What’s supposed to happen is that the short program uses a 6522 Versatile Interface Adapter (VIA) to turn on and off a row of eight LEDs (the kit provides separate LEDs, but I substituted an eight-segment bar LED). It works much like flashing an LED via an Arduino or Raspberry Pi GPIO.
Gah! Time to start debugging.
Checking the program
The first step was to check that I’d entered the program correctly. Doing this was simple – I chucked the EEPROM into my MiniPro EEPROM programmer and read it in.
At this point, some people will be slapping their foreheads and yelling, ‘Why didn’t you program the EEPROM with that in the first place?’.
Well, that would have been too easy. There was actually a strange pleasure to be had from entering those bytes manually, one at a time. It felt like physically pushing the code into the machine.
The problem was, I hadn’t done it very well. Only about half the bytes were correct. Most that were wrong were out by one nibble, so I suspect a couple of dodgy connections. That’s breadboards for you.
Once corrected, I checked the values of the bytes against the assembler program given in the manual. All looked good. I plugged the EEPROM back into the breadboard.
The computer still didn’t work, but it didn’t work in a different and more promising way.
Checking the wiring
The next step was to check the wiring. This breadboard machine is a mess of wires.
First, I Checked that all chips were getting the voltage they needed. They were.
The I buzzed out the address and data lines. There are four chips that have to be connected with all eight data lines and some or all of the 16 address lines. Using the multimeter in continuity mode, I checked that, for example, the A0 pin on the processor was connected to the A0 (or RS0 in the case of the 6522) on the other chips. I did this by probing the chips’ actual pins, not the wires plugged in next to them. All good.
To check if the 6502 was actually running at all, I broke out the oscilloscope. First, I made sure the oscillator was supplying a 2MHz square wave to the 6502’s PHI2 clock input. It was.
Then I checked that the 6502 was putting out clock signals on the PHI1O and PHI2O pins. Hmm. Sometimes it did and sometimes it didn’t.
I could see on the scope that, when first powered, there was a good clock signal coming out of PHI2O for a moment, but then it would disappear and that pin would go high. That brief period was where a DS1813 chip holds the 6502’s reset pin RESB low for a moment, as required by the microprocessor so that it can get its ducks in a row. It then lets it go high, at which point the 6502 starts running code.
And, apparently, crashing.
Then my eye lit upon a strange sight. As per the instructions, I’d linked together the /CE (chip enable) and /OE (output enable) pins of the EEPROM. These both need to go low for the chip to operate as a ROM. But neither of these pins were connected to anything else. That was obviously wrong. A skim through the manual and I realised that I’d run a wire from the 74LS138 decoder chip to the RAM instead of the ROM. Oops.
That fixed, I fired up again and … nope.
Again, there’s a mildly encouraging change. The clock output from the 6502 remains running solidly now, suggesting the processor is running okay, and no longer crashing. And the LEDs are flashing – but not as they should.
So, progress of a sort. The next step will be to recheck all the rest of the wiring. Stay tuned.