Surrogate 8 bit ROM with an ESP32?

[paulca]

Im building an 8bit MCU based on a Z80.

Presently (Version1) I am planing on my lower 32K of address space to be mapped to an MCU.  The upper 32K I will map to an SRAM chip.

The MCU will have all 16 address lines.  It will also have the memory control lines such as "MREQ denoting the address bus is stable" and "RD" output for signalling the data bus is stable.  Plus the clock... which I haven't even considered yet.

However.  The idea is for the MCU to trigger an event handler when MREQ 'goes' low AND clock (matches the timing diagrams).


The first thing it will do is check the MSB bit. 

If the MSB is 1 we exit the handler with no action.  *
If it is 0, the request is for "US" so we pull the WAIT line to signal "we got it, hang on"

The MCU code can then lazily shift the 15 LSBs to create an index into a big-old-array in FlashROM and then lazily shift the 8 bit contents back out onto the dataline GPIOs.  Finally it can release the WAIT and PULL the "RD" on the correct clock edge. **

There is another signal, maybe just a clock edge when we can release everything and go back to floating on all pins.

As for the physical RAM chip, the address lines are fine.  Memory chips are cheap when you are looking for 16 bit address and 8 bit data.  So I don't care if I have 64K or RAM and only half addressable.

The only undecided part is how to 'gate' the data bus based off of the MSB address line.  Such that if that line is low, the physical RAM chip does not receive the MREQ and does not energise the data bus.  Can I avoid a whole bus transceiver.  Considering this is only the memory sharing on the databus, later comes the I/O peripherals sharing the databus too.  I expect some creativity and a small peppering of LS74 series logic gates will be in order.

In terms of performance.  With careful C or maybe even inline ASM an ESP32 or other MCU should easily be able to meet timings.  If it doesn't get a response in a single clock cycle it's still fine.  The Z80 supports slow DRAM, so it will wait at least a couple of cycles.

The Z80 I have is capable of 20Mhz.  "Capable", but as V1 is likely to be breadboarded, also "unlikely".  It's more likely to be running at 300kHz minima.  I might even let the MCU do the clock, makes me eye STM32 again though as it would just be a matter of configuring the clock matrix and assign it to a pin.  That makes the ROM memory timing a lot simpler too if that MCU is making the clock too.

STM32 option.  A black pill has enough GPIO exposed to meet the needs.  Runs at 80Mhz IIRC?  It could support Z80 ROM flash writing over USB... or I could just bundle the Z80 payload in the STM deployable.

The only appealing thing with the ESP32 is it allows wireless flashing of the ROM.  The peripheral set of the STM32 appeals more though.

* - we need to consider that we are in a tri-state and not a digital domain here.  By no action means, "no influence", floating pins.
** Clock edge timing sounds like it will be a pain in the a.r.s.e especially on an ESP32, I might have more edge trigger functionality with STM32 timers.

[bobxyz]

I've forgotten too much of the Z80 to be able to comment directly, but have you looked at the Raspberry Pi Pico RP2040 chip setup as a EPROM emulator (google: RP2040 EPROM Emulator)?  The RP2040 has a programmable PIO sub-block that can do a lot of different standard and custom protocols.  Maybe you'll find it useful in your project?

[SiliconWizard]

I second the RP2040 or now RP2350 for this. It has been used successfully on many similar designs and the PIO allows you to do this kind of things with ease.
Trying to emulate that with a conventional MCU is likely going to drive you nuts. But whatever floats your boat of course!

[ozcar]

Im building an 8bit MCU based on a Z80.

...
STM32 option.  A black pill has enough GPIO exposed to meet the needs.  Runs at 80Mhz IIRC?  It could support Z80 ROM flash writing over USB... or I could just bundle the Z80 payload in the STM deployable.

Original "black pill" used STM32F103, officially up to 72MHz, but maybe you could overclock it.

Now there are "black pill" boards with faster processors, like STM32F411 (100MHz) and STM32H503 (250MHz).

[westfw]

You need quite a lot of pins.  I don't know if an ESP32 has enough.
Remember that an ESP32 executes from serial flash, so it can be slower than you expect.

There are a couple of Z80 SBCs that do essentially this with an AVR:
https://hackaday.io/project/19000-a-4-4ics-z80-homemade-computer-on-breadboard
https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer

They use a separate flipflop to be sure to turn on the WAIT signal fast enough.

3.3V vs 5V may be a problem when trying to use a more "modern" microcontroller.

[paulca]

I second the RP2040 or now RP2350 for this. It has been used successfully on many similar designs and the PIO allows you to do this kind of things with ease.
Trying to emulate that with a conventional MCU is likely going to drive you nuts. But whatever floats your boat of course!

To be honest I can write the code in my head for it.

But... as you point out, the thing I am still not fully grasping is how fiddly the timing and interrupts will be.  Triggering on a rising edge of a GPIO is childs play is some MCUs a nightmare in others.  Triggering on a pair of GPIOs AND  a clock.... you might be right that might send me insane.

Bizarrely some of that "bit field" triggering may actually be easier in LS74 hardware.

Or... the RP2040 "state machine" ports, as I call them.

I will consider it. 

What I want to avoid is looking for ideas and ending up lifting a product off the shelf that decides the next 1000 decisions for me and I end just making one of their project.  I want to retain free rule here.  That doesn't mean I have to it ALL myself.  But I want to avoid getting locked in to someone elses design.

I scratched out an F411 config for the GPIOs.  It has enough....  sort of.  Sure you can plop out your 24 lines, control lines and clock and have pins spare.  However your available peripherals are basically 2 very basic timers and almost nothing else.  Even to get a single timer with an input capture for "rising edge detection" and I had to start moving all my address lines from port A to port B, as port B has hardware I don't need.

I think this project needs at least 2, possibly 3 of those edge detect timers.  She ain't going to have enough pins.  I would need to go up to the Q48 or Q64 packages.  Its not like you get much paralleling them either, for each doubling you only need 1 address bit less.

[paulca]

Just how bad is the alternative?

Don't fake it.  Use an actual parallel flash rom.  My first thoughts are that this will turn the entire thing into couple of logic gates to gate the address lines.

Where I think the problem lies there, is that the circuit and support firmware required for the Z80 to facilitate "flashing it" over Serial is probably a larger more complicated project that creating the core Z80 system in the first place.

A hybrid approach might be a parallel flash ROM chip with a gated power switch such that if the Z80 is on, the MCU power is DEAD.  Vice versa.  When the MCU is the leader it can flash the physical flash rom chip and then when it's done I can flip a switch and boot the Z80.

Does this actually simplify things?  I feel it does.  The MCU can deal with the flash ROM however it likes.  As long as it lays out the data correctly, it will be fine.  (Power off pins states are important!  If any go open drain that might be expensive).

If the hardware circuit is solid the Z80 shouldn't really know it's a modern flash rom.  Assuming I can get a parallel flashrom that is 5V and that slow.

[paulca]

Well a bit of research last night revealed a few things.

1.  It would be a lot simpler to put a parallel flash chip (Microchip make 1Mbit units with compatible pin outs for a few dollars) on the board and just use an off the shelf Arduino+sketch to program it while the Z80 is powered off.  This meets the "fast flash" cycle requirement, although if I want WIFI I'd need the same for the ESP32.  Still probably an "off the shelf" or "out of github" basis.

2.  The comments on FPGA sent me back to the Digikey YouTube tutorials on the Ice40.  So I ended up ordering a couple of dev boards.   I can see the appeal.  So off down the verlog rabbit hole I go.  Not that I really intend to use an FPGA in this project, but, as pointed out, it does provide a way to develop fully virtual for quite a bit.  Given you can "simulate" and test your stuff without even having a dev board.  It may serve as it's intended, sort of.  ie. before I commit to a address line router set of 74HC chips, I can prototype those same gates in an FPGA and fiddly with them a hundred times until I'm happy and convert back to actual 74HC chips... or not.

I also found an open source Z80 implementation in Verlog for an Ice40.  I'm sure if I look harder I will find dozens of them.

[paulca]

On further research, it would be easier to keep the Z80 powered, but send it a BUSREQ as if we were a DMA device - well, we ARE a DMA device at that point.  When it acks that, it will "tri-state" all of it's bus pins and wait.  At this point we have "bus master" and can program the flash rom.  When done we can release the bus back to the CPU.

There is a funky "might work" holding the Z80 in RESET state and some line jumpers.

The "powered off Z80" is actually the more difficult.  Whatever if going to program the flash rom will need to drive the memory control lines, which means driving an output pin on a powered off CMOS Z80, apparently a bad idea.  So for this approach to work tri-state bus-trancievers would be needed to "master" the bus.

Thats two rules so far. 

1. DO NOT FLOAT INPUTS.
2. DO NOT DRIVE OUTPUTS.

[squadchannel]

have you considered DPRAM (Dual Port RAM)?
I think the EPROM emulator uses DPRAM or SRAM + bus transceiver.

[SiliconWizard]

Or... the RP2040 "state machine" ports, as I call them.

I will consider it. 

What I want to avoid is looking for ideas and ending up lifting a product off the shelf that decides the next 1000 decisions for me and I end just making one of their project.  I want to retain free rule here.  That doesn't mean I have to it ALL myself.  But I want to avoid getting locked in to someone elses design.

Oh absolutely. You definitely don't need to do this if you go for the RP2040/2350. Documentation is pretty good and you don't have to reuse any existing design if you don't want to. I was just mentioning that many "vintage" projects have used it for this kind of purpose, mainly due to its PIO and its relatively generous RAM. You don't have to copy any of these projects.

The PIO is really fantastic for this (emulating memories) and again the available RAM (520 KB in the RP2350) makes it usable too for a wide range of projects. The two cores are also a plus when you want to have it do a bit more than initially thought.

If you go that path, I would recommend the RP2350 now, especially the B version which has more GPIOs - the limited GPIOs in the RP2040 may prove a bit inconvenient, but the RP2350B has 48, and more state machines in their PIO.

Keep in mind in any case that you'll have to consider level shifting to accomodate 5V logic. Look at the datasheets. Some MCUs have 5V-tolerant pins, but the 5V-tolerance of the RP2350 is, at best, unclear: https://forums.raspberrypi.com/viewtopic.php?t=375118 (I would say: no) Now even when you have 5V-tolerant GPIOs, that's good for the "input" side but not always for the "output" side (check thresholds). I think it usually is ok for 5V TTL logic, as high thresholds are in the order of 2.4V-2.5V IIRC. So, this 5V-tolerance requirement may make the RP2350 less attractive. Now if anyone has more detailed info on this point...