Disassembled NABU Stash
Collection of disassembled NABU software, such as the 8k and 4k ROMs, communication protocol, boot loader, and IOS. Please be courteous and credit authors for their effort if you build off what you learn from these verbose annotations.
NABU PC ROM (BIOS) Communication Protocol Definition
The NABU PC was designed to boot and load its software over a network instead of from local storage. To make that work, the computer communicates with an external network adapter using a small binary protocol over an I/O port. Even with a later-release ROM that included the option for disk booting, these facts remain. Through the network protocol, the PC asks the adapter if it’s present, requests status information, sends a user-defined channel number, sets up a download session, and then receives the operating system and application data in blocks.
In today's era, with cable networks no longer available, DJ has introduced the concept of an Internet Adapter (IA), and there are several others to choose from, each offering its own feature set. The NABU Internet Adapter emulates the NABU Network Adapter, allowing applications to be loaded from a PC onto the NABU.
Every part of the boot process depends on that exchange. If the adapter doesn’t respond with the right handshakes and markers, the NABU PC won’t load anything—there’s no disk fallback in the default 4k NABU ROM. That makes the protocol essential for anyone trying to emulate the adapter, build replacement hardware, archive the platform, or simply understand how the machine actually works at power-on.
The PDF below documents the entire communication protocol, based solely on how the NABU BIOS ROM behaves. Since no official modern documentation exists, this PDF fills a gap for developers, archivists, and hardware hobbyists who want to keep the NABU ecosystem alive. It defines each command, explains the handshakes, describes the block transfer format, and lays out how the PC expects the adapter to behave—making it possible to build fully compatible modern replacements.
Memory Map, ROM Shadowing, and Program Relocation
The NABU PC’s boot process is tightly constrained by how memory is mapped at power-on and how programs must relocate themselves after loading.
Summary Of This Section
On power-on, the NABU maps ROM from 0x0000 to 0x1000 (4096 bytes) so the Z80 can safely boot starting at 0x0. Any ram above the ROM is in an unknown state. The boot ROM downloads the program into RAM starting at 0x140D and executes from that location. If loading the main menu, 0x140d is not the final run address. The main menu includes a relocator that copies itself to upper RAM, moves the program down to its execution address (0x0100), then jumps to it. Relocators need extra free RAM because they must exist twice in memory while copying itself, which limits the maximum size of downloadable programs.
ROM Must Execute at Address 0x0000
When the NABU PC powers on, the state of RAM is undefined. Because of this, the CPU must begin execution from RAM at a known, stable address. The NABU hardware maps the boot ROM to address 0x0000, shadowing RAM at that location. Shadow ROM is enabled when the rom bit at Control Port 0x00 is not set (0). This guarantees that, on power-on, the first and subsequent instructions executed by the Z80 always come from ROM, since they are shadowed in RAM.
This ROM shadowing is critical:
* The CPU reset vector points to 0x0000
* RAM contents are unknown at power-on
* The ROM is shadowed over the RAM and must be visible at 0x0000, or the system cannot boot
Once the ROM has initialized the system and begun the network download process, control eventually transfers to code loaded into RAM, and the shadow ROM is disabled with the bit within the control port 0x00.
Boot Loader and Download Address (0x140D)
With the standard 4 KB NABU ROM (the default configuration used by essentially all systems), the built-in boot loader downloads the application program into RAM starting at:
0x140D
This address is not arbitrary. The ROM and boot loader occupy the lower memory region and require space for:
* ROM shadow mapping
* Boot protocol handling
* Download buffer logic
Because of this, downloaded programs cannot start at 0x0000 or 0x0100 directly. Instead, they are initially placed at 0x140D. If running the NABU Main Menu BootP, it is moved into the final execution location by a relocator routine included with the program (0x100).
Note: There exists an uncommon 8 KB ROM variant used in a few systems, but it is not relevant for standard NABU software and can be ignored for most practical purposes. However, if you wish to include a discussion of the 8K ROM, note that the available RAM will be 8K less than 64K, rather than 4K less.
Relocators and Upper Memory Usage
The NABU Main Menu program includes a relocator (named bootp). This is a small piece of code whose job is to:
1. Copy itself to the upper RAM
2. Copy the main program data to its final execution address (commonly 0x0100)
3. Transfer control to the relocated program
Note: Regarding the statement above, homebrew software will execute at 0x140d and does not relocate itself.
This relocation process of the bootp main menu allows the main menu to run from low memory even though it was initially downloaded into a higher temporary location.
Why Relocators Need Extra RAM
A relocator must keep its original code intact while it copies itself elsewhere. This means:
* The relocator must exist twice in memory at the same time during relocation
* Therefore, relocation requires 2× the size of the relocator code in free RAM
* This space must exist above the downloaded program
If there is not enough space at the top of RAM to hold the relocator and its temporary copy, relocation will fail.
Maximum Program Size Constraints
Because of ROM placement, download address, and relocation requirements, the maximum size of a downloadable program is constrained by memory layout.
At a high level, the usable memory range is: 0x140D → 0xFFFF
But this entire region is not available to the program itself, because space must be reserved for:
* The relocator
* The relocator’s temporary copy
* Stack usage during relocation
So in practice: Maximum Program Size
= (0xFFFF - 0x140D + 1)
- (Relocator Size × 2)
This means:
* Larger relocators reduce the maximum program size
* Programs that include complex loaders or overlays must be smaller
* Large applications must be split into multiple downloadable stages
Why This Design Exists
This memory layout reflects early 1980s design constraints:
* No disk storage
* Network-only booting
* Small ROM
* No guaranteed RAM state at power-on
* Programs written to be position-independent and relocatable
Understanding this layout is essential if you are:
* Writing your own NABU boot loaders
* Building custom downloadable applications
* Creating replacement network adapters
* Designing modern toolchains for NABU software development
0x000001 Boot Loader w/Main Menu
The ROM requests 0x000001 (also called main menu) from the cycle, which contains a position-independent, self-relocating bootloader (called bootp). The payload within the bootloader PAK contains the IOS (Input/Output System) and main menu. The bootloader can execute from different memory ; locations and dynamically relocates the IOS code before transferring control.