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

[PauldB]

Hi Wayne, and thanks for the feedback.

I've been trying to follow instructions (from Github, among others) to create a new branch for myself, but I can't to get it to work. It's confusing because I don't really know *where* to start (not to mention *what* to start with: a 'Fork' or a 'Branch' ?). Ugh!

Wayne, please do the "integration" for me :)

Thanks,

Paul

[Wayne Warthen]

No problem Paul.  GitHub can be very confusing if you do not deal with it regularly.

I will work on the integration and keep you posted.

Thanks, Wayne

[Wayne Warthen]

Hi Paul,

How are you building the decompression binary?  Which Z80 assembler and what command line are you using?

It looks like the compression on the normal .upd file results in a 2868 byte overrun.  I guess I need to automate the "nulling out" of some ROM components to make this fit.  Which components are you currently removing?

Thanks, Wayne

[Wayne Warthen]

Never mind the question about building the decompression binary.  I figured this out.

I would still like to confirm that you are removing the components TastyBASIC and Game.

In order to do the binary manipulation of the output file (removing the components), I am going to use srecord.  This tool is already used in other places in the RomWBW build.

I am going to take some liberties with your compression program (hope that is OK).  Since srecord already has a powerful mechanism to merge binaries (hex and raw), I will use it to create the final output.  This just means that the compression program can be a completely generic compressor.  This allows it to be used in other scenarios.  Additionally, this approach will allow using alternate compressors.  Someday, it would be nice to use Exomizer because it probably would make everything fit.

The srecord tool is quite intelligent and will diagnose the "doesn't fit" scenario.

Thanks, Wayne

[PauldB]

Sorry about the delay, Wayne. I live about 8 or 9 time zones before your's (CAL right?) and I only read your post as I was going to bed.

It was good thing that you asked about the decomp_rom.bin source because I had completely forgotten what assembler I had used. I just remember that after having assembled it, I just used a hex editor (okteta) to trim the code into the 256-byte blob I've been using since.

Probably unnecessary now, but I slightly modified and reformatted the decomp source to assemble with uz80as. I'll attach it anyway.

For RomWBW-v3.6.0-dev.29, the components I had removed were Forth, Tasty, Game, Easter Egg and User. That left just the Nascom Basic app, resulting in 8357 bytes left over. That was an extreme case; given the free space, some apps could have been left in.

RomWBW-v3.6.0-dev.29, without removing any apps, gave an overrun of 2871 bytes.

RomWBW-v3.6.0-dev.6, also without removing any apps, had 4762 bytes left over.

"I am going to take some liberties with your compression program (hope that is OK)."

Wayne, I leave the compression code in your competent hands to do with as you like :)

I'm just pleased I could make a small contribution to RomWBW!

Thanks,

Paul

[Wayne Warthen]

OK, I think I have this integrated into the RomWBW build now.

If you look at the latest RomWBW Snapshot, you will see RCZ80_ez512_std_64k.rom in the Binary directory.  I have tested this on my system, but would be happy to get feedback from others.

Thanks to Paul for providing the compression utility that is integral to this enhancement.

Thanks, Wayne

[PauldB]

Wayne,

That was quick!

The ROM flashed with RCZ80_ez512_std_64k.rom ran fine in my EaZy80-512. The only difference I could see from my compressed version was that the menu apps for Tasty and Game are still listed in yours. However, executing either just brings the menu back, so no problem there.

Impressive. I'll have to dig into the RomWBW code and see how you used srecord :)

Paul

[PauldB]

Wayne, I am wondering about this line from /Source/EZ512/Makefile:

srec_cat $< -binary -exclude 0x13700 0x14A00 -fill 0xC9 0x13700 0x14A00 -o temp.upd -binary

Is this arg necessary

    -exclude 0x13700 0x14A00

when the next arg fills that same segment of memory with C9's ?
    -fill 0xC9 0x13700 0x14A00

I'm probably thinking wrong - wouldn't be the first time ;)

Paul

[Mark Pruden]

>> I've been trying to follow instructions (from Github, among others) to create a new branch for myself, but I can't to get it to work. It's confusing because I don't really know *where* to start (not to mention *what* to start with: a 'Fork' or a 'Branch' ?). Ugh!

Paul

for future reference.

basically you have to create a Fork of the repository, which create your own copy

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo

then you clone your repository to your local machine.
https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository

you make changes on a branch, (per feature or change) in a repository

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository

then you make changes test, and commit your changes to your local repository

https://github.com/git-guides/git-commit

then you need to push your changes from local to your github repository

https://github.com/git-guides/git-push

finally you create the pull request

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

[PauldB]

Hi Mark, 

Thanks, I appreciate the detailed instructions. Good reference for others as well.

I haven't given up yet. Will study your instructions and try again :)

Thanks,

Paul

[Mark Pruden]

Paul

srec_cat ..\..\Binary\%1.upd -binary -exclude 0x13700 0x14A00 -fill 0xC9 0x13700 0x14A00 -o temp.upd -binary

This command (i am pretty sure) is removing code and replacing with C9's (before compression), which has the affect of excluding the section.

Wayne

While I understand the intent. However as soon as layout.inc is changed, it will come back to bite you. As a minimum this code need commenting, and layout.inc needs comments pointing to the line of code (above)

However a slightly better approach (IMHO) - see post from Oct 2, 2025, 11:14:27 AM - In Short 

* Config Files could have options for Excluding each of selected apps, which could be considered optional, e.g. Tasty

* layout.inc could use #ifdefs to exclude each section if config excludes it.

* The assembler of the app code itself, can also use #ifdefs to generate a zero length binary - assumes !!! it is assembled and is part of hbios - which I know Tasty and Nascom are not.

* romldr can also use #ifdefs to exclude the menu items.

This seems like a bit of work, realistically may not be used by too many people, but it does give a way to claw back space if start getting close to 128Kb

[Wayne Warthen]

On Monday, October 13, 2025 at 3:54:07 AM UTC-7 PauldB wrote:

Wayne, I am wondering about this line from /Source/EZ512/Makefile:

srec_cat $< -binary -exclude 0x13700 0x14A00 -fill 0xC9 0x13700 0x14A00 -o temp.upd -binary

Is this arg necessary

    -exclude 0x13700 0x14A00

when the next arg fills that same segment of memory with C9's ?
    -fill 0xC9 0x13700 0x14A00

This does look redundant doesn't it.  😀  Turns out to be necessary though.

srec_cat actually keeps track of the bytes that are occupied and vacant separately from any specific value.  The fill command, by design, only fills in the "holes".  So, without the exclude command, fill would actually do nothing.  srecord is powerful and useful, but can be a bit tricky.

Thanks, Wayne

[Wayne Warthen]

On Monday, October 13, 2025 at 4:51:15 AM UTC-7 mark....@gmail.com wrote:

While I understand the intent. However as soon as layout.inc is changed, it will come back to bite you. As a minimum this code need commenting, and layout.inc needs comments pointing to the line of code (above)

However a slightly better approach (IMHO) - see post from Oct 2, 2025, 11:14:27 AM - In Short 

* Config Files could have options for Excluding each of selected apps, which could be considered optional, e.g. Tasty

* layout.inc could use #ifdefs to exclude each section if config excludes it.

* The assembler of the app code itself, can also use #ifdefs to generate a zero length binary - assumes !!! it is assembled and is part of hbios - which I know Tasty and Nascom are not.

* romldr can also use #ifdefs to exclude the menu items.

This seems like a bit of work, realistically may not be used by too many people, but it does give a way to claw back space if start getting close to 128Kb

Thanks Mark.  I am going to respond to this on the GitHub issue to avoid duplication.

Thanks, Wayne 

[Mark Pruden]

Paul.

Regarding documentation, I think this should be added to (to Page 40) the RomWBW hardware.PDF document. I copied this from an earlier post of yours. Does it look accurate ?

#### Compressed ROM Image File

RCZ80_ez512_std_64k.rom

A 64K ROM image is supported. As there were many areas of $00 and $FF bytes in RomWBW, it is possible to compress the 128K RomWBW *.upd file to fit into 64K ROM. The compression routine looks for two or more consecutive bytes of the same value (any values of $00 to $FF). If it finds duplicates, it would leave two duplicate bytes followed by a byte count, n-1, (with a max byte count of $FF) where n is the total number of duplicates. 

A stand-alone program written in C creates a ready-to-flash binary file for the 64K ROM. The 64K binary file is in the following format. 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.

* location $FF00 up to $FFFF, a seperate Z80 decompression routine that executes at startup to decompress the the 64K ROM into RAM.

[Wayne Warthen]

On Monday, October 13, 2025 at 4:22:42 PM UTC-7 mark....@gmail.com wrote:

Regarding documentation, I think this should be added to (to Page 40) the RomWBW hardware.PDF document. I copied this from an earlier post of yours. Does it look accurate ?

It seems reasonable to me, so I have added it.  If changes are desired, just let me know.

Thanks, Wayne 

[PauldB]

Mark and Wayne,

Regarding documentation, I think this should be added to (to Page 40) the RomWBW hardware.PDF document. I copied this from an earlier post of yours. Does it look accurate ?

 I've uploaded an improved text to Github issue #500 you should use instead.

Thanks,

Paul

[Fernando Carolo]

Hi Wayne,

On Mon, Oct 13, 2025 at 12:31 AM Wayne Warthen <wwar...@gmail.com> wrote:

OK, I think I have this integrated into the RomWBW build now.

If you look at the latest RomWBW Snapshot, you will see RCZ80_ez512_std_64k.rom in the Binary directory.  I have tested this on my system, but would be happy to get feedback from others.

I've just upgraded my Eazy80-512 with a custom image built from head, with a slightly modified config since I have a 25.175MHz crystal and an SC129 I/O module installed. I ended up with a ROM image with 65445 bytes, which I flashed without issues and I have to say it, the boot time is *fast*.

Thanks to you, Paul and Mark for all the work on this.

Best,

Fernando

 

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/797566ca-681f-422d-bae0-019b2fe863ebn%40googlegroups.com.

[Wayne Warthen]

Thanks for the feedback Fernando.  Glad it worked for you.

I think we can put this one to bed for now.

Thanks, Wayne

[Bill Shen]

I downloaded the latest RomWBW (master 3.6, dev 36) and checked out the much better process of compressing RomWBW to 64K ROM.  Compliment to Paul for raising the issue and Wayne for solving the problem in his systematic way.  I will check out the new compression process for John Winans' Z80retro.

I want to show a derivative of Eazy80-512 that is the same Eazy80-512 design except the RC2014 expansion bus and prototype area are removed so to fit in an Altoids can.  The design motivation is a JLCPCB shipping coupon that will expired soon so I made some blind assumptions about size of Altoids can and have 5 boards built and shipped for $7.   Received the pc board today; the board works, but won't fit inside the Altoids can because the corner radius is too sharp so the four corners sticking out too far.  I think I can move the components inward and round the corners more so it will fit.  Height wise, the SD daughter card is low enough that the lid can closed over the board with SD daughter card installed.  Current consumption is 100mA at 5V with 22MHz clock, so it can be powered with an USB-serial adapter outside of the Altoids can.  There you have it, RomWBW in Altoids!
Bill

[Mark Huffstutter]

Very Nice, Bill!

 

At least You can say You didn’t cut corners on the design…..  :>)

 

I’ll let Myself out now…..

 

Mark

 

From: retro...@googlegroups.com <retro...@googlegroups.com> On Behalf Of Bill Shen
Sent: Wednesday, October 22, 2025 8:45 PM
To: retro-comp <retro...@googlegroups.com>
Subject: Re: [retro-comp] Re: EaZy80-RomWBW - EOL ?

 

I downloaded the latest RomWBW (master 3.6, dev 36) and checked out the much better process of compressing RomWBW to 64K ROM.  Compliment to Paul for raising the issue and Wayne for solving the problem in his systematic way.  I will check out the new compression process for John Winans' Z80retro.

I want to show a derivative of Eazy80-512 that is the same Eazy80-512 design except the RC2014 expansion bus and prototype area are removed so to fit in an Altoids can.  The design motivation is a JLCPCB shipping coupon that will expired soon so I made some blind assumptions about size of Altoids can and have 5 boards built and shipped for $7.   Received the pc board today; the board works, but won't fit inside the Altoids can because the corner radius is too sharp so the four corners sticking out too far.  I think I can move the components inward and round the corners more so it will fit.  Height wise, the SD daughter card is low enough that the lid can closed over the board with SD daughter card installed.  Current consumption is 100mA at 5V with 22MHz clock, so it can be powered with an USB-serial adapter outside of the Altoids can.  There you have it, RomWBW in Altoids!
Bill

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/ba183bf8-89a6-4a62-a9a9-f341805c4f00n%40googlegroups.com.

[PauldB]

Move over Raspberry Pi, here comes the Magnolia Pi !!

Amazing stuff, Bill :)

Paul

[Wayne Warthen]

Very nice Bill.  Smallest RomWBW yet...  😀

-Wayne

[Mark Pruden]

Hi Bill

You could save some board space by shrinking the footprint for the Oscillator removing extra pins needed for Dip14, only support the small footprint

Also the decoupling Capacitors come in a 2.54mm pitch variant, which might help shave some space. 

Mark

[Bill Shen]

Half size oscillator and bypass with 2.54mm pitch are good suggestions. I’m pretty sure the design can fit with these suggestions.  I’ll be sure to do a better job of cutting corners ;-)

I am building up another board without quad OR gates and only 128KB RAM to verify the Eazy80-128 configuration.

Bill

[T Gerbic]

There are switches half or maybe 40% smaller and you may be able to get RAM in smaller width package. Maybe the arrangement could shrink if you use the PLCC version of the Z80. 

[Bill Shen]

Z80 in PLCC44 package will certainly save lots of space, but I design Eazy80 for this particular eBay kit, https://www.ebay.com/itm/116032696403. It is an inexpensive $7.50 kit (shipping is $16, however) that I’ve tested several times and proven to be functional parts.  The shipping remains $16 for 2 kits, so I’d order two kits, just in case.  This is why I’ve designed Eazy80 with two configurations, such that one kit is for Eazy80-128, and the second kit is for Eazy80-512 (with the 128k RAM replaced with 512k RAM).

Bill

[7alken]

cool and sweet :-)