Unified Emulator Format

Before the development of the UEF, archives of Acorn computer software on the World Wide Web had adopted a convention of hosting ZIP archives of the raw files on a tape, each raw file accompanied by a sidecar file, with extension .inf, carrying the load and execution addresses from the file header. The INF convention, described and implemented by Wouter Scholten in bbcim (1995), extends the output format of the *INFO command (built into Acorn DFS and ADFS, which lists file lengths and other metadata attached to files on disc[5]) to cover CRCs and the order of files on tape.[6] While it works adequately for storing user files, it does not preserve the baud rate of the recording, precise timing information or the non-standard data streams used in copy protected titles.

In the case of disc-based software, it became increasingly convenient to send a sector dump of the disc instead, and by the time of the UEF's introduction the file extensions .ssd and .dsd were already established for single-sided and double-sided raw images of DFS discs, respectively. Distributed bare or in a ZIP archive, they remain popular on archive sites.

In a 2010 post to the Stardot forum, Harte explained at length his reasons for creating the format: being the first to address emulation of the Acorn Electron and its primary medium, tape, Harte wanted a fine-grained and technically optimal representation of media, compared to existing ad hoc formats; and to package the multiple media elements of a software release into a single file, so that downloading a UEF is "more like obtaining the original product".[7] He went on to observe that it was the tools in use, and "user need", that determined the actual uses to which the UEF had been put.

A UEF file consists of a fixed length header that identifies itself, followed by a linked list of chunks containing the data of interest. The header comprises the magic string UEF File!, a terminating null character, and the two-byte version number of the UEF specification in use. A reading application needs to pay attention to the version number, as the unit of measurement in some chunks differs according to the specification version, and one chunk has been redefined between versions.

Each chunk consists of a two-byte ID which determines its meaning, the length of the body in four bytes, and the body itself. An application can readily skip the bodies of chunks it does not need to process. After the last chunk the file simply ends. Currently, UEF chunks do not nest.

The whole UEF file, including the header, may optionally be compressed in gzip format. By examining the start of the file for a gzip or UEF header, a decompression library can be invoked as appropriate.

The Unified Emulator Format models software on cassette as a contiguous sequence of segments, which may be carrier tones, the modulated asynchronous signals of ordinary data blocks, security cycles (modulated synchronous signals, said to be an "identification feature"[3]) or gaps where no recognised signal is present. Tape UEF chunks are concatenated in the order they appear, to build up the representation of a whole recording. When generated from a real source tape, each waveform on the tape corresponds directly to a tape chunk, such that the source can be accurately reconstructed (with any non-encodable signals replaced by gaps of equal length.)

Standard Acorn streams (chunk ID: 0x0100) are encoded so that their bytes reappear in the UEF chunk body. From version 0.10, direct support is extended to all asynchronous formats (0x0104) including the 8,N,2 format of BASICODE. Otherwise there is a generic chunk (0x0102) to accommodate any arbitrary sequence of bits. Security wave chunks (0x0114) also carry bit streams, encoded in a different form to allow the half-length one bits observed in commercial recordings to be represented.

There are some modal variables affecting the interpretation of these chunks: the baud rate, 1200 baud for Acorn signals or 300 baud for KCS; the exact carrier frequency, which determines the playing time of the reconstructed tape; and the phase of the signal. The latter two may change within a published recording, and their absolute values depend on the tape player, amplifier and sound card used to digitise the signal.[8]

A UEF file can contain markers to separate the tapes of a multiple-tape distribution, and the sides of each tape; positions of interest within each side can also be marked.

Discs are stored as raw sector dumps of each surface, along with their geometry and a byte identifying the file system. Previous versions of the specification had provisions to encode discs at the byte stream level, or the magnetic domain level. With SSD and DSD sector dumps serving standard BBC discs well, and the mature FDI format catering for copy-protected software, the disc image function of UEF is little used.

Sideways ROMs are likewise stored as raw data, plus an indication of their purpose and a ROM slot recommendation. Again the user base prefers bare ROM dumps for archival.

State snapshot UEF files include standardised chunks to store the major portions of an Acorn Electron or BBC Micro's state: main, shadow and expansion bus memory, the CPU and the WD1770 floppy drive controller; also the Electron ULA and the Slogger Master RAM Board, a common Electron add-on. A patch memory chunk rewrites a block of memory at any address, allowing the UEF format to package pokes. To store state elements not accommodated in the standard chunks, emulators can define their own chunks. A private use area of chunk IDs is reserved for this or any other purpose, although some emulators save state under invalid chunk IDs in the public space.

Multiplexed data is an extension for emulators, used by ElectrEm but without a published specification:[3]

Bit multiplexing supplies the emulator with additional information so that old programs may be run to produce a greater quality of output. This feature is really only for emulation use of UEF files and ignoring bit multiplexing will have no effect on the accuracy of your tool to original hardware.

— Thomas Harte, UEF File Format Specs 0.10 (document draft 28)

One salient application mentioned by Harte is to superimpose "new graphics on old games",[9] and a single example, a 256-colour enhanced Daredevil Dennis, is available from StairwayToHell.com to run in ElectrEm.

Multiplexed data chunks are intended to follow ordinary data chunks in any of the above classes, supplementing the data. Their contents are not meant to be visible to the Acorn computer, whether real or emulated, but otherwise their meaning has not been specified.

Chunks providing content information include the file origin chunk, which identifies the application that generated the UEF file. Inlay scan chunks, intended as a file preview, hold a raw bitmap of the cover art although anything beyond a thumbnail can take up more data than a typical game. The UEF author can also provide the text of an instruction booklet or a URL for more information, a short title for display, minimum machine specification and keyboard mapping for the enclosed software; and where a game does not use the whole screen, the coordinates of the visible area can be given. A minority of UEF files available online contain anything in this class but an origin chunk.

A UEF file can contain multiple classes of data at once, as Harte intended;[7] it is not possible to know which classes it contains without scanning the whole file. In its file selection box ElectrEm displays an icon according to the first data class chunk it finds.

• Specifications document