You'll need to fill/update the SRAM content some how while the system is live.  i.e. 1 writer for the bits you want to set and the read is the matching logic.  Unfortunately dual port RAM aren't cheap or huge. MUXes / tristate buffers to drive the address/data line.  That's going to be boring wiring those up.

For the breakpoint system, yes, filling the SRAMs will be demanding and I am thinking about it. A new separate log would be a better place for this but here are my thoughts :

- during power-on, the reset signal disables the breakpoint masks (stored as '273 for example). SRAM contents can be anything and will not stop execution.

- The BP RAMs don't need to be dual port. Setting the breakpoints uses the internal bus, while the processor is stopped (all the buses are hi-Z). For a single point, 1) stop the proc 2) enter the value to match in the hex-keypad 3) send this value to the desired bus 4) in the corresponding BP pannel, toggle the output bit from the SRAM (it's usually in read mode but pressing a button will start a write cycle). Voilà. (repeat until all the RAM is filled ;-) )

- the user might use a free-running counter (like the one for the keyboard scan) to flush the SRAMs, one by one or in parallel. For precisely setting certain bits, buttons (up/down) and the mouse will send pulses.

- external assistance will later come with software running on a host computer. An interpreter would transform higher-level commands (gdb-style) to individual keycodes. Like "bpres 1 1234h-5678h" sets breakpoint n°1 on the result bus for all values between 1234h and 5678h. It would even manage "ignore bits".

- Serial communication speed will be a bottleneck so a 8-bits parallel interface is also necessary. You could hook up your Pi or whatever nanocomputer's GPIO on it.

two 32k's in parallel, and an inverter ;)

These "cache SRAM" consume quite some power so I would rather find larger chips to keep the current draw "reasonable" and save a bit of PCB room.

Additionally, these chips must be fast because slow chips would slow the whole system down... That's why I need fast 64K SRAM.
Fortunately I have a good supply of 3.3V asynch SRAM, but their TSOP44 package is not adapted for the prototype.

ROMs: "solve many arbitrary combinatorial problems" Indeed, thanks for the reminder... Need 16x 17-bit address-matchers? One (16-bit) FLASH chip. Nice. What was your 'ol buddy, the 74640? One flash chip'll do the work of 16 of 'em :)

Heck, could almost build an entire processor out of nothing but flash chips...

Though, speeds may be slower than a 74AHC...

I agree on many points :-)

(but my old buddy is the '688, not a bus transceiver ;-P )

For the address-matcher, you got me thinking and you're fsck DAMN RIGHT, I must thank/credit you for that. It took 9 hours for my tired brain to connect the dots : why use Flash ?

I think I'll use SRAMs for the next generation of breakpoints. The 688 can detect strict equality, but a SRAM can match any range and whatever condition you like... OK I can say goodbye to the 688 ;-)

OMG it will be way easier to develop and debug on this system than most other systems I know. And it will have more support/debug RAM than working RAM :-D

EVEN BETTER !
So far, there would be one 64KB chip to spy on each 16 bits bus (instruction, instruction address, SI4, SND, DST) plus some more SRAM for the register addresses.

Now, let's say that 5 of the output bits of each condition can trigger a trap on its own. The remaining 3 bits of each SRAM chip can be combined with another SRAM to sieve complex conditions !

Let's say you want to set a breakpoint at instruction address 1234h when SND=234?h and result goes to register D4.

- set an instruction address breakpoint at 1234h
- set SND value breakpoints in the range 2340h to 234Fh
- set a write address breakpoint to D4
- keep these values "alive" on the bus so each breakpoint is active
- set the combined breakpoint to this "address" made of all those conditions

It looks like I'm reinventing gdb but in hardware :-D

Ah, hah! For breakpoints, nice! I was thinking to use it for e.g. recognizing whether the upper-address bits should activate a comparatively-small RAM or ROM, etc... But breakpoints, nice.

It's groovy to switch things up a bit, there's so many de-facto standards that've been around for decades, and yet so many new options available, like throwing huge amounts of RAM where it once would've been cost-prohibitive.
Keep it up!

I'll keep it up, certainly !
And I'll figure out how to set a SRAM bit on every CPU cycle, to mark all the used addresses/data/instructions/etc. so it also performs code coverage. "what code addresses have (not) been executed ?" "what instruction opcode was not used ?" etc.

Now the problem is that for my prototype, I don't have very many 64KB cache chips, the stock I have is mostly 32KB.

The other concern is interface speed. For example, flushing one "LUT" chip would take ages manually, with the keyboard. Automating it with the host interface will be better but still not... fast: the 115200bps interface limits the speed to 11520 commands per second, about 6s to scan a whole LUT. And there will be 6 or 7 LUTs so doubling the serial speed will only make a dent in the wait... Reset procedures will be tedious. Onboard hardware assist becomes necessary.

Time to write another log ;-)

OK I have 8×UM61512 (old pulls), that should be enough for the prototype... These damned 64K chips were rare, most Pentium motherboards had only 256KB cache.

Now I'm concerned that the breakpoints might add delays to the critical datapath. The 20ns access time is not the slowest part, the rest of the breakpoint and control logic will also add their own delay...