| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Fri, Apr 15th, 2011 @ 14:54 ( . ) |
I found the entry in the detailed changelog: 2010-04-16 Antti S. Lankila <alankila@bel.fi> * src/drive/rotation.c: At least some copy protections require distinguishing true GCR=1 from the reinterpreted GCR=0 read as 1. ... Rewrite rotation to rotate disk bit-by-bit. Use hardware-style 10-bit sync sequence detection. Support GCR=0 reads in deterministic fashion based on a PRNG. Bump drive snapshot version to accommodate new fields. So it looks like this is a more accurate emulation of the drive, and does reflect some experiences I had on a real 1541 when using the Maverick Track Editor to read in a track given a specific header. Sometimes the drive would read for an extremely long time, not finding the header pattern that I knew was there. Lifting the latch and then closing it a few times was enough to shift the reading so that the framing would line up properly and the header was found. On my image of Take Down, this happens on track 19 in Vice 2.3. There's no sync there, and it reads for quite a long time and then "catches" and loads the track and continues. If I add the sync, it loads immediately. In all the other cases I've seen, the framing never matches up and the track never loads. I'm still inclined to think there's a bit of a bug here that doesn't adjust the rotation properly when it hits bad GCR and the "deterministic pattern" is such that the the framing is consistently off, never to be adjusted correctly. Perhaps this is indeed accurate though. I'll try take a look at the vice code to see if/when it shifts the framing when there's no sync to force it. On the plus side, this should allow arbitrary sync lengths down to the accuracy of a single bit, not relying on the byte boundaries in the image, which makes Nate's G64 tool even more useful for emulators. |
--- 0 Users Online --- 0 Recent Unique Posters |