--
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.
--
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.
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.
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.
--
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.
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.
...