C64 dumping

[mr.vince]

For dumping C64 disks, use the following command line:
dtc -p -b-8 -fdumpdir/<NameOfGame_> -i -i2 -y -g2 -i6 -l8 -t10

If you want to have a d64 simply change it to:
dtc -p -b-8 -f<dumpdir>/<NameOfGame_> -i -i2 -f<d64dir>/<nameofgame.d64> -y -g2 -i6 -l8 -t10

<NameOfGame_> is used for dumping so track files can't possibly get mixed up. The trailing _ just makes the file names tidy
NameOfGame is just whatever is written on the disk label as game title without spaces or special characters, without any copyright notices etc.
If it is a compilation and has disk numbers and titles I use the disk number:
e.g. CoinOpHitsII_Disk1_
If a compilation disk instead has a specific name:
e.g. MAX_NightShift_

If it is a standalone game just use the name as printed on the label:
e.g. DefenderOfTheCrown_Disc1_

If you use Total Commander, a quick check to do is the file number and sizes; you should have 168 files listed per disk, and you shouldn't encounter any 45 bytes long file; that's a transfer error.

Once a dump is complete just zip it up into a single archive for all disks belonging to the same title/compilation.

Things to watch out for - just in case, although you should have experienced some of it already...:

1. Don't run any other program in the background; it will result in the 45 bytes transfer error files eventually... We mean major applications here, not something that the OS would run anyway.

2. Some of our drives are known to show symptoms of static/overheating after a while - exact cause unknown, but if your drive has the same issue what you'd see is that known good disks will show errors despite the head being clean. Simply turn off the drive and wait a few minutes, it will "fix" it.

3. Many of the disks can be dirty, hard to read etc. IPA can be very handy for cleaning them - We use pure alcohol and destilled water or Servisol IPA 170 and it can help a lot.

4. Watch the output while dumping if it suddenly turns into something that looks suspicious chances are the head just got dirty. Do clean the drive head to prevent disk damage, then just start dumping a known good pre-formatted disk to verify the cleaning. Obviously clean the offending disk as well before using it again...

5. Always keep the command line as is, unless it's a multi-platform disk, e.g. Atari-8 bit plus CBM, in that case set the correct format for each side. Say side 0 is CBM and side 1 is A8 the format specification of the command line (after -i2) in the above example should look like this: -g0 -i6 -g1 -y -i3a -l8 -t10

6. If you keep on getting track number warnings, the head wondered off calibration. It can happen, if you break the execution below track 0.
Don't panic, just let the head move into the positive track domain, say until cbm track number 5 is being displayed, then reset the board using the small button on it. The next dump command will recalibrate correctly. It's easier to not break execution below 0 though

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...
When/if ever that happens change the command line to use the correct offset, both heads will have an offset in these cases.e.g. -a+2 -b-6 for a drive that could only go to -6. We've seen two such disks so far out of hundreds.

8. Warnings are marked with a * e.g. OK* <some info text> *T is a track number warning. Watch out for those and act if needed, e.g. stop/restart dumping. The number displayed for track is the expected track number, the actual track number found is also displayed in brackets.

9. To correctly identify SKUs it is very important to have the info file filled in, we've attached an example, Rambo.txt.
Additionally, please make a scan or photo at a resolution that keeps every text readable of:
- front of the disk/label.
- back of the disk only if it has any markings
- front and back cover of the box, ensuring any copyright and publisher notices and years remain readable
- front and back cover of the inlays, ensuring any copyright and publisher notices and years remain readable
- code sheets if supplied
- manual if small, or manual pages with any copyright/year notices

10. Try and use the correct format for dumping a disk and replace the -i6 CBM image type accordingly. That can save a lot on redumping
You can get a list of image types by using DTC -h command.
The ones interesting for pure c64 disks are: 6 (CBM), 15 (CBM MicroProse), 16 (CBM RapidLok), 17 (CBM Datasoft), 18 (CBM Vorpal)
For CBM plus other format disks you might need: 4 (MFM, for PC sides), 3a (Atari 8-bit)

11. As always please use the latest beta version of DTC and firmware.

12. Please mark dumped disks as such with say a number on the disk with a stick it note, so they won't get mixed up with undumped ones - I know it's common sense, but in some cases we had to redump quite a few copies of the same title to find the correct disk to redump, as the labels were identical, but only one of them was needed - so labelling dumped disks can save a lot of time occassionally

13. Skipped, for scientific purposes... it would bring bad luck!

14. Do a few test dumps that can be checked, just in case.

15. DTC can detect modification for most formats, but it is not possible to verify games that were not professionally duplicated (very few) and RapidLok titles, EU versions of Melbourne House games. Both RL and MH titles use recording that cannot be checked for modification so we need multiple dumps of those, everything else can be verified for modification from a single dump. One company known for using home equipment for duplication is Datasoft.
Modified tracks are marked with a + sign in the output and the number after the plus sign is the number of modified sectors.


***NEW ***

When you dump a disk with a custom format, you may get tons of unformatted tracks, tons of errors or a mix of these two depending on the custom format used on the disk.
In these cases the disk should be dumped with the correct guide format, replacing the -i6 parameter.

For a list of all CBM custom formats supported enter dtc -h.
All formats between 15 and 21 are custom CBM formats used by various disks.

In the case of Gunship it is RapidLok, so the correct -i value is -i16

To have a good idea of which publisher used which format(s) please try and use the table below.
It is very important to have custom format disks dumped using the correct format, so errors can be detected and retried.
When we encounter something that is not supported at all (yet!) we do a blind dump of the disk, reverse-engineer the format, add it to DTC then do a redump.
Unfortunately, apart from having a hunch of which game uses which format the only way to know is trial and error.
Note, that there are lots of variants of these formats which DTC automatically detects during dumping and selects - however it must know where to look first to be able to decide on the finer details.

Generally speaking:
- most Epyx games use Vorpal, apart from the very early ones using simple CBM (i6), US Gold published Epyx games are again either Vorpal or CBM.
- Digital Integration might have used Vorpal, unconfirmed yet. (ATF - Advanced Tactical Fighter)
- MicroProse used MicroProse or RapidLok or CBM (MP: Stealth Fighter, Airborne Ranger, RL: Gunship, Pirates...)
- Accolade/Avantage: RapidLok
- Activision: CBM, RapidLok (in the US), V-MAX!
- Access: CBM or RapidLok
- Teque on any game developed by Teque, e.g. many original Grandslam titles (Terramex, Thunderbirds, Munsters... probably all others undumped as well)
- TDP is only known to be used on Dragon's Lair and Escape from Singe's Castle
- Datasoft on almost all Datasoft titles
- V-MAX! Cinemaware, and lots of other games originating from the US; Taito, Mindscape, Origin, Activision, Discovery Software so far

[Feltzkrone]

If I can use unmodified 5.25" drives only for dumping, I obviously cannot use your command lines.

To make a dump of side 0 I'd use the following switches:
-fdir\game_ -i0 -fdir\game.d64 -g0 -i6 -s0 -e80

To make a dump of side 1 I'd use these switches:
-fdir\game_ -i0 -fdir\game.d64 -g1 -b-8 -y -i6 -s8 -e80

This gives me a dump with files named game_00.0.raw etc. as complete as possible with my drive. Additionally I get two images game_s0.d64 and game_s1.d64. And I use tee to catch the stdout and additionally put it into a .log file.

1. Will the first command line alone be sufficient for dumps of single sided games in order to be accepted by the SPS, i.e. if that is the only dump submission you have for a specific disk, will it be sufficient for the creation of an .ipf file? I guess it should as e.g. halftracks aren't dumped by default which might contain data aswell as tracks 76 to 81 (or 82) on the backside might contain data aswell (even if not intended to be read in 1541 drives) which would be skipped when using the -b-8 switch "blindly".

2. For double sided disks I'd use the second command line additionally just to provide dumps for CBM tracks 5 to 41 for verification purposes or for the case another dump submission lacks one of those tracks in good condition. Or would it be just of no value to you?

3. Is -t10 really needed? Woudln't it make more sense to even lower it from -t5 to say -t2 instead, i.e. leaving it to the user to review the log and re-dump erroneous or suspicious tracks with more retries. I just ask because I think 10 retries is too much for sectors damaged on purpose (part of a protection scheme), but on the other hand too less for tracks in really bad condition which might produce decodable data at e.g. the 23rd retry. Or more generally spoken: Do you require the dump being made in one pass with more or less exactly your command line switches or is many of that left to the user? Again, are dumping process deviations tolerated when it's about .ipf preservation?

4. Is it normal that e.g. on V-MAX! which uses data which violates the GCR rules (more than two consecutive zeroes) or normal CBM DOS data at the higher tracks (lower density), or in general when flux intervals of about 12 µs or greater appear (not really a non-flux "area"), at least HD drives are having problems reading those properly (random flux transitions reported where there aren't). I have made a dump of Defender of the Crown without using -i19 (scatter plot shows disk is in good condition) and afterwards tried running dtc on the dump with -i19 and it found CBM Track 20 to be erroneous. Before I knew about the #19 format I was working on a STREAM->G64 converter and ran into problems here, too, i.e. instead of having a value of 14 µs (4x 3.5µs) in the dump for two revolutions it is 7µs + 3µs + 4µs and for the other three it is 3.5µs + 7µs + 3.5µs. Sorry for getting into technical details here that much, but the question is: How can standard command lines used with standard HD drives provide good dumps for V-MAX! games then? Or does whatever tool you use in the STREAM->IPF process compensate for that?

Thanks for your help in advance.

[IFW]

TBH it would be really great to use a modified drive for dumping - it would be especially annoying if yours is the only dump of a game and we couldn't get a good or complete read of side 1
There are several people on the board who could try and help; either loaning a drive, dumping a disk, or helping modding the drive.
Using the command lines as per the original post does dump everything on the disk including half-tracks.
The key is the additional format without filename -i2. In theory that one would set all the parameters for CT RAW format - which was the tool we used for Amiga dumps if you remember. We don't really need the CT RAW files (they are useless in GCR world), but we do need the specific settings it provides - ie uncoditionally dump all tracks (regardless whether they get checked or not by the guide formats set), set revolutions, TPI etc.
1, In other words, your command produces different results, due to the lack of -i2. Please use the full command.
2, As above, if you have lots of c64 disk it would make sense to get a modded drive sorted out asap.
3, Yes, it is normally useful, especially when track 0 is protected - as changing the track domain also produces an error, probably due to signalling problems. At least use a -t paramater with even number of retries.
4, Yes, those things were all scripted when duplicated, ie never verified, just blindly written.
My drive seemingly has no problems reading at least 20us, but I guess it really depends on the filtering type used or even the age of electronics...
Regardless, C64 IPF generation will be scripted just like any other platform, hence the proper data wil be present.

[Feltzkrone]

Thanks a lot for explaining the -i2 thing. I'll try to sum it up (please correct me if needed):

1. If having many disks, try to get the disks dumped with a modified drive / with help of the people on the board
2. If no modified drive available, dump single sided disks using any reasonable command line* ("better than nothing"?)
3. Dump double sided disks with any reasonable command line or command line combinations* ("better than nothing"?)
4. Try to find out the protection and use the specific -i... switches when applicable as it might help overcoming problems with filtering or electronics

* Reasonable command lines must contain the -i2 switch and the -t10 switch, so that reading out half-tracks (odd tracks) is ensured for the disk side intended to be dumped and work around signalling problems.

I think there are many KryoFlux owners out there which would like to make a C64 disk dump occassionally and have a normal, unmodified 5.25" drive available - and I just wanted to find a way to dump everything which can be dumped with such a drive, but without asking the drive to seek to track -8 as it might cause problems.

[IFW]

Yes, pretty much. If you dump only a single side, you may want to enforce that with -g0 -i2 so -i2 does not enforce both sides either.

In your case, it should be a modded drive though for lots of originals
Additionally, some disks may have two index holes, those disks can be dumped by manually flipping the disk - however it is likely that the index position will be shifted by 180' as they were mostly duplicated in a single pass with modded drives.
Also, someone made a slightly different drive modification - which may be simpler if you no longer want to keep the original drive functionality, e.g. only use the drive for flippy dumping. I'll try to get him to post about it.

For normal c64 dumping, e.g. scene/homebrew/work/etc material I'd say just go for a fake index signal - it's only needed as on all the PC drives we tested the read line was not active until a ready state was detected, e.g. two index holes passed. Hence there is no support in DTC for dumping without index, as the drives themselves (at least the ones we had so far) don't supply data without having seen them.

[JohnF]

Also, someone made a slightly different drive modification - which may be simpler if you no longer want to keep the original drive functionality, e.g. only use the drive for flippy dumping. I'll try to get him to post about it.

You might be referring to me - I've posted some information in this thread: viewtopic.php?f=10&t=417

[IFW]

Yes, indeed and thanks for the post

[Feltzkrone]

And again two short ones (probably for IFW)...

1. If all .raw STREAM files originate from the same physical disk, may one or some of them be produced with a different drive? If read errors occur on one track when using one drive and later a different drive is used to retry reading the erroneous tracks for a bunch of dumps and it really succeeds, would that be ok as long as it's documented, e.g. in the "Extra Info" field in the info file?

2. Is it really needed to dump tracks 0 to 7 (i.e. -8 to -1) from the back side when all other tracks of the back side are unformatted (scatter plot = noise) and chances are great that the game uses the front side only (info on internet, C64PP, size of cracked versions)? I'm asking because I would like to protect the more valuable modified drive from defects caused by dirt or cracks on the disk surface which might not be obvious and therefore I would like to use that drive only, if really needed (and then maybe use it for the back side, tracks 0 to 7 only, in order to fill the gap? see 1.)

Thanks for clarification in advance!

(And the worst case already nearly happened while dumping the fourth disk with the drive. Despite of looking brand-new the disk had a crack on the higher tracks. :/)

[IFW]

1, Yes, DTC adapts the stream to the current drive speed (which varies from drive to drive) so it should be fine.
The only other problem that can happen is the jitter of the index signal - so it would make sense to make a complete dump of the disk with both drives just in case. The jitter itself is uniform to a specific drive, but depends on drive model/manufacturer/luck.

2, Yes, it would be useful TBH. We simply don't know what's there until it's dumped. There is a 99% chance in those cases, that it's nothing or DI, but... would hate to find out 20 years later that some data is missing

IPA is your friend for dirty/old disks, but it can be very time consuming - some disks I was working on for hours until we got a working dump... I usually try and rotate the disk for a complete revolution in its jacket these days before instering into the drive, to see if there is anything suspicious on the surface. I watch the index hole for a complete revolution for both sides and hold the disk under light so dirt/mould/dust etc is visible.

[mr.vince]

Post #1 updated, general information about protections used added.