High level view of content
The stream is a series of elements, and when grouped can be viewed like this:
The format assumes being used with a mapper with 16kB segments (see INC_PAGE "command")
In short, the content is
- Data
- Code hooks in the data
Yes, point 2 is a crazy hack and would be impossible in any modern format for a number of reasons.
The content elements
The series of elements in the stream, when
not grouped, are like this:
JMP - Jumps aka code hooks aka commands
The encoder knows the game runtime memory address of the following "commands" and will insert these addresses instead of a command id (which would be the more common approach):
- SET_PORT_FM1
- SET_PORT_FM2
- SET_PORT_WAVE
- LOAD_WAIT - one or more waveheaders is set to load, wait before using them
- INC_PAGE - data is at the end of the 16kB segment, replace segment with next
- EOF
- REG_WRITE (calculated address, see below)
- WAIT_FRAME (calculated address, see below) - indicates the amount of frames to ignore before we continue to parse the stream again
Specifying the number of reg-val-pairs to consume in case of a REG_WRITE
There is never any direct specification of how many reg-val pairs to consume from the stream in sequence, this information is
implicit in the calculated REG_WRITE jump address. Number of frames to wait, WAIT_FRAME, is using similar technique. More specifically:
- The encoder knows the last address of the following blocks and the length of the related macro
- REG_WRITE_BLOCK_FM1
- REG_WRITE_BLOCK_FM2
- REG_WRITE_BLOCK_WAVE
- The encoder knows the last address of the following bloack and the length the related macro
- See the replayer page to easier understand how this works
Extensions
This format should be very easy to extend -- adding compression could be one idea and a nice challenge.
Comments
Post a Comment