8080/Z80/8085 and 68xx, and 6502 were all better suited 8-bitters for general purpose computing for one simple reason ... they didn't suffer from the Harvard architecture! Single chip microcontrollers were never very good at that.

In order to make the computer general-purpose in nature, one has to circumvent the architectural feature of having separate code and data space, particularly non-writeable code space. It's not hard to do, but it's a pain in the *ss to have to do that when there are devices out there that don't force you to defeat one of the principal architectural features in order to make it useable in that mode.

Further, it's not terribly general in the sense that it has no means for synchronizing with devices that won't function at its native bus speed. Of course you could use an ultra-slow verison, i.e. a more-than-one-clocker operating slowly enough that its external bus cycle is long enough to allow reads and writes to external devices to be performed in a single bus cycle. After all, while you're loading your program, you can send out for, and consume, a pizza and a couple of beers.

I'd point out, that it looks to me as though the O/P is under the mistaken impression that he'll be able to execute code from his SD card. OTOH, with those 4 Mb FRAMs, he could do just that, without any painful write delays, without having to time any of the cycles, and, above all, without having to implement any protocol. It's just non-volatile read/write memory.

It's not clear what, exactly the O/P's goals are, though he's added a few things to his initial description. It would be interesting to know what he intends to use as program store. After all, he'll have to have some non-volatile code space in order to start up, and then to read his SD card. After that, since he intends to use FAT16, which limits him to 512kB (=4 Mb), which just happens to be the size of the latest parallel FRAMs. I'm persuaded that this project hasn't been thoroughly thought-through.

RE