Info on copy protection?
Michael Saunders
Many years ago, I used to really enjoy the subject of copy
protection on my C64. My favorite util was Fast Hack'em
combined with an Icepik cartridge. I even bought a book
through mail order (there were 2 volumes) which explained
the subject and gave examples (I still have it somewhere in
my piles of boxes I hope!) With this book, I eventually
created a copy-protection method that Fast Hack'em couldn't
nibble as a personal "fun" project.
Anyway, with the increasing use of copy protection on modern
CD-ROM's, I have gotten back to thinking of this stuff (it's
funny, the schemes on CD-ROM's are like the *very* early
C64 methods which used bad blocks. History is repeating...)
Is there an archive of information on C64 copy protection
information? I'm more interested in the information itself,
since I can understand the "small world" of a c64/1541 as
opposed to the 100meg+ stuff today. I just find the subject
very iteresting, plus, it's a neat game of "cat and mouse,"
between the protection developers and copiers. Anyone know
what Mike J. Henry (Fast Hack'em) is doing these days?
Any other cool "nostalgia" info like this?
One scheme in particular that I remember started coming onto
the scene at the end of my C64 days. It reportedly wasn't
copiable without adding RAM to the 1541 because the key track
was so complex. I don't remember what games I saw this on,
or the name of the scheme, but I do remember that it was
by "Harold Seeley" or something very similar. Anyone remember
or know anything about this one?
Kinda a strange request, in these days of C64 emulators and
all, but I can't find much info on this subject at all... :^(
Thanks,
Mike
mics...@holly.colostate.edu
Forrest
On 9 Oct 1999, Michael Saunders wrote:
> One scheme in particular that I remember started coming onto
> the scene at the end of my C64 days. It reportedly wasn't
> copiable without adding RAM to the 1541 because the key track
> was so complex. I don't remember what games I saw this on,
> or the name of the scheme, but I do remember that it was
> by "Harold Seeley" or something very similar. Anyone remember
> or know anything about this one?
>
Hi Mike,
That protection would be the later variation of V-Max protection, created
by Harald Seeley. There have been a few variations of this protection
that I've seen. The earliest I think was from about 1985, I have a copy
of Star Rank Boxing that uses it, and it was fairly easy to duplicate.
Then around late 1986, early 1987 came another variation that was more
complex. Games like Defender of the Crown, Bop N Rumble, Howard the Duck
used this protection. Then around 1988 another version of V-Max appeared,
the one that you're mentioning, that requires having extra RAM in your
1541 drive in order to duplicate. Alot of companies ended up using this
on their games, I have a few. The Three Stooges, Arkanoid 2, Alien
Syndrome, etc..
later
Forrest
Forrest
But what you're describing is basically cracking the game, and I don't
think he was saying the protection was uncrackable. The extra RAM
was needed if you wanted a duplicate of the disk with the protection
intact. I've never seen a way to duplicate the protection without extra
RAM in the 1541 anyway.
Forrest
On Sun, 10 Oct 1999, Dahl wrote:
> About that "uncopiable" protection-scheme. Well, it was copiable. I didn't
> make a "straight-off" copy from the disk but modified the loader-code on the
> c64 to send all the files to my REU, hence made them copiable. The only
> thing to do next was to save them to disk, level-pack them and modify the
> loader to read the files with standard ROM-routines and decompress. Fairly
> easy I'd say.
Cameron Kaiser
>used this protection. Then around 1988 another version of V-Max appeared,
>the one that you're mentioning, that requires having extra RAM in your
>1541 drive in order to duplicate. Alot of companies ended up using this
>on their games, I have a few. The Three Stooges, Arkanoid 2, Alien
>Syndrome, etc..
This later V-Max was also notoriously incompatible with fastloaders because
of its drive RAM usage. FastLoad, which downloads a small routine to drive
RAM before it executes LOADs, does not like "V-Max 3" much at all. Neither
does my Final Cartridge 3.
I'm curious about your Three Stooges. While I'll need to dig my originals
out to be sure, I don't remember it using V-Max. DotC does definitely. :-)
--
Cameron Kaiser * cka...@stockholm.ptloma.edu * posting with a Commodore 128
personal page: http://calvin.ptloma.edu/~spectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/~spectre/cwi/ **
Joseph Fenn
created on cbm software? If so give the DSI programs
Pocket Writer 64&128
Pocket Planner 64&128
To my knowledge nobody ever had succeeded on these. Elite v3
did it but only to the extent that a full disk fast copier
could duplicate them easily to another disk, but a type of
non standard tracking and sectoring remained which prohibits
their use on CMD devices Ramlink etc. Elite V3 was a product
of kracker jax boys.
Joe (aka kilroy)
Maurice Randall is still attempting on this but no luck so far!!!
--
************************************
* jf...@lava.net *
* Ham KH6JF (since '37) *
* MARS (AARS) ABM6JF (since '40) *
* WW2 Vet ARMY SIGNAL CORPS *
************************************
Dahl
Forrest
On 9 Oct 1999, Cameron Kaiser wrote:
> Forrest <fem...@divms.uiowa.edu> writes:
>
> >used this protection. Then around 1988 another version of V-Max appeared,
> >the one that you're mentioning, that requires having extra RAM in your
> >1541 drive in order to duplicate. Alot of companies ended up using this
> >on their games, I have a few. The Three Stooges, Arkanoid 2, Alien
> >Syndrome, etc..
>
> This later V-Max was also notoriously incompatible with fastloaders because
> of its drive RAM usage. FastLoad, which downloads a small routine to drive
> RAM before it executes LOADs, does not like "V-Max 3" much at all. Neither
> does my Final Cartridge 3.
Actually, I don't think any of the versions of V-Max work very well with
fastload carts. All of the V-Max protected games I have refuse to load
with my Epyx Fastload cartridge plugged in. Even disabling the cartridge
after turning on the computer doesn't work.
>
> I'm curious about your Three Stooges. While I'll need to dig my originals
> out to be sure, I don't remember it using V-Max. DotC does definitely. :-)
>
I think all of Cinemaware's games used V-Max protection. DoTC used an
earlier version of V-Max like I mentioned that didn't require any extra
drive RAM to duplicate. All of their other games needed more RAM (3
Stooges, Sinbad, Rocket Ranger) to make a duplicate. One redeeming
quality of V-Max is that it loads extremely fast.
If someone feels up to the task, a sixpacker that would use the extra 8k
of drive RAM would be a very useful utility. Then it may be possible to
convert these games into .g64 format. Currently I don't know of any way
to do it though, the standard sixpacker isn't able to read the data off of
any of the tracks other than track 18.
Forrest
Nicolas Welte
>
> But what you're describing is basically cracking the game, and I don't
> think he was saying the protection was uncrackable. The extra RAM
> was needed if you wanted a duplicate of the disk with the protection
> intact. I've never seen a way to duplicate the protection without extra
> RAM in the 1541 anyway.
It'll probably work with Burstnibbler 1.9 and a parallel cable. But I'm
not sure if this program is compatible with NTSC machines. If anybody
want's to try it, the program is on funet and the cable is described on
sta.c64.org in the StarCommander cable section. Works great with 1541
and 1571 drives.
Nicolas
Radioactive Warrior
BN 1.9 does not work on NTSC. I have a PAL unit that I was using to test
Burst Nibbler 1.4 - 1.9 and all will copy Pocket Writer/Planner, no problem
but the V-max v3+ variants refuse to copy with any Burst Nibbler version I
have. RAMBoard (as has been mentioned) is the only thing I have that will
copy V-MAX v3. I have cracked, among others, Alien Syndrome using the
method Nicolas described. I am sure there are V-MAX boot makers in exestance
but I don't know where to find any. One guy I know might have some of them
(you out there, Mad Max?) but I suspect most are filed away under obsolete
in some software houses basement...
If anyone has detailed info on V-MAX v3 - v7 please post it. If anyone has
detailed info on the RAMBoard coppier, please post that.
And if anyone wants to help me NTSC fix BN 1.9 Email me.
poof,
Zak mailto:rad...@mindspring.com
Cameron Kaiser
>>This later V-Max was also notoriously incompatible with fastloaders because
>>of its drive RAM usage. FastLoad, which downloads a small routine to drive
>>RAM before it executes LOADs, does not like "V-Max 3" much at all. Neither
>>does my Final Cartridge 3.
>Actually, I don't think any of the versions of V-Max work very well with
>fastload carts. All of the V-Max protected games I have refuse to load
>with my Epyx Fastload cartridge plugged in. Even disabling the cartridge
>after turning on the computer doesn't work.
No, actually, both DotC and Three Stooges (still haven't checked if it's
V-Max) boot just fine on my Epyx FastLoad system. Arkanoid doesn't. I always
got a sick feeling when I saw that triumphant blue "V-MAX!" appear on the
screen, something like the feeling I get from the old EA loader.
Joseph Fenn
not remove the protection or standardize the tk/wectors therefore
nothing hacked with burstnibler will run in any CMD device including
Ramlink/Hard drives/fd2000 or 4000 series.
Joe
(ps elite v3 was better than burstnibblers because it removed
enough of the protection so you could fast copy any dsi stuff
with any disk copier, but again useless for CMD stuff)
uh1_...@my-deja.com
Michael Saunders <mics...@holly.ColoState.EDU>
wrote:
> Hi,
>
> Many years ago, I used to really enjoy the
subject of copy
> protection on my C64. My favorite util was
Fast Hack'em
> combined with an Icepik cartridge. I even
bought a book
> through mail order (there were 2 volumes) which
explained
> the subject and gave examples (I still have it
somewhere in
> my piles of boxes I hope!) With this book, I
eventually
> created a copy-protection method that Fast
Hack'em couldn't
> nibble as a personal "fun" project.
Finally a similar minded soul! I was always (and
still am) fascinated by copy protection... my
friends used to say that I bought c64 games just
for the protection ;-) I had an obsession with
nibblers - had (and still have) many software
copiers and hardware like super snapshot/burst
nibbler etc. I also remember creating my
own 'uncopiable' protection that I used to dare
my friends to copy with software nibblers - it
was designed from succesful elements of many copy
protected games (such as Epyx Championship
Wrestling track 18 - had a specific pattern of
various 21/23 errors which resulted somehow
(never really understood why - can someone fill
in here?) in a corrupted track if read by most
software nibblers. The funny thing is the track
would be readable (without errors of course) if
you copied it with a fast copy type program (i.e.
not a nibbler). In fact if memory serves me right
the only software nibbler that would nibble it
correctly was Copy II 64 (Central Point
Software? - the one Jim Drew wrote).
> Anyway, with the increasing use of copy
protection on modern
> CD-ROM's, I have gotten back to thinking of
this stuff (it's
> funny, the schemes on CD-ROM's are like the
*very* early
> C64 methods which used bad blocks. History is
repeating...)
Copy protection never goes away... although some
modern cdrom protection goes beyond simple 'check
for bad areas of the cd' method.
> Is there an archive of information on C64 copy
protection
> information? I'm more interested in the
information itself,
> since I can understand the "small world" of a
c64/1541 as
> opposed to the 100meg+ stuff today. I just
find the subject
> very iteresting, plus, it's a neat game of "cat
and mouse,"
> between the protection developers and copiers.
Couldn't have said it any better. I've never seen
any websites relating to c64 copy protection, and
I'm seriously thinking about doing or at least
helping someone start one, before what remaining
knowledge evaporates out of my mind ;-)
The problem, is what free hosting service or ISP
will host a page will unprotect info & c64 disk
images, both original & cracked D64s? I'd guess
most non c64 users would view this as WaReZ type
material, but *I* think it's important to
preserve this knowledge..
Anyone know
> what Mike J. Henry (Fast Hack'em) is doing
these days?
> Any other cool "nostalgia" info like this?
>
> One scheme in particular that I remember
started coming onto
> the scene at the end of my C64 days. It
reportedly wasn't
> copiable without adding RAM to the 1541 because
the key track
> was so complex. I don't remember what games I
saw this on,
> or the name of the scheme, but I do remember
that it was
> by "Harold Seeley" or something very similar.
Anyone remember
> or know anything about this one?
This would have to be the legendary V-MAX!
protection scheme. Anybody have any info on how
schemes like RapidLok & V-MAX! worked? Anyone
have books like Kracker Jax Revealed or Program
Protection Manual that they wanna part with?
Kevin.
uh1_...@email.com
Sent via Deja.com http://www.deja.com/
Before you buy.
Nospam9212
Date: Wed, 13 October 1999 12:04 PM EDT
>I've never seen any websites relating to
>c64 copy protection, and I'm seriously
>thinking about doing or at least
>helping someone start one, before what remaining
>knowledge evaporates out of my mind ;-)
I was thinking of putting up some copy-protection info on my C= Web site but
thought it had been pretty much played out. If anyone wants to write something
up, I am willing to put it out there.
>This would have to be the legendary V-MAX!
>protection scheme. Anybody have any info on how
>schemes like RapidLok & V-MAX! worked?
I never really got the hang of V-MAX! I did figure out it was doing it's thing
in drive memory, but could not do much with it. I simply used various V-MAX!
copiers and left it alone. So.. how it worked, I am not sure... I know where it
where it worked, but can't shed much light on how....
Now.. RAPID-LOK was rather fun. It was the first scheme that took me beyond the
simple drive-error/BNE/BEQ type protection.
Here is how I understand it...
There is a "key" placed on a non-standard track and used to time the data reads
from the disk. Disk tracks have a non-standard format (still GCR I would
assume) and the data from those tracks were read by using precise timing and
stepping the drive head at just the exact data byte. It was very important to
RAPID-LOK that your drive speed was correct, because the timing/stepper moves
relied on a specific rpm. If the drive speed was off, the stepper motor moved
the read/write head, but the data byte that the head expected would be
incorrect and would not return the correct byte. The real protection was the
"key" that was put on (usually) track 36, and the track layout. GUNSHIP would
not load on three different 1541, until I sat there with a small screwdriver
and kept adjusting the drive speed a little at a time. As a matter of fact...
it was a good method of setting my drive speed !!!!!!!
What I found amazing (at that time) was that some of the tracks on a disk may
have been RAPID-LOK format and some may have been standard 1541. I should say
that track 18 HAD to be standard 1541 format and normally the "loader" was on a
standard layout track, also.
I have a few good RAPID-LOK and V-MAX! copiers available if anyone wants them
on a Web site, just say so and I will make it so....
>Anyone have books like Kracker Jax Revealed or Program
>Protection Manual that they wanna part with?
I do have the Kracker Jax Trilogy but have no desires to ever part with it :)
It does state the developers of V-MAX! claim it is a fast-load system and NOT a
copy-protection scheme... I say... "yea..right!!!!"
It has been a long time since I did any work with copy-protection on a C64, so
if any of this info is incorrect or anyone can add to, please do.
-= Francis Yarra =-
http://members.aol.com/fyarra
uh1_...@email.com
nospa...@aol.com (Nospam9212) wrote:
> I was thinking of putting up some copy-protection info on my C= Web
site but
> thought it had been pretty much played out. If anyone wants to write
something
> up, I am willing to put it out there.
Cool, I'll take you up on that offer... I have some protection
explanations written up on paper somewhere, just have to type them up...
> I never really got the hang of V-MAX! I did figure out it was doing
it's thing
> in drive memory, but could not do much with it. I simply used various
V-MAX!
> copiers and left it alone. So.. how it worked, I am not sure... I
know where it
> where it worked, but can't shed much light on how....
Same here.
> Now.. RAPID-LOK was rather fun. It was the first scheme that took me
beyond the
> simple drive-error/BNE/BEQ type protection.
I remember buying Avantage's Spy vs Spy 1&2 and trying to make a copy
with the nibblers I had at the time, only to have the drive head step
out to Track 36 (like it usually did) but it didn't stop! Kept hitting
the head stop (past Track 40) looking for the data that was supposed to
be on Track 36. I still remember that awful noise it made ;-) Bought
Kracker Jax's Super Shotgun II nibbler (which had RapidLok copy
capability) and it worked fine. It's only then I figured out that Spy
vs Spy was RapidLok protected, I was wondering why none of the other
nibblers I had worked ;-)
And speaking of BEQ/BNE protection the first game that I figured out
how to crack was Mastertronic's Vegas Jackpot which had the protection
routine (standard U1 error seek) in ML. Before that I unprotected Strip
Poker ;-) which if I remember correctly was written in Basic and had
the classic Rem Shift L unlist protection... he he, ah, the good old
days... <sigh>
> I have a few good RAPID-LOK and V-MAX! copiers available if anyone
wants them
> on a Web site, just say so and I will make it so....
Won't mind taking a look at these if only to bring back memories....
> I do have the Kracker Jax Trilogy but have no desires to ever part
with it :)
Anybody willing to scan them it? (I am!) I am *dying* to take a look at
it....
> It does state the developers of V-MAX! claim it is a fast-load system
and NOT a
> copy-protection scheme... I say... "yea..right!!!!"
Vorpal was a fast load system too.... but IT could be copied ;-)
> It has been a long time since I did any work with copy-protection on
a C64, so
> if any of this info is incorrect or anyone can add to, please do.
>
> -= Francis Yarra =-
> http://members.aol.com/fyarra
BTW is your site down?
Markus Brenner
>This would have to be the legendary V-MAX!
>protection scheme. Anybody have any info on how
>schemes like RapidLok & V-MAX! worked?
There are different versions of v-max. The simple one just reads continually
data from a track, EORing together two consecutive bytes each and stores those
in floppy memory (this bascially is the floppy part of the fast loader).
Usually this track was on track 20 (at least on those 'Thunder Mountain'
disks). Additionally they used nonstandard bit-rates on the higher tracks,
something a normal copy wouldn't easily copy, too.
The tougher v-max protection (and also RapidLok) actually change the format of
*the data* on the disk. RapidLok basically throws away every third bit in a
GCR byte stream, thus implementing its own GCR encoding (IIRC). I'm not sure
about the tougher v-max version, but I assume it's something very similar.
cheers,
-markus
----
Markus Brenner -==(UDIC)==- Net boy, net girl
AKA \\// Send your impulse 'round the world
Minstrel Dragon (\/) Put your message in a modem
Polite Squirrel \/ and throw it in the Cyber Sea (Rush)
Lord High Mucketty-muck of the UDIC Greybeards (tm)
email: mar...@brenner.de * WWW: http://www.biochem.mpg.de/~brenner/
Josh Payne
David Thom and Vic Numbers, c 1984 by PSIDAC. It's got all sorts of
goodies, programs, discussions and such on Protection methods for disks,
cartridges and tapes, autorun booters, memory maps of c64 and 1541, etc...
It sounds like what you may be looking for, let me know if you're
interested.
-----------------------------------------
remove X's to reply via e-mail
<uh1_...@my-deja.com> wrote in message news:7u2ai9$t3f$1...@nnrp1.deja.com...
> Couldn't have said it any better. I've never seen
> any websites relating to c64 copy protection, and
> I'm seriously thinking about doing or at least
> helping someone start one, before what remaining
> knowledge evaporates out of my mind ;-)
>
> The problem, is what free hosting service or ISP
> will host a page will unprotect info & c64 disk
> images, both original & cracked D64s? I'd guess
> most non c64 users would view this as WaReZ type
> material, but *I* think it's important to
> preserve this knowledge..
>
> Anyone know
> > what Mike J. Henry (Fast Hack'em) is doing
> these days?
> > Any other cool "nostalgia" info like this?
> >
> > One scheme in particular that I remember
> started coming onto
> > the scene at the end of my C64 days. It
> reportedly wasn't
> > copiable without adding RAM to the 1541 because
> the key track
> > was so complex. I don't remember what games I
> saw this on,
> > or the name of the scheme, but I do remember
> that it was
> > by "Harold Seeley" or something very similar.
> Anyone remember
> > or know anything about this one?
>
> This would have to be the legendary V-MAX!
> protection scheme. Anybody have any info on how
> schemes like RapidLok & V-MAX! worked? Anyone
> have books like Kracker Jax Revealed or Program
> Protection Manual that they wanna part with?
>
> Kevin.
> uh1_...@email.com
uh1_...@email.com
bre...@biochem.mpg.de (Markus Brenner) wrote:
> There are different versions of v-max. The simple one just reads
continually
> data from a track, EORing together two consecutive bytes each and
stores those
> in floppy memory (this bascially is the floppy part of the fast
loader).
Is this before or after GCR decoding? Won't this EOR storage method
occupy more disk space (special disk format) than a 'normal' format?
> Usually this track was on track 20 (at least on those 'Thunder
Mountain'
> disks). Additionally they used nonstandard bit-rates on the higher
tracks,
> something a normal copy wouldn't easily copy, too.
One thing I never understood about non-standard density - why was it
not possible to autodetect what the density rate was? I know Shotgun &
other nibblers like Superkit had autodensity options, but did they
actually work?
> The tougher v-max protection (and also RapidLok) actually change the
format of
> *the data* on the disk. RapidLok basically throws away every third
bit in a
> GCR byte stream, thus implementing its own GCR encoding (IIRC). I'm
not sure
> about the tougher v-max version, but I assume it's something very
similar.
Thanks for the info Markus. One of these days when I have the time I
may just have a look at v-max and/or rapidlok in more detail (after I
give the Inside C= dos chapter on GCR a good read!) ;-)
I've been doing some more thinking about c64 copy protection, and I
remember there were 2 games (still have the originals) that I was never
able to make a working backup. I've tried with Burst Nibbler v1.7 &
Supercard (forgot the software version). The 2 games were Last Ninja 3
(System3 - English black disk with purple silkscreen) which presumably
used a protection method called "Para-Protect" (said so in the
directory listing) and Gauntlet 2 (Mindscape - not sure what this
used). Both games apparently checked a single track (or possibly
halftrack), but both used the plain old C= dos disk format.
Markus Brenner
>> data from a track, EORing together two consecutive bytes each and
>stores those
>> in floppy memory (this bascially is the floppy part of the fast
>loader).
>
>Is this before or after GCR decoding? Won't this EOR storage method
>occupy more disk space (special disk format) than a 'normal' format?
This _IS_ GCR decoding! :) As this is only used for a short floppy program
(about $0400 bytes) the $800 GCR bytes needed for this technique easily fit
into one track. Plus, the this is very fast, so the 1541 program can do the
GCR decoding 'on the fly', while reading the bytes. Here's a code example:
(courtesy Thunder Mountain: Pole Position)
$0765: a0 00 LDY #$00
$0767: 98 TYA ; initialise byte = 0
$0768: a2 02 LDX #$02 ; read two GCR bytes
$076a: 50 fe BVC $076a ; wait for byte
$076c: b8 CLV ;
$076d: 4d 01 1c EOR $1c01 ; EOR together two GCR bytes
$0770: ca DEX ;
$0771: d0 f7 BNE $076a ;
$0773: 91 30 STA ($30),Y ; resulting byte -> destination
$0775: c8 INY ; increment destination
$0776: d0 f0 BNE $0768 ;
Of course the GCR bytes have to be cleverly encoded that this works (and the
GCR bytes are still conform with the floppy requirements). Normal copy
programs and even simple nibblers choke on that kind of long-track, because it
doesn't completely fit into the floppy RAM.
>One thing I never understood about non-standard density - why was it
>not possible to autodetect what the density rate was? I know Shotgun &
>other nibblers like Superkit had autodensity options, but did they
>actually work?
It should be auto-detectable. Provided that the blocks in this track are
error-free. Still, you might be able to read wrong bitrate-tracks in _some_
sectors, the boundaries between bit-rates doesn't seem to be very broad, so it
isn't either OK or bad, but there's grey area of 'looks good for some blocks'
;) However I'm no expert in writing copy programs, and neither hardware 1541
expert, so this isn't a very precise anwer ;)
>I've been doing some more thinking about c64 copy protection, and I
>remember there were 2 games (still have the originals) that I was never
>able to make a working backup. I've tried with Burst Nibbler v1.7 &
>Supercard (forgot the software version). The 2 games were Last Ninja 3
>(System3 - English black disk with purple silkscreen) which presumably
>used a protection method called "Para-Protect" (said so in the
>directory listing) and Gauntlet 2 (Mindscape - not sure what this
>used). Both games apparently checked a single track (or possibly
>halftrack), but both used the plain old C= dos disk format.
Hm, reminds me of Baker St. 221B. This game also uses normal C= DOS, but it
extremly packs the floppy RAM (with a similar method as described above), and
it is quite a task replacing the custom GCR loading scheme by normal DOS
functions. If you got disk images of those games maybe you can send them over
and I'll have a look.
uh1_...@email.com
bre...@biochem.mpg.de (Markus Brenner) wrote:
> This _IS_ GCR decoding! :) As this is only used for a short floppy
program
> (about $0400 bytes) the $800 GCR bytes needed for this technique
easily fit
> into one track. Plus, the this is very fast, so the 1541 program can
do the
> GCR decoding 'on the fly', while reading the bytes.
Oh. Duh. Like I said, I *really* need to read about GCR encoding ;-)
> ;) However I'm no expert in writing copy programs, and neither
hardware 1541
> expert, so this isn't a very precise anwer ;)
Actually you sound pretty expert to me!
> Hm, reminds me of Baker St. 221B. This game also uses normal C= DOS,
but it
> extremly packs the floppy RAM (with a similar method as described
above), and
> it is quite a task replacing the custom GCR loading scheme by normal
DOS
> functions. If you got disk images of those games maybe you can send
them over
> and I'll have a look.
Will do, assuming bitrot hasn't claimed them yet ;-\
Kevin.
Jim MacKenzie
C64 diskettes? Did they use custom-made Commodore computer setups? Or did
they just use expensive disk duplicating machines that could copy *any*
data? If so, would you be able to get such a duplicator cheap now that
5.25" diskettes are obsolete? Curious...
Jim
arc...@delphi.com
I'm not sure how the big companies did it, I assume they used a
mass duplicator that could read all the individual bits and
duplicate them exactly anywhere on the disk. Maybe someone else
can elaborate on this.
-
With my Wheels disk, they are produced with an MSD-2 disk drive
and made using an original unprotected master disk. Folliwng
Following that, they are placed in a 1541 and a special program
then runs in the 41 to place the copy protection on the disk.
The program will ask for the next disk when finished and will
increment the ID number, making each disk unique. All I have
to do is enter the starting number when I make a batch of disks.
It takes the 41 about 7 or 8 seconds to do its part of the job.
-
-Maurice
Eyeth
that was probably used by a small software house. It was a compaq
'luggable' and had a small monitor and two disk drive bays. It can copy
any GCR format diskettes from Apples, Ataris to the Commodores,
including copy protection schemes. Quite cool, and I believe that the
unit I saw wasn't for sale, unfortunately. :(
-Todd Elliott
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
c...@cmdweb.com
<j...@dusykbarlow.sk.ca> wrote:
>To ask a dumb question... how did software vendors duplicate copy-protected
>C64 diskettes? Did they use custom-made Commodore computer setups? Or did
>they just use expensive disk duplicating machines that could copy *any*
>data? If so, would you be able to get such a duplicator cheap now that
>5.25" diskettes are obsolete? Curious...
>
>Jim
Large software houses used commercial disk duplicators with
autoloaders, and in some cases may have farmed the job of duplicating
out to dedicated duplication houses.
When I was at Abacus, one of my jobs there was the maintenance of the
duplicating equipment. Most of our Commodore disks were done on a pair
of duplicators that were slaved to IBM PC's and used 'Ghostwriter'
copying software. The drives in these duplicators had been modified to
handle GCR copying, and along with the software these were capable of
handling most forms of copy-protection. The disk images were stored as
image files on the PC's, and loaded as needed for a given run. Each of
these machines had a 50-disk autoloader 'IN' bin, and had separate
'PASS' and 'FAIL' bins. I believe these units cost somewhere in the
area of about $3500 each.
We did have one title that could only be produced on an older
stand-alone PDP-11 based copier, and for that one we had to use three
disks to initialize the copy process... I'm not sure what the first
disk contained (possibly format information), the second was the disk
to be copied, and the third had copy protection information. Once
these were read into the machine it could then produce as many disks
as you wanted, though the bin size was limited to 25 disks.
We also had another disk which couldn't be copied on either of these,
but which copied fine using FAST HACK'EM on an MSD Dual drive, so
that's how we did that one.
There was also a 3.5" disk duplicator which was like the first two
described, and later Abacus bought a newer Unix-based system which
could slave several autoloaders and perform copy batches.
At CMD we have also have an autoloader with a 50-disk bin, but when we
got it, it was strictly for PC disks. We picked it up second-hand, but
it really hadn't been used at all by the owner, whom was someone we
know. Getting software and modifications from the company for this
machine to make it capable of duplicating Commodore disks would have
been fairly expensive, so instead we set about modifying it ourselves.
Like the ones at Abacus, it was designed to be controlled by a PC via
an RS-232 port. So we wrote software to control it from a Commodore
using a SwiftLink or Turbo232. We changed out the drive mech, and
installed a 1541 mech and controller. We interfaced to the disk
controller via a parallel cable attached to the User port on the
computer. We store the disk images on a CMD HD, and these are
downloaded into a RAMLink by the software, which then writes the data
to the drive via the User port parallel interface. It doesn't handle
much in the way of protection schemes, but it was designed to do the
GEOS disk protection.
For 3.5" disks (of which we do very little) we use a custom version of
the FD-2000 which has two drives attached to a single controller
board. This operates much like the MSD Dual drive did, though it is
dedicated strictly to the purpose. When turned on, it autoloads a
control program from a control partition on a high-density disk, then
blinks its lights to tell you its ready to make a copy. Once a
destination disk has been placed into the second drive it copies the
contents of a 1581 partition located on the first disk onto the disk
in the destination drive (formatting it as Double-Density, 1581).
Nospam9212
Date: Thu, 14 October 1999 10:51 AM EDT
>> thought it had been pretty much played out. If anyone wants to write
something
>> up, I am willing to put it out there.
>
>Cool, I'll take you up on that offer... I have some protection
>explanations written up on paper somewhere, just have to type them up...
Fine... let me know when you have them ready. Use this to E-Mail me...
fyarraATjunoDOTcom (AT=@ DOT=. of course)
>> I have a few good RAPID-LOK and V-MAX! copiers available if anyone wants
them
>> on a Web site, just say so and I will make it so....
>
>Won't mind taking a look at these if only to bring back memories....
I will dig them up and transfer them to my Web site.
>> I do have the Kracker Jax Trilogy but have no desires to ever part with it
:)
>
>Anybody willing to scan them it? (I am!) I am *dying* to take a look at it....
Gee... if I can find some time, I can scan some or all of it. I may not find
enough time to OCR it to text, though. If you can fire up an OCR app, I can
send ya some as I scan it.
I am not sure if this publication is still being sold or not, so I can't say
that I am willing to put it on the Web site, but who knows, it may be do-able
if anyone thinks it would be Ok.
I believe I have some other text files of interest on the subject I can put
up.. I'll check my C:\DOCS\C64 and see what I can find in there.
>> http://members.aol.com/fyarra
>
>BTW is your site down?
Damn !!!! I have a few Web sites and that addie is close but no cigar... try
...
http://members.aol.com/fyarra001
I did start a copy protection project just for the fun of it (educational
purpose). I used a "key" type scheme on track 36, that was EORed with 5 data
bytes in the tailgap of each sector and those data bytes were used to encrypt
the data as it was read into memory, in 256 byte blocks. The data blocks were
also stored backwards on the disk. I never really got it working as I wanted
(my ASM coding is not real good) and went on to bigger and better things, but
it did give me some idea as to what goes into copy-protection coding. Makes you
understand what is possible. Sort of the opposite of thinking like a
criminal... if I understood what goes in, it helped me to understand how to
"get it back out" !!!!
I can't say for anyone else, but I got more enjoyment out of ripping out the
copy protection than I did from some of the software itself !!!! :) I didn't
spread it, just liked the challenge !!!
Oh... did anyone ever try that CATWEASEL thingie for the PC ??? And if so,
could you make a dup of a copy-protected disk with it ???
bye for now...
-= Francis Yarra =-
http://members.aol.com/fyarra001 (yea that's it !!)
uh1_...@email.com
"Jim MacKenzie" <j...@dusykbarlow.sk.ca> wrote:
> To ask a dumb question... how did software vendors duplicate copy-
protected
> C64 diskettes? Did they use custom-made Commodore computer setups?
Or did
> they just use expensive disk duplicating machines that could copy
*any*
> data? If so, would you be able to get such a duplicator cheap now
that
> 5.25" diskettes are obsolete? Curious...
I remember reading in Ahoy! magazine somewhere that Basement Boys
software (Fast Hack'em) created all their production disks on a
modified MSD-2 drive. Which would make sense, since they probably
supported the MSD-2 better than other 3rd parties...
And I also remember reading about Chip Level Designs' (which included
some ex-basement boys programmers) software package which included an
additional 2k ram chip which plugged into an empty socket on the MSD-2
motherboard and was designed for the rapid copying of disks... I
wouldn't be surprised if many of the smaller vendors actually used MSD-
2 for dulpication.... I guess only the larger vendors could afford
those expensive duplicators w/ sort bins...
uh1_...@my-deja.com
nospa...@aol.com (Nospam9212) wrote:
> Fine... let me know when you have them ready. Use this to E-Mail me...
Will do...
> I will dig them up and transfer them to my Web site.
Okie dokie...
> >Anybody willing to scan them it? (I am!) I am *dying* to take a look
at it....
>
> Gee... if I can find some time, I can scan some or all of it. I may
not find
> enough time to OCR it to text, though. If you can fire up an OCR app,
I can
> send ya some as I scan it.
No probs, I wouldn't mind taking care of the OCR hassle....
I've also been thinking of scanning the copy of Inside C= Dos that I
have, but that book is huge.... the commented 1541 ROM disassembly is
half the book...
> I am not sure if this publication is still being sold or not, so I
can't say
> that I am willing to put it on the Web site, but who knows, it may be
do-able
> if anyone thinks it would be Ok.
I don't think there will be a problem with this. Software Support
International (distributors of Kracker Jax) no longer sells or deals
with C=... and they don't seem to mind all those copies of Maverick all
over the place ;-)
> I believe I have some other text files of interest on the subject I
can put
> up.. I'll check my C:\DOCS\C64 and see what I can find in there.
Will look for them...
> I did start a copy protection project just for the fun of it
(educational
> purpose). I used a "key" type scheme on track 36, that was EORed with
5 data
> bytes in the tailgap of each sector and those data bytes were used to
encrypt
> the data as it was read into memory, in 256 byte blocks. The data
blocks were
> also stored backwards on the disk. I never really got it working as I
wanted
> (my ASM coding is not real good) and went on to bigger and better
things, but
> it did give me some idea as to what goes into copy-protection coding.
Makes you
> understand what is possible. Sort of the opposite of thinking like a
> criminal... if I understood what goes in, it helped me to understand
how to
> "get it back out" !!!!
Yeah I enjoy the mindset of doing copy protection stuff... you almost
have to think like 2 different people...
> I can't say for anyone else, but I got more enjoyment out of ripping
out the
> copy protection than I did from some of the software itself !!!! :) I
didn't
> spread it, just liked the challenge !!!
Same here! Why reverse engineer? Just for the challenge!
> Oh... did anyone ever try that CATWEASEL thingie for the PC ??? And
if so,
> could you make a dup of a copy-protected disk with it ???
Eh? I'm not familiar with this - tell me more... PC disk protection is
a different kettle of fish... with no intelligent drive like the 1541
things look like they'd be harder to cover up what's going on...
uh1_...@my-deja.com
> I do have the Kracker Jax Trilogy but have no desires to ever part
with it :)
> It does state the developers of V-MAX! claim it is a fast-load system
and NOT a
> copy-protection scheme... I say... "yea..right!!!!"
Been digging thru the old floppies yesterday and found a copy program
called Diskmaker v3.3b (BASIX software). I'm not sure if it uses a non-
standard disk format (will check it this weekend, but if it isn't
anyone who is interested in V-MAX might find it interesting to look
at). On the title screen it lists "V-MAX! (c) 1985 by Harald Seeley".
The built-in fastloader is definately much slower than the later V-MAX
as used on Thunderblade, Rastan, Times of Lore, etc. Maybe the idea of
the earlier V-MAX versions was fastload, the protection developing
later? Anyone know where Harald Seeley is now?
Forrest
On Fri, 15 Oct 1999 uh1_...@my-deja.com wrote:
> > I am not sure if this publication is still being sold or not, so I
> can't say
> > that I am willing to put it on the Web site, but who knows, it may be
> do-able
> > if anyone thinks it would be Ok.
>
> I don't think there will be a problem with this. Software Support
> International (distributors of Kracker Jax) no longer sells or deals
> with C=... and they don't seem to mind all those copies of Maverick all
> over the place ;-)
>
Actually, I believe Centsible Software bought all of SSI's stuff when SSI
got out of the c64 business. So they may own the rights to it currently,
and they're still in business http://www.centsible.com
No idea if they'd care or not though, last time I checked with them about
Kracker Jax Revealed they didn't have any copies to sell.
later
Forrest
Forrest
On Fri, 15 Oct 1999 uh1_...@my-deja.com wrote:
That version of V-Max sounds like what is on my copy of Star Rank Boxing.
I think this version was mostly a fastloader because the protection
doesn't appear to be very strong, not compared to the other versions of
V-Max anyway.
Forrest
Anders M Montonen
> Jason Compton <jcom...@xnet.com> wrote:
> : By the way, Randy Harris, author of Bleem! (Playstation emulator for
> Oops. I meant Randy Linden.
The way I've heard it, this same guy also did the copy protection for
the Amiga's Dragon's Lair, which (AFAIK) holds the world-record in
remaining uncracked (over half a year is a long time for a game!)
-a
uh1_...@my-deja.com
"Radioactive Warrior" <nosmeg@radwarATmindspringDOTcom> wrote:
> BN 1.9 does not work on NTSC. I have a PAL unit that I was using to
test
> Burst Nibbler 1.4 - 1.9 and all will copy Pocket Writer/Planner, no
problem
> but the V-max v3+ variants refuse to copy with any Burst Nibbler
version I
> have.
Anyone know what the latest Burst Nibbler version that will run on NTSC
machine is (and where to get it?)
I think I used to use v1.8 (European version) on an NTSC machine and it
worked fine...
>RAMBoard (as has been mentioned) is the only thing I have that will
> copy V-MAX v3. I have cracked, among others, Alien Syndrome using the
> method Nicolas described. I am sure there are V-MAX boot makers in
exestance
> but I don't know where to find any. One guy I know might have some
of them
> (you out there, Mad Max?) but I suspect most are filed away under
obsolete
> in some software houses basement...
Ah, the hidden treasures that we seek....
> If anyone has detailed info on V-MAX v3 - v7 please post it. If
anyone has
> detailed info on the RAMBoard coppier, please post that.
I've got a RAMBoard - what info do you need to know?
I think RAMboard was a clone of Megasoft's Supercard 8k ram board...
used to be able to run Supercard software on it... then Megasoft
changed the design to prevent RAMboard owners from pirating the
Supercard software. The new version was called Supercard+, and while
I've never seen one I would assume the only thing different is the
memory range... the RAMboard/older supercard 8k ram starts at $8000 in
drive memory...
BTW anyone know where I can find the software that came with the
supercard? A D64 would be fine...
> And if anyone wants to help me NTSC fix BN 1.9 Email me.
I probably am of limited use in helping to fix, but I can test... ;-)
Kevin.
uh1_nivek%email%com (%=@ then %=.)
(damn spammers - you make one little NG post and they assume you are a
prime candidate for buying Viagra)
Michael Saunders
: Jason Compton <jcom...@xnet.com> wrote:
:> : By the way, Randy Harris, author of Bleem! (Playstation emulator for
:> Oops. I meant Randy Linden.
: The way I've heard it, this same guy also did the copy protection for
: the Amiga's Dragon's Lair, which (AFAIK) holds the world-record in
: remaining uncracked (over half a year is a long time for a game!)
I must admit that I don't know any of these people (the Bleem! guy,
Harald Seeley, Mike J. Henry), but if anyone has an opportunity to
communicate with any of these people (interviews, etc. like the
Bleem! guy), please, please see if they will contribute some knowledge
on the subject, or stories, or whatever.
It would be very cool to, for example, see if Harald Seeley would
publish his notes or comments or description on how V-Max was designed,
implemented, or whatever.
So, if you ever find anyone from this "scene," please remember to
ask them for some info!
Mike
mics...@holly.colostate.edu
Dan Barber
>If someone feels up to the task, a sixpacker that would use the extra 8k
>of drive RAM would be a very useful utility. Then it may be possible
Yes that would be cool. If I could code I would do it. Oh well. ;)
Dan Barber
d...@dbdigitalweb.com
V-MAX!
Anyway, I really only remember the fine details of the last one, but feel
free to ask
if you need help understanding how it works. I honestly don't know of
anything that
could copy it with a 1541/71 (even getting it professionally duplicated was
a real problem).
If it's keeping you from making archival copies of your legitimately
purchased
C64 software 12 years later, I guess it's outlived it's usefulness. ;-)
- Harald
uh1_...@my-deja.com wrote in message <7uin3l$ue8$1...@nnrp1.deja.com>...
>In article <7tqr4t$j85$1...@nntp2.atl.mindspring.net>,
> "Radioactive Warrior" <nosmeg@radwarATmindspringDOTcom> wrote:
>
>> BN 1.9 does not work on NTSC. I have a PAL unit that I was using to
>test
>> Burst Nibbler 1.4 - 1.9 and all will copy Pocket Writer/Planner, no
>problem
>> but the V-max v3+ variants refuse to copy with any Burst Nibbler
>version I
>> have.
>
>Anyone know what the latest Burst Nibbler version that will run on NTSC
>machine is (and where to get it?)
>
>>RAMBoard (as has been mentioned) is the only thing I have that will
>> copy V-MAX v3. I have cracked, among others, Alien Syndrome using the
>> method Nicolas described. I am sure there are V-MAX boot makers in
>exestance
>> but I don't know where to find any. One guy I know might have some
>of them
>> (you out there, Mad Max?) but I suspect most are filed away under
>obsolete
>> in some software houses basement...
>
uh1_...@my-deja.com
"V-MAX!" <email@address> wrote:
> Did I actually make 7 versions of V-MAX! ??? I forget...
Hiya Harald, glad you could join the party...
> Anyway, I really only remember the fine details of the last one, but
feel
> free to ask
> if you need help understanding how it works. I honestly don't know of
> anything that
> could copy it with a 1541/71 (even getting it professionally
duplicated was
> a real problem).
Hmmm... I've made backups of V-MAX titles like thunderblade, rastan,
arkanoid II using RAMboard & Supercard software, but it sometimes took
multiple attempts (and it's been awhile, but I seem to remember that
the higher tracks >20 were harder to write successfully)... in
particular V-MAX seemed to be rather picky about disk density, speed
etc. Maybe you could briefly explain the V-MAX system esp. in terms of
its copy protection abilities (like why it could not be copied with a
serial nibbler etc)? I (and many of the other copy protection
enthusiasts) would love to see some docs/explanations straight from the
source ;-)
> If it's keeping you from making archival copies of your legitimately
> purchased
> C64 software 12 years later, I guess it's outlived it's usefulness.
;-)
Heh, my Rastan & Arkanoid II originals are still going strong... but
that's only cause I play from the backups and never touch the
originals... But I honestly expect them to bitrot any day now...
Kevin M.
uh1_...@my-deja.com
V-MAX!
>In article <s1s2h9...@corp.supernews.com>,
>Hmmm... I've made backups of V-MAX titles like thunderblade, rastan,
>arkanoid II using RAMboard & Supercard software, but it sometimes took
>multiple attempts (and it's been awhile, but I seem to remember that
>the higher tracks >20 were harder to write successfully)... in
>particular V-MAX seemed to be rather picky about disk density, speed
>etc. Maybe you could briefly explain the V-MAX system esp. in terms of
>its copy protection abilities (like why it could not be copied with a
>serial nibbler etc)? I (and many of the other copy protection
>enthusiasts) would love to see some docs/explanations straight from the
>source ;-)
See the "Re:V-MAX! discussion" thread for more info....