4
\$\begingroup\$

tldr; I built and later extended Ben Eaters 8-bit breadboard computer. After the initial build I integrated 16-bit program counter and memory address registers, redesigned the instruction set and managed to access 64kB of RAM. Going forward I added 8-bit X and Y registers as counter registers comparable to X and Y of the 6502/10. With these 2 additional registers the microcode organization and the necessary ROM size become uncomfortably huge already. How can I better handle the microcode organization?

Details: In the current design I already have 7 8-bit registers (A, B, ALU, output, instruction register, X and Y counters). In addition I have 2 16-bit registers (program counter, memory address register) and a 2-bit flags register.

Currently I use 3 ROMs for microcode, each with 11 bits address width, therefore 2kB each and 6kB all together. The ROMs currently decode the output for already 18 control signals to handle input and output of all hardware attached to the 8-bit single bus.

The 11 bits of input for the decoder ROMs are formed of 6 bits from the instruction (which leaves me with only 64 instructions max.), 2 bits from flags and 3 bits from a instruction sub-step counter.

The design works like a charm, but I wonder, how I can still manage the microcode, if I extend the design even further. I plan on having more busses (data, address, ALU separated), more flags, more registers. I fear, that the sheer number of necessary input bits for the instruction ROMs will blow up their size pretty quickly. On the other hand also the need for control lines grows quite quickly.

Possible solutions I see: My current design has the advantage, that all instructions are super fast and need between 2 and 6 cycles max. I could for example get rid of control lines by reducing their number and use shift registers to form control signals sequentially. But this cost me many cycles per ASM instruction and would slow down the machine dramatically. The problem of input signals is completely unsolved.

I have no formal education in that field, therefore, please forgive my naive question. I would like to understand, how hardware engineers in the 70s and 80s solved these problems in CPUs like the RCA 1802, the MOS 6502 or the Z80. Are there concepts, that I am not aware of? Where can I learn about these? Can anyone help here?

\$\endgroup\$
4
  • \$\begingroup\$ Traditionally, these CPUs were designed entirely without microcode. The instruction decoder was hard wired logic, and the ISA was designed very carefully to minimise the logic involved. (e.g. arrange instruction formats so that 3 bits of the instruction address registers directly) At least that minimises the microcode! Microcode was a way to manage the complexity of the hard wired decoder... Extending an existing CPU leads to the Z80 (from 8080) and x86 (from the 8086). At some point you're better starting over with a clean instruction set, but that loses backward compatibility. \$\endgroup\$
    – user16324
    Aug 30, 2021 at 13:49
  • \$\begingroup\$ Thank you @user_1818839, backwards compatibility is not a problem for me, but I'd rule out combinatorial logic as microcode replacement, because that'd be too complex when trying to implement it based on 74xx ttl chips solely. I generate my microcode programmatically, but one problem - for example - is, that I double my microcode ROM size with every new input line - for example a new flag. And most of the ROM pages are currently populated with very few bytes. I am looking for a different encoding scheme. \$\endgroup\$
    – Scott vanVoss
    Aug 30, 2021 at 15:22
  • \$\begingroup\$ This question is too broad as it stands. But in general, you've overextended the basic microcode architecture that you stated with. For example, feeding "flag" inputs directly into the ROM as address bits is acceptable when there is only a trivial number of them, but as your system grows, you need to extend your architecture. Try feeding your flags into a multiplexer that is controlled by a few output bits from the ROM, and then you just have one output from the mux that feeds back into the ROM address. \$\endgroup\$
    – Dave Tweed
    Aug 30, 2021 at 15:41
  • \$\begingroup\$ Maybe scout out a copy of ‘bitslice microprocessor design’ by mick and brick. As well, interesting design hints can be got from looking at the schematics of old computers. Eg pdp11 and their hard disk controllers. \$\endgroup\$
    – Kartman
    Aug 30, 2021 at 22:25

1 Answer 1

Reset to default
2
\$\begingroup\$

Perhaps you could use some multiplexing/consolidation. Maybe you can use the same lines for different contexts. If you have a repeat flag, it likely won't be useful for register-to-register ALU ops, so for ops like that, some of the lines could do something else. I suspect that your microcode ROM has a number of gaps already, only that you cannot reach them.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.