There have been a variety of ingenious ways people have attached to the bus on the compacts. One is the killy clip approach where you have kind of an inverse socket that fits over the top of the 68000 chip. I've found those to be incredibly frustrating to work with. The other approach is to insert a layer between the board and the ROM chips, and then just have clips for the remaining couple of address lines that are missing from the ROM sockets.
For snooping the system bus, I wasn't thinking of using the rpi directly. I've been toying with the stm32f4 lately, and it seems to be pretty quick for just bitbanging stuff. It might be fast enough to decode the addresses plus forward data off. Otherwise, decoding the addresses can be done by a CPLD or discrete logic (I've done the latter for 030PDS before, so seems fairly straightforward). Then have the little bitbanging device contain the framebuffer and forward off via some other modern interface, I'm just using USB as an example. If it was USB, you can plug it into an rpi and display it out hdmi, that way you don't have the rpi bitbanging.
Given that it's an 8Mhz, 16bit bus, memory access takes 4 cycles, and the internal clock on the stm32f4 is something like 140MHz, it seems somewhat reasonable. But maybe it's just one of those cases where I have a hammer in the form of the stm32f4 and everything looks like a nail now.
The big problem with using rpi for this kind of stuff directly is of course that it runs linux and you get everything that means, for better or worse. Including imprecise timing...
For snooping the system bus, I wasn't thinking of using the rpi directly. I've been toying with the stm32f4 lately, and it seems to be pretty quick for just bitbanging stuff. It might be fast enough to decode the addresses plus forward data off. Otherwise, decoding the addresses can be done by a CPLD or discrete logic (I've done the latter for 030PDS before, so seems fairly straightforward). Then have the little bitbanging device contain the framebuffer and forward off via some other modern interface, I'm just using USB as an example. If it was USB, you can plug it into an rpi and display it out hdmi, that way you don't have the rpi bitbanging.
Given that it's an 8Mhz, 16bit bus, memory access takes 4 cycles, and the internal clock on the stm32f4 is something like 140MHz, it seems somewhat reasonable. But maybe it's just one of those cases where I have a hammer in the form of the stm32f4 and everything looks like a nail now.
The big problem with using rpi for this kind of stuff directly is of course that it runs linux and you get everything that means, for better or worse. Including imprecise timing...