| Author: | Keith Henrickson (guest: search) |
|---|---|---|
| Date: | Wed, Feb 21st, 2007 @ 21:46 ( . ) |
Ok, I get most of the theory, but some of the best schemes actually seem to use NO sync marks. If I understand the drive mechanics right, when the head is stepped to a track, it has a 1 in 8 chance of lining up on the data, thus, sync marks are included on a normal disk to say, "Forget what you were doing...HERE'S the real data." So, if the track has no sync, and you're looking for a series of 4 or 5 bytes line PirateSlayer, don't you have a 1 in 8 chance of booting? I seem to recall that GEOS 1.0 used a syncless track and actually wrote it's key 8 times, with a single bit stuffed between each group. Is that what the others do, or is there yet another way to convince a 1541 to reframe? |
 | Author: | Jim Drew (guest: search) |
|---|---|---|
| Date: | Mon, Feb 26th, 2007 @ 20:45 ( . ) |
You can write code self modifying code that will retry all 8 bit shifts. This is how I was able to read/write the EPYX and other stuff that was sync-less. |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Feb 26th, 2007 @ 21:04 ( . ) |
On 02/26/2007 @ 20:45, Jim Drew wrote :
You can write code self modifying code that will retry all 8 bit shifts. This is how I was able to read/write the EPYX and other stuff that was sync-less. : -- For copying to a real disk, it's not an issue since you just write what you read. It's only a problem for current emulators, since they only access the G64 file on byte boundaries. That appears to be changing with VICE and may already be the way HOXS does it. Since there is no way to know without disassembly that signature it's looking for, I just have to bitshift the track until it matches the signature. |
| Author: | Keith Henrickson (guest: search) |
|---|---|---|
| Date: | Wed, Feb 28th, 2007 @ 14:41 ( . ) |
Thanx! I guess I should have thought of that. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sat, Mar 03rd, 2007 @ 22:54 ( . ) |
As for how the drive read it- nothing fancy. If you poll the memory address the drive head puts the data into directly, you don't have to worry about sync. The sync marks are only for the drive to frame each byte properly. A good comparison is an analog record album. You can keep "picking up the needle and dropping it on the record" until you hear the part of the song you like. :) |
 | Author: | Nate (guest: search) |
|---|---|---|
| Date: | Sun, Mar 04th, 2007 @ 14:28 ( . ) |
On 03/03/2007 @ 22:54, Pete Rittwage wrote :
: : A good comparison is an analog record album. You can keep "picking up the needle and dropping it on the record" until you hear the part of the song you like. :) : -- I'd say it's more like you pick up the needle and drop it on the record, then wait as the song loops to get to the part you want to hear. This is different from a record where it's one continuous "spiral" (although that's the same as a CD, DVD, etc.) On the C64, each track is a full circle so if you start from any part on the circle, you'll eventually see all of it. And bitwise, as you point out, the circle is identical no matter where you start. |
 | Author: | JimDrew (registered user: 23 posts ) |
|---|---|---|
| Date: | Wed, Mar 07th, 2007 @ 09:58 ( . ) |
Since the object to duplicating protection is being able to determine the write spice(s), it is important to be able to read the track and shift the data to determine where the splice occurs. The only thing we are concerned about is this. With the EPYX stuff (perhaps others), the "weak bits" created by the write splice is actually checked as part of the protection. They expect this data to change and never be the same or it won't load. They use this point to start their data reads when loading/sending their data too. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Mar 14th, 2007 @ 23:08 ( . ) |
I've never been able to get the whole correct track cycle on those syncless Vorpal (EPYX) tracks. When I read them, I get half the data correct and half shifted, so it's losing framing on me. Did SC do anything special to read these tracks? I notice that it must be set to NON-CBM, AUTOGAP, GAP LENGTH 7. What did these options do? |
 | Author: | jonathon (registered user: 3 posts ) |
|---|---|---|
| Date: | Tue, May 22nd, 2007 @ 10:13 ( . ) |
On 02/26/2007 @ 20:45, Jim Drew wrote :
You can write code self modifying code that will retry all 8 bit shifts. This is how I was able to read/write the EPYX and other stuff that was sync-less. : -- I'm not quite sure why self-modifying code is necessary here. Would you mind providing a few more details? |
| Author: | Jim Drew (guest: search) |
|---|---|---|
| Date: | Thu, May 24th, 2007 @ 11:22 ( . ) |
On 05/22/2007 @ 10:13, jonathon wrote :
: I'm not quite sure why self-modifying code is necessary here. Would you mind providing a few more details? : -- It is necessary if you want code fast and small. There is not a lot of RAM in the drive, so it was necessary to improvise. In NON-CBM mode, the write splice is detected by loading the entire track into RAM and searching for it, bit by bit. The track is then re-loaded and compared during the load. This works well for a single write splice (common with commercial duplication machines), but is next to imposible for a standard DOS disk due to the constant write splices that occur during normal write operations. |