Rom Filing System

Overview

RFS Monitor

If the Kuma 40/80 column upgrade or the Video Module is installed, typing 4 switches to 40‑column display and 8 switches to 80‑column display. In 80‑column mode the directory listing commands (IC / IR) display four columns.

Upgraded Applications

Sharp BASIC SA-5510

See SD Card Organisation below for the default drive layout.

Microsoft BASIC

• MS-BASIC(MZ-80A) — for original MZ-80A hardware, cassette storage only.
• MS-BASIC(RFS40) — RFS with 40‑column display; adds SD card, CLOAD, CSAVE, DIR.
• MS-BASIC(RFS80) — RFS with 80‑column display; adds SD card, CLOAD, CSAVE, DIR.

Each variant appears on the RFS ROM drive and SD drive. Consult the NASCOM Basic Manual for the full standard command set. The table below lists the extensions added for RFS.

NASCOM Cassette Image Converter

nasconv v1.0

Required:
  -i | --image  <file>   Cassette image file to convert.
  -o | --output <file>   Output file for converted BASIC data.

Options:
  -l | --loadaddr <addr> MZ-80A BASIC start address.
  -n | --nasaddr  <addr> Original NASCOM BASIC start address.
  -h | --help            Show this help.
  -v | --verbose         Verbose output.

Example:
  nasconv --image 3dnc.cas --output 3dnc.bas \
          --nasaddr 0x10fa --loadaddr 0x4341

BASIC MZ-5Z008 (Quick Disk)

BASIC MZ-2Z009E (Floppy Disk)

Software Architecture

Build System

Prerequisites

The GLASS Z80 assembler (glass.jar) is bundled in the tools/ directory — no separate installation is needed.

Automated setup and build (recommended)

macOS / Linux / WSL — setup_RFS.sh

chmod +x setup_RFS.sh
./setup_RFS.sh

Windows 10 / 11 — setup_RFS_windows_native.ps1 (recommended — native, no WSL). From a PowerShell prompt:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup_RFS_windows_native.ps1

The native script uses winget to install Git for Windows (which provides bash, coreutils, perl and curl) and a Temurin JRE (Java, for the GLASS assembler), clones the repo, fetches the content bundle, and runs ./build.sh through Git Bash — with no WSL, Docker or reboot required. The RFS build needs no C compiler on Windows because two prebuilt host tools (tools/cpmcp.exe and tools/sdtool.exe) are bundled.

Windows 10 / 11 — setup_RFS_windows.ps1 (alternative — builds inside WSL2 / Ubuntu). From an Administrator PowerShell:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup_RFS_windows.ps1

This WSL variant installs WSL2 + Ubuntu if they are not already present (a one-time reboot is needed — reboot, launch Ubuntu once from the Start Menu to create your Linux username/password, then re-run the script), then runs setup_RFS.sh inside Ubuntu. Prefer the native script above unless you specifically want a WSL environment.

Questions the setup asks, and what to do

Every prompt has a safe default shown in brackets — the capital letter is the default, so pressing Enter accepts it. The prompts appear in this order:

Windows only (in PowerShell, before the Linux setup runs):

macOS / Linux / WSL (in the Linux / Ubuntu shell):

You may also be prompted for your sudo password (package install) and your git credentials if you chose a private repository.

After setup — building again

When setup finishes it prints the checkout path. To rebuild later:

cd ~/RFS                 # or the directory you chose
source ./rfs_env.sh      # macOS only (adds GNU coreutils + the JRE to PATH); harmless elsewhere
./build.sh -m            # FIRST build: process MZF -> MZB, then build everything
./build.sh               # subsequent builds (re-run -m only when MZF sources change)
./build.sh -h            # list variants and options

On Windows, open the Ubuntu terminal (Start Menu → “Ubuntu”, or type wsl in PowerShell) and run the same commands inside ~/RFS. The ROM images appear in ~/RFS/roms.

build.sh builds all hardware variants by default; pass one or more variant names (sfd700, romdisk_mz80a, picoz80_mz80a, picoz80_kuma, picoz80_mz700, picoz80_mz1500, picoz80_mz80k, or all) to build only those. Selecting a variant configures everything automatically — no source edits needed. Options: -m (process MZF), -s (skip shared assembly), -c (clean), -v (verbose), -h (help).

Advanced: build target flags

For most builds you do not need this section — selecting a variant with build.sh (above) configures everything automatically. The underlying mechanism is a set of flags in asm/include/rfs_definitions.asm; exactly one of the following is set to 1 (all others 0) for a given target, which build.sh does for you per variant. Edit them by hand only for a custom configuration:

Additional optional flags in the same file:

Manual build and what build.sh does

If you prefer not to use the setup script (or are scripting a CI build), you can clone and build directly — you must still have the prerequisites installed and, on a fresh standalone clone, fetch the content images yourself (or run setup_RFS.sh, which does it for you):

git clone --recurse-submodules https://git.eaw.app/eaw/RFS.git
cd RFS

# Full build (assembles all ROMs, packages ROM images, builds SD card image):
./build.sh

# Full build including re-processing all MZF application files
# (only needed when MZF source files in MZF/ have changed):
./build.sh -m

build.sh performs the following steps in order:

1. Compiles cpmtools from source (first run only) and adds the result to PATH.
2. tools/assemble_rfs.sh — assembles rfs.asm and rfs_mrom.asm into roms/rfs.rom and roms/rfs_mrom.rom.
3. tools/assemble_cpm.sh — assembles the CP/M 2.2 CBIOS (cbios.asm, cbios_bank1–4.asm, cpm22.asm) into roms/*.rom.
4. tools/assemble_roms.sh — assembles all monitor variants (SA-1510, 80c SA-1510, 1Z-013A, hi-load variants, Kuma version, IPL) and MZF application files (SA-5510, MS-BASIC variants, etc.) into roms/ and MZB/.
5. tools/make_roms.sh — packages the assembled ROMs and MZF applications into Flash ROM images (see Output Files below).
6. tools/make_cpmdisks.sh — builds CP/M disk images in RAW and CPC Extended Disk Format for each of the pre-populated CP/M drive sets.
7. tools/make_sdcard.sh — assembles the final SD card image combining 10 RFS drive images and 7 CP/M disk images.

The individual scripts can also be run directly from within the tools/ directory for partial rebuilds.

Output Files

After a successful build the roms/ directory contains:

Programming the Flash ROMs

The ROM images are written to SST39SF040 (512 KB) Flash RAM chips using a TL866 or compatible programmer:

# Monitor ROM (RomDisk build):
minipro --infoic /path/to/minipro/infoic.xml -p SST39SF040 -s -w roms/MROM_ROMDISK_256.bin

# User ROM 1:
minipro --infoic /path/to/minipro/infoic.xml -p SST39SF040 -s -w roms/USER_ROM_256.bin

# SFD-700:
minipro --infoic /path/to/minipro/infoic.xml -p SST39SF040 -s -w roms/SFD700_256.bin

Writing the SD Card Image

Write the combined SD card image directly to the SD card using dd:

# Replace /dev/sdX with your SD card device:
dd if=roms/SHARP_MZ80A_RFS_CPM_IMAGE_1.img of=/dev/sdX bs=512
sync

No partitioning is required. The SDCFS image begins at sector 0. Insert the SD card into the reader on the RomDisk board.

Adding Applications to the ROM Drives

Applications stored in the Flash ROM drives must first be converted from MZF format into sector-padded binary images. Place the MZF files in the appropriate subdirectory under MZF/ and run:

tools/processMZFfiles.sh

This converts all MZF files into 128-byte and 256-byte sector-padded images stored in MZB/. They are then picked up automatically by make_roms.sh.

To choose which applications appear in each ROM drive, edit tools/make_roms.sh and adjust the addMZFToROMImageList calls. Each call takes four flags (include in ROMDISK build, include in SFD700 build, include in picoZ80 build, reserved) and the path to the sectored binary:

# Format:
#   addMZFToROMImageList  <ROMDISK>  <SFD700>  <picoZ80>  <reserved>  "<MZB path>"
#
# Example — include in all builds:
addMZFToROMImageList 1 1 1 0 "${MZB_PATH}/Common/sa-5510_rfs.${SECTORSIZE}.bin"

# Example — RomDisk and picoZ80 only:
addMZFToROMImageList 1 0 1 0 "${MZB_PATH}/MZ-80A/defender.${SECTORSIZE}.bin"

Applications are packed in the order listed, filling User ROM 1 first, then User ROM 2 and 3. Place applications you always want available at the top of the list.

Build Tools Reference

SD Card Filing System

SDCFS Structure

Each file block is a fixed 64 KB, matching the maximum CMT (tape) block size. This keeps the layout simple and allows files to be read or written exactly as if they were on tape, enabling transparent SD↔CMT copy operations.

SD Card Layout

ADDRESS    SECTOR   CONTENT
00000000   00000  ┌─────────────────────────────────────────────────────────────┐
                  │  RFS DRIVE 0                                                │
00000000   00000  │  Directory entry 000 (32 bytes)                             │
                  │  ...                                                        │
00001FE0   0000F  │  Directory entry 255 (32 bytes)                             │
00002000   00010  │  File block 0     (64 KB)                                   │
                  │  ...                                                        │
00FF2000   7FF90  │  File block 255   (64 KB)                                   │
01001FFF   8000F  └─────────────────────────────────────────────────────────────┘
                  ...  (RFS drives 1–8 follow the same pattern)
09012000   48090  ┌─────────────────────────────────────────────────────────────┐
                  │  RFS DRIVE 9                                                │
0A013FFF   5009F  └─────────────────────────────────────────────────────────────┘
                  ... padding to 256 MB boundary ...
10000000   80000  ┌─────────────────────────────────────────────────────────────┐
                  │  CP/M DISK IMAGE 0   (16 MB, 32 sectors × 1024 tracks)     │
11000000   88000  ├─────────────────────────────────────────────────────────────┤
                  │  CP/M DISK IMAGE 1                                          │
                  │  ...                                                        │
XX000000          │  CP/M DISK IMAGE n                                          │
                  └─────────────────────────────────────────────────────────────┘

SD Card Organisation

The SD card image built by the repository tools is pre-populated as follows:

Manuals

Credits

Licenses

The Gnu Public License v3