C64 dumping

All questions regarding the dumping of media go here.
Edsel007
Posts: 59
Joined: Sun Jun 10, 2012 10:20 am

Re: C64 dumping

Post by Edsel007 » Tue Aug 07, 2012 10:01 am

I'm a little bit confused right now which is the right way to dump my disks. I did some testing and used 3 different ways (commandlines) to dump one and the same disk. All three ways gave me different results in the size of the raw files as well as in the size of the generated g64 images. The disk I used for these tests is O'Rileys Mine (Datasoft), which would be the -i17 switch.

Method 1:
commandline used for dumping: dtc -p -b-8 -fg:\dumpdir\Test\Test_ -i -i2 -y -g2 -i17 -t10 -l8
- this generated raw files only of course. Output was CBM DS: OK on every track, no errors

I then converted the stream files into g64 Image using this commandline: dtc -p -m1 -fg:\dumpdir\Test\Test_ -i0 -fg:\dumpdir\Test\Test_.g64 -y -g2 -i22 -l8
The g64 works in Winvice. Size is 482KB

Method 2:
commandline used for dumping: dtc -p -b-8 -fg:\dumpdir\Test2\Test2_ -i -i2 -fg:\dumpdir\Test2\Test2.g64 -y -g2 -i17 -t10 -l8
- this generated raw files as well as g64 Images. Output was CBM DS: OK on every track, no errors

Winvice won't even let me attach this g64 Image. Size is 166KB

Method 3:
commandline used for dumping: dtc -p -b-8 -fg:\dumpdir\Test3\Test3_ -i -i2 -fg:\dumpdir\Test3\Test3.g64 -y -g2 -i22 -t10 -l8
- this generated raw files as well as g64 Images. Output was CBM GCR DATA: OK for each track, no errors

This g64 works in Winvice. Size is 500KB



The raw files are of different size in each of these tests.
Now I wonder which of these methods do you recommend for dumping? Method 2 fails, I guess.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: C64 dumping

Post by IFW » Tue Aug 07, 2012 11:38 am

For Datasoft games I'd recommend -i17.
For converting to g64 I'd always use -k2 (or, very rarely, -ks2 if there is too much cross-talk) to get a realistic image with most/all of the unnecessary data removed.
DTC is very good in removing unneeded data from g64 images if it is allowed to do so. ;)

The only format that would be a g64 is -i22; so unless you specify that, the images will never ever be loadable in an emulator, unless accidentally they match the size of a d64 image... in which case they still wouldn't work, see below why.

DTC fully decodes and verifies all of the custom formats it supports - actually a lot more, e.g. variants of the same format, not listed under different image types.
When you give a filename for a custom format, the decoded image gets saved, like how a d64 is a decoded sector image of a standard CBM DOS disk. However, since the other formats are often wildly different in their encoding from CBM DOS no emulator will load those.
The purpose of these images is different: you can make binary comparisons on images and see if, say, two dumps of the game "Pirates" are identical or not - despite the fact that the game uses RapidLok. Since the image saved is strictly the decoded data (plus in the case of RapidLok, the unique disk key) you can just compare the images and know if it is the same version of the game or not.

The stream file sizes will always be different for various reasons, one obvious reason is that sampling starts at a different (random) point on the track, the other is aliasing artefacts - at the level the disk gets sampled you will never ever read the same data twice. It is up to the controller (or in our case DTC) to make sense of such data.

While method 3 might work, I can't recommend it.
When DTC converts to g64, it tries to maximize the data completely understood on a track, to ensure that as little data is included "blindly" as is possible.
The algorithm may pick data/formats it should not. It's not a problem when the data is known to be good according to the format specifications of the real format, but not necessarily good if simply used to verify a dump...
e.g. on a bad track DTC may find a format where a bad sector is not an issue, while in reality it really is bad and should have been retried; had the correct format been used, DTC would have known to retry the read.

Hope this helps :)

Edsel007
Posts: 59
Joined: Sun Jun 10, 2012 10:20 am

Re: C64 dumping

Post by Edsel007 » Wed Aug 08, 2012 11:13 am

Yes thanks :)

So, regarding a working Image of a disk, this is where the SPS team joins the field with their IPF format, right?
What if I submitted a dump of a modified or bad disk, and another user submitted an unmodified dump.
Will I still receive an IPF? As IPF will only be generated of unmodified dumps, afaik.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: C64 dumping

Post by IFW » Wed Aug 08, 2012 11:44 am

Yes, finding a good disk of any game is always a team effort and sometimes it can take years... So anyone involved in finding something should get it.

sncboom2k
Posts: 147
Joined: Sat Jul 21, 2012 5:33 am

Re: C64 dumping

Post by sncboom2k » Wed Aug 08, 2012 10:09 pm

Doing what I can - just purchased 120 games between ebay and lemon64 (loose disks). Should keep me busy for a while ;)

malers
Posts: 17
Joined: Sun Apr 08, 2012 2:00 pm

Re: C64 dumping

Post by malers » Thu Apr 04, 2013 3:18 pm

I am currently trying to dump Gunship from Microprose with its Rapidlok V6 Protection.
I was not successful yet but before I post details I would like to know if there is any method/process which reveals wether the disk drive is well alligned or not.
The final g64 loads endless in WinVice 2.4a_SPS.

I tried 2 panasonic ju475-5 and one Teac-55 and there are always errors detected during dumping like:

dtc -p -fgunshipRL/ -i0 -i2 -i16 -t10 -l8
KryoFlux DiskTool Console, v2.20, uiv.1, Mar 24 2013, 19:59:17
(c) 2009-2013 KryoFlux Products & Services Ltd.
Developed by The Software Preservation Society,
Licensed for private, non-commercial use only.

00.0 : CBM RL: <error>, trk: 001, sec: 21, mis: 1, * +3
02.0 : CBM RL: OK, trk: 002, sec: 21
04.0 : CBM RL: <error>, trk: 003, sec: 12, bad: 1
04.0 : Bad sector found
04.0 : CBM RL: <error>, trk: 003, sec: 12, bad: 1
04.0 : Bad sector found
04.0 : CBM RL: <error>, trk: 003, sec: 12, bad: 1
04.0 : Bad sector found
04.0 : CBM RL: <error>, trk: 003, sec: 12, bad: 1
04.0 : Bad sector found
04.0 : CBM RL: <error>, trk: 003, sec: 12, bad: 1
.
.
.
04.0 : Read operation failed
06.0 : CBM RL: OK, trk: 004, sec: 12
08.0 : CBM RL: OK, trk: 005, sec: 12
10.0 : CBM RL: OK, trk: 006, sec: 12
.
.

Are errors already a sign of misalignment when the disk works in a 1541 in case of special CBM formats?
Is there a process which approximatly reveals a well aligned drive without oszilloscope and Alignment-Disk?

Thanks in advance

User avatar
mr.vince
Posts: 2117
Joined: Tue Oct 05, 2010 5:48 pm

Re: C64 dumping

Post by mr.vince » Thu Apr 04, 2013 6:56 pm

Yes, if the disk is fine in a 1541, it seems your drives are misaligned. I'd say otherwise if this would be a user written disk, because it would read back fine in the 1541 it was written with.

This is an original and no copy?

malers
Posts: 17
Joined: Sun Apr 08, 2012 2:00 pm

Re: C64 dumping

Post by malers » Fri Apr 05, 2013 9:55 am

I bought it as original from ebay. I think the disk is original while the sticker is not on the disk anymore but contained in the box. There are surroundings of the sticker on the disk, so it might be sticking in past on the disk. The disk also contains 2 index holes.
Yes, it works on a 1541. But right, it might be that it was copied with an 1541 in past with some Rapidlok-Copier or SC+.

Nevertheless, also the game writes on the disk. I know that in case of Rapidlok protections there is of course track 18 in cbm-dos format and additionally Track 0 and Track 1 cbm-dos format for saving scores and hall of fame infos.

I cant believe that all my drive are misalligned. Especially the TEAC reads and writes Defender of the Crown perfectly.

Can I send the raws of Gunship to have a look?

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: C64 dumping

Post by IFW » Fri Apr 05, 2013 10:55 am

Sure, but if the track contain bad sectors, and eventually that bad sector is being accessed by the RapidLok loader it will lock up/crash as a nice way of informing the user about the disk error ;)

malers
Posts: 17
Joined: Sun Apr 08, 2012 2:00 pm

Re: C64 dumping

Post by malers » Sat Apr 06, 2013 10:16 am

Mail sent

Post Reply