Problems dumping games

[admin]

for example CalGames.g64:

Code:

0000:000a | 90 1F    <- max length in header ix 0x1F90
0000:000c | AC 02    <- track 1 is at offset 0x02AC
0000:02Ac | A9 20    <- track 1 contains 0x20a9 bytes, which is longer than the 0x1f90 specified in the header, and thus will not work

This is perfectly normal, and due to using the SPLICE mode.  Any disk that is not index aligned will not convert to .g64.  California Games is one of those.  When using INDEX mode (a requirement for .g64 conversion), the track length is capped at $1F68.

[jupp]

This is perfectly normal, and due to using the SPLICE mode. Any disk that is not index aligned will not convert to .g64. California Games is one of those. When using INDEX mode (a requirement for .g64 conversion), the track length is capped at $1F68.

not sure if its a good idea to produce broken images like that, or even use a hardcoded length in the header - the software should instead just put the length of the longest track into the header, at least then you can be sure that all other software is able to properly work with that image and not reject it because the image is broken. (that problem exists in all of the images above, btw, not just california games)

[admin]

You aren't suppose to be trying to make .g64 images from disk that were not created using the index mark to start/stop tracks. I want the image rejected. At some point I will add support for non-index'd disks.

[jupp]

then why not simply refuse to make this conversion step in the first place?

[admin]

There is currently no way to know if the disk was created using the index mark to start/stop tracks.

I have made a new version of the SCP software that caps the track length at the max length, but this is not going to fix anything when attempting to convert disks that were not index'd to begin with.

[jupp]

There is currently no way to know if the disk was created using the index mark to start/stop tracks.

how does that matter anyway, when the problem is that the flux dump was created using "splice mode"? surely you can detect that and then not convert it into a g64?

[SomeGuy]

I tried cleaning the game disks from the outside as best I could, but it made no real difference. I'm not going to go as far as cutting the disks, and cleaning the disk surfaces directly, as that destroys any value the disks had. The disks heads have been cleaned multiple times, especially after the worse disks (which tend to really screech) that still only seem to show garbage for the directory listing.

Unfortunately these disks really seem completely worthless, I got the games from a large batch of C64 disks (100+) on eBay, and looks like I'm going to have to put a claim in for a refund. I'm going to stick to only new disks, and tested disks on eBay in the future.

Thanks again, for the attempts to help.

I'd be curious to know what methods you tried to clean the disks.

I've made a bit of a hobby of grabbing crufty, often poorly stored disks off of eBay just to see if I can clean and read them. Unless they were quality disks and stored inside, random disks from eBay will all too often have readability issues without any cleaning, and may even destroy the disk.

In my experiments so far, I have had mixed results with just q-tips and alcohol. And surprisingly excellent luck rinsing the disks with warm tap water (if you are careful, you can avoid getting the labels wet).

[Kirben]

I tried using cotton buds and Q-Tips over the disk surface, while slowly rotating the disks. Also I tried putting a few drops on the surface, and used the Disk Speed Test option, to try to spread it around that way too. The worst disks continue to make screeching type noises at times, even after cleaning though, so seem to be very bad.

The disks seem to be have been stored very closely together for a long time, which might have had negative effects on their data too.

I have avoided using water so far, since I read it could leave cracked mater on the disks.

[SomeGuy]

Also I tried putting a few drops on the surface, and used the Disk Speed Test option, to try to spread it around that way too.

From my own experiments, that can do a lot of damage. This spins the disk with much more friction between the surface and the jacket. - and you may still have loose dirt or other junk inside the jacket. For me, this technique usually creates a lot of small "spots" where it pulls up bits of the disk surface.

The worst disks continue to make screeching type noises at times, even after cleaning though, so seem to be very bad.

These wouldn't happen to be Wabash media? I had a bunch of Wabash disks that all did that, even after alchohol cleaning - until I rinsed them with warm water.

The disks seem to be have been stored very closely together for a long time, which might have had negative effects on their data too.

Normally, I say not to use a hair dryer on disks because it will warp the jacket. But if the disk jackets are crushed so that the cookie does not turn freely, or if the jacket makes excessive noise from the friction, then a few quick hot puffs form a hair dryer can intentionally warp the jacket just a tad to loosen things up. (Better ideas are always welcome.) Of course, the "professional" way would be to cut the cookie out and use a different jacket.

I have avoided using water so far, since I read it could leave cracked mater on the disks.

In *theory* tap water could leave sediment behind, that long term could scratch the disk. But from my experiences so far, I have had zero issue with this. There is more risk from the dirt, grime, and residue already inside the disk jacket. Your mileage may vary depending on what is in your tap water.

Id take one of these disks that still screeches, run warm (hot enough you can still comfortably touch it) tap water in around the hub on each side to rinse things out. Then carefully stick a couple q-tips in to the jacket around the hub to prop the jacket up for air circulation and place it in front of fan to dry.

You will need to periodically move the q-tips around to move the air flow around. If these are wabash disks, I suggest moving the q-tips frequently as the cookie in these seem to have a habit of sticking to jacket lining, which can rip off some of the magnetic material.

I'd bet that would get rid of the screeching, and improve the readability. Although I'd be worried that your previous attempts may have already done some damage.

[admin]

There is currently no way to know if the disk was created using the index mark to start/stop tracks.

how does that matter anyway, when the problem is that the flux dump was created using "splice mode"? surely you can detect that and then not convert it into a g64?

Yes, but it has not been a priority since I never intended to actually convert disks images for emulators.  At some point I will get around to making a routine that will handle SPLICE mode for conversion.