However, I'm curious to know if it supports an HCF (Halt and Catch Fire) opcode
As a matter of fact, one of my earliest Magic-1 ISA designs included an HCF instruction along with an external output bit (similar to the 1802's Q bit) that HCF would set. My plan was to use that bit to trigger a flashing red fire alarm on the front panel. Sadly, I dropped HCF in a later revision.
Actually, there were serious EE's involved - only I was not one of them, I just got some excellent advice along the way. To answer your question about debugging, though, within 36 hours of the last chip being inserted Magic-1 was up and running.
The key was simulation. I wrote two complete simulators for it during design, and had the LCC C compiler running long before the first wire was wrapped. Also, while still in simulation, I wrote and passed a complete architectural validation test suite (several hundred individual tests).
Now that I think about it though, there is a better answer. I've been actively working on this project for about 4 years. It's taken me 4 years to debug.
Getting it running at 3 Mhz was actually a bit of a challenge. On paper, I'd naively thought I could push it to 4 (and possibly even higher), but as you might expect I missed some key critical paths (condition code setting, mostly). Even then, to get to 3 I had to put a bunch of 74F parts on each new critical path as it emerged (with associated cascading problems). I spent a lot of time with the logic analyzer during speed tuning.
Overall, though, I'm quite pleased with 3 Mhz. It's also a bit better than you might imagine for a comparable non-pipelined CISC machine. I average between 4 and 5 micro-ops per instruction (minimum 2), compared to typically 6 or more for comparable CPU's of decades past. Of course, that isn't because I'm clever - I'm just using modern, very fast SRAM.
Yes, I just put it back online. Actually, Magic-1 did just fine during the Slashdot storm - it was my home DSL line that got creamed (enough that I had to block access). As far as serving pages, Magic-1's 3Mhz clock isn't the primary bottleneck, it's the 38400 baud SLIP line that feeding it.
My big regret right now is that I never got around to upgrading the packet statistics counter to 32 bits. It's 16 bits right now, and it looks like it's going to be rolling over pretty frequently.
Ah, I see you've been deceived by the "little-endian" heresy. As all right-thinking people know, both bits and bytes are numbered from the "big end" first. [In truth, I got used to big-endian numbering when doing lots of work on HP's PA-RISC architecture, which used big-endian bit numbering. So, when doing my own CPU I decided to make it big-endian as well.]
As far as the blue wire, I started out trying to use different colors, but found that only a few kinds of wire would work reasonably well in my cut-strip-wrap gun. And, it only came in blue. I did make an exception for clocked signals where I could and used red wire (but I only had a limited amount of it).
Although I'm a software guy, I did get some great advice from folks who actually knew what they were doing. Power/ground & decoupling were given lots of attention, and I was also helped by finding some nice wire-wrap prototype boards that had good power and ground planes. What's keeping Magic-1 from going faster than 3Mhz is my memory access mechanism. I don't support wait states, and rather a lot happens during each clock cycle. In any event, except when being Slashdotted, 3Mhz is plenty fast enough for a homebrew project.
Slashdot Mirror
However, I'm curious to know if it supports an HCF (Halt and Catch Fire) opcode
As a matter of fact, one of my earliest Magic-1 ISA designs included an HCF instruction along with an external output bit (similar to the 1802's Q bit) that HCF would set. My plan was to use that bit to trigger a flashing red fire alarm on the front panel. Sadly, I dropped HCF in a later revision.The key was simulation. I wrote two complete simulators for it during design, and had the LCC C compiler running long before the first wire was wrapped. Also, while still in simulation, I wrote and passed a complete architectural validation test suite (several hundred individual tests).
Now that I think about it though, there is a better answer. I've been actively working on this project for about 4 years. It's taken me 4 years to debug.
Overall, though, I'm quite pleased with 3 Mhz. It's also a bit better than you might imagine for a comparable non-pipelined CISC machine. I average between 4 and 5 micro-ops per instruction (minimum 2), compared to typically 6 or more for comparable CPU's of decades past. Of course, that isn't because I'm clever - I'm just using modern, very fast SRAM.
Yes, I just put it back online. Actually, Magic-1 did just fine during the Slashdot storm - it was my home DSL line that got creamed (enough that I had to block access). As far as serving pages, Magic-1's 3Mhz clock isn't the primary bottleneck, it's the 38400 baud SLIP line that feeding it. My big regret right now is that I never got around to upgrading the packet statistics counter to 32 bits. It's 16 bits right now, and it looks like it's going to be rolling over pretty frequently.
Ah, I see you've been deceived by the "little-endian" heresy. As all right-thinking people know, both bits and bytes are numbered from the "big end" first. [In truth, I got used to big-endian numbering when doing lots of work on HP's PA-RISC architecture, which used big-endian bit numbering. So, when doing my own CPU I decided to make it big-endian as well.] As far as the blue wire, I started out trying to use different colors, but found that only a few kinds of wire would work reasonably well in my cut-strip-wrap gun. And, it only came in blue. I did make an exception for clocked signals where I could and used red wire (but I only had a limited amount of it).
Although I'm a software guy, I did get some great advice from folks who actually knew what they were doing. Power/ground & decoupling were given lots of attention, and I was also helped by finding some nice wire-wrap prototype boards that had good power and ground planes. What's keeping Magic-1 from going faster than 3Mhz is my memory access mechanism. I don't support wait states, and rather a lot happens during each clock cycle. In any event, except when being Slashdotted, 3Mhz is plenty fast enough for a homebrew project.