The complexity of the register file is becoming an issue, so I'm rethinking.

My target date for implementation is 1982. In 1982, while they were expensive, small 35ns static RAM chips in reasonable sizes (1Kx4) were available, e.g. the TMS2149.  This puts a limit on my performance -- I'll need to be able to access the register file at least twice per processor cycle, in order to perform both a read and a write -- but using these for registers will significantly decrease complexity.  My latest designs would have used something like 20+ individual register file chips to implement the whole register file, which would have used a substantial amount of board space.  That's not something that could really have been tolerated in the home computer market that I want this system to be a plausible candidate for, so it had to go.

A 35ns access time, plus control signal generation and latching time, twice per processor cycle, means realistically my clock period can't even be as short as 80ns (12.5Mhz).  I may be able to achieve 12Mhz (83.3ns), which would be nice, as I wanted to be able to use this processor alongside a 6MHz Z80, and having them at integral multiples of clock speed would simplify the design.  If necessary, I'll put my RAM chips under a cooler, or maybe even overvolt them slightly.  These things tend to help quite a bit, according to the datasheets I've looked at for other devices.  And most RAM devices of the period could tolerate 5.5V supply happily. Unfortunately, I've been unable to find a datasheet for the TMS2149, so can't confirm anything for this device. 

(UPDATE: having checked the memory requirements, I think the older 256x4 "93422A" type chips would be ideal -- unfortunately, I haven't been able to find any price information about those. They do however have 30ns typical access time; they also have non-multiplexed input and output pins, which may allow me to remove a set of tristate buffer chips from the data path).

With a ~12Mhz limit, I'm going to have to profile very carefully.  Every cycle is going to count in order to use this for display generation, as I was hoping to.  I was planning on performing various operations (e.g. palette lookup) in code in the IO processor rather than implementing hardware for them, but that's looking less likely now.

I've decided to go ahead and implement an FPGA version.  I need to have something I can tinker with so I can get some cycle-exact timings of tasks I have in mind.  My original idea was to implement a simulator, but I've been working on a design for a simple yet fast Z80 system, inspired by projects like Z80-MBC2 -- like that project I originally started with a microcontroller to provide IO interfaces, but I also wanted to implement cycle-stealing DMA and a microcontroller just isn't up to that job without significant support circuitry, so I'm ditching it and using an FPGA instead ... and if I'm using an FPGA anyway, why not put IO881 on there?

I've got the start of some verilog code up on github.  It still has the old register file design as of right now, so I need to go back and update that to use RAM instead before continuing.  Next job after that is the instruction fetch system, which is where things start to get interesting.