| 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. |