Catatonic Rockwell AIM-65 - test-drb@ccmp.vtda.org

4 Jun 2019

Hi, all,

I recently was given a Rockwell AIM-65 single-board computer in nice physical condition,
with the original keyboard and keyboard connector cable.
I've downloaded all of the documentation that I can find, and have been trying to get
it running.

After doing a thorough visual inspection looking for any sign of detritus, especially
anything metallic, as well as making sure all of the ICs were seated in the pretty-lame
single-wipe sockets, and checking for any obviously cooked or overheated components.   

Everything looked really nice, and quite clean.  
All of the required chips were in place, and looked good, including the 6532 RIOT, 6520
PIA for the display, and two 6522 VIAs.  All of the LSI's, including the 6502, were
Rockwell-made parts, with date codes all within a reasonable time of each other.   

I checked across the +5V and GND power supply connection points, and found that it
wasn't shorted, another decent sign.

The machine came with all five of the ROM sockets filled with original Rockwell ROMs,
including the two-ROM BASIC interpreter, the Assembler ROM, as well as the two Monitor
ROMs, all installed in the sockets they should be installed in.    The machine had six
2114's (1024x4 static RAM) installed in the lower three banks of user RAM, with two of
the sockets unoccupied.  I got two known good 2114's from my stock of parts and
installed them in the two empty sockets, so that the machine would be in the 4K of User
RAM configuration.

I understand that the machine can be powered up with only the +5V supply, but the thermal
printer will show as "down", as it requires the +24V supply.  The +12/-12
supplies are also not required.   

I made sure that the RESET switch worked properly, and tested the KB/TTY and RUN/STEP
switches operated properly.  I set the KB/TTY switch to KB, and the RUN/STEP switch to
RUN.

I found a power supply that provides +5V at 5A, and tested it out on a dummy load to make
sure it was healthy and had clean output, and it was fine.  I connected it up to the +5
and +5 Return (GND) terminals on the power supply input barrier strip, and held my breath,
and switched on the power strip that the power supply was plugged into.

The result.  Absolutely nothing.
No sign of any activity on the display.
I didn't expect anything from the printer, because it didn't have its +24V power.

I left it powered for a little bit, checking for any chips that seemed unusually hot or
anything else that seemed amiss, and nothing was obviously upset.   The CPU chip warmed up
slightly to the touch, but wasn't at all alarming in terms of its temperature.     I
pressed the RESET switch a number of times, and it made no difference.   Oh well.

I powered it off, and pulled the ROM chips out, and decided I'd pop 'em in my ROM
programmer and compare them to the ROM images I'd downloaded off the net.

The two monitor ROMs verified exactly.   The Assembler ROM also verified correctly.  One
of the BASIC ROMs also verified properly, but the other failed the verification. 
Hmm...upon READing it into the programmer's RAM, I dumped it out, and low and behold,
it read back as all 0xFF's.   Oops..  I double checked that the ROM was properly
seated in the programmer's ZIF socket, and it was.  I tried READing it a number of
times, and the result was always the same.  This ROM must have expired somewhere along the
way.  I can blast a 2732 with the proper bits and build an adapter to make BASIC work once
I get the thing running, and hope that maybe sometime I might find a good blank OTP 2532
ROM I can blast with the code, or find one already programmed somewhere.

That said, the BASIC ROMs aren't required to get the AIM-65 to "boot up" in
the Monitor, nor is the assembler ROM.  I decided to set the BASIC and Assembler ROMs
aside, and just re-installed the known-good monitor ROMs in the proper sockets.

I double-checked that all of the RAM chips were properly inserted in their sockets by
pulling and re-inserting them, as well as the 6502, 6532, and 6522's.  The 6520 on the
display board is soldered in, so no socket issues there.

I powered it up again, and verified that +5V was present on all of the chips on the board,
and that was fine, with every chip showing +5 give or take +/- .02 Volts.  All of the GND
pins were at 0V, with only tiny (sub-millivolt) noise on GND.

I put a big dip-clip on the 6502, and got out my trusty Tektronix 2465 scope, and figured
I check some of the basic stuff, like making sure that the clock generator was running,
and that the 6502 properly would generate the Phase 1 and Phase 2 clocks that the rest of
the system uses, as well as looking at the address bus and data bus to see if it was doing
anything.  The clock generator uses a 7474 dual flip flop, which I know have a tendency to
go bad, so checking the clock was the logical first step.

I powered it up again after hooking everything up, and probing around showed that the
clock generator was indeed running, and had the proper voltage levels, timing, and duty
cycle.  The thought that maybe it'd be a simple fix, with a bad 7474, went out the
window.  The 6502 was pumping out the proper Phase 1 and Phase 2 clock signals, and  both
were very clean and within specifications.

I looked at the address 0 line, and pressed the RESET button, and it'd wiggle for a
short period of time, then go high.  Hmm...   I looked at the other address lines, and
while not all of them wiggled, they all ended up at logic 1 after a short period of time,
as if the CPU was stuck at address 0xFFFF.   I did the same thing watching the data lines,
and the symptoms were similar. 
They'd wiggle around a bit, then settle at logic 1 and stay there.

I then watched the chip select signals for the ROMs to see if they were being addressed,
and indeed, the low ROM was getting selected for a short period of time, then it'd get
de-selected and stay that way.  The other monitor ROM also got a short burst of select.  
So...it appears that the ROMs are being addressed, at least for a short time, and the
processor is likely executing the code for a short time, but something causes it to lock
up.

I checked to see if any of the RAMs were being selected, and at no time during the short
period of activity after a RESET did any of the chip selects on the 2114 RAMs go active.

I then checked the PIA (6520) on the display board to see if it was being selected at all.
 Nope. 

Then I looked at the RIOT chip to see if it was being selected, and indeed, it is being
selected during the short period of activity, but then, it goes deselected and quiet once
the CPU settles in at 0xFFFF on the address lines.  

It appears that the address decoding circuitry is at least mostly functional, as the ROMs,
PIA, and RIOT are being addressed.  It's not exactly 100% sure that the address
decoding stuff is working as it should, though.

I thought that perhaps there might be something up with the 6502.  
I have a Commodore VIC-20 that works fine, and it has an original MOS 6502 in a socket, so
I opened up the VIC-20, pulled the 6502 from its socket, and popped it in place of the
Rockwell 6502 in the AIM-65.

The behavior was identical.  So, I'm pretty sure that the Rockwell 6502 is good.   I
should have popped the Rockwell 6502 in the VIC-20 and tested it that way, but didn't
want to fuss with hooking the VIC 20 up to an old TV. 

I pulled all of the 2114 RAMs out, and popped them into an old calculator that I have that
uses 2114 RAMs, and tested them out this way.  The calculator ran just fine with the chips
from the AIM-65 in place.   I'd figure a bad RAM would likely cause the calculator to
malfunction in some way.  Not a thorough test, but enough of a test to validate that none
of the RAMS were dragging the address or data busses down, and that they did properly do
reads and writes.

So, with all that said (sorry, I am verbose), I'm kind of at a loss as to what to do
next to try to figure out what is wrong with the machine.   Does anyone out there have any
suggestions?  I have a couple of spare 6522 VIA chips, but these shouldn't really be
accessed unless the printer is trying to be accessed (which it might be during
initialization at least), and the other VIA is for  external interface use...and is
probably initialized by the ROM, but neither of them should really be actively accessed
other than a short burst of initialization.   I could swap in my spare 6522's to see
if it makes any difference, but I doubt it would make any.

The unknown is the 6532 RIOT chip.   I pulled up some data on the chip, and it appears to
be a combination of a PIA (like 6520), 128 bytes of RAM (hmm...), and a programmable
interval timer.  I don't have any spares for this chip, so I can't just substitute
in another chip and see if it makes a difference.  The RIOT chip is used to scan the
keyboard, and, after looking at the assembly source listing of the ROM Monitor, it appears
the 128 bytes of RAM in the RIOT chip are used as the storage for the monitor.     It
appears that RIOT chips can be purchased, I found a place online in the US that has them
for $9.95 each.  Maybe I'll order one up.

Maybe the RAM in the RIOT chip is not working properly?  If that were the case, since it
appears that the stack is stored in that RAM, the first time a subroutine was called and a
return executed, it'd cause possibly 0xFFFF to be read as the return address, and
that's where things go awry.   

I guess maybe I need to dig out my logic analyzer, and monitor the address and data
busses, and trace out what is actually happening.   But, I figured I query the list here
to see if anyone might have some other things that I could do that might be easier to
identify what's wrong with the thing.   

One thing that I have no idea about is the display subsection.  Since the display PIA is
never selected, I suspect that any code that initializes it and tries to put something up
on the display never gets a chance to execute.    The "smart" starburst LED
display modules are all properly in their sockets, and +5 is delivered to the proper pin
on each module, and there's no sign of unusual heating or anything else that might
indicate a problem with the display modules.   The PIA also has a clean +5 and GND, and
doesn't show any sign of overheating.

I have a small Motorola 6809 microprocessor development system with a couple of 6820
PIA's that I could probably write a quick routine to try to initialize the 6820 on the
AIM-65 display board, and try to write a message out to the display to test it, but that
seems like a lot of work.   I'd rather just fix what's up with the AIM-65, and get
it running.

Any thoughts from those out there as to what to do next would certainly be appreciated.  I
always value the collective knowledge of the members of this list.

Thanks,
-Rick
--
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com