eZ80 experimental firmware release

[Dean Netherton]

Hi all,

I have been working on my eZ80 system for a few weeks - been exploring how to 'alter' CP/M - and apply my own custom BIOS.  

I have wanted to get the eZ80 system to boot directly into CP/M, using the Linear 2MB RAM Module -- and not use a banked memory system -- with the USB module for storage.

The eZ80 has the Z80 compatibility mode, where you set the MBASE register to the upper byte of an address within the eZ80's 24 bit address range.  With this feature, code can then execute from within a specific 64K segment of memory - in much the same was as the Z80 does.

So instead of a CBIOS implementation needing to bank switching its memory to execute various hardware functions, the CBIOS code can delegate its main requirements by calling to code anywhere within the full 24bit address range.  For my custom bios, I delegates all the BIOS functions to code implemented in the built-in eZ80's ROM (firmware) - accessing the uart, usb disk system and other hardware.

My firmware includes the USB drivers and V9958/Super HDMI support for CP/M.

I followed the same disk layout as Wayne has done in RomWBW - so the disk images/slices are generally compatible (the hd1k_xxx).

I don't think I can port CP/M 3 though - well at least the banking version - the MBASE register only allows the system to address one specific 64K segment.  You cant do the equivalent of swapping the lower pages out.  I'd reckon that it could be 'emulated' by just copy memory (LDIR) from one place to another - but I'd image this process could be a bit slow.

I am detailing the progress on my blog:  https://www.dinoboards.com.au/2026/04/12/ez80-booting-cpm-part-2.html

If you have the required hardware - you may want to join me in the fun!

Dean

[Bill McMullen]

Been there & done a full eZ80 CP/M BIOS, including I2C & SPI on a couple of different systems.  A couple of comments:

- Executing all BIOS code from the internal flash "ROM" causes a speed degradation versus using zero wait state RAM.  This is much more of a concern if you go to a 50MHz eZ80 where 3 or 4 wait states are required.  The F92 power-on default is 4 wait states i.e. 20% or about 4MHz equivalent although 1 wait state can be set and is okay for a 50% or about 10 MHz equivalent ... the same degradation you're showing for the linear RAM.

- Banking for CP/M-3 or MP/M can be accomplished by enabling the F92's 8KB of internal SRAM.  MBASE & RAM_ADDR_U can then be used to set various 56KB banks from 0-DFFFh and an 8KB common area at E000h.  Note that this will also depend upon your interrupt configuration (i.e. MADL) and vectors location.

- Booting from an external USB storage device means that every such device must be configured with the CP/M system.  That can lead to downlevel devices, especially during development, and extra work every time you want to use a new device.  Given that the F92 has internal flash, it's much simpler to embed the CP/M system into internal flash without any reliance on external devices for booting, except perhaps your precedent of RomWBW.  Boots from internal flash are extremely fast.

[Dean Netherton]

> Been there & done a full eZ80 CP/M BIOS, including I2C & SPI on a couple of different systems.

Yep, like a bush-walker following well tread tracks - its still fun and challenging.  I guess that's the point of retro computing - doing stuff that been done before - but each with our own unique take.

>  Executing all BIOS code from the internal flash "ROM" causes a speed degradation versus using zero wait state RAM.  This is much more of a concern if you go to a 50MHz eZ80 where 3 or 4 wait states are required.  The F92 power-on default is 4 wait states i.e. 20% or about 4MHz equivalent although 1 wait state can be set and is okay for a 50% or about 10 MHz equivalent ... the same degradation you're showing for the linear RAM.

My eZ80 for the RCBus module is rated at 20Mhz (I've overclocked it up to 32Mhz - but found the sweet spot is at 25Mhz) - it boots up with some conservative timings - to aid in compatibility.   1 W/S for the internal Flash ROM and external RAM (@ 25Mhz).  At this speed, it configures the 512K ROM/RAM banked module access to 3 Z80 bus cycles.  So running CP/M in ROM and the linear RAM module is faster than the banked module - although the speed difference is not noticeable to me.   I can run with 0 W/S for internal flash, and bring down the IO wait state from 4 to 3 Bus cycles - this can speed up the CRT and USB interfaces a smidgen.  But for my external linear 2Mb module, rated @ 60ns, I still need one 1 W/S.  So for me , the ROM is potentially faster than the external RAM.  Some time time critical code is executed from the the internal 0 W/S RAM - things like interrupts, uart processing and its buffers, etc.  The long stack also uses the fast internal RAM.

> Banking for CP/M-3 or MP/M can be accomplished by enabling the F92's 8KB of internal SRAM.  MBASE & RAM_ADDR_U can then be used to set various 56KB banks from 0-DFFFh and an 8KB common area at E000h.  Note that this will also depend upon your interrupt configuration (i.e. MADL) and vectors location.

Hmm - that make sense... Something to ponder....

> Booting from an external USB storage device means that every such device must be configured with the CP/M system.  That can lead to downlevel devices, especially during development, and extra work every time you want to use a new device.  Given that the F92 has internal flash, it's much simpler to embed the CP/M system into internal flash without any reliance on external devices for booting, except perhaps your precedent of RomWBW.  Boots from internal flash are extremely fast.

When i first started coding this, I had initially tried to 'replicate' the RomWBW approach with a full system on ROM.  But I only have a maximum of 128K internal ROM - and near half of that is consumed with code, including the VDU and USB drivers.  I did create a small ROM disk to contain some key programs.  But then I changed track and went with the more traditional approach.  (During dev I cheated, and have the CBIOS embedded in the internal ROM to aid iteration).  The system can still boot using RomWBW for a full disk-less system or other RomWBW hardware setups.

With the USB driver, I can have multiple connected disks - one flash drive for boot - and the others can be data.  I want to bring over the USB-UFI floppy disk interface so I can actually boot CP/M from an actual floppy disk - almost like they did in the old days.  I say almost, as USB only supports 3.5" floppies.  I do have a RC2014 Floppy module and a 5 1/4" drive -- i think that will be fun to also incorporate drivers for.  All these drivers of course, will need to fit in the internal ROM.

Nonetheless, I think i will still have it fall back to a basic CP/M boot, just without a ROM disk.  This should give the system a good broad level of boot options.

Dean.

[Wayne Warthen]

Looks really nice Dean!

-Wayne

[Bill McMullen]

> Yep, like a bush-walker following well tread tracks - its still fun and challenging.  I guess that's the point of retro computing - doing stuff that been done before - but each with our own unique take.

I fully agree that retro computing for me is also about applying my own unique take on various HW & SW.  When I returned to my Zilog trek that started in the 70's, my primary objective was throughput & optimization while strictly adhering to manufacturer's specifications.  I experimented with CPLDs (including things like fly-by DMA), 16-bit memory on a Z180 (SRAM, flash & MRAM), multi-processor slave boards, USB, ATA, Propellers, W5100, PC SuperI/O chips, etc.

My initial eZ80 design was to see if all the negative comments and the lack of designs for that family had any significant foundation.  That design (Min-eZ) proved to me that it was an extremely fast system with absolutely no issues running CP/M or any of the packages I tried.  My personal opinion is that the Z80 purists who vocally knocked this processor family did a HUGE disservice to the retro community.

> But I only have a maximum of 128K internal ROM - and near half of that is consumed with code, including the VDU and USB drivers.  I did create a small ROM disk to contain some key programs.  But then I changed track and went with the more traditional approach.

I chose to only use Assembler code and on the F91 I use HW write protection for the lowest 32K of the 256K internal flash.  That 32K protected area is used for CP/M, including the BIOS, and currently only uses about 21K of it which leaves space for a 224K R/W "disk".  On the F92/F93 I currently reserve 24K for CP/M with about 5K unused, which then leaves space for a 104K or 40K "disk".

> I want to bring over the USB-UFI floppy disk interface so I can actually boot CP/M from an actual floppy disk - almost like they did in the old days.

In the 70's I interfaced a genuine IBM 33FD drive to my S100 system ... it worked well but was EXTREMELY slow and had a very load & distinctive clack-clack as it stepped.  Since then I've used various 8", 5.25" & 3.5" floppies.  I've now chosen to get rid of ALL my floppy drives and mostly use SD and/or serial flash as they're MUCH faster, quiet, lower cost, much smaller and don't require maintenance.  Simply a personal choice and from personal experience I fully understand the educational value and satisfaction in writing code for the various floppy controllers plus all the various formats.

> Nonetheless, I think i will still have it fall back to a basic CP/M boot, just without a ROM disk.  This should give the system a good broad level of boot options.

I typically think in terms of a basic embedded OS that that can be used standalone, as a loader for other OS's, for SW upgrades and/or to repair user mistakes.  In that vein, I also chose that my eZ80 systems do not require a Smart Cable except one initial time, although it could be used for debugging purposes.  Likewise for simplicity, my systems only use one SW IDE (i.e. ZDS) and one language (i.e. Assembler).

The beauty of retro computing as a hobby is that there is no real right or wrong.  There's simply a lot of educational opportunities for exploration ... of course one may end up going bald if there's a nasty bug.  I'm really glad to see that others are also doing designs & development with the eZ80, especially since it's now the only Zilog Z80 style processor that's still in production.  Enjoy your journey!!!