| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 11:01 ( . ) |
I've recently started dumping some C64 disks with the KryoFlux device, one of them being "The Games: Winter Edition" (probably PAL). Unluckily no public KryoFlux stream to G64 converter was available, so I started to code my own quick-and-dirty one in Java and has been able to generate a G64 file which is booting and loading until track 3 is accessed (after track 2 has been read successfully). I wanted to know why the loader hangs at track 3 so I started to analyze the track data. From what I found out so far, newer Vorpal uses sectors with $80 bytes of user data and an interleave of 3 sectors. Sector format (from track 2 analyzation): - 11111111 (8 one bits, maybe used a sync) - 0101010 (7 bits) - $a0 GCR bytes for user data - three more GCR nibbles (15 bits) - some additional bits which I can't explain yet The following GCR-decoding scheme is used (5 GCR bits to one plain nibble): $09: $00, $0a: $01, $0b: $02, $0d: $03, $0e: $04, $0f: $05, $12: $06, $13: $07, $15: $08, $16: $09, $17: $0a, $19: $0b, $1a: $0c, $1b: $0d, $1d: $0e, $1e: $0f Additionally - I guess in order to avoid false "sync" positives, for the codes starting or ending with 3 or 4 one bits (namely $0f, $17, $1d and $1e) there are alternative ones to encode the corresponding user data nibbles: $14: $0a, $05: $0e, $06: $0f, $0c: $05 The latter ones are not standard encoded GCR but as far as I know don't break the rules (bits in a row) applied to GCR encoding. Using that scheme I could reproduce the user data which is loaded to $a800 by the game from the bitstream of track 2, taking the interleave of 3 into account. As the loader is unable to read track 3 from the generated G64 I patched the file to make the following track's pointers go into track 2 data instead, and it loaded completely until the game (expectedly) crashed afterwards. I could decode the bitstream of the following tracks using the same scheme, so my question is: What prevents the loader from doing a successful read of track 3? How does the loader address the sectors (maybe the problem is lying here)? As far as I remember track 2 has 47 "Vorpal" sectors and track 3 has one sector less and instead more space occupied by bit sequences between the sectors (sometimes including series of one bits which form "real" syncs). I think I'll have to take some deeper look at it but appreciate any ideas you might have. If you like, I could attach a runnable .jar file which will read a G64 file and extract Vorpal sector data into one file per track, including source. |
12/01/2011 @ 15:08----swolff --- 0 Users Online --- 0 Recent Unique Posters |