I got a TOP 2007 universal programmer yesterday, for burning EPROMs, GALs, and Flash memory. Whenever I hear the term “universal programmer”, I imagine a nerd-equivalent of the 1992 movie Universal Soldier, starring Jean-Claude Van Damme. Plot: a mild-mannered C++ programmer gets cybernetic implants and goes on a killing spree.

TOP 2007 Pros: It’s pretty cheap (about $100), and it programs GALs, unlike most low-cost programmers.

TOP 2007 Cons: Horrible, horrible software. I’ve seen slipshod, poorly-translated software before, but this really elevates it to an art form. Maybe 25% of the text isn’t translated at all, and is still in Chinese, including some status and error messages. What text is in English is so poorly translated, it’s difficult to tell what it means. “Driver not ready ,if load it now?” Damned if I know. And what’s a “cussor?” Clicking the close box minimizes the window instead. Reading from a chip overwrites the contents of any data file you previously had open for writing. Lots of options and menu items do mysterious unknown functions, or nothing at all. Device recognition doesn’t seem to work– you have to manually select the right device from a list of hundreds, and pray you got it right.

Despite these issues, programming a 128K Flash memory worked fine. I had problems with some Lattice 22V10D GALs, however. That’s especially frustrating, since GAL support is the whole reason I chose the TOP 2007 over other choices. The 22V10 is on the supported device list, and it does almost work, but not quite. What appears to happen is that it successfully programs all the 5000+ fuses needed to implement the logic expressions, but won’t program the last 20 fuses that configure the output pins to be inverting or non-inverting, registered or combinatorial.

Any sane person would have attempted to return the programmer, or junk it and get a better one. Instead I spent an afternoon trying to reverse engineer the software to see if I could fix the problem. By accident, I discovered that I could program 14 of the 20 unprogrammable fuses by adding extra fuse data to the data file, beyond the number of fuses that are actually in the GAL. I also found that 3 more of those 20 seemed to copy the data from elsewhere in the fuse map. But the last 3 fuses appear permanently stuck at 0. The net result is that with some complicated effort, I can completely configure 8 of the 10 GAL outputs. The other two are stuck in registered, inverting mode. I can probably work with that for most purposes. Worst case, those 2 outputs will just be unused.

GAL Counter: The hardware design calls for a stack pointer that’s a 24-bit up/down counter with output enable. The simplest approach would be to use six 4-bit up/down counters, and three 74LS244 drivers, requiring nine chips total. A better solution would use the hard-to-find 74LS569 4-bit up/down counter with integrated output enable, requiring only six chips. Better still would be to use three 22V10 GALs to make 8-bit up/down counters with output enables, requiring just three chips.

It turns out that programming an 8-bit up/down counter into a GAL is quite a challenge. For starters, there are barely enough pins. The 22V10 has 22 data pins, of which at most 10 can be outputs. I was able to barely cram it in by encoding some of the control inputs into a 2-bit function code. But the bigger challenge is that the logic equations for computing the new value of each counter bit require more product terms than the GAL supports. My equation for the MSB of the counter includes 19 AND terms all OR-ed together, but the 22V10 supports at most 16 terms. Here’s my equation:

/q7 := f1*f0*/q7 + /f1*/cet*/q7 + f1*/f0*/d7 + /f1*f0*cet*q0*q1*q2*q3*q4*q5*q6*q7 + /f1*f0*cet*/q7*/q0 + /f1*f0*cet*/q7*/q1 + /f1*f0*cet*/q7*/q2 + /f1*f0*cet*/q7*/q3 + /f1*f0*cet*/q7*/q4 + /f1*f0*cet*/q7*/q5 + /f1*f0*cet*/q7*/q6 + /f1*/f0*cet*q7*/q6*/q5*/q4*/q3*/q2*/q1*/q0 + /f1*/f0*cet*/q7*q0 + /f1*/f0*cet*/q7*q1 + /f1*/f0*cet*/q7*q2 + /f1*/f0*cet*/q7*q3 + /f1*/f0*cet*/q7*q4 + /f1*/f0*cet*/q7*q5 + /f1*/f0*cet*/q7*q6

cet is the count enable (active high). F=00 means count down, F=01 means count up, F=10 means load, and F=11 means no change. So this crazy equation says that bit 7 should be zero if we’re not changing and the current bit 7 is zero, or we’re trying to count up/down but counting is disabled and the current bit 7 is zero, or we’re loading and the input bit 7 is zero, or we’re counting up and the counter is at 11111111, or we’re counting up and the the current bit 7 is zero and any of bits 0-6 are zero, or we’re counting down and the counter is at 10000000, or we’re counting down and the current bit 7 is zero and any of bits 0-6 are one. Phew! If you can simplify that to 16 product terms, you’ll win a prize. Maybe I should create a truth table with 4096 entries, and build a Karnaugh map. Or not.

I need to take another look to make sure there isn’t some clever way I can simplify the equation to get under 16 terms. If not, then I’ll probably either make four 6-bit up/down GAL counters (which would be a little strange, since bytes would be awkwardly divided among different GALs), or six 4-bit up/down GAL counters, essentially replicating a 74LS569 in a GAL. So far I haven’t found any place that has 74LS569s is stock.

I’ve started creating schematics for the machine, using an evaluation version of CSiEDA 5. Making a real schematic that shows all the parts, pins, and interconnections is amazingly time-consuming, but it’s essential if I want to avoid making construction mistakes.

It took me a couple of hours to get familiar with CSiEDA and create this schematic for the clock and reset generation circuitry. A crystal oscillator is used to clock a pair of flip-flops, wired so as to produce two new clock signals, Q0 and Q1, at a quarter the frequency of the oscillator input. Q0 is the primary clock signal, and is used by most other clocked components in the system. Q1 lags Q0 by 90 degrees (one-quarter of a cycle), which is useful for generating other timing signals. The clock signals are buffered by a 74LS244, which has a higher drive current than most TTL chips, meaning each output pin can drive up to 16 other TTL inputs. Some signals appear on multiple ‘244 output pins, where I expect to need them at more than 16 inputs elsewhere in the system.

A Microchip TC1232 supervisor chip is used to generate the /RESET signal. Whenever the +5V input to the TC1232 is too low (during power-on, power-off, or power glitches), it forces the /RESET signal active for about 100ms, restoring the machine to its initial state. It also has an input for a reset switch, with built-in pull-up resistor and debouncing circuitry. The /RESET signal is clocked through another flip-flop, so the rest of the system will only see /RESET change at a clock edge, rather than in the middle of a clock cycle.The TC1232 also has a “watchdog” feature that can be used to auto-reset the machine if it crashes. The CPU is expected to toggle the TC1232’s strobe (/ST) input periodically to indicate that it’s still alive. If too much time passes without /ST being toggled, the TC1232 will force the /RESET signal active. I don’t plan to use this feature, so I’ve tied /ST directly to the clock signal, so it will always be toggling.In the final implementation, the flip-flops and 74LS244 may all be replaced by a single GAL, but the functionality will remain the same.

I’m trying to finish up the final hardware design now, so I can get started with actually building this thing. Although it will probably never be truly “done”, I don’t want to end up ripping out half the components and wiring to accommodate some new design feature I should have anticipated in the first place.

Here’s what I’ve been considering:

Improved condition code register: I could use a GAL to replace the 4-bit shift register with a custom dual parallel-in, parallel-out register. That would make it possible to load and store the entire CC register in a single clock cycle, instead of shifting data in/out over multiple cycles. The savings would help speed up the BRK and RTI instructions used during interrupt processing, shaving a total of 9 clock cycles off the total time needed to invoke an interrupt service routine and then return to the original program.

Conclusion: Skip it. I expect that a typical interrupt service routine will be tens of instructions long, taking probably 50 to 100 clock cycles, so a savings of 9 clock cycles isn’t that compelling.

Zero-page addressing: The 6502 CPU, from which I’ve borrowed the assembler syntax, has a mode known as zero-page addressing. Instructions using this addressing mode have an implied high-byte of zero for the address, so only the low-byte is specified. This means the instruction requires one less byte, resulting in more compact program code. On the 6502, zero-page addressing instructions also execute in fewer clock cycles than their absolute addressing counterparts. It’s sort of like having an extra 256 registers (the size of the zero page) that can be manipulated with a speed somewhere between true CPU registers and generic memory locations.

To gain a speed benefit from zero-page addressing, the BMOW hardware would require a change to permit zeroing of the high-byte of the address register simultaneously with loading of the low-byte. It would probably also require some tweaking of the memory mapping and reset circuitry, since page zero is currently part of ROM, and the machine begins program execution at memory address 0 after a reset.

If a program could be written such that one in every four instructions employed zero-page addressing, then I estimate it would be about 8% smaller and 6% faster than a program that never used zero-page addressing. In the limiting case where every instruction employed zero-page addressing (not realistic), the program would be 33% smaller and 25% faster.

Conclusion: Skip it, mostly. A typical improvement of under 10% doesn’t seem worth the hassle of changing the hardware design yet again. I may still choose to implement the zero-page addressing mode instructions later as a software-only change (new microcode), which would provide the program size savings, but no speed benefit. It would just substitute a clock cycle where the high-byte of the address register is loaded with some constant value for a cycle where the high-byte would otherwise have been loaded with a byte from the program code.

Add a Y register: I’ve been talking about this for a while, and I think I’ve figured out how to shoehorn a Y register into the left ALU input, where it must be in order to work as intended. The left input already has 4 possible sources, and with no spare control ROM outputs, and I was originally stumped as to how to support a fifth source for the left input.

My solution is to make X and X7 (a pseudo-register containing X’s sign bit) share a single enable signal from the control ROM. This signal would be AND-ed with the load enable signals for PCHI and ARHI, the high-bytes of the program counter and address register, in order to create the individual enable signals for X and X7. If the load destination were PCHI or ARHI, then X7 would be enabled, otherwise X would be enabled. While this is arbitrary and potentially limiting, in practice it mirrors exactly how X7 is already used for address calculations by the microcode. With X and X7 now sharing a control signal, there would be a free one for the Y register.

Conclusion: Do it. While the solution is a bit ugly, it’s relatively isolated. Adding Y will give the machine three general-purpose data registers rather than two, which is a significant improvement that should enable writing substantially faster/simpler programs. It will also make it much easier to port 6502 assembly programs to BMOW.

More than 64K Memory: 64K is the standard memory space for an 8-bit machine, but something larger would open up many interesting possibilities related to multi-tasking, for which 64K is probably too small to be practical. It would also allow the creation of single programs operating on larger data sets. Realistic values for the total amount of memory are in the 128K to 4MB range, assuming the use of standard SRAM.

A key consideration is how the extra memory should be addressed. One option is to have a separate segment register to hold the highest address bits. This register might be explicitly loadable by programs, or might be controlled by the OS, with each process given a separate segment. With this scheme, the bulk of the instructions would still use 16-bit addresses, and the segment register would presumably be altered infrequently. The alternative is to change all the instructions to use 24-bit addresses, providing for a totally generic 4MB address space. That would negatively impact program size and speed, however, due to the extra byte of address data in most instructions. Fortunately these approaches all require the same underlying hardware, with the differences lying entirely in the instruction set design and microcode.

Conclusion: Do it. The extra hardware needed is trivial, and the decision regarding how to use the additional memory can be made later.

But wait, there’s more! On top of these four issues, there are several other half-conceived ideas flying around my head as well:

• Direct connection of a keyboard and monitor (or LCD panel?), instead of using a PC as a terminal.
• Compact flash or IDE-based file storage.
• Integration of a real-time clock with timer interrupts.
• Two-phase clock. Investigate the necessity of buffering for clock signals due to TTL fanout limits.
• Physical construction. I need a case, a power supply, on/off switch, reset button, maybe a fuse? The case must also provide easy access to all the hardware, as well as space/power/mounting points for future add-ons I haven’t yet thought of.

I think I’m getting a little carried away. It’s time to build the basic machine and get it working, then I can return to these other ideas.

My long-awaited delivery of hardware arrived yesterday, including a protoboard, tools, and about half the components I need to build the machine. I’m using the protoboard to try various test circuits, before I construct the real thing on the wire wrap board. Last night I geeked out with the protoboard, and threw together some sample circuits.

I cut the tip off an old 9V laptop power supply, and wired it to the Vcc and ground terminals of the protoboard. Then I used a 5V voltage regulator and some capacitors (at right in the photo) to get a smooth 5V supply for the other components. The silver rectangle is a 1MHz clock oscillator. The yellow chips are resistors used to limit the current through the LED, and pull up the voltage at the push-switch. The black chip is a 4-bit counter. I wired the push-switch to the counter’s clock input, and the LED to the lowest bit of its output. Every time I press and release the switch, it clocks the counter, the low bit switches between 0 and 1, and the LED toggles off and on. It’s digital baby!

I used Verilog to do a simple test to estimate the machine’s top clock speed. I kept increasing the clock rate until the validation test suite started failing, and it topped out at about 2.63MHz. That feels respectable for a home-built machine. In reality I think I can go faster than that, since the timing data for my Verilog simulation is built around the worst-case estimates. Depending where the critical path is (I didn’t investigate to see), I may also be able to speed it up further by using a two-phase clock. Of course this all assumes I’m not limited by signal noise or some other intrusion of physics into the digital domain!

Time to celebrate! I powered through the remainder of the microcode for the core machine instructions, along with a full test suite to verify each instruction, and it all works. That’s 50 different instructions, and a couple of hundred individual tests. The test suite program alone fills more than half the machine’s ROM. Whew! I’m beat.

What I call the “core” instructions are the overlap between the 6502 instruction set (from which I’ve largely adopted the assembler syntax) and BMOW’s instruction set. That means jumps, subroutines, branches, math, boolean operators, comparisons, stack manipulation… everything you would need to write a real program. It obviously doesn’t include instructions related to 6502-specific features, like the Y register and zero-page addressing. It also doesn’t include planned BMOW-specific instructions and addressing modes; these will come later, but they aren’t essential. The core instructions provide all the functionality needed for most programs.

I resolved the problem regarding overwritten condition codes with the quick and dirty solution I first thought of. The machine saves and restores the CC’s on the stack during the instruction’s execution. ADC, SBC, ROL, and ROR all faced this problem, and my solution adds 3-4 clock cycles to those instructions. That stinks, but at least it works.

Ultimately, I think I may implement the extra carry pseudo-flag I described previously. That would let me reclaim the lost clock cycles on those four instructions, and also save a cycle on several other instructions in certain cases. Perhaps more importantly, it would also remove the need for many other instructions (like branches, or anything using x-indexed addressing mode) to modify the condition codes.

Here’s the source for BMOW Microcode 1.0. The microcode syntax is mostly self-explanatory. Each line is prefixed by a set of condition codes. A prefix of “*” means the line should be used no matter what the values of the condition codes, while a prefix like c=1 means the line should only be used if the carry flag equals 1. Each line (or pair of lines, in cases like c=0, c=1) represents one phase (one clock cycle) of the instruction’s execution.

The longest instructions are BRK (all the machine state must be saved) and ROR (rotate right is performed by repeated rotate lefts). Each is 16 cycles. At the other extreme, INX, DEX, ASL, TAX, and TXA are all 1 cycle, and many others are 2 cycles.