So impressed with the progress.

When I was a lad I spent 2 and a half days without sleep debugging an intermittent logic problem in an IBM 3033, a machine the size of a room with massive looms of trilead cables running between the frames. I remember the terror of having to do some bodgy fix like the one described when the guys file the notch out of the extender card, while an angry data processing manager a few decades my senior cursed and glowered behind me and the bank's check processing center stood idle. Perhaps the scariest experience of my life.

Hats off to anyone who fixes old computer hardware.

Seems to me that these times its worse.

With hardware you have a known good state to test against.

I prefer software! With hardware you have to think about ringing circuits and intermittent faults that you eventually find are due to the cleaner bringing in a vacuum cleaner with bad motor brushes that injects electrical noise into the mains. Most software bugs are nothing compared to tracking down that sort of thing.

It's not black magic; systematic troubleshooting is the key to either environment.

With hardware you don't always have a reproducible known good state. Many changes aren't reversible. Certain tests can irreparably damage things.

I just wanted to say thanks for the work that has gone into, not only the restoration process, but the videos and accompanying articles as well. Computer history has always been a favorite topic of mine. I was only 7 when my father gave me my first computer (an IBM 5150), so there is a lot that I simply wasn't around to experience. These videos and articles give me a taste of that. Thanks.

This is looking good. Disk returns data, CRT lights up, CPU almost working. It's good to hear that data is coming in from the disk. Looks like they won't have to build something to emulate the disk drive.

I really enjoy these. Having brought a number of MicroVAXen back to operating condition it is really fun to have such a complex system suddenly back in operation. Understanding a problem at the chip level is so much more satisfying than saying "well I swapped this board and it works now."

Wow, seriously impressed by the regular progress on each step. Great "documentary".

Maybe a dumb question, but why dead-bug the existing 7414 instead of dropping in a new one?

We didn't have a new 7414 handy, so we hacked the old one. We'll replace the chip with a new one next session.

That was a particularly nice little angle, I felt .. when I showed my kids this video, I had to explain how the chip contained multiple gates, and it was likely that one of them was borked, so you hacked over some wires to use one of the other gates - and my kids tuned into this right away .. "you mean that not all the features of these chips are used in the original?" .. typical engineering lesson, in a few seconds of video. :)

That's why Woz's boards were so crazy, he found ways to make use of every last gate and such on each chip he put in.

Fascinating thing I saw recently in social media, though I don't have a URL: Woz woke up one night in 2014 with the thought of a way to knock a chip off the Apple II's design. I haven't looked at the details but of course this was very endearing to me, the pure love for that design that Woz has always felt.

https://groups.google.com/forum/#!topic/comp.sys.apple2/iiLg...

Thanks for that, great read. . .

Yeah Woz was a beast like that, but I wonder how effective he would have been working with more people. Would he have been seen as a great engineer or just an early version of someone who wrote spaghetti code in hardware?

Well i think Atari had to redo his implementation of the Breakout game because they could not make heads or tails of it. But then they likely thought it was Jobs that made it, so...

I'm very glad you didn't have a chip handy, the deadbug hack was the coolest thing I've seen all week.

Thank you for this series! Its a real education and fun walk back in time to see how the Alto was made and how it operates.

Since it wasn't mentioned in this update, I assume the memory parity problem from last week remains?

Near the end I mention that the parity errors from last week have disappeared. There's no obvious reason for them to go away, but memory appears to be working okay now.

Oh, I missed that sentence, thanks! Since it was such a big part of last week's debug, I thought there'd be more followup coverage.

Problems which go away alone tend to come back alone, so maybe a followup comes next week :)

That's a relief, I was really worried about that.

LN

I watch these videos all the time on YouTube. Thanks for documenting the work!!

Why not proactively check all the chips to make sure all gates are working on each chip, rather than try to debug when something breaks?

Checking all the chips would be very, very time consuming. Not to mention we'd need to build some sort of test setup for each chip. It's more likely we'd cause a problem (e.g. bend a pin) than fix a problem.

But wouldn't it be fun to build a raspberry pi based chip tester!

All the contemporary CPUs you find on affordable boards have only 3.3V (maybe some even 1.8V, at least on a subset of pounds) I/O. Not directly connect able to chips as used in the Alto.

There are still a few CPLD/FPGA available with 5V capable banks, which would be preferable, so you'd build a JTAG TAP for single ICs. At this point, you could as well connect it to a PC using a JTAG pod .

We used to have an old EPROM (the UV-erasable kind) programmer in the lab. I remember it also had a mode for testing 74xx series logic. I don't think it was ever used in that capacity though.

I actually watched a YouTube video the other day where someone used a similar programmer to test all the logic chips in his ZX-80: https://youtu.be/qqUxXrh_xgM (Spoiler warning: it didn't find the failure.)