|
|
Joined: Sep 2008
Posts: 105
Senior Member
|
Senior Member
Joined: Sep 2008
Posts: 105 |
I recently got a Kryoflux and dumped all my C64 original game disks. I was surprised almost all of them were error free. I only included games with no hard errors and that worked in VICE. Only a few failed to work California Games, Into Eagles Nest, Renegade, and Skate or Die. I don't know if these were emulation related or that Kryoflux didn't dump the protection properly. I also imaged these games about 7 years ago using a modified 1541 drive with an XMP1541 cable and nibtools. At the time I imaged them none of the three would work in WinVice, CCS64, or MESS. I just retried them and none of them worked in WinVice (2.4), CCS64 (3.9.1) or MESS (0.154). You were able to get them to work in Vice? I just wanted to verify since you were questioning whether Kyroflux dumped the protection properly.
|
|
|
|
Joined: Jun 2001
Posts: 262
Senior Member
|
Senior Member
Joined: Jun 2001
Posts: 262 |
i only dumped the back side on disks that are known to have different content on the back side. I wasn't aware that any c64 disks had duplicate contest on the back of single sided games.
I don't think there's a way to hex-compare the contents of two g64 images since each dump is drastically different. Maybe there's a way to normalize the contents but nothing that i know of. Hex editors like Hex Workshop have a function to resynchronize the data when comparing files, so it would indeed be possible to locate the matching data even if it's stored in different places. In any case, if dumping each side gives drastically different results... then, technically, the dumps may not really be "complete" until both sides are preserved, right? What i was referring to is when dumping to g64 you never seem to get identical dumps. I assume this is due to imaging as GCR encoding rather then a plain sector dump. Because of the nature of dumping C64 disks with Kryoflux you either need a modified floppy drive. Or you need an index hole for both sides of the disk or you can't dump the back side properly. So i have to hole punch the disk sleeve if it doesn't already have an index hole for the back side. So unless i know the back side needs to be copied i'm hesitant to try just to find it's unformatted. Most disks note contents on both sides ones that don't i've checked online to see if there 1 or 2 sided. I did miss the back side for Shoot'em Up Construction kit i'll upload it later.
|
|
|
|
Joined: Jun 2001
Posts: 262
Senior Member
|
Senior Member
Joined: Jun 2001
Posts: 262 |
I recently got a Kryoflux and dumped all my C64 original game disks. I was surprised almost all of them were error free. I only included games with no hard errors and that worked in VICE. Only a few failed to work California Games, Into Eagles Nest, Renegade, and Skate or Die. I don't know if these were emulation related or that Kryoflux didn't dump the protection properly. I also imaged these games about 7 years ago using a modified 1541 drive with an XMP1541 cable and nibtools. At the time I imaged them none of the three would work in WinVice, CCS64, or MESS. I just retried them and none of them worked in WinVice (2.4), CCS64 (3.9.1) or MESS (0.154). You were able to get them to work in Vice? I just wanted to verify since you were questioning whether Kyroflux dumped the protection properly. The 4 games i listed did not work in Vice. I was contemplating whether it was an emulation issue or a dumping problem.
|
|
|
|
Joined: Sep 2008
Posts: 105
Senior Member
|
Senior Member
Joined: Sep 2008
Posts: 105 |
The 4 games i listed did not work in Vice. I was contemplating whether it was an emulation issue or a dumping problem. Gotcha.
|
|
|
|
Joined: Nov 2003
Posts: 804
Senior Member
|
Senior Member
Joined: Nov 2003
Posts: 804 |
What i was referring to is when dumping to g64 you never seem to get identical dumps. I assume this is due to imaging as GCR encoding rather then a plain sector dump. Yeah, the problem with dumping raw is you're trying to read everything including data that isn't really there. It's unreliable to read and hard to tell whether it's important or not. Good dumps not working in Vice are common, for example there was an assumption about how the data in the g64 was structured because it was how older tools generated them. New tools came along which generated valid files but those assumptions were no longer valid and the protection checks would fail.
|
|
|
|
Joined: Mar 2013
Posts: 331 Likes: 1
Senior Member
|
Senior Member
Joined: Mar 2013
Posts: 331 Likes: 1 |
What i was referring to is when dumping to g64 you never seem to get identical dumps. I assume this is due to imaging as GCR encoding rather then a plain sector dump. Yeah, the problem with dumping raw is you're trying to read everything including data that isn't really there. It's unreliable to read and hard to tell whether it's important or not. Okay, so... These dumps can't be verified against other dumps, then? How can we know that nothing went wrong and they're perfect? I'm confused now.
LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
|
|
|
|
Joined: Mar 2001
Posts: 16,911 Likes: 56
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 16,911 Likes: 56 |
Dumps done on drives without a hardware index hole sensor cannot be verified against each other, welcome to what we've been talking about for the last 2 years 
|
|
|
|
Joined: Mar 2013
Posts: 331 Likes: 1
Senior Member
|
Senior Member
Joined: Mar 2013
Posts: 331 Likes: 1 |
Well, I hope that somebody will eventually come up with a way to extract and preserve just the relevant (non-exclusively-physical) info from these, in a way that two dumps from two disks of the same version of the game will give the same results...
I mean, I'm sure that more difficult things have been achieved at this point.
LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
|
|
|
|
Joined: Nov 2003
Posts: 804
Senior Member
|
Senior Member
Joined: Nov 2003
Posts: 804 |
Well, I hope that somebody will eventually come up with a way to extract and preserve just the relevant (non-exclusively-physical) info from these, in a way that two dumps from two disks of the same version of the game will give the same results...
I mean, I'm sure that more difficult things have been achieved at this point. If you don't know how to achieve it, how can you make a judgement on whether it's more or less difficult than other things? Even with an index sensor you could have problems. There is nothing to say that the original disks were written synchronised to the index sensor & even if there were there might have been an offset. With a long track you can still end up being in the middle of data when the index pulse happens. It is essentially impossible to automatically dump every single game into a working and consistent image. You can try to build a system where the software analyses the data and recognises which game it is and re-masters it, but you have to do the original re-mastering by hand.
|
|
|
|
Joined: Mar 2013
Posts: 331 Likes: 1
Senior Member
|
Senior Member
Joined: Mar 2013
Posts: 331 Likes: 1 |
You can try to build a system where the software analyses the data and recognises which game it is and re-masters it This would also be useful for matching and verifying tape images, by the way. I guess it would be incredibly complicated to make such a thing? =\
LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
|
|
|
1 members (Vas Crabb),
20
guests, and
0
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums9
Topics9,086
Posts119,088
Members5,014
|
Most Online890 Jan 17th, 2020
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|
|