richwind writes ...
There are several approaches to making backups. One is to use a
whole-disk 'fast copier' such as Disk Muncher or Diversi-Copy. These
usually work fine so long as the disk to be backed up is not copy
protected.
Educational software is often copy protected. If a lot of your
software is from MECC, a good try is to get an MECC copy program by John
Kielkopf named
"meccopy". You can find it as meccopy.sdk on Ground at ...
ftp://ground.ecn.uiowa.edu/2/apple2/apple8/Utils/
Meccopy will make copy de-protected copies of many MECC products. (To
get the program going on your Apple II, transfer meccopy.sdk file to the
Apple and use ShrinkIt 3.4 to unshrink the file to a formatted 5.25"
diskette.)
A different way to get backups of copy protected software is to use
a whole-disk copier with built-in features to deal with specific copy
protection schemes-- like Copy II Plus, Locksmith, ... . Later versions
of Copy II Plus (v7.1 and later) include a 'Bit Copier' with a large
library of parms to copy many pieces of copy protected software.
Probably the quickest way to get backups for copy protected
software is to access one of the major Apple II archives and download
already-deprotected copies of the stuff you want backed up. Educational
software is probably the least well represented area; but, there is a
chance you will find some of the titles you wish to back up on Asimov or
Asimov-GS ...
ftp://ftp.apple.asimov.net/pub/apple_II/
ftp://apple.cabi.net/pub/apple_II/
ftp://mirror.aarnet.edu.au/pub/apple_II/
ftp://mirror.apple.asimov.net/pub/apple_II/
ftp://apple.cabi.net/pub/applegs/
A good 'starting off' place for information about the Apple II
(which includes a listing of other A2 info sites) is the Csa2
(comp.sys.apple2) newsgroup FAQs at ...
ftp://ground.ecn.uiowa.edu/apple2/Faqs/
http://www.grin.net/~cturley/A2.FAQs.and.INFO/CSA2.FAQs/
ftp://apple.cabi.net/pub/applegs/FAQs.and.INFO/A2.Csa2.FAQs/
ftp://ground.ecn.uiowa.edu/2/apple2/Faqs/Formatted/
Start with the first file listed.
When there are more questions (about copying, downloading,
transferring files from PC to Apple II, ...), this newsgroup is the
place to post them.
Rubywand
> Later versions
> of Copy II Plus (v7.1 and later) include a 'Bit Copier' with a large
> library of parms to copy many pieces of copy protected software.
Minor quibble -- Copy II Plus version 6.6 had a parameter library.
Version 4.3 did not (the user had to change the parameters manually
with the / key, if memory serves). I don't know about versions
between 4.3 and 6.6.
Paul Guertin
p...@sff.net
> There are several approaches to making backups. One is to use a
> whole-disk 'fast copier' such as Disk Muncher or Diversi-Copy. These
> usually work fine so long as the disk to be backed up is not copy
> protected.
Ah, Disk Muncher (Written by The Stack -- Corrupt Computing). Nice
little program. Does anyone know who The Stack was, and if he/she
wrote any other utilities? I don't remember seeing that nickname
anywhere else.
Also, I would love to learn more about the Apple II cracking/piracy
scene during the late 70s and 80s. But the only materials I have are
1) The title pages of cracked games I have,
2) Some how-to disks like Krakowicz Kracking Korker,
3) A few issues of Computist magazine.
I think it would be interesting if the former sysops of underground
Apple II BBSes would distribute their logs on the Internet. It is,
after all, an important part of Apple II history.
Paul Guertin
p...@sff.net
> Educational software is often copy protected. If a lot of your
> software is from MECC, a good try is to get an MECC copy program by John
> Kielkopf named
> "meccopy". You can find it as meccopy.sdk on Ground at ...
>
> ftp://ground.ecn.uiowa.edu/2/apple2/apple8/Utils/
>
> Meccopy will make copy de-protected copies of many MECC products. (To
> get the program going on your Apple II, transfer meccopy.sdk file to the
> Apple and use ShrinkIt 3.4 to unshrink the file to a formatted 5.25"
> diskette.)
>
> A different way to get backups of copy protected software is to use
> a whole-disk copier with built-in features to deal with specific copy
> protection schemes-- like Copy II Plus, Locksmith, ... . Later versions
> of Copy II Plus (v7.1 and later) include a 'Bit Copier' with a large
> library of parms to copy many pieces of copy protected software.
>
PN(G| Ah, Disk Muncher (Written by The Stack -- Corrupt Computing).
| Nice little program. Does anyone know who The Stack was, and if
| he/she wrote any other utilities? I don't remember seeing that
| nickname anywhere else.
Now you got me in reminiscing mode...
Krak-Man, Mr. Xerox, the Black Bag, the 212, and so on...
I've never seen anything else by The Stack either, but never really
took much stock in Disk Muncher 1.0 because despite the 13 second read
and 13 second write (that's cool, pirate a plain ol' disk during the
30 seconds your friend is in the bathroom) it wasn't terribly
effective. Neither was Crazy Copy (could never get it to run on an
enhanced //e or higher) except for in one case, the teacher's hacked
copy of Print Shop (Crazy Copy copies worked *better* than the dupe
they came off of). Sigh, those were the days...
* 2qwk! 2.04 * FORMAT: The easiest way to keep software out of others hands.
> Now you got me in reminiscing mode...
>
> Krak-Man, Mr. Xerox, the Black Bag, the 212, and so on...
1200 Club, Gumby, Disk Jockey, the MPG, Tom E. Hawk, Apple Rebel...
> I've never seen anything else by The Stack either, but never really
> took much stock in Disk Muncher 1.0 because despite the 13 second read
> and 13 second write (that's cool, pirate a plain ol' disk during the
> 30 seconds your friend is in the bathroom) it wasn't terribly
> effective.
What do you mean by "not terribly effective"? Sure, it wasn't that good
a bit copier, but it was great for copying cracked wares. Much better
than COPYA.
The first bit copier I used was Locksmith 3.1. Boy, that was slow. Then
someone gave me a nice program called "Pirate's Friend", which was much
faster (it copied 2 or 3 tracks per pass, with no delays). It became
my favorite until Disk Muncher came around. I couldn't believe how fast
that was. And then I got Locksmith 5.0, with the Fast Disk Copy that
could duplicate a disk in 16 seconds flat, or do a copy+verify in 24
seconds. Difficult to do better than that because at 300 rpm, you need
at least 7 seconds to read or write 35 tracks.
When I tried to copy a protected program, I generally tried DM or LSFDC
first, then Copy II Plus (4.3, then 6.6 when I got it), and if that
didn't work it was time to sit down and try to understand what was going
on...
I had disks full of copy programs (EDD, Echo, Nibbles Away, Back-It-Up,
The Clone Kit, Penulti Copy, Magnetic Xerox...) but I rarely used them.
Paul Guertin
p...@sff.net
Thank you,
Jason Whorton
http://www.microxl.com/oldcomputers/main.html
Paul Guertin wrote in message <36a07a20...@news.newsguy.com>...
I uploaded it to Ground last year for the needs of all A2 users today that
might find a need for such back-ups of old A2 (5.25 disk) titles they wish
to duplicate and preserve for their needs.
the url and text file documentation for DM1 follows:
ftp://128.255.21.234//2/apple2/apple8/Utils/DM1.sdk
--------------------------------------------------------------------------
------
Disk Muncher v1.0 is copyrighted freeware, for duplication of 5.25
disks. It's a DOC 3.3 disk that should allow exact duplicate/backup
for any 5.25 disk you have, in any format; DOS3.x, CPM, Pascal,
ProDOS or any other exotic DOS known.
The archive 'DM1.sdk' is a shrinkit (.sdk) 5.25 disk archive which
unshrinks as a self booting standard DOS 3.3 disk.
If your Apple II computer model does not support 80 Col. then it
defaults to 40Col. The disk will boot from any know Apple II
computer model (including IIgs - ROM 01 or ROM 03) or clone. Using
two 5.25 Apple II disk drives, and having 128k of memory you can do
a single disk copy with automatic ease.
This is by far, the best disk duplication version of Disk Muncher
ever released. Note: to varify a reboot, type Y
--------------------------------------------------------------------------
-------------
Cheers,
Tom
> Krak-Man, Mr. Xerox, the Black Bag, the 212, and so on...
PN(G| 1200 Club, Gumby, Disk Jockey, the MPG, Tom E. Hawk, Apple
| Rebel...
I remember about half of those...
PN(G| What do you mean by "not terribly effective"? Sure, it wasn't
| that good a bit copier, but it was great for copying cracked
| wares. Much better than COPYA.
Most things were better than COPYA. I pity the fools who used FID. :)
PN(G| The first bit copier I used was Locksmith 3.1. Boy, that was
| slow. Then someone gave me a nice program called "Pirate's
| Friend", which was much faster (it copied 2 or 3 tracks per
Pirate's Friend was okay, and I started with Locksmith 4.2.
| got Locksmith 5.0, with the Fast Disk Copy that could duplicate
I hardly ever used LS5's Fast Disk Copy unless I knew it was a DOS
disk, and used the regular slooooooow one for the harder stuff.
PN(G| I had disks full of copy programs (EDD, Echo, Nibbles Away,
| Back-It-Up, The Clone Kit, Penulti Copy, Magnetic Xerox...)
EDD is good; a friend gave me two versions and a photocopy of the parms
list for it :) :) so I was pretty set. Used Nibbles Away (1 and 2) a
lot, passed on Back-It-Up and Clone Kit, never heard of the others.
Was always holding out for the Smiths (gold, silver, diamond).
Copy II+ (version 5.2 through 9.1) were always *the* place to start. :)
* 2qwk! 2.04 * EDLIN: The computer world's version of mud-and-stylus writing.
Jason Whorton writes ...
>
> Hi. Since the topic is being discussed, will I be able to copy my
> "copy-protected" programs to a hard drive? I have a few copying programs,
> but I haven't used them in a while and I was just backing up software I
> bought to another floppy (honest :-), so I have no experience with copying
> it to a hard drive. If anyone has any suggestinos or information, please
> let me know.
For sure, it is very nice to have copies of favorite games and
other old wares on diskette backed up on hard disk. You can use ShrinkIt
v3.4 to convert a deprotected 5.25" or 3.5" diskette to shrinked form
(usually called an ".sdk" file). These generally run about 70kB or so
for a shrinked 5.25" diskette side. It takes ShrinkIt about a minute to
convert a shrinked disk file back to diskette form; so, .sdk files on
hard disk is a practical way to reclaim space taken up by stacks of
diskettes.
If the idea is to run the software from your hard drive, then, as
Brian indicates, you can eliminate quite a few wares.
Most old 5.25" protected software ends up as DOS 3.3 or some
variant when deprotected. Quite a few of these make assumptions about
format which makes running them from hard disk impossible without
modification or, even, dangerous. For example, a game which does
direct-to-disk writes could trash hard disk files and directories.
The best way to run deprotected DOS 3.3 and weird-DOS wares is to
just boot the game or whatever from Slot 6, Drive 1.
Deprotected ProDOS wares are more likely to run okay from hard
disk. Still, a ProDOS program may assume that it is running from a
specific diskette and feel safe in writing "High Scores", "Learner
Progress", "Config", etc. to a specific block which, on your hard disk,
could be the middle of a directory. It is safer to transfer deprotected
5.25" ProDOS files to 3.5" diskette and run them under ProDOS booted
from the diskette.
Checking through the "Cracks", "Deprotects", ... folders of sites
like Asimov and Asimov-GS will produce help in moving some popular
products to hard disk. Unfortunately, hard disk for Apple II was so
expensive for so many years that relatively few users even owned one
until the 1990's. There is much more information for deprotection than
there is for converting wares for hard disk.
Rubywand
Okay, so they can't copy a protected disk. But need a quick back-up of
ANYTHING not protected? Is 26 seconds fast enough? How about a classroom
set of the strange little routine that Althoff and friend cooked up for
BASIC Programming II? Done.
Then there was the truly serious production copy program, Penaulti. Like
Disk Muncher, it can't handle protected disks. And it is slower than Disk
Muncher. But it could make nine copies at a time if you had enough disk
drives connected!
If you're trying to pirate warez, those copiers are pretty useless. But
if you've been given the chore of making a dozen copies, or copying a
dozen disks (I've had to do both...this is high-school computing,
remember, and I was the student who got called on to do that stuff), such
programs are really, really nice to have!
--Dave Althoff, ][.
--
/^\ _ _ *** Closed for the season 8-( ***
/XXX\ /X\ /X\_ _ /X\__ _ _ _____
/XXXXX\ /XXX\ _/XXXX\_ /X\ /XXXXX\ /X\ /X\ /XXXXX
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXX\__/XXX\_/XXX\_/\_/XXXXXX
It's about time you replied to my post -> Roachbag :) I've been waiting for
your skilled comments for almost a week now. It's really amazing how you seem
to know with such perfection, more about the programs than even the authors
know about them. But, then why not? You are - after all - the 'Grand Wizard'
of the Apple II world - aren't you?
Cheers,
Tom
: > I always used DM1 (which was a
: > very special version) that was made as a collective effort by some of
: > the most skilled krackers of that time.
: All versions of Disk Muncher disabled checksum and trailer validation,
: making disk copying completely unreliable yet to the naive seemingly
: faster and more reliable. Serves anyone right who actually used the thing.
Interesting. I had a darned near 100% success rate with Disk Muncher
copies of never-protected DOS 3.3 disks. Granted, I was only asking it to
do the easy jobs, but that was all I needed. Did I just get lucky?
> I always used DM1 (which was a
> very special version) that was made as a collective effort by some of
> the most skilled krackers of that time.
All versions of Disk Muncher disabled checksum and trailer validation,
making disk copying completely unreliable yet to the naive seemingly
faster and more reliable. Serves anyone right who actually used the thing.
> I'd say it made perfect working copies of about
> 96% of all the A2 software titles I made copies of during that period
> and era of time from 1981 to 1993.
Says it all really.
>All versions of Disk Muncher disabled checksum and trailer validation,
>making disk copying completely unreliable yet to the naive seemingly
>faster and more reliable. Serves anyone right who actually used the thing.
Completely unreliable? Far from it. When the disk drives became more
reliable (not the old fat 5.25 inch drives with that big metal disk at the
bottom) the checksums weren't needed as much (I doubt even the old drives
were that unreliable). In most cases the copy protected disks stuck to the
basic Apple format and just changed the D5AA96 part (main header start
marker) to something different (e.g. BBAAD5). It was mainly the D5AA96 and
D5AAAD (end marker) which counted. The D5AAEBs (subheader markers) were
mostly not important (Woz very conservative?). In many cases they still
used the same checksum method for the data.
Hmm, interesting what sticks in the brain. Ah, nostalgia :).
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @peo...@uu.net
pop.jaring.my @
*******************************
Weren't needed AS MUCH?
> Interesting. I had a darned near 100% success rate with Disk Muncher
Darned near? I wouldn't stand for anything but.
> It's really amazing how you seem to know with such perfection,
> more about the programs than even the authors know about them.
The authors didn't post about their programs, you did.
> All versions of Disk Muncher disabled checksum and trailer validation,
> making disk copying completely unreliable yet to the naive seemingly
> faster and more reliable. Serves anyone right who actually used the thing.
"Completely unreliable" is an exaggeration, I think. I used Disk
Muncher quite a lot for some time, and it worked very well. In fact,
when I started using Locksmith's fast disk backup (which does verify
the checksums and prints an error diagnostic if it has to re-read a
sector due to a checksum error), it confirmed that checksum errors
were extremely rare on my system (unless the disk itself had a weak
spot).
Paul Guertin
p...@sff.net
Yes, you did. I was using it to make backup copies of my checkbook data
disk until I needed to use a backup to recover... One bad sector on the
backup that was never detected by Disk Muncher, and a long evening
trying
to piece my files back together. ;-(
-michael
Digital data is frequently copied many times in the course of
its use, and the design of _any_ copy utility should aim to
perform copying _absolutely flawlessly_, within the limits
of the technology. This is why any copy program should,
by default, read back copied data and verify that it is
identical to the original if there is any possibility of an
error (as there is on disk).
I suspect that this was not the motivation of the author of
Disk Muncher, who apparently was more interested in
speed than accuracy. Those who do not keep backups
of important data value speed (when things work) over
speed when they don't work. ;-)
A hundred good copies and one bad one is a terrible record
in my book--unless you routinely make _two or more_
copies of important data, since 1 chance in 10,000 or 1,000,000
of an unrecoverable error might be sufficient for many
purposes.
>On Wed, 20 Jan 1999 02:28:08 +1100, rich...@genie.com (Richard Bennett)
>wrote:
>
>> All versions of Disk Muncher disabled checksum and trailer validation,
>> making disk copying completely unreliable yet to the naive seemingly
>> faster and more reliable. Serves anyone right who actually used the thing.
>
>"Completely unreliable" is an exaggeration, I think. I used Disk
>Muncher quite a lot for some time, and it worked very well. In fact,
>when I started using Locksmith's fast disk backup (which does verify
>the checksums and prints an error diagnostic if it has to re-read a
>sector due to a checksum error), it confirmed that checksum errors
>were extremely rare on my system (unless the disk itself had a weak
>spot).
>
>Paul Guertin
>p...@sff.net
-michael
Email: mjm...@aol.com
Home page: http://members.aol.com/MJMahon/
: Digital data is frequently copied many times in the course of
: its use, and the design of _any_ copy utility should aim to
: perform copying _absolutely flawlessly_, within the limits
: of the technology. This is why any copy program should,
: by default, read back copied data and verify that it is
: identical to the original if there is any possibility of an
: error (as there is on disk).
True. But I imagine the value of the program is tempered by the actual use...
I used to use Disk Muncher quite a lot...not for making backup copies, but
for making distribution copies. And if one of the copies failed...well,
we made another one. "Distribution" in this case is the 1980's classroom
version of computer networking, so it's not like anyone had to go through
great difficulty to fix a blown copy.
Still, I don't remember any failures...
Oh, for my own backups of the era, I didn't use copy utilities...I used
redundant SAVEs instead.
>My guess is that everyone has already made up their mind
>about Disk Muncher, but...
>
>Digital data is frequently copied many times in the course of
>its use, and the design of _any_ copy utility should aim to
>perform copying _absolutely flawlessly_, within the limits
>of the technology. This is why any copy program should,
>by default, read back copied data and verify that it is
>identical to the original if there is any possibility of an
>error (as there is on disk).
I suspect checking of trailers and checksums was disabled in order to
backup/copy copy protected software, not to speed things up.
Not checking things does not speed things up, because you still have to
wait for the disk nibbles to spin around.
If you cannot make a single copy because the checksums/trailers/headers are
intentionally nonstandard, then you usually switch to a copy program which
can deal with that. Even if it makes one bad copy out of 100, it's better
than making zero copies out of 100.
Because of the Apple II disk system design there is no easy way to make
sure the nibble data is identical from within a standard Apple II system.
Some systems didn't even use the usual 10 bit FF syncs, you could do have
11 bit ones maybe even 12 bit. e.g. instead of using the following to
synchronise
1111111100 1111111100 1111111100 1111111100 1111111100
you used
11111111000 11111111000 11111111000 11111111000
If you know what you were looking for it's fine but trying to find and
recreate these patterns for perfect copies was nontrivial given that the
6502 was running only at about 1MHz.
> MJMahon (mjm...@aol.com) wrote:
> : Digital data is frequently copied many times in the course of
> : its use, and the design of _any_ copy utility should aim to
> : perform copying _absolutely flawlessly_, within the limits
> : of the technology. This is why any copy program should,
> : by default, read back copied data and verify that it is
> : identical to the original if there is any possibility of an
> : error (as there is on disk).
For maximum safety, the verify step should be done on a different
drive. I had a backup fail once because the (5 1/4 inch) disk was
off-center in the drive. It copied and verified OK, but of course
there was no way of reading the data back when the backup was
needed. Locksmith 6.0's disk recovery saved the day and could
restore almost everything on the disk, except a few sectors on
track 0.
> Oh, for my own backups of the era, I didn't use copy utilities...I used
> redundant SAVEs instead.
So did I, and the really important stuff got printed on paper and
stashed somewhere safe. Human-readable backups bring me peace of
mind.
Paul Guertin
p...@sff.net