Prior to determining if POC V1 would actually compute, I had to verify that Vcc
was being correctly distributed to all areas and that no faults were going to occur at power-on.
I had already metered between Vcc
and ground to verify that no catastrophic short was present.
The next step would be to actually apply power and confirm what the ohmmeter test had reported.
Here again, long experience in bring new circuits to life got into the picture.
I started by removing all chips that were socketed, as well as the two
clock oscillators—the only silicon left on the board was the SRAM and
The idea was to avoid damaging the "expensive" stuff in the event a
serious circuit error put power where it didn't belong.
It should be noted that PC power supplies are capable of producing
copious amperage, certainly more than enough to turn chips into crispy
critters if something goes awry.
If the load is sufficiently severe the power supply will "crowbar" and
immediately cut off output.
However, that would still produce high current flow for a fraction of a
second, more than enough time to take out something.
|Initial Test Setup — Click on Images to Enlarge
The application of power was uneventful.
The "power good" LED illuminated and some poking around with both the
meter and logic probe indicated that things were okay so far.
Next I tried powering it with the two clock oscillators installed.
My ancient Beckman dual-trace oscilloscope indicated that the Ø2
clock oscillator was running and that the clock generator flip-flip was
producing an output.
A check of the DUART's baud rate clock generator showed that it too was
Incidentally, that old Beckman 'scope in the above picture has a 20 MHz
bandwidth, which is why the Ø2 signal isn't a pristine square
The el cheapo test probe I was using didn't help any.
Lastly, I metered the charge pump outputs on the MAX-238 TIA-232
transceiver and found the voltages to be in range.
Just to satisfy myself that the transceiver would work, I attached my
ancient TIA-232 diagnostic device to both ports and got the correct
With all of these preliminary steps completed, the next step would be to
plug in the remaining chips and see if the thing would
There was no reason to think it wouldn't.
In order to determine if the MPU was running I would need to have it
execute some instructions while monitoring the address and data buses
for signs of activity.
There are two ways to go about providing test code:
a NOP generator
plugged into the ROM socket or an actual ROM that has been loaded with a simple program.
I decided to go with the latter and prepared three ROMs, one for the
initial test, a second one to do some read/write operations on RAM and a
third to do some read/write operations on the I/O hardware.
The code in the first ROM was minimal:
$00E000 4C 00 E0 JMP $E000
The endless branching back to $E000
would cause both
address and data bus activity that could be monitored with the logic
probe. Initially, I would watch A0
since the above program should cause the MPU to repeatedly assert those
lines as it fetched the opcode from the ROM. I'd also see
activity on D0
as the MPU first
fetched the opcode and then the operand. If I did see such
activity then it was an indication that the MPU was probably upright
with a pulse and POC V1 was operational.
Operation with the first ROM demonstrated that there was MPU
activity—all observed bus signals were active. Operation with the
second ROM was likewise successful. The code in this one was a
little more elaborate:
$00E000 A2 00 LDX #$00
$00E002 8A TXA
$00E003 95 00 STA $00,X
$00E004 D5 00 CMP $00,X
$00E006 E8 INX
$00E007 80 F8 BRA $E002
Here I also watched the /WD
signal, which should be pulsing on each write cycle (STA $00,X
), but only when Ø2 is high.
Its action showed that the read/write logic was correct.
This is where a dual-trace 'scope comes in handy: one channel was watching Ø2 and the other watching /WD
Also, I was using Ø2 to trigger the 'scope.
A check of the SRAM's /CE
input showed that it was being selected when it was supposed to be.
Also, all data lines were pulsing as the program wrote successively larger values into each RAM location.
So far, so good!
The third ROM was similar to the second except it was accessing one
of the read/write configuration registers in the DUART.
After a quick check to make sure the MPU was running I probed the /CEN
(chip enable) input on the DUART to verify that it was being selected.
It was continuously high, not good!
It should have been pulsing.
is driven by the /IO-0
output of the 74AC138 decoder, and like /CEN
was continuously high.
That meant either the 'AC138 was defective or was not being enabled when it should be.
I decided to pursue the latter case, since the days when chip defects were common are long gone.
A quick check with the logic probe confirmed what I had suspected.
During the PCB layout I somehow missed connecting A12
to pin 9 of U6, which is a quad-input NAND gate.
not present, the gate wasn't driving the /E1
(enable) input of the 'AC138, so the decoder wasn't being enabled when any address in the $Dxxx
range was being emitted by the MPU.
A short piece of wire-wrap wire took care of the problem (see below—black arrow points to patch).
Now the DUART's /CEN
input was pulsing, as was its /RDN
(read enable) and /WRN
(write enable) inputs.
With these signals acting as they should, I had proved that all basic
logic functions were working and that the MPU could access RAM, ROM and
Now I needed to get the unit to drive the console terminal.
Here's a picture of my augmented test setup:
Yep! That's a TV tray on which the WYSE 60 terminal is
sitting. A little wobbly, but perfectly adequate.
Also, note the ancient RS-232 tester hooked up to the terminal—it's that
gadget attached to the blue ribbon cable that's resting on the
I had it there just in case something hinky occurred with the serial
However, before I could try out POC V1 I had to cobble together enough
code to perform a basic POST (power-on self-test), configure the I/O
hardware and produce a display.
I started with a very simple ROM that did little more than initialize
the stack pointer, load some configuration values into the DUART and
write the byte $41
to the DUART's channel–A TxD
(transmit) register, which should display the letter A
on the terminal screen.
As I had prior experience with the DUART's big brother, the SCC2698
OCTART (functionally four DUARTs in one chip), no learning curve was
required to write a simple DUART driver.
Like its predecessors, this ROM used the MPU's emulation mode, which is
the default at reset—I didn't want to introduce too many things to go
wrong into this first effort.
I plugged the ROM into POC V1, powered everything, and the letter A
My very first scratch-designed and built computer was functional!
To say I was pleased that it worked on the first try would be an understatement.
Given all that could go wrong, I was ecstatic, actually.
The next ROM, still operating in emulation mode, had a more elaborate POST screen driven by interrupts, along with a simple
loop to verify that two-way TIA-232 communications were working.
It took several days to write the code and visually verify the logic, which also included a rudimentary memory test.
I tested some parts in the
to avoid having to try to debug the ROM in the event it failed to produce the desired results.
Finally, on December 27, 2009, the ROM was ready.
I powered everything and was greeted with the following display:
Once the above had appeared, I type a few characters and saw that my
typing was being echoed to the screen, demonstrating that
bi-directional, interrupt-driven serial I/O was working.
To quote my friend Lloyd Sponenburgh, who replied when sent the above
picture via E-mail,
Having leaped over the initial hurdle of getting POC V1 into operation, I
went to work in developing more elaborate firmware, including code to
detail-test memory at boot time, and cause the watchdog timer to
and maintain a 32 bit uptime counter.
I also wanted to see if I could design a fancier POST screen using the
terminal's block graphics capabilities.
Along the way, I ran into an interesting hardware bug (mentioned earlier
on the system design page) that resulted in several pages of discussion
6502.org hardware forum
Previous Page Home Next Page