| Author: | SaxxonPike (registered user: 16 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 15:21 ( . ) |
Currently digging into a few of the listed games under Vorpal (Later) in an attempt to find out the disk format. There doesn't seem to be a lot of documentation about the format of the disks or any source code for it, only documentation how to load the files from these specially formatted disks using the protection's own code. I've extracted code for both sides of the transfer process (computer and drive) if anyone's interested. What I would like to be able to do is write a full specification. If anyone here has input or any notes on the spec, I'd really like to see them :) |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 16:19 ( . ) |
I don't think anything for the last version has turned up as far as low-level details, or how similar it is to the preceding versions which are documented to some extent. |
| Author: | SaxxonPike (registered user: 16 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 18:21 ( . ) |
1541: There's an init stub that runs in the stack space of the 1541 (0160-01DA) and it is wiped out after it executes. After init, $0146-$01FF is used as a data buffer (the stack is set to $45). Going to post the conditions required for a sync to be counted soon. Computer: Drive code is loaded into $F300-$F6FD under Kernal ROM. |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 18:57 ( . ) |
what would happen if you tried to read a disk protected with vorpal-later with nibtools rev 493? |
| Author: | SaxxonPike (registered user: 16 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 19:21 ( . ) |
Btw, I'm curious what exactly you did to patch the Legend of Blacksilver disks to make them work in the emulators. Did you change the code? Or just the track data? |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 20:44 ( . ) |
Just the track data has been reframed. It's the same as what Maverick does to it... |
 | Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Mar 19th, 2011 @ 18:24 ( . ) |
I took a look at the Maverick Epyx Copier for California Games to see what it does. It looks for a repeating byte pattern of at least 10 identical bytes (any byte except $55 or $AA). Once that run of bytes is complete, it skips 3 GCR bytes and then reads another 10 bytes and checks for repeat patterns of these 10 bytes. Once the repetitions are complete, it reads in 8k of track data with a different timing routing. This routine should handle "copying" of syncs since they pre-fill the track buffer with $FF bytes, and skip over buffer bytes if a byte-ready isn't received in a cycle-specific period of time. It uses self-modifying code to alter the timing sequences in this read loop depending on the track density. Track density seems to be set according to regular Commodore DOS rules. It doesn't change density in the middle of a track or anything odd like that. It finds the end of track cycle by looking for that same repeating byte pattern and marking a $00 after the first byte of it. For writing, it erases the track with $55 bytes, writes two bytes ($FF $55), then just dumps the track data to disk with a BVC/STA/CLV loop, finishing when it reaches the $00 marker byte. This $FF $55 might be the key to reframing the data. I took a fairly quick look at the Vorpal loader drive code from California Games, and it looks for a few different bit patterns on the disk, one of them being $FF (although it seems to expect the sync bit to be set in $1c00 if it sees this, so maybe I'm wrong here). I've attached the commented disassembly from the Maverick copier and the main Vorpal drive loader loop. The Vorpal code is confusing and I see why people had trouble understanding it. |
Attachments: |
| 1300573258_cgames-vorpal.txt |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sat, Mar 19th, 2011 @ 18:33 ( . ) |
Thanks very much for detailing this. I knew it did something strange, but never had time to disassemble and see exactly what. :) |
| Author: | SaxxonPike (registered user: 16 posts ) |
|---|---|---|
| Date: | Sat, Mar 19th, 2011 @ 21:33 ( . ) |
Aha, beat me to it :) I don't know a lot about how the 1541 works so spent lots of time researching. Your disassembly is most helpful, thank you! :) The loader in LoB is exactly the same, byte for byte. Seems it uses the clock bit on the serial bus as a data bit when transferring to the C64. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Mar 20th, 2011 @ 01:41 ( . ) |
That's the "2-bit loader" that is used by nearly every fast loader around. V-Max uses one too. It's not the fastest, but the v-max one is nice because it doesn't disable interrupts, so music can play while it's loading, screen doesn't blank, etc. The interesting catch on it is that it transfers the bits out-of-order to the c64 and you have to fix them up with the computer side code (or like in V-Max's case, the data is stored already rearranged on the disk and the xfer actually puts it back the correct way, saving precious clock cycles). Here's a good article on how the 2-bit fast loader works: [link] |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Fri, Mar 25th, 2011 @ 23:27 ( . ) |
I made a mistake in the commentary of that disassembly. In the Vorpal code, at $586-$58a, it reaches here if it read a $FF byte and branches if sync is NOT set. I originally had this the other way around (sync is set). This is due to the 1541 memory map I was using which has bit 7 of $1c00 listed as 0=data, 1=sync which is backwards. Perhaps the doc is referring to the voltage level on the actual pin instead of what the drive sees, since these are active-low. Also, I originally wrote that the Maverick copier writes $FF $55 at the start of the track. It's actually $FF $FF $55. I missed the 2nd BVC which occurs at $099, which, absent another STA $1C01 will just write the previous byte again. So this does indeed write a 16 bit sync mark, which is how Maverick frames the track data properly. Note that the Vorpal loader doesn't look for this sync and will handle the data either way. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 27th, 2011 @ 13:44 ( . ) |
Since a track cycle can not be easily found, I always figured that the framing must "float" on this track. There must be some 3x0 bits on in different places to cause this? |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Mar 27th, 2011 @ 15:31 ( . ) |
The track gap area, perhaps? There's usually junk in the write splice that comes through as illegal GCR, and with no sync mark at the start of track the framing is likely to be off. If you know the start of the track (after the repeating bytes in the write splice area) and the track length (up to the beginning of the repeating bytes again) and read in just this data, does it still wind up misframed at the end? |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 27th, 2011 @ 16:02 ( . ) |
Yes, about 1/4 of the data is good, then it gets OOF. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Mar 28th, 2011 @ 00:01 ( . ) |
What process are you using to determine the start of the track and then load the track in? I was looking at some original disks on a real 1541 through Maverick's track editor. Here's what I noticed: 1. The track lengths for all these no-sync tracks always seems to be the same ($1E28/$1E29). 2. If you read across the track gap, the data always shifts, but does so predictably. 3. Since there's no sync, there's no framing reference, so any track read can come back in 1 of 8 different ways. This is irrelevant to the loader and the Maverick copier. You could force it to come back with a specific pattern by using the header search feature, but that would occasionally hang for a very long time as not every pattern seemed to come up due to a timing issue. I had to lift the drive latch and drop it back down a few times before it would result in that particular arrangement and read the track. 4. The first byte after the end of track pattern (the repeating single byte) is maybe 40% of the time a bad GCR byte. This would indicate to me that this is the write splice and is the actual end of track. The repeating 20 bit pattern after this is inert gap bytes. As long as you start reading after the gap and stop when reaching the repeating single-byte pattern, you should get a track that Vorpal can read. It will be framed in 1 of 8 ways, but it doesn't matter since the Vorpal loader will handle it. The sync mark that Maverick adds simply makes it easier to make another copy of in the future with a generic 8k nibbler or parallel copier. This mark isn't necessary for the copy to load properly, and I'm guessing the SuperCard nibbler does the same thing as Maverick, but doesn't add the bonus sync mark. Maybe I should disassemble that copier to verify. If you blindly read in the whole track just once without waiting for the actual start of track, you'll wind up with the write splice somewhere in the middle and the track data on one side shifted one way, and the data on the other side shifted a different way. If you just try to paste this together, it's ruined. It's interesting that there are sync marks on the odd numbered tracks at all, since analysis of the loader indicates they aren't necessary. The same load routine is used for every track, sync or not. Perhaps a technical requirement for the mastering process? I didn't have time to try it, but you should be able to copy these syncless tracks with the Maverick track editor as well. Read in the track blind, scroll through the buffer to find the track start, then put the first 4 bytes or so in the search header and read the track in again. Scroll down to where the gap is, enter edit mode and put a $00 byte after the first byte of the repeating single-byte pattern to mark the end of track (Maverick will now show the length of the track). Ensure your drive is slowed down and write the track to your target disk. This should work as it's basically the same thing the custom copier does. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Mon, Mar 28th, 2011 @ 21:25 ( . ) |
If only there was a similar g64 editor for the pc, or a pc application that lets you do what maverick's disk editor does. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 02nd, 2011 @ 01:53 ( . ) |
I partially disassembled the SuperCard v6 GCR copier (regular version, not SuperCard+) to see how it handles the non/CBM-auto gap format mode that you need for the newer Vorpal. It does it exactly like it describes in the manual. It starts reading the track and tossing away bytes until it gets X number of bytes in a row (which you specify with the parameter "number of gap bytes"). Once this has been found, it skips any remaining consecutive bytes that match the gap byte and then starts reading GCR bytes into the 8k buffer until $2000 bytes have been read. It then searches through the buffer for X number of repeating bytes (gap length), and marks a $01 after it. This is how it knows where to stop writing the track. So, it's almost exactly the same as the Maverick Epyx copier with the following differences: 1. It doesn't go out of its way to avoid reading the entire actual track gap into the drive buffer for a Vorpal disk (which is typically 52 94 A repeating, or some bitshifted variant), which results in a longer track that requires the drive to be slowed down a bit more to remaster. 2. It copies the majority of the end-of-track byte pattern depending on what you chose for the "number of gap bytes" parameter, which means the Maverick copier would be able to copy this copy. When Maverick copies the disk, it chops off all but one byte of this pattern, which means it cannot detect the start-of-track if you copy the copy with the same custom copier, and will hang forever trying to read the track (although it should work with the generic ramboard copier due to difference #3). 3. It doesn't add the extra sync (FF FF 55) at the start of the track. This copier also has a slight bug/anomaly that could come up if you were to copy a particular type of disc using this format mode. If the disc has two long byte patterns on it (say, d6 d6 d6 d6 d6... followed by 55 55 55 55..) then SuperCard would think the d6 pattern is the gap byte and start writing the track buffer at the $55 byte pattern. But then when it tried to detect track length in that buffer, it would read X number of bytes of the gap byte ($55) and mark the $01 right near the start of the track, leaving you with a botched copy. This happened to me in the emulator when copying a modified Maverick copy of the disc. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Mar 07th, 2011 @ 20:45 ( . ) |
Nothing different. The framing shifts on the sync-less tracks and must be reframed in software. |
| Author: | SaxxonPike (registered user: 16 posts ) |
|---|---|---|
| Date: | Tue, Mar 08th, 2011 @ 23:25 ( . ) |
I also noticed that when converting NIB to G64 some of the tracks are truncated. Why is this? |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Mar 09th, 2011 @ 08:27 ( . ) |
VICE (<=2.2, at least, I haven't tested 2.3) has all the G64 parameters hard coded and ignores the G64 header. For this reason, any G64 *had* to be 42/84 tracks, exactly 7928 bytes each. Any more than that must be truncated or VICE would crash. The later Vorpal has tracks longer than this, and the drive must be slowed to 296 or so to write all the data back. |
 | 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. |
 | Author: | swolff (registered user: 26 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 14:44 ( . ) |
A few years ago I wrote a program which reads all data from a "Vorpal (later)" G64 or NIB image, including verifying the data integrity checksum. While I don't remember any details, I should be able to find my notes and the program C code itself if you get stuck in your analysis, or simply don't want to reinvent the wheel. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 14:53 ( . ) |
Hi markus, can you please write to me off list? My email is whocrazy@gmail.com. Thanks |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 14:58 ( . ) |
That's really odd, as I recall tracks 2/4/6/8 being the sync-less tracks with the special encoding. At least maybe they are the same encoding but use %0101010101 for a sync instead of %1111111111. |
| Author: | swolff (registered user: 26 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 15:08 ( . ) |
SYNCs are handled in software by the Vorpal loader, not by the drive's SYNC hardware signal. IIRC, Vorpal syncs may be as short as five 1-bits, which is what you're seeing on the densest tracks. The tracks that do not appear syncless are, in fact, written in the same format as those that do. IIRC, Vorpal doesn't contain any obfuscation or other deterrents. It's just a very nice fastloader. Pretty, even. Much nicer than the horrible mess that is RapidLok (of course this mess is intentional, making it harder to follow and break). The high data density and long sectors along with the ultra-short sync marks makes Vorpal tricky to copy using general-purpose disk copiers or nibblers. |
 | Author: | IFWSPS (guest: search) |
|---|---|---|
| Date: | Fri, Dec 02nd, 2011 @ 13:23 ( . ) |
The nosync Vorpal format has 46/47, 41, 39 and 37 sectors per track depending on speed zone. The sectors are 128 bytes long. The 46 sector tracks have a single dos header to enable track seek/verify (for the 1541 that is). CBM tracks 5 and 21 have a wrong track number recorded on purpose. The encoding is a continuous bitstream with syncs added to allow sector level reading. The encoding is a maximum of 4 consecutive 1 bits, and 2 consecutive 0 bits (hw limit). This has been achieved by an adaptive encoding scheme that treats the bitcells as a continuous stream rather than simple 5 bit entities. Some nybbles can be encoded in two different ways (the encoding scheme is somewhat similar to how MFM encoding works in this regards), and the combination of those always guarantee that the recording rules of this scheme is never violated. Syncing is performed by finding 5 consecutive 1 bits, as the encoding won't produce that otherwise. This, however is recorded on the disk as 8x1 bits. There is no sector header, just the sync, 7 bitcells as 0101010 and the sector data 128x10 bits, plus checksum 10 bits. The following 9 bit contains the actual sector number, using a different encoding. The next sector sync immediately follows that. If the sector number encoded ends with 1s, the sector sync count is decreased to ensure that always 8x1 bits are recorded. e.g. sector number encoded ends with ...11 the sync following it will be 6 bits instead of 8. These tracks are by design not modifiable. It is easy to see that getting the track gap position wrong, one sector is guaranteed to get damaged and the stream will be broken. This is on purpose of course. The KryoFlux host software can fully verify this as well as other Vorpal variants. |
| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Mon, Dec 05th, 2011 @ 11:38 ( . ) |
Thanks for this detailed explanation of the format. Until IPFs become available and usable in emulators for these titles, this will help verifying track dumps and G64 files fore those titles. |
| Author: | IFWSPS (guest: search) |
|---|---|---|
| Date: | Tue, Dec 06th, 2011 @ 11:38 ( . ) |
You are welcome, and thanks for working on a new tool - once it is ready please consider posting about it at [link] as well :) |
 | Author: | The Doctor (guest: search) |
|---|---|---|
| Date: | Thu, Mar 28th, 2013 @ 02:42 ( . ) |
On 12/06/2011 @ 11:38, IFWSPS wrote :
You are welcome, and thanks for working on a new tool - once it is ready please consider posting about it at [link] as well :) : -- Cool stuff. I used to hack back in the early days and got quite familiar with disk formats and controlling the drive directly. But you've obviously taken it further with the dissection of Vorpal. Amazed that people are still studying this platform. |
 | Author: | bluebirdpod (registered user: 28 posts ) |
|---|---|---|
| Date: | Tue, May 07th, 2013 @ 19:53 ( . ) |
not really, its amazing that peeps are still messing with Amstrad CPC64, and Apple2 stuff. Now the best selling 8-bit computer the Commodore 64, is still my favorite computer EVER. I miss all the glory. We had FUN. now its just work. LIVE FOREVER !! ! ! !!!!! |
| Author: | SaxxonPike (registered user: 16 posts ) |
|---|---|---|
| Date: | Tue, May 28th, 2013 @ 20:47 ( . ) |
In the last two years I've practiced a lot with 6502 assembly, going so far as to implement barebones support in the Bizhawk emulator and code a few utilities for the C64 myself. I decided today I was going to look back at this project and pick at it once again. I find it fascinating how fast this fast loader really is. It just blows through tracks like it's nothing. I didn't see that there was much to obscure the code because there isn't actually time in the transfer loop for it. While extracting the files from Legend of Blacksilver using its own code, I found that the sectors it uses contain about $80 bytes worth of data. The file table is located at $FA04 in computer memory (which can be observed when the Kernal is disabled.) GCR is assembled by the drive using two tables that take up about a quarter of available RAM there. I'm still not sure how the sectors are laid out on the drive, but in this game it appears the directory is in a low track, I think it was track 2 on each disk. Interestingly enough, even using VICE 2.4 "x64sc", the directory didn't seem to load up the same every time. The game appears to use the integrity of the directory itself to determine if the rest of the disk is valid data. Sometimes the directory would be loaded in with the bits shifted once (left, IIRC). Once the directory loaded fine, the rest of the disk seemed to work OK, until a disk change. This is using the set of the "patched" G64 files. Hoxs64 doesn't actually exhibit this issue, and I can't figure out why. Still crazy that it has the capability to load its largest files in a couple seconds. With a bit of patience, I was able to extract all the game files and export them using monitor commands. It was a little tedious, but I'm going to be putting together something really special. |
 | Author: | jonathon (registered user: 3 posts ) |
|---|---|---|
| Date: | Sat, Jun 08th, 2013 @ 08:39 ( . ) |
So, how is the reframing handled in software? Is there a loop that scans the data for 8 different shifted versions of the sync, then shifts all the data enough bits to reframe them? |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Jun 13th, 2013 @ 03:22 ( . ) |
Greetings. I bought a copy of La_Crackdown off Ebay which supposedly uses vorpal-newer. I dumped it with nibtools and loaded it up in winvice sps and to my utter amazement, the game actually worked, Nibtools just seems to dump the so-called "syncless" tracks with ease. My setup is a a machine with windows xp sp3, open cbm 0.4.99.93 built sept 2011, an original 1541, a Parallel port using the xap1541 setup, and multiple versions of nibtools. I used mnib 0.45.1 for the dumping of this title because I find it dumps some protections better than others. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Jun 13th, 2013 @ 08:03 ( . ) |
Just got hold of a copy of Legend of blacksilver and all I can say is... wow. No wonder it's impossible to dump with nibtools. when I examined the troublesome track 2, I counted only 4 or 5 sync marks throughout the entire track. The fewer sync marks there are, the more difficult the track is to nibble. La Crackdown is one of those hit&miss titles. Most times you'll get a good read of the disk, but no such luck with Blacksilver. |