EaZy80-RomWBW - EOL ?

[PauldB]

A couple of weeks ago, when I received the batch of 10 W27C256-45Z 64K EPROMs I had ordered from aliexpress, I decided to use my EaZy80-RomWBW SBC (which uses a W27C512 EPROM and runs reliably at 29.5MHz) to test access speed of the EPROMs (more on that later).

While preparing to use the SBC, I saw I had RomWBW-v3.5.1-rc.4 flashed on the ROM. So I decided it was a good time to update it. I had downloaded 'RomWBW-v3.6.0-dev.24-Package.zip' earlier, so I just needed to copy 'RCZ80_ez512_std.upd' from the binary folder.

After compressing the 128K file to fit into a 64K ROM, I checked the resulting binary with a hex editor to see how much free space was left. Oh dear, the compressed code had written past $FF00, the start location of the appended Z80 code decompressor!

RomWBW had grown so much that the simple RLE compression algorithm couldn't compress it enough to fit. So with which version did this happen?

Using "ye olde binary technique"(tm), I tried a RomWBW version halfway between what I was running and the latest version. That didn't fit either. Iterating, I came to 'RomWBW-v3.6.0-dev.6', the last version to fit. I flashed it to ROM and it booted up RomWBW just as expected.

My first thought was that as newer RomWBW versions would no longer fit, it could be EOL of EaZy80-RomWBW :(

Then it occured to me that I could free space by removing a ROM-resident program (or two) that I seldom used. But *how* to do do that?

The closest I came to an answer was this sentence in 'The RomWBW User Guide', Section 12.3 "ROM Customization": "Modification of the source code is considered an expert level task and is left to the reader to pursue." Well, I'm certainly no expert! But I peeked into the source code anyway ;-) I did find this file that appears to be a key in RomWBW: 'Source/HBIOS/layout.inc'

After studying this file for some time and trying some modifications without getting anywhere, I got yet another idea! Open the *.upd file in a hex editor and simply replace the program code to be exorcised with $00 or $FF. Locations $3700 to $49FF, where 'Tasty BASIC' and 'Play a Game' had lived, were now $FF. Compressing the file once again left me with nearly 1600 bytes free :-)

But in the 'HELP' menu, two items I tried didn't work right. 'Device Inventory' returned nothing, and what was worse, 'Slice Inventory' caused the computer to hang!

Time to ask the forum for help :-)

Oh, yes, I was going to report the results of testing the W27C512-45Z EPROMs from aliexpress with my EaZy80-512 SBC. Well, all flashed ok and then 7 out of 10 could boot reliably into RomWBW @29.5MHz with 3 failing to do anything at all. So, of the 10 W27C512 EPROMs that had been re-marked as 45ns, 3 were probably 70ns (or slower).

I'll attach jpegs of the W27C512 chips I received. They actually came in tubes! Note that the IC legs haven't been covered, like usual, with solder. Oh, and isn't it interesting that all ICs have the same markings on top, yet the marking on the bottom show they weren't even manufactured in the same country. Shock! ;-)

Paul

[T Gerbic]

We might need to re-task those Z80 speed testers to test memory speed now. 

[Wayne Warthen]

Hi Paul,

On Monday, September 29, 2025 at 4:02:40 PM UTC-7 PauldB wrote:

After compressing the 128K file to fit into a 64K ROM, I checked the resulting binary with a hex editor to see how much free space was left. Oh dear, the compressed code had written past $FF00, the start location of the appended Z80 code decompressor!

Yes, there have been substantial additions to the first 4 ROM banks.  Previously, the last of the 4 was empty.  Not any more.

After studying this file for some time and trying some modifications without getting anywhere, I got yet another idea! Open the *.upd file in a hex editor and simply replace the program code to be exorcised with $00 or $FF. Locations $3700 to $49FF, where 'Tasty BASIC' and 'Play a Game' had lived, were now $FF. Compressing the file once again left me with nearly 1600 bytes free :-)

But in the 'HELP' menu, two items I tried didn't work right. 'Device Inventory' returned nothing, and what was worse, 'Slice Inventory' caused the computer to hang!

A couple observations.  First, your location offsets appear to be relative to the third bank which is the bank that Tasty BASIC and Play a Game live.  The offset from the start of the file would actually be 0x13700 I think.  Second, the "broken" menu items occupy space after the space you cleared.  I would double check that you did not clear beyond the intended area.  One more thing.  In the past the fourth bank of ROM was unused.  The "broken" items now live in that fourth bank.  Is there any chance that the compression mechanism was not dealing with the fourth bank at all?

Thanks, Wayne

[Bill Shen]

 Paul,

Thanks for checking out whether the latest RomWBW can be compressed into 64 KB flash.  I’ll study it more, my first thought is developing an Eazy80 configuration that turns off as many RomWBW features as possible to see if that’ll fit.  It is entirely possible and even expected that later versions of RomWBW will not fit.  I’ve went through many generations of PC since 1989 because memory were no longer big enough to work with latest OS, or some other incompatibility.  (This is why I still use Windows ME to lay out pc boards).  Not too surprising to me the maverick Eazy80 design may not work with the latest RomWBW.  Maybe there are other solutions…

Regarding W27C512 not 45nS parts, I’ve encountered the same problem.  Most of them are -45, but some are functional but clearly not fast enough.  My observations are only top sides are re-labeled, the bottom sides are always the original, so when you have a tube of parts with same date codes, check the bottom for different markings.

Bill

[Bill Shen]

Another hint of re-labeled parts are the top sides are clean without any scratches while the bottoms are all scratched up.

Bill

[Mark Pruden]

> The closest I came to an answer was this sentence in 'The RomWBW User Guide', Section 12.3 "ROM Customization": "Modification of the source code is considered an expert level task and is left to the reader to pursue." Well, I'm certainly no expert! But I peeked into the source code anyway ;-) I did find this file that appears to be a key in RomWBW: 'Source/HBIOS/layout.inc'

There are 2 other key things that are needed :

First is the build.cmd or Makefile (Linux/mac).  It is the build file that actually copies the individual .bin files (output of assembly) into a single binary rom file. 

RomLdr.Asm - is the user application loaded at boot, that acts to display startup information and provide the boot menu to the user

So to remove an unused application 

* Build makefile - don’t copy the apps into the final binary you don’t want

* Layout inc - remove the apps you don’t need, layout is a map of the locations in Rom, and must match the binaries. I suggest you comment delete what you don’t want. Doing this will break other aspects of build which need to be fixed

* RomLdr.asm - contains references to each app, and utility in the menu. The removed menu items need to be cleaned here

Hope this helps, There is probably something I missed. 

Mark

[Mark Pruden]

> Slice Inventory' caused the computer to hang!

This utility is quite new, while it is possible patching the Rom manually caused the issue, it is possible the app has an issue with your setup. 

To confirm this there is a CPM app called SLABEL, which is a superset of the Rom startup menu function. If running this app on a booted OS also fails then you may have uncovered a different issue. 

[PauldB]

Hi Mark,

(Note: now running RomWBW HBIOS v3.6.0-dev.28 on EaZy80)

Here's the output of 'SLABEL' as well as from typing 'D' and 'S' in HELP:

--------------------------------------------------------------------------------------------

RomWBW HBIOS v3.6.0-dev.28, 2025-09-24

EaZy80-512 [RCZ80_ez512_std] Z80 @ 22.000MHz
0 MEM W/S, 1 I/O W/S, INT MODE 2, EZ512 MMU
0KB ROM, 512KB RAM, HEAP=0x52AD

KIO: IO=0x00 ENABLED
CTC: IO=0x04
SIO0: IO=0x09 SIO MODE=115200,8,N,1
SIO1: IO=0x0B SIO MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT
MD: UNITS=1 RAMDISK=256KB
SD: MODE=EZ512 IO=0x02 DEVICES=1
SD0: SDHC NAME=00000 BLOCKS=0x03BA0000 SIZE=30528MB

EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]: c

Loading CP/M 2.2.

CBIOS v3.6.0-dev.28 [WBW]

Configuring Drives...

A:=MD0:0
B:=SD0:0
C:=SD0:1
D:=SD0:2
E:=SD0:3
F:=SD0:4
G:=SD0:5
H:=SD0:6
I:=SD0:7

1907 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

A>b:
B>dir sl*.*
B: SLABEL   COM
B>
B>slabel

Slice Label, v1.1, July 2025 - M.Pruden

Un.Sl Label          
----- ----------------
1.0   CP/M 2.2
1.1   ZSDOS 1.1
1.2   NZ-COM
1.3   CP/M 3
1.4   ZPM3


B>
B>reboot /c

RomWBW Reboot Utility, Version 1.0, 12-Oct-2024
   Wayne Warthen (wwar...@gmail.com) & MartinR

Cold booting...


RomWBW HBIOS v3.6.0-dev.28, 2025-09-24

EaZy80-512 [RCZ80_ez512_std] Z80 @ 22.000MHz
0 MEM W/S, 1 I/O W/S, INT MODE 2, EZ512 MMU
0KB ROM, 512KB RAM, HEAP=0x52AD

KIO: IO=0x00 ENABLED
CTC: IO=0x04
SIO0: IO=0x09 SIO MODE=115200,8,N,1
SIO1: IO=0x0B SIO MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT
MD: UNITS=1 RAMDISK=256KB
SD: MODE=EZ512 IO=0x02 DEVICES=1
SD0: SDHC NAME=00000 BLOCKS=0x03BA0000 SIZE=30528MB

EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]: h

  L           - List ROM Applications
  <u>[.<s>]   - Boot Disk Unit/Slice
  N           - Network Boot
  D           - Device Inventory
  S           - Slice Inventory
  W           - RomWBW Configure
  I <u> [<c>] - Set Console Interface/Baud Rate
  V [<n>]     - View/Set HBIOS Diagnostic Verbosity
  R           - Reboot System

Boot [H=Help]: d     <= NO OUTPUT

Boot [H=Help]: s     <= COMPUTER HANGS AT THIS POINT

[Wayne Warthen]

Mark asked a good question...

On Tuesday, September 30, 2025 at 6:17:22 AM UTC-7 mark....@gmail.com wrote:

This utility is quite new, while it is possible patching the Rom manually caused the issue, it is possible the app has an issue with your setup. 

So, since I have the hardware (thanks to Bill), I put RomWBW v3.5.0-dev.29 on the CF Card.  My ROM is still the "old fashioned" ROM that loads RomWBW into RAM from the CF Card (no compression/decompression).  Both the Device Inventory and the Slice Inventory worked fine.  So, I don't think this is a software issue with RomWBW itself.

Thanks, Wayne

[PauldB]

Hi Wayne,

I was just in the middle of writing a reply to you. You mentioned a few observations in your first reply.

"First, your location offsets appear to be relative to the third bank which is the bank that Tasty BASIC and Play a Game live.  The offset from the start of the file would actually be 0x13700 I think."

Yes, you're right about the start offset. I meant 0x13700.

"Second, the "broken" menu items occupy space after the space you cleared.  I would double check that you did not clear beyond the intended area."

I'm afraid you really got me confused here. In file 'Source/HBIOS/layout.inc', the section "ROM BANK 2 (BID_IMG1) LAYOUT (ROM2.BIN)" shows the programs in BANK 2 are linked as follows:

CAMEL FORTH -> NASCOM BASIC -> TASTYBASIC -> GAME 2048 -> EASTER EGG -> NETWORK BOOT -> ROM UPDATER -> NVRAM CONFIG -> USER

(After that section come the linked programs for "ROM BANK 3 (BID_IMG2) LAYOUT (ROM3.BIN)")

So if I understand that section of 'layout.inc' right, 'EASTER EGG' should follow 'GAME 2048', and I haven't changed any of the code in EASTER EGG, which it still runs fine. I used 'okteta', a graphical hex editor in Linux, to replace the program code where I found the locations of TASTY BASIC and GAME 2048 ($13700 to $149FF in the *.upd file) with $FF.  Location $14A00 is the start of the Mandelbrot program (EASTER EGG).

But BANK 2 doesn't seem to reference the "broken" menu items, i.e. 'Device Inventory' & 'Slice Inventory' at all. 

"The "broken" items now live in that fourth bank."

Hmm, 'layout.inc' has 'Device Inventory' & 'Slice Inventory' in BANK 3. ??

Thanks,

Paul

[PauldB]

Wayne, Mark

I decompressed the binary that I used to flash the ROM and got a file identical to the *.upd that I had modified.

I also lowered the EaZy80 osc frequency to 22MHz just in case, but it made no difference.

However I need to correct what I wrote about typing 'S' in the menu. It *will* return to the menu, but just the first time it's typed. The second time will definitely hang the computer.

I'm out of any more ideas :(

Paul

[Wayne Warthen]

Hi Paul,

On Tuesday, September 30, 2025 at 11:15:48 AM UTC-7 PauldB wrote:

"Second, the "broken" menu items occupy space after the space you cleared.  I would double check that you did not clear beyond the intended area."

I'm afraid you really got me confused here. In file 'Source/HBIOS/layout.inc', the section "ROM BANK 2 (BID_IMG1) LAYOUT (ROM2.BIN)" shows the programs in BANK 2 are linked as follows:

CAMEL FORTH -> NASCOM BASIC -> TASTYBASIC -> GAME 2048 -> EASTER EGG -> NETWORK BOOT -> ROM UPDATER -> NVRAM CONFIG -> USER

(After that section come the linked programs for "ROM BANK 3 (BID_IMG2) LAYOUT (ROM3.BIN)")

So if I understand that section of 'layout.inc' right, 'EASTER EGG' should follow 'GAME 2048', and I haven't changed any of the code in EASTER EGG, which it still runs fine. I used 'okteta', a graphical hex editor in Linux, to replace the program code where I found the locations of TASTY BASIC and GAME 2048 ($13700 to $149FF in the *.upd file) with $FF.  Location $14A00 is the start of the Mandelbrot program (EASTER EGG).

Good point.  If the Easter Egg runs fine, then that implies you did not overwrite unintended areas.

But BANK 2 doesn't seem to reference the "broken" menu items, i.e. 'Device Inventory' & 'Slice Inventory' at all. 

"The "broken" items now live in that fourth bank."

Hmm, 'layout.inc' has 'Device Inventory' & 'Slice Inventory' in BANK 3. ??

Yes, Device Inventory and Slice Inventory do now live in ROM bank 3.  I have not looked at the decompression in detail and am not sure if it operates a bank-at-a-time or decompresses the entire 128K in one shot.  Could there be an issue with decompression of ROM bank 3 in general?  In your case, the only items in ROM bank 3 that you use would be Device Inventory and Slice Inventory.  If ROM bank 3 is corrupt, those applications would be the ones affected.

Thanks, Wayne

[Wayne Warthen]

On Tuesday, September 30, 2025 at 1:29:21 PM UTC-7 PauldB wrote:

I decompressed the binary that I used to flash the ROM and got a file identical to the *.upd that I had modified.

I also lowered the EaZy80 osc frequency to 22MHz just in case, but it made no difference.

However I need to correct what I wrote about typing 'S' in the menu. It *will* return to the menu, but just the first time it's typed. The second time will definitely hang the computer.

I'm out of any more ideas :(

Have you tried using the monitor to examine the contents of ROM bank 3 (bank id 0x83 in your case) to confirm the contents are as expected after decompression?

Thanks, Wayne

[PauldB]

Ha!! Wayne, if you're saying what I think you're saying then you've (probably) hit the nail on the head!

I'm afraid the compression program hasn't a clue about any 'banks'.  It just, uh, compresses 8-)

To tell you the truth, modifying it to handle anything else would be way beyond what my 3 old grey cells could handle!

Any volunteers?

[Mark Pruden]

> Have you tried using the monitor to examine the contents of ROM bank 3 (bank id 0x83 in your case) to confirm the contents are as expected after decompression?

I think this is the best next step. 

> Any volunteers?

I can take a look at it, and look for anything obvious. - So where is the code that compresses / decompresses  - is it part of RomWBW or source code you have? Remember it could be either compression or decompression causing the issue. How do you actually create this compressed rom, is it an automated process or something done manually ?

Mark.

[Mark Pruden]

> Yes, Device Inventory and Slice Inventory do now live in ROM bank 3.  I have not looked at the decompression in detail and am not sure if it operates a bank-at-a-time or decompresses the entire 128K in one shot.  Could there be an issue with decompression of ROM bank 3 in general?  In your case, the only items in ROM bank 3 that you use would be Device Inventory and Slice Inventory.  If ROM bank 3 is corrupt, those applications would be the ones affected.

Is it possible that Rom Bank 3 is not being compressed into the target ROM image. If previously ROM bank 3 was empty, is it possible that compression just stops after the first 96K? 

Also from what you describe (RLE compression) the purpose is just about removing the blank spaces between code blocks, so in essence if the ROM is complete filled with actual code, then RLE is going to perform badly. In essence the only long term solution would be to remove apps considered lower priority.

[PauldB]

Mark, here's the layout of the 64K ROM:

The first 3 bytes are always $C3 $00 $FF, a jump to the Z80 decompression code located at $FF00 in the ROM.

Locations $0003 up to, and including, $FEFF are then available to store the compressed 128K *.upd file.

Bill Shen came up with the idea that as there were many areas of $00 and $FF bytes in RomWBW, it would be possible to compress the 128K RomWBW *.upd file to fit into 64K ROM. He originally implemented the code as part of his EaZy80 monitor program as I recall.

I suggested a stand-alone program in C to create a ready-to-flash binary file for the 64K ROM. It would generate a binary file by first adding the 3-byte jump then take the input *.upd file and look for two or more consecutive bytes of the same value (any values of $00 to $FF). If it finds duplicates, it would leave two of those followed by a byte count, n-1, (with a max byte count of $FF) where n is the total number of duplicates. Then it would append that compressed code to the binary at location $0003. Finally, it would input the Z80 decompression binary file and append it to the binary starting at location $FF00 and output a 64K binary file.

Attached is the source code for the C and Z80 programs

If anything is unclear, just let me know.

Paul

[PauldB]

Mark, you said 

"In essence the only long term solution would be to remove apps considered lower priority."

Yes, I agree. Perhaps the only built-into-ROM program should be NASCOM BASIC. That would make a RomWBW computer without any external drives still able to run *BASIC*. Now that's retro!!

Paul

[Alan Cox]

On Wed, 1 Oct 2025 at 17:09, PauldB <pakt...@gmail.com> wrote:

Mark, you said 

"In essence the only long term solution would be to remove apps considered lower priority."

I would say the obvious thing to do would be to use exomizer so you've got proper compression so that stuff fits. Run length is basically just packing the spaces in the images whereas a proper compressor will make a quite a dent in the image size

Yes, I agree. Perhaps the only built-into-ROM program should be NASCOM BASIC. That would make a RomWBW computer without any external drives still able to run *BASIC*. Now that's retro!!

You don't really need ROMWBW then at all. You will just need to build a tape interface and write some tape load/save routines.

Alan

[Mark Pruden]

On the topic of shrinking the rom image

I was able to shrink my sc126 image to easily fit within the eazy 80 64Kb compressed file with about 3k to spare. I removed EasterEgg,UserApp, Game,TastyBasic, Forth; reducing usage in BANK 2 

from 

ROM BANK INFO   LENGTH  SLACK
BANK2 BID_IMG1  29440   3328

to 

ROM BANK INFO   LENGTH  SLACK
BANK2 BID_IMG1  17664   15104

The changes were fairly simple, requiring little effort, and not much real knowledge.

Changes needed are

* layout.inc - comment out the section(s) for each app that is being removed

* romldr - need to remove the lines in the menu that refer to the included applications, easy enough to find since the compile will fail based on the previous change

* makefile (for linux) - remove references to the associated bin files e.g.easteregg.bin

Further to last step: The most important change is to the command, which creates the target binary image:

cat camel80.bin nascom.bin tastybasic.bin game.bin eastaegg.bin $(NETBOOT) updater.bin sysconf.bin usrrom.bin >rom2.bin

Some comments :

While  not well defined, there was some definition put to what is in each bank.

Bank 1 Core System - I think should be left alone at this point.

Bank 2 User applications - Prime candidate for things to remove, although does contain utilities (network boot,updater,Nvrconfig which ultimately should be moved to bank 3 )

Bank 3 System Utilities - Can be deleted with caution ! , e.g. Device Inventory is used internally by RomWBW

I think the `romldr`  could be changed to use ifdefs on the (optional/non-critical) menu definitions so no changes would be needed when standalone apps are removed from layout.inc

Possibly this could be made configurable, e.g. If the build of easteregg does not detect EGG_LOC defined variable, the assembler could output a zero length file, then the build scripts (makefile) wont need to change. thus the only change would be to layout.inc.

Just opinions, up to "Wayne Warthen" to advise

I would recommend you try building a cutdown ROM and see how you go. I looked at your routines and didn't see any issues. The biggest improvement would be the compressor should advise of the outcome, e.g Byes Free (or not) in the target image.

[Bill Shen]

I am juggling too many tasks, most are not even electronics related, so I’m sorry I wasn’t able to participate in this interesting topic.   Z80retro by John Winans also uses compression to fit RomWBW in its flash, so I’m interested in a solution.   I see nice progress, so maybe the problem gets solved with fresh new ideas.

As a fallback solution, prior to compression/decompression, there was a simple SD/CF read routine to load the RomWBW binary saved in the 1 megabyte reserved area in the CF and SD.  The RomWBW load routine works well for CF, but somewhat slow for SD because of bitbang interface.  If all failed, loading RomWBW from SD is still an option, especially when Eazy80 is running at 29.5mhz.

Bill

[PauldB]

Mark, thanks for the tips.

I made the changes you mentioned and it booted right up. The only difference I noticed to my config was that menu choice 's' didn't hang the computer. However neither 'd' nor 's' produced any output.

I went a step further. In layout.inc, I moved two items from bank 3 to bank 2. In Makefile, in section '$(OBJECTS) : $(ROMDEPS)', I did likewise regarding what items were concatenated into rom2 & rom3. I'm attaching the files with the changes.

Here's some sample output from 'M6' (my 6th mod of RomWBW):

(note that menu choices 'd' and 's' now give (hopefully) correct output!)

----------------------------------------------------------------------------------------------------

RomWBW HBIOS v3.6.0-dev.29, 2025-10-02

EaZy80-512 [RCZ80_ez512_std] Z80 @ 22.000MHz
0 MEM W/S, 1 I/O W/S, INT MODE 2, EZ512 MMU
0KB ROM, 512KB RAM, HEAP=0x52AD

KIO: IO=0x00 ENABLED
CTC: IO=0x04
SIO0: IO=0x09 SIO MODE=115200,8,N,1
SIO1: IO=0x0B SIO MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT
MD: UNITS=1 RAMDISK=256KB
SD: MODE=EZ512 IO=0x02 DEVICES=1
SD0: SDHC NAME=00000 BLOCKS=0x03BA0000 SIZE=30528MB

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      SIO0:       RS-232            115200,8,N,1
Char 1      SIO1:       RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      SD0:        SD Card           30528MB,LBA

EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]: h

  L           - List ROM Applications
  <u>[.<s>]   - Boot Disk Unit/Slice
  N           - Network Boot
  D           - Device Inventory
  S           - Slice Inventory
  W           - RomWBW Configure
  I <u> [<c>] - Set Console Interface/Baud Rate
  V [<n>]     - View/Set HBIOS Diagnostic Verbosity
  R           - Reboot System

Boot [H=Help]: l

ROM Applications:

  M: Monitor
  C: CP/M 2.2
  Z: Z-System
  B: BASIC
  X: XModem Flash Updater

Boot [H=Help]: d

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      SIO0:       RS-232            115200,8,N,1
Char 1      SIO1:       RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      SD0:        SD Card           30528MB,LBA


Boot [H=Help]: s

Un.Sl Label
----- ----------------
1.0   CP/M 2.2
1.1   ZSDOS 1.1
1.2   NZ-COM
1.3   CP/M 3
1.4   ZPM3

Boot [H=Help]: w

RomWBW System Config Utility, Version 1.1 June-2025

Current Configuration: NVRAM Not Found. Exiting.


Boot [H=Help]: v

HBIOS Diagnostic Level: 4

Boot [H=Help]: m

Loading Monitor.

Monitor Ready (? for Help)
8E>X

EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]: c

Loading CP/M 2.2.

CBIOS v3.6.0-dev.29 [WBW]

Formatting RAMDISK...

Configuring Drives...

A:=MD0:0
B:=SD0:0
C:=SD0:1
D:=SD0:2
E:=SD0:3
F:=SD0:4
G:=SD0:5
H:=SD0:6
I:=SD0:7

1907 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

A>b:

B>reboot /w

RomWBW Reboot Utility, Version 1.0, 12-Oct-2024
   Wayne Warthen (wwar...@gmail.com) & MartinR

Warm booting...


EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]: z

Loading Z-System.

CBIOS v3.6.0-dev.29 [WBW]

Configuring Drives...

A:=MD0:0
B:=SD0:0
C:=SD0:1
D:=SD0:2
E:=SD0:3
F:=SD0:4
G:=SD0:5
H:=SD0:6
I:=SD0:7

1907 Disk Buffer Bytes Free

ZSDOS v1.1, 54.0K TPA

A>b:
B>reboot /w

RomWBW Reboot Utility, Version 1.0, 12-Oct-2024
   Wayne Warthen (wwar...@gmail.com) & MartinR

Warm booting...


EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]: b

Loading BASIC.
Memory top?
Z80 BASIC Ver 4.7b
Copyright (C) 1978 by Microsoft
55603 Bytes free
Ok
bye


EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]: x

Loading XModem Flash Updater.

ROMWBW XMODEM FLASH UPDATER

FLASH CHIP NOT SUPPORTED


EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]: z

Loading Z-System.

CBIOS v3.6.0-dev.29 [WBW]

Configuring Drives...

A:=MD0:0
B:=SD0:0
C:=SD0:1
D:=SD0:2
E:=SD0:3
F:=SD0:4
G:=SD0:5
H:=SD0:6
I:=SD0:7

1907 Disk Buffer Bytes Free

ZSDOS v1.1, 54.0K TPA

A>
A>b:
B>dir
  |  ASM     .COM  |  DDT     .COM  |  DUMP    .COM  |  ED      .COM
  |  HELP    .COM  |  HELP    .HLP  |  LIB     .COM  |  LINK    .COM
  |  LOAD    .COM  |  MAC     .COM  |  PIP     .COM  |  RMAC    .COM
  |  STAT    .COM  |  SUBMIT  .COM  |  XREF    .COM  |  XSUB    .COM
  |  ZSID    .COM  |  README  .TXT  |  ASSIGN  .COM  |  BBCBASIC.COM
  |  BBCBASIC.TXT  |  CPUSPD  .COM  |  REBOOT  .COM  |  COPYSL  .COM
  |  COPYSL  .DOC  |  FAT     .COM  |  FDU     .COM  |  FDU     .DOC
  |  FORMAT  .COM  |  MODE    .COM  |  RTC     .COM  |  SLABEL  .COM
  |  SURVEY  .COM  |  SYSCOPY .COM  |  SYSGEN  .COM  |  TALK    .COM
  |  HTALK   .COM  |  TBASIC  .COM  |  TIMER   .COM  |  TUNE    .COM
  |  XM      .COM  |  ZMP     .COM  |  ZMP     .HLP  |  ZMP     .DOC
  |  ZMP     .CFG  |  ZMP     .FON  |  ZMXFER  .OVR  |  ZMTERM  .OVR
  |  ZMINIT  .OVR  |  ZMCONFIG.OVR  |  ZMD     .COM  |  VGMPLAY .COM
  |  CPM     .SYS  |  ASCIIART.BAS  |  DDTZ    .DOC  |  FLASH   .DOC
  |  SUPERSUB.DOC  |  TE      .DOC  |  UNARC   .DOC  |  UNZIP   .DOC
  |  ZDE     .DOC  |  CRUNCH28.CFG  |  CLRDIR  .COM  |  COMPARE .COM
  |  CRUNCH  .COM  |  DDTZ    .COM  |  DOWNLOAD.COM  |  EX      .COM
  |  FDISK80 .COM  |  FIND    .COM  |  FLASH   .COM  |  GENHEX  .COM
  |  LS      .COM  |  LSWEEP  .COM  |  MBASIC  .COM  |  NULU    .COM
  |  PMARC   .COM  |  PMEXT   .COM  |  RMXSUB1 .COM  |  SUPERSUB.COM
  |  TDLBASIC.COM  |  TE      .COM  |  UNARC   .COM  |  UNCR    .COM
  |  UNZIP   .COM  |  WDATE   .COM  |  XSUB1   .COM  |  ZAP     .COM
  |  ZDE     .COM  |  ZDENST  .COM  |  ZMRX    .COM  |  ZMTX    .COM
  |  HELLO   .ASM  |  KERCPM22.COM
B>stat
A: R/W, Space: 248k
B: R/W, Space: 6164k


B>survey


        *** RomWBW System Survey (Mar 2023) ***

Drive A: 24K bytes in 0 files with 232K bytes remaining
Drive B: 2012K bytes in 173 files with 6164K bytes remaining

Memory map:
0       8       16      24      32      40      48      56      64
|       |       |       |       |       |       |       |       |
TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTCCCBBBBBBB
T=TPA   C=CPM   B=BIOS or unassigned    R=ROM or bad
BIOS at E600    iobyte 94       drive 01        BDOS at D800

65535 Bytes RAM         0 Bytes ROM             55296 Bytes in TPA
0 Bytes Empty           65535 Total Active Bytes

Active I/O ports:
01 02 03 08 09 0B 0C 0E
10 11 12 13 18 19 1B 1C 1E
20 21 22 23 28 29 2B 2C 2E
30 31 32 33 38 39 3B 3C 3E
40 41 42 43 48 49 4B 4C 4E
50 51 52 53 58 59 5B 5C 5E
60 61 62 63 68 69 6B 6C 6E
70 71 72 73 78 79 7B 7C 7E
71 Ports active

B>cpuspd

RomWBW CPU Speed Selector v1.0, 11-Sep-2024

  22.000 MHz Oscillator
  CPU speed is 22.000 MHz

B>slabel

Slice Label, v1.1, July 2025 - M.Pruden

Un.Sl Label
----- ----------------
1.0   CP/M 2.2
1.1   ZSDOS 1.1
1.2   NZ-COM
1.3   CP/M 3
1.4   ZPM3


B>

----------------------------------------------------------------------------------------------------

Thanks,

Paul

[PauldB]

Here is a screenshot of the partial contents of the compressed file 'rom64k_v360-d29__M6.bin'. Note there's over 8K of space left!

[Mark Pruden]

Paul.

I took a look at the decompression Z80 code, and think found the issue. See Below. Think this is why the 4th bank is omitted

nxtDbank:
ld hl,0
inc d ;next bank
ld a,d
cp 83h ;compare to bank 3 <<<<<<< Should be 84h
jp z,decompDone
jp start

Mark.

[PauldB]

Mark, good catch!

After changing that byte in 'decomp_rom.asm', I compressed 'RCZ80_ez512_std-v3.6.0-dev.29.upd' (with just Nascom Basic), flashed a 64k ROM and booted up EaZy80-512. Everything seems to work :-)

That 'Device Inventory' and 'Slice Inventory' now both generate output shows, AFAIK, that the 4th bank is loaded.

-------------------------------------------------------------
RomWBW HBIOS v3.6.0-dev.29, 2025-10-02

EaZy80-512 [RCZ80_ez512_std] Z80 @ 22.000MHz
0 MEM W/S, 1 I/O W/S, INT MODE 2, EZ512 MMU
0KB ROM, 512KB RAM, HEAP=0x52AD

KIO: IO=0x00 ENABLED
CTC: IO=0x04
SIO0: IO=0x09 SIO MODE=115200,8,N,1
SIO1: IO=0x0B SIO MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT
MD: UNITS=1 RAMDISK=256KB
SD: MODE=EZ512 IO=0x02 DEVICES=1
SD0: SDHC NAME=00000 BLOCKS=0x03BA0000 SIZE=30528MB

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      SIO0:       RS-232            115200,8,N,1
Char 1      SIO1:       RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      SD0:        SD Card           30528MB,LBA


EaZy80-512 [RCZ80_ez512_std] Boot Loader

Boot [H=Help]:

... ETC

-------------------------------------------------------------

I'll contact Bill to let him know of the change in 'decomp_rom.asm' in case he's not keeping up with this conversation.

Thanks,
Paul

[PauldB]

Mark,

I've modified the compression program (with a bit of help from Le Chat) to output either the bytes free if RomWBW fits after compression, or the overrun in bytes if it doesn't. Also some more error checking is done.

ex. with 'RCZ80_ez512_std_v360-d24.upd', which without changes is too large, the program returns only the message: 

    "Error: Compressed RomWBW file exceeds available space by 2860 bytes"


ex. with 'RCZ80_ez512_std_v360-d6.upd', which does fit, the program returns a 64k binary and the message: 

    "Compression of RomWBW file complete. Free bytes left in available space: 4762 bytes"

Let me know if it does the job you asked for.

The source files are attached.

Paul

[Mark Pruden]

Paul

Changes are a good improvement (i didn't look at code), and makes it easier to use. If this gets integrated into RomWBW build them may need additional change to return failure error code on exit (but that's for another day)

Mark.

[PauldB]

Mark, these are the changes I came up with to adapt  'comp_ez512' to the RomWBW build system:

1. Use a fixed output file name, e.g.:

   'RCZ80_ez512_std_rom64k.rom'
      or perhaps even better
   'RCZ80_ez512_std.rom' (replacing (useless?) original file)

2. Add Exit statements

Code  Description
----  -----------
 0    Success: Compressed *.upd fits; 64k bin file written
 1    Error: Compressed *.upd exceeds available rom space
 2    Error: File 'decomp_rom.bin' not found
 3    Error: Input file not found

Are these changes correct/enough?

Paul

[Mark Pruden]

Looks OK to me. You will need to create a PR for @wayne to approve.

IMHO
* keeping the output file "RCZ80_ez512_std_rom64k.rom" seperate to the "RCZ80_ez512_std.rom" is better, as it makes it explicit. i.e. a build system that replaces a file, how do you know if the file was replaced or not, you just copy the file, and might get the uncompressed version.
* how about RCZ80_ez512_std_64k.rom (removing the duplicated "rom") - a duplicate ROM doesnt add any value, just makes the filename longer.

[PauldB]

On Fri, 10 Oct 2025 at 04:27, Mark Pruden <mark....@gmail.com> wrote:
"Looks OK to me. You will need to create a PR for @wayne to approve."

A nooby question I'm afraid. How do I create a "PR" and where is "@wayne" ?

 
"IMHO
* keeping the output file "RCZ80_ez512_std_rom64k.rom" seperate to the "RCZ80_ez512_std.rom" is better, as it makes it explicit. i.e. a build system that replaces a file, how do you know if the file was replaced or not, you just copy the file, and might get the uncompressed version."

Yes, good point to give the file a unique name

 
"* how about RCZ80_ez512_std_64k.rom (removing the duplicated "rom") - a duplicate ROM doesnt add any value, just makes the filename longer."

Quite obvious when you point it out  :)

After a bit of pondering, it occurred to me that other boards having only 64k ROM onboard might also be able to run RomWBW if compression was used.

As a result I've renamed 'comp_ez512' to 'compress_upd' and modified it to accept a *.upd (or other) input file. The program then makes an attempt to fit the code into a 64k ROM. If successful, if outputs a 64k binary file with the name of the input file (minus extension) + "_64k.rom". 

ex. 'compress_upd  RCZ80_ez512_std.upd'  would output, if compression was successful, the file 'RCZ80_ez512_std_64k.rom'  plus exit code '0'. 

This program should easily fit into a batch file. Source files are attached.
Thanks,
Paul

[PauldB]

Hmm, doesn't look like I attached the files. Let's try again...

[Wayne Warthen]

Hi Paul,

Comments below...

On Friday, October 10, 2025 at 12:04:35 PM UTC-7 PauldB wrote:

On Fri, 10 Oct 2025 at 04:27, Mark Pruden <mark....@gmail.com> wrote:
"Looks OK to me. You will need to create a PR for @wayne to approve."

A nooby question I'm afraid. How do I create a "PR" and where is "@wayne" ?

Mark is referring to a Pull Request against the RomWBW GitHub Repository that hosts RomWBW.  This is the GitHub way of submitting a code change request.  Let me know if you want to pursue that.

"IMHO
* keeping the output file "RCZ80_ez512_std_rom64k.rom" seperate to the "RCZ80_ez512_std.rom" is better, as it makes it explicit. i.e. a build system that replaces a file, how do you know if the file was replaced or not, you just copy the file, and might get the uncompressed version."

Yes, good point to give the file a unique name

Yes, I would like to retain the original ROM since the compressed one removes some functionality.

After a bit of pondering, it occurred to me that other boards having only 64k ROM onboard might also be able to run RomWBW if compression was used.

I am not aware of any other RomWBW platforms with 64K ROM.  However, there may be some in the future.  It would be good to have this capability available for use by other platforms in the future.

As a result I've renamed 'comp_ez512' to 'compress_upd' and modified it to accept a *.upd (or other) input file. The program then makes an attempt to fit the code into a 64k ROM. If successful, if outputs a 64k binary file with the name of the input file (minus extension) + "_64k.rom". 

ex. 'compress_upd  RCZ80_ez512_std.upd'  would output, if compression was successful, the file 'RCZ80_ez512_std_64k.rom'  plus exit code '0'. 

Sounds good.

This program should easily fit into a batch file. Source files are attached.

OK.  Let me know if you want to pursue submitting a PR or if you want me to do the integration.

Thanks, Wayne 

[Bill Shen]

The other Z80 SBC that benefited from the updated compression/decompression scheme is Z80Retro! By John Winans.  It also has 64K ROM and SD card for storage.  Earlier I have successfully compressed older version of RomWBW for Z80retro.  I’ll try the updated compression method when I have a bit more time.

https://groups.google.com/g/retro-comp/c/6p2iAUDaZ-g/m/ul-ZoRUsAQAJ

There are other RomWBW-capable designs with tiny ROM, but they generally have CF disk, RomWBW can be stored in CF and quickly copied into RAM.  In case of 3VZ180 which has SD card and a tiny ROM, Z180’s SPI interface is very fast, so I still can copy RomWBW from SD to RAM fairly quickly.  The only exception is 3VZ80 that has tiny ROM, SD card, and bit-bang SPI, so its only option is bit-bang copying RomWBW from SD card to RAM which takes 6-7 seconds at 16Mhz.  That’s is the slowest implementation of RomWBW.

Bill

[Wayne Warthen]

Hi Bill

On Friday, October 10, 2025 at 4:23:13 PM UTC-7 Bill Shen wrote:

The other Z80 SBC that benefited from the updated compression/decompression scheme is Z80Retro! By John Winans.  It also has 64K ROM and SD card for storage.  Earlier I have successfully compressed older version of RomWBW for Z80retro.  I’ll try the updated compression method when I have a bit more time.

https://groups.google.com/g/retro-comp/c/6p2iAUDaZ-g/m/ul-ZoRUsAQAJ

Thanks for reminding me of this.  I remember that you had some success porting RomWBW to John Winan's Z80Retro!.  We never really formalized that in RomWBW.  If you get a chance, let me know where that stands and whether we should make it a "real" platform in RomWBW.

Thanks, Wayne