The The Z80-MBC2 is out!

More info here: https://hackaday.io/project/159973-z80-mbc2-4ics-homemade-z80-computer

During some tests on the new Z80-MBC2 I realized that the circuitry of the USER led and key (that is the same used in the Z80-MBC) could cause in some cases an erratic behavior of the USER key (USER key not recognized when pressed).

The solution is easy, and the fix requires only to change the values of R14 and R15 (see the A041116 schematic) to 390 Ohm (both) as shown:

Remember that the USER led (D5) must have a forward voltage drop (Vf) of at least 2.7V (e.g. a blue led).

Please note that this fix is suggested only if you are building a new board or if you are experiencing difficulties with the USER key.

If you already have a perfect working board there is absolutely no need to apply this fix.

Reading this Japanese article on a kit sold in Japan to build a Z80-MCB, I realized the presence of a possible bug seeing this two images:

As you can see, there is a Z80-MCB without any Virtual Disk or RTC attached and in the resulting screenshot the RTC appears present.

After a quick check I found a little bug in the RTC discovery routine that see a "ghost RTC" when the Virtual Disk is not present.

So I've uploaded a new "sketch" (S221116_R100218_Z80.ino) that fix the bug.

Note that if you have the Virtual Disk already installed, there isn't any real need to upgrade.

To do that you need two really powerful tools: Cpmtools to create CP/M disk images and SRecord to manipulate ROM/EPROM images.
Take in account that the structures of the virtual disk 0 and 1 of the Z80-MBC are different. Disk 0 has the two first tracks reserved for the system image (loaded into RAM by the CP/M loader), instead disk 1 doesn't have this "reservation". This means that the images have a different "structure". More, because disk 0 must have the system image inside the two first tracks, the disk 0 image creation will be different if the OS is CP/M rather than QP/M.
So to make things easier I've prepared some batch file to simplify the needed operations.
As for the Assembler and C toolchains you need a Windows host or VM.

Here all the steps to set up the needed tools:

1. Create a working directory on your Windows Machine;
2. Download Cpmtools and unzip in your working directory;
3. Download last version of SRecord and unzip in your working directory;
4. Download from the Files section CPMtools-custom.zip and unzip the files into the directory containing the Cpmtool executables (as cpmcp.exe). During the copy overwrite the file DISKDEFS because the new one contains the needed definitions for the Z80-MBC;
5. Download from the Files section SRecord-custom.zip and unzip the files into the directory containing the SRecord executables (as srec_cat.exe).

Now you are ready to create your custom image. First create a sub-directory (called e.g. CPM-files) in the cpmtools directory to store all the files to load in the disk image. Check that they fit into the 128kB avaliable space.

Steps to create a Disk 1 image

1. Go to the cpmtools directory and with an editor modify/add/delete in the file MakeDisk1.bat the various lines "cpmcp -f z80mbc-d1 %dskfile% CPM-files\xxxxx.yyy 0:xxxxx.yyy" to match the directory in your host (if needed) and all the files to load (xxxxx.yyy);
2. From the cpmtools directory open the provided DOS command shell and give the following command (I'll use here the name disk1.dsk for the disk image file):
   

   MAKEDISK1 disk1.dsk

3. After the execution copy the file disk1.dsk in the SRecord directory;
4. Go to the SRecord directory, open the provided DOS command shell and give the following command:
   

   D1TOHEX disk1.dsk

5. After the execution you will find four files named from disk1_SEG0.hex to disk1_SEG4.hex to upload into the virtual disk with iDisk.

Steps to create a Disk 0 CP/M image

1. Go to the cpmtools directory and with an editor modify/add/delete in the file MakeDisk0CPM.bat the various lines "cpmcp -f z80mbc-d0 %dskfile% CPM-files\xxxxx.yyy 0:xxxxx.yyy" to match the directory in your host (if needed) and all the files to load (xxxxx.yyy);
2. From the cpmtools directory open the provided DOS command shell and give the following command (I'll use here the name disk0CPM.dsk for the disk image file):

   MAKEDISK0CPM disk0CPM.dsk

3. After the execution copy the file disk0CPM.dsk in the SRecord directory;
4. Go to the SRecord directory, open the provided DOS command shell and give the following command:

   D0TOHEXCPM disk0CPM.dsk

5. After the execution you will find four files named from disk0CPM_SEG0.hex to disk0CPM_SEG4.hex to upload into the virtual disk with iDisk.

Steps to create a Disk 0 QP/M image

1. Go to the cpmtools directory and with an editor modify/add/delete in the file MakeDisk0QPM.bat the various lines "cpmcp -f z80mbc-d0 %dskfile% CPM-files\xxxxx.yyy 0:xxxxx.yyy" to match the directory in your host (if needed) and all the files to load (xxxxx.yyy);
2. From the cpmtools directory open the provided DOS command shell and give the following command (I'll use here the name disk0QPM.dsk for the disk image file):

   MAKEDISK0QPM disk0QPM.dsk

3. After the execution copy the file disk0QPM.dsk in the SRecord directory;
4. Go to the SRecord directory, open the provided DOS command shell and give the following command:

   D0TOHEXQPM disk0QPM.dsk

5. After the execution you will find four files named from disk0QPM_SEG0.hex to disk0QPM_SEG4.hex to upload into the virtual disk with iDisk.

Remember that you have to do the procedure to "timestamp the disk" to enable files timestamping as described in the Q/PM Log.

Just a thought...

It might be interesting if the "customs diskpacks" were shared, e.g. using some kind of shared cloud or something like that...

So anyone interested could just... use them...

Here is an interesting alternative to CP/M developed by MICROCode Consulting that supports also file timestamping, and it is 100% CP/M 2.2 "compatible".
MICROCode Consulting has released the original installation files and all the documentation in their site with the "restricted usage" condition, that means free for non-commercial use and for personal use only, so it should be ok for us. Anyway I've sent them a mail about this project.
To enable timestamping you need a DS3231 based RTC module like this one:

WARNING: these modules can cause battery "explosion"! How to fix it

This cheap modules have a trickle charging circuit that may cause the "explosion" of the battery if you use a standard CR2032 cell. More, it can damage also a rechargeable LIR2032 cell (see this thread). So the safer thing is "disable" the trickle charging circuit (a CR2032 can last 5/10 years, so there is no practical need to a rechargeable battery, after all...).
To avoid any charging current flowing into the battery you can take away the series limiting 200 Ohm resistor (or cut the trace). Alternatively you can take away the red diode, or destroy it (it is in series with the 200 Ohm resistor). In the following photo you can see the module with some Kapton tape (used as thermal barrier) before to desolder the 200 Ohm resistor (on the right marked as 201) with an hot air gun:

And here after the desoldering:

Now the module it's safe and a CR2032 can be used. To connect it use the SCL/SDA/VCC/GND terminals and connect them at the corresponding pins of the IOEXP/I2C connector of the Z80-MBC (pay attention because the position of the signals is different):

QP/M quick set up guide

The setup is quite similar to those used to install CP/M. The Assembler automated toolchain must be already set up and the Virtual Disk Module present.

Here all the steps:

1. Connect the DS3231 module (with the CR2032 battery inside);
2. Update the IOS using the new file S221116_R100218_Z80.ino in the File section;
3. Reboot the Z80-MBC and from a terminal emulator you'll see this:
   Press Y. If you are enough fast you have the RTC set up with the right date/time taken from the sketch compile time (if you are lazy like me you'll find this very handy...). In any case it is possible adjust the date/time manually too from the boot selection menu;
4. Reboot the Z80-MBC again and select the iLoad boot mode;
5. From the File section download the file "QPM271_DiskPack.zip", unzip it in the directory used for the Assembler automated toolchain;
6. Upload the file "iDisk - S250317.hex" to the Z80-MBC using the Dos batch L.BAT (see Assembler automated toolchain) with the command:

   L "iDisk - S250317.hex"
   

7. When iDisk waits for the input stream, from the Tera Term menu select "File" -> "Send file..." and choice one of the unzipped .hex file from QPM271_DiskPack.zip;
8. Repeat step 7 for all the four files;
9. Press the Reset button on the Z80-MBC and enter into the boot selection menu and select 4 to load the OS from disk 0 (and select the disk light ON if not already done, to have an idea of the behavior):
   

NOTE: as already noticed, if you experience errors during the serial upload increase the delay after each line from the Tera Term menu (Setup -> Serial port -> Transmit delay -> msec/line). In my VM I set up a 90ms delay. This is due because Arduino serial port doesn't have any handshaking.

Now you have QP/M 2.71 up and running, but you need further operations to enable the file timestampig (as stated in the QP/M Installation Guide):

1. To enable file disk timestamping it is necessary run the utility QSTAMPX from A:
   and do the "disk timestamping" for both A: and B: disks.
   When done type the command D $T and check that the output is similar to this:
   
2. Now to set up a starting date to all files give the command QSUB SETDATE to run a simple batch that I made to do this initialization easily;
3. Copy the file SETDATE.QSB to drive B: (using the command QPIP B:=SETDATE.QSB) and repeat from B: the same batch (QSUB SETDATE). Now the command D $T will give this output:
   

All done!

It is possible setup the D command to display the timestamping as default mode. To do this give the command (from A:) QPATCH:

select the E option, then the option 5, and X to save. Repeat this for both disks and exit the QPATCH program. Now the command D will give the output with file timestamping without specify any option.

In the Files section you can find the BIOS source "BIOS QPM271 - S080517.asm". The only change (compared with the CP/M BIOS) is the RTC routine.

The Cold Loader is the same used for CP/M.

I suggest to read the QP/M documentation for the various commands (see the Downloads section in their site).

AUTOEXEC

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 QP/M "disk pack" (QPM271_DiskPack.zip) there is an example of AUTOEXEC.QSB file.

ZDE editor

I've added a screen oriented text editor: ZDE16. For more information see this site.

About the I2C pullup

The RTC module has it's own pullup resistors on SDA and SCL. Because the value is 4k7, the resulting value will be:

4k7 // 4k7 = 2k3

Because this value is fine there is no need to take away the pullup on the RTC module.

If you used different values on the Z80-MBC, you must check that the resulting value is not less than 1k8 (taking some margin). If so, take away the pullpup resistors on the RTC too.

Playing with the Z80-MBC I realized that there was a missing feature: to run a program automatically after the "cold" boot.
So after some searches I found a way to implement in the BIOS a function similar to AUTOEXEC.BAT for DOS using the CP/M SUBMIT command and a batch file that I called AUTOEXEC.SUB (of course...).
Editing the AUTOEXEC.SUB file it is possible to run a sequence of commands after the cold boot (as with AUTOEXEC.BAT for DOS), and it is possible enable or disable the execution of the AUTOEXEC batch file from the IOS boot selection menu (but this isn't possible with DOS...).

AUTOEXEC for CP/M quick set up guide

You must have CP/M 2.2 already up and running (see CP/M 2.2, iDisk and a new IOS), and you can have also only a "single disk" installed (but I recommend the original dual disk configuration), meaning that only U1 (see the A110417 schematic) is populated. Of course the Assembler automated toolchain must be already set up.

Here all the steps:

1. Update the IOS using the new file S221116_R300417_Z80.ino in the File section;
2. Reboot the Z80-MBC and select the iLoad boot mode;
3. From the File section download the file CPM22SYS_BIOS_S050217_R300417.hex. This file contains only the new CP/M system image for the system tracks of Disk 0, so the "user files" will be left untouched;
4. Upload the file "iDisk - S250317.hex" to the Z80-MBC using the Dos batch L.BAT (see CP/M 2.2, iDisk and a new IOS) with the command:

   L "iDisk - S250317.hex"

5. When iDisk waits for the input stream:from the Tera Term menu select "File" -> "Send file..." and choice CPM22SYS_BIOS_S050217_R300417.hex. After the upload iDisk will show a summary, at this point press W to proceed and confirm your choice (as done for the CP/M 2.2 installation described in CP/M 2.2, iDisk and a new IOS). Wait until the write and verify phase is completed.
6. Press the Reset button on the Z80-MBC and enter into the boot selection menu and select 4 for CP/M loader.

All done!

NOTE: as already noticed, if you experience errors during the serial upload increase the delay after each line from the Tera Term menu (Setup -> Serial port -> Transmit delay -> msec/line). In my VM I set up a 90ms delay. This is due because Arduino serial port doesn't have any handshaking.

How use it

To create or edit AUTOEXEC.SUB from drive A, you can use the ED command or an other editor like the Turbo Pascal editor. In this case remember to terminate the file with a CR, or "strange" things will occur when executing the SUBMIT AUTOEXEC command.
You can test the execution giving the command SUBMIT AUTOEXEC from drive A (you can omit the extension .SUB inside the SUBMIT command).
To enable the AUTOEXEC execution after the cold boot change the corresponding state to ON from the usual IOS boot selection menu.
If the AUTOEXEC is enabled but the AUTOEXEC.SUB file doesn't exist in the drive A, an error will be displayed:

New "disk packs"

I've updated both "disk packs" in the files CPM22_DualDiskPack_v2.zip and CPM22_SingleDiskPack_v2.zip with the new BIOS in the system tracks. So if you are installing them for the first time or you need for any reason to reload them, the new BIOS will be installed. I've added an example of AUTOEXEC.SUB too.

How it works

The "trick" used was to inject the string "SUBMIT AUTOEXEC" into the CCP (the Command Processor of CP/M) input buffer. The BIOS after the cold boot checks if the AUTOEXEC flag is set in the IOS, and in this case makes the injection. When the CCP starts after the cold boot, it runs this injected command.

In this video there is an in depth explanation for a "legacy" Altair 8800 clone.

The CP/M 2.2 and the new BIOS sources are in the file "CPM22 BIOS - S050217 R300417.zip" in the File section.

CP/M 2.2 quick set up guide

The set up is very simple. I've done an utility (iDisk) to simplify all the needed operations. Of course the Virtual Disk Module must be present, but you can have also only a "single disk" installed (but I recommend the original dual disk configuration), meaning that only U1 (see the A110417.pdf schematic) is populated.
The Assembler automated toolchain must be already set up.

Here all the steps:

1. Update the IOS using the new file S221116_R130417_Z80.ino (or a newer version if present) in the File section;
2. Reboot the Z80-MBC and select the iLoad boot mode (if not already selected);
3. From the File section download the file "iDisk - S250317.hex" and copy it into your PC in the directory used for the Assembler automated toolchain . (Do not use the source file "iDisk - S250317.c" because it requires a special compiling option);
4. From the File section download the file "CPM22_DualDiskPack.zip" and unzip it (for a single disk configuration download the file "CPM22_SingleDiskPack.zip"). Each disk image is divided into four .hex files called "segment" (32kB each) that are named accordingly (e.g. D0XXX_SEG1.hex means the segment 1 of disk 0);
5. Upload the file "iDisk - S250317.hex" to the Z80-MBC using the Dos batch L.BAT (see Assembler automated toolchain) with the command:
   

   L "iDisk - S250317.hex"
       

6. When iDisk waits for the input stream:
   from the Tera Term menu select "File" -> "Send file..." and choice one of the unzipped .hex file from CPM22_DualDiskPack.zip (or CPM22_SingleDiskPack.zip for a single disk configuration). After the upload iDisk will show a summary:
   at this point press W to proceed and confirm your choice.
   You don't have to follow any order in the "segments" upload sequence, iDisk will know how to do. To know before each upload what "segments" have been already written into the disks just see the "Disk segment write status":
   in the photo the segments 0, 1 and 3 of Disk 1 have been already successfully written, so you can choose any of the remaining;
7. Repeat step 6 for all the eight (or four for the single disk pack) "segment" files;
8. Press the Reset button on the Z80-MBC and enter into the boot selection menu:
   select 4 for the CP/M loader (and select the disk light ON if not already done, to have an idea of the behavior).

All done!

NOTE: if you experience errors during the serial upload increase the delay after each line from the Tera Term menu (Setup -> Serial port -> Transmit delay -> msec/line). In my VM I set up a 90ms delay. This is due because Arduino serial port doesn't have any handshaking.

Disk speed

The Virtual Disk Module is based on simple EEPROMs using a 200KHz I2C serial bus. Of course do not expect the same speed of an hard disk with a DMA controller!
The speed probably is like using the floppy drive of those days...

Single disk configuration

You can have also only a "single disk" installed (but I recommend the original dual disk configuration), meaning that only U1 (see the A110417.pdf schematic) is populated.

In this case you have about 120kB free, because the first two tracks of Disk 0 are reserved for the system image (Disk 1 doesn't have the system image, so all the 32 tracks are used for the file system).

Because the BIOS is the same and is configured for a dual disk system, if you try to select the "B:" drive you'll get a "BAD SECTOR" error.

Disk pack contents

In the disk 0 image there are the various external CP/M commands, the Basic interpreter, the CP/M Assembler and the Macro Assembler.
I've added also D, an alternative DIR command, and PEG, a bin to hex converter (and vice-versa) to exchange files:

In the disk 1 image there is the complete Turbo Pascal compiler v3.01A with a sample program (SA.PAS):

In the "single disk pack" the CP/M Assembler and the Macro Assembler are missing, and the Turbo Pascal is without the installing executable (not a big issue anyway) and without the sample program.

In a next Log I'll explain how create custom disk images.

Mind the .map!

During the development of iDisk I encountered "strange" errors during testing. After a while I noticed that these run-time errors seemed to be "sensible" to the code allocation, meaning that adding a single source line e.g., for a test print, caused a different run-time error. And all this without any error or warning from SDDC.

After some research I found that SDDC outputs a .map file with the linker allocation of the Code and the Data area, and with my surprise I saw that the SDDC Linker was allocating some variables OUT the 64kB address space!

After some tests it was clear the problem: the Linker by default puts the DATA section starting from the address $8000 (the second half of the 64kB address space). Because iDisk uses an array of 32KB (so the size is $8000 in hex), all the data space is used for it, and the Linker simply puts the other variables AFTER it, out the 64KB space! And without any warning.

So to solve the issue the solution was simply add in the command line of the SDDC invocation an option to set the DATA allocation at $6000 (--data-loc 0x6000)...

Conclusion: if you are using SDDC for something more complex than a "Hello world!" always give a look to the .map file!

The making...

I've never used CP/M, so the first step was to try to use it with a simulator just to have an idea, and read this book about the commands...
After some research I found that the real starting point was the CP/M Alteration Guide that explains how to write the BIOS that is the only part that interacts with the HW.
For the source I used that one on the Grant Searle site because already adapted for the TASM assembler. In the file "CPM22_BIOS - S050217.zip" (in the File section) there is the CP/M 2.2 source I used and the BIOS source I wrote/adapted for the Z80-MBC.

CP/M story

If you are pretty new to CP/M (like me), I suggest to read something about the story behind it. It is the story of ours PC.

It's time for a new "module", the Virtual Disk Module! In the photo is that one on the right, near the previous GPIO module.

In the File section is possible see the simple schematic A110417.pdf with two I2C EEPROM 24LC1025.

With this module it is possible to emulate two disks of 128kB each (probably like the floppy disk drives of those years).

Each disk is divided into 32 tracks of 32 sectors. Each sector is 128 bytes long.

Of course to manage this new HW there is a new release of IOS. The new file S221116_R180217_Z80.ino is in the File section.

This new IOS checks if the module is present and prints a message if found:

There is also a new item in the boot selection menu if the virtual disk is found, to use the User led as a disk activity led:

I suggest to activate this option to have an idea of the behavior.

ViDiT

In the File section I've added a simple test program (file "ViDiT - S090417.c") to check the virtual disk. Of course you need to compile it with the C "toolchain":

About I2C speed

With this IOS the I2C speed is 200KHz. Note that if you are using a 16MHz external quartz to clock the Atmega32 the I2C speed will be 400kHz. In this case I suggest to lower the two 4k7 pull-up resistors (on SDA and SCL signals) to about 2k2.

The next Log will bring the CP/M 2.2 up and running...

Forth

Thanks to Bill Westfield now we have a new language for the Z80-MBC, the fig-FORTH v1.3 (here the link to the Bill GitHub repository with the source he adapted for the TASM assembler with the needed modifications for the Z80-MBC).

The acronym "fig" stands for "Forth Interest Group", that was a world-wide non-profit organization (now dissolved) for the promotion of the Forth computer language.
I've just started to play with this thing, and I must say that it is not the most friendly language I've seen... anyway it is an interesting different approach.

To enable Forth just upload the new IOS release S221116_R120217_Z80.ino in the Files section, and select the Forth language from the new multi-boot menu (see next paragraph).

Here it is a "blink" demo program:

( ****************************
(                     
( Blink test - Forth - Z80-MBC
(
( ****************************
: ledon 1 0 P! ;
: ledoff 0 0 P! ;
: delay 4000 0 DO NOOP LOOP ;
: blink CR ." Blinking..." CR BEGIN ledon delay ledoff delay 0 UNTIL ;

To execute give the command "blink":

If you are using Tera Term to send a text file to load a forth source, remember to set up a delay of 1ms for each character (serial port managed by the Arduino bootlader doesn't have any handshaking, so for now this is required to handle the serial stream without errors when sending a text file using a terminal emulator):

New multi-boot selection

Now pressing the User key after a reset brings to a new menu to chose the preferred boot mode. During this phase the LED-D0 will blink until you choose the boot mode:

New name

As you can see from the previous photos, from this release the MBC acronym changes to "Multi Boot Computer"...

Here how set up a toolchain to program the Z80-MBC using the C language. It is based on SDCC (Small Device C Compiler) and uses the same "process" of the previous Assembler toolchain.
In the following it is assumed the the Assembler toolchain is already set up in a Windows host as described in in the Log: New iLoad boot mode and an automated Assembler toolchain.
So only the SDCC relevant part is explained here.

Here it is a short video with the toolchain in action:

What you need to do:

1. Create a working directory (or use the previous one) where to store the C sources and the two batch files (C.BAT and L.BAT) in the C_batch.zip file from the File section (if you are using the same assembler working directory overwrite the previous L.BAT);
2. With a text editor search the line:

   "C:\Program Files\teraterm\ttermpro.exe" /c=3 /BAUD=9600 /w="Z80-MBC Terminal" /m=LoadZ80.ttl

   inside C.BAT and L.BAT and verify that both the path and the COM number (/c=3 means COM3) meet your system;
3. Download and install SDDC from here;
4. Download the file S030217_crt0.s from the Files section in the working directory;
5. Open the DOS command line and give the command: "sdasz80 -o S030217_crt0.s".
   Then rename the generated S030217_crt0.rel as crt0.rel. Copy it in the SDCC directory "C:\Program Files\SDCC\lib\z80" (may be a bit different in your system) overwriting the old one.

All done!

As usual close Tera Term before every new upload.

To check if it is all ok, download from the File section the file C_demo.zip and unzip it in the working directory.
From the DOS command line give the command: "C Blink.c" to check if all the toolchain works as in the video.
Try also the other demo ANSItest.c (taken from here) to check the ANSI capabilities of a different terminal emulator or a physical terminal:

About SDCC

I'm pretty new to SDCC. The SDCC documentation is 8051 "focused", so the given examples can be misleading if used with an other processor in mind.
When "porting" SDCC to a target HW, there are 3 things to prepare:

• customize the crt0.rel file that contains the initialization code for the target system;
• add to the library the function putchar(char c) to send output to the console;
• add to the library the function getchar() to read from the keyboard.

I found the documentation quite missing about how to modify for a custom system.
In particular in the provided crt0.s example there isn't a needed global declaration of three variables (l__INITIALIZER, s__INITIALIZED and s__INITIALIZER). Without this declaration the code will not compile.
And to make this customization you need to know how the provided assembler works, but the assembler manual is not provided. So you must find it googling...
If you are used to the Arduino IDE, read carefully the SDCC manual. This C compiler is a lot more "rude" about types and syntax... (as C standard is...).

Last minute update

Just found the assembler and linker documentation here!