It has an optional on board 16x GPIO expander, and uses common cheap add-on modules for the SD and the RTC options. It has an "Arduino heart" using an Atmega32A as EEPROM and "universal" I/O emulator (so a "legacy" EPROM programmer is not needed).
It is a complete development "ecosystem", and using the iLoad boot mode it is possible cross-compile, load and execute on the target an Assembler or C program (using the SDCC compiler) with a single command (like in the Arduino IDE).
* * HARDWARE OVERVIEW * *
The needed ICs for the "base system" are:
Z80 CPU CMOS (Z84C00) 8Mhz or greater
TC551001-70 (128kB RAM)
If you want the 16x GPIO expansion (GPE option) add a MCP23017 too.
The schematic and the BOM are attached in the Files section. The MCU Atmega32A is used as universal I/O subsystem, as Eeprom, and as reset and 4/8MHz clock generator for the Z80 CPU. Inside the Atmega32A it is flashed an Arduino bootloader taken from here, and it is possible to use the Board Manager of the Arduino IDE to "import" it.
Flash the Arduino bootloader at first (with the method you prefer), next you can upload the IOS "sketch" (the I/O Subsystem that interacts with the Z80 bus and "virtualizes" the EEPROM and all the peripherals seen by the Z80 CPU) using Arduino IDE.
You can use the on board ICSP port J3 (also called ISP port) to write the bootloader, but remember to disconnect any other connector when using it. Also both SD and RTC modules (if present) must be removed from...
The sketch for the IOS (with the needed libraries). Unzip into a folder and open the .ino file (with Arduino IDE). IOS is required for CP/M 2.2, CP/M 3.0 and QP/M 2.71 (the SD module is mandatory). Adds the XMODEM protocol support. NOTE: now the default serial speed is 115200 bps.
The sketch for the IOS in executable format (.HEX) with the bootloader. This executable file is intended for use with a programmer as the Atmel Ice or AVRISPmkII or others (Fuse bits: High Byte 0xD6, Low Byte 0xAF, Lock Byte 0xCF)
I've done a separate "project page" for uCom (RS232 add-on card for the Z80-MBC2) here.
The uCom board, as the uTerm VT100 board, has a "transparent" USB-serial adapter connector, so you can upload firmware to the Z80-MBC2 (using Arduino IDE) or load an Intel-Hex file (with iLoad) or use XMODEM to exchange files with a PC (running a terminal emulator that supports XMODEM file transfer) while the uCom is in use.
Both the "mixed" power supply scenarios (USB-serial adapter not powered from USB but Z80-MBC2 powered and vice-versa) are managed by the HW, so you don't need to worry about it.
uCorm can be mounted horizontally or vertically to the Z80-MBC2.
The 3D printed custom angled brackets .STL files are the same of the uTerm.
I've done a separate "project page" for uTerm here.
uTerm can be mounted horizontally or vertically to the Z80-MBC2.
All the details including the 3D printed custom angled brackets .STL files are there.
uTerm is a VT100 terminal with VGA out and PS/2 keyboard with a power supply (for the Z80-MBC2 too). It has a "transparent" USB-TTL adapter connector, so you can upload firmware or load an Intel-Hex file (with iLoad) while the card is inserted. Both the "mixed" power supply scenarios (USB-TTL adapter not powered from USB but Z80-MBC2 powered and vice-versa) are managed. The video terminal is based on the ChibiTerm (https://hw-by-design.blogspot.com/2018/07/low-cost-vga-terminal-module-project.html).
Currently working on a RS232 add-on card for the Z80-MBC2.
As the uTerm board, it has a power supply for the Z80-MBC2 and a "transparent" USB-TTL adapter connector, so you can upload firmware or load an Intel-Hex file (with iLoad) while the card is inserted. Both the "mixed" power supply scenarios (USB-TTL adapter not powered from USB but Z80-MBC2 powered and vice-versa) are managed.
There is a problem with this new IOS with the MBASIC Basic interpreter. The "GPELED.BAS", "RTC.BAS" and "USERLED.BAS" example programs don't work anymore. It seems that the way MBASIC does some I/O checks using the new virtual serial port interferes with others virtual I/O ports. Further analysis is required...
* * * UPDATE 2 * * *
I think to have found the origin... now thinking to a possible solution...
* * * UPDATE 3 * * *
The new SD image (SD-S220718-R260119-v2.zip) is out in the Files section. It fixes the MBASIC issue for CP/M 3 and 2.2. Please update your SD image.
* * * * * *
Because some people requested to use the XMODEM protocol to exchange files through the serial port, I've added the support for this protocol into CP/M 2.2 and CP/M 3 (banked only).
XMODEM needs a full 8 bit binary data transfer, and this is not possible with the CON port (the CP/M port used for the console) with a "legacy" CP/M system installation because the CP/M Alteration Guide says to strip the eight parity bit when reading a byte from the console input.
More, because the Z80-MBC2 uses a virtual serial port without handshaking there is also a timing problem when dealing with the 128 bytes packets used by the XMODEM protocol.
So the support to the XMODEM protocol has requested changes in the IOS and in the CP/M BIOS, and also in the Arduino core to extend the serial input buffer.
Please note that with the new IOS the default speed of the serial port is now 115200 bps.
To have the XMODEM support active, before the update of the new IOS firmware and the new SD image (see in the Files section), you have to manually create a new "board variant" in the Arduino IDE and then change the default Rx input buffer size to 128 bytes in the "core" of this new variant.
If you aren't interested into the XMODEM support, you can simply update the IOS and the new SD image as usual without the need to create the new board variant. In this case the XMODEM will not work in the receive direction, but only in the send direction (from the Z80-MBC2 to a PC with a terminal emulator).
HOW MANUALLY CREATE A NEW BOARD VARIANT (LINUX)
In the following I'll assume an Arduino IDE 1.8.5 installation on a linux host and the MightyCore ver. 1.0.8. Anyway I've tried to make the procedure enough general to be used for other versions too.
Currently working on a VT100 terminal with VGA out and PS/2 keyboard with a power supply (for the Z80-MBC2 too). It has a "transparent" USB-TTL adapter connector, so you can upload firmware or load an Intel-Hex file (with iLoad) while the card is inserted. Both the "mixed" power supply scenarios (USB-TTL adapter not powered from USB but Z80-MBC2 powered and vice-versa) are managed. The video terminal is based on the ChibiTerm (https://hw-by-design.blogspot.com/2018/07/low-cost-vga-terminal-module-project.html).
Working on a new revision (A071218-R250119):
Waiting the new PCB, I'm playing with the current PCB "patched" to perform like the new one. Here a session with Wordstar 4 configured to use all the 30 rows of uTerm:
In the photo you can see that also the serial-USB adapter is attached to the uTerm using the "transparent" port. This allows to use two keyboards and two monitors in the "same" time (one keyb and monitor attached directly to the uTerm, and another keyb and monitor of the terminal emulator on a PC connected with the serial-USB). This allows also to use XMODEM (e.g. between the Z80-MBC2 and a PC) or to flash the Atmega firmware with the uTerm connected.
Or you can use the monitor attached to the uTerm and the keyboard of the terminal emulator on a PC. This is exactly the "configuration" I used in the photo to make the test (as you can see, there isn't any keyb attached to the uTerm).
Here last version assembled horizontally with the Z80-MBC2:
With the latest IOS revision and the corresponding new SD image (see the Files section) there is one more option: the CP/M 3.0!
With CP/M 3.0 it is possible use the 128KB banked RAM to have a wider user area (TPA) for programs and a more "evoluted" OS.
Just as example of how it is easy with CP/M 3.0 manage multiple configurations, I've done also a "non-banked" 64KB version. The switch from one version to the other can be done simply running a batch from the console itself.
I've prepared two simple batch files to do that. From drive A: the command:
will set the 64KB "non-banked" version and then reboot the system.
To activate again the 128KB "banked" version give the command (from drive A:):
NEW DISKDEFS FILE
To use cpmtools or cpmtoolsGUI with the virtual disks of the CP/M 3.0 environment, you must update the DISKDEFS definition file (from the SD in the folder <SD>/cpmtools/) and use the "z80mbc2-cpm3"entry for all the 16 disks:
Please note that for the CP/M 3.0 environment all the 16 virtual disks have the same structure and for this there is only one entry for all the CP/M 3.0 virtual disks.
The AUTOEXEC switch for CP/M 3.0 works in a different way from the CP/M 2.2 and QP/M 2.71 implementations.
Now there is a custom utility (AUTOEXEC) that checks the IOS flag and sets the exit code accordingly (using the BDOS function 108). This allow to use the CP/M 3.0 batch conditional execution (see the CP/M 3 Programmer Guide par. 1.6.3) to run any wanted command or program based on the status of the IOS AUTOEXEC flag.
I've prepared an example using an other CP/M 3.0 feature, the "PROFILE.SUB" batch that is automatically executed at cold boot (if it exists). To activate it (in the drive A:) rename the file PROFILE.SUas PROFILE.SUB with the command:
Now you can see how it works setting the AUTOEXEC flag on or off with the IOS "Select boot mode or system parameters" menu.
The QP/M uses for the batch file the .QSB extension. So the AUTOEXEC file is now renamed AUTOEXEC.QSB. To enable the AUTOEXEC execution after the cold boot change the corresponding state to ON from the usual IOS boot selection menu.
In the drive A: there is an example of AUTOEXEC.QSB file ready to run.
IOS MULTI-BOOT MANAGEMENT
Now the IOS has a new entry (8) in the boot menu to manage the OS multi-boot configuration:
Each OS is associated with a set of virtual disks called "Disk Set", and changing the "Change Disk Set..." entry (8) will switch all the virtual disks of his "environment".
The new IOS is out, and the CP/M 2.2 OS with it, and 16 disks are available (from A: to P:), each 8Mbyte large.
With IOS (not for IOS Lite) the SD module is mandatory to run not only CP/M 2.2 but also for the stand-alone Basic and Forth interpreters. You need a microSD card (FAT16 and FAT32 are both supported) to store the content of the SD image file, retaining the directory structure.
Pay attention on how the modules are inserted because their positions are fixed and absolutely not swappable (see the upper photo).
To add, extract or delete files inside a virtual disk (virtual disks filenames on SD are "DS0Nxx.DSK", where "xx" is the disk number) it is possible use the cpmtools or cpmtoolsGUI utilities, with the diskdefs file in the \cpmtools directory of the SD zipped file.
I suggest to use cpmtoolsGUI (only for Windows) because is very easy.
Unzip it into a folder and put the diskdefs file in the same folder. Select "z80mbc2-d0" only for disk 0, and "z80mbc2-d1" for the others (disk 1 - 15):
NOTE: use cpmtoolsGUI only to add, extract or delete files inside a virtual disk. Not try to create new virtual disks files with cpmtools or cpmtoolsGUI because further processing is required for a valid virtual disk file.