That's an interesting idea! I think I get it, but I'm also not fully understanding how both the Mac and the microcontroller can access the latch considering the data bus might be in use for other purposes in the meantime when the microcontroller gets around to reading the latch. Also, how do you make a status register? Are you saying another latch could be used for that purpose? I don't know a lot about this stuff though, so forgive me if my mind's headed in the wrong direction. My SIMM project was just a simple "hook all of the pins up to where they have to go" project and this type of project is a lot more complicated than that
So... I was thinking about it myself after posting last night, and realized the part number for the latches that I tossed out would be inappropriate for the very reason you bring up, IE, unless you had a buffer/line driver like a 74LS244 in front of it that you can "open and close" it's going to be a problem that said part uses the same pins for parallel input and output. A little searching later and it looks like something like the 74ACT373/573 might do; it's 8 bits wide and has seperate input and ouput pins. For the "input" (from the Macintosh) buffer you'd have the D0-7 pins connected to A0-A7, while the "LE" pin would be activated by a combination of a chip select signal derived from your decoding logic (let's be lazy and use something like a 74138 on A8->A10, that will make your "disk device" occupy 2k of address space) and the "read" line. When the Mac reads a value somewhere inside the memory range decoded by the 74138 for this device should take a "snapshot" of the state of the address lines, which will be your data value. At some later point the microprocessor which is connected to the O0-O7 pins on the other side should be able to read that value out by triggering the OE line.
(I'm sure you can reverse this in your head for the "microprocessor writes data for the Mac" buffer.)
The trick of course is the "status register". Sort of what I'm thinking is another "memory device" linked via a few gates so when what's described above happens (the state change that triggers the LE pin on the buffer), a "1" gete written into one of the slots on said "flag device", which would be readable from both the Mac and the Microprocessor's side. Similar circuitry would reset it he buffer in question is emptied. The question is, what's an appropriate part? If we can limit ourselves to needing two flags (one for "Byte waiting for MCU" and one for "Byte ready for Mac") maybe we could use... a 74HCT75? That gives you two two-bit latches that behave like the '373s above. When a "write" operation is executed the same value gets written into both latches on the chip (you tie their input data lines together), but the two devices can *read* the statuses seperately on each latches' output lines. (Which are mapped to a memory location on the Mac's side, using another line from the 74138 decoder, and tied to a couple pins on the MCU on the other side.)
(Hrm. Come to think about it, you'll need two 7475s, one for each status flag, because otherwise the operation that updates that status code for one buffer will clobber the result for the other. Whee.)
Anyway, if you figure 4 chips for the buffer latches and status registers, one for the decoder, a few more 74xx gates for the glue, and then of course the AVR or whatever for the actual disk subsystem doing it all discretely would probably take about 10 or so ICs. (I haven't the foggiest where Technight gets his "500 chips" figure from. But yes, with a sufficiently large CPLD you could probably fit those buffers and gates into one package.)
Of course, that same latch-buffer system would work just as well if not better to interface a slow MCU to the PDS slot. Trying to find an affordable MCU that can bit-bang fast enough to follow a 16Mhz+ bus cycle itself is probably futile.
