I'd like to improve on my first TTL computer, DIP-8. I'm going to use this project to write down my ideas on how to do that. If it looks feasible then hopefully I can make it a reality, but to begin with we are just designing.

So, reflecting on DIP-8:

• Using EEPROMs for the ALU and microcode kept everything simple, but I'd like to get rid of them. For the record I don't think there's anything wrong at all with using EEPROMs in a design, but I want to set myself more of a challenge.
  • The ALU can be the popular mux-based design of Dieter Mueller, including the ability to shift right.
  • For instruction decoding, it would be nice to just use 7400 logic, but that might not be feasible. PLDs (i.e. ATF22V10) are fast and cheap and I've not used them before, so I'll give that a go.
• Let's see if we can really increase the performance. DIP-8 ran at 4 MHz, and I think it worked up to about 6 MHz. Getting rid of the EEPROMs should speed things up, and I can use surface-mount 74AC logic. Maybe we can hit 10 MHz? The other thing that will improve performance is...

• Switching from a von Neumann to a (modified) Harvard architecture. That way we can execute instructions while fetching the next one, which should be a nice performance boost.
  • DIP-8 assembly instructions are often macros that generate multiple instructions, for example "mov x, y" is actually two instructions: "mov t, y" and "mov x, t". When using the addressing modes, an "adr" instruction is needed first to put the address in the address register. So "add x, [sp+4]" becomes "adr sp+4; ldt; add x, t". I actually like this part of the design as it makes it quite powerful and nice to program, but it would really benefit from not having to spend extra cycles fetching instructions.
  • Instructions will initially come from a small boot ROM which will write instructions (from an external source) to a 64K program SRAM. Code in program RAM (PRAM) might be able to modify PRAM, or it might be that you have to jump back into the ROM to do that.
• The 574-based register file requires 14 ICs. Can we use the 670 4x4 register file IC instead? AC670 doesn't exist but HC670 is fast enough. Then maybe I could have more registers, or just fewer ICs. The only problem is it's a transparent latch, so the inputs will need to be registered to keep them stable.

There are some other things around addressing that I'm thinking about, but that's the general idea.