o65 6502 binary relocation format v1.3

• Current Version
• Example Code
• o65 Next Generation
• Distribution
• Current uses
• Disclaimer

The current version is version 1.3 in fileformat.html

The change from version 1.2 are an upward compatible change in the mode bits, more os types, and better explanations.

The change from the version 1.1 is that the undefined reference relocation entry for high-byte relocation has changed.

In the file libloader.a65 is a sample loader for the o65 file format in 6502 assembler. It is taken from the OS/A65 lib6502 code. It does not use the simple file format (as described by mode.11), but computes the relocation differences for each segment separately. What it does, however, is late binding of the OSA2KERNEL and lib6502 variables, as well as looking for the main exported label to start the program.

A simpler version (without undefined references and without late binding) comes with the xa assembler and you can find it in loader.a65. It also has a sample C64 binding.

The code is not cleared from debug statements and lacks comments. Wear your hard hat.

Due to some requests to support other CPUs and "larger" systems, I have made an attempt to define a new, "v2" version of the o65 file format. It is far from complete, and open for discussion. You can find the working draft in fileformatng.html.

The file format extension o65 for a 6502 relocatable file format is copyrighted by me. It may be used by systems and applications without restriction, as long as the files named with this extension obey the definitions stated in this document.

The o65 file format is currently used in the following systems:

• GeckOS/A65 operating system: o65 is the main file format for the GeckOS operating system for executables.
  It uses late binding to insert the kernel jumptable address as well as the lib6502 jumptable address into the executable at load time. Also it searches the (optional) "main" label to start the executable. Name lengths can be arbitrary as they are not stored, name encoding is ASCII. Currently the simple file format is not required, the loader can handle arbitrary segment addresses.
• Lunix operating system uses the cc65 toolchain to produce o65 as executable file format.
• CC65: o65 is used for two purposes in the 6502 C compiler:
  • Loadable modules (can be viewed either as "executables" or as "overlays").
  • ld65 can also generate executable programs in o65 format for use with other operating systems. Currently this is in experimental use in Lunix (as far as I know).
  The format is currently used for 6502/C02. The cc65 module loader expects the simple format. The linker is able to generate other formats as well. cc65 itself (that is: the library) won't use exports and imports. o65 is not used as an object code format. Because of its simplicity (which, as said before, is also its advantage) it is missing features for this purpose.
• opencbm floppy modules: The opencbm API (cbm4win, cbm4linux) will (work in progress) use the o65 file format for modules to load into floppy. The API itself loads o65 files to account for the differences between the various floppy drives (1540/1541, 1570/1571, 1581), and to present the API user transfer protocols for its use. The API user loads additional modules into the floppy drives which then use late binding to connect to the various support routines of the floppy ROM, or of the transfer protocols. Name encoding is ASCII. Currently, the simple file format is not required (but there is no definitive decision about this yet).
• The Contiki Operating System uses o65 as format for its 6502 program executables.
• A Free SNES assembler uses o65 as output file format for the 65816 files.
• The WiNGs operating system use the o65 file format for its binaries.
• Other projects use the o65 file format for own experimentation, even for such CPUs as Z80 and 80286!