FM3 format

Parent Previous

FM3 format

The FM3 format is a simple extension of the FM2 format. FM2 files contain data which is needed for replaying the movie, and FM3 just adds Taseditor's working data to the end of FM2 file.

You can read full specifications of FM2 format in the FCEUX Help and on official site.

Every FM3 consists of 3 parts:


The Header is always in ASCII plain text format.

It consists of several key-value pairs (lines of text where all symbols before the first space separator are considered to be the keyword and all symbols after this separator are considered to be the text representation of the value).

Newlines may be \r\n or \n.

If a line starts from "|" (pipe), it means the end of Header and the beginning of Input Log.

The key-value pairs may be in any order, except that the first key must be version.

Value text is always terminated by a newline, which the value text does not include.

The value text is parsed differently depending on the keyword, it can be either integer or string.

Keys with integer value:

(also used for booleans, with a 1 for true and 0 for false)

(the value can be stored as int32)

Keys with string value:

(their values cannot contain newlines)

romFilename (required) – the name of the file used to record the movie

romChecksum (required) – the base64 of the hexified MD5 hash of the ROM which was used to record the movie

comment (optional) – simply a memo. By convention, the author of the movie should be stored in a comment with the subject "author". Example: "comment author AnS"

subtitle (optional) – a message that will be displayed on screen when movie is played back (unless Subtitles are turned off). Right after the word "subtitle" and following space separator there must be an integer value indicating the frame that the subtitle will be displayed.  Any remaining text after the integer and following space separator is considered to be the string displayed. Example: "subtitle 100 Level Two" – at frame 100 the words "Level Two" will be displayed on the screen

guid (required) – a unique identifier for a movie, generated when the movie is created. Meaningless in FM3, because all there's no external savestates associated with the project file.

Input Log

The Input Log section consists of movie records either in the form of text lines or in the form of binary data.

Text format:

Every frame of the movie is represented by line of text beginning and ending with a "|" (pipe).

If fourscore is not used, the fields in the line are as follows:


Field commands is a variable length decimal integer which is interpreted as a bit field corresponding to miscellaneous input states which are valid at the start of the frame. Current values for this are:

The format of port0, port1, port2 depends on which types of devices were attached.

If fourscore is used, then port0 and port1 are irrelevant and ignored. The input types must all be gamepads, and each input log record must be in the following format:


(commands, player 1, player 2, player 3, player 4, port2)

Binary format:

Input Log section starts with a | (pipe).

Every frame of the movie is represented by a record of a fixed length. The length can be determined by the devices on port0 and port1.

The first byte of each record stores "commands" bit field:

If fourscore is not used, the remaining bytes in the record depend on which types of devices are attached to port0 and port1:

If fourscore is used, then port0 and port1 are irrelevant and ignored. 4 bytes are added to the size of record. The bits of the 1st byte represent the state of buttons of the 1st joypad (bit0 = A, bit1 = B, bit2 = Select, bit3 = Start, bit4 = Up, bit5 = Down, bit6 = Left, bit7 = Right); bits of the 2nd byte represent the state of buttons of the 2nd joypad, and so on.

Taseditor Data

4 bytes

unsigned int32

FM3 version

4 bytes

unsigned int32

Saved modules

4 bytes

unsigned int32

Number of offsets (N = 6)

4 * 6 bytes





















The data starts right after the last record of the Input Log. If there's EOF after the last record, TAS Editor will interpret the file as an FM2 file.

First 4 bytes of Taseditor Data contain the version of the project file format. The first release version of TAS Editor 1.0 saves projects with version = 3.

Next 4 bytes contain bit field that can be used for determining which modules of Taseditor were saved to the FM3 file:

Next 4 bytes contain the total number of modules, in the version 3 this number must be 6.

Then there are six offsets (4 bytes each) pointing at the data of each module. The offsets are counted from the beginning of the file.

When Taseditor saves the project, it calls all 6 modules that need saving. Each of them saves current writing offset and then serializes its own data into the file stream and moves current write position forward. The order of calling modules is always the same (Markers, Bookmarks, Greenzone, History, Piano Roll, Selection). When loading a project Taseditor calls those modules in the same order and they seek to the given offset and load / deserialize the data from the file.

To check the integrity of the data loaded, every module writes its own ID (string) into the file stream before writing the data. When loading the data it expects the ID to match, if it doesn't match then the module refuses to load following data, creates default state and reports "loading error" to Taseditor.

When using Save Compact settings, modules either save all their data as usual or write dummy ID which indicates that this module didn't save its data into the file. When loading the file a module that detects dummy ID refuses to load following data, creates default state but then reports "loading success" to Taseditor.


ID when saved

ID when not saved













Piano Roll






Created with the Personal Edition of HelpNDoc: Single source CHM, PDF, DOC and HTML Help creation