README.txt
==========

  Z20X is a simple expandable DIY computing system, built around the eZ80
  microprocessor. The eZ80 was chosen due to its native simplicity and full
  backward code compatibility with the great and very popular Z80 and Z180.
  The design goal of Z20X is to offer a good DIY/LIY (Do-It-Yourself/Learn-
  It-Yourself) kit for system built with through-hole components, simple
  enough for assembly and learning in deep details, but without the
  constraints of using only old technology ICs. In order to maintain full
  exposure to technical details, the system also avoids using secondary
  MCUs or programmable logic, and sticks only with true hardware solutions.


 System Summary

    eZ80 running at 20 MHz (default on board)
    128 KB flash ROM (internal for eZ80)
    520 KB total RAM on board (512K external plus 8K internal)
    4 MB non-volatile storage (optional, can be upgraded by changing the IC)
    Real-time clock
    SSD1963-powered 7.0 inch TFT display with resolution 800 x 480 pixels
      and touch panel
    SD card slot
    YM2413 programmable sound generator with amplifier
    PS/2 connectors for industry standard keyboard and mouse
    Additionally installable processor modules
    72-pin expansion header with Z20X bus
    Optional expander board with Z20X bus sockets and bonus support for
      RC2014 bus

Contents
========

  o ZDS-II Compiler Versions
  o Environments
  o Memory Constaints
  o Serial Console
  o LEDs and Buttons
    - LEDs
    - Buttons
  o Configurations
    - Common Configuration Notes
    - Configuration Subdirectories

ZDS-II Compiler Versions
========================

Version 5.3.3

  As of this writing, this is the latest version available.  This is the
  default configured for all ez80 boards.

  Compilation using version 5.3.3 was verified on February 20, 2020.

Version 5.3.0

  Compilation using version 5.3.0 was verified on February 19, 2020.

Other Versions
  If you use any version of ZDS-II other than 5.3.0/3 or if you install ZDS-II
  at any location other than the default location, you will have to modify
  three files:  (1) arch/arm/z80/src/ez80/Kconfig, (2)
  boards/z80/ez80/z20x/scripts/Make.defs and, perhaps, (3)
  arch/z80/src/ez80/Toolchain.defs.

Environments
============

Cygwin:

  All testing was done using the Cygwin environment under Windows.

MinGW/MSYS

  One attempt was made using the MSYS2 environment under Windws.  That build
  correctly until the very end, then it failed to include "chip.h".  this
  was traced to arch/z80/src/Makefile.zdsiil:  The usrinc paths created by
  Makefile.zdsiil contained POSIX-style paths that were not usable to the
  ZDS-II compiler.

Native

  The Windows native build has not been attempt.  I would expect that it
  would have numerous problems.

Memory Constaints
=================

  The eZ80F92 has a smaller FLASH memory of 128Kb.  That combined with the
  fact that the size of NuttX is increasing means that it is very easy to
  exceed the ROM address space.

  The sdboot configuration will fit into the ROM address space, but NOT if
  you enable assertions, debug outputs, or even debug symbols.

Serial Console
==============

  The eZ80 has two UART peripherals:

  UART 0:  All of Port D pins can support UART0 functions when configured
  for the alternate function 7.  For typical configurations only RXD and TXD
  need be configured.

    eZ80 PIN
    ===============
    PD0/TXD0/IR_IXD
    PD1/RXD0/IR_RXD
    PD2/RTS0
    PD3/CTS0
    PD4/DTR0
    PD5/DSR0
    PD6/DCD0
    PD7/RIO0

  PD0 and PD1 connect to the PS/2 keyboard connector.

  UART 1:  All of Port C pins can support UART1 functions when configured
  for the alternate function 7.  For typical configurations only RXD and TXD
  need be configured.

    eZ80 PIN
    ========
    PC0/TXD1
    PC1/RXD1
    PC2/RTS1
    PC3/CTS1
    PC4/DTR1
    PC5/DSR1
    PC6/DCD1
    PC7/RIO1

  PC0 and PC1 connect both to the MCP2221 UART-to-USB converter and also to
  the PS/2 mouse connector.

  UART1 is the default serial console in all configurations unless
  otherwise noted in the description of the configuration.

LEDs and Buttons
================

  There are no on-board user LEDs or buttons.

Configurations
==============

Common Configuration Notes
--------------------------

  1. src/ and include/

     These directories contain common logic for all z20x
     configurations.

  2. Variations on the basic z20x configuration are maintained
     in subdirectories.  To configure any specific configuration, do the
     following steps:

       tools/configure.sh [OPTIONS] z20x:<sub-directory>
       make

     Where <sub-directory> is the specific board configuration that you
     wish to build.  Use 'tools/configure.sh -h' to see the possible
     options.  Typical options are:

       -l Configure for a Linux host
       -c Configure for a Windows Cygwin host
       -g Configure for a Windows MYS2 host

     Use configure.bat instead of configure.sh if you are building in a
     native Windows environment.

     The available board-specific configurations are  summarized in the
     following paragraphs.

     When the build completes successfully, you will find this files in
     the top level nuttx directory:

     a. nuttx.hex - A loadable file in Intel HEX format
     b. nuttx.lod - A loadable file in ZDS-II binary format
     c. nuttx.map - A linker map file

  3. ZDS-II make be used to write the nuttx.lod file to FLASH.  General
     instructions:

     a. Start ZDS-II
     b. Open the project, for example, nsh/nsh.zdsproj
     c. Select Debug->Connect To Target
     d. Select Debug->Download code

     There are projects for the ZiLOG Smart Flash Programmer as well but
     these are not functional as of this writing.

  4. This configuration uses the mconf-based configuration tool.  To
     change this configurations using that tool, you should:

     a. Build and install the kconfig-mconf tool.  See nuttx/README.txt
        see additional README.txt files in the NuttX tools repository.

     b. Execute 'make menuconfig' in nuttx/ in order to start the
        reconfiguration process.

Configuration Subdirectories
----------------------------

  hello:

    This is a minimal "Hello, World!" program that runs out of RAM.  It is
    a small program that is really useful only for testing the bootloader.

    NOTES:

    1. Debugging from RAM

       You can debug from RAM version using ZDS-II as follows:

       a. Connect to the debugger,
       b. Reset, Go, and Break.  This will initialize the external RAM
       c. Break and Load the nuttx.lod file
       c. Set the PC to 0x050000
       d. Single step a few times to make sure things look good, then
       e. Go

  nsh:

    This configuration builds the NuttShell (NSH).  That code can be
    found in apps/system/nsh and apps/system/nshlib..  For more
    information see:  apps/system/nsh/README.txt and
    Documentation/NuttShell.html.

    To be usable, this configuration should:  (1) Use the same BAUD
    as the bootloader and (2) switch from the MMC/SD card to the second
    partition in the W25 part.

    NOTES:

    1. This configuration builds for execution entirely from RAM.  A
       bootloader of some kind is required to support such execution from
       RAM!  This is reflected in a single configuration setting:

         CONFIG_BOOT_RUNFROMEXTSRAM=y  # Execute from external SRAM

       Why execute from SRAM?  Because you will get MUCH better performance
       because of the zero wait state SRAM implementation and you will not
       be constrained by the eZ80F92's small FLASH size.

    2. The eZ80 RTC, the procFS file system, and SD card support in included.
       The procFS file system will be auto-mounted at /proc when the board
       boots.

       The RTC can be read and set from the NSH date command.

         nsh> date
         Thu, Dec 19 20:53:29 2086
         nsh> help date
         date usage:  date [-s "MMM DD HH:MM:SS YYYY"]
         nsh> date -s "Jun 16 15:09:00 2019"
         nsh> date
         Sun, Jun 16 15:09:01 2019

       When the system boots, it will probe the SD card and create a
       block driver called mmcsd0:

         nsh> ls /dev
         /dev:
          console
          mmcsd0
          null
          ttyS0
         nsh> mount
           /proc type procfs

       The SD card can be mounted with the following NSH mount command:

         nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard
         nsh> ls /mnt
         /mnt:
          sdcard/
         nsh> mount
           /mnt/sdcard type vfat
           /proc type procfs
         nsh> ls -lR /mnt/sdcard
         /mnt/sdcard:
          drw-rw-rw-       0 System Volume Information/
         /mnt/sdcard/System Volume Information:
          -rw-rw-rw-      76 IndexerVolumeGuid
          -rw-rw-rw-      12 WPSettings.dat

       You can they use the SD card as any other file system.

         nsh> ls /mnt/sdcard
         /mnt/sdcard:
          System Volume Information/
         nsh> echo "This is a test" >/mnt/sdcard/atest.txt
         nsh> ls /mnt/sdcard
         /mnt/sdcard:
          System Volume Information/
          atest.txt
         nsh> cat /mnt/sdcard/atest.txt
         This is a test

       Don't forget to un-mount the volume before power cycling:

         nsh> mount
           /mnt/sdcard type vfat
           /proc type procfs
         nsh> umount /mnt/sdcard
         nsh> mount
           /proc type procfs

       NOTE:  The is no card detect signal so the microSD card must be
       placed in the card slot before the system is started.

    3. Debugging from RAM

       You can debug from RAM version using ZDS-II as follows:

       a. Connect to the debugger,
       b. Reset, Go, and Break.  This will initialize the external RAM
       c. Break and Load the nuttx.lod file
       c. Set the PC to 0x050000
       d. Single step a few times to make sure things look good, then
       e. Go

    4. Optimizations:

       - The stack sizes have not been tuned and, hence, are probably too
         large.

  w25boot

    This configuration implements a very simple boot loader.  In runs from
    FLASH and simply initializes the external SRAM, mounts the W25 FLASH
    and checks to see if there is a valid binary image at the beginning of
    FLASH.  If so, it will load the binary into RAM, verify it and jump to
    0x50000.  This, of course, assumes that the application's entry point
    vector resides at address 0x050000 in external SRAM.

    The boot loader source is located at boards/z20x/src/w25_main.c.

    When starting, you may see one of two things, depending upon whether or
    not there is a valid, bootable image in the W25 FLASH partition:

    1. If there is a bootable image in FLASH, you should see something like:

        Verifying 203125 bytes in the W25 Serial FLASH
        Successfully verified 203125 bytes in the W25 Serial FLASH
        [L]oad [B]oot
        .........

       The program will wait up to 5 seconds for you to provide a response:
       B to load the program program from the W25 and start it, or L to
       download a new program from serial and write it to FLASH.

       If nothing is pressed in within the 5 second delay, the program will
       continue to boot the program just as though B were pressed.

       If L is pressed, then you should see the same dialog as for the case
       where there is no valid binary image in FLASH.

    2. If there is no valid program in FLASH (or if L is pressed), you will
       be asked to :

         Send HEX file now.

    NOTES:

    1. A large UART1 Rx buffer (4Kb), a slow UART1 BAUD (2400), and a very
       low Rx FIFO trigger are used to avoid serial data overruns.  Running
       at only 20MHz, the eZ80F92 is unable to process 115200 BAUD Intel Hex
       at speed.  It is likely that a usable BAUD higher than 2400 could be
       found through experimentation; it could also be possible to implement
       some software handshake to protect the eZ80f92 from overrun (the
       eZ80F92 does not support hardware flow control)

       At 2400 BAUD the download takes a considerable amount of time but
       seems to be reliable

       Massive data loss occurs due to overruns at 115200 BAUD.  I have
       tried the bootloader at 9600 with maybe 30-40% data loss, too much
       data loss to be usable.  At 9600 baud, the Rx data overrun appears
       to be in the Rx FIFO; the data loss symptom is small sequences of
       around 8-10 bytes often missing in the data.  Apparently, the Rx FIFO
       overflows before the poor little  eZ80F92 can service the Rx
       interrupt and clear the FIFO.

       The Rx FIFO trigger is set at 1 so that the ez80F92 will respond as
       quickly to receipt of Rx data is possible and clear out the Rx FIFO.
       The Rx FIFO trigger level is a trade-off be fast responsiveness and
       reduced chance of Rx FIFO overrun (low) versus reduced Rx interrupt
       overhead (high).

       Things worth trying:  4800 BAUD, smaller Rx buffer, large Rx FIFO
       trigger level.

    2. Booting large programs from the serial FLASH is unbearably slow;
       you will think that the system is simply not booting at all.  There
       is probably some bug contributing to this probably (maybe the timer
       interrupt rate?)