Archiving copy protected c64 disks

[wadzinsky]

I have been working on a program for Windows over the last year for repairing or adjusting NIB reads/images of copy protected c64 disks.  The goal was to be able to preserve original disks to be able to use in emulation or write working images back to disk for use on a real c64.

 

So far, the program can successfully reproduce the following protection methods..

 

V-Max (all versions)

RapidLok

Vorpal (EPYX -- California Games, Legend of Blacksilver, Wrestling, The Games - Summer/Winter Edition)

Pirate Slayer (EA)

Fat Tracks (EA/Activision)

Micro Prose (custom format)

Cyan Loader

Radwar

Rainbow Arts/Magic Bytes

GMA/Securispeed

 

To obtain (read/write) images from originals, Nibtools and a parallel modified 1541 drive or a 1571 drive with XUM (Zoom) Floppy is required (or you can find NIB images on various other sites)

The latest build of Nibtools can be found here https://github.com/rittwage/nibtools/releases/tag/20241120

 

You can grab the latest build of ReMaster here.

ReMaster Utility.7z

 

or check out my GitHub

https://github.com/DarylKrans/ReMaster-Utility

 

Thank you!

 

 

Edited December 1 by wadzinsky

[Albert]

I love the visual display of data on the floppy discs. Very cool. 

 

 ..Al

[wadzinsky]

I've seen images like this before on other websites but figuring out how to re-create it was almost as hard as learning all the various protection schemes.  It's one of my favorite things about this project, with the exception of finally being able to preserve my own private collection.

[Gordon Fecyk]

Doesn't Nibtools already do this? I've been using it to write out G64 images to an unmodified 1571 drive over XUM1541 - the USB version that works over IEC.

 

My thinking is avoiding having to modify a drive. Nibtools seems to work with the 1571 burst mode or some variant, removing the need for a parallel interface.

Edited November 26 by Gordon Fecyk
1571 not 1751 dur...

[R.Cade]

This is a great tool!

 

It fixes your images of the tougher protections that tend to miss short sync marks (detected as 9 bits instead of 10).

That plus the error checking makes it invaluable. 

It goes farther than what nibtools does, and it's not likely things I would ever add to it.

[wadzinsky]

It's not as good as Nibtools on standard protections.  ReMaster is much more specialized on specific protections that are harder to reproduce.  This tool is really for the images that Nibtools can't replicate with its generalized approach.

[wadzinsky]

2 hours ago, R.Cade said:

That plus the error checking makes it invaluable. 

 

Well....  The error checking only goes as far as Standard CBM format.  I haven't figured out any of the other GCR decoding routines for V-Max or RapidLok.  It can decode Vorpal, but still haven't figured out error checking on that yet

[Gordon Fecyk]

12 hours ago, wadzinsky said:

It's not as good as Nibtools on standard protections.  ReMaster is much more specialized on specific protections that are harder to reproduce.

The only thing I'd ask for then, is support for 1571 Burst Mode on the XUM1541 USB adapter, to avoid needing the parallel interface and using an unmodified 1571 drive. Might be able to take some inspiration and sample code from Nibtools.

[wadzinsky]

27 minutes ago, Gordon Fecyk said:

The only thing I'd ask for then, is support for 1571 Burst Mode on the XUM1541 USB adapter, to avoid needing the parallel interface and using an unmodified 1571 drive. Might be able to take some inspiration and sample code from Nibtools.

ReMaster only processes the NIB images and outputs a G64.  You still need to use nibwrite to write the image back to disk.

 

From my understanding from the author of Nibtools, the parallel modification was necessary for low-level reading/writing.  Standard CBM formatted disks could be written without a parallel mod, but data transfer at the GCR level required it.  This was nearly 20 years ago and I took it as gospel.  If 1571 burst mode can do low-level writing over the serial connection alone, then this would open the doors for many more enthusiasts who don't want to modify their old hardware.  I would LOVE to be proven wrong here!

 

However, there is a caveat.  The 1571 doesn't seem to have a way to adjust the drive speed for certain protections that can't be written at the standard 300rpm... (early V-Max and All later Vorpal)

 

I've included an image if you'd like to test this for me.  I found a way to reduce later V-Max titles to fit all the data within the 300rpm margins.  If this writes back (without parallel connection) and loads on a real 64, this is a game changer!

 

3 Stooges S1.g64

Edited November 27 by wadzinsky

[wadzinsky]

I didn't take region into consideration,  If you're not in the US, here's the PAL version

3 Stooges S1 (PAL).g64

[wadzinsky]

There's a new version on GitHub, I'll also post the executable here.

 

Changes..

Fixed a bug where de-selecting 'auto adjust' on V-Max v3 image caused the program to crash

Fixed a bug where de-selecting 'auto adjust' on Vorpal image caused the output image to be empty except for standard formatted tracks

 

currently working on..

Writing Vorpal images to disk currently has about a 70% success rate.  I'm unsure what the issue is, all output images work perfectly in Vice.  I'm working on a new method of reconstructing the tracks in a test build which has greatly improved the success rate, however the tracks are longer which requires even slower drives speed to write.   Test Build known issue --  Source Vorpal images CANNOT contain half-tracks (665k nibs), use NBZ files, or 330k NIB's instead.  (Work in progress, these bugs will eventually be worked out as I perfect the process)

 

This new version is 'lightly' tested.  Crashes are still possible.  If you encounter any problems, please inform me of the issue and send the image you were working with when the crash occurred.

 

Thank you!

 

Side note:  It would appear that a parallel modification is NOT needed for a 1571 drive when using XUM (zoom) Floppy.

 

ReMaster Utility (test build).7z

ReMaster Utility.7z

Edited November 28 by wadzinsky
The non-test build version displayed it was the test build. It was indeed, NOT the test build. New upload should correctly display in the title bar.

[Gordon Fecyk]

So far, so good. I tested the disk image attached alongside an image of a 1983 EA game.

 

The EA game worked as expected.

 

The test image wrote out using the unmodified 1571 drive, but wouldn’t run on a modified 1541-II drive. I think this is because of the unusual build, as it has a Mitsumi motherboard but a Chinon drive mechanism plus JiffyDOS. However, the unmodified 1571 read back the disk fine.

 

I’ll have to try an unmodified 1541 drive later on.

 

I forgot that Cinemaware did that goofy sight gag for their intro.

[wadzinsky]

2 minutes ago, Gordon Fecyk said:

The test image wrote out using the unmodified 1571 drive, but wouldn’t run on a modified 1541-II drive.

Many of the V-Max titles also look for extra drive RAM and will crash if it's detected.  I don't believe the game I sent checks for this, but I know for sure that Gauntlet does.

[Gordon Fecyk]

Maybe it doesn’t like JiffyDOS either, as an otherwise unmodified 1541 works fine. JiffyDOS causes the V-Max loader to freeze.

[Gordon Fecyk]

Here's the result of my testing with an unmodified 1571 floppy drive and XUM1541 USB adapter.

 

[wadzinsky]

1 hour ago, Gordon Fecyk said:

Here's the result of my testing with an unmodified 1571 floppy drive and XUM1541 USB adapter.

 

Oh my!!,  Does it still say C++ extensions enabled??  I really need to go through this some more.  I thought I removed that
Also, my dog is famous now!!

 

Thank You!

 

-- just noticed after pausing the video, you have v 1.0.0.1  (that explains it)  I'm still not adept on GitHub, there is an older version on the main page and I don't know how to get rid of it.

Edited November 28 by wadzinsky

[Gordon Fecyk]

1 hour ago, wadzinsky said:

just noticed after pausing the video, you have v 1.0.0.1

I got that from the C64 Preservation Project's website. 

[wadzinsky]

12 minutes ago, Gordon Fecyk said:

I got that from the C64 Preservation Project's website. 

Interesting.  

 

I've been in much communication with him throughout this project.  I even stole a bit of his code like GCR encode/decode routines and the math for drawing track data on the disk image.  If not for his immense help in learning the in's and out's of the 1541, this program would have been dead in the water.  I never knew he hosted the program.

I'm flattered!

[R.Cade]

1 hour ago, wadzinsky said:

Interesting.  

 

I've been in much communication with him throughout this project.  I even stole a bit of his code like GCR encode/decode routines and the math for drawing track data on the disk image.  If not for his immense help in learning the in's and out's of the 1541, this program would have been dead in the water.  I never knew he hosted the program.

I'm flattered!

I'm confused. There is nothing on my website about this.

 

I would be happy to host it, but I don't have a page for it currently.

 

[Gordon Fecyk]

Ok hang on I confused nibtools version with the ReMaster version. It was Nibtools I got from C64 Preservation, not ReMaster.

[wadzinsky]

4 hours ago, Gordon Fecyk said:

It was Nibtools I got from C64 Preservation, not ReMaster.

Haha, no worries.  

 

I've given a few test versions out to various people in the past, including R.Cade during various points of development.  I just wanted to make sure I didn't accidentally leave a "not suitable for children" version out in the wild.  Many frustrations have led to some un-friendly debugging text in the title bar

[+OLD CS1]

33 minutes ago, wadzinsky said:

Many frustrations have led to some un-friendly debugging text in the title bar

heheheheheh

[scotty]

Why not just use a Kyroflux?

 

[+OLD CS1]

6 minutes ago, scotty said:

Why not just use a Kyroflux?

Different tools for different purposes.  A XUM1541 (or ZoomFloppy) with a real 1541/1571 drive in combination with nibtools is a pretty powerful and useful setup.  Is there also any guarantee that a KryoFlux capture as a g64 (or converted to a g64) is any better than what this tool is designed to fix?

[wadzinsky]

4 hours ago, scotty said:

Why not just use a Kyroflux?

 

Very valid!

 

Short answer : 

I don't have one. I also don't own enough original disks to justify the price of sourcing an old 5.25" drive and the device itself.  I probably only own 4 original disks that can't be reproduced by standard means.

I am certainly interested in getting one sometime down the road though.

 

Long answer :

I've been fascinated with copy protection and encryption since I was very young.  Making ReMaster wasn't initially supposed to turn into what it did.  It started out as a crude program to find patterns in NIB files to try to make sense of what made these protections so different from standard Commodore floppies.  I was very curious of HOW something was able to be put on the disk, but not taken back off.  Through much research, I found that the 1541 disk drive had some flaws that made it unable to accurately read certain bit-patterns.  If three or more zero-bits were read in a row, the drive logic had a chance to return a '1', known as a "weak bit".  The drive logic also has special circuitry that takes over when 10 '1' bits in a row are read, everything else is ignored (from my understanding) until it reaches a '0' bit.  This is called the sync signal.  Because of this circuitry, it's impossible for the 1541 to accurately report how long the sync actually is.  MANY forms of copy protection rely on these two things.  The 1541 could write ANYTHING you told it to, but reading it back wasn't always as easy.

 

I wanted to find a way to reproduce these images using nothing but the actual Commodore disk drive 

 

I was told that making such a program to repair these inaccuracies would be very difficult. (yes, it was!) and it also required learning as much as I could about the different forms of copy protection.  Through months of research and hair-pulling, I found a way to find and replace or mimic these hard-to-read signatures to a close-enough form that when written back to disk on actual Commodore hardware, the protection would pass all the checks and your game would load.  AND.. It does it all without modifying any of the original code, so the images resemble very closely the data as it was on the original, without the need for special hardware.  Many of the copiers back in the day would partially 'crack' the loader routines to make it more forgiving.  ReMaster doesn't crack in any way, unless you want it to, but only on a few protections that there was sufficient documentation on how to do so.

 

In the beginning, this was all for my own personal knowledge but I soon realized what I had and how powerful it became, so I tried to make it as easy to use as possible and make it look as 'pretty' as I could.  You just drag an image in, click export, done!

Edited November 30 by wadzinsky