C64 dumping

All questions regarding the dumping of media go here.
malers
Posts: 17
Joined: Sun Apr 08, 2012 2:00 pm

Re: C64 dumping

Post by malers » Mon Apr 08, 2013 2:09 pm

I guess, it's track 3 on original disk which causes a non working dump. An error on it prevents proper dumping...

JanneG
Posts: 4
Joined: Thu Apr 25, 2013 7:15 am

Re: C64 dumping

Post by JanneG » Thu May 09, 2013 2:08 pm

>7. Once in a blue moon, you will encounter a disk that will display a track number
>warning, no matter what. The reason for that is the duplicator did not have a drive
>that could correctly go to -8, but the CBM drive will seek to the correct track anyway,
>as it reads the track position...


Here's an example of one such disk, Terry's Big Adventure by Grandslam.
When we first start dumping, the output looks like this:

--------
c:\C64\kryoflux\dtc>dtc -p -b-8 -fTerrysBigAdventure_/TerrysBigAdventure_ -i -i2 -y -g2 -i20 -l8 -t10
KryoFlux DiskTool Console, v2.20, uiv.1, Feb 22 2013, 18:52:16
(c) 2009-2013 KryoFlux Products & Services Ltd.
Developed by The Software Preservation Society, www.softpres.org
Licensed for private, non-commercial use only.

-8.1[00]: CBM TQ: <unformatted>
-6.1[02]: CBM TQ: <unformatted>
-4.1[04]: CBM TQ: <unformatted>
-2.1[06]: CBM TQ: <unformatted>
00.0 : Control command rejected by the device
00.0 : CBM TQ: <unformatted>
00.1[08]: CBM TQ: <unformatted>
02.0 : CBM TQ: <unformatted>
02.1[10]: CBM TQ: <unformatted>
04.0 : CBM TQ: OK*, trk: 003[001], sec: 21, *T
04.1[12]: CBM TQ: <unformatted>
06.0 : CBM TQ: OK*, trk: 004[002], sec: 21, *T
06.1[14]: CBM TQ: <unformatted>
08.0 : CBM TQ: OK*, trk: 005[003], sec: 21, *T
08.1[16]: CBM TQ: <unformatted>
10.0 : CBM TQ: OK*, trk: 006[004], sec: 21, *T
10.1[18]: CBM TQ: <unformatted>
12.0 : CBM TQ: OK*, trk: 007[005], sec: 21, *T
12.1[20]: CBM TQ: <unformatted>
14.0 : CBM TQ: OK*, trk: 008[006], sec: 21, *T
14.1[22]: CBM TQ: <unformatted>
16.0 : CBM TQ: OK*, trk: 009[007], sec: 21, *T
16.1[24]: CBM TQ: <unformatted>
...
--------

The resulting stream files and a .g64 converted from them will not work.
The .G64 conversion output shows that the first four tracks are unformatted:
--------
c:\C64\kryoflux\dtc>dtc -m1 -fTerrysBigAdventure_/TerrysBigAdventure_ -i0 -fdisk
.g64 -y -g2 -k2 -i22a -l8
KryoFlux DiskTool Console, v2.20, uiv.1, Feb 22 2013, 18:52:16
(c) 2009-2013 KryoFlux Products & Services Ltd.
Developed by The Software Preservation Society, www.softpres.org
Licensed for private, non-commercial use only.

00.0 : CBM GCR DATA: <unformatted>
00.1 : CBM GCR DATA: <unformatted>
02.0 : CBM GCR DATA: <unformatted>
02.1 : CBM GCR DATA: <unformatted>
04.0 : CBM DOS: OK*, trk: 003[001], sec: 21, *T
04.1 : CBM GCR DATA: <unformatted>
06.0 : CBM DOS: OK*, trk: 004[002], sec: 21, *T
06.1 : CBM GCR DATA: <unformatted>
08.0 : CBM DOS: OK*, trk: 005[003], sec: 21, *T
08.1 : CBM GCR DATA: <unformatted>
...
-------

So let's adjust the head offset:

--------
C:\C64\kryoflux\dtc>dtc -p -a+4 -b-8 -fTerrysBigAdventure/TerrysBigAdventure_ -i -i2 -y -g2 -i6 -l8 -t10
KryoFlux DiskTool Console, v2.20, uiv.1, Feb 22 2013, 18:52:16
(c) 2009-2013 KryoFlux Products & Services Ltd.
Developed by The Software Preservation Society, www.softpres.org
Licensed for private, non-commercial use only.

-8.1[00]: CBM DOS: <unformatted>
-6.1[02]: CBM DOS: <unformatted>
-4.1[04]: CBM DOS: <unformatted>
-2.1[06]: CBM DOS: <unformatted>
00.1[08]: Control command rejected by the device
00.1[08]: CBM DOS: <unformatted>
02.1[10]: CBM DOS: <unformatted>
04.0[00]: CBM DOS: OK, trk: 001, sec: 21
04.1[12]: CBM DOS: <unformatted>
06.0[02]: CBM DOS: OK, trk: 002, sec: 21
06.1[14]: CBM DOS: <unformatted>
08.0[04]: CBM DOS: OK, trk: 003, sec: 21
08.1[16]: CBM DOS: <unformatted>
10.0[06]: CBM DOS: OK, trk: 004, sec: 21
10.1[18]: CBM DOS: <unformatted>
12.0[08]: CBM DOS: OK, trk: 005, sec: 21
12.1[20]: CBM DOS: <unformatted>
14.0[10]: CBM DOS: OK, trk: 006, sec: 21
14.1[22]: CBM DOS: <unformatted>
16.0[12]: CBM DOS: OK, trk: 007, sec: 21
16.1[24]: CBM DOS: <unformatted>
...
--------

Looking good, and now we have a working dump of the disk! :)

Finally let's take a look at how the G64 creation looks like now, as opposed to how things were when the head offset was not adjusted:
--------
C:\C64\kryoflux\dtc>dtc -m1 -fTerrysBigAdventure/TerrysBigAdventure_ -i0 -fdisk.
g64 -y -g2 -k2 -i22a -l8
KryoFlux DiskTool Console, v2.20, uiv.1, Feb 22 2013, 18:52:16
(c) 2009-2013 KryoFlux Products & Services Ltd.
Developed by The Software Preservation Society, www.softpres.org
Licensed for private, non-commercial use only.

00.0 : CBM DOS: OK, trk: 001, sec: 21
00.1 : CBM GCR DATA: <unformatted>
02.0 : CBM DOS: OK, trk: 002, sec: 21
02.1 : CBM GCR DATA: <unformatted>
04.0 : CBM DOS: OK, trk: 003, sec: 21
04.1 : CBM GCR DATA: <unformatted>
06.0 : CBM DOS: OK, trk: 004, sec: 21
06.1 : CBM GCR DATA: <unformatted>
...
--------
Thanks to IFW for some guidance with this title :)

br
JG

rcade
Posts: 119
Joined: Mon Nov 21, 2011 5:21 pm

Re: C64 dumping

Post by rcade » Fri May 10, 2013 2:46 am

This has happened to me before and I wondered why it worked on the real thing, but not imaged in G64. The emulator doesn't seek out the track like a real drive, or didn't at the time.
-
Pete Rittwage
C64 Preservation Project
http://c64preservation.com

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

Re: C64 dumping

Post by IFW » Fri May 10, 2013 2:46 pm

Actually, shifted tracks work emulated these days.

It's worth keeping in mind that certain data - most notably weak bits - looks very different when read via 1541 vs reading with a normal drive, not to mention how this data should be represented in a g64 file; practically, generated when needed.
DTC only checks the correct track(s) for the weak bit protection used, as it's an expensive operation, so once the tracks are not in their correct positions, such protection will no longer be detected.

The more common thing is having a drive that cannot seek to track -8; the duplicator shifted the tracks on side 1 up in that case.

Additionally, both are duplication problems, that are not part of the process (hence we shouldn't keep it, as it's a defect) - the reason they got away with it was how the 1541 firmware seeks the target track without a track 0 sensor.

BarryB
Posts: 282
Joined: Thu Aug 02, 2012 8:15 pm

Re: C64 dumping

Post by BarryB » Mon Apr 21, 2014 1:53 pm

Just trying some test dumps of my C64 disks and happened on a flippy disk, The Three Muskeeters! When using the parameters in the manual for dumping flippy disks: dtc -p -b-8 -fttm\ttm_ -i0 -y -g2 -i6 -l8 -t10 I get this output:

-8.1[00]: CBM DOS: OK*, trk: 001, sec: 21, *H +14
-6.1[02]: CBM DOS: OK*, trk: 002, sec: 21, *H +21
-4.1[04]: CBM DOS: OK*, trk: 003, sec: 21, *H +15
-2.1[06]: CBM DOS: OK*, trk: 004, sec: 21, *H +21
00.0 : Control command rejected by the device
00.0 : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +15
00.0 : Bad sector found
00.0 : Control command rejected by the device
00.0 : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +15
00.0 : Bad sector found
00.0 : Control command rejected by the device
00.0 : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +15
00.0 : Bad sector found

Tried just a dump of side 0: dtc -fttm\ttm_ -i0 -i6 and got a good dump, converted to G64: dtc -m1 -fttm\ttm_ -i0 -fttm1.g64 -k2 -i22a -l8 and loads in WinVice SPS but asks to flip the disk.

Tried again but got the same problem and now the drive seems to be stuck as the head makes a loud machine-gunning noise and doesn't move? I've removed power to it, unplugged the USB and all cables and set it back up from scratch, floppy cable into Kryoflux/drive, USB into kryoflux then into PC and finally power to the drive, but as soon as I do that the I get the same load machine-gunning noise and have to remove the power! Any ideas?

*EDIT*
Managed to carefully rotate the stepper motor so the head has now moved forward, retried and it seems OK now. Have now managed to successfully dump The Three Musketeers, after numerous tries, as the drive seems a bit temperamental. Creating the .G64 files from the dump shows no errors and loads both images in WinVICE 2.4 SPS!

One other thing is when dumping the flippy, I always got '00.0 Control command rejected by the device', is that normal?

Rakki
Posts: 747
Joined: Fri Jun 03, 2011 8:29 pm
Location: Jyväskylä, Finland

Re: C64 dumping

Post by Rakki » Mon Apr 21, 2014 5:47 pm

BarryB wrote:Just trying some test dumps of my C64 disks and happened on a flippy disk, The Three Muskeeters!
00.0 : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +15
It might help to clean side 0 (=side B of the real disk as the drive head is below)) of disk with q-tips + IPA. Please bear in mind that some protections are recognized as "bad" tracks and still dump may be good despite of errors. Often reason is dirt etc. on the disk surface that must be cleaned off.
BarryB wrote: One other thing is when dumping the flippy, I always got '00.0 Control command rejected by the device', is that normal?
Yes it is completely normal.
Last edited by Rakki on Mon Apr 21, 2014 5:52 pm, edited 1 time in total.

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

C64 dumping

Post by mr.vince » Mon Apr 21, 2014 5:51 pm

The drive reports an error when stepping from -1 to 0. We could suppress it, but we do not.

What you have experienced is a problem we can not avoid: you stepped below 0, then aborted dumping. Because drives seek to 0 on power up, it seeks further into the negative domain. Simple solution: do not force quit DTC when it is in the negative domain. It will always step the head back to 0 a few seconds after processing has finished.

EDIT: As for errors... Yes, these can be due to protection, dirt/mould or age. Just imaging blindly duping such a disk on the flux level...

BarryB
Posts: 282
Joined: Thu Aug 02, 2012 8:15 pm

Re: C64 dumping

Post by BarryB » Mon Apr 21, 2014 6:03 pm

@Rakki: Visually the disk was perfectly clean, but have since managed to get an error free dump!

@mr.vince: Thanks for that tip regards negative domain, makes sense when it's explained, will CTRL-C from track 1 onwards from now on then there won't be a problem!

Also, is there a list of games and their copy protections? Have Ultima IV on 2 flippys and there's an error on the first disk, not sure if I need to use -i15 to -i20:

00.0 : CBM DOS: OK, trk: 001, sec: 21
00.1 : CBM DOS: OK, trk: 001, sec: 21
02.0 : CBM DOS: OK, trk: 002, sec: 21
02.1 : CBM DOS: OK, trk: 002, sec: 21
04.0 : CBM DOS: OK, trk: 003, sec: 21
04.1 : CBM DOS: OK, trk: 003, sec: 21
06.0 : CBM DOS: OK, trk: 004, sec: 21
06.1 : CBM DOS: OK, trk: 004, sec: 21
08.0 : CBM DOS: OK, trk: 005, sec: 21
08.1 : CBM DOS: OK, trk: 005, sec: 21
10.0 : CBM DOS: <error>, trk: 006, sec: 21, mis: 18
10.1 : CBM DOS: OK, trk: 006, sec: 21

Converting to G64 results in a non working image, Syntax Error when game has loaded and run!

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

Re: C64 dumping

Post by Edsel007 » Mon Apr 21, 2014 6:09 pm

Pete´s site is a great source for copy protections. I usually check there what -i flag to choose.
Ultima 4 should be fine with -i6, I think.

BarryB
Posts: 282
Joined: Thu Aug 02, 2012 8:15 pm

Re: C64 dumping

Post by BarryB » Mon Apr 21, 2014 8:39 pm

Edsel007 wrote:Pete´s site is a great source for copy protections. I usually check there what -i flag to choose.
Ultima 4 should be fine with -i6, I think.
Ultima IV is listed but doesn't have any info for it! Have read it used a track error for protection, which seems to be what DTC is telling us and the -i6 flag is echoing that but creating G64 images isn't working on this one so will have to try dumping just side 0 and see what that does!

Post Reply