iome VS spork-8

Ohh, very nice! I'm also using customasm, but haven't bothered to even run it locally, because the online version is convenient enough for now. What I did do though, was write a script to generate my customasm rules, directly from the cpp file that defines them (and is the real source of truth for what gets written to the microcode EEPROMs).

The current setup (see near top right) IS inverted clock AND'd with the control line, which makes it read only when the clock is low. If I made it the reverse, so the 273 loads when clock goes high, then that would trigger changes to the EEPROM address lines, causing control lines to switch randomly while the clock is high, which would affect the instruction register and everything else too.

It's actually just writing to an HM62256 here, but it will hopefully work with a 28C64 as well. I've set it up so the Arduino basically acts as the control module for my computer; setting the value of the counter (used as a 16-bit address register), by controlling the bus and clock, and setting which module is outputting / inputting. It's deliberately slowed down 3x to be able to see it happen a little better, but it's still quite fast, writing a whole 32KB! This is using 10 Arduino pins for control (could be fewer), and 8 for the bus (the other 2 are for serial with the computer). Directly driving the chip's 15 address lines + 8 data lines + a couple control lines, would be too much for an Uno. And this way is probably more resilient and easier to setup than breadboards anyway. Code is here.

I'm fairly sure this is the problem, but I can't find any examples of how you're supposed to do this. I think it would work to send the first counter's TC signal to the third counter as the clock pulse. But I don't want to do that, because I also want to be able to parallel load on any clock cycle. So, I probably just have to use some gates to AND things together. Has anyone else dealt with this? Is there an obvious solution I'm missing? Project details are here.

You're definitely right that one of the main challenges with modular PCBs is getting a whole bunch of control signals between different boards. My solution was a bit different though: I've got a control module, with the microcode EEPROMs, micro-instruction counter, and flags register on it (plus a USB-B plug for power, and the reset button). Then plugged into that, are 2 bus boards on top, and 2 on bottom. 8 control lines are encoded for in / out (so 16 mutually exclusive in / out lines), and the other 8 are general purpose / not encoded. All other modules are plugged into the bus boards, which demux the in/out signals. The boards plug into each other with headers horizontally; the ALU plugs into two registers on either side of it, and the RAM / ROM modules plug into counters next to them (for their address). In case you're interested: project details, mockup of how it'll look.

I'm making a modular PCB version of the SAP (details here, visual mockup here), and I'm at the stage where I've ordered PCBs and parts, but after reading lordmonoxide's post, I'm anticipating having issues with the control lines being random mid-clock cycle, as well as potential issues with the RAM/ROM module because it doesn't use the clock pulse OR do edge detection.