Bare-bones minimal CP/M (CP/NET) system

[Douglas Miller]

As an off-shoot from another conversation, I'm thinking about what would be the most-minimal system where one could run CP/M. I think about a CP/NOS system (CP/NET where there are no local disks) where the console port is also used as the network link, running a combined server/console program on a host PC. This system would require just a CPU and a UART, with memory and ROM. Since the Z180 contains a (two) UART, as well as memory management, one can further reduce the chip count.

As a first pass, I'm working up a simulator for prospective hardware. I'm looking at a Z180 with ASCI0 connected to the host (console+network) and a very simple RAM/ROM selection mechanism (A19 selects RAM or ROM).

The amount of ROM probably need not be more than 8K, and the amount of RAM need not be more than 64K - at least initially (standard CP/NET can only use 64K). I'm thinking of a minimal "monitor" program in ROM, to allow simple debug, plus a "boot" routine that uses the serial port as a network connection.

My existing serial CP/NET server code can be expanded to include a "console" mode, and I already have network boot working. So, I would envision running the serial server code in "console" mode, interacting with the Z180 monitor rom and then starting the network boot, at which point the server switches to network mode and the CP/NOS images redirects the console over the network with the rest of the CP/NET traffic.

[c f]

If the Z180 includes a serial bootloader, I think you could dispense with the ROM entirely  - just a Z180 + 64KB of RAM, and load the CP/NOS ROM code via the bootloader.

It's in an FPGA, but I kind of have a similar setup for my 16-core Z80 'ZedRipper' laptop. 15 of the Z80 cores are just instantiated with 60KB of RAM + 4KB of ROM (with CP/NOS in it), and a little bit of logic that feeds in a single JMP instruction to jump to the ROM when you take it out of reset. I then have an internal network that looks like a two UARTs to the CP/NOS clients and lets them have console and CP/NET server access.

-Chris

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/8efe963b-2220-4ce2-8929-b7f07f0f0c94n%40googlegroups.com.

[Greg Holdren]

That sounds interesting.

Not sure how you were thinking to implement 64KB but a 128KB part may be easier and cheaper than two 32KB or hard to find single package 64KB RAM.

Greg

[Greg Holdren]

Chris,

I think only the Z280 has the boot loader feature which usable too I'm guessing.

Greg

[Sergey Kiselev]

Flash ROMs are dirt cheap... 128 KB SST39SF010A part is only $1.36 (in single quantities), 512KB SST39SF040 is not much more expensive - $1.83.

Technically something like Steve Cousins's SC130 (https://www.tindie.com/products/tindiescx/sc130-romwbw-cpm-computer-kit-for-rc2014/) might be the best fit for your project.

You can save a few $$ by:

1. Omitting the 74*logic, e.g. simplifying memory decode and removing SPI/SD card interface

2. Replacing 512KB SRAM with 32 IC (about $2.50 difference)

3. Replacing 512KB Flash ROM with 128KB one ($0.50).

4. If bus is not required, remove the RC2014 headers, that would also result in smaller PCB.

Thanks,

Sergey

[Bill Shen]

Given Z80180 as the processor of choice, I have a simple Z80180 design already has CP/M working, RIZ180.  It currently has CF interface and 3 RC2014 expansion slots, but it would be very easy to to get rid of CF, expansion buss and the 74138.  The clock can be shared, so the basic design is Z80180, 128K RAM, 32K EPROM (W27C512, <$1) and a OR2 gate on 50x100mm pc board.  I can see a $10 solution easily.
  Bill

[Bill Shen]

Another possible simple design with 2 serial ports is Simple80.  It has no glue logic, just Z80, SIO, 128K RAM, and 32K EPRMO (W27C512).  Should be able to fit it in 50mm X100 mm pc board (2 boards per 100x100mm panel).  Cost wise, SIO+Z80 is probably more expensive than Z80180, however.
  Bill

On Monday, February 8, 2021 at 5:01:01 PM UTC-7 Douglas Miller wrote:

[Alan Cox]

The classic way this was done in  the old days if you look at the S100 boards that had one or two single board Z80 systems on them and which then used the S100 machine running MP/M or similar as the host, and also many of the minimal cards was to use a 2692 or similar, and these are still available in modern forms with the 26C92. Unlike the SIO or 16x50 the device has 7 output GPIO lines, 5 input GPIO lines, an on-chip timer with interrupt.

You need two input and two output lines for RTS/CTS on the ports (the chip can select this automatically), which leaves you with enough to do the bank switching and ROM enable/disable for 512K RAM and an EPROM overlay for part of it. For a CP/M 3 banked system you need a tiny bit more glue so you can switch the top or bottom 32K. If you drop the flow control output (or borrow another line and do the I/O from common) you can also get an SD card in I think. For 128K + ROM you can definitely make it work with an SD as well as you only need one line for the ROM/RAM select using the second CS on the 128K RAM, and one for A16 on the RAM. That leaves 3 for the SD card (clock, MOSI, cs), and two outputs for the serial ports, plus 3 inputs in use (MISO, two serial). Would still need a single extra chip to do the glue for CP/M 3 and partial banking.

Alan

[Bill McMullen]

While a minimal Z80 or Z180 system with a serial connection to an MP/M system will work with CP/NET, "disk" I/O performance would be dependent upon both the MP/M host AND the speed of the serial link.  Unless you really need physical separation between the MP/M and networked systems, an alternative is to tightly couple them via dual-port memory. Rather than physically separating the systems, their individual consoles could be physically distanced.

I did that on my NYOZ system using a 33 MHz Z180 for the Master (i.e. MP/M) and connected via dual-port memory to one to four 3.2" x 4.1" boards each of which contain one to four 33 MHz Z180's with 512K RAM, no ROM and a 4K dual-port RAM.  Slave booting and CP/NET communication are both done via the dual-port memory and interrupts.  The 1-16 slave Z180's each use their two serial links for a console and a common RS-485 bus available for future experimentation.  For simplicity during development, the four consoles per board share a USB connection to a host running multiple copies of HyperTerm.

Right now this project is on hold while I finish my eZ80 system.  I got it to the point where the slaves are loaded and running with their individual copy of CP/M and use the excess RAM as a local RAMdisk which can be preloaded from the host.  The master is still running CP/M so next on my development list is MP/M, testing the SNIOS, etc.

[Douglas Miller]

The actual amount of RAM or ROM is not terribly important, the 64K RAM and 8K ROM figures are really just a stab at minimums. Choosing larger parts to achieve lower cost and/or smaller package count is perfectly reasonable. Right now, it is all just code in a simulation and so such details are rather fluid and flexible.

[Tadeusz Pycio]

The 128kB RAM selection brings no glue logic to the ROM-RAM selection as it also has CS which runs high. So you can limit yourself to 4 ICs, something like my project from a few years ago.

[Karl Albert Brokstad]

Could my Z180 micro module be used or modified for the purpose?

Karl

[Kurt Pieper]

Hello Douglas,

I've been following your work with cpnet for some time.

I currently have a successful adaptation on the Kaypro 4/84

to run. I am still using the version cpnet-0.8 from Hector Peraza. I made the decision because of the programming in C.

Thanks to your module snios.spr (for the Kaypro) I can exchange my data with a notebook or a Pi 400.

I think the option for the sc126 etc. is very good.

Nice job, thanks for your activity.

Kurt

Kurt

[c f]

Ooh, I have a Kaypro 2/84 with TurboRom - how would I go about running CP/NET on it?

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/5ac23594-7440-4be7-800e-8cc3d445593an%40googlegroups.com.

[Douglas Miller]

A little off-topic, but the Kaypro code is here: http://sebhc.durgadas.com/kaypro/cpnet12.tgz

You can (currently) use one of two servers. Kurt is using the latest a.k.a. "cpnet-0.8" for Linux, latest code (compatible with above) is at https://github.com/hperaza/cpnet-server.git

The other is the JAVA server/proxy that I use/wrote, which should run on any system with a JRE. It is part of the repo https://github.com/durgadas311/cpnet-z80 - which also includes the source code used to build the Kaypro CP/NET package. See 'contrib' subdir for JAR file and startup script, see 'doc' for documentation. The "Socket" server code is for WizNet systems, or for use as "satellite" servers for the "Serial" proxy.

[Bill Shen]

Karl,
Nice board, it should work just fine for Doug's purpose

So it looks like there are several minimal boards available already.  What's next step?

[Douglas Miller]

I think the next step is for me to get this simulator working and get some basic code running as a proof-of-concept. I need to be able to modify the server/proxy to add the console capability, and get a CP/NOS network boot going. If all that goes well, then we can hammer-out the hardware details and get real hardware running.

At least, that's my suggestion.

I've got a basic simulation ready to test, and am writing a very simple ROM monitor in order to test it all out. From there, I plan on adding basic console capability to the server and get that running with the simulation. Then, add network boot and a CP/NOS image, and get the console-transitioning code working (transitioning from raw console to CP/NET, and back to raw console for RESET/reboot).

[Alan Cox]

On Tuesday, 9 February 2021 at 02:44:18 UTC mcmull...@gmail.com wrote:

While a minimal Z80 or Z180 system with a serial connection to an MP/M system will work with CP/NET, "disk" I/O performance would be dependent upon both the MP/M host AND the speed of the serial link.  Unless you really need physical separation between the MP/M and networked systems, an alternative is to tightly couple them via dual-port memory. Rather than physically separating the systems, their individual consoles could be physically distanced.

You don't actually need dual port memory although now days it's probably a lot simpler than all the other logic involved. This sort of set up existed late in the S100 era but to save cost ordinary RAM was used plus a simple status communication port. When the master wanted access it flipped a control bit and that in turn triggered the bus cycles to push the slave Z80 off the bus and map the RAM Into the S100 space for the master. When the master was done it flipped it back and the slave continued happily on its way. Some of the other systems used the same clock for the master and slave processors so that you synchronized them before a block transfer and they did an inir and otir within a few clocks of each other to get 256Kbytes/sec (@4MHz) over nothing more than a simple 8bit buffer each way.

I did that on my NYOZ system using a 33 MHz Z180 for the Master (i.e. MP/M) and connected via dual-port memory to one to four 3.2" x 4.1" boards each of which contain one to four 33 MHz Z180's with 512K RAM, no ROM and a 4K dual-port RAM.  Slave booting and CP/NET communication are both done via the dual-port memory and interrupts.  The 1-16 slave Z180's each use their two serial links for a console and a common RS-485 bus available for future experimentation.  For simplicity during development, the four consoles per board share a USB connection to a host running multiple copies of HyperTerm.

That is quite a beast!

Alan

[Tadeusz Pycio]

wtorek, 9 lutego 2021 o 17:07:10 UTC+1 Alan Cox napisał(a):

You don't actually need dual port memory although now days it's probably a lot simpler than all the other logic involved. This sort of set up existed late in the S100 era but to save cost ordinary RAM was used plus a simple status communication port. When the master wanted access it flipped a control bit and that in turn triggered the bus cycles to push the slave Z80 off the bus and map the RAM Into the S100 space for the master. When the master was done it flipped it back and the slave continued happily on its way. Some of the other systems used the same clock for the master and slave processors so that you synchronized them before a block transfer and they did an inir and otir within a few clocks of each other to get 256Kbytes/sec (@4MHz) over nothing more than a simple 8bit buffer each way.

 The cost of separating every the slave bus will be disproportionate to the cost of ROM for the slave. A similar hardware mechanism is included in the Z280.

[Bill McMullen]

Alan: Although I never added multi-processing to my S100 system in the 70's, I'm aware that some of these systems used an arbitrator that issued wait states for simultaneous access to shared RAM.  However this scheme also requires a lot of tri-state buffers.  A CPLD with lots of spare I/O pins could possibly be used to minimize board area for the arbitrator and tri-states.

Dual-port RAM is still quite expensive but luckily I acquired a good supply of them at a very reasonable price.  A possible future project is to take one of the small non-volatile FPGA's with internal dual-port RAM logic such as the ICE40 and create a cheaper alternative than dedicated dual-port RAM.  Fine for 3.3V systems but adding 5V level shifters probably just makes it a tradeoff with an arbitrator, tri-states and SRAM.

As to providing a ROM for each slave: I agree that's the simplest and cheapest route but it doesn't do anything to improve disk performance from the MP/M master.  In order to make a slave code change it requires updating every slave's ROM versus just a single downloadable image via dual-port memory.  Alternatively the ROM could simply be a loader that gets the actual slave code from the MP/M system.  Extra space in the ROM could also be used as a local ROMdisk.

[Douglas Miller]

I've got a basic virtual machine running, and a simple monitor/debugger. Now, on to adapting the CP/NET server to handle the console mode. This particular machine has a Z180, 64K RAM, 8K ROM. The Z180 ASCI0 is used as the console/comms port.

A very simple block diagram is:

The system will operate with only a terminal connected to ASCI0, however to run CP/NET requires a server connected in-line.

For those interested, the current pieces are at https://github.com/durgadas311/minimalCPM

FYI, my Z180 emulation is not complete. It supports some basic CPU registers including (memory-to-memory) DMA and the MMU. I have added an ASCI plug-in that does not support interrupts or DMA. At this point, I don't see any need for serial port interrupts or DMA.

[Bill McMullen]

Thought I'd throw out another board alternative if you're looking for standalone Z180 slaves.  I have the MinZ series which have a PLCC Z180 at up to 36.864 MHz, a PLCC flash (SST39SF0x0), up to 512KB RAM (DIP or SOJ) and various serial options (TTL, RS-232 or USB).  These boards have been working well under CP/M 2.2 with just a ROMdisk and RAMdisk or with an optional I/O board that has hex LEDs, DIP-8 switch, RTC, SD and 8MB flash disk.  There's some documentation with pictures <here> and I have bare boards plus some kits or assembled / tested boards available.

[Richard Deane]

Has anyone tried upping data throughput by implementing one of the synchronous modes available on SIO?

Richard

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/73e1afcb-21df-49a5-bd2f-68ab3650718dn%40googlegroups.com.

[Douglas Miller]

Quite off-topic, as this thread is not about RC2014/SC126/... or the SIO board. I suspect the issues with throughput have to do with the overhead imposed by the RomWBW interrupt and buffering. Maybe start a new thread to discuss that.

First attempt of this project will be at 115200 baud over the Z180 builtin ASCI0 port, CPU at 18.432 MHz. That suggests time for 1600 CPU cycles between characters, plenty of time for polled-I/O.

[Douglas Miller]

I've got a basic CP/NOS running now, using the simulation with the JAVA server. The machine starts up with a direct connection to the console through the server, then once CP/NOS boots (CP/NET traffic begins) it switches to network messages only.

The first thing I noticed (and suspected but didn't do the math before) is that the console output is rather slow. Just calculating the CP/NET overhead, each character output requires an exchange of 33 characters on the "network" (serial port). Add to this the fact that CP/M routinely checks console input status and that overhead goes to 65 characters. This effectively reduces the 115200 baud (11520 chars/sec) down to an effective 1772 baud. And that's not taking into account any other overhead. The simulator does not throttle the serial traffic to the baud rate (the CPU is throttled), but even so it is pretty slow. Reminds me of watching a daisy-wheel printer go at it.

So, if this is going to be viable, it will probably require finding a way to handle console output OOB. Will need to look into that. Console input is probably not an issue, and would create some problematic race conditions if done OOB.

I also saw some chunks of output lost during one command, but that did not repeat during the rest of my session. Requires more investigation.

I updated the github project, although documentation is still thin. If anyone is going to try it out, I can provide more information.

[Douglas Miller]

For those curious, here's a transcript of my test session. I'm using telnet to connect the console, although there are other options.

[Pellatonian]

Regarding interrupts vs polled mode: the first thing I do on any CP/M system is to revert to polled mode serial I/O.  I've yet to find any system that does anything useful with interrupt mode.  A RC2014 Pro at 7.4 MHz is my slowest system and transfers files comfortably at 15200 bps with PCGET/PCPUT or XM in polled mode (though there may be some invisible retrying going on).

[Bill McMullen]

That's a LOT of overhead on both sides for console I/O and although it may require a BIT more hardware perhaps it's time to consider separating the slave console and data "channels".  The Z180 has a second ASCI and rather than requiring a dedicated MP/M console port per slave, you could use a multi-drop architecture like RS-485 or perhaps Tx tri-states and daisy-chaining of the RTS/CTS signals.  There's also the ASCI MP bit to reduce overhead.  The CSI/O could also be used in multi-drop with the MP/M system as the master.  Slave console input would be 2 bytes (control flag including slave select and data) while slave console output would be via polling each slave for buffered data.  Just some ideas which I haven't fully thought out.

As an additional thought ... perhaps a hybrid for slave console I/O with 1/2 duplex on two interfaces.  Slave input via the two byte CSI/O messages and slave buffered console output via the second ASCI (polled) or the CP/NET data stream upon CR/LF or a maximum delay timer.

Re Interrupts and useful activities:  My Z180 and eZ80 systems all use interrupts and a few of the reasons:

- MP/M requires a 60Hz timer for the scheduler.

- Avoiding polling when multi-tasking. 

- During the long waits for console input the processor can enter SLEEP mode and considerably reduce the power requirements ... a good design practice.

- A system without RTC can use a 1Hz interrupt to create a clock.

[Douglas Miller]

That's really a different project. While my initial implementation is on a Z180, this should be extendable to any (CP/M-compatible) CPU with a serial port. MP/M is also not the focus, although I suspect this could be done in MP/M - with some effort. A modern CP/NET server on a host PC can do so much more.  I'm still pondering how to improve console I/O. NDOS does not really allow for console output to be different from console input, so I'm not sure I want to hack the NDOS that much. Still, initial results at least show something that works, albeit sub-optimal. Adding more hardware is really something different, as the question here was whether a system with only a serial port could run something more than ROM code.

On Saturday, February 13, 2021 at 10:58:20 AM UTC-6 Bil McMullen wrote:

That's a LOT of overhead on both sides for console I/O and although it may require a BIT more hardware perhaps it's time to consider separating the slave console and data "channels".  The Z180 has a second ASCI and rather than requiring a dedicated MP/M console port per slave, you could use a multi-drop architecture like RS-485 or perhaps Tx tri-states and daisy-chaining of the RTS/CTS signals.  There's also the ASCI MP bit to reduce overhead.  The CSI/O could also be used in multi-drop with the MP/M system as the master.  Slave console input would be 2 bytes (control flag including slave select and data) while slave console output would be via polling each slave for buffered data.  Just some ideas which I haven't fully thought out.

...

[Douglas Miller]

Update: I've got a version running with "normal" console speed. The console is not "networked", and console traffic is intermixed with CP/NET request-response sequences. I still need to devise a test to check the race condition between console input and the start of a CP/NET request, but there is code to address this.

The server detects the start of a CP/NET request-response sequence, and buffers any console input received during that time. And then passes that input along at the end of the CP/NET response.

The client (SNIOS) must be careful during the initial ENQ-ACK sequence at the start of a CP/NET request. Any non-ACK characters received must be buffered as console input. Once the ACK is received, we know the server will be holding any further console input while we complete the request-response.

This technique has some restrictions on allowable console characters:

• The client (CP/M) must never generate a ^E (ENQ) on the console output channel. It's possible this could be caught in the BIOS and converted to a CP/NET message to avoid the issue. It seems unlikely that any terminal type would use ^E as part of it's escape sequences, at least any modern ANSI terminal would not.
• The user must not generate a ^F (ACK) [at the same time the client is starting a CP/NET message]. This seems possible for certain CP/M programs such as WordStar. Not sure how to mitigate this one.

There may be ways to lift these restrictions. I'll keep thinking about them.

[Douglas Miller]

Note, currently the "boot" method is not over the "network". Instead, the cpnos image is appended to the ROM, and the "boot" routine simply unpacks the image into memory and executes it. I plan on getting the network boot going soon. It's just a matter of adding the existing network boot code from the Socket server into the Serial [port] server.

[Douglas Miller]

Network booting is now working, so that's about all the features that were planned. A little more testing on the simulator, and that's about it for the proof of concept.

[Douglas Miller]

I've ordered an SC203 (https://www.tindie.com/products/tindiescx/sc203-modular-z180-computer-kit-for-rc2014/) for the real-hardware prototype. We'll see how long it takes to arrive. I believe I have a soldering iron tip suitable for these boards, although the PCB photos suggest the solder pads are not very generous. Also ordered some more flash ROMs and a TL866ii. The last Z80 system I bought was a brand-new Kaypro 2X hot off the assembly line.

[Kurt Pieper]

Hello Douglas,

you have made a good choice. Stephen C. Cousins' kits are amazing.
I have Steve's SC114, SC126, SC130 kits.
All boards work immediately after completion.

You will have your joy.

It will promote or assist your work with the development of cpnet with Z80 / Z180.

I wish you much success.

Kurt

[Kurt Pieper]

recommend a CF adapter.

The adapters from Karl (https://www.tindie.com/stores/karlab/)

or Compact Flash Storag v1.1 from RC2014.co.uk work. See at Tindie.

Kurt

[Douglas Miller]

Yes, I may get a storage adapter at some point. For this project, I should not need any local storage on the Z180.

[Douglas Miller]

The single-board MinZ (http://www3.telus.net/public/wsm/MinZ180.pdf) would be a better choice to demonstrate "minimal" and "bare-bones". But, I have some other projects where I'll need the MT011 and so the SC203 seemed the way to go if I were going to purchase only one system. The code for the MinZ should only require minor changes, related to initializing the Z180 a little differently in the ROM. The ROM(s) that ship with all of these systems will not perform the CP/NOS boot function required here, although once this is working it may be possible to get their authors to integrate this into their builds.

[Douglas Miller]

Still waiting for the SC203 kit to arrive, but I did get enough hardware (USB-RS232 adapters) to setup a "real" serial connection between the simulator and the server. This helped shake-out a few issues, and gives me a better idea of the performance. It's been a long time since I've impatiently waited for floppy I/O, but it seems comparable to that. The bitrate of a 5" DD floppy is over twice that of a 115200 baud serial port, but the CP/NET file protocol does not suffer from rotational latencies and seek delays. So, as expected, this is not blindingly fast. But, it is perhaps tolerable.

[Kurt Pieper]

Hello Douglas,

I also ordered the SC203 kit. Deliveries are currently a bit delayed. In the next week the parts will come.

I work with the KAYPRO 4/84 and cpnet-0.8-master with 9600 baud.
Is tolerable, since only client 254 is active.

greeting
Kurt

[Douglas Miller]

Finally got the necessary soldering iron tips Friday, and built the sc203 last night. cleaned up and populated it this morning, and it powered up and ran SCM just fine. I ran into some trouble running my Minimal System Monitor, but that turned out to be a missing resistor on CTS. It then ran fine and booted CP/NOS. Appears to be working well. The MinZ system is due to arrive Monday.

[Douglas Miller]

Got Bill's MinZ-U system today, and have been having some fun. It is a very nice and compact system, and it powers up directly into CP/M - with ROMdisk on P: and RAMdisk on A:.

My first test was to replace the ROM with my custom one, and it worked just fine and booted CP/NOS as expected.

Bill had made this suggestion but I hadn't really visualized it yet: make the network boot code into a CP/M program file and add it to the ROMdisk. So, I threw that together and put the revised original ROM back into the system. This worked great (as long as you have the CP/NET server running on the console, of course) and I was able to boot CP/NOS just by typing P:NETBOOT.

I think the next step here is to work up a network-boot version CPNETLDR that keeps Bill's BIOS/BDOS and just adds the CP/NET layers. One could just put all the CP/NET files onto the ROMdisk, but there are space concerns and keeping it net-boot means you're not stuck replacing the ROM when updates are needed.

Anyway, lots of progress and this MinZ is really neat! I'll be discussing with Bill about whether to add this feature to his standard ROM.

[Bill McMullen]

Glad to hear the MinZ-U is working as expected.  I have no problem including NETBOOT or CPNETLDR etc. on the ROM and there's also a few utility files there that could be deleted to create space.  You're way ahead of me on that development as I digressed into the eZ80 which would make a great MP/M host.

Since you're using an ASCI for networking, that system should run fine at 36.864 MHz which is easy to obtain by changing the 16.667 MHz crystal to one at 18.432 MHz.  The primary advantage is that the standard baud rate of 230400 is then available using the basic Z180 baud rate generator with PS=0,DR=0,SS2=SS1=SS0=0 which gives PHI/160 = 230400 baud.

I'm not sure how far you want to go with configurations and testing but I also realized it would be easy to stack multiple MinZ-U systems by using three male-female threaded standoffs between them instead of the screws.  Hmmm ... four MinZ-U's stacked beside a 4 port USB hub, but the hub would probably need to be a powered one.

Looking forward to hearing more results of your testing.