Project Logs

Collapse

• Kit available on Tindie

  Dean Netherton • 10/06/2024 at 10:04 • 0 comments

  The eZ80 for RC kit is now available from my Tindie store.

  A super easy kit to build with everything needed to explore the most advanced Z80 based CPU available.

  Click here to purchase your own eZ80 for RC kit.

  I have also started to build up a new website detailing all my kits: www.dinoboards.com.au

  It includes a page for the new eZ80 for RC kit: www.dinoboards.com.au/ez80-for-rc

  The plan is to consolidate all supporting materials for all kits and projects on this new site.

• Pi Pico Programmer

  Dean Netherton • 09/29/2024 at 08:38 • 0 comments

  This weekend, I made significant progress in making a PI Pico module connect to the eZ80. Enabling the ability to erase and write to the on-chip flash ROM. This will be an alternative and cheaper way to program the eZ80 compared to Zilog’s Smart Programmer.
  

  The Pi Pico Programmer connects to the eZ80’s ZDI interface, a 2 pin (similar to i2c) serial interface. The Programmer can transmit commands to halt, inspect, debug, erase and write to the on-chip 128K Flash ROM.

  Getting it operational was quite challenging. My first challenge, that took way longer than I had expected, was to install the compiler/build tool chain for the Pico. Once that was done, I had the ability to write C code for the Pico that can drive some GPIO pins. So it was just a matter of discovering the ZDI signalling protocol to command the eZ80 to erase and write to its flash (and do a few other operational things)

  This proprietary interface is a bit like I2C, but not quite… Its documented by Zilog in the eZ80 manual. I did find though, that the documentation is sometimes a little brief or confusing.

  The development process mostly entailed me flashing some code on the Pi Pico - verifying that the GPIOs are toggling as expected - then connecting it for real to my eZ80 and see if that’s actually what Zilog wants! A lot of head scratching and trying over and over.

  The Pi Pico Programmer is now able to to program/flash the eZ80 - it still needs some polish - but is sufficient for now.

  I intend to detail the solution, with appropriate pictures in the main repo. I have also designed a small PCB to mount the Pi Pico and a 6 pin header. Should make for a very neat solution.

  I am not the first to use a cheap modern Microcontroller to program an eZ80. There are some projects for the Agon using its onboard ESP32
  

• RomWBW Integration

  Dean Netherton • 09/22/2024 at 09:24 • 0 comments

  I am very excited to announce that Wayne Warthen has accepted my pull requests for the eZ80 module into his mega RomWBW project. The eZ80 support is now part of the mainline code base. Still very much under development and early alpha - but official!

  I am very thankful to Wayne for his assistance in the development of the eZ80 for RC2014/RCBus.

  Wayne has also received a kit and will soon be able to personally validate the eZ80 operation.
  

  And in other news, I started experimenting with a Pi Pico this weekend to see if I could make a programmer for the eZ80 (as a possible replacement for the very expensive Zilog programmer). I thought to myself, surely this cant be too hard to do. When will I learn not to call myself Shirley!

• Benchmarking

  Dean Netherton • 09/15/2024 at 10:36 • 0 comments

  My primary goal with the eZ80 module is to achieve maximum compatibility with RC2014/RCBus modules and configurations. The eZ80 is a significantly faster processor. However, to ensure communication with older, slower retro modules, appropriate wait states must be introduced, which means some performance will be sacrificed. Despite this, the system remains much faster than a standard Z80 running at 7MHz.

  I ported some benchmarking software from the z88dk library, which includes the classic Dhrystone and Whetstone benchmarks to give me some insights on the degree of performance this system operates at, compared to a stock RC2014 build.

  I ran these benchmarks on various configurations and at different CPU frequencies, and the results were quite interesting.

  When the eZ80 boots up, it detects the current CPU frequency and adjusts the timing for accessing the external ROM/RAM module and its own on-chip flash ROM. I chose conservative settings and calculations. As a faster oscillator is installed, the boot-up firmware will increase the extra wait states required when accessing memory and I/O devices.

  The purpose of this benchmarking was not to showcase raw speed. Other eZ80 systems can achieve higher speeds by using fast RAM chips, typically SMD RAM chips soldered next to the CPU. The fast RAM chips allow the eZ80 to run at its full potential. But I tend to think, if I wanted a faster solution, I could probably achieve orders of magnitude increases by running everything in JavaScript within my main PC’s browser.

  The Results

  Stock RC2014 System @ 7.372Mhz

  First, I ran the two benchmarking utilities using a stock RC2014 system with a standard Z80 CPU running at 7.372MHz, an SIO/2 module for serial communication, and a V9958 VDP module to generate a 50Hz timer tick for time reference.

  • Dhrystone score: 556.2
  • Whetston score: 8

  Stock RC2014 System @ 20Mhz*

  I then conducted the same tests, using my Turbo CPU module - the fastest standard Z80 I have. This is a CPU module for the RC2014/RCBus systems, that can run a standard Z80 at 20Mhz. (If you are not familiar with this module, check it out over in my Tindie Store https://www.tindie.com/stores/dinotron/)

  • Dhrystone score: 1144.2
  • Whetston score: 16.5

  * The Turbo CPU does not run its Z80 at a constant 20Mhz - it will, if any I/O operations are performed, briefly slowdown to a more typical speed (7.372Mhz). The interrupt timer tick from the V9958 will cause the CPU to do some I/O operations, thus down clocking the CPU for short bursts.

  eZ80 System @ various clock frequencies

  Below is the result of running the benchmark applications for the eZ80 at different CPU Frequencies. Note how the wait states increase as the clock goes up.

  Cpu Frequency	Memory W/S	I/O W/S	Flash W/S	Dhrystone Score	Whetstone Score
  7.37	1	6	0	1149.7	14.4
  14.75	1	6	1	2301.1	28.9
  16.00	2	6	1	1680.4	21.1
  18.43	2	6	1	1938.9	24.3
  20.00	2	6	1	2103.1	26.4
  24.00	2	5	1	2520.3	31.7
  * 25.00	2	5	1	2625.6	33.0 *
  32.00	3	7	2	2536.1	31.8
  35.00	4	7	2	2226.0	28.0
  40.00	4	9	2	2544.0	32.0

  Paradoxically, it does seem that sometimes, a faster CPU frequency, actually results in slower performance. For example, the 14.74MHz CPU outperforms the 18.43MHz CPU because the latter is heavily impacted by the need for an extra wait state.

  I know that some configuration are perhaps overly conservative (eg: 32Mhz will run at 2 W/S just fine) - and with some more time to experiment, more ‘performance’ can be achieved.

  Despite this, the current solution is still significantly faster than the stock RC2014. Additionally, the solution remains highly compatible, even when overclocking the eZ80.

  And yes, I have successfully overclocked my eZ80 to 40MHz, even though Zilog rates it for a maximum speed of 20MHz. I am eager to test even higher frequencies, but I lack the necessary oscillators to generate higher clock rates.

  Next, I need to start generating some Mandelbrot sets!

• Hot Flashing

  Dean Netherton • 09/15/2024 at 09:36 • 0 comments

  Been working on understanding and writing code to re-flash the on-chip ROM from a CP/M application.

  I have written an application that allows for the ‘updating’ of the on-chip ROM without the need for the Zilog Programmer.

  Designed a system, where I can install dual firmwares. A default/fallback bootable firmware and an ‘alternative’ firmware.

  The first firmware is flashed, using the Zilog programmer, within the first 64K page of the 128K on-chip ROM.

  The CP/M application FWUPDATE.COM can then be executed within CP/M, to flash an ‘alternative’ firmware in the 2nd 64K page.

  On reboot, the system sees this new ‘alternative’ image and boots using that version. Should this new ‘alt’ firmware fail to launch HBIOS/CPM successfully, the main boot loader will switch back to the main ‘firmware’.

  A future goal will be to develop, using something like a PI Pico, to create my own external programmer. A Pi Pico, or other similar cheap microcontroller, will be a lot cheaper than the Zilog Programmer

• Factory assembled CPU Modules

  Dean Netherton • 09/06/2024 at 23:17 • 0 comments

  Last week, I submitted to the PCB manufacturer, an order for assembled CPU modules. This is the first time I have submitted an order to the factory to place and solder components onto one of my PCB designs. It was quick, easy and generally quite simple.

  And now they have arrived.

  Will they work?

  Only one way to find out. Of course, I live on the edge, and ordered a version of the module (and associated interface PCB) with some last minute untested changes.

  One change was the size of the various SMD capacitors and resistors. For the hand assembled units, I had selected as large a footprint I could - to reduce the challenge when hand soldering. But for the factory assembled units, it was cheaper and easy to use smaller components. Smaller sizes, I gather, are not only cheaper, the de-coupling capacitors would likely have a lower inductance -- meaning they will work just that bit better at absorbing all those high frequency digital spikes.

  The other change was a slight 'correction' to the positioning of the interface pins. The inner rows are now 2.54mm (100mil) from the outer rows. (The original versions had a rows separation of 3mm)

  The factory assembled units only assembled the surface mount components. I still needed to solder the programming header and the 93 PCB pins.

  Me vs Factory

  Here's a comparison of my hand-assembled module (left), and the factory assembled unit (right). Notice the much smaller components:

  Close up of the factory assembled unit, after I have soldered in the header and PCB pins:

  The back of the module is basically the same:

  I am please to say, I have since installed the new CPU Module and Interface board into my RC2014 and it all works just like the hand assembled units.

• RC2014/RCBus Mapping

  Dean Netherton • 09/06/2024 at 04:25 • 0 comments

  As the eZ80 CPU has some differences and additional control signals, I need to consider how some of these signals have to be mapped, and how their slight difference may impact compatibility. I have already had to 'resolve' issues with the timing of the WR signal to ensure operation of the Bank Memory module and the Compact Flash module.

  Many people have installed various alternative CPUs into their RC2014/RCBus based systems, from the various Zilog processors (Z180, Z280) and Intel 8080 to CPUs with very different timings and signals, such at the 6502. The eZ80 is now, just another CPU for the platform.

  On the electrical front, the eZ80 operates at 3.3V, but is 5V tolerant.  The interface module I have built, uses a number of 74HC245 buffer chips to step-up all outgoing signals to 5V.  The frequency of these signals are going to be higher and have a much quicker rise and fall times compared to a stock Z80 system.  In all my testing to date, I have the eZ80 configured to operate in Z80 Bus Mode.  So in theory, an eZ80 operating at 20Mhz will drive the Address and Data Buses at a similar rate as a Z80 operating at 20Mhz - although its not quite that simple.  (Of course the eZ80 will still run at full speed when operating from its on-chip RAM/ROM, and combined with the chips ability to execute more instructions per clock cycle -- we will still have a very fast processor compared to a standard Z80)

  Nonetheless, any CPU operating at 20Mhz will typically exceed the operating timings requirements for many RC2014/RCBus modules.

  The eZ80 can be configured, as mentioned, to operate its Address, Data and Control Bus in various 'Modes' of operation.  It can be configured to its default eZ80 Mode, or a 'compatible' Z80 Mode, or if you wish, an Intel or even the very different Motorola Mode.

  In the default eZ80 Bus Mode the CPU's reads and writes can be conducted within a single clock cycle.  Compared this to the Z80 mode, where the reads/writes are conducted over at least 3 clock cycles.  Of course, the targeted memory, or I/O device, can send a WAIT signal back to the CPU, extending the time taken for any transfer.  But this requires the memory to be able to trigger that WAIT signal before the CPU has moved onto the next cycle.  A lot of retro modules use older chips that could not possibly operate at these data rates.  Even the modern memory chips (AS6C4008 SRAM) typically used in the RC2014/RCBus systems will struggle at this rate.

  Thankfully, the eZ80 can also be configured to include its own additional WAIT states.  So with the appropriate configuration, we can drive our Memory and I/O devices at a rate that is kept within the required timing specifications.

  The modes are configured through the use of the eZ80's Chip Select signals (CS0, CS1, CS2, CS3).  Each of these CSx lines can be configured to only be activated for specific address ranges. For example, I have configured CS3 to use *Z80 Compatible Bus Mode* and only activate when a memory read or write happens in the address range of 0x030000 to 0x03FFFF.  And configured CS2 to also use *Z80 Compatible Bus Mode* and activate when an I/O request happens in the address range of 0xFF00 to 0xFFFF.

  The eZ80 to RC2014/RCBus mapping

  Below is a brief description of some of the key signals on the RC2014/RCBus backplanes and the eZ80 equivalent and any differences.

  A0-A15 and D0-D7

  These signals are as expected; the address from the CPU and the bi-directional data bus.

  19 M1

  The eZ80 does not have an M1 signal - it has INSTRD (instruction read) signal.  For simplicities sake, I have not mapped this line -- I just pulled it high with a 10K resistor.

  21 - Bus Clock

  My eZ80 CPU module has an onboard oscillator.  I have tested oscillator's with frequencies from as low as 7.3728MHz up to the CPU's rated 20MHZ and overclocked to 32Mhz.  But I don't send this clock...

  Read more »

• eZ80 i2c Interface

  Dean Netherton • 08/18/2024 at 06:02 • 0 comments

  Been learning about i2c over the last few days.  Today I managed to get the eZ80's i2c interface to drive a little Adafruit 8x8 LED matrix i2c module.

• Video Evidence

  Dean Netherton • 08/17/2024 at 02:40 • 0 comments

  Thought I should share a quick little demo video, showcasing some of the progress with porting RomWBW to the eZ80 CPU.

  The RC2014 system is configured with:

  1. The Official RC2014 Backplane Pro
  2. The Official RC2014 512k ROM 512k RAM Module
  3. The Official RC2014 Digital I/O
  4. My Yellow MSX V99x8 Video Module
  5. My Yellow MSX Keyboard Module
  6. J. B. Langston's SN76489 Sound Card for RC2014
  7. WD37C65 Based Floppy Adapter*

  * Can not remember where I got this module from, but its based on Dr. Scott M. Baker's design.

  The Video shows me using RomWBW, via the MSX Keyboard and Video modules, to load some CP/M applications from a floppy disk.

  
  

• Power on reset

  Dean Netherton • 08/11/2024 at 02:22 • 0 comments

  One issue I hit when I was attempting to port the V9958 driver code (TMS9918 compatible driver), was an apparent intermittent fault. After a few frustrating hours, I figured out that the V9958 was not being 'reset' on power up - and could not be initialised correctly by the CPU.

  I think the V9958 is very fussy on requiring that its held in RESET during power-up. If not, it will be in a state that does not seem to be correctable in software.

  I realised that I forgotten to include a Power-On-Reset circuit in my design.

  A quick work around is to press the RESET button on the backplane after initial powering on the kit.

  The original RC2014 Dual clock module does include a Power-On-Reset circuit, but this module is not required for the eZ80 Interface module as it has its own high speed clock on board.

  I have drafted a new PCB design that includes a Power-on-Reset facility; this should ensure the whole system is held in RESET state for a few milliseconds when its initially powered on, and allow the V9958 to initialise itself correctly.

View all 28 project logs