Sounds like you've covered most of the common issues; a bad RIOT would definitely keep it from working and it might be worth while to replace it; if it turns out you didn't need it you could build a three-chip SBC with it, a 6502 and an EPROM ;-)
If you've got a couple of 40-pin sockets I'd build a NOP generator which basically cycles through all the addresses; that will let you check all the address and select lines and by checking the signals on the socketed chips you'd also check the troublesome single-wipe sockets used on the early boards. Just bend out the 8 data pins on one socket and plug it into the other one with a piece of paper in between to prevent the bent-out data pins from contacting the lower socket. Connect the data pins to Vcc and Gnd respectively so as to present the 6502 with a permanent NOP ($EA), plug it into the board with the 6502 inserted on top and watch the address signals on your scope. Look about 1/3 down this page: http://www.8bit-homecomputermuseum.at/repair/bluepet/bluepet.html Coincidentally I'm just about to test and if necessary revive a half-dozen AIM65s myself; aside from the 6532 they're actually a pretty straightforward design using commonly available parts. I assume you've found Rich Cini's treasure trove of AIM65 (and other) documentation; now that Dave Colglazier's added his collection that is the definitive source of AIM65 stuff. Good luck; they're a fun little machine, especially with some extra memory and an RS-232 terminal. The monitor is pretty sophisticated, and having BASIC, A (Dis-)assembler, FORTH, PL-65 and even Pascal (with a little futzing) available in ROM is really convenient. Aside from current loop, RS-232 and dual cassettes for I/O there were several disk and video interfaces available and I believe an SD-card interface is in the works... m ----- Original Message ----- From: "Rick Bensene via cctalk" <cctalk@classiccmp.org> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk@classiccmp.org> Sent: Tuesday, June 04, 2019 11:10 PM Subject: Catatonic Rockwell AIM-65 > 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 > >
