| Author: | DonM (guest: search) |
|---|---|---|
| Date: | Thu, Mar 20th, 2008 @ 22:38 ( . ) |
Okay, I've finally got my cable working. I figured I should report back here what was going on. It turned out to be an intermittent connection on wire 5 of the DIN plug. That's why it was testing okay when not connected to the PC but wasn't working when connected to the PC. Big thanks to Womo, Joe, and Spiro for all their help. Now on to my question: When imaging some disks I noticed an oddity that I don't remember being discussed on the forums... On some disks I noticed that mnib would mark some of the tracks weak, even on games that I'm sure don't use weak bits. Does that mean the data on the disk is starting to fade or something else? Here's a small snippet of the log from Last Ninja 2 (original disks, of course): 0.5.2 (Built Jan 9 2008 22:27:15) 'nibread lastninja2_1.nib ' Drive Version: 73,CBM DOS V2.6 1541,00,00 Drive type: 1541 18.0: {0: 0/ 0}{1:209/ 0}{2: 46/20}{3: 1/ 0}(2) CID: 'Q1' FID: 'AC' 1.0: {0: 0/ 0}{1: 0/ 0}{2: 11/ 0}{3:226/10}(3) 7816 [DOS] (7816) 2.0: {0: 0/ 0}{1: 1/ 0}{2: 12/ 0}{3:224/10}(3) 7817 [DOS] (7817) 3.0: {0: 0/ 0}{1: 0/ 0}{2: 5/ 0}{3:226/10}(3) 7818 [DOS] (7818) 4.0: {0: 0/ 0}{1: 0/ 0}{2: 12/ 0}{3:218/10}(3) 7816 [DOS] (7816) 5.0: {0: 0/ 0}{1: 0/ 0}{2: 14/ 0}{3:238/10}(3) 7816 [DOS] (7816) 6.0: {0: 0/ 0}{1: 0/ 0}{2: 11/ 0}{3:228/10}(3) 7816 [DOS] (weak:2) (7816) 7.0: {0: 0/ 0}{1: 0/ 0}{2: 10/ 0}{3:231/10}(3) 7817 [DOS] (7817) 8.0: {0: 0/ 0}{1: 0/ 0}{2: 9/ 0}{3:208/10}(3) 7817 [DOS] (7817) 9.0: {0: 0/ 0}{1: 0/ 0}{2: 11/ 0}{3:190/10}(3) 7816 [DOS] (7816) 10.0: {0: 0/ 0}{1: 0/ 0}{2: 17/ 0}{3:197/10}(3) 7816 [DOS] (7816) 11.0: {0: 0/ 0}{1: 0/ 0}{2: 10/ 0}{3:210/10}(3) 7816 [DOS] (weak:2) (7816) 12.0: {0: 0/ 0}{1: 0/ 0}{2: 9/ 0}{3:203/10}(3) 7817 [DOS] (weak:2) (7817) |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Fri, Mar 21st, 2008 @ 08:28 ( . ) |
Hi Don, Glad you got it working. Weak areas (or bad GCR) is normal on any track. They happen during the mastering process where the track begins or ends, or during normal use when the drive writes out the data sectors. The process is like pressing record on a tape recorder, you never know exactly in the bitstream where it will end up. |
| Author: | DonM (guest: search) |
|---|---|---|
| Date: | Fri, Mar 21st, 2008 @ 12:28 ( . ) |
Ahhhh, thanks for the explanation. I've also noticed that using mnib in DOS seems to be a little more reliable (on my PC anyway) than in Windows (XP). After imaging about 50 disks I started going through and trying a few. Some didn't work because they used newer Vorpal protection (California Games, Championship Wrestling, etc), but some would load under WinVice and not under CCS64 and vice-versa. Two examples that come to mind are Vorpal and The Last Gladiator (which isn't in the DB yet and uses early EA protection). Vorpal would load fine in WinVice, but refused to load in CCS64. The Last Gladiator would load just fine in CCS64 but would not load in WinVice; Well, it would load in WinVice but it would fail the copy protection and restart the loading process a second time, taking twice as long to load as it should. After imaging these both in DOS they both booted fine in both emulators. I don't know if this is normal or not but just thought I would mention it. At that point I was not using the -m switch, which I assume reads the track multiple times and compares the reads to see if they are the same, however, now that I am going back through and re-imaging them I am using the -m switch so that may possibly have some affect. Another quick question Pete: Do you prefer verbose logs or regular logs? Also, is there any particular command-line switch you would prefer I use, outside of enabling track matching (-m) ? |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Fri, Mar 21st, 2008 @ 18:13 ( . ) |
Hi Don, The standard settings should work fine. I have experienced plenty of times where the first image isn't as good as a second image, and I attribute that to "knocking the dust off" the surface of these old disks. Track matching does something like this where it try to match the track on two good reads, but a lot of tracks never read the same twice if there's a problem anyway. Best way is to test them, or send them to me for testing. Either log is fine, I don't use them unless I have to figure out what drive or see if an error was repeated over and over on successive reads. Thanks for taking the time! :) |