| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Apr 14th, 2011 @ 00:38 ( . ) |
Has anyone noticed anything odd with Vice 2.3 when it comes to sync marks (maybe related to illegal GCR), specifically with V-Max V2? In my attempts to get a working copy of Gauntlet: The Deeper Dungeons, it would always hang on some track and entering the debugger would show the drive code looking for the sector header on the track and it would never find it, even though I could see it in the image. Checking the $1C01 register to see the GCR bytes it was seeing on the "disk" showed byte sequences that didn't even exist in the image. I encountered the same problem with Bad Street Brawler on track 8. However, loading these images in Vice 2.2 works. I found that for the problematic tracks, if I added a sync mark in front of the $64 byte of the first sector on the track (in relation to where the track started in the image, not necessary logical sector 1), it would then load properly in Vice 2.3. However, it would sometimes, depending on the track, fail the V-Max sector checksum in Vice 2.2 unless I made the sync mark another 8 bits longer (as seen on BSB track 10). So does Vice 2.3 adjust framing when it encounters bad GCR? Or is this just an odd bug? In the end, I was able to get a copy of Bad Street Brawler that worked on both versions of the emulator by adding the sync marks to the tracks it was hanging on, but I can't figure out why, since the protection doesn't even look for sync. It moves the head to the track and immediately just starts reading GCR bytes and comparing the byte read to $64. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Apr 14th, 2011 @ 01:31 ( . ) |
The anomaly with having to add the extra 8-bit sync to get Vice 2.2 working was my fault. V-Max V2 reads in bytes until it gets a byte that doesn't have bit 7 set. So when adding syncs, this violates that rule since $FF has bit 7 set, V-Max thinks it's part of the data block. Solution is to insert $7F $FF as the sync before the $64 byte. Of course it still doesn't explain why that worked in Vice 2.3... |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Apr 14th, 2011 @ 20:28 ( . ) |
The old code that I added just looked for 0x00 bytes and replaced them with random numbers. Womo changed it to use a number derived from the clock instead of random numbers which worked better for the rewind feature (if I recall correctly). I don't know if they still use this code- I haven't checked. Before 2.3, you had to uncomment it and recompile. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Fri, Apr 15th, 2011 @ 01:21 ( . ) |
I found that removing the illegal GCR doesn't fix the issue (at least not when I was trying with Harrier Combat Simulator, which hangs on track 22). This track had no sync marks anywhere. Usually there's a short 12 bit one right before sector 0, but in this case it was imaged in as $7E $FF. Same thing noticed for the next 2 tracks it hangs on (12 and 14). Neither of them had a sync mark anywhere. Looking at tracks that worked, they all had a sync mark somewhere. I also verified that adding a sync mark of 10 bits or more to anywhere in the non-working track (even in the track gap) produced a working track. Does Vice now require a sync mark on every track to establish proper framing? I suppose that would be more in-line with a real 1541, but I never saw this emulation enhancement mentioned anywhere. I tried removing the Maverick-added sync mark on track 2 of California Games and it still loads correctly, but that could be due to the loader handling any shift. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Fri, Apr 15th, 2011 @ 14:05 ( . ) |
Perhaps they added code to align the track data to the end of sync marks. I don't use 2.3, personally- too buggy! |
| 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. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Fri, Apr 15th, 2011 @ 15:25 ( . ) |
Agreed that it is a step in the right direction. I would also be curious on what the "determinalistic" variable is. :) |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Fri, Apr 15th, 2011 @ 17:05 ( . ) |
From rotation.c: /* GCR=0 support. * * In the absence of 1-bits (magnetic flux changes), the drive * will use a timer counter to count how many 0s it has read. Every * 4 read bits, it will detect a 1-bit, because it doesn't * distinguish between reset occuring from magnetic flux or regular * wraparound. * * Random magnetic flux events can also occur after GCR data has been * quiet for a long time, for at least 4 bits. So the first value * read will always be 1. Afterwards, the 0-bit sequence lengths * vary randomly, but can never exceed 3. * * Each time a random event happens, it tends to advance the bit counter * by half a clock, because the random event can occur at any time * and thus the expectation value is that it occurs at 50 % point * within the bitcells. * * Additionally, the underlying disk rotation has no way to keep in sync * with the electronics, so the bitstream after a GCR=0 may or may not * be shifted with respect to the bit counter by the time drive * encounters it. This situation will persist until the next sync * sequence. There is no specific emulation for variable disk rotation, * this case is thought to be covered by the random event handling. * * Here's some genuine 1541 patterns for reference: * * 53 12 46 22 24 AA AA AA AA AA AA AA A8 AA AA AA * 53 11 11 11 14 AA AA AA AA AA AA AA A8 AA AA AA * 53 12 46 22 24 AA AA AA AA AA AA AA A8 AA AA AA * 53 12 22 24 45 2A AA AA AA AA AA AA AA 2A AA AA * 53 11 52 22 24 AA AA AA AA AA AA AA A8 AA AA AA */ And: /* * Simulate loss of sync against the underlying platter. * Whenever 1-bits occur, there's a chance that they occured * due to a random magnetic flux event, and can thus occur * at any phase of the bit-cell clock. * * It follows, therefore, that such events have a chance to * advance the bit_counter by about 0,5 clocks each time they * occur. Hence > 0 here, which filters out 50 % of events. */ Hm, in the images I converted from .nib to .g64, I used the -f option to not force the $00 bytes for invalid GCR. This may have been a mistake. I'll try it again later without that option and see if the framing eventually falls in line after a few rotations of the disk and allows the loader to continue. Also nice to see in the TODO list of drive.c: /* TODO: - more accurate emulation of disk rotation. - different speeds within one track. Would also be nice to see removal of hardcoded track sizes in G64. Should also be pretty straightforward to alter the bps speed of the track from the current hardcoded table, to a generated value based on how many bytes are on the track (bytes-in-track*8*RPM/60 would be close enough for a track that doesn't include speed zones). This would fix the V-Max density protection check. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Fri, Apr 15th, 2011 @ 20:06 ( . ) |
Well, nibconv without the -f flag didn't set any of the bad GCR to $00 bytes, but after I changed a run of the bytes in the track gap to $00, the image did load correctly. So it's not a bug, it's accurate emulation of a flawed device! Kudos, Vice team. |
 | Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Fri, Apr 15th, 2011 @ 23:22 ( . ) |
Concerning VICE 2.3 x64sc, I have found that a number of titles (including ones that are not copy protected) do not work unless the 6526A (new) CIAs are selected. Does anyone know why this is the case? 2.3 is also a lot pickier with my pirate slayer titles. Pete, thanks for adding the automatic bit rotation to the -pp switch! I haven't tried to compare the behavior of the 2.3 x64 vs. the x64sc. I still have one non copy protected title, BI's Cal-Kit, that works with CCS64, but not VICE. |