Skip to content

Files

Latest commit

a0d1825 · May 8, 2025

History

History

Source

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Apr 25, 2025
Feb 22, 2025
Dec 21, 2024
Dec 20, 2024
Apr 10, 2025
Feb 14, 2024
May 8, 2025
Dec 20, 2024
Aug 19, 2024
Apr 25, 2025
Jan 27, 2025
May 8, 2025
Sep 4, 2024
Apr 25, 2025
Feb 7, 2024
Dec 20, 2024
Mar 29, 2025
Nov 28, 2024
Oct 9, 2024
Aug 19, 2024
Feb 8, 2025
Jul 24, 2022
Feb 11, 2022
Apr 13, 2025
Aug 19, 2024
Aug 19, 2024
Dec 20, 2024
Aug 19, 2024
Jun 20, 2023
Dec 20, 2024
Jul 24, 2021
Oct 21, 2021
Dec 20, 2024
Jul 1, 2024
Jul 24, 2021
Jul 24, 2021
Jul 25, 2021
Feb 11, 2024
Oct 30, 2023
Jul 24, 2021
Dec 10, 2023
Oct 9, 2023
Feb 11, 2024
Jul 4, 2017
Dec 20, 2024
Feb 24, 2025
Sep 7, 2024
Feb 24, 2025
May 8, 2025
May 8, 2025
***********************************************************************
***                                                                 ***
***                          R o m W B W                            ***
***                                                                 ***
***                    Z80/Z180 System Software                     ***
***                                                                 ***
***********************************************************************

This directory is the root directory of the source tree for RomWBW.

This document describes the process to build a customized version 
of the RomWBW firmware.  RomWBW was explicitly organized in a way 
that makes it very easy to rebuild the firmware.

Significant customization can be achieved with a custom built 
firmware using simple option configuration files.  You can 
customize your firmware to:

    - Include support for add-on support boards such as
      the DiskIO, Dual-IDE, etc.
    - Modify operational parameters such as serial port
      speed or wait state insertion.
    - Add or remove programs or files contained on the disk images.
    
Virtually all source code is provided including the operating
systems themselves, so advanced users can easily modify any of
the software.

A cross-platform approach is used to build the RomWBW firmware. 
The software is built using a modern Windows, Linux, or Mac
computer, then the resulting firmware image is programmed into
the ROM of your RetroBrew Computer CPU board.

Windows Build System Requirements
---------------------------------

For Microsoft Windows computers, all that is required to build the
firmware is the RomWBW distribution zip archive file.  The zip
archive package includes all of the required source code 
(including the operating systems) and the programs required to run 
the build.

The build process is run via some simple scripts that automate the 
process.  These scripts utilize both batch command files as well as 
Windows PowerShell.  Windows 7 or greater is recommended.  If you want 
to use Windows Vista or XP, you will need to first install PowerShell 
which available for free from Microsoft.  Either 32 or 64 bit versions 
of Microsoft Windows are fine.  No additional programs need to be 
installed to run the build.

You may find that you get messages such as this during the Windows
build process:

Security warning
Run only scripts that you trust. While scripts from the internet can be 
useful, this script can potentially harm your computer. If you trust 
this script, use the Unblock-File cmdlet to allow the script to run 
without this warning message. Do you want to run 
C:\Temp\RomWBW-v3.5.0-dev.67-Package\Source\Images\BuildDisk.ps1?
[D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"):

These prompts occur if Windows has marked the files as "blocked"
because they were downloaded from the Internet.  To unblock all of
the files in the entire RomWBW distribution tree, start PowerShell
and navigate to the root of the distribution.  Enter the following
command:

	dir -recurse | unblock-file

This will unblock all files within the distribution and preclude the
security warning messages.  Obviously, you should make sure you have
downloaded the RomWBW distribution from a valid/trustworthy source
before removing the file block protection.

Linux Build System Requirements
-------------------------------

You must have some standard system tools and libraries 
installed, specifically: gcc, gnu make, libncurses, and srecord.
Typically, something like this will take care of adding all
required packages in Linux:

	sudo apt install build-essential libncurses-dev srecord

Since there are many variants and releases of Linux, it is difficult
to ensure the build will work in all cases.  The current stable
release of Ubuntu is used to verify the build runs.

MacOS Build System Requirements
-------------------------------

You will need to install the srecord package to complete the
build process:

	brew install srecord

You may encounter a failure reading or writing files. This is caused by 
protection features in MacOS (at least, in Catalina) that prevent 
programs built on your local system (unsigned) from running.  To 
disable this feature:

1) Make sure you exit System Preferences.
2) Open a terminal session and type the following.  You will need to
   authenticate with an admin account: sudo spctl --master-disable
3) Exit terminal
4) Go into System Preferences and choose Security and Privacy
5) Select the General tab if it isn't already selected
6) You should now see a third selection under
   "Allow apps downloaded from:" of Anywhere - select this.
7) Now you can run the build successfully.

DISCLAIMER: You do this at your own risk.  I highly recommend that you
return the settings back to normal immediately after doing a build.

Process Overview
----------------

The basic steps to create a custom ROM are:

  1) Create/update configuration file (optional).

  2) Update/Add/Delete any files as desired to customize the disk
     images (optional).

  3) Run the build scripts and confirm there are no errors.

  4) Program the resultant ROM image and/or write thedisk images.

Note that steps 1 and 2 are performed to customize your ROM as 
desired.  If you want to simply build a standard configuration, it is 
*not* necessary to perform steps 1 or 2 before running a build.  In 
fact, I strongly recommend that you skip steps 1 and 2 initially and 
just perform perform steps 3 and 4 using the standard configuration to 
make sure that you have no issues building and programming a ROM that 
works the same as a pre-built ROM.

Each of the 4 steps above is described in more detail below.

1. Create/Update Configuration File
-----------------------------------

The options for a build are primarily controlled by a configuration 
file that is included in the build process.

RomWBW uses cascading configuration files as indicated below:

cfg_MASTER.asm				- MASTER: CONFIGURATION FILE DEFINES ALL POSSIBLE ROMWBW SETTINGS
|
+-> cfg_<platform>.asm			- PLATFORM: DEFAULT SETTINGS FOR SPECIFIC PLATFORM
    |
    +-> Config/<plt>_std.asm		- BUILD: SETTINGS FOR EACH OFFICIAL DIST BUILD
        |
        +-> Config/<plt>_<cust>.asm	- USER: CUSTOM USER BUILD SETTINGS

The top (master configuration) file defines all possible RomWBW
configuration settings. Each file below the master configuration file
inherits the cumulative settings of the files above it and may
override these settings as desired.

Other than the top master file, each file must "#INCLUDE" its parent 
file.  The top two files should not be modified.  To customize your 
build settings you should modify the default build settings 
(config/<platform>_std.asm) or preferably create an optional custom 
user settings file that includes the default build settings file (see 
example Config/SBC_user.asm).

By creating a custom user settings file, you are less likely to be
impacted by future changes because you will only be inheriting most
of your settings which will be updated by authors as RomWBW evolves.

RomWBW uses the concept of a "platform" and "configuration" to
define the settings for a build.  Platform refers to one of the core
systems supported.  Configuration refers to the settings that
customize the build.  The configuration is modifies the platform
defaults as desired.

The platform names are predefined.  Refer to the following table 
to determine the <plt> component of the configuration filename:

	SBC		Z80 SBC (v1 or v2) w/ ECB interface
	ZETA		Standalone Z80 SBC w/ SBC compatibility
	ZETA2		Second version of ZETA with enhanced memory bank switching
	N8		MSX-ish Z180 SBC w/ onboard video and sound
	MK4		Mark IV Z180 based SBC w/ ECB interface
	UNA		Any Z80/Z180 computer with UNA BIOS
	RCZ80		RCBUS based system with 512K banked RAM/ROM card
	RCZ180		RCBUS based system with Z180 CPU
	EZZ80		Easy Z80, Z80 SBC w/ RCBUS and CTC
	SCZ180		Steve Cousins Z180 based system
	DYNO		Steve Garcia's Dyno Micro-ATX Motherboard
	RCZ280		Z280 CPU on RCBUS or ZZ80MB
	MBC		Andrew Lynch's Multi Board Computer
	RPH		Andrew Lynch's RHYOPHYRE Graphics Computer
	Z80RETRO	Peter Wilson's Z80-Retro Computer
	S100		S100 Computers Z180-based System
	DUO		Andrew Lynch's Duodyne Computer
	HEATH		Les Bird's Heath Z80 Board
	EPITX		Alan Cox' Mini-ITX System
	MON		Jacques Pelletier's Monsputer
	GMZ180		Doug Jacksons' Genesis Z180 System
	NABU		NABU w/ Les Bird's RomWBW Option Board
	FZ80		S100 Computers FPGA Z80

Configuration files are found in the Source\HBIOS\Config 
directory.  If you look in the this directory, you will see a 
series of files named <plt>_<cfg>.asm.  By convention, all
configuration files start with the platform identifier followed
by an underscore.  You will see later that the build process does
require this naming convention and it allows you to easily see which
configuration files apply to each of the platforms supported.

Each of the possible platforms has at least one configuration file.  In 
many cases, there will be a standard ("std") configuration for the 
platform.  For example, there is a file called MK4_std.asm.  This is 
the standard ("std") configuration for a Mark IV CPU board.

The <cfg> portion of the filename can be anything desired.  To create
your own custom configuration, you can modify an existing configuration
file or (preferably), you could copy an existing configuration file
to a new name of your choosing and make your changes there.  For
example, you could copy "MK4_std.asm" to something like "MK4_cust.asm".
Now, you can make changes to your private copy of the configuration
and easily revert back to the original if you have problems.

It is important to understand how configuration files are processed.
They start by inheriting all of the default settings for the
platform.  This is accomplished via the "#INCLUDE" directive near
the top of the file.  For the "MK4_std.asm" configuration file,
this line reads:

#INCLUDE "cfg_MK4.asm"

When the configuration file (MK4_std.asm) is processed, it will first
read in all the default platform settings from "cfg_MK4.asm".  All of
the platform default configuration files are found in the parent
directory (the HBIOS directory).  You will see a "cfg_<plt>.asm" for
each platform in the parent directory.

If you look at the platform configuration file, you will see that it
has many more settings than you found in the build configuration file.
The platform configuration file contains *all* possible settings for
the platform and defines their default value.  The settings in the
build configuration file just override the platform default settings.

Note that the settings in the platform configuration file are all
defined using ".EQU" whereas the build configuration file uses ".SET".
This is because ".EQU" defines the initial value for a variable and
".SET" modifies a pre-existing value.  You *must* use ".EQU" and ".SET"
correctly or the assembler will complain very loudly.

In our example, let's say you have added a DiskIO V3 board to your 
Mark IV system and want to include floppy support. You will see a 
couple lines similar to these in the config file:

FDENABLE	.SET	TRUE		; FD: ENABLE FLOPPY DISK DRIVER (FD.ASM)
FDMODE		.SET	FDMODE_DIDE	; FD: DRIVER MODE: FDMODE_[DIO|ZETA|ZETA2|DIDE|N8|DIO3|RCSMC|RCWDC|DYNO|EPWDC]

FDENABLE is already set to TRUE, so that is fine.  However, FDMODE
is not correct because it specifies a different board.  To fix this,
just modify the line to read:

FDMODE		.SET	FDMODE_DIO3	; FD: DRIVER MODE: FDMODE_[DIO|ZETA|ZETA2|DIDE|N8|DIO3|RCSMC|RCWDC|DYNO|EPWDC]

You are now probably wondering where to find detailed instructions for 
each of the configuration settings.  Sadly, this is an area where 
RomWBW is very deficient.  The changes to hardware support happen so 
fast that is have been virtually impossible to create such a document. 
If it is not obvious what you need to do when looking at the build 
configuration file, I recommend that you look at the platform 
configuration file in the parent directory.  It will contain all of the 
possible settings and their default values as well as a brief comment.  
In many cases this is enough information to figure out what to do.  If 
not, you will need to either look at the HBIOS source code or request 
help in any of the RomWBW support communities (people are typically 
very helpful).  You can also post questions or issues on the GitHub 
repository.

2. Update/Add/Delete Disk Files
-------------------------------

A major part of the RomWBW build process is the creation of the
ROM disk contents and the floppy/hard disk image files.

The files that are included on the ROM Disk of your ROM are copied 
from a set of directories during the build process.  This allows 
you to have complete flexibility over the files you want included 
in your ROM.

The ROM disk process starts in the Source/RomDsk directory.  Within
that directory, there are subdirectories for each of the different
possible ROM sizes that can be created.  The vast majority of all
ROMs are 512KB, so you will probably be interested primarily in the
ROM_512KB subdirectory.

These subdirectories are already populated in the distribution.  You do 
not need to do anything unless you want to change the files that are 
included on your ROM Disk.

In summary, the ROM Disk embedded in the ROM firmware you build, 
will include the files from the ROM_512KB directory (or the 
ROM_1024KB directory if building a 1024KB firmware, etc.).  

There is a ReadMe.txt document in the \Source\RomDsk directory 
with a more detailed description of this process.

Note that the standard 512K ROM disk is almost full.  So, if
you want to add files to it, you will need to delete other files
to free up some space.

Creation of the floppy/hard disk images is similar, but these
images are much larger and have many more files.  Additionally, the
process pulls in files from multiple places and creates multiple
formats.  The Source/Images directory of the distribution handles
the creations of these disk images.  There is a ReadMe.txt file there
that describes the process and how to customize your disk images.

3. Run the Build Process
------------------------

Regardless of whether you are using Windows, Linux, or MacOS to perform
the build, you will initiate the build at a command prompt.  So, you
start by starting a command window/terminal.  Make sure your
command prompt has the root "RomWBW" directory as the default.

For a Windows computer, the build is initiated by simply running the
command "Build".  To delete all files created during a build process,
use the "Clean" command.  I recommend doing this before each build.  It
will operate recursively on all directories.

For Linux or MacOS, you will use the command "make".  To delete all
files created during a prior build run, use the command "make clean".
I strongly recommend doing this before each build.

This will launch the build process for a complete RomWBW build including
ROM and disk images.  Some of the output may be confusing, so a sample
normal build run called Sample_Build.log is included in the Source directory.
The sample build is from a typical build run under Windows.

At a point in the middle of the build, you will be prompted to choose
the specific platform and configuration for your ROM.  For platform, be
sure to enter the platform identifier that corresponds to the ROM you
are creating.  The prompt will look something like this:

    Platform [SBC|MBC|ZETA|ZETA2|RCZ80|EZZ80|UNA|N8|MK4|RCZ180|SCZ180|DYNO|RCZ280]:

You will subsequently be prompted for the specific configuration that
you want to build.  It will display the available possibilities based
on the platform you previously chose.  Notice that you are choosing
the portion of the configuration filename that follows the platform
id:

    Configurations available:
     > std
     > cust
    Configuration:

Enter one of the configuration options to build a ROM with the 
associated config file.

At this point, the build should continue and you will see output 
related to the assembler runs and some utility invocations.  Just 
review the output for any obvious errors.  Normally, all errors 
will cause the build to stop immediately and display an error 
message in red.

You will see some lines in the output indicating the amount of 
space various components have taken.  You should check these to 
make sure you do not see any negative numbers which would indicate 
that you have included too many features/drivers for the available 
memory space.  Here are examples of the lines showing the space 
used:

    HBIOS PROXY STACK space: 38 bytes.
    HBIOS INT space remaining: 82 bytes.
    DSRTC occupies 423 bytes.
    UART occupies 716 bytes.
    ASCI occupies 580 bytes.
    MD occupies 451 bytes.
    IDE occupies 1276 bytes.
    SD occupies 2191 bytes.
    HBIOS space remaining: 21434 bytes.

At the completion of the build process, you will find the resultant
ROM and disk image files in the Binary directory.  

There will be many disk image (".img") files created.  These are 
described in the RomWBW User Guide document.  Since RomWBW
encapsulates all hardware interface code in the ROM itself, the
disk image files are generic for all ROMs.  The only reason they
are built is to accommodate any disk content changes you may have
made.

4. Deploy the ROM
-----------------

Upon completion of a successful build, you should find the 
resulting firmware in the Binary directory.  The ROM file
will be called <plt>_<cfg>.rom matching the platform identifier
and configuration you chose.

Three output files will be created for a single build:

     <plt>_<cfg>.rom -	binary ROM image to burn to EEPROM
     <plt>_<cfg>.com -	executable version of the system image
			that can be copied via X-Modem to a
			running system to test the build
     <plt>_<cfg>.upd -	partial ROM image containing just the
			first 128KB which can be used to update
			only the "code" portion of your ROM
			and not modify the ROM disk

The actual ROM image is the file ending in .rom.  It will normally be 
512KB.  Simply burn the .rom image to your ROM and install 
it in your hardware.  The process for programming your ROM depends 
on your hardware, but the .rom file is in a pure binary format (it 
is not hex encoded).

You can alternatively reprogram your ROM in-situ (most hardware
supports this) using the FLASH application included with RomWBW.  This
is described in the "Upgrading" section of the RomWBW User Guide.

Refer to the document ReadMe.txt in the Binary directory for more 
information on the other two file extensions created.

Specifying Build Options on Command Line
----------------------------------------

If you are repeatedly running the build process, you may prefer to
specify the platform and configuration on the command line to avoid
being prompted each time.

Under Windows, you can specify the platform and configuration
like this:

    Build MK4 cust

Under Linux or MacOS, you can do the same thing like this:

    make ROM_PLATFORM=MK4 ROM_CONFIG=cust

In this case, you will not be prompted.  This is useful if you wish 
to automate your build process.

In the past, the size of the ROM could be specified as the third
parameter of the command.  This parameter is now deprecated and
the size of the ROM is specified in your configuration file
using the ROMSIZE variable.