APS Files: Difference between revisions
→RAE Signal Scramble Lookup Table: Correct this - It's really down to the original Pianocorder bit layout and the way the boards were adapted for use with the RAE |
imported>The 64th Gamer m 4 revisions imported |
||
Line 9: | Line 9: | ||
*'''.3st''' for 3-Stage (1991-1992) |
*'''.3st''' for 3-Stage (1991-1992) |
||
*'''.c&r''' for C-Stage and Rocker Stages |
*'''.c&r''' for C-Stage and Rocker Stages |
||
*'''.atl''' for Road Stages (October-November 1990) |
|||
*'''.roa''' for Road Stages (1990-1991) |
*'''.roa''' for Road Stages (1990-1991) |
||
*'''.r12''' for Road, 1-Stage, and 2-Stages (1992) |
*'''.r12''' for Road, 1-Stage, and 2-Stages (1992) |
||
*'''.bzr''' for Beach Bowsers |
*'''.bzr''' for Beach Bowsers |
||
*'''.hlf''', |
*'''.hlf''', an unknown stage format |
||
== Overall format == |
== Overall format == |
||
APS files are rather minimal and contain a length value, segment name, and control data. Data is stored at 29.97 FPS and each frame contains the state of all bits, so playback can be seeked to any arbitrary location without needing to process any preceding data. |
APS files are rather minimal and contain a length value, segment name, and control data. Data is stored at 29.97 FPS and each frame contains the state of all bits, so playback can be seeked to any arbitrary location without needing to process any preceding data. |
||
Line 43: | Line 42: | ||
== RAE Signal Scramble Lookup Table == |
== RAE Signal Scramble Lookup Table == |
||
For 3-Stage APS files, all data bytes past the 0x200 header space |
For 3-Stage APS files, all data bytes past the 0x200 header space will be read as garbage data unless rearranged. This is due to an intentional feature built into the [[Grey Box]], likely to prevent reverse engineering or playing of unofficial tapes. |
||
Every 16 bytes must be rearranged into this order (0-indexed) |
Every 16 bytes must be rearranged into this order (0-indexed) |
Revision as of 21:10, 29 November 2022
![](http://static.miraheze.org/decodedocdigitizewiki/thumb/8/85/Gju4.jpg/300px-Gju4.jpg)
The APS format is used to store the raw programming data for various animatronic shows. Different stage types are denoted by the file extension used, but the file format otherwise remains the same for each type.
Each file represented a segment of a showtape, rather than the entirety of the showtape's runtime. Segments were never programmed for intermissions, and their file names were usually numbered, with accordance to actual segments with performances in the tape.
Known File Extension Names
- .mvt for Random Movements
- .sho for 3-Stage (1990)
- .3st for 3-Stage (1991-1992)
- .c&r for C-Stage and Rocker Stages
- .roa for Road Stages (1990-1991)
- .r12 for Road, 1-Stage, and 2-Stages (1992)
- .bzr for Beach Bowsers
- .hlf, an unknown stage format
Overall format
APS files are rather minimal and contain a length value, segment name, and control data. Data is stored at 29.97 FPS and each frame contains the state of all bits, so playback can be seeked to any arbitrary location without needing to process any preceding data.
Note that APS files do not contain the required information to sync with audio. It is unknown exactly how this was handled by the original programming software, but it is likely that the frame number within each show is determined based on the timecode value from the tape used in the editing system.
Frame format
Frames are made up of 32 bytes, storing 256 channels of control data. A bit value of 1 indicates the particular bit is active. Any bits unused by the show controller are left as value 0. Show bits are stored with the least significant bit first, and the following table explains the arrangement for a few example bits:
Show bit (1-indexed) | Byte offset within frame | Bit within byte |
---|---|---|
1 | 0x00 | 0 |
2 | 0x00 | 1 |
8 | 0x00 | 7 |
9 | 0x01 | 0 |
16 | 0x01 | 7 |
Show types using multiple "drawers" are stored with the second drawer's data starting at show bit 129. Of course, the exact mapping of bit to movement depends on the show type.
Chunk format
Frames are stored in 0x400-byte chunks, beginning at offset 0x200 in the file. While it would be possible to fit 32 frames total in each chunk, the last two frames in each chunk are left unused, so each chunk actually contains only 30 frames. It is assumed that this was done to allow easier seeking in the file, since each chunk containing one second worth of data is convenient, but it is also possible that this area was intended to be used for future expansion. None of the files examined so far appear to use it for that purpose, however.
RAE Signal Scramble Lookup Table
For 3-Stage APS files, all data bytes past the 0x200 header space will be read as garbage data unless rearranged. This is due to an intentional feature built into the Grey Box, likely to prevent reverse engineering or playing of unofficial tapes.
Every 16 bytes must be rearranged into this order (0-indexed)
10, 11, 0, 1, 2, 3, 4, 12, 13, 5, 6, 7, 8, 9, 14, 15
Header format
![](http://static.miraheze.org/decodedocdigitizewiki/thumb/a/a6/Apsss.png/453px-Apsss.png)
The file header starts at offset 0 and is not completely understood, but is easily human-readable in a hex editor for file identification purposes. It appears to be entirely plaintext. The exact size is also unknown, but definitely not larger than 0x200 bytes.
Offset | Data | Example |
---|---|---|
0x00 | Length M:SS | 7:30 |
0x0a | Length repeated? | (7:30) |
0x10 | Title Line 1 | |
0x32 | Title Line 2 |
All gaps in the header should be filled with 0. It is reasonable to assume that strings are intended to be read as null-terminated with a maximum length determined by the location of the next string.