datawiz

Available here: http://204.16.8.40/other/toyshop/
Uploading to Asimov shortly...


Date: 01/10/12
Software: Toy Shop by Br0derbund - 1986
Originals provided by: Tempest
Converted to working NIB images by: datawiz

Description:
Toy Shop was a fun application that allowed you to print out paper
models,
which allowed you to cut them out, fold, and glue them together. 20
working
paper models are available.

6 Disk Images total:
Master Disk Side A (boot this)
Master Disk Side B
Data Disk 1 Side A
Data Disk 1 Side B
Data Disk 2 Side A
Data Disk 2 Side B

Additionally, I have included all 20 model files printed into PDF
files so
they can be used on modern computers.

Technical Notes:
Strangely, this is one of the few applications released by Broderbund
and not
a game, which is what they are normally known for. This game has some
pretty
heavy format-based copy protection. Specifically, it uses 18-sector
protection
which stores the equivalent of 18 sectors of data within a track.
While I
haven't looked, I expect that this protection is very similar to other
big
Broderbund game titles released around that time that also had 18-
sector
protection (Airheart, Wings of Fury, and a bit later Prince of
Persia).

Why protect an application like this? Well, I have 2 ideas on this.
First,
they had already developed the protection scheme, so why not use it?
Secondly,
and I think more plausible, is because this app has so many graphics,
it
actually takes advantage of the additional space. So perhaps the 18-
sector
protection wasn't for protection, per se, but for more storage and to
reduce
the need for ANOTHER data disk (or removing some of the models to
fit).

Initially, I intended on deprotecting the software, and I got to the
point
where I could use their own 18-sector DOS read routines to load in
arbitrary
tracks into memory locations I specified. I had assumed that only the
Boot
disk had 18-sector protected tracks, and on the master disk I found
that
tracks 1-4, 1c-22 had 18-sector protection and the remaining were 16
sector
standard DOS 3.3 format tracks. The program's code has a second DOS to
read
and write standard dos 3.3 as well.

When I dumped the 18-sector tracks, I realized that they were all full
of
data and code, and when I looked at the 16-sector tracks I did not
have enough
free sectors to store the extra sectors for the 16-sector crack. This
is a
problem, as you can guess. Well, out of curiosity, I decided to look
at the
other 5 disk sides. Imagine my surprise when I found that almost all
the
tracks on the remaining disk sides had 18-sector formatting! This
poses a HUGE
problem, and makes it unfeasible to do a full 16-sector rewrite
without a
lot of work. And, as you can guess, these 18-sectors were full of
graphics
and there was little room to store extra sectors for a crack.

So, I decided to build .NIB images, expecting them to NOT work, as
almost
every format based copy protection scheme also includes a secondary
protection.
Normally, this would mean nibble count routines that would fail on a
copy and
reboot or lock up the program. Well, after a few attempts with bit
copiers, I
converted the images to NIBs, and ran them under emulation (Virtual II
on a
Mac). Imagine my surprise to find that everything worked 100% with no
additional nibble patching needed to defeat nibble counting. So there
was no
secondary protection outside of the 18-sectoring, which also makes me
think
that the decision to use 18-sectoring was for the additional disk
storage space.

If you are not interested in Apple II pirate history, then stop
reading now...
--------------------------
Apparently, this application was never cracked and released in the
golden days
of the Apple II when piracy hovered around BBS' and local copy meets.
Having
been in part of this scene in the later 80's, I was intrigued by this,
and I
think having been involved then and now seeing the application and
protection,
I can shed some light on it. I'm not sure there's any interest, but
I'm a bit
of an Apple II Pirate Archaeologist, so I find it fascinating.

First of all, in the Apple II pirate underground, it was unfashionable
to
pirate anything but games. There were probably just as many
educational titles
available for the Apple II during the mid-80s, but if a legitimate
cracking
group released an educational title, other competing groups would
ridicule them.
This sounds utterly ridiculous, but in those days the competition was
high and
this was a rule. So even a very challenging app like Toy Shop would
have fallen
under the category of "edu-ware" and the top tier crackers would not
have touched
it. For an example of the ridicule a group would go through, you can
find crack
screens from groups like First Class, Coast to Coast, USAlliance and
others who
"rag" on groups like The Bunnymen and Circle of Deneb who did release
edu-warez.
Once this top tier of groups turned on you, you were treated as
pariahs on all of
the top tier BBS' of the day.

Assuming that the top-tier crackers associated with these groups were
not interested
in working on a crack for this, there were not many other people with
the
knowledge to undertake a full crack of this, which may be another
reason it was
never done. Research the index of Computist magazines. There are no
full cracks
ever reported, just some tips for nibble copy parameters. Also, while
the app itself
is neat, it's not something all that interesting or fun (like a game),
which means
there probably wasn't a high demand to have it cracked.

Because the disks are packed full of data, a 16 sector crack is really
unreasonable.
If you look at games based on 18-sector protection, in most cases
there is enough
space on the disk to store the additional 2 sectors per track. You can
then rewrite
the game's dos to load in the additional sectors as needed. Refer to
Airheart, Wings
of Fury, and even Prince of Persia. Origin later came out with 18-
sector protection
on Tangled Tales, and the Brain Trust crack of this game appears to
use an additional
boot disk for the initial load up of the 18-sector tracks, which is
another approach
if there's not enough free space on the disk.

Finally, while this game would have been difficult to crack back in
those days, there
is an approach that could have been used to distribute a working copy.
A program
could be written to read a track on a protected disk, and save it's
nibbles out.
A separate program would be written to re-assemble the nibble images
back into a
disk that has a non-standard format that would work (assuming the
crackist removed
secondary protection in the nibblized images). The downside to this is
that, obviously,
you still have an uncracked version, but the bigger issue is that for
each disk side,
it takes 2 disks of data to store the nibblized disk data. That will
essentially
DOUBLE the application. So, Toy Shop is a 3 Disk program, that's 6
sides. It would take
12 disks total for the nibblized images, plus another disk for the re-
assembly program
for a total of 13 disks! This is essentially with SST (Saltine's Super
Transcopy) does,
but this application would be custom written for the game/app you are
pirating. I
have seen something like this in the BBS scene before, but I can't
remember which
game it was for (perhaps Battle Chess for the Apple IIe, release by
the Byte Bastards).

In our days of modern technology and virtual disk images, it's really
no
big deal, but recall technology in the mid-80s: Disks were NOT cheap,
data was transferred
over TELEPHONE lines. Analog! At earth-shattering speeds of 2400 Baud
IF YOU WERE LUCKY.
Most people still puttered along at 1200 or maybe 300 BPS still...

Assuming 20 minutes a disk side, you are still looking at over 4 hours
to upload/download
this program as a pirate. Back then, most reputable pirate boards ran
on a credit
system. You had credits to use for downloads, or a ratio that gave you
so many download
credits per upload. So spending hard earned credits to download this
would seem silly,
especially if your opportunity cost is something like Airheart or
Wings of Fury. Also,
disk space on BBS' were at a premium, so I can also see BBS System
Operators getting
angry at a person uploading this "junk" (recall, this would have been
considered an
edu-ware), and they would probably nuke (delete) it on the spot to
save space for an
highly anticipated game or utility.

This is long and rambling. Sorry if you were forced into reading it.
You will never, ever
get those precious minutes back. It just amuses me that I keep
encountering rich
background stories as I tear into this old software, and my mind looks
back at the events
and environments of those days. I'm sure I'll run into more, and I
can't wait.

Rich/datawiz

Vladimir Ivanov

On Tue, 10 Jan 2012, datawiz wrote:

> Specifically, it uses 18-sector protection
> which stores the equivalent of 18 sectors of data within a track.

Interesting, I haven't looked so far into 18 sector schemes.

Just by a quick glance, track #0 of "master_a" disk has visibly 17
sectors. There are also two instances of hard sector #1, with different
data.

Sync fields are also generous. They must have slowed down the writing RPMs
quite much to fit this many bits.


Now that I look at it, NIB's track length of 6656 (0x1A00) nibbles is not
enough to carry 18 sectors with such sync fields. I suspect they're either
not 18, or something went wrong in the conversion.

datawiz

Hey Vlad,
Track 0 is in a normal 16-sector format. Here's some more from my
notes:

Protected tracks will be T1-4, T1C-22. All the rest are normalized.
If you want to see the second stage boot code that reads in the 18-
sector track, boot the master a disk and enter the debugger at the
first hgr title screen and at look at $6803. This is called after the
address marker is read (D5 9D XX XX XX AA).

A5 marks the start of data
The loop runs for 256 iterations (via y) and reads 4 bytes from the
drive per iteration.
The disk bytes are 6+2 encoded, and the first byte holds the "2" bits,
and the next 3 bytes are the 3 "6" bytes.
These 4 disk bytes are translated to 3 data bytes (translate table is
at $6e00) and stored in memory.
D4 marks the end of data
This will yield 3 pages of data in memory per call, and is called 6
times in a track read for a total of 18-sectors of data per track.

There's a table set up at $6e43 that holds the memory pages in which
to store the data as it reads it from the disk and is translated.
This is always set up with 18 pages. In the read routine, $26, $28,
$2A are used to indirectly store the translated and decrypted byte
($26),Y for instance.

The 18-sector dos is used with a JSR to $69E7 followed immediately
with a command.
Commands are:
00 = turn on drive motor
01 = turn off drive motor
02 = seek to track followed by 00 XX (XX is track number(
03|43 = read track and store contiguous (18 pages) followed by XX
(start page in memory to store data)
04|44 = read track and store non-contiguous (18 pages) followed by 18
values of memory pages to store data to

At $6b41 the program makes it's first call to the dos, which is:
JSR $69E7 followed by 02 00 01 (seek to track 1)
JSR $69E7 followed by 43 20 (read, store starting at page $20 -- HGR1
screen)
After this point, track 1 is read, translated, and stored at $2000-
$31FF

Later in the application, the dos is relocated and called in a
different place. I think it's in the $4300 range. This dos is
sufficient to read in protected tracks on all disks, so that's where I
stopped.

I hope that helps!

Tempest

I'm just glad it's finally cracked and uploaded. I've had these disks
since forever (I bought the program new back in the day and spent far
too many hours putting those little contraptions together), so I never
knew it wasn't available online until I checked the Asimov missing
list last year. Of course cracking something like this was out of my
league (if Locksmith doesn't crack it then it's beyond me) so even
though I had the missing disks, I couldn't do anything with them. But
after a chance conversation with datawiz about an unrelated topic, we
got to talking about cracks and the 'old days' and everything fell
into place.

Tempest

Vladimir Ivanov

Hello datawiz,

On Wed, 11 Jan 2012, datawiz wrote:

> Track 0 is in a normal 16-sector format.

Now I see. I got the following sector numbers:

$00, $01, $10, $11, $02, $03, $12, $13,
$20, $21, $30, $31, $22, $23, $32, $33

Sector $01 is present two times, but I guess it's because of the imaging
buffer, leftovers and read repetitions. After the second $01 data end
marker ($DE $AA) there is some leftover chunk from sector $00.

Did you use SST or your own program? The reason I ask is because I am more
concerned with the leftovers in the track image and whether they can be
avoided, such as pre-filling the $1A00 buffer with $FF or anything
smarter, depending on the reading algorithm.

> Protected tracks will be T1-4, T1C-22. All the rest are normalized.
> If you want to see the second stage boot code that reads in the 18-
> sector track, boot the master a disk and enter the debugger at the
> first hgr title screen and at look at $6803. This is called after the
> address marker is read (D5 9D XX XX XX AA).
>
> A5 marks the start of data
> The loop runs for 256 iterations (via y) and reads 4 bytes from the
> drive per iteration.
> The disk bytes are 6+2 encoded, and the first byte holds the "2" bits,
> and the next 3 bytes are the 3 "6" bytes.
> These 4 disk bytes are translated to 3 data bytes (translate table is
> at $6e00) and stored in memory.
> D4 marks the end of data
> This will yield 3 pages of data in memory per call, and is called 6
> times in a track read for a total of 18-sectors of data per track.

Got it this time. The 6 big "sectors" and the short headers and sync make
the total length well within the limits.

> I hope that helps!

Thank you very much for the detailed explanation!

Cheers,
-- Vlad

Antoine Vignau

A long time ago, in France...
It was a dark and stormy night ((c) Schulz),
It was about 18-sec protections,
It was in 1988...

@ http://boutillon.free.fr/Underground...f19/Gdf19.html

antoine

ps. I hope you read French ;-)

Michael J. Mahon

Antoine Vignau <antoine.vignau@laposte.net> wrote:
> A long time ago, in France...
> It was a dark and stormy night ((c) Schulz),
> It was about 18-sec protections,
> It was in 1988...
>
> @ http://boutillon.free.fr/Underground...f19/Gdf19.html
>
> antoine
>
> ps. I hope you read French ;-)

Unfortunately, I don't. ;-(

I presume that there are not 18 separately addressable sectors, but rather
a few large (>256 bytes) sectors that add up to 18 "sectors worth" of data.
It sounds like only whole tracks are read.

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

datawiz

On Jan 12, 5:27*pm, Michael J. Mahon <mjma...@aol.com> wrote:

> I presume that there are not 18 separately addressable sectors, but rather
> a few large (>256 bytes) sectors that add up to 18 "sectors worth" of data.
> It sounds like only whole tracks are read.

Correct. The term 18-sector has always been a bit of a misnomer. There
aren't 18 individual sectors (if there were, you wouldn't be able to
fit it in the track), but it's the equivalent of 18-sectors of data in
the same track. In the case of the Broderbund protection, there's 6
sectors presented per track, but the read routines always read a
complete track at a time.

Vlad,
To create the NIB images, I used SST as it (and EDD) were the only bit
copiers I had that let me specify both source and destination disks on
different slots, so I could use my CFFA3000 (I LOVE THIS THING, btw!).

Antoine,
Thanks for the link to the 18-sector page. Even through babel fish, I
could understand it enough that it helped clear up some things in the
toy shop protection that I didn't understand completely.

Rich

Antoine Vignau

IIRC from the disk image copy I did from Wings of Fury, you specify a
12b buffer to the read command.

That buffer contains the high RAM pointer where the "sectors" must be
loaded. It one value is zero, it means don't load the sector.

For instance:
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 will load 18
sectors from a track
20 21 22 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 will load the
first 4 sectors
00 00 00 00 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D will load 14
sectors

Antoine

Vladimir Ivanov

On Thu, 12 Jan 2012, Antoine Vignau wrote:

> A long time ago, in France...
> It was a dark and stormy night ((c) Schulz),
> It was about 18-sec protections,
> It was in 1988...
>
> @ http://boutillon.free.fr/Underground...f19/Gdf19.html

Interesting. RWTS18 has command for writing individual sectors with
parameter bitmap similar to "read" command - which I don't see working for
the 18 sector case, except if the whole track is written at once. Even
writing of a single (1 out of 6) macro sector is little questionable with
such small sync gaps as seen on the Toy Shop image.

Aren't all 18 sector tracks read-only in all installations? Is that RWTS18
write command actually for 16 sectors? Did I miss something?

Oh, and I should check Trinity some day ..

> ps. I hope you read French ;-)

Unfortunately, no.

Salut, Deckard!