Digital Integration

Found on:
"Bobsleigh"
"Fighter Pilot"
"Speed King"

Loader files:
ROM Header 1
Only filename
ROM Data 1
Autostart, loads turbo loader using ROM routines
ROM Header 2
Only filename
ROM Data 2
Turbo loader

Encoding:
Endianess:MSbF
Threshold:0x01db
Lead-in:8 x 0-bit, 1 x 1-bit
Sync:None
Byte:8 bits
0-bit:Long

Structure:
Header:No
Checksum:Yes
Notes:
Note that the loader uses long duration to represent the 0-bit.

The first bit of the lead-in sometimes is a '1', the loader usually 'misses' the first bit, so isn't bothered by this.

All three games found so far using this loader have the addresses hardcoded and in EOR encrypted code.

There are three versions of Fighter Pilot.
Two are very similar, same length lead-in and load address/size. But they have different checksum.
The third version has a longer lead-in, 6144 bits, documented separately

The +2 is the 'checksum bytes' loader always adds 2 to load size regardless of which checksum variant is used.

Bobsleigh:
File #1: Start: 0x4000 Size: 0x1f40 + 2
File #2: Start: 0x6000 Size: 0x03e8 + 2
File #3: Start: 0x1000 Size: 0x1ff0 + 2
File #4: Start: 0x7640 Size: 0x59b0 + 2
File #5: Start: 0x0a00 Size: 0x2df0 + 2
File #6: Start: 0x7000 Size: 0x02f0 + 2

Fighter Pilot (Short lead-in):
Start: 0x0C00 Size: 0xC3FC + 2

Speed King:
Start: 0x0C00 Size: 0xC3FE

Checksum:
Checksum varies somewhat between the games.

Speed King & Fighter Pilot (Short lead-in):
-------------------------------------------
EOR of the first 0xC3F0 bytes of the loaded data. Compared against offset 0xc3f5 of the loaded data.

Bobsleigh:
----------
EOR of all data bytes, first byte after data is the checksum byte.
Loader doesn't calculate checksum for the first two files and the would be checksum byte does not match.