Getting my C2 up and running

[dave]

I finally was able to pull out the C2-4P today. It's got a 502 card, fitted with CEGMON in a 2716 and a MAX-232 chip; a 540 card, a 527 card with 24K, and a 470 floppy board. My intention is to get it to boot from a floppy. It looks like I have video. The 502 card is flaky, and has been ever since I got the machine. I'm getting intermittent boots--sometimes it won't reset, sometimes it reset to the CEGMON prompt, but won't respond to key presses, and sometimes it will boot right up into the monitor or basic. With the 527 board in place, the machine will not reset, so I'll have to isolate the issue on that card--it must be something fundamental. Then, I'll be able to look at the floppy system.

Regarding the flaky 502, the intermittent behavior is partly dependent on board flexion--if I put the board in the top slot without physical support, and let it sag, it won't boot. If I pull up on the board, it is likely to boot, but still may be intermittent. This was true 30+ years ago as well, and I had dealt with it by adjusting the spacer lengths so that the CPU was always flexed up a tiny bit when all the boards were screwed in.. I don't see any obvious bad traces, and about 10 years ago, I touched up all the solder joints, so I'm suspicious of a bad socket. Flexing the board down could potentially separate a marginal pin/socket contact. Since the processor is getting a clock signal on pin 37, the issue would have to be with the processor itself, adress decoding, monitor ROM, or the bus interface. I expect that the amount of board flexion is greatest closer to the connectors than the edge--I doubt the processor or EPROM sockets flex much when the board sags.. I'll see if I can burn a serial monitor, to find out if the board flexion affects serial bootup as well, or just the video boot.

I don't want to re-socket the whole board to hunt down the problem--I'd just like to find the bad one and fix it. In the worst case, i have an extra 505 card I can use, but that will also require repairs. I'd rather have both working solidly.

So, that's the status at the moment. I'll report more as I have time to go through the card. If anyone has any suggestions, let me know!

Dave

[billdrom]

Dave, My 500 board was intermittent also at one time. I tracked it down to a cold solder joint on one of the bus connectors.
I used a scope to look at the waveforms on each pin at the backplane. One of the signals was only about half the amplitude of the others.
After re-soldering the connector pin all was well. If you don't have a scope, you could just reheat and apply a little more solder to the edge connector pins.
There are only 48 pins so it wouldn't take very long. Maybe start with the data and address pins first then re-test.
If you look at the pins with a magnifying glass you may be able to spot a dull joint with poor flow to the lands on the board and only need to fix one pin.
It could also be the male pins on the bus with a poor joint. Try the card in a different slot.
Good luck.

BillDrom

[glitch]

I had some bad single-wipe sockets on two of my 520 RAM boards. Same kind of results...depended on how the board was flexed! Fortunately, I had three in the system, so rejumpering one allowed me to find bad sockets on the other two. Those single-wipe sockets can be pretty lousy.

[dave]

Lots of good ideas there. A few years back, I carefully inspected and re-soldered the entire backplane, and carefully reflowed every socket and connector pin on the CPU board.

I actually did put a scope on all the bus lines with the board in various degrees of flexion, but was not fortunate enough to find any low amplitude or obviously deformed signals. I couldn't detect the glitch, even when the system went off to never-never land. To be honest, I could have been much more aggressive with the troubleshooting on that front. I guess the trick is figuring out what to trigger on to capture the glitch. Also, since i was using a 2-channel analog scope, the capture options were limited. Perhaps now that I have a deep memory DSO, I could write some code to reset a watchdog, and use the watchdog timeout as a trigger. I have a centronics interface on the proto space of my 470 card consisting of a latch and a 74123 strobe, so I the 74123 could be a good watchdog. A MSO sure would be nice. . .

The issue is independent of the slot, and follows the CPU board if I swap boards to a different machine. I've inspected . I'm suspecting it's a bad IC socket or a bad molex on the CPU board. The degree of instability when the board sags by gravity makes me suspect a bad socket or connector close to the bus, since that area flexes the most.

In the meanwhile, the system is usable as long as the board is not permitted to sag.

By the way, would either of you happen to have a copy of a C2/4/8 boot disk? I did have these with my original machine, but for the life of me, I can't find those disks, or my OSI software collection (of stuff written by me, which I never got to pull from floppy). It's got to be somewhere here in the lab, but it's managing to hide pretty well Bill Sudbrink is going to bring a boot disk to the VCF East, but it would be awesome to verify my system before then, so I can test out the new disk-interface paddle board, and then try to test out some different disk interfacing options.