# WLA DX: one assembler for twenty retro processors

> WLA DX is a cross assembler package that compiles assembly for twenty old processor families, from the Z80 and the 6502 to the SuperFX, and it is unusual in letting you define your own memory map rather than assuming a console.

**vhelin/wla-dx** — WLA DX - Yet Another ANSI C GB-Z80/Z80/Z80N/eZ80/6502/65C02/65CE02/65816/68000/6800/6801/6809/8008/8080/HUC6280/SPC-700/SuperFX/Cx4/SH-2 Multi Platform Cross Assembler Package

- Repository: https://github.com/vhelin/wla-dx
- Stars: 611 · Forks: 103
- Language: C
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/vhelin-wla-dx

## The design decision: you define the memory map

WLA DX is a set of tools to assemble assembly files to object or library files with wla-ARCH, and to link them together with wlalink. The sentence that explains the project is the one about not being bound to one system. WLA DX is not tied to a single machine, such as the NES or the C64, but instead lets you define your own memory map, and that map is meant to be shared across all the object and library files you assemble. This is the difference between a cross assembler and a console development kit. A kit hard-codes the ROM layout, the address of the interrupt vectors and the bank switching scheme of one machine, and the moment you want to target anything else you are writing a new tool. A tool that takes a memory map as input is a general instrument, and the console kits become configurations of it.

## Twenty processor families, one syntax

The supported architecture list is the honest measure of what the project covers. It spans the Z80, Z80N, eZ80, GB (GB-Z80) and Cx4 on the Z80 side, the 6502, 65C02, 65CE02 and 65816 on the MOS side, the 68000, 6800, 6801 and 6809 on the Motorola side, the 8008 and 8080 on the Intel side, and the HuC6280, SH-2, CP1610, SPC700 and SuperFX. The repository layout shows how that is implemented, with one C file per architecture, such as iz80.c, iez80.c, igb.c, icx4.c, i6502.c, i65c02.c, i65ce02.c, i65816.c, i6800.c, i68000.c, i6801.c, i6809.c, i8008.c, i8080.c, ihuc6280.c, ish2.c, ispc700.c and isuperfx.c, alongside a shared include.c, decode.c, listfile.c and a hashmap.c. The instruction table is generated, with an instruction_table_generator/ directory in the tree, which is how twenty instruction sets stay consistent with one parser. A new processor means a new source file, and that is manual work rather than a plugin, which is the main thing to understand about extending it.

## Building it from source

The overview points at the INSTALL file for the detailed instructions and gives the short version. You need CMake, at least version 2.8.12, an ANSI C compiler, and optionally Sphinx, minimum version 1.2.0 with 1.6.0 recommended, to generate the documentation. The sequence is a clone of the repository, a change into the wla-dx directory, a build directory created with mkdir build and a change into it, cmake .. to generate the build system, cmake --build . --config Release to compile, and finally cmake -P cmake_install.cmake to install it, which is optional. If you didn't install it, you can still access the binaries in the binaries folder, and that folder also contains the compiled documentation in the doc subfolder, so a quick look at the tool needs no compiler at all. The install prefix can be set with a CMAKE_INSTALL_PREFIX argument passed to the configure step or the install step, before the -P.

## CI across eight configurations, sanitizers included

The build badges tell you how seriously the project takes regressions, and the list of Azure Pipelines configurations is unusually broad. There is a Linux Sanitizers run using ASan, UBSan and MSan, a Windows MSVC run, a Windows Clang run, a Windows XP 32-bit run, a macOS GCC run, a macOS Clang run, a Linux GCC run and a Linux Clang run, with a matching azure-pipelines-*.yml file at the repository root for each. Running the same assembler under ASan, UBSan and MSan is the part worth noting, because an assembler that reads untrusted or malformed input is exactly the kind of program where memory errors hide, and MSan in particular catches reads of uninitialised memory that no functional test would ever surface. The Windows XP 32-bit configuration is the other interesting one, since it keeps the oldest supported toolchain in the build matrix. The project is under active development with a last push on 2026-10-07, and the release history shows v10.7 on 2026-06-28 after v10.6 in November 2023.

## The examples show what a memory map looks like in practice

The examples directory is the best documentation in the repository, and it is organised by machine rather than by feature. There are worked examples for the Intellivision, the Lynx, the Mega Drive, the Neo Geo, the NES, the PC Engine and the SH-2. That set of targets tells you what the tool is actually used for. The Intellivision and the PC Engine are not platforms with a maintained modern toolchain, so a homebrew developer for those has to build their own assembler or use an old one, and WLA DX fills that gap. The NES, the Mega Drive and the Neo Geo have community toolchains, and the presence of examples for them means the tool is being used where alternatives exist, presumably for the shared syntax and the map definition. The project also keeps a historical/ directory and a FILE_FORMATS file at the root, which documents the object and library file formats the assembler and linker agree on, plus a byte_tester/ directory and a display_statistics/ directory for the tool's own checks and output.

## Where WLA DX is the wrong tool

Two boundaries make this the wrong choice. The first is that it is a native-code C program with a C build system, not a modern managed toolchain, so if your workflow expects a language-agnostic build with dependency locking, reproducible environments and a package index, you will be assembling it yourself and carrying that burden. The second is scope in the other direction. The architecture list stops at the processors of the 1980s and early 1990s, and the SuperFX, the Cx4 and the SPC700 are the newest things in it. If you are targeting anything from the last thirty years, this is the wrong tool, and the modern vendor toolchains for ARM, RISC-V or x86 will serve you better. There is also a licensing point to check before you embed it in a commercial product. The project states that WLA DX is GPL-2.0-or-later software, with the file LICENSE and the SPDX identifier given, which is fine for a hobbyist toolchain and a constraint for a shipped SDK.

## Conclusion

WLA DX fits a retro homebrew developer who has to target more than one processor family, because the same assembler, the same syntax and the same linker cover Z80, 6502, 65816, 68000 and the rest, and it fits anyone who wants a memory map they define rather than one baked in by the tool, which is what makes it usable for consoles and home computers nobody has a modern toolchain for. It does not fit a developer who wants a modern managed toolchain, since the project is a C program with a Make-era feel and a hand-written file format, and it does not fit someone who needs the tool to keep up with a new processor, because each architecture has its own source file in the repository and adding one is a manual job. Before you build it, read the INSTALL file, since the six-step build in the overview is the short version, and check the examples directory for the machine you are targeting, because the project ships worked examples for the NES, the Intellivision, the Lynx, the Mega Drive, the Neo Geo, the PC Engine and the SH-2.

## FAQ

### What is WLA DX and what does it do?

It is a cross assembler package that assembles files to object or library files with wla-ARCH and links them together with wlalink. It is not tied to one console, letting you define your own memory map that is shared across all the object and library files.

### Which processors does WLA DX support?

Twenty families: Z80, Z80N, eZ80, GB (GB-Z80), Cx4, 6502, 65C02, 65CE02, 65816, 68000, 6800, 6801, 6809, 8008, 8080, HuC6280, SH-2, CP1610, SPC700 and SuperFX. The repository holds one C source file per architecture.

### How do I build WLA DX from source?

You need CMake at least v2.8.12, an ANSI C compiler and optionally Sphinx for the documentation. The overview gives the steps as git clone, a build directory, cmake .. to generate the build system, cmake --build . --config Release, and optionally cmake -P cmake_install.cmake to install, with the prefix settable through CMAKE_INSTALL_PREFIX.

### Does WLA DX have worked examples?

The repository ships examples for the Intellivision, the Lynx, the Mega Drive, the Neo Geo, the NES, the PC Engine and the SH-2, organised by machine. The built binaries and compiled documentation are also in the binaries folder, with the documentation in a doc subfolder.

## Sources

- [Issues](https://github.com/vhelin/wla-dx/issues)
- [README](https://github.com/vhelin/wla-dx/blob/master/README.md)
- [Releases](https://github.com/vhelin/wla-dx/releases)
- [vhelin/wla-dx on GitHub](https://github.com/vhelin/wla-dx)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vhelin-wla-dx