It was very fortunate for me to see the progress of your designs.
I am starting to think about doing something similar, and am probably about 12 months behind where you are right now.
Basically, I'm rationalising the right frame to build a solution for myself.
Not too small, and not too big.
I like to work with bare metal solutions, so I think going the full CP/M solution may be missing my point of interest.
Stack180On the other hand, I do like smaller embedded RTOS and writing with C, so too small is also not right.
Having said that, I've actually already purchased an RC2014 solution, to cut my teeth on Z80 assembler.
RC2014My view of the perfect starting point is basing the design on the Z8S180.
It has some improvements in power reduction modes over Z80, and is fully static.
Also the clock generation, timers, USARTs and some other messy 1970s things are handled on chip,
making the overall system design more robust (and easier).
I would build the board the maximum compliment of SRAM (1MB), with the lower 64kB Bank 0 comprised of FRAM.
Now that FRAM is available there is no sense to use Flash in kB sizes, with its limited lifespan and slow write speeds.
I would focus on modern interfaces using
I2C-Parallel and
USB-USART interfaces to expand and access the board.
You can even drive video off I2C, with
FTDI EVE, and this works great.
I was thinking of being original and using an
FT245R device for programming the FRAM, and avoiding the need for a bootloader by writing direct to FRAM.
But it turns out that
Philip Jacob Smith has already done EEPROM programming with USB... there's nothing new left in the world, it seems.
So what I'm looking for, I think you've already built.
I like the idea of having a RTC on board. It is one thing that I always need on my previous AVR solutions.
I wouldn't bother to take the Z180 address & data bus off the board, as this may cause problems at 33MHz.
Doing this also makes the board very busy, with all of the bus buffer, and interrupt management chips.
Your use of the R6522 to provide parallel I/O interfaces is enough, I think.
If it can't be covered by I2C, USART, or Parallel, then it is out of scope for me.
Anyway, that's my 2C right now. Your starting point is already 90% of where I think I'm heading. So thanks