I'm designing a Z80 system from scratch. My approach is to only have one memory device, a big SRAM, that covers the entire 64 KB memory block.
A sub-system on the board will be a microcontroller (MCU). It will be connected to a PC by a UART and have an I2C EEPROM on it as well. The idea is that this MCU subsystem will be a bootloader of sorts. From the PC you can upload code and also store it in NVM. The MCU would be connected up to all of the bus signals, but only as inputs while in a passive state to let the Z80 run.
According to the Z80 handbook, an MCU can gain control of the bus with the
/BUSRQ signal. During that time, according to how I read the datasheets, the MCU can drive the address bus, data bus and bus control signals
So an MCU could pull an image out of the I2C EEPROM and load it into the SRAM. However, this might be awkward for the Z80 when the MCU releases
/BUSRQ to let it have the bus: it will have to come out of a reset condition instead, to boot from the software image properly.
So Plan B would be to hold the Z80 in reset and do the software load. Is it known that all of the Z80 bus control pins are tri-stated during a reset condition?
Are there known issues with working the bus while a Z80 is held in reset, versus by
A stretch goal is that the MCU could also be a debugger, if it is fast enough (and the Z80 slow enough) for the MCU to passively recognize a specific bus address and then assert
/BUSRQ. According to the rules of
/BUSRQ, an MCU should then be able to browse the SRAM or I/O devices and, when done, the Z80 would pick back up as if nothing happened. Is that a safe assumption?