I guess hadn't realized that the thing I linked to was the source of the project you'd been working on. (I didn't chase down the old thread.) If I had oodles of time (which I don't) and the appropriate legacy hardware to fiddle with it would be totally fun to try poking at something like this myself; I'm still sort of wondering if it might be possible to compress a working model down to one AVR instead of two. (Doing so would probably come at a significant performance loss, but elderly Macs don't push SCSI particularly hard in the first place.)
I'm saying this completely from ignorance, of course, but looking at the schematic/hardware doc .pdf it appears that the AVR connected to the SCSI PHY is completely dedicated to "low-level bitbanging" the port, doing some simple protocol checks (parity checking?), and communicating "sanitized" data/control words with the "target" AVR over a dedicated high-speed serial bus with control signals. (Which I gather is sort of a communications standard for AVR chips?) I can't help but wonder if you used a single AVR with sufficient SRAM (looks like they're available with up to 8k, vs. the 1k and 4k used here?) if you could timeslice between running the PHY and driving an SD card with the I/O pins you'd otherwise use for inter-AVR communication. I know there can sometimes be significant (and unpredictable) latency when dealing with SD cards, but assuming a Mac has reasonably low expectations and does transfers on a per-sector basis maybe it would be tolerable. "BigMessOWires" talked at length about how the latency of SD cards caused issues with emulating the spinning-disk mechanicals of a floppy drive on his Mac floppy emulator, but SCSI is a higher-level protocol that doesn't have the same constraints. Some of those early SCSI drives (like the ones that were actually an MFM/RLL drive with a converter board) undoubtedly had their own problems with unpredictable latency.
Anyway, blawblawblaw. I don't know snot about AVR programming so don't mind me. I haven't looked at what's actually required from a SCSI PHY, either, so if it has to "automatically" change the state of pins by itself while the "target" CPU is digesting a command it might be an incredibly difficult job to do that "time slicing". It looks like AVRs have the capacity to throw interrupts on pin changes, but I could totally see a problem with "drowning" a single core with interrupt traffic, particularly if there are other devices sharing the SCSI bus.
(Hey, you could use a Propeller! Eight seperate cores!... and probably not enough I/O pins and a few other problems. Never mind.)