'Vorpal (later) analysis'
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.

REPLY: [With No Quote] --- [With Quoted Text]

--* Vorpal (later) analysis
12/01/2011 @ 14:44--swolff
12/01/2011 @ 14:53----hyper active
12/01/2011 @ 14:58--Pete Rittwage
12/01/2011 @ 15:08----swolff
12/02/2011 @ 13:23------IFWSPS
12/05/2011 @ 11:38--------Markus Benko
12/06/2011 @ 11:38----------IFWSPS
3/28/2013 @ 02:42------------The Doctor
5/07/2013 @ 19:53--------------bluebirdpod
5/28/2013 @ 20:47----------------SaxxonPike
6/08/2013 @ 08:39------jonathon
6/13/2013 @ 03:22--------hyper active
6/13/2013 @ 08:03----------hyper active

--- 0 Users Online --- 0 Recent Unique Posters

Q55=1660600181 - Threads: / 1660600181