V-Max! Discussion
Michael Saunders
of the V-Max! CP scheme with Harald. Let's try to keep on topic
here for ease of navigation and location of information.
To get things rolling and give us more to "chew on," since V-Max
is so mysterious:
How about a high-level description of the V-Max! features and
major points? Nothing as detailed as GCR formats or serial
communications protocols, but rather a list of features/etc.
like you would have used to sell the scheme to a publisher...
A little more detailed: What was required to duplicate the
V-Max disks? How are they mastered? This will help describe
some of the inner functionality of the scheme...
Some personal/historic stuff:
If you don't mind, what is the background of someone who
creates such a beast as V-Max!? I saw that you worked on
DiskMaker... What made you switch to "the other side" and
begin authoring protection, rather than making copiers?
Well, I'll limit my questions to that much for now. I don't
want to burn your whole night with dozens of questions! If
we can keep them in little chunks like this, it should make
it easier to respond, too.
Later,
Mike
mics...@holly.colostate.edu
V-MAX!
>like you would have used to sell the scheme to a publisher...
>
V-MAX! sales points (last version I built):
Holds more than a standard C64 disk. Uses only a couple pages
of C64 memory, while permanently freeing up all RAM under the
ROMS which don't need to be swapped in for loads. 10X - 15X faster
loads, 1541/1571 compatible. Reliable with older & out of spec drives.
"Protection" impossible to patch/break. Disks difficult to copy. Takes
less than 24 hours to turn around a gold master from the final product.
>What was required to duplicate the
>V-Max disks?
V-MAX!'s biggest weakness, there was only one commercial duplicator in
a northern suburb of Chicago that had equipment flexible enough to copy it!
> How are they mastered?
DiskMaker was mastered on a Dual Drive from MSD with a custom RAM expansion
added.
Commercial games were mastered on a C128 with 1571 (running at 295 RPM!) ,
custom modified with a
parallel disk drive connection, and (remote) access to the sync hole LED
signal.
>If you don't mind, what is the background of someone who
>creates such a beast as V-Max!?
I went to Germany on a vacation, and while there picked up Data Becker's
book
on the 1541 drive and ROM listings. Not long after,
I was hired to analyze 3rd party copy protection, write
a fast loader for, and copy protect Basix' product. I'd learned to write
assembly code by cracking early C64 software, and I understood
the hardware side from my early days as a reader of the "Byte"
columns of '73 magazine. (Those columns eventually gave rise
to the magazine of the same name).
>I saw that you worked on
>DiskMaker... What made you switch to "the other side" and
>begin authoring protection, rather than making copiers?
>
I was really disappointed by some of the lame attempts to copy protect
most commercial games at the time; they showed such little
imagination. RapidLok had not yet made it's appearance,
and the only clever 1541 programming I had seen up to that time
was the work of Scott Nelson ( of FastLoad and Vorpal fame).
So I decided to try and build a better mousetrap, and guess I managed
to do a reasonable job, if we're still talking about it now! Mostly, it
was for the fun and challenge of it. My first sale was to Scott Orr at
Gamestar for Star Rank Boxing. (You may have heard of his name
before, he went on to build EA Sports into a household name, as the
Exec Producer of Madden Football.) That sale lead to sales to Cinemaware,
which lead to Origin and Mindscape, which lead to Taito ......
Forrest
Well it is possible to make duplicates of the disks using V-MAX on a real
c64 if you add extra RAM to your 1541 drive, but the big problem
we're facing today seems to be getting the disks into a format that would
be useable by a c64 emulator.
Sure there are cracked versions of all the games floating around, but the
originals are so much better because V-MAX loads so fast. And it seems
like a ton of games released in the US between 1988-1989 used V-MAX.
It was a great copy protection though, I would assume there were so many
different variations because people found ways to crack the protections.
I think the 7 or so variations of V-MAX is about right, there were also 6
variations of Rapidlok I think. In the end though, none of the
protections were uncrackable (although I could have never done it :)
Did any companies ever come back to you afterward demanding to know why
cracked versions of their games were floating around after you said in
your "sales pitch" that the protection was impossible to patch/break?
Just curious.
Forrest
Michael Saunders
Harald,
In the Kracker Jax Revealed book, they mentioned that "the
author" of V-Max! only intended it to be a fast-loader (but
they were "skeptical" :^)
Is there any truth to that statement? It seems that as
thorough as V-Max seems to be, it just had to be designed
from the ground-up as a protection scheme first and foremost...
Mike
mics...@holly.colostate.edu
Michael Saunders
Harald,
I've tried to format these questions for easy replying:
-----------------
What feature or event in your copy-protection past are you
most proud of?
What was the most difficult part to implement?
What is the general (main) protection in V-Max!? I'd assume
the custom formatting, but who knows?
What is the "behind the scenes" operational process for
V-Max!? (ie. the sequence from loading the booter up to
the main program execution)
When a company requested your service to protect their program,
did you require changes to their "main" code, or is V-Max!
more like a "wrapper"?
Was the copy prtection business "good to you" at the time?
Forgive me if that is too private to answer -- I'm just curious
what they had to pay for licensing on a top-notch scheme like
V-Max!...
What was the process for mastering a disk using V-Max!
Did you have to provide special parameters to the copy-house,
or was their equipment good enough to simply copy whatever
you gave them?
-----------
Well, that's it for now (grin)... We'll get to the beefy GCR
and code related stuff after we've laid the foundation with
these higher-level questions. Plus, it's neat to hear the
"personal" side of the story, too.
Mike
mics...@holly.colostate.edu
Michael Saunders
:>What feature or event in your copy-protection past are you
:>most proud of?
:>
: I was really happy with all of the subtlties of the final version, but
: explaining that woud be very technical and lengthy. Short of that,
Hmmm... if you've got the time... :^) That's the kind of
interesting stuff we can only hear from author(s)! Most of
the people here who are following this discussion (and you're
all welcome to help me-out with some questions!) are at least
familiar with protection concepts and maybe, many years ago,
some of use did a little cracking or writing of our own
protections. Don't be afraid to get technical -- if you've got
the time.
By subtleties, I assume that you mean the little tricks that
serve to piss-off/irritate the crackers -- like encryption,
self-modifying code, etc.?
I remember your work in Defender of the Crown. It was such
a big deal to have the high-quality music playing WHILE the
disk was loading. All that on 1MHz...
:>What is the general (main) protection in V-Max!? I'd assume
:>the custom formatting, but who knows?
:>
: The disappearing sync bytes
Tell me more! I'm hungry!!! :^)
:>What is the "behind the scenes" operational process for
:>V-Max!? (ie. the sequence from loading the booter up to
:>the main program execution)
<snip informative/cool stuff>
: out to the next track, and load up the "real" drive OS using our
: (basic) custom 2 for 1 GCR encoding, which allowed simple and quick
: "on the fly" decoding (and which defeated most early copy programs all
Was this the every-other sector load and then EOR them together,
or am I thinking of something else? I'm getting hungrier for
some beefy details...
Did you basically reproduce all of the calls (or re-map) from
DOS to allow the protected programs to run unmodified, or just
a standard subset (load, save, etc.)?
: They had some guideline to follow (like only 2 letter filenames), but
Is this simply an efficiency decision (to save bytes on the
disk), an arbitrary limitation in the V-Max code, or simply
to make it more difficult for crackers to locate the names
since they aren't long strings?
: That's a relative assesment. The game's busines is a lot "better" to
: me now, but I wouldn't be here if I hadn't gone therer first.
Interesting... what's your role in the game business, now that
copy-protection and similar low-level routines are no longer
used (at least, like they once were)?
: Over 2
: years time, we received royalties on a couple million C64 disks, not
: bad considering we started by working out of a two bedroom apartment
: at the time.
Hell of a lot better than any of my inventions have done for me!! :^)
: By the end, it was pretty automatic. Put the original in one drive
: after running the (copy protected) mastering program, and a blank in
You protected the protection program -- that's understandable,
but still sounds funny. Kinda like the various copier programs
that were protected... I guess that if anyone were able to copy
the mastering program, it would impact your bottom-line.
You said earlier that you used a 1571 with an external tap on
the sync hole LED. How does that fit into the greater V-Max!
scheme of things?
: Well, lest I be accused of forgetting the obvious, there were other
: "personell" involved. Like Peter and Marty, who helped me develop
hehehe... I've got Marty on my target list to "interview" also!
One obvious question that I've forgotten so far: What is the
significance of "V-Max!"? Velocity Maximizer?
What do you think is the primary factor in V-Max! that kept
the crackers from easily breaking the code? At some point,
the data must be exposed for the CPU to execute -- it's
amazing that more people didn't trace the code to this point --
you must have some good tricks in there!
If one were interested in getting "into" a V-Max! game and
seeing what was going on, would you have any recommendations
to make the exploration easier?
---------------
Well, I think that's all I'll bother you with tonight... Thanks
very much for taking the time to particpate in the newsgroup!
I must admit, you are somewhat of a copy-protection idol to
those of us who really like the subject! Maybe I'll try to a
hold of Marty and see if he'd like to help you answer all of
my questions... :^)
Good night,
Mike
mics...@holly.colostate.edu
V-MAX!
wrote:
>
>Well it is possible to make duplicates of the disks using V-MAX on a real
>c64 if you add extra RAM to your 1541 drive, but the big problem
>we're facing today seems to be getting the disks into a format that would
>be useable by a c64 emulator.
True for earlier versions of V-MAX!, but the last version would have
been a real challenge, even for me (and I knew all the tricks).
However, I have to admit, I could have done it. So I will accept that
others did.
>
>Sure there are cracked versions of all the games floating around, but the
>originals are so much better because V-MAX loads so fast. And it seems
>like a ton of games released in the US between 1988-1989 used V-MAX.
>
The cracked version I saw of Defender of the Crown was missing the
most important disrobing scene!! Typical solution when you couldn't
fit all the data on the cracked disks was to leave stuff out...
>It was a great copy protection though, I would assume there were so many
>different variations because people found ways to crack the protections.
Yes, it was an ongoing battle, but not just to make the protection
stronger. To make the loadig times faster, the footprint in memory
smaller, and the install process easier and more automatic was also a
big priority. As was reliability, and compatibility with the 1571,
the pesky "updated" (cost reduced) C64 and 1541's.
>I think the 7 or so variations of V-MAX is about right, there were also 6
>variations of Rapidlok I think. In the end though, none of the
>protections were uncrackable (although I could have never done it :)
>
The final version wasn't a "protection", but a replacement DOS. As
such, it was integral to the products. You could have substituted
another DOS (like VORPAL), but you would have had difficulty finding
one that could have stored nearly as much on the disk (it certainly
held more than Rapidlok). Of course, if the game wasn't taking
advantage of the extra storage space, then any DOS would do. But
games that filled up the disk, they were pretty solidly protected.
>Did any companies ever come back to you afterward demanding to know why
>cracked versions of their games were floating around after you said in
>your "sales pitch" that the protection was impossible to patch/break?
Only the last version had that claim, and I made it clear what they
needed to do (fill up the disk) in order for the claim to hold.
Couldn't do much for games which fit into RAM, like PacMan. But no,
no one ever complained, as the protection worked much better than
anything else they had tried. Generally, if 6 months went by before a
copier came out that could copy their game, they were ecstatic. My
former employers at Basix continued to crack Rapidlok, but they didn't
have as much success with my stuff <grin> .
>Just curious.
>
>Forrest
>
V-MAX!
<mics...@holly.ColoState.EDU> wrote:
>Michael Saunders <mics...@holly.colostate.edu> wrote:
>
>Harald,
>
>In the Kracker Jax Revealed book, they mentioned that "the
>author" of V-Max! only intended it to be a fast-loader (but
>they were "skeptical" :^)
>
>Is there any truth to that statement? It seems that as
>thorough as V-Max seems to be, it just had to be designed
>from the ground-up as a protection scheme first and foremost...
>
>Mike
>mics...@holly.colostate.edu
>
On DiskMaker, V-MAX was conceived as just the name for the fast
loader. Once I took off on my own, I integrated the copy protection.
On DiskMaker, I wrote some of the protection, as did the guy who
actually wrote the copier. That way, it was so well protected,
nothing else could copy it. The idea was, if our protection was
better than that of the competing products, that proved we knew more
about CP and therefore must have the better product. Buy ours, you
could then copy theirs.....
After I split from Basix, I only used the protection-less version of
V-MAX! on Origin's "Times of Lore". Everything else, the protection
was integrated with the DOS.
V-MAX!
<mics...@holly.ColoState.EDU> wrote:
>Michael Saunders <mics...@holly.colostate.edu> wrote:
>
>Harald,
>
>I've tried to format these questions for easy replying:
>-----------------
>
>What feature or event in your copy-protection past are you
>most proud of?
>
I was really happy with all of the subtlties of the final version, but
explaining that woud be very technical and lengthy. Short of that,
making a very early version work with interrupts turned on, so that a
very involved music driver could play while loading in "Defender", and
still keeping all of the performance goals intact (faster than
FastLoad, more storage than regular DOS, reliable but difficult to
copy)
>What was the most difficult part to implement?
>
reliability, those belt drives had terrible wow and flutter specs.
>What is the general (main) protection in V-Max!? I'd assume
>the custom formatting, but who knows?
>
The disappearing sync bytes
>What is the "behind the scenes" operational process for
>V-Max!? (ie. the sequence from loading the booter up to
>the main program execution)
>
Load into the stack, over-writing the stack and interrupt vectors,
with a small bootstrap program which included a bi-directional serial
transfer routine, clamp the nmi line down (to defeat early snapshot
devices), then load a smal bootstrap program into the drive memory.
It in turn would load and send down a more sophisticated (bigger and
faster) serial transfer routine to the C64, after first uploading some
of the crucial vectors from the C64 to the drive. Then it would step
out to the next track, and load up the "real" drive OS using our
(basic) custom 2 for 1 GCR encoding, which allowed simple and quick
"on the fly" decoding (and which defeated most early copy programs all
on it's own.). This track also held the actual disk directory. Next,
the loader would download the game's main kernal file, then retrieve
the saved vectors from the drive and restore them on the C64. Finally,
the game's main entry point would be pushed on the stack, and the
routine allowe to "return".
Note - they didn't all work like that, but as I recall that was
typical for the final version...
>When a company requested your service to protect their program,
>did you require changes to their "main" code, or is V-Max!
>more like a "wrapper"?
>
They had some guideline to follow (like only 2 letter filenames), but
in general they were free to do anything they wanted, as long as they
didn't store stuff in the stack. As I recall (and I could be wrong on
this, it's only been 12 years!), they just used Commodore's normal
load routines, our routines just replaced the vector to point into our
own code. However, we may have patched their calls within their code
directly, in some cases. I've forgotten, actually...
V-MAX! could either just load a file, or load and execute at a
specified address. This was something that the user could specifiy at
conversion time.
>Was the copy prtection business "good to you" at the time?
That's a relative assesment. The game's busines is a lot "better" to
me now, but I wouldn't be here if I hadn't gone therer first. Over 2
years time, we received royalties on a couple million C64 disks, not
bad considering we started by working out of a two bedroom apartment
at the time.
>Forgive me if that is too private to answer -- I'm just curious
>what they had to pay for licensing on a top-notch scheme like
>V-Max!...
A couple thousand to install the protection (we originaly only charged
a couple hundred, but raised it over time), and then a small royalty
to the publisher, plus another royalty from the duplicator (gave us a
way to verify publisher's numbers, haha!) who we supported not only
with instructions on how to duplicate, but also products to QA their
disk dupication runs.
>
>What was the process for mastering a disk using V-Max!
>
By the end, it was pretty automatic. Put the original in one drive
after running the (copy protected) mastering program, and a blank in
the modified drive. List the files on the original, flag the boot
file and any other auto-executing files, enter their execution start
addresses (as I remember, they could also be "run" via a call to the
basic ROM), and press "GO".
>Did you have to provide special parameters to the copy-house,
>or was their equipment good enough to simply copy whatever
>you gave them?
We only worked with one copy house, where we wrote the "script" whcih
drove their duplication equipment for them. They paid us well, we
gave them the best support possible, we were both extremely happy
together.
>
>-----------
>
>Well, that's it for now (grin)... We'll get to the beefy GCR
>and code related stuff after we've laid the foundation with
>these higher-level questions. Plus, it's neat to hear the
>"personal" side of the story, too.
>
Well, lest I be accused of forgetting the obvious, there were other
"personell" involved. Like Peter and Marty, who helped me develop
V-MAX! from what you saw on Star Rank Boxing, to the final utility
which saw mass acceptance. Don't know what became of Peter, but Marty
went to Sega, then 3DFX (after we both left Taito, but that's another
story!)
>Mike
>mics...@holly.colostate.edu
>
Forrest
On Tue, 2 Nov 1999, V-MAX! wrote:
> The cracked version I saw of Defender of the Crown was missing the
> most important disrobing scene!! Typical solution when you couldn't
> fit all the data on the cracked disks was to leave stuff out...
Yeah, I remember that version of DOTC, I think ESI did another crack a
little bit later that fixed the problem. But the original is still
superior because of the V-MAX fastloader. But yeah, thats a pretty good
idea for protection, fill the entire disk, up to track 40 and the
directory track, and then see if you can fit the cracked version back onto
two disk sides.
Although ESI did end up cracking California Games (vorpal protection) and
ended up putting it on 3 disk sides, so I guess there are limits to that
type of protection. The original was only 2 sides.
> Only the last version had that claim, and I made it clear what they
> needed to do (fill up the disk) in order for the claim to hold.
> Couldn't do much for games which fit into RAM, like PacMan. But no,
> no one ever complained, as the protection worked much better than
> anything else they had tried. Generally, if 6 months went by before a
> copier came out that could copy their game, they were ecstatic. My
> former employers at Basix continued to crack Rapidlok, but they didn't
> have as much success with my stuff <grin> .
>
Hehe, its funny you mention stuff like PacMan, because I remember Thunder
Mountain releasing stuff like Super Pacman and Junior Pacman using V-MAX
protection, but it seems kind of pointless since you like mentioned the
entire game fit into RAM, so all you had to use was a freezer cartridge on
it. Taito did the same thing with things like Arkanoid II.
Forrest
Markus Brenner
>The cracked version I saw of Defender of the Crown was missing the
>most important disrobing scene!! Typical solution when you couldn't
>fit all the data on the cracked disks was to leave stuff out...
Hm, I recently had a look at 'Defender of the Crown' and I was able to get it
running from a G64 disk image (by substituting the protected track
information boot-strap with standard 'READ' jobs) at least up to the
Tournament - you built in another copy protection which works on disk two of
the game, and that's where I'm currently stuck. The non-standard bit-rate on
the outer tracks can be dealt with for emulator images as well as the
additional 5 tracks, but patching a copy protection routine that is actually
located in non-standard disk sector data is another topic and quite a job :)
Do you still have any idea of what you actually did in that protection
routine? (I disassembled it, but it doesn't really make much sense to me).
Also, with the later versions of v-max! it seems like you created your own
sector layout on each track, opposed to the earlier versions where standard
sector headers and such where used. In 'California Games' (Also 'Legend of
Blacksilver') I found these tables:
----------------------------------------
--- # of sectors in speed zone 0-4 ---
----------------------------------------
$0553: 2e 29 26 25 2f ; 46 41 38 37 47
$0558: 2e 29 27 25 2f ; 46 41 39 37 47
$055d: 2d 28 26 24 2e ; 45 40 38 36 46
Any idea why you needed three slightly different tables? Are these the actual
# of 'sectors' used in v-max!?
There's also a funky looking bit-rate table in the same loader:
----------------------------------------
--- track 2 speed zone lookup table ---
----------------------------------------
$0561: 2e
$0562: 00 04 00 04 00 04 00 04 ; tracks 01-08
$056a: 00 04 00 04 00 04 00 04 ; tracks 09-16
$0572: 00 01 01 01 01 01 01 01 ; tracks 17-24
$057a: 02 02 02 02 02 02 03 03 ; tracks 25-32
$0582: 03 03 03 ; tracks 33-35
The values 0-4 are related to the 5 entries in the # of sector table above,
but why did you bother to make things so complicate by having two cases for
alternating tracks from track 1-17?
I also didn't figure out how the actual sector header is constructed in this
version of the loader. Do you only synchronise once for the whole track, or
does each sector have its own complete header information? (it doesn't seem
like that).
Anyway, thanks for bothering to actually read this drives from us, it's great
to know the 'guys from back then' are still around!
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/
Markus Brenner
>Anyway, thanks for bothering to actually read this drives from us, it's great
oops, typo, I meant to write 'drivel' :)
Steve Judd
I edit a little technical magazine for the 64 called C=Hacking
(http://www.ffd2.com/fridge/chacking), and I think the readers would be
very interested in a technical discussion of V-Max, especially from
the author! The C=Hacking audience is experienced programmers, and as
such enjoy rather detailed technical information.
My thinking is also that it would be useful to have all the information
in a single, more permanent location. I certainly don't mean to
interrupt the discussion here, but rather to perhaps complement it.
Thanks, and it's really great to see people such as yourself! :)
-Steve
sjudd(@)ffd2.com
--
V-MAX!
Michael Saunders wrote in message <7vls6s$7...@holly.ColoState.EDU>...
>V-MAX! <no-...@nonesuch.com> wrote:
>
>:>What feature or event in your copy-protection past are you
>:>most proud of?
>:>
>: I was really happy with all of the subtlties of the final version, but
>: explaining that woud be very technical and lengthy. Short of that,
>
>interesting stuff we can only hear from author(s)! Most of
>the people here who are following this discussion (and you're
>all welcome to help me-out with some questions!) are at least
>familiar with protection concepts and maybe, many years ago,
>some of use did a little cracking or writing of our own
>protections. Don't be afraid to get technical -- if you've got
>the time.
>
may take a few posts, but I'll try.
>By subtleties, I assume that you mean the little tricks that
>serve to piss-off/irritate the crackers -- like encryption,
>self-modifying code, etc.?
In general, I would write the routines in a fairly straightforward manner.
Then Peter would cipher block chain them to obfuscate their purpose. The
code to decode them would be heavily self-modifying, and make extensive use
of all of the "illegal" opcodes on the 6502. I would sometimes also add
self-checking routines to deter hackers from making patches in our code and
executing them a "piece" at a time. Such routines, might, for example,
checksum the code using 2 or more different methods (additive vs xor vs the
additive checksum of the xor series), then use one of those values to xor
another byte at an offset or address defined by the other value. What this
would end up doing would be to change a single value somewhere in memory,
but you'd never know from or to what, nor where. One of my favorites was to
modify a bit in the synchronous transfer routines, which would change the
timing very, very subtly, and make it 99.9% reliable, instead of 100%. This
would create an untraceable random error during every load. Another would
be to adjust the timing values in our accelerated stepper motor routine,
such that head seeks eventually became unreliable.
>I remember your work in Defender of the Crown. It was such
>a big deal to have the high-quality music playing WHILE the
>disk was loading. All that on 1MHz...
>
>:>What is the general (main) protection in V-Max!? I'd assume
>:>the custom formatting, but who knows?
>:>
>: The disappearing sync bytes
>
>Tell me more! I'm hungry!!! :^)
>
That would require me describing our custom track format, with a fair amount
of background info needed as well. Better to put in a separate post.
>:>What is the "behind the scenes" operational process for
>:>V-Max!? (ie. the sequence from loading the booter up to
>:>the main program execution)
>
><snip informative/cool stuff>
>
>: out to the next track, and load up the "real" drive OS using our
>: (basic) custom 2 for 1 GCR encoding, which allowed simple and quick
>: "on the fly" decoding (and which defeated most early copy programs all
>
>Was this the every-other sector load and then EOR them together,
>or am I thinking of something else? I'm getting hungrier for
>some beefy details...
>
I don't remember if it required us xoring even and odd bytes together (most
likely), or even and odd "sectors" (pages), but yes, that was the idea.
>Did you basically reproduce all of the calls (or re-map) from
>DOS to allow the protected programs to run unmodified, or just
>a standard subset (load, save, etc.)?
>
Just load or load-and-execute. We'd leave some normal C64 tracks on the
disk if people wanted to save game data on the disks. While we wrote a
number of "fast save" routines for our cartridge, I don't think we ever
licensed them out for inclusion in a game, though I could be wrong. Also, I
recall at least one time, we licensed out a fast replacement for Commodore's
"sector read" routine, but that was the exception, not the rule.
>: They had some guideline to follow (like only 2 letter filenames), but
>
>Is this simply an efficiency decision (to save bytes on the
>disk), an arbitrary limitation in the V-Max code, or simply
>to make it more difficult for crackers to locate the names
>since they aren't long strings?
>
Saved every byte we could.
>: That's a relative assesment. The game's busines is a lot "better" to
>: me now, but I wouldn't be here if I hadn't gone therer first.
>
>Interesting... what's your role in the game business, now that
>copy-protection and similar low-level routines are no longer
>used (at least, like they once were)?
>
At various time a development director, director of technology, and a
producer.
>
>: By the end, it was pretty automatic. Put the original in one drive
>: after running the (copy protected) mastering program, and a blank in
>
>You protected the protection program -- that's understandable,
>but still sounds funny. Kinda like the various copier programs
>that were protected... I guess that if anyone were able to copy
>the mastering program, it would impact your bottom-line.
>
Didn't want it going out the back door to hackers to analyse, did I?
>You said earlier that you used a 1571 with an external tap on
>the sync hole LED. How does that fit into the greater V-Max!
>scheme of things?
>
We arranged our data such that the tracks all lined up with the sync hole
signal. This made it easier for our duplicator to read in the master.
>: Well, lest I be accused of forgetting the obvious, there were other
>: "personell" involved. Like Peter and Marty, who helped me develop
>
>hehehe... I've got Marty on my target list to "interview" also!
>
If you ever find out what happened to Joe Peter, let me know. Both Marty and
I lost track of him.
>
>One obvious question that I've forgotten so far: What is the
>significance of "V-Max!"? Velocity Maximizer?
>
V-MAX is another acronym for the limit sometimes know as VDNE (velocity do
not exceed), or the speed at which,
should you go any faster, the wings will fall off. (I was hooked on
Microprose' F15 flight sim at the time).
>What do you think is the primary factor in V-Max! that kept
>the crackers from easily breaking the code? At some point,
>the data must be exposed for the CPU to execute -- it's
>amazing that more people didn't trace the code to this point --
>you must have some good tricks in there!
>
Sure, you could grab the code in the C64, but the minute you needed to load
more data, you needed to have our DOS booted up in the drive, or you would
just hang. If you had our DOS there, then you needed a properly formatted
V-MAX! disk. Plus, we frequently re-arranged our GCR table, so that working
your way through one product, might not help you with the next.
>If one were interested in getting "into" a V-Max! game and
>seeing what was going on, would you have any recommendations
>to make the exploration easier?
>
Have fun! Peter was so good at his job, I couldn't even disassemble his
stuff afterwards (at least, with the final version of V-M). I could run it,
and capture the memory of the drive afterwards, once the DOS was booted (to
debug it). Or I could modify my source, then run his utility on it to
encypher it, but I didn't have the patience to actually work through and
crack it step by step.
>---------------
>
>Well, I think that's all I'll bother you with tonight... Thanks
>very much for taking the time to particpate in the newsgroup!
>I must admit, you are somewhat of a copy-protection idol to
>those of us who really like the subject!
The real goal of V-MAX! was ALWAYS to be the fastest loader available.
Everything else took a back seat. The only competition for the title we had
was VORPAL, and I don't mean the version he gave out in the utility kit. I
mean the one he used on Epyx last products. We always looked forward to
Scott's latest work, he was a very creative programmer.
>Maybe I'll try to a
>hold of Marty and see if he'd like to help you answer all of
>my questions... :^)
Marty was very instrumental in getting the latter versions of V-MAX! out
there. He wrote all of the tools (like our heavily modified assembler,
debuggers, and install utility), as well as contributing a number of ideas
for the OS itself. He was also the chief architect of our WarpSpeed
cartridge.
V-MAX!
Forrest wrote in message ...
>
>
>On Tue, 2 Nov 1999, V-MAX! wrote:
>
>
>Yeah, I remember that version of DOTC, I think ESI did another crack a
>little bit later that fixed the problem. But the original is still
>superior because of the V-MAX fastloader. But yeah, thats a pretty good
>idea for protection, fill the entire disk, up to track 40 and the
>directory track, and then see if you can fit the cracked version back onto
>two disk sides.
>
>Although ESI did end up cracking California Games (vorpal protection) and
>ended up putting it on 3 disk sides, so I guess there are limits to that
>type of protection. The original was only 2 sides.
>
While there was some concern about the cracked versions that got passed
around, the bigger concern was for the software copy programs which could
turn any kid, with no technical knowledge, into a source of endless copies
of the original. We figured the cracked versions, which generally had no
ability to fast load at all, were just nuicances at worst, and free demos at
best. The fast loader added a lot to the play value. Likewise, we weren't
concerned about the hardware modification kits for disk drives, figuring
that the number of people with the technical ability to do that was pretty
small in comparison to the overall market.
>
>Hehe, its funny you mention stuff like PacMan, because I remember Thunder
>Mountain releasing stuff like Super Pacman and Junior Pacman using V-MAX
>protection, but it seems kind of pointless since you like mentioned the
>entire game fit into RAM, so all you had to use was a freezer cartridge on
>it. Taito did the same thing with things like Arkanoid II.
>
Yeah, but the fast loader made it still worth paying for (everyone else had
a fast loader, but our clients never had to bother creating one of their
own, since V-MAX! had always been there for them).
V-MAX!
Markus Brenner wrote in message <7vmjso$7mid$3...@fu-berlin.de>...
>Do you still have any idea of what you actually did in that protection
>routine? (I disassembled it, but it doesn't really make much sense to me).
>
Not really. But before RAM expansions for the drives became common, I would
often either add additional and specific bytes in front of each sync mark,
or bury a sync mark in an unexpected location. I also sometimes tried to
check track to track alignment (since commercial disks were always aligned
by the sync hole). I also used blocks with unreliable GCR (too many off
bits in a row), and checked to see if they changed from read to read. Hope
that helps.
Unfortunately, the only version I remember many details about was the last
one, since we used that on so many products over such a long time.
>Also, with the later versions of v-max! it seems like you created your own
>sector layout on each track, opposed to the earlier versions where standard
>sector headers and such where used.
Yep. The standard format was such a huge space waster, because it was
designed to be written to as well as read from. The latter versions of
V-MAX! were read-only formats, and much more efficient. We couldn't do
that, however, till we solved the duplication problems.
>In 'California Games' (Also 'Legend of
Not mine. That was Vorpal.
>Anyway, thanks for bothering to actually read this drives from us, it's
great
>to know the 'guys from back then' are still around!
>
V-MAX!
- Harald
Steve Judd wrote in message <7vmtge$8da$1...@kc.trail.com>...
Dan Gahlinger
would like to get into the deeper workings of vmax protection/loader.
would love to work on the last version you put out, and take a look at
the code, etc...
The reason for a lot of this, is the c64 is such a great machine, and the
1541 drive ahead of its time. the PC floppy can't do much if anything.
Have you ever looked at or into or worked on PC copy protection? just
curiousity here.
Dan.
Dan Gahlinger
PD, or freely used?
How was v-max connected to another product called "21 second backup", rumor was
back then they were both written by you. I seem to recall 21 second backup was
able to copy some disks (all I remember ever trying anyhow). and another
product was 'trackmimic" although that one was not related as such except in
operation.
I'd like everyone to know that I'm in the process of setting up a "c64archive"
information about copy protection, and hopefully combine everything that's on
some other web sites together. It's about time my "web museum" got back on the
air :)
Dan.
Michael Saunders
: any chance of getting a "replyable" email address harald?
: would like to get into the deeper workings of vmax protection/loader.
: would love to work on the last version you put out, and take a look at
: the code, etc...
I don't want to sound like a Net-Cop, or anything, but:
Actually, Dan, let's keep the discussion here, if possible. I, too would
like to have these details (as would several other people monitoring this
thread). That's why we asked to contact Harald and started this thread.
Feel free to get "down and dirty" with the code/GCR/etc. -- that's why
we're here!
We also need to be considerate of Harald's time and realize that he has
a life outside of helping us live in the past. :^) He said that he'd
get more in-depth with the V-Max scheme, but it would probably take some
time/multiple posts.
However, if you do get-off on an individual conversation, please make sure
to copy the rest of us on what you find...
Mike
mics...@holly.colostate.edu
Michael Saunders
:>protections. Don't be afraid to get technical -- if you've got
:>the time.
:>
: Giving a full technical run-down of all the pieces of that made up V-MAX!
: may take a few posts, but I'll try.
That would be great! Whenever you get the time, I'll be here
to read the info!! A "full technical run-down" of V-Max!
is definitely worth waiting for...
: Then Peter would cipher block chain them to obfuscate their purpose. The
: code to decode them would be heavily self-modifying, and make extensive use
Did Peter use a program to do this trickery, or was it hand-coded/
altered for each version?
: of all of the "illegal" opcodes on the 6502. I would sometimes also add
Damn those illegal opcodes... I've gotta find a good listing of those
before I get back into tracing code heavy!
: but you'd never know from or to what, nor where. One of my favorites was to
: modify a bit in the synchronous transfer routines, which would change the
: timing very, very subtly, and make it 99.9% reliable, instead of 100%. This
: would create an untraceable random error during every load. Another would
: be to adjust the timing values in our accelerated stepper motor routine,
: such that head seeks eventually became unreliable.
Tricky, tricky -- just the kind of "games" that make the CP field
so fun and interesting.
I'd assume that your custom stepper drive routines pulsed the
head motor much faster than the 1541 was designed for. If
someone had a drive that wasn't up to the task and the head
got off-step, could V-Max! find where the head was and retry,
or was everything done in RAM, relative to the starting
point?
:>: The disappearing sync bytes
:>
: That would require me describing our custom track format, with a fair amount
: of background info needed as well. Better to put in a separate post.
Probably will be part of the "run-down" above, as this is probably
very key to the functioning of the routine. We'll be here
whenever more details are available!
:>disk), an arbitrary limitation in the V-Max code, or simply
:>to make it more difficult for crackers to locate the names
:>since they aren't long strings?
:>
: Saved every byte we could.
What is the maximum capacity of a side of the latest V-max!?
Let's assume a fully protected disk, with only track 18 in
standard format (as much as V-max needed).
: At various time a development director, director of technology, and a
: producer.
Any titles we might recognize?
: We arranged our data such that the tracks all lined up with the sync hole
: signal. This made it easier for our duplicator to read in the master.
I would imagine that tapping the sync signal from the LED would
make copying a V-Max disk significantly easier. Since all of the
tracks begin at a known physical location on the disk, the lack
of sync bytes on the disk would become less problematic. You'd
probably have to create a hacked drive specific to copying V-Max,
which, like you said, would be beyond the means of the thousands
of kids who might copy the games like mad. Are you aware of
anyone doing such a thing?
:>hehehe... I've got Marty on my target list to "interview" also!
: If you ever find out what happened to Joe Peter, let me know. Both Marty and
: I lost track of him.
Hmm... I'll definitely let you know if I run-across his e-mail
address. I'll send a private e-mail, just in case he doesn't
want to get plastered with e-mail from those of us living in
the past :^)
: not exceed), or the speed at which,
: should you go any faster, the wings will fall off. (I was hooked on
: Microprose' F15 flight sim at the time).
Hehehe... it's cool how something of these things happen. Maybe
that question/answer will appear in a "Nerd Trivial Pursuit" a
decade from now. We (all 5 or so of us reading this) will be
able to ace that one!
: just hang. If you had our DOS there, then you needed a properly formatted
: V-MAX! disk. Plus, we frequently re-arranged our GCR table, so that working
: your way through one product, might not help you with the next.
So, it sounds like as long as the disk was filled to V-Max capacity,
even without the software tricks, V-Max would have been hard to
copy without going to muliple disks. Since the data was written
using the custom format, which requires an expanded RAM drive to
write, that is a pretty good barrier in itself. Combined with the
large capacity of a V-Max disk and having to split it to more
than one disk if the special format was removed (and hacking the
game to handle disk swaps) is even better.
: Have fun! Peter was so good at his job, I couldn't even disassemble his
: stuff afterwards (at least, with the final version of V-M). I could run it,
Uh oh... doesn't sound promising! :^) Are you sure you don't still
have any of those old disks or papers laying around?!? (just
kidding -- I believe your original comment that you don't.) Well,
maybe a few technical postings from "the man" will be enough to get
us on the right track... hopefully...
: mean the one he used on Epyx last products. We always looked forward to
: Scott's latest work, he was a very creative programmer.
Was it common for you guys to dig-into other people's schemes
to see what was going on (like Vorpal) or, did you realize at the
time that you were "top of the heap"?
Were there any games that you cracked/evaluated the protection on
(in you early days) that were partcularily informative for later-on?
: Marty was very instrumental in getting the latter versions of V-MAX! out
: there. He wrote all of the tools (like our heavily modified assembler,
: debuggers, and install utility), as well as contributing a number of ideas
: for the OS itself. He was also the chief architect of our WarpSpeed
: cartridge.
Sounds cool.. Maybe Marty might still have some of those tools in
a box somewhere!
What kind of modifications (in general) did you guys have to make
to something like an assembler? I can certainly see that a custom
debugger would be handy...
Later,
Mike
mics...@holly.colostate.edu
uh1_...@my-deja.com
"V-MAX!" <email@address> wrote:
> Not really. But before RAM expansions for the drives became common, I
would
> often either add additional and specific bytes in front of each sync
mark,
> or bury a sync mark in an unexpected location. I also sometimes
tried to
> check track to track alignment (since commercial disks were always
aligned
> by the sync hole).
According to the Supercard manual I have in front of me, there is a
index hole sensor modification that can be performed so that the
special Index Hole Sensor (IHS) can copy *anything* (that's what it
says!) I've done the modification but unfortunately I think my version
of the IHS 1541 nibbler is either corrupted or doesn't work ;-(
Sent via Deja.com http://www.deja.com/
Before you buy.
uh1_...@my-deja.com
"V-MAX!" <email@address> wrote:
> >:>What is the general (main) protection in V-Max!? I'd assume
> >:>the custom formatting, but who knows?
> >:>
> >: The disappearing sync bytes
Harald, can you briefly explain why the 'sync bytes' technique (and any
other stuff that you used) could not a copied with any serial nibbler
or Burst Nibbler/21 sec backup/other parallel cable? Why was it
necessary to have the 8k ram expansion to successfully nibble V-MAX?
> >You protected the protection program -- that's understandable,
> >but still sounds funny. Kinda like the various copier programs
> >that were protected... I guess that if anyone were able to copy
> >the mastering program, it would impact your bottom-line.
> >
> Didn't want it going out the back door to hackers to analyse, did I?
You, ah, won't happen to have this disk just lying around, would you ?
;-) For that matter what happened to all your source, tools, work disks
etc from when you were creating V-MAX?
> V-MAX is another acronym for the limit sometimes know as VDNE
(velocity do
> not exceed), or the speed at which,
> should you go any faster, the wings will fall off. (I was hooked on
> Microprose' F15 flight sim at the time).
<grin> I remember reading the F15 manual and was absolutely sure V-MAX
was named because of F15... ;-)
> Marty was very instrumental in getting the latter versions of V-MAX!
out
> there. He wrote all of the tools (like our heavily modified
assembler,
> debuggers, and install utility), as well as contributing a number of
ideas
> for the OS itself. He was also the chief architect of our WarpSpeed
> cartridge.
Although I never had a Warpspeed cart, there's something I always
wanted to know... was it more compatible that Epyx's Fastload ? Did it
have any sort of enhancements or detection in order to optimise (or at
least stay out of the way) when loading V-MAX protected software?
Also...
On the back of the TAITO (Rastan, Arkanoid 2) manuals that I have
there's a short copyright statement something like this: "V-MAX (c)
Alien Technology Group"
Could you talk a bit about the company? Who were the original founders
(Marty/Joe/You?) You also mentioned in an earlier post that you worked
for Taito... what was the relationship bet. Taito & Alien Tech Group?
And I recall correctly I believe the fast loader/custom disk format in
"Graphics Transformer" (published by CDA (Complete Data
Automation)/written by Joe Peter, Scott M Blum (of Di-Sector fame),
Jeff Spangenberg & Daniel Wolfe) was even faster at loading than V-
MAX... tracks used to click by faster than a V-MAX load... but I don't
know if that meant that the load was faster or that tracks held less ;-)
Kevin M.
Joe Forster/STA
can only be made to read _sectors_ that follow the standard MFM-encoded
sector format. What you can do, as copy protection, is using sectors
that the _DOS or the BIOS_ can't read because:
1. The track number in the sector header is different from the track
where the sector is phyisally located, e.g. sector 2;0 on track 1.
2. The head number (0 or 1 for double-sided disks) in the sector header
is different from the real value. Actually, 1581 disks have this
parameter swapped ("head 0" written into sectors under head 1 and vice
versa), this is why you can't simply read them with the BIOS.
3. The sector number in the sector header lies outside the range of
valid sector numbers on that particular track, e.g. sector 1;255 on
track 1.
4. The "number of bytes per sector" value is other than 512. DOS can't
handle sectors with 128, 256 or 1024 bytes - might be, the BIOS neither
but I'm ot sure about it...
Actually, these are the only four values (called "CHSN": Cylinder, Head,
Sector, Number of bytes) inside the sector header of a PC-formatted disk
and these are the values which you have to tell the floppy disk
controller when asking it to read a sector or a couple of sectors off
the disk. So, there's not much more to fool around with, I think.
I think Wolfgang Moser, the author of 1581COPY, could tell you more
because he dove really deep into the FDC specification and the full
source of 2M, a floppy formatter program, when designing his program.
Joe Forster/STA
s...@c64.org
PS: Sorry to interrupt this _excellent_, interesting discussion! Dan,
please, contact me - or Wolfgang - in a personal E-mail if you need
more infos...
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Nicolas Welte
> According to the Supercard manual I have in front of me, there is a
> index hole sensor modification that can be performed so that the
> special Index Hole Sensor (IHS) can copy *anything* (that's what it
> says!) I've done the modification but unfortunately I think my version
> of the IHS 1541 nibbler is either corrupted or doesn't work ;-(
I don't understand why there were index hole hacks for a 1541 when the
1570 and 1571 were factory equipped with an index hole sensor. I also
don't understand why Harald said that even the 1571 drives had to be
equipped with an additional connection to the index sensor to be able to
create V-Max disks. The signal is readily available via a VIA port bit,
so why connect it somewhere else?
Nicolas
uh1_...@my-deja.com
"V-MAX!" <email@address> wrote:
> Unfortunately, the only version I remember many details about was the
last
> one, since we used that on so many products over such a long time.
I know the details are sketchy, but...
Do you have a V-Max version list so we can identify what V-Max version
was used by a specific title? Failing that, is there a way (version
byte or code sequence) that can be used to identify a specific V-Max
version? If not, do you remember what year you started using the last
version?
uh1_...@my-deja.com
Nicolas Welte <we...@chemie.uni-konstanz.de> wrote:
> I don't understand why there were index hole hacks for a 1541 when the
> 1570 and 1571 were factory equipped with an index hole sensor.
Well, if you don't have a 1571 but a 1541 and you have Supercard
software & a 8K ram expansion board/mod you can use the IHS nibbler and
(supposedly) nibble anything. The 1571 version of the
RAMBoard/Supercard 8k ram expansion is different from the 1541 version,
as there is ROM at $8000 in the 1571 whereas that memory space is clear
in the 1541. I've never seen the 1571 version so I don't know where the
8K expansion is addressed in memory space.
> I also
> don't understand why Harald said that even the 1571 drives had to be
> equipped with an additional connection to the index sensor to be able
to
> create V-Max disks. The signal is readily available via a VIA port
bit,
> so why connect it somewhere else?
Harald said:
"DiskMaker was mastered on a Dual Drive from MSD with a custom RAM
expansion added. Commercial games were mastered on a C128 with 1571
(running at 295 RPM!) , custom modified with a
parallel disk drive connection, and (remote) access to the sync hole LED
signal."
Maybe he was saying that the index sensor was accessed thru the
parallel cable and not the serial bus (say, for timing reasons?)
Dan Gahlinger
And BTW, you are quote wrong about the PC floppy, I base this only on the fact
that there have been (and still are) many many different copy protections (disk
based) for the PC.
I will name only a few, but one famous company was "Microprose" who had a habit
of doing this, but one protection that rivalled the c64 was "EverLock", very
difficult to deal with. and yes, there were even "laser burn" (or laser hole)
protection schemes for PC floppies, and even more beyond that.
This is why products like "copywrite" came into existance in the first place,
and things that came out of it like "neverlock" and "rawcopy" to name only a
few.
Copywrite was (and still is) one of my all time favourite programs. although it
will only run on (max) a 486-DX2-66, maybe someone could modify my legal copy so
it will work on anything (this restriction had to do with timing apparantly).
some copy protection (actually a LOT of it) was timing sensitive. hmm, sound
familiar Joe?
makes me think of c64 days all the time.
All I'm saying is this: if there have been protections so advanced for the PC in
the past, just imagine what they could do today? Although the floppy has a
limited life perhaps on the PC with such a small storage space available, there
are ZIP drives, and Sonys HIFD (200megs) and the new 250meg ZIP drives, although
the Sony is backward compatible (the only one), then there is CDROM (they have
laser lock protection and more too, take a look at Bleem! or some other things).
So maybe the drive is limited, but ingenuity is not. I'm sorry your imagination
is lacking in this regard or perhaps it's your knowledge of the PCs past of copy
protection. I have over 10,000 floppies of original PC software, from 386 days
(CGA) to present which I collected over the years, let me tell you, the PC is
only limited by the ability of the programmer. I have probably 100s or 1000s of
protected disks, which I'd be glad to send someone to look at if they like.
Dan.
- I consider myself somewhat a moderate expert on the subject of copy protection
(probably not in the ranks of Harald as far as c64 stuff (although I studied
that a lot and made my own) but on the PC...)
V-MAX!
Dan Gahlinger wrote in message <381F54B2...@bell.ca>...
>Who has the "rights" to v-max protection scheme today? (legally) could it
be
>PD, or freely used?
>
>How was v-max connected to another product called "21 second backup", rumor
was
>back then they were both written by you. I seem to recall 21 second backup
was
>able to copy some disks (all I remember ever trying anyhow). and another
>product was 'trackmimic" although that one was not related as such except
in
>operation.
Before coming to work with me, Marty and Joe wrote another copy utility, but
I don't recall the name. After we got together, the only copy programs we
wrote were for unprotected disks, which we put into our WarpSpeed cart.
V-MAX!
Michael Saunders wrote in message <7vofe5$5u...@holly.ColoState.EDU>...
>V-MAX! <email@address> wrote:
>:>protections. Don't be afraid to get technical -- if you've got
>:>the time.
>:>
>: Giving a full technical run-down of all the pieces of that made up V-MAX!
>: may take a few posts, but I'll try.
>
>That would be great! Whenever you get the time, I'll be here
>to read the info!! A "full technical run-down" of V-Max!
>is definitely worth waiting for...
OK, I'll start writing it up, then I'll post it when I'm done.
Also, to the person who asked about the protection on the second Defender of
the Crown disk, it's also possible that I put a protection integrity check
on one of the disks. I may also have replaced the GCR table with a
different one, if the protection or integrity check succeeded, I just don't
remember now.
>
>: Then Peter would cipher block chain them to obfuscate their purpose. The
>: code to decode them would be heavily self-modifying, and make extensive
use
>
>Did Peter use a program to do this trickery, or was it hand-coded/
>altered for each version?
>
Hand written for each and every version.
>Damn those illegal opcodes... I've gotta find a good listing of those
>before I get back into tracing code heavy!
>
You might try the Apple II groups if you have on other luck, they also had
to deal with them.
>: but you'd never know from or to what, nor where. One of my favorites was
to
>: modify a bit in the synchronous transfer routines, which would change the
>: timing very, very subtly, and make it 99.9% reliable, instead of 100%.
This
>: would create an untraceable random error during every load. Another
would
>: be to adjust the timing values in our accelerated stepper motor routine,
>: such that head seeks eventually became unreliable.
>
>Tricky, tricky -- just the kind of "games" that make the CP field
>so fun and interesting.
>
>I'd assume that your custom stepper drive routines pulsed the
>head motor much faster than the 1541 was designed for. If
>someone had a drive that wasn't up to the task and the head
>got off-step, could V-Max! find where the head was and retry,
>or was everything done in RAM, relative to the starting
>point?
>
It varied. I think we had a drive head reset routine in one or more
versions, but it proved unneccessary. Once we were able to read the track
18 directory, we were already lined up. Thereafter, we never accellerated
so fast that we lost alignment (even on older drives). We had a lot of beat
up old drives which we used for reliability testing, and would do 24 hour
continous load tests, to see if we dropped any bits. If we did, we fixed
the problem and retested.
>
>>
>What is the maximum capacity of a side of the latest V-max!?
>Let's assume a fully protected disk, with only track 18 in
>standard format (as much as V-max needed).
>
I don't actually remember, I don't even remember how many tracks we finally
ended up with in the last version. Over time, we tried to push the limits
of the drive by adding more tracks or using a higher bit rate, but would
always run into problems with worn out drives or the later "cost reduced"
ones (I think they were called 1541C's, but I could be wrong), and the 1571
was based on still a different mechanism (not belt driven, as I recall, plus
MFM compatible). So we ended up with a least common denominator kind of
result.
>: At various time a development director, director of technology, and a
>: producer.
>
>Any titles we might recognize?
>
Probably not, not many big hits, though some of them did OK. Some of the
better known ones might be (oldest to newest):
Take Down, Top Fuel Eliminator (Gamestar/Activision)
WarpSpeed, Rocket Ranger, TV Sports Football (Cinemaware)
QIX, Operation Wolf, Bubble Bobble , Chase HQ, Puzznic, Revenge of Doh,
Indiana Jones & the Last Crusade (Taito)
HR Giger's DARKSEED (Cyberdreams)
Rage in the Cage - WWF Wrestling, The Simpsons - Bart's Nightmare (Acclaim)
Super NBA (Tecmo)
March Madness, Andretti Racing, NASCAR, NCAA College Football, J. Madden
Football (EA Sports)
James Bond - Tommorow Never Dies (EA/MGM) (not yet released)
>: We arranged our data such that the tracks all lined up with the sync hole
>: signal. This made it easier for our duplicator to read in the master.
>
>I would imagine that tapping the sync signal from the LED would
>make copying a V-Max disk significantly easier. Since all of the
>tracks begin at a known physical location on the disk, the lack
>of sync bytes on the disk would become less problematic. You'd
>probably have to create a hacked drive specific to copying V-Max,
>which, like you said, would be beyond the means of the thousands
>of kids who might copy the games like mad. Are you aware of
>anyone doing such a thing?
That wouldn't have been enough, though it would have helped. But no, I don't
know of anyone who did, since in the first place only the 1571 had the LED.
But who says their were no sync bytes? They were there, just nearly
invisible. Scott's last VORPAL protection was the only one I ever saw that
apparently used no sync bytes whatsoever. When we saw how he did that, we
were all pretty amazed.
>So, it sounds like as long as the disk was filled to V-Max capacity,
>even without the software tricks, V-Max would have been hard to
>copy without going to muliple disks. Since the data was written
>using the custom format, which requires an expanded RAM drive to
>write, that is a pretty good barrier in itself. Combined with the
>large capacity of a V-Max disk and having to split it to more
>than one disk if the special format was removed (and hacking the
>game to handle disk swaps) is even better.
>
The drive also had to be slowed down 5 to 10 RPM (I don't recall exactly),
cause the duplicator used a slightly higher than standard bit rate when the
disks were duplicated. So even if you read in all the bytes, starting &
ending at the LED sync, you wouldn't have fit them on the track using a
drive that was properly "in spec", which most 1571's were!
>: mean the one he used on Epyx last products. We always looked forward to
>: Scott's latest work, he was a very creative programmer.
>
>Was it common for you guys to dig-into other people's schemes
>to see what was going on (like Vorpal) or, did you realize at the
>time that you were "top of the heap"?
>
Oh yeah, we always kept tabs on the competition, but Scott was the only one
who consistently impressed us. After a while though, we got lazy and didn't
really list and comment them out, like we did in the beginning. It was
enough for us to see the general idea, 'cause we knew what we needed to do,
and how to do it, and had come up with enough good ideas of our own. Or at
least we thought so.
>Were there any games that you cracked/evaluated the protection on
>(in you early days) that were partcularily informative for later-on?
>
I think Joe may have gotten some ideas about obfuscation from RapidLok, but
in general, he was better than anyone else (including me). Me, my first
hack was Multiplan, which I legitimately wanted/needed to back up (the Apple
version included a backup disk, but the C64 version didn't). Funny thing
is, the guy who wrote the C64 version actually came to work for me later,
when I was at Taito.
>What kind of modifications (in general) did you guys have to make
>to something like an assembler? I can certainly see that a custom
>debugger would be handy...
>
We took a commercial assembler, then modified it to work remotely, with a
downloader and remote debugger (C128 hosted to C64/128 client). We may
have added illegal opcodes to it as well, I forget. Oh, and I think it
could also download directly to a remote disk drive, if I'm not mistaken.
V-MAX!
>any chance of getting a "replyable" email address harald?
I would prefer to answer questions here on this thread over the next few
days (I'm just coming off a project, and will be taking a vacation soon, so
this is something of a break for me).
>would like to get into the deeper workings of vmax protection/loader.
>would love to work on the last version you put out, and take a look at
>the code, etc...
If someone were to reset a drive while V-MAX! was running (assuming they'd
modifed their ROMS so all memory wasn't cleared), they could capture an
image of the the drive code. Actually, we used to have two different ROMS
in two different drives. With one, the reset would leave intact the
scratchpad/buffer RAM, but clear out the stack, zero page, and initialize
the system areas. The other ROM would first copy those pages to the buffer
RAM, then initialize zero page, stack, etc. This way, between the two
drives, we captured everything (this was before we added the extra RAM, and
just copied everything prior to RESET). Some versions of V-MAX! may have
had a check for extra RAM, and refused to run if it found it (or run badly).
It was something we considered, but don't know if we actually implemented it
or not.
If you do this, and would like help understanding any of the "bits", then
feel free to email me, I'll look at it and post my response back here for
all to see.
As I positively hate spam, you'll just have to figure out the correct email
address from below:
Use MyfirstnameMyLastname at yahoo dot com.
Spelling is important, but I see you've already got that under control.
BTW - If I start getting spammed at that email, I'll just delete that
account. Would be spammers, take note.
>The reason for a lot of this, is the c64 is such a great machine, and the
>1541 drive ahead of its time. the PC floppy can't do much if anything.
Funny thing is, the PC's of the time also took longer to load off of
floppies than a C64 with V-MAX!. But with everyone having a HD, no one
really bothered to improve them.
>Have you ever looked at or into or worked on PC copy protection? just
>curiousity here.
Looked at it, but decided against it. Floppies were clearly on the way out
as a distribution medium. I have toyed with the idea of writing CD
protection, but never actually tried (though I do have a couple ideas that
would be fun to try). Don't have a relationship with any CD duplicators.
V-MAX!
Nicolas Welte wrote in message <382031...@chemie.uni-konstanz.de>...>1570 and 1571 were factory equipped with an index hole sensor. I also
>don't understand why Harald said that even the 1571 drives had to be
>equipped with an additional connection to the index sensor to be able to
>create V-Max disks. The signal is readily available via a VIA port bit,
>so why connect it somewhere else?
To be truthful, I'm not sure whether we had the 1571 monitor the sensor, and
signal the C128 when the hole came by, or whether we just carried the signal
directly to the C128. We might well have done the former, not the latter.
In any event, we used the signal to initiate the transfer/track write. This
way, we didn't need to buffer the data in the drive, our parallel connection
gave us enough throughput.
V-MAX!
>
>Harald, can you briefly explain why the 'sync bytes' technique (and any
>other stuff that you used) could not a copied with any serial nibbler
>or Burst Nibbler/21 sec backup/other parallel cable? Why was it
>necessary to have the 8k ram expansion to successfully nibble V-MAX?
>
To read a sync byte (and confirm it's existence), you have to test for a bit
which is set by the shift register chip which clocks in each bit, and sets
that bit (and keeps it set) once 12 or more sequential on bits are detected.
This flag only stay up until the first zero bit is clocked in (4 CPU clock
cycles equal one data bit clock, as I recall). Since my sync bytes were
exactly 12 bits long, that was too short to reliably see using the standard
Bit xxxx, bvc back: loop, which had a 5 CPU cycle jitter. Commodore used
extremely long sync bytes, 40 bits as I recall, which wasted a good deal of
space.
But they were necessary for the disk to be writable as well as readable,
since the first few bits could be clobbered by turning on the bias current
which preceded writing new data to the disk. Every time the current was
turned on or off (at the end of the write sequence), some bits would be
clobbered and rendered indeterminate. V-MAX! tracks were read-only, so no
extra bits were needed. We didn't find the start of data by looking for the
sync bytes, they were ignored by our software (unlike commodore's DOS).
They were there purely for hardware reasons, to make sure that the following
data bytes were framed correctly. We had a unique byte (or two?) for the
start of each sector, which had a bit pattern that real V-MAX! GCR data
would never produce, no matter how it was framed. We could have gotten
away with putting only one sync pattern at the beginning of each track, but
we didn't want to have to wait for the start of the track every time we
stepped the heads, this would have added an unacceptable worst case delay of
an entire disk rotation, before the data was properly framed and readable.
Another reason for the long standard Commodore sync bytes, was that the
Commodore GCR-to-binary conversion routine was so slow, that the CPU needed
all the time that went by to convert the data, so it could determine if this
was indeed the sector it was looking for. Ours was real-time (we converted
to binary while waiting for the next byte to clock in).
The only loader we ever saw, that could handle data no matter how it was
framed (i.e. had no sync bytes) was the last VORPAL loader, which gave us
migraines just looking at how it managed to accomplish that task. It used
self modifying real-time GCR conversion code to do half the job, and the
serial transfer routine to do the remainder of the work, of putting things
back in proper order. Twisted is the only term that does it justice. I
never completely analyzed it, it was just too much trouble to figure all the
little details out.
With V-MAX!, we had no padding between sectors, and the sector header info
was combined with the actual data. The end of the data sector was also a
unique bit pattern (actually the start of the next sync). Therefore, the
data had to be written to disk in one continuous stream. If you didn't have
a parallel disk drive, or expansion RAM, you couldn't store an entire track
of data in the standard buffers, especially in expanded GCR form.
Therefore, if you tried to copy the track piecemeal, you would end up with
breaks in the bitstream before each sync byte.
On earlier versions of V-Max!, we would check for those breaks, by looking
at the last byte before each of the sync marks. On the last version, that
last byte was the crucial end of sector indicator, it wouldn't load properly
without it. Our last version had variable sized sectors, so you needed that
marker to tell when you were done.
Also, if you didn't slow the drive down, as we did, you would end up
overwriting the beginning of the track (which we always filled up, what with
our variable sector sizes).
>You, ah, won't happen to have this disk just lying around, would you ?
>;-) For that matter what happened to all your source, tools, work disks
>etc from when you were creating V-MAX?
>
No more C64 stuff, gave it all away when I left Taito.
><grin> I remember reading the F15 manual and was absolutely sure V-MAX
>was named because of F15... ;-)
Yeah, we later met with "Wild Bill", and even tried to get him to license
our stuff.
>Although I never had a Warpspeed cart, there's something I always
>wanted to know... was it more compatible that Epyx's Fastload ? Did it
>have any sort of enhancements or detection in order to optimise (or at
>least stay out of the way) when loading V-MAX protected software?
>
Absolutely! 20/20 hindsight was of course, a very useful thing.
>
>On the back of the TAITO (Rastan, Arkanoid 2) manuals that I have
>there's a short copyright statement something like this: "V-MAX (c)
>Alien Technology Group"
>
>Could you talk a bit about the company? Who were the original founders
>(Marty/Joe/You?) You also mentioned in an earlier post that you worked
>for Taito... what was the relationship bet. Taito & Alien Tech Group?
>
Marty and I started ATG. Joe was a friend who occassionally did work for
hire for us.
ATG started out as developers for Taito, Cinemaware, and others. Then Taito
hired me, and I Marty.
>And I recall correctly I believe the fast loader/custom disk format in
>"Graphics Transformer" (published by CDA (Complete Data
>Automation)/written by Joe Peter, Scott M Blum (of Di-Sector fame),
>Jeff Spangenberg & Daniel Wolfe) was even faster at loading than V-
>MAX... tracks used to click by faster than a V-MAX load... but I don't
>know if that meant that the load was faster or that tracks held less ;-)
Wouldn't doubt it could move the head faster, but unless they improved the
serial transfer routine, I doubt they could have actually loaded data any
faster (Can't get any quicker than real-time GCR conversion, and I couldn't
get real-time conversion of a GCR that was denser than 75% data, 25% clock).
However, it would have been easy to use the 50% data, 50% clock of alternate
byte real-time conversion (via xor), at the cost of disk space.
By comparison, Commodore was 80% data, 20% clock. Which couldn't be decoded
in real-time (though I don't know what VORPAL's final throughput was, or
what density of data/clock they were using). So if VORPAL was using
Commodore's GCR scheme, and Joe & Scott finished reverse engineering it,
they might well have beaten V-MAX!, now that I think of it. If anyone could
have done it, it would have been JP.
Michael Saunders
###
# # #### # # ###
# # # # # # ###
# # # # # # #
# ## # # # # ## #
## ## # # ## ## ###
# # #### # # ###
I contacted Marty Franz last night, and he provided me with
some VERY good news... While he doesn't have any notes/etc.
from his C64 days, just last month, he zipped all of his 64
stuff-up and posted it to his website!!!! GOLDMINE!!!
Thanks sooooo much, Marty!
I haven't really looked into everything yet (I'm at work, and
well, I guess I have to work :^( ), but doing a search does
reveal some source for the V-Max! mastering program! There's
also source for WarpSpeed, and a bunch of other stuff...
<drool, drool, drool>
Anyway, here's Marty's reply to me. Read it carefully to
find the download link:
Mike
mics...@holly.colostate.edu
--------------------------------------
Mike,
RE: VMAX. I didn't work on the internals of VMAX!, so I'm not certain what I
can offer documentation wise. If you have something specific your looking
for, feel free to email me about it. In general, most of the documentation
has been thrown out due to lack of storage space. Not exactly the answer you
wanted to hear, but that's where things stand.
That's the bad news.
On the bright side, I've always been a packrat with source code. Due to some
form of cosmic harmonic convergence, I posted all my old c-64 source code to
my web site last month. I posted source code to Warpspeed, Superkit 1541,
Take Down wresting, and *some* VMAX! Source code. The code can be found on
my website at http://www.artmath.com/~mfranz/brain/brain.html
<http://www.artmath.com/~mfranz/brain/brain.html>
My role in VMAX was more of a tools programmer. I didn't do any low level
drive programming. Both Harald and Joe did that work. The tool that created
VMAX protected disks was written by me. The zip file should contain the code
to that creation tool. If it's not in the zip, then I'm afraid it's gone. I
don't have many c64 disks laying around anymore.
RE: joining the cbm list. I'll take a look, but I'm busy working on new
artifacts to be found 10 years from now. :-)
----------------------------------
Stephen Judd
In article <s1ue83...@corp.supernews.com>, V-MAX! <email@address> wrote:
>
>Feel free to reprint any info I provide. :0)
>
Well, fair enough :). I have a few (four, actually) questions. Some have
been partly covered already, some have been partly asked already; hopefully
things won't become too disjointed, or spread across too many articles.
How is the data encoded on the disk? Could you also comment on how
it compares to the standard DOS scheme which we are all familiar with:
header, sync bits, track/sector layout, track/sector size, GCR encoding,
and so on.
The answers to the above might answer the next question: what aspects
of the encoding make it difficult to copy? What aspects make the encoding
reliable on imperfect drives? In practice, how susceptible was the
system to errors (I'm sure we've all had various disks that have either
worked unreliably or rapidly self-destructed, due to the copy protection)?
Related to that, could you describe the fastloading system employed
in V-max, both at the 1541 side and the 64 side? Again, some comments
relating it to standard fastloading schemes (multiple bit transfers,
custom vs. standard DOS encoding scheme, handshaking vs. non-handshaking,
interruptable, etc.) would be welcome.
Finally, you've mentioned a few aspects of the protection system, but
could you give a detailed description of the method, at least a "global"
picture of the scheme. For example, the route a byte (or bit) of data
takes from the disk surface into the C64's memory, how that route can
vary, how the data might be used once in memory (checksums etc.),
and comments on aspects that makes it quite tough to beat. Once again,
comparisons with other protection schemes (simple encryption, timer-based
loaders, custom disk formats) would be helpful.
Thanks.
-Steve
V-MAX!
Stephen Judd wrote in message <7vq4ui$k...@news.acns.nwu.edu>...
>Hi Harald,
>
>In article <s1ue83...@corp.supernews.com>, V-MAX! <email@address>
wrote:
>>
>>Feel free to reprint any info I provide. :0)
>>
>
>Well, fair enough :). I have a few (four, actually) questions. Some have
>been partly covered already, some have been partly asked already; hopefully
>things won't become too disjointed, or spread across too many articles.
>
>How is the data encoded on the disk? Could you also comment on how
>it compares to the standard DOS scheme which we are all familiar with:
>header, sync bits, track/sector layout, track/sector size, GCR encoding,
>and so on.
>
OK, I touched on that subject in my posting earlier today. Here's the rest,
or at least as much as I can remember ;-)
Every block started with a unique byte after the 12 bit sync mark. This
byte, obviously, had the highest bit cleared. I could be wrong, but I'm
guessing $7E?
The remaining GCR table was designed to substitute 8 bits out for every 6
in. I don't recall whether we worked from nibbles (3 expansing to 4) or
bytes (6 to 8). To make the data read reliably, we were forced to follow
Commodore's own rules regarding how many off bits in a row we could support.
I'm guessing it was a maximum of 2. You have to understand, that due to wow
and flutter problems, that the 1541 resyncronized itself to each of the
"1"'s (transitions) on the drive surface. You pretty much had to be a
digital hardware engineer to figure this out from the schematics on your
own, I never saw this explained in any books. Thanks to an early interest
in Ham radio, I was able to work some of these things out. What would
happen, if you left too many "zeros" (no transition) in sequence on the
surface of the floppy was, that the shift register would overflow, and
apparently clock in a "phantom" on bit.
Early in the V-Max series, we didn't pay close enough attention to this
rule, and this brought on reliability problems. But, by following
Commodore's own internal rules, we were guaranteed to be as reliable on a
drive as non-protected disks.
The second rule was, that no possible combination of GCR bits could
accidentally generate a string of 12 "on" bits in a row, or we would end up
with an unintended sync byte, which would destroy the framing we had
established earlier. This set of rules gave us just enough possible
combinations that it proved possible to encode every 6 bit entry with a
proper 8 bit value ( or maybe 3 with 4, as I mentioned earlier, a
disassembly of the loader should make it clear which we used).
With this scheme, it was also (barely) possible to convert each GCR value
read back into it's proper binary form in real time. This involved bit
shifting and table lookups, then maybe more shifting and xoring (combining)
of the results. A single byte took, I think, 32 CPU clocks to read in.
Therefore, on average, you had to be done with all your shifting and moving
of data 32 cycles after your first read in the value. You had some
tolerance for error, however.
With Commodore, all they did was store the GCR value in a buffer to work on
later, then went back in a loop, waiting for the bit to be set that
indicated the next byte was ready.
What I did, was calculate how many cycles each operation took, so that I was
ready to read each subsequent byte about the middle of the time it was
present in the IO port. I.E, if it took 32 cycles to read in a byte, the
second byte would become available 32 cycles after first byte had been read,
and that second byte would remain available to be read for another 32
clocks, before it would be replaced by the next, and so on.
Now, to that, I added a tolerance for drives that were running faster or
slower than Commodore's spec. And to that, I added a further allowance for
wow and flutter. This, then, gave me my timing windows, for when I could
safely and reliably read sequential bytes from the disk, without wasting
cycles (which I didn't have) sitting in a loop waiting for a "byte ready"
signal. If I was in danger of running too fast, I might have added a
conditional branch to a follow-on instruction, after the "bit" test, to
conditionally slow things down a tad. But pretty much all of the cycles
were put to use, sometimes I would have to break off what I was doing and
store a value temporarily, so that I could read the next byte. It was a lot
like juggling, and I re-wrote the routines multiple times, moving operations
earlier or later, till I was satisfied. As a result, we could read in 4 GCR
bytes, convert them to binary, and store them in a buffer, then go back to
the top of the loop and wait for the byte ready signal, then do it all over
again. This took several weeks to perfect, though we got the original
(flakey) version running up in a couple of days.
We would break out of the loop when the end of sector byte was read, as I
recall. The start of our load buffer overlapped our read routine by one
byte. That meant, the first binary value of each sector had to translate to
a $60 (rts). This was a "future expansion" hook that would allow us to
embed additional copy protection (signature checks) any place/time on the
disk. We never needed to use it, but it was there for expressly that
purpose.
The remaining header information would contain the sector number, possibly
the track number (not sure), and the number of the file to which the sector
belonged. Other bytes (or maybe we just used a single bit) would indicate
the last sector of a file, which always got sent last. The remaining
sectors would get sent in whatever order they were decoded (each sector had
embedded into it the load address where it belonged in C64 memory). Our
"directory/VMAX DOS" track had embedded information, which told us how many
sectors a given file occupied on each track. The drive would keep track of
which sectors had already been transfered, and not send them twice. When it
had sent all of the sectors belonging to that file which were to be found on
the current track, it would step to the next track, and start again. When
it reached the last track, it would skip over the final sector as long as
there were other sectors to send. The final sector was sent last, as it had
embedded in it, the execution address where control was to be given, (or a
value indicating a normal return via the stack).
With this scheme, files did not have to sit in contiguous memory, they could
be scattered in several places (which would have taken multiple loads to do
otherwise). Plus any file could be made to autoexecute, a big convenience
since that meant games could safely load multiple modules over themselves
without worrying about maintaining a "core" control loading kernal. It also
meant, that data could be sent over the serial bus as fast as the C64 could
receive it, that is, we didn't have to "skew" the data on the disk to
optimally intersperse reading with sending.
>The answers to the above might answer the next question: what aspects
>of the encoding make it difficult to copy? What aspects make the encoding
>reliable on imperfect drives? In practice, how susceptible was the
>system to errors (I'm sure we've all had various disks that have either
>worked unreliably or rapidly self-destructed, due to the copy protection)?
>
The copy protection question I answered in my earlier post today. The
reliability of the GCR was such that it was no different than unprotected
disks. We always did soak tests >24 hours of continuous, error free file
loads, with our oldest and most worn out drives, before we released our
later versions, to test our assumptions. Because of the format (below), we
didn't find it necessary to add additional "signatures" that might make the
loader less reliable on some drives.
Keep in mind, that was for our last (and longest lived) version, we made our
share of mistakes along the way.
>Related to that, could you describe the fastloading system employed
>in V-max, both at the 1541 side and the 64 side? Again, some comments
>relating it to standard fastloading schemes (multiple bit transfers,
>custom vs. standard DOS encoding scheme, handshaking vs. non-handshaking,
>interruptable, etc.) would be welcome.
>
Yes, that was our DOS' other big attraction, however I co-wrote that with
Joe, (whereas the stuff above I did myself), so it's not as fresh in my
mind. Joe would always come up with new, faster ways to do things, then I
would tweak them again to be both faster and more reliable. He would then
trump me by coming up with yet a better and faster way, then I would feel
compelled to find 3 or 4 wasted cycles in his code just to one-up him. It
was a very productive collaboration/competition, which went on for as long
as we worked together. I remember one version of his serial transfer
routine, that would mess up one byte in maybe 1000K. It took me a (long)
while, but I finally found the timing error, and fixed it. I never quit
without shaving at least 2 clock cycles from anything he gave me <grin>.
The only top level stuff I remember, was that we found a way to get rid of
the 5 cycle jitter that generally limited the speed at which the 2-bit
transfers could operate, between 2 cpu's running at different clock rates.
We got it down to 1 and a fraction cycles by using additional handshaking
signals at the beginning of the loop, which were then used to condiditonally
adjust the timing (using forward branches) by a smaller and smaller number
of cycles. The benefit of this tighter synchronization was, we didn't need
to hold the signals for as long, plus we could transfer more than one byte,
before returning to the top of the loop to resynchronize. I believe that we
only allowed interrupts in-between whole sectors of data, when and if we
allowed them at all. Of course, all routines were self-modifying so that
they would run on PAL and NTSC machines (as if there weren't enought timing
headaches already!)
>Finally, you've mentioned a few aspects of the protection system, but
>could you give a detailed description of the method, at least a "global"
>picture of the scheme. For example, the route a byte (or bit) of data
>takes from the disk surface into the C64's memory, how that route can
>vary, how the data might be used once in memory (checksums etc.),
>and comments on aspects that makes it quite tough to beat. Once again,
>comparisons with other protection schemes (simple encryption, timer-based
>loaders, custom disk formats) would be helpful.
>
In summary, nearly invisibly short sync bytes, coupled with overlong,
continuous tracks, which wouldn't fit on a disk spinning at normal speed and
clock rates.
And that's about it. The only other info I remember, is that the start of
each track (before the first sync) had a unique and repetitive pattern on
it, for the duplicator to find and use. This would be located immediately
after the index hole...
And that's the way it was...
V-MAX!
unmodified.
V-MAX! wrote in message ...
Mr. X
> Feel free to reprint any info I provide. :0)
Just wanted to take a sec to say thanx for all the interesting info!
X
Nicolas Welte
> To read a sync byte (and confirm it's existence), you have to test for a bit
> which is set by the shift register chip which clocks in each bit, and sets
> that bit (and keeps it set) once 12 or more sequential on bits are detected.
> This flag only stay up until the first zero bit is clocked in (4 CPU clock
> cycles equal one data bit clock, as I recall). Since my sync bytes were
> exactly 12 bits long, that was too short to reliably see using the standard
> Bit xxxx, bvc back: loop, which had a 5 CPU cycle jitter. Commodore used
> extremely long sync bytes, 40 bits as I recall, which wasted a good deal of
> space.
I just had a look at old drive schematics from Commodore, where the sync
sequence test circuit is still built with discrete components. The
hardware actually needs only ten 1 bits to generate the sync signal.
This is probably just enough to resync the byte shift register, because
the signal will vanish with the next 0 bit. The 4 CPU clocks equals one
data bit rule is valid for the slowest speed zone, it's even less cycles
in the faster zones, especially with your equipment that reduced the
disk speed for recording the master and duplicating it.
Just for the records, did you really use 12 bit syncs and if yes, why
not syncs of 10 or 11 bits which should also have worked? Does it have
something to do with the fact that 12 bits equal three nibbles which is
probably easier to handle during continously writing the master track
than 10 or 11 bits that cause bit shifts between sectors?
Nicolas
V-MAX!
be an early sign of Alzheimer's. Either that, or what I was smoking the
night before!
And you are also correct, that the bit clock runs faster at higher data
rates. Which makes me wonder, how many CPU clocks == 8 bits at that rate?
Anybody have that info handy? I may, or may not, have remembered to factor
that in when I wrote the scheme. So I may, or may not, have had as much
leeway as I thought with drives running above the nominal speed, which as I
recall was supposed to be 300 rpm (or am I getting that confused with CD
ROMs?).
Oh well, Marty has posted the source, so you can always go work it out
yourselves <g>
As for ownership of V-MAX!, I always retained the ownership, along with
Marty. He has made his part available via the GNU GPL, and I hereby do
likewise. Anyone wishing to use V-MAX! or it's derivatives, is free to do
so, providing they adhere to the GNU license requirements, and credit
myself, Marty, and Joe Peter with the original work.
Nicolas Welte wrote in message <382156...@chemie.uni-konstanz.de>...
>V-MAX! wrote:
>> To read a sync byte (and confirm it's existence), you have to test for a
bit
>> which is set by the shift register chip which clocks in each bit, and
sets
>> that bit (and keeps it set) once 12 or more sequential on bits are
detected.
>> This flag only stay up until the first zero bit is clocked in (4 CPU
clock
>> cycles equal one data bit clock, as I recall). Since my sync bytes
were
>> exactly 12 bits long, that was too short to reliably see using the
standard
>> Bit xxxx, bvc back: loop, which had a 5 CPU cycle jitter. Commodore
used
>> extremely long sync bytes, 40 bits as I recall, which wasted a good deal
of
>> space.
>
Cameron Kaiser
>framed (i.e. had no sync bytes) was the last VORPAL loader, which gave us
>migraines just looking at how it managed to accomplish that task. It used
This reminds me. I've been toying with the idea of using the Vorpal loader
in some Computer Workshops titles rather than working on my own routines
for it (it's midterms, I don't want to be worrying about a fastloader, too!).
I can't find out who's licensing it, though. The Vorpal toolkit asserts that
you need a licensing agreement, but of course the address is out of date.
I doubt anyone at today's Epyx knows about the title anymore.
The other thing I've been thinking about is a better compressed-data loader.
That would load fast on any drive, and wouldn't depend on custom formats.
Too much work though.
--
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/ **
Michael Saunders
: As for ownership of V-MAX!, I always retained the ownership, along with
: Marty. He has made his part available via the GNU GPL, and I hereby do
: likewise. Anyone wishing to use V-MAX! or it's derivatives, is free to do
: so, providing they adhere to the GNU license requirements, and credit
: myself, Marty, and Joe Peter with the original work.
That's great -- thanks, Harald (and Marty!) Does that indicate that you
found a source code disk somewhere in your stuff that you're about
to spring on us? <please,please,please> :^)
If not, I've got a loooooooooong way to go before you'll ever see a
disk from me with V-Max! protection...
Mike
mics...@holly.colostate.edu
David Evans
Michael Saunders <mics...@holly.ColoState.EDU> wrote:
[ Marty Franz wrote... ]
>I posted all my old c-64 source code to
>my web site last month. I posted source code to Warpspeed, Superkit 1541,
>Take Down wresting, and *some* VMAX! Source code.
This is pretty impressive. I've always loved Superkit 1541. I still use it
today when necessary--along with PAL/POWER it was the most useful C64 software
that I ever bought.
--
David Evans (NeXTMail/MIME OK) dfe...@bbcr.uwaterloo.ca
Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo "Default is the value selected by the composer
Ontario, Canada overridden by your command." - Roland TR-707 Manual
V-MAX!
Michael Saunders wrote in message <7vsgg0$31...@holly.ColoState.EDU>...
Nicolas Welte
>
> Uh, you are correct. Please replace "12" with "10" in my explanation. Must
> be an early sign of Alzheimer's. Either that, or what I was smoking the
> night before!
;-) Okay, so you used the minimum working value of 10 bit syncs in your
format.
> And you are also correct, that the bit clock runs faster at higher data
> rates. Which makes me wonder, how many CPU clocks == 8 bits at that rate?
There are four possible speed zones, the bit clocks are generated by
dividing the 16MHz master clock by a selectable value of 16,15,14 or 13
and that clock is further divided by four. This leaves us with
250,000bit/s (4 CPU clocks) in the slowest and 307,692bit/s (3.25 CPU
clocks) in the fastest zone. Per byte this is between 32 and 26 cycles
per byte. Since you were using 295rpm drives to record the disks there
is even less available on a standard 300rpm drive. A 305rpm drive still
has 25.1 cycles available in the fast zone.
> Anybody have that info handy? I may, or may not, have remembered to factor
> that in when I wrote the scheme. So I may, or may not, have had as much
> leeway as I thought with drives running above the nominal speed, which as I
> recall was supposed to be 300 rpm (or am I getting that confused with CD
> ROMs?).
No, original CD-ROMs run at variable spindle speed, they have a fixed
data rate. 300kbyte/s was double speed, maybe you remembered that
number. 300rpm is correct for 5,25" double density disk drives like the
1541/1571.
> Oh well, Marty has posted the source, so you can always go work it out
> yourselves <g>
Currently it seems a little bit easier to interview you ;-) But I will
surely have a look at it sometimes.
> As for ownership of V-MAX!, I always retained the ownership, along with
> Marty. He has made his part available via the GNU GPL, and I hereby do
> likewise. Anyone wishing to use V-MAX! or it's derivatives, is free to do
> so, providing they adhere to the GNU license requirements, and credit
> myself, Marty, and Joe Peter with the original work.
Thanks! But now that you revealed all the details (index hole alignment,
295rpm drives,...) I doubt anybody will use it as copy protection. But I
guess it still is a hell of a fastloader ;-)
Nicolas
Michael Saunders
: Should be up on Marty's web site (see other posts)
:>: As for ownership of V-MAX!, I always retained the ownership, along with
:>: Marty. He has made his part available via the GNU GPL, and I hereby do
:>: likewise. Anyone wishing to use V-MAX! or it's derivatives, is free to
: do
:>: so, providing they adhere to the GNU license requirements, and credit
:>: myself, Marty, and Joe Peter with the original work.
I think that Marty's stuff is just the mastering program, not the
actual V-Max loaders/etc. Of course, I'm new (well, after 12+ years,
might as well be) to reading ASM, so maybe it's all there. Has anyone
more knowledgeable than I had a chance to check through those source
disks and see what V-Max! stuff is there?
Mike
mics...@holly.colostate.edu
Dan Gahlinger
But if it's for commercial sale, that would be different.
Apparantly EPYX is now a church... or something.
Dan.
Cameron Kaiser wrote:
> "V-MAX!" <email@address> writes:
>
> >framed (i.e. had no sync bytes) was the last VORPAL loader, which gave us
> >migraines just looking at how it managed to accomplish that task. It used
>
Dan Gahlinger
modified drive, is there any way (practically) to use it?
Dan.
V-MAX!
1) modify the V-MAX! creation utility to work with the expanded memory
provided by some of the hardware kits (so you don't need a parallel drive
connection). Without either a parallel connection to the drive, or expanded
memory, you're pretty much out of luck. With the extra memory, even a 1541
will work, provided you do step 3.
2.) shorten the number of allowable bytes per track (a table entry for each
zone), so that you don't have to slow the drive down to fit the data
3.) Add a long sync mark at the beginning of the track, so that nibble
copiers could find the beginning of the track data without using the index
LED signal. (and remove the beginning of track pattern that was there for
the duplicator's use).
4.) Lengthen the sync marks between data sectors, so that nibble copiers can
see them to insert them in the copies (so the copies load as fast as the
original).
This removes any "copy protection" aspect from V-MAX!, without affecting
it's fast loading capabilities.
Then, If you want to copy protect (for grins only, obviously), put a
signature track of some sort (use your imagination), either at the end of
the VMAX! DOS track, or an unused track. Write a special signature track
check routine, and modify the V-MAX! creation utility to add it to a sector
at the end of one or more tracks (any sector which does not start with a RTS
($60) will autoexecute.) If the protection check fails, erase the GCR
table, and the code doing the checking, and return (by jumping to the code
to move the head back to the original track). Otherwise, just jump back to
the beginning of the read loop, where it looks for the start of a valid
sector (after moving the head back to it's original track), and read in the
next sector normally.
That's what I would have done, had it become generally known how to copy
V-MAX! successfully.
What would I have used as a signature? A special pattern of sync bits and
non-sync bits, where the number of bits in between created a particular
timing pattern, which I would have tested for in a fashion similar to how
the fast serial transfer routine eliminates the 5 clock jitter at the
beginning of the transfer, and maybe some non-reliable gcr patterns, as
well.
Again, Marty's URL was http://www.artmath.com/~mfranz/
Dan Gahlinger wrote in message <382303D2...@bell.ca>...
Dan Gahlinger
Just some more minor questions on this, 3 to be exact...
1. if we do have a parallel cable for the drive (connected already) how does
this alter what we can do with fastload/copy protection?
2. if we add 32k ram to the 1541 as per some instructions on some web sites
namely:
http://members.tripod.com/~ilkerf/chard/1541-32k.txt
does this change our possibilities? I think I remembre it said that an extra 8k
of ram was needed, does 32k ram give us any further possibilities? Does the
above instructions even look like they work?
and finally, the big one
3. what if we have the 32k ram added and also the parallel cable, does the
combination of these two allow us to do any better for making more difficult
copy protection?
Also, I was kind of curious if there was a way, in the signature track to make
it so that if it's not read correctly to have the drive "accidently" (so to
speak) get an all "1s" GCR code (12 "1" bits in a row), that magical mark. Or
even use this code intentionally as part of it or something to that effect.
Try and remember it's been a very long time since I touched GCRs and I may be
WAAY off... Then again, I'm the crazy guy trying to write PC floppies using
GCRs.
Dan.
David Evans
>
>2.) shorten the number of allowable bytes per track (a table entry for each
>zone), so that you don't have to slow the drive down to fit the data
It's not as if slowing down the drive is *that* hard...
David Evans
Dan Gahlinger <dan.ga...@bell.ca> wrote:
>
>1. if we do have a parallel cable for the drive (connected already) how does
>this alter what we can do with fastload/copy protection?
One would assume that the parallel cable merely lets you control more stuff
inside the drive from the computer, rather than by code inside the drive
itself. If you have enough RAM in the drive I'd imagine that you could do
pretty much anything you wanted, except maybe spit SID output directly onto the
disk or something. :)
V-MAX!
to tweak their drive speeds.
David Evans wrote in message <7vve01$3e$1...@watserv3.uwaterloo.ca>...
>In article <s269k9...@corp.supernews.com>, V-MAX! <email@address>
wrote:
>>
>>2.) shorten the number of allowable bytes per track (a table entry for
each
>>zone), so that you don't have to slow the drive down to fit the data
>
> It's not as if slowing down the drive is *that* hard...
>
V-MAX!
Dan Gahlinger wrote in message <3823328C...@bell.ca>...
>Thanks Harald,
>
>Just some more minor questions on this, 3 to be exact...
>
does
>this alter what we can do with fastload/copy protection?
Let's you write an entire track seamlessly.
>2. if we add 32k ram to the 1541 as per some instructions on some web sites
>namely:
>http://members.tripod.com/~ilkerf/chard/1541-32k.txt
>does this change our possibilities? I think I remembre it said that an
extra 8k
>of ram was needed, does 32k ram give us any further possibilities? Does the
>above instructions even look like they work?
I haven't reviewed schematics at that URL, can't say if it works or not.
But no advantage, you either have a full track buffer, or you don't.
>and finally, the big one
>3. what if we have the 32k ram added and also the parallel cable, does the
>combination of these two allow us to do any better for making more
difficult
>copy protection?
>
Not really.
All of the above only serve one purpose, to be able to write out the entire
track in a single pass, without having to turn the write current off mid
track, when you otherwise would run out of buffer space, forcing you to
write out the track piece-meal . Now a really tricky idea would be to try
to spiral track the disk, with no breaks at all, like a CD. *THAT* would be
interesting to see, if you could get it to work. You'd never have been able
to commercially duplicate those disks, however. At least, I couldn't.
>Also, I was kind of curious if there was a way, in the signature track to
make
>it so that if it's not read correctly to have the drive "accidently" (so to
>speak) get an all "1s" GCR code (12 "1" bits in a row), that magical mark.
Or
>even use this code intentionally as part of it or something to that effect.
I don't understand what you mean. Unreliable GCR worked by having too many
"0"s in a row, so the bit clock would get "randomly" out of sync, and/or ov
erflow (which, when that happened, would clock in a phantom "1" bit, where
none actually existed). It might have been possible to change the bit clock
speed on the fly, while writing the 10 "1"s that make up a sync byte (not
12, like I said, my mistake), so as to get a wierd effect, but I never
played with that. The point of my short syncs was to synchronize the
hardware, without giving visibility to the software as to when, where and
how I was doing the synchronization. I suppose a long stretch of zeros,
followed by 9 ones, *might* *somtimes* synchronize the hardware with an
"accidental" sync, but what would be the point? It would be pretty
unreliable, in so far as copy protection was concerned.
>
>Try and remember it's been a very long time since I touched GCRs and I may
be
>WAAY off... Then again, I'm the crazy guy trying to write PC floppies using
>GCRs.
>
You can't do it with MFM. It's a different technology, and you don't have
the low level control from software, that you would need to play with the
mfm clock and data bits. That's besides the fact, that CD-ROM (or even
DVD-ROM) is the distribution media for PC's, not floppies.
>Dan.
>
>"V-MAX!" wrote:
>
>> If you wanted to play with the dos, I would do the following:
>>
>> 1) modify the V-MAX! creation utility to work with the expanded memory
>> provided by some of the hardware kits (so you don't need a parallel drive
>> connection). Without either a parallel connection to the drive, or
expanded
>> memory, you're pretty much out of luck. With the extra memory, even a
1541
>> will work, provided you do step 3.
>> 2.) shorten the number of allowable bytes per track (a table entry for
each
>> zone), so that you don't have to slow the drive down to fit the data
David Evans
>No, the point is if you want to make a disk others can copy, without having
>to tweak their drive speeds.
>
Ahh! Yes, that's true.
Dan Gahlinger
SuperKit.
I wonder if Marty would mind if I put it up online at
http://nexus.vrx.net/mp3
Dan.
Dan Gahlinger
What you say about the PC control of the floppy, I think you'd be very
pleasantly surprised. There were a LOT of protections that remind me so much of
the c64 days. timing sensitive things. "everlock" and others like it come to
mind.
Dan.
Mr. X
> Let's you write an entire track seamlessly.
This bit of extra RAM is something Commodore *really* should have
included in the orginal 1541. Sigh. The drives could have been faster
and held more data. At least by the time they did the 1581 they got
their act together. :(
> All of the above only serve one purpose, to be able to write out the entire
> track in a single pass, without having to turn the write current off mid
> track, when you otherwise would run out of buffer space, forcing you to
> write out the track piece-meal . Now a really tricky idea would be to try
> to spiral track the disk, with no breaks at all, like a CD. *THAT* would be
> interesting to see, if you could get it to work. You'd never have been able
> to commercially duplicate those disks, however. At least, I couldn't.
There was a commercial copy protection on the Apple II called
"SpiraDisk" and it used spiral sectors. Of course, the drive is
controled by the main CPU on the Apple II, so you have much easier
access, and more RAM to work from.
X
Mr. X
> I don't think you can do a real spiral, without breaks, on an Apple
> II drive, because the R/W head moves in discrete steps. I suppose you
> *could* write to the disk during those steps, but I have no idea if
> you could reliably read the result. Probably not.
All drives use discrete steps, even CDROMs, albeit very small ones in
that case.
> There was a protection scheme called "spiral tracking" or "track
> arcing" on the Apple II, that is a kind of synchronized half-tracking:
> the data is laid out on the disk like this:
>
> track 1 datadatadata--------------------------------------------
> track 1.5 --------------datadatadata------------------------------
> track 2 ----------------------------datadatadata----------------
> track 2.5 ------------------------------------------datadatadata--
Yeah, that's the sort of thing SpiraDisk was.
X
Paul Guertin
> > Now a really tricky idea would be to try
> > to spiral track the disk, with no breaks at all, like a CD. *THAT* would be
> > interesting to see, if you could get it to work. You'd never have been able
> > to commercially duplicate those disks, however. At least, I couldn't.
>
> There was a commercial copy protection on the Apple II called
> "SpiraDisk" and it used spiral sectors. Of course, the drive is
> controled by the main CPU on the Apple II, so you have much easier
> access, and more RAM to work from.
I don't think you can do a real spiral, without breaks, on an Apple
II drive, because the R/W head moves in discrete steps. I suppose you
*could* write to the disk during those steps, but I have no idea if
you could reliably read the result. Probably not.
There was a protection scheme called "spiral tracking" or "track
arcing" on the Apple II, that is a kind of synchronized half-tracking:
the data is laid out on the disk like this:
track 1 datadatadata--------------------------------------------
track 1.5 --------------datadatadata------------------------------
track 2 ----------------------------datadatadata----------------
track 2.5 ------------------------------------------datadatadata--
Booting such a disk makes a very recognizable "fluppfluppflupp" sound
(a stethoscope is a useful tool when cracking Apple II disks). This
scheme is hard to copy automatically with a nibble copier because of
bleed-off effects (on an Apple drive, because of the width of the drive
head, writing to track N will overwrite what's on tracks N-0.5 and
N+0.5). So you have to know exactly when the real data begins and ends,
which is difficult to do without boot-tracing the code.
I think there was a more sophisticated variant that used quarter
tracks, too, but it was not used as much. I suspect that's because
quarter-tracking was unreliable on many drives, so sometimes originals
wouldn't even boot.
BTW, I am thoroughly enjoying this thread.
Paul Guertin
p...@sff.net
V-MAX!
simplified version of LZW coding to save disk space and further increase
capacity/reduce load times.
Cameron Kaiser wrote in message ...
Jim Lawless
"Hackers" book as one employed by John Harris when he worked
at Sierra?
IIRC, the technique allowed them to place the Apple and Atatri
versions of some software on the same diskette ( same-side...
mind you...not a "flippy").
Jim Lawless
ji...@radiks.net
http://www.radiks.net/jimbo
Cameron Kaiser
>Forgot to mention, that V-MAX! disks also used run-length encoding and a
>simplified version of LZW coding to save disk space and further increase
>capacity/reduce load times.
Figures. :-) The compressed loader I use is RLE, but it seems to be a little
flaky (first appeared on MGSE, haven't used it since).
Markus Brenner
disassembly from the 'Times of Lore' loader :), and understood the loader to
some degree, however I have one more question:
After the loader is booted up by the EOR read routine, it transfers the
block-transfer routine to the C64 along with some RLE decoding stuff, then
starts loading the first file. The individual blocks are read in and sent to
the computer, finally the 'last' sector is read. So far OK. Now it seems like
afterwards some 'recovery block' (file ID: #$00) is read from the current
track.
What exactly does this 'recovery block' do? Is the floppy reset to normal DOS
operation mode, so the program can use normal DOS commands like SAVE etc.?
And if this is the case, how is the V-MAX! loader kicked back in action? I
didn't notice any 'fast-upload' routines, so my guess is, it is booted up from
scratch, or it is re-envoked by a series of 'M-W' and 'M-E' commands. Can you
please shed some light on that aspect?
Thanks,
-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/
Pontus Berg
<fm...@c264325-a.moline1.il.home.com> wrote:
>> The cracked version I saw of Defender of the Crown was missing the
>> most important disrobing scene!! Typical solution when you couldn't
>> fit all the data on the cracked disks was to leave stuff out...
>Yeah, I remember that version of DOTC, I think ESI did another crack a
>little bit later that fixed the problem. But the original is still
>superior because of the V-MAX fastloader. But yeah, thats a pretty good
>idea for protection, fill the entire disk, up to track 40 and the
>directory track, and then see if you can fit the cracked version back onto
>two disk sides.
It seems the "hacker side" always had surperior packers and crunchers, so i
normally had no problems fitting stuff on the disks. It's of course a major
mess to try to rearrange a program to fit on two sides which was originally on
one, but what is commonly used is to have the main file on side one and the
rest of the data on side two.
The comment above also reminds me of Dragon's Lair on the Amiga. it was
heavily protected but also featured strong compression so that the crackers
were totally lost when trying to make a working copy on the same number of
disk the original was!
>Although ESI did end up cracking California Games (vorpal protection) and
>ended up putting it on 3 disk sides, so I guess there are limits to that
>type of protection. The original was only 2 sides.
Vorpal protection? Was CVorpal also a protection?
Aka: Bacchus/FairLight (UIN 109686)
Phone/Fax: +46-70-5246010 / +46-70-6126010
URL: www.fairlight.to
Get the FairLight CD - www.fairlight.to/cd
Pontus Berg
>Not really. But before RAM expansions for the drives became common, I would
>often either add additional and specific bytes in front of each sync mark,
>or bury a sync mark in an unexpected location. I also sometimes tried to
>check track to track alignment (since commercial disks were always aligned
>by the sync hole). I also used blocks with unreliable GCR (too many off
>bits in a row), and checked to see if they changed from read to read. Hope
>that helps.
Track to track sync seems really efficient in fooling the copiers.
Hain/Elysium did the copy protection for a program called hardTrack composer
and thing I had could back that one up. He used the sync on a sector of track
25 and the bumped the head to track 36 where he read a decyper key for the
routine currently in memory.
Cameron Kaiser
>Vorpal protection? Was CVorpal also a protection?
Sure was. Wasn't Winter Games the first title to have Vorpal protection on it?
Or was it Multiplan? Bizarrely, Programmer's BASIC Toolkit is also Vorpal
protected.
Forrest
I think Vorpal was used on stuff earlier than Winter Games. I used to
have a copy of Barbie that had copyright 1984 that used Vorpal
Protection, but I have no idea what I did with the disk.
Not sure what CVorpal is though.
Forrest
Markus Brenner
>I think Vorpal was used on stuff earlier than Winter Games. I used to
>have a copy of Barbie that had copyright 1984 that used Vorpal
>Protection, but I have no idea what I did with the disk.
Well, similar to V-MAX! Vorpal mainly was a fast loader - Once you removed the
actual copy protection (which is nearly always the same for Summer Games II,
Winter Games, World Games etc.) you can copy those disks with a normal
nibbler (like the zipcode sixpacker), so they didn't use many funky tricks
like V-MAX! did (non-standard sectors, slowed-down floppy drive, non-standard
bit-rates etc.).
BTW, I recently got a copy of an original of 'Rescue on Fractalus', which had
a very similar protection/fast loader layout like this 'early Vorpal' stuff,
but even works from a normal D64 disk image! So my guess is that this is
actually the predecessor for the often used 'early' vorpal loader.
The Vorpal loader used on later products (California Games, Legend of
Blacksilver) of couse is an entirely other beast ...
cheers,