A 4$, 4ICs, Z80 homemade computer on breadboard

No iron, no cry! Simply wire it to build a mini 4MHz Z80 64kB RAM system with a Basic and Forth interpreters, and Assembler and C toolchains

Similar projects worth following
This is the Z80-MBC (Mobile Breadboard Computer), a mini 4MHz Z80 64kB RAM system with a Basic and Forth interpreters and Assembler and C toolchains. It can be easily expanded and it has an "Arduino heart" using an Atmega32A as an "universal" I/O emulator, and can be used and powered with a tablet or smartphone too...

During some surfing on Ebay I realized that with 4$ it is possible to buy enough ICs to build a complete Z80 system that can be done using a breadboard, and taste some flavor of retro computing.... So I did it and here it is the story!

Here is a video with the Z80-MBC in action:

and here with a smartphone (so it is explained the word "Mobile" in his name...) with a common OTG cable (the various test clips in this video were used for some measurements with a Logic Analyzer):


The needed ICs are:

  • Z80 CPU CMOS (Z84C00) 4Mhz or greater ($1.16)
  • Atmega32A ($1.70)
  • TC551001-70 (128kB RAM) ($1.10)
  • 74HC00 ($0.25)

Total cost: $4.21

The wires were taken from salvaged broken LAN cables, and the other components were salvaged from others unused breadboards.

The schematic is attached in the Files section. The MCU Atmega32A is used as universal I/O subsystem, as Eeprom, and as reset and 4MHz clock generator for the Z80 CPU.
Into the Atmega32A it is flashed an Arduino bootloader taken from here , and it is possible to use the Board Manager of the Arduino IDE for that.

Flash the Arduino bootloader at first (with the method you prefer), next you can start to build the whole thing!

Of course I used the Arduino IDE to develop the IOS (I/O Subsytem) that interacts with the Z80 bus and "virtualizes" the peripherals seen by the Z80 CPU.
As oscillator it is used the internal 8MHz Atmega32A oscillator, so no quartz is needed, and from this one is derived the 4MHz clock for the Z80 CPU (so the "Internal 8MHZ osc." bootloader variant must be chosen when flashing the bootloader from the Arduino IDE!).

The 74HC00 is mainly used as RS flipflop to stop the Z80 CPU during I/O operation, giving the needed time to the Atmega32A to interact with the Z80 bus.
The 128kB RAM TC551001 is used only for half (64kB) because the Z80 address space is only 64kB (I've chosen this IC for the low cost).
Note that only the CMOS version of the Z80 CPU can be used here. This because only CMOS version, under given condition that are respected in this schematic, has logical levels compatibles with Atmega32A and 74HC00.


You can use any Z80 CMOS speed grade, because the lowest is 4MHz.
The Atmega32A can be substituted with an Atmega16A, I've chosen the first one just to have enough space for future upgrades.
The 74HC00 can be substituted with a 74HCT00 if you already have one.
The RAM chip TC551001-70 can be substituted with any suitable 64kB RAM (do not use < 64kB RAM).
The USER led (D5 in the schematic) MUST be blue or white just to be sure that V(forward) is >= 3V.

Here is a video that shows a simple basic program that interacts with the "USER led" and "USER key":

On the breadboard there are others status led: the HALT led turns on if an HALT instruction is been executed and the Z80 CPU is in a Halt state, the DMA led turns on during DMA operations when the Z80 bus is in Hi-Z, the IO_OP led turns on when the Z80 CPU is accessing a I/O virtual device "emulated" by the Atmega32A (as the serial port), the LED_D0 led is the classical "Arduino" led (that one connected to D13 pin on the Arduino Uno) that here is connected with the Arduino D0 pin and is turned on normally as a power on indicator.

The serial port SERIAL-USB (see schematic) can be connected with a TTL-RS232 adapter, or with a serial-USB adapter.
I've used a serial-USB adapter that acts also as power source for the Z80-MBC, and has the DTR signal for the "autoreset" driven from the Arduino IDE. For a terminal that has a serial TTL port no adapter is needed.

In the schematic there is also the IOEXP port to expand the I/O capabilities, i.e. adding GPIO ports or a RTC for future expansions.


I've "ported" the Basic interpreter to the Z80-MBC using the sources provided in the great Grant Searle site , after the needed modification due the...

Read more »


The sketch for the Atmega32A (New release. Adds the Forth language and the multi-boot selection).

x-arduino - 129.42 kB - 02/17/2017 at 21:18


Two SDCC demo programs.

Zip Archive - 1.25 kB - 02/09/2017 at 21:11


Two .BAT files for the SDDC toolchain.

Zip Archive - 1.01 kB - 02/09/2017 at 21:10



"crt0" source file for the SDCC compiler.

Assembler Source File - 4.23 kB - 02/09/2017 at 21:08


Z80-MBC Eagle 2-Layer PCB and schematic made by Bill Westfield (Thanks Bill for sharing!). See his GitHub site for more info:

Zip Archive - 2.04 MB - 02/04/2017 at 17:30


S091216 R230117.asm

Z80-MBC uLoader source file

asm - 3.70 kB - 01/31/2017 at 20:42



Z80-MBC iLoad source file.

asm - 15.06 kB - 01/31/2017 at 20:42



The Assembler demo program used in the video for the "automated" Assembler toolchain.

- 1.80 kB - 01/31/2017 at 21:38



Tera Term macro for the "automated" toolchain.

turtle - 708.00 bytes - 01/31/2017 at 20:40


Two .BAT files for the Assembler toolchain.

Zip Archive - 1.03 kB - 01/31/2017 at 20:40


View all 16 files

  • Forth language, new multi-boot selection and a new name

    Just4Fun6 days ago 4 comments


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

  • An automated C language toolchain

    Just4Fun02/09/2017 at 21:26 0 comments

    Here how set up a toolchain to program the Z80-MBC using the C language. It is based on SDDC (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 SDDC 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 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 SDDC 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 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 SDDC

    I'm pretty new to SDDC. The SDDC documentation is 8051 "focused", so the given examples can be misleading if used with an other processor in mind.
    When "porting" SDDC 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 SDDC 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!

  • Two layers PCB!

    Just4Fun02/06/2017 at 20:44 0 comments

    Thanks to Bill Westfield now we have a beautiful ready to made PCB!

    I've uploaded in the Files section all the Eagle files (schematic + PCB) zipped as
    There are two versions, the first one with some little bugs and a second one with the needed corrections (see the "readme" file inside the zip for the explanations).

    In any case I suggest to check at the Bill GitHub repository here for any update/information before sending it to a service (so you are sure to use the last updated version...).

  • New iLoad boot mode and an automated Assembler toolchain

    Just4Fun01/31/2017 at 20:36 2 comments

      This new IOS release (S221116_R230117_Z80.ino in the Files section) brings a new dual-boot mode. Now it's possible choose if boot with the usual Basic or use the new iLoad boot mode.
      iLoad (S260117.asm in the Files section) is an Intel-Hex bootloader that allows to load from the serial port a binary program using the Intel-Hex format, and execute it. I've used a large part of the source from this site.

      To select a boot mode just push the Z80-MBC Reset button and immediately after push the User button at least until the User led turns off.
      The selection works as a toggle switch, and is stored in the EEPROM.
      Here it is a video that shows how to switch:

      Using the iLoad boot mode it's possible to automate all the process from the source to the execution in the target.
      This video shows an automatic Assembler toolchain; only one command from the source assembler to the execution on the target (the source file BlinkDemo.asm used in the video is in the File section):


      What you need to do:

      1. Set up a Windows host or a VM (Virtual Machine). I've used a Windows XP SP3 VM onto a linux host;
      2. Load the Windows driver for your serial-USB adapter. Remember that your dongle *must* have the DTR signal;
      3. Create a working directory where to store the assembler sources, the assembler program and the two batch files (A.BAT and L.BAT) in the file (see the File section). 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 A.BAT and L.BAT and verify that both the path and the COM number (/c=3 means COM3) meet your system;
      4. Download and copy in the previous directory the TASM v3.2 assembler from here. The on-line manual is here;
      5. Download and install the "Tera Term" terminal emulation from here;
      6. Set up Tera Term. From the Tera Term "Setup" menu select "Serial port..." and configure the parameters for your COM<n> connection to your serial-USB adapter. Set 9600 Baud, 8N1, Flow control none, Transmit delay 40ms/line. Save configuration with "Save setup..." from the "Setup" menu;
      7. Copy the file LoadZ80.ttl (see Files section) in the "Tera Term" installation directory, where it is installed the main file ttermpro.exe (for a standard installation for an English Windows version should be "C:\Program Files\teraterm");
      8. Open the file LoadZ80.ttl with a text editor and go to line 10. Edit the "setdir" parameter to meet your working directory path and name created at point 3. on your system, and save the file;
      9. Open the DOS command line and go in the working directory (using the CD dos command), attach the serial-USB dongle to the Z80-MBC and for a VM "connect" the dongle to the emulated usb of your VM. All done!

      Now it's time to check if it is all ok. From the DOS command line give the command: "A blinkdemo.asm" to check if all the toolchain works as in the video. To load the last compiled program give the command "L" without parameters. To load a specific intel-hex file give the command "L <filename.hex>".

      Close Tera Term before every new upload.

      iLoad behavior

      Please remember that iLoad will take the first address of the intel-hex stream as the starting address of the program, and after the loading will jump to it.
      iLoad will check the hex stream for errors, and protects itself if "someone" try to load a program (or a part) over it ("illegal address" error).

  • GPIO Expansion Module

    Just4Fun01/22/2017 at 13:50 2 comments

    This is the first add-on module for the Z80-MBC. It is a 16x GPIOs expansion module based on a MCP23017 IC, and can be easily connected to the Z80-MBC using the IOEXP connector (based on a I2C serial interface), of course on a breadboard...

    In the Files section I've added the schematic (A080117.pdf) and all the KiCad4 files (A080117
    There is also a new release of the IOS (S221116_R200117_Z80.ino) that takes care of it. During the boot phase, if the GPIO expansion module is found, a specific text is displayed:

    No configuration is needed, just plug it.

    Here is a short demo video:

    Each GPIO can be configured as input or output, and for each single input it is possible activate a 100K pull-up resistor. Of course this can be done from the Basic language, using new "virtual" I/O addresses as a language extension (if the module is not present, these I/O addresses are simply ignored):

    New WRITE I/O addresses:

              // GPIOA write (GPIO Expansion Module):
              //                I/O DATA:    D7 D6 D5 D4 D3 D2 D1 D0
              //                            ---------------------------------------------------------
              //                             D7 D6 D5 D4 D3 D2 D1 D0    GPIOA value (see MCP32017 datasheet)
              // GPIOB write (GPIO Expansion Module):    
              //                I/O DATA:    D7 D6 D5 D4 D3 D2 D1 D0
              //                            ---------------------------------------------------------
              //                             D7 D6 D5 D4 D3 D2 D1 D0    GPIOB value (see MCP32017 datasheet)
              // IODIRA write (GPIO Expansion Module):
              //                I/O DATA:    D7 D6 D5 D4 D3 D2 D1 D0
              //                            ---------------------------------------------------------
              //                             D7 D6 D5 D4 D3 D2 D1 D0    IODIRA value (see MCP32017 datasheet)
              // IODIRB write (GPIO Expansion Module):
              //                I/O DATA:    D7 D6 D5 D4 D3 D2 D1 D0
              //                            ---------------------------------------------------------
              //                             D7 D6 D5 D4 D3 D2 D1 D0    IODIRB value (see MCP32017 datasheet)
              // GPPUA write (GPIO Expansion Module):
              //                I/O DATA:    D7 D6 D5 D4 D3 D2 D1 D0
              //                            ---------------------------------------------------------
              //                             D7 D6 D5 D4 D3 D2 D1 D0    GPPUA value (see MCP32017 datasheet)
              // GPPUB write (GPIO Exp. Mod. ):
              //                I/O DATA:    D7 D6 D5 D4 D3 D2 D1 D0
              //                            ---------------------------------------------------------
              //                             D7 D6 D5 D4 D3 D2 D1 D0    GPPUB value (see MCP32017 datasheet)

    New READ I/O addresses:

                // GPIOA read (GPIO Expansion Module):
                //                I/O DATA:    D7 D6 D5 D4 D3 D2 D1 D0
                //                            ---------------------------------------------------------
                //                             D7 D6 D5 D4 D3 D2 D1 D0    GPIOA value (see MCP32017 datasheet)
                // NOTE: a value 0x00 is forced if the GPIO Expansion Module is not present
                // GPIOB read (GPIO Expansion Module):
                //                I/O DATA:    D7 D6 D5 D4 D3 D2 D1 D0
                //                            ---------------------------------------------------------
                //                             D7 D6 D5 D4 D3 D2 D1 D0    GPIOB value (see MCP32017 datasheet)
                // NOTE: a value 0x00 is forced if the GPIO Expansion Module is not present

    And here is the Basic program used in the video (the HW wiring is shown in the comments):

    1 REM * * * GPIO EXPANSION MODULE (A080117) DEMO  * * *
    2 REM
    3 REM (USER Key -> slow led, GPIO-A(9) Key -> fast led)
    4 REM --------------------------------------------------
    5 REM Demo HW wiring (see A080117 schematic):
    6 REM
    7 REM   GPIO-B
    8 REM    (J3)
    9 REM   +----+   LED
    10 REM  | 2  |--->|---+
    11 REM  | 3  |--->|---+      RESISTOR
    12 REM  | 4  |--->|---+        680
    13 REM  | 5  |--->|---+-------/\/\/-----o GND
    14 REM  | 6  |--->|---+
    15 REM  | 7  |--->|---+
    16 REM  | 8  |--->|---+
    17 REM  | 9  |--->|---+
    18 REM  +----+        |
    19 REM                |
    20 REM                |
    21 REM  GPIO-A        |
    22 REM   (J4)         |
    23 REM  +----+   LED  |
    24 REM  | 2  |--->|---+
    25 REM  | 3  |--->|---+
    26 REM  | 4  |x 
    27 REM  | 5  |x
    28 REM  | 6  |x
    29 REM  | 7  |x     PUSH BUTTON            RESISTOR
    30 REM  | 8  |x        ---                   1K
    31 REM  | 9  |---------o o------------------/\/\/-----o GND
    32 REM  +----+ 
    33 REM
    34 REM
    35 REM
    36 REM --------------------------------------------------
    37 REM
    38 REM Set MCP23017 GPIOB all pins as output (IODIRB=0x00)
    39 OUT 6, 0
    40 REM Set MCP23017 GPIOA 0-1 as output, others as input (IODIRA=0xFC)
    41 OUT 5, 252 
    42 REM Set MCP23017...
    Read more »

  • SOFTWARE INTERNALS: The boot process

    Just4Fun01/04/2017 at 14:35 0 comments

    Here is a description of the two phases boot process and the sources of the Loader and the uBIOS + Basic (as requested by some people).

    At power on, the Atmega32A uses a DMA access to SRAM to copy the loader in the upper memory address space.
    Because the loader is small, only a limited number of address lines are requested, saving some GPIOs for others tasks.

    When the Atmega32A completes the DMA loading phase (first phase), it releases the Z80 bus and resets the Z80 CPU that starts to execute the loader from SRAM starting at address $0000.

    Then the loader relocates itself at the bottom of the memory address space and it loads from the Atmega32A (this time used as a "virtual" sequential ROM in the I/O address space) the uBIOS + Basic image (second phase).

    After this second load phase it jumps to the starting address of the uBIOS + Basic image, and executes it.

    Inside the Arduino sketch you can see the two hex arrays. The smaller one is the Loader image, the bigger one is the uBIOS + Basic image.

    In the Files section I've added the Loader source (S091116.asm) I wrote from scratch, and the two files (uBIOS and Basic) I took from the Grant's site. I've modified the first one (the one I've called uBIOS) that contains the I/O routines due the different HW design. In particular I changed the I/O addresses, the init code made for the original ACIA and the code to menage the internal registers of the ACIA. I've changed also the code that manages the ACIA serial handshaking because not needed here (the serial is managed inside the Atmega32A by the Arduino bootloader "environment") . You can easily see any modification in the source (S121216.asm) because they are marked with the string "Z80-MBC:" in the comment.

    I left the Basic interpreter (basic.asm) untouched (for now, until I need some custom commands...).

View all 6 project logs

Enjoy this project?



asorc wrote 4 days ago point


Does the serial port accept keyboard? Could I use a TV with composite video connection as an screen? Or better, Is it possible to add a composite video connection to this computer?

Thanks, very, very, very nice project. Thanks for sharing it. Regards.

  Are you sure? yes | no

Just4Fun wrote 3 days ago point

Hi, for now is not possible. Only one serial communication is allowed (so you can use a serial-USB adapter for a PC terminal emulation or a serial-RS232 adapter for a "physical" asynchronous terminal as a VT100 or VT220 etc..).

But you can easily build your own asynchronous terminal and attach it to a video composite TV input and a PS/2 keyboard with just one Atmega328 and one 74HCT166 (for the video signal generation) and one Atmega88 (for the keyboard). See this project made by Grant Searle:

I also remember an other project around that uses SPI output for the video generation without the need of the 74HCT166 shift register (if I remember well)...

  Are you sure? yes | no

WestfW wrote 02/12/2017 at 23:32 point

I found this similar project; fewer details, but it does look like they got CP/M running...

  Are you sure? yes | no

Just4Fun wrote 02/13/2017 at 07:32 point

Interesting... it seems the same approach...

I was curious to see how he managed the the t(hold) stuff on the Z80 bus, but there isn't any detail about it... :(

In any case there are some information...

  Are you sure? yes | no

WestfW wrote 02/12/2017 at 20:45 point
"I'd better use DosBox"

 Hmm.   The last time I tried to use DOSBox, it was excessively focused on running old games, which you'd think would be MUCH harder than running old command-line compilers.   I wonder how much work it would be to put together a more CLI-oriented DOSBox for the non-gaming retro-computing community, that would end up with a Wine-like interface "Dosbox tasm -80 figforth.asm"  (and I wonder how well the DOSBox source is documented...)

  Are you sure? yes | no

villaromba wrote 02/11/2017 at 11:51 point

Thank you for updating SDCC guide, much clearer and at last I have ANSI.c working. Couldn't figure out the crt0 bit!! Looking forward to CP/M and Forth .............

  Are you sure? yes | no

WestfW wrote 02/11/2017 at 05:20 point

Whee!  fig-Forth 1.3 working!

I had to convert assemblers, and it took me a long time to figure out how TASM was treating some of the code differently than the original 8080 assembler; it was causing really mysterious problems!  Added

  Are you sure? yes | no

villaromba wrote 02/11/2017 at 12:24 point

Thank you - works brilliantly - need to get the Forth books out now!!

  Are you sure? yes | no

Just4Fun wrote 02/11/2017 at 13:43 point

Wow Great!!

It seems I've to learn an other language... :-) (for now I can only replicate your example...)

It is about 8KB, so it leaves inside an Atmega32 about 10KB for CP/M stuff. I think it should be enough...

So next days I'll do a new IOS release with Forth and, at this point, a more "sophisticated" multi boot management... (and it's time to change the MBC acronym...)

BTW: In the meanwhile "some" AT24C1024 are on the way... I've just realized that I've got only an AT24C32 :(

Thanks again!

  Are you sure? yes | no

Scott wrote 02/11/2017 at 20:29 point

It's too bad that TASM is so incompatible with the Z80 assemblers available for Linux. :( No easy way to run TASM under Linux unless I use DOSBOX or the like, which I do not wish to do.  I would consider re-spinning it as a Linux executable but I cannot find the source code for TASM, so it must not have been released.

I found a program in UBUNTU repository named "intel2gas", which is supposed to convert TASM to AT&T format for GCC's "gas" assembler.  Looking at GCC, there is a "Z80 target" but I was not able to configure GCC and MAKE the target toolchain without error.  

Does anyone have a conversion script to convert TASM to either Z80asm or Z80-asm?

Peace and blessings.

  Are you sure? yes | no

legacy wrote 02/11/2017 at 21:06 point

I have the same problem with HC11. AS11.exe is 10 years light far from being compatible with GAS11. What's wrong with dosbox? it works on linux, macOSX, freeBSD and UNIX, even on a not-x86 machine (e.g. my Apple PowerBook G3 laptop). So have fun with it. 

Converters just don't work, especially for MACROs!

  Are you sure? yes | no

Scott wrote 02/11/2017 at 21:17 point

Thanks for your input.

If DOSBOX was like WINE, then I would.  With WINE, I can run "wine avrasm.exe test.asm" and it runs the "avrasme.exe" file, which assembles "test.asm" and leaves the resulting file in the current directory; easy and clean.  With DOSBOX, I have to run a separate (Free)DOS "virtual machine" and if I have to do that, I might as well just run TASM under my WINDOWS virtual machine under Linux.  

I was looking for a "cleaner" way to assemble Z80 programs via Linux command line tools so I can use an automated make file.

Peace and blessings.

  Are you sure? yes | no

legacy wrote 02/11/2017 at 23:06 point

keep in mind that Wine doesn't work with DOS16 executables, and it's not stable with win95 applications. It requires win32 binaries.

With dosbox you can mount the current folder. Inside dosbox, type "mount c: ."

Or check your home, you should have ~/.dosbox/dosbox.conf. In case, you just need to append the following:

mount c: .


  Are you sure? yes | no

WestfW wrote 02/12/2017 at 03:24 point

I'm using Wine to run TASM on my mac.  Aside from various error messages from Wine itself (because I'm running an older MacOS, I guess), it seems to work fine.

  Are you sure? yes | no

Scott wrote 02/12/2017 at 04:49 point

Hi Bill:

Holy cow!  Being that TASM is a DOS program, I never thought to try TASM under WINE!  I just tried it and it seems to work.  Thanks for that update.  :)

BTW: PCB is up and running.  I added a jumper to "bank select" A16 on the RAM between "upper" and "lower" 64KB bank.  No free I/O pins on the AVR though. :(

Peace and blessings.

  Are you sure? yes | no

legacy wrote 02/12/2017 at 10:32 point

well, googling you can find three versions of asm11.exe, an assembler for HC11: { Dos16bit version, Win95 version (16bit, Windows-95 API), Win32 version (32bit, Windows-98/99 API) }
a) The win95-asm11.exe executable works great under a real Windows XP machine, but it sucks a lot under Wine, it **seems** to work but  it does not, sometimes it does't work as expected, you don't see the error messages, and the list file is not generated.  Annoying.
b) The Win32-asm11.exe executable (updated to 2016) works great on both Wine and XP platforms. It generates list files, and I can see error messages if I voluntary type a typo, but the author has improved the code so much that the macro-handling is not compatible with the legacy code. I don't want to waste my time converting || fixing sources, so I just can't use it. 
*) DosBox. can execute nor win95 neither win32 binaries, not directly, check out sources, if Wine catches a Dos16 binary it tries to launch DosBox, and execution goes through it. DosBox can also run dos32bit executables, such as games which needed a dos-exteneder, e.g. DukeNuken3D and Doom.
c) The Dos16-asm11.exe executable works great under OS/2 Warp3/dos16-mode, XP/dos16-mode, and DosBox!
~ ~ ~ ~ ~
My conclusion is: for the vintage software, those things written for dos-16bit (including Turbo Pascal, Turbo C, ASM11, SierraC, OrCad SDT), I'd better use DosBox!

  Are you sure? yes | no

WestfW wrote 02/12/2017 at 20:35 point

In retrospect, it's not clear whether "TASM32" is version 3.2, or whether it's a WIN32 version of the .EXE.

I agree that Forth is a very odd language.  The nice thing about it is that you can get pretty quickly to a place where you can string together relatively language-like interactive constructs like:

   1 setuserled delay10ms 0 setuserled

without having to write any keyword or expression parsing code.

  Are you sure? yes | no

Scott wrote 02/12/2017 at 21:45 point


I investigated the type of executable TASM is.  Here is what Linux reports for TASM 3.2:  TASM.EXE: PE32 executable (console) Intel 80386, for MS Windows

I also tried TASM 3.1, which wine does spawn a DOSBOX window but no object files are produced.  Linux also reports: TASM.EXE: MS-DOS executable, MZ for MS-DOS

Thanks for the clarification.

I don't have to try and convert to another assembler format.  I just need to figure out how to pass the PATH to TASM.EXE and it's tables while I am in another directory.

Peace and blessings.

  Are you sure? yes | no

Scott wrote 02/13/2017 at 06:32 point

I was able to get V3.2 of TASM to work from the Linux command line.  It ran fine with WINE but passing the location of the TASM tables was an issue until I found the the user manual online.  The invocation is:

TASMTABS=[path to TASM directory] ; wine [path to TASM directory]/TASM.EXE -80 -la -x -s BlinkDemo.asm 2>/dev/null

WINE tends to dump extraneous (and annoying) debug info to the error console, so the "2>/dev/null" prevents that and you are left with TASM's output.  I am running the newly released version 2.1 of WINE but it should run the same under V1.4 as well.

WestfW has a bash script for MacOS now, which I think he will post when he gets a chance.

Peace and blessings.

  Are you sure? yes | no

Peabody1929 wrote 02/08/2017 at 01:05 point

Would you share the method you used to create the labels on each of the ICs?


  Are you sure? yes | no

WestfW wrote 02/08/2017 at 06:13 point

I used EAGLE, which was pretty easy because I already had the text for pin names placed on the PCB at the appropriate spacing anyway.  I just copied that part of the silkscreen to a new "board" , used rectangles on the top, bottom, and via layers to provide the colored background, and duplicated it a bunch, used the "print-transparent-brd" ULP to get the black-on-faded-colors look, and printed on full-sheet laser labels...
The file is in the github repository:

(I really like using EAGLE as a general purpose drawing tool when I have technical diagrams to make that need to have specific dimensions.  And not many drawing programs will let you enter coordinates in polar notation, which is useful ...  more often than I would have thought!)

  Are you sure? yes | no

Scott wrote 02/11/2017 at 21:20 point

I have a post that illustrates the method I used under Linux.  I provide a base template file with many DIP packages already outlined.  All you do is add the text (on separate layers) using GIMP.  Here's the post: 

Peace and blessings.

  Are you sure? yes | no

Just4Fun wrote 02/05/2017 at 14:39 point

Rainy day... So starting to make some experiments with CP/M...

  Are you sure? yes | no

villaromba wrote 02/04/2017 at 10:43 point

Great work and thankyou, blinkdemo.asm working great, just needed to amend .BAT files to agree with my directories and COM port in case anyone not aware that it may not be the same as yours. Like you now need to learn SDCC and try out the ANSI test. etc Looking forward to next installments!!!

  Are you sure? yes | no

Just4Fun wrote 02/04/2017 at 16:50 point

Ops... I forgot to mention it in the "guide"... 

Just corrected... :-)

BTW: The SDCC documentation is quite missing about how to modify for a custom system... anyway "googling" a little I've sorted...

  Are you sure? yes | no

WestfW wrote 02/04/2017 at 07:32 point

PS: Working on Forth, which should fit in the m32 flash WITH the BASIC already there.
Z80 Forth is apparently in a relatively sorry state - the ones I've found use obscure assemblers and/or have CP/M dependencies.  But ...  Forth is one of the environments that really benefits from a "RAM-rich" hardware implementation.

  Are you sure? yes | no

Just4Fun wrote 02/04/2017 at 17:02 point

This sounds good! I haven't ever used Forth, but after a 5 minutes search it seems a good "environment" for an "embedded" system... I'm very curious...

So the Z80-MBC will became a "multi-boot" system: BASIC, FORTH, Intel-Hex loader for Assembler and C toolchains, and... may be a day... CP/M too... 

(I'm starting to think to rename it as "Z80 Multi Boot Computer"....)

Not too bad for a 4$ system... :-)

  Are you sure? yes | no

Scott wrote 02/05/2017 at 06:31 point

Keep in mind that the ATmega644 and ATmega1284 are pin-compatible with the ATmega32, thus the larger memory parts can be used if larger memory requirements are needed. I.e. multiple "ROM" images; BASIC, FORTH, etc. 

  Are you sure? yes | no

Just4Fun wrote 02/05/2017 at 14:57 point

Yes ... I have to have both somewhere ... still are a bit expensive ... I'm starting to think about an Atmega128A .. I can find it for less than $ 1 ... but for a new HW revision... may be one day... :-)

  Are you sure? yes | no

WestfW wrote 02/06/2017 at 06:17 point

I'd rather add a bit I2C EEPROM "Floppy Drive." A 1Mbit EEPROM is 128kBytes, which is pleasantly similar in capacity to some of those early "mini" (5.25inch) floppy disks, is pretty commonly available in DIP8...

  Are you sure? yes | no

Just4Fun wrote 02/06/2017 at 21:02 point

Mmm... I was just starting to think what to use as "virtual" floppy.. The first thing was a SD as "the definitive" mass storage, but it brings some complexity in the current design... After all an I2C EEPROM might be a good tradeoff to start to play with CP/M... 

  Are you sure? yes | no

Scott wrote 02/06/2017 at 22:48 point

I toyed with the idea of using an off-chip I2C EEPROM for my Z80 SBC project but decided that using the SD card interface, although a bit more complex, does allow me the ability to "load" "virtual floppy disks" via my laptop.  Using an EEPROM as a "virtual floppy disk" would need a user interface written to transfer files back and forth from the laptop. 

WestfW, when you get a chance, check your private messages.

Peace and blessings,


  Are you sure? yes | no

Just4Fun wrote 02/07/2017 at 07:56 point

Yes...  this is the "odd" thing of using an EEPROM...
Anyway I think that it would be possible  to use both... I mean first one or
two EEPROMs as an easy first approach (as A: and B:), and then
eventually a SD as a virtual HD (as C:). This remind me "something"....

  Are you sure? yes | no

Scott wrote 02/07/2017 at 08:22 point

I agree; step by step.  EEPROM is easy to implement but limiting in accessibility.   Use as "proof of concept" then perhaps SDcard, which is more accessible but has a steeper learning curve to implement.  Always baby steps when creating, yes? :)

  Are you sure? yes | no

Just4Fun wrote 02/03/2017 at 14:47 point

Hi all, the C toolchain seems to work. I'm using SDCC (I'm pretty new to SDCC, and i had to figure how to do...).

Here is an ANSI test taken from here: (and only a little adapted...):


Stay tuned...

  Are you sure? yes | no

john wrote 02/03/2017 at 15:32 point

Too cool!  Very nice work with the loader!

  Are you sure? yes | no

WestfW wrote 01/30/2017 at 08:53 point

Hmm.  it occurs to me that for old CPUs that have DMA based on "I release the bus!" mechanisms, you could essentially simplify the interface even further (though probably not get the chip count any lower.)  A "mailbox" of shared memory, plus "ATTN", BUSREQ, BUSACK, and RESET, and that's it.  The Z80 (or whatever) would put stuff at a known location and signal ATTN to the AVR, which would then take the bus, read and re-write the shared memory, and give it back.  At poweron, the AVR could put the bootstrap in low memory instead.
I guess the problem is that while you'd still be running on an actual Z80, it would rapidly become non-retro-like WRT its IO...

  Are you sure? yes | no

Just4Fun wrote 01/31/2017 at 07:21 point

Interesting approach... virtually HW independent...

A problem in this case would be that the various CMOS SRAM seem to have strictly TTL outputs (at least datasheets says so...), so readings SRAM directly from an AVR would be possible only using an analog read for each pin and reassembling the byte... possible (in fact the data bus pins are also analog pins... it is not a coincidence...) but time consuming... so I left this way as last chance.

  Are you sure? yes | no

WestfW wrote 01/31/2017 at 09:40 point

Hmm.  The RAM Voh specs are a little annoying, aren't they?  Since the technology is CMOS, I *suspect* the low guaranteed output voltage is a current drive issue, and won't come into play as long a everything that's connected is also CMOS (and not requiring any drive current to speak up.)  In any case, since I'm still waiting for my Z80s, I've been playing with just the AVR and memory, including writing a little "memory test" utility that writes AND READS the memory from the AVR.  It seems to work fine (even though my memory chip also says 2.4v min output.  And the scope shows a nice and solid 5V output.  (you spend a lot of time poking around with a scope if you forget that you have to read PINx rather than PORTx.  Sigh.  The test program pretty much lets you step through individual accesses so you CAN poke around, as well as doing the full speed memory test.)

Single Step Memory Read from 7
Requesting DMA. DDR = 00 f3 fc fc.  PORT = 8a 72 1a 21
Control signal. DDR = 00 f3 fc fc.  PORT = 8a 72 1a a1
Bus Direction. DDR = 00 f3 fc fc.  PORT = 8a 72 1e 21
MREQ_ low   . DDR = 00 f3 fc fc.  PORT = 8a 32 1e 23
RD_ low     . DDR = 00 f3 fc fc.  PORT = f8 12 1e a3
RD_ high    . DDR = 00 f3 fc fc.  PORT = f8 32 1e 23
MREQ_ high  . DDR = 00 f3 fc fc.  PORT = f8 72 1e a3
Data read: f8 if you'd like to play with it.  I *think* it should work with or without the Z80 in-circuit...

  Are you sure? yes | no

Just4Fun wrote 01/31/2017 at 10:16 point

Ops... I've realized only now "Who" you are... :-)

  Are you sure? yes | no

K.C. Lee wrote 01/31/2017 at 10:40 point

I suspect the TTL compatible VOH (min) is left over from the old days for old TTL loads.  Chances are that it would go to full rail for CMOS high impedance only loads.

CMOS input threshold is actually targeted to be half rail.  All the AC timings are usually specified that way. However this parameter is dependent on the input MOSFET P and N types to be identical.  They also want to have enough guard band to make sure that the input stage doesn't have shoot through.

Unfortunately can't depend on the being full CMOS compatible for a proper paper design even though it would likely work for most parts not under extreme conditions.

  Are you sure? yes | no

WestfW wrote 02/01/2017 at 00:48 point

Hmm.  Even the CMOS Z84C00xxx chips have the same 2.4V Voh spec.  Perhaps we're just lucky.  I never would have noticed; is there some famous example of CMOS SRAM *not* working with modern CMOS processors?

  Are you sure? yes | no

Just4Fun wrote 02/01/2017 at 05:27 point

In the Z80 CMOS datasheet there is the Voh2 parameter valid if load is not greater than 250uA. In this case Voh2 is higher than 2.4V...

See page 30 (of the file) here:

Instead in the various CMOS SRAM datasheet nothing is said for "low" load... :-(

  Are you sure? yes | no

K.C. Lee wrote 02/01/2017 at 10:08 point

You can find them if you know what to look for (and what to do with it).  

There are IBIS model for simulation which are essentially voltage vs current curves data for I/O pads.  These are what people typically use for signal integrity simulation.  under Software & Tools

  Are you sure? yes | no

K.C. Lee wrote 02/01/2017 at 10:24 point

FYI: The typical VIH is actually very similar to TTL at 5V.  It is however not part of the guaranteed specs.

  Are you sure? yes | no

Just4Fun wrote 02/02/2017 at 07:43 point

Interesting... I have not ever thought about using those simulation models...

  Are you sure? yes | no

Just4Fun wrote 01/28/2017 at 19:37 point

Hi all, a new update is coming... Stay tuned...


  Are you sure? yes | no

john wrote 01/28/2017 at 14:37 point

Just finished my build of this - ended up with ATMEGA32 clocked at 16 MHz so Z80 is running at 8MHz.  Great project and was a lot of fun to build.  

  Are you sure? yes | no

Just4Fun wrote 01/28/2017 at 19:35 point

Thanks! Great built... :-)

  Are you sure? yes | no

Peabody1929 wrote 01/28/2017 at 00:06 point

Outstanding project!  I am going to build one.  I ordered some faster parts: 15ns 64Kx8 CMOS SRAM and 20MHz CMOS Z80.  This could be a damn fast Z80 system.  Thoughts on high performance?

  Are you sure? yes | no

Just4Fun wrote 01/28/2017 at 11:34 point

Thanks!. The FW on Atmega "should work" at those speed "virtually" without modifications. Of course I haven't done any test @ 20MHz... so let me know....

  Are you sure? yes | no

villaromba wrote 01/25/2017 at 16:22 point

Hi, I have a minipro TL866A eprom burner which can handle the ATMega32A. Can I just use your .ino file, program the IC  and then plug into the board and go or do I need a bootloader first? thnx

  Are you sure? yes | no

john wrote 01/25/2017 at 18:40 point

Once you compile the code in the Arduino environment, there will be a .hex file (somewhere in your Arduino folder - can't remember where) that you can use with the TL866A.  I believe in that same folder, there is a version that has the bootloader included as well for the device type you selected in the Arduino environment.  Just make sure to get the fuse bits right, and to disable JTAG or your PortC pins won't work...

  Are you sure? yes | no

Just4Fun wrote 01/26/2017 at 10:08 point


in the Arduino forum someone posted a software to use the TL866 with the Arduino IDE as programmer:

It seems that you can upload the .ino directly (no bootloader) with that, and the "burn bootloader" option seems not to work.

So try to give a look....

About the Arduino bootloader, you can upload the .ino (I mean after the compilation, so is an .hex file) without the bootloader too. In this way you need to re-use your programmer for every upload (when/if needed).

  Are you sure? yes | no

Just4Fun wrote 01/21/2017 at 18:17 point

Hi all, something new is coming... Stay tuned...

  Are you sure? yes | no

villaromba wrote 01/21/2017 at 14:39 point

Sorry, sorted out please ignore previous comment !!!!

  Are you sure? yes | no

villaromba wrote 01/21/2017 at 14:34 point

Great project .. I thought before I build the hardware that I would get an Eprom programmed so went through the build cycles - all to the video and all went OK, just a question at the BUILDROM.cmd stage - I get the same options as you - so selected SMB but options that then come up  are different - I get acia, acia_vfd, SIO, SIO_vfd, SIO_vfd_8in ..... I selected SIO but do you think this will be a problem (I didn't get the std that you selected). Thanks for your advice

  Are you sure? yes | no

WestfW wrote 01/18/2017 at 12:35 point

Starting to look relatively real!

Three mistakes so far: two missing pull-x resistors, and a signal trace that collided with a power trace :-(   Nothing too difficult to repair, though!  Still waiting for chips (and it turns out I hadn't ordered them when I thought I had...)   I also bugged Atmel for some samples :-)

  Are you sure? yes | no

Just4Fun wrote 01/18/2017 at 12:54 point
Hi, I've seen that you added a couple of power connectors... good idea...
On the back side (your previous photo) it seems to be some SMD capacitors on it. Do you have added more bypass caps?

  Are you sure? yes | no

WestfW wrote 01/18/2017 at 23:38 point

Yeah. For personal/hobbyist PCBs, I like to put SMT bypass caps on the back of the board (where they usually fit pretty easily) as well as TH caps on the front. That way you can populate with whichever you happen to have on-hand (if you're like me, at some point you bought a "near infinite supply" of some type of bypass cap...) It doesn't hurt that this also means you can do "extra" and "multiple value" caps "if needed."

  Are you sure? yes | no

WestfW wrote 01/27/2017 at 03:32 point

Meh.  My ATmega32s arrived, and I found another bug.  Rx&Tx swapped :-(  I would have thought I would have noticed that!  Also, apparently I don't have any 74HC00s.  I have some in SMT.  I have some 4011s.  I have 74hc30s.  But no DIP 00s that I can find (Now sorting through piles of stuff.  Sigh.)
On the bright side, after spending a day debugging a mis-spelling of "AVR_FREQ" to build a custom bootloader, I now have the AVR mounted on the board and accepting sketch uploads.

  Are you sure? yes | no

Just4Fun wrote 01/27/2017 at 07:42 point

Hi, just for curiosity.... why do you need a custom bootloader?

BTW: Next thing will be a "developer boot mode" and an Assembler "toolchain"...

  Are you sure? yes | no

WestfW wrote 01/28/2017 at 03:00 point

I made the bootloader startup blink happen on your "User" LED.  I'm very familiar with the bootloader, and it should have taken mere seconds.  But it didn't :-(
(using the "Mighty" Core, connect to the bootloaders directory and use "make atmega32 AVR_FREQ=8000000L LED=D5 BAUD_RATE=38400" before you use the "burn bootloader" command in the Arduino IDE.)

ZDDT?  I was going to work on adding some big I2C EEPROMs for "files."  A 1Mbit EEPROM is "about" the size of a floppy "from those days."

  Are you sure? yes | no

WestfW wrote 02/02/2017 at 04:12 point

Woot!  Working.  (without the missing pull-resistors, which may explain some occasional weird behavior...)

  Are you sure? yes | no

Just4Fun wrote 02/02/2017 at 07:28 point

Great! Nice label too (Definitely better than mine...)

BTW: You have the "old" IOS... Try the last one with the "dual-boot" feature... (see last "Log").

PS: I've found the "original" Startrek game in Altair Basic. It should run here... I can upload it... may be it's more fun than the FOR NEXT cycle... :-)

Now "working" at the C toolchain...

PPS: until now I haven't seen any weird behavior on the breadboard  leaving running it  for hours with the "GPIO expansion module" attached...

  Are you sure? yes | no

WestfW wrote 02/04/2017 at 07:38 point

I decided that things are "good enough for OSHW" and uploaded EAGLE files to

(actually, two sets of EAGLE files.  Your choice of "Broken in known ways and know to be fixable" or "probably fixed, but untried."  See the README.)
I'm not sure how to handle this WRT  I don't think it should be a separate "project" (github is more of a file repository than a project host, IMO.)  You (just4fun) are welcome to put a copy of the files here, if you wish.

  Are you sure? yes | no

Just4Fun wrote 02/04/2017 at 17:29 point

Great! I'll post a new "Log" on this topic next days... Thanks a lot!

For now I've uploaded yours Eagle files for both "versions"...

BTW: I'm starting to think about a new HW revision... I've a couple of ideas... may be two HW revisions, one only TH and an other one "boosted" with "mixed" TH and SMD... but for now it is too early... and I've other things to do before...

  Are you sure? yes | no

Scott wrote 01/13/2017 at 04:38 point

I like this  design.  I had to take a few minutes to see how the bootloader works; 1) AVR copies the bootloader to Z80 RAM then 2) the Z80 bootloader xfers the BASIC image from the AVR to RAM on its own.  I see an 'HC00-Flip-Flop to force a wait condition while the AVR responds to "I/O" requests.  That's a simpler method than I am using. :)  Using that method, do you know what the latency time is for the Z80 to make an I/O request till the time the AVR responds with data available on the data bus?

I am presuming this is a "proof of concept design".  Do you have intentions of going further with it? i.e. adding more I/O?

I am working on a similar design using a TEENSY++ 2.0 as the host controller.  Using a 16MHz AVR, the Z80 clock can be as high as 8MHz (using an OCx output).  I was looking forward to the end design goal, which is to use an SDcard as a "disk drive" (or drives) for the Z80 (CP/M), the TEENSY as a TTL-2-USB bridge and and "system monitor".  I have intentions of implementing a software debugger as well since there doesn't seem to be any available except via the software emulators, which sometimes do not work with all code.  I wanted to read all 16 bits of the address bus, for memory test, etc. and the AT90USB1286 on the TEENSY does not have enough I/O to access all address, data and Z80 control lines so I use a 74HC299 as a bidirectional data bus expansion interface and two 8-bit ports for the upper and lower address lines.  

Thanks for the effort!

P.S. Bill Westfield; any extra PCB's available?

Peace and blessings,

Johnny Quest

  Are you sure? yes | no

Just4Fun wrote 01/13/2017 at 11:15 point

Hi, I'm glad for your question. You are the first person that focused the * main * aspect of this thing: how the AVR interacts with the Z80 bus! In fact there is a double "hidden" trick that makes the whole thing working!!! (I mean hidden "inside" the schematic...), and the FF is only a little part of it. Explain all the "process" is a little complex and can't be done here. I'll make a "log" on this theme (as I did for the boot process), but it require some time to prepare some theoretical timings to explain it.

I'm currently working on a GPIO expansion (HW 80% done, SW 0% done) , so this it shall be the next thing. I'm just starting now to study the CP/M porting....

There are a lot of improvements that can be done.... may be a "boosted" version (but not on breadboard....).

I do this in my little spare time... so this is the limit....

  Are you sure? yes | no

Scott wrote 01/13/2017 at 12:12 point


Thanks for your reply.

I am not sure if you had a look at my project.  The difference in our two methods of using the AVR as a "host (I/O) controller" are slightly different.  In your case, any access to I/O space triggers the WAIT F/F, thus holding the Z80 in a perpetual WAIT state until your AVR can service the request.  That certainly simplifies the timing.  If I am not mistaken, your AVR also initiates a Z80 IRQ and tosses an IRQ vector on the data bus, yes?

And yes, my original breadboard version got complex very quickly, which is why I decided to cut a PCB. :)  No doubt, you are likely at that stage as well. :)

In my design, I wanted to keep the AVR in SLEEP mode and only wake it from SLEEP when it is needed, thus conserving power since the intention is to use the USB connection for power and being limited to ~500 ma max.  The AVR data sheet states that the AVR needs ~5 clock cycles to service an external IRQ (INT0).  In testing with a logic analyzer, I found that at 16MHz, the AVR IRQ service routine needed about 14 cycles (875nS) maximum to respond and set the WAIT line active, hence the programmable WAIT state generator design to force a WAIT condition until the AVR can respond.  This of course varies depending on the clock speed of the Z80, which is also programmable via the "host controller" as is the number of wait-states.  

That's the reason for my question concerning the response time of your AVR once a WAIT state is asserted.

Since the wait-state generator is contained within a GAL22V10, I may look into implementing a simple F/F as you did.  It may be easier to work with and would not require setting "X" number of wait-states depending on the Z80 clock speed.

I like your use of the larger RAM chip.  I had about 20 pieces of the 32Kbx8 RAM on hand, so they made their way into the design.  But a single RAM takes less PCB space and fewer trace runs.  It also allows bank-switching, which I see you are not implementing in your current design. I/O pin limited, eh? I know the dilemma. :)

I noticed you are using the internal 8MHz oscillator on the AVR.  Since timing is not critical in the case of your design, that makes sense.  If speed becomes an issue, the AVR is rated to 20MHz at 5 volts, which would reduce your response and servicing time by about 60%.

What you are doing with your Z80 bootloader and the AVR as a sequential ROM dumper are the equivalent of what I am planning to do with the SDcard interface.  Of course, I'll need to modify a custom CP/M BDOS for it to work with the AVR/SDcard interface.

I have the hardware finished on my project and have performed some preliminary hardware testing but I have spent the last several weeks on another parallel project I am working on, so the Z80 SBC progress has fallen a bit behind. :(

On the GPIO, is that something you are planning to do with the I2C interface?  Perhaps using one of the PCF8574's?  For CP/M, you might look into the DS3231 (I2C interface) as a Real-Time Clock for date/time stamping.  eBay has modules with a battery for about US$1.25.

How are you testing your Z80 code?

What are you using for your Z80 assembler?  I tried Z80ASM and Z80-ASM under Linux and both failed to assemble your source code.

If you are like me in this respect, taking a step a few decades back in time to to the days of the Z80 is certainly another learning process.  Adding to that the AVR "technology" and mating it with the Z80 is another learning process, not to mention eventually delving into the internals of the CP/M source code but I find the challenge in hardware and software rewarding. :)

Looking forward to seeing more progress on this design.  Thanks again for sharing.

Peace and blessings my friend,

Johnny Quest

  Are you sure? yes | no

WestfW wrote 01/16/2017 at 10:14 point

>> P.S. Bill Westfield; any extra PCB's available?
I had 10 made; I've got some local people that might be interested, but there might be one or two left over.  If they work, I'll be posting the CAD files.  Though they're a bit big to be economical on OSHPark, and PCBWay/etc will give you 10 boards at a time.

I thought the IO mechanism was obvious (which makes it elegant!) - is there more to it than going into continuous wait states on any IO request?  You should be able to plug in "more complicated" devices where the AVR is now, and use the same mechanism.  Probably even paralleled m32's that each only respond to "their" part of the io address space...   And it should work on other chips that use a similar wait-state mechanism (8085, 6800, 6502, 6809...) (but memory mapped IO will make some aspects harder...)  (And I haven't thought further than IO plus "boot state."  Interrupts might be complicated as well.)

  Are you sure? yes | no

Scott wrote 01/16/2017 at 10:40 point

Hi Bill:

Thanks for your reply.  I sent you a private message on your PCB's.  

I looked at pricing for  OSHPark and thought they were expensive.  I also looked at PCBway and they're a little high as well.  For my Z80 SBC and 8052 SBC projects, I went with . 10 pieces of a 3x4 inch, 2-layer PCB was US$41 total ($22 + $19 shipping).

On your thoughts about using the AVR host controller as a more complicated I/O device, that's my intention, to use the AVR as a "virtual peripheral", or multiple "virtual peripherals".  I plan to emulate an i8051 or MC6850 UART and *maybe* an i8072 FD controller, depending on how I modify the CP/M BDOS.   

The AT90USB1286 used on the TEENSY++ 2.0 has built-in USB hardware, so it can be programmed to be a "CDC compliant" serial-to-USB bridge with little effort.  I see no reason why the Mega32 used on this project cannot do the same.  If code space is a problem, the Mega644 and Mega1284p are pin-compatible drop-in's for this project (and yours).

I am looking forward to seeing where the author takes this project ... and where you will go with it.  :)

Thanks for sharing.

Peace and blessings,

Johnny Quest

  Are you sure? yes | no

WestfW wrote 01/16/2017 at 23:36 point

The PCBs arrived today.  Rather quicker than I expected - I'm still waiting for parts...

PCBWay was having a "special" $10 for a 10x10 board (plus ~$20 shipping),  so these ran me about $3 each.  OSHPark is great for tiny boards, but gets expensive rapidly as the board size increases (which is fine, and exactly the way I normally want things, but it doesn't work out well for this board.)

  Are you sure? yes | no

legacy wrote 01/17/2017 at 06:52 point

I have these 8051 boards(1) for sale. Classic design with CPU, ROM, RAM, UART. Maybe someone can be inspired by their design.


  Are you sure? yes | no

Just4Fun wrote 01/17/2017 at 09:26 point

Bill, you are now the "Official" PCB designer of this project.... :-)

  Are you sure? yes | no

WestfW wrote 01/17/2017 at 09:41 point

Ahh.   I see.  In addition to the flip-flop to add wait states, you need to do a little dance coming OUT of the wait state so that the AVR continues to drive the bus long enough for the Z80 to read data (assuming an IO Read), but not so long as to be driving the bus when the z80 does it's NEXT access.  Annoying.  Essentially equivalent to enforcing Thold on an actual device...
Is that actually needed on IO Write as well?  The AVR isn't driving any pins in that case...

  Are you sure? yes | no

Just4Fun wrote 01/17/2017 at 09:54 point

Yep... You cought it!... But there is also an other "side effect" to manage.... So it's needed for WRITE too...

  Are you sure? yes | no

WestfW wrote 01/20/2017 at 04:07 point

OK; I give up.  I can't figure out why you're doing the BUSREQ stuff after the AVR services an IO Write operation...  Can you give me a hint?  :-)

  Are you sure? yes | no

Just4Fun wrote 01/20/2017 at 10:52 point

Ok. The other "side effect" to manage is the RS FF. To keep the BOM low, I drive it in the "unstable" region (that one that good designers want to avoid...), when both /R and /S are LOW, and the FF doesn't work as a FF anymore. As you know in this situation if both /R and /S go HIGH the result is unknown. To avoid this, I've added a HiZ bus state to be sure that /IORQ is pulled HIGH by the pullup resistor, and is "safe" set /WAIT_RES to HIGH again...

  Are you sure? yes | no

WestfW wrote 01/20/2017 at 23:15 point

Ah.  One gets so used to everything being edge-triggered...
Would a capacitor/resistor "differentiator" been sufficient?

  Are you sure? yes | no

Just4Fun wrote 01/21/2017 at 11:42 point

Probably yes, changing the 'HC00 with a 'HC132. But I didn't like putting a RC in a "time sensitive" path. It seemed to me more a "patch" than a "solution". I preferred the other way, more "clean" and "future proof", time independent and "for free" too... (of course in my opinion)

  Are you sure? yes | no

Does this project spark your interest?

Become a member to follow this project and never miss any updates