401 lines
13 KiB
Plaintext
401 lines
13 KiB
Plaintext
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?)
|