When I was in college, studying electrical engineering, we used a 68K (I forget the exact version) in our microcomputers course. In lab, the "computers" we wor

When I was in college, studying electrical engineering, we used a 68K (I forget the exact version) in our microcomputers course. In lab, the "computers" we worked on were hand assembled, wire-wrapped from individual chips. Quite the site to look at, especially considering that it fit in the same size as a then standard desktop form. What I do remember is that while 32-bit ISA, the data bus was 16-bit. We had both hardware and software debuggers. The hardware debugger was basically flipping a switch from going from a regular clock to a single step with set of hex displays on the front of the computer that allowed you to see what was on the databus, no internal CPU state. The software debugger allowed you to see CPU registers, display memory. No stack trace. One of our projects was to write a resident monitor, maybe more analogous to a super micro kernel. Because the monitor ran in supervisor mode, while normal code ran in user mode, and our software debugger also ran in supervisor mode, we couldn't use the software debugger for our monitor. We could only use the hardware debugger. I got really good at decoding 68K instructions from reading the hex display while single-stepping. A silly aside from that last comment; We built our monitor on then modern PCs, specifically, I had a laptop running FreeBSD, because it had a 68K emulator available. To get our assembled code to the micro computer, we had to transfer it over a 1200 baud serial connection, and it took around 30 minutes to transfer our monitor before we could even test. So, we heavily utilized the emulator which was nearly instantaneous. We had run all of our tests against the emulator and everything looked good. We were still in lab at around 2AM, and our professor walks in and asks how we were doing. I responded we were doing great, and had just uploaded our latest code to test. Our test on the actual hardware failed spectacularly. Started using the hardware debugger to find out why, and it turned out to be an addressing issue (the instruction was using the default 16-bit addressing instead of the intended 32-bit addressing). It was literally a 1-bit bug. I manually edited the memory and reran and it was fine. There might have also been a jokingly light back-hand across the face of the team member that wrote the routine that failed.