|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 @ 14:58--Pete Rittwage
12/01/2011 @ 15:08----swolff
12/02/2011 @ 13:23------IFWSPS
--- 0 Users Online --- 0 Recent Unique Posters