Thanks Herb, its actually my intention that since I have the real deal, to get the experience of messing with it as someone may have back in the day. For the most part, I haven't used almost any test equipment other than a logic probe and multimeter so far. I'm no stranger to test gear though, I cut my teeth learning digital electronics on a Space Invaders arcade board, which happened to be powered by an 8080. I've fixed a bunch of other boards and have some decent test gear, like a Fluke 9010A with 8080 pod, O-scopes and an HP 16500C logic analyzer. That said, I'm working on this in the house, away from the bench, under a desk lamp, and so far, no cheater toys yet. YET. (evil grin) I'm at my wits end with it though, the total echo program which is about as simple as it gets really, runs about 60 bytes that I'm entering at the front panel every time. This thing has certainly given me an honorary computer science degree, as every little error and attempt to cut a corner was thrown back at me. I can speak binary and octal fluently even in my sleep, and I've also gone over this program enough times against an opcode list to make my head hurt, and all while knowing that I'm not 100% sure that either the serial board OR the CPU is 100% operational, although I'm leaning towards the CPU being good enough as it did run the kill-the-bit game and played music through an AM radio, with no problems with ram. Even if this was on the bench, I guess I'd have to run NOPs or Port IOs and look at the bus with the LA or o-scope. If the LA didn't weight more than my car I'd have lugged it into the house by now. Hardware wise, on the serial board, I found a bad voltage regulator, replaced the 1488 and 1489 ics that were missing, and even found the -16v was even missing on the motherboard (cold solder point) . I inspected it for jumpers/mods and while it does have one, it doesn't seem to be part of the serial ports nor hurting anything. As of today, I eliminated the ram board being culprit with an DeRamp FDC+ board doing ram duties. I also learned about interrupts and initially thought that perhaps they were somehow getting enabled and processed, as my code was starting at 0 and interrupt vectors are at very low addresses, like 0008h. I messed with the EI/DI opcodes to make sure the INTE light works. I've now bumped the code up to 1000h, and added a DI opcode to it, but nothing changed. I also found one final error that was likely causing a stack issue (jumping to a push instead of the following opcode), and fixed that. NOW, what did change, is that I've sat here and single stepped the entire thing, and found it works perfectly in doing so. A character I enter is being replied back no problem, which tells me serially everything's fine Yet if I run it, I'm just getting a solid stream of garbage, although interestingly, repetitive garbage. So my next thoughts are that the bus is ringing/noisy, or perhaps there's bad buffers on either the serial board or the CPU board, as it seems that reading ports 0/1 is flaky or having a timing issue, or the serial board itself has other issues. Again, works absolutely great if I single step it all the way through. If anyone wants to look at the code, you can find it here: https://docs.google.com/spreadsheets/d/e/2PACX-1vTsNFtuSOJeGfHeCDvdB7ClGbMEg... It was mostly taken straight from the TU-ART manual, except I changed JR's to Jump if Zeros since JR was a Z80 opcode and not supported by 8080. Jeff