--------The Music Class: Symbols-------
A 4am crack                  2014-09-08
---------------------------------------

"The Music Class: Symbols" is a 1985
educational program by Frank Bradshaw
and Virgil Hicks and distributed by
Wenger Corporation. My originals say
"Version 2.10" on the outside label and
on the title screen.

The program comes on two double-sided
disks. All sides are bootable, and each
is independent of the others.

- Disk 1: "Music Box I"

- Disk 2: "Music Box II"

- Disk 3: "Music Box Tool Kit"

- Disk 4: "Music Box Tool Kit"

The program appears to be Apple
Pascal-based. The boot sequence has
that distinctive Pascal smell: several
sequential track reads, filling the
screen with null bytes, switching to 80
column mode, clearing the screen,
showing the block cursor in the upper
left corner. I even recognize the font
on the graphical title screen; they're
calling the WSTRING function in the
standard TURTLEGRAPHICS unit.

Anyway, COPYA fails immediately and
miserably on all disks. Turning to my
trusty Copy ][+ sector editor, I press
"P" to get to the Sector Editor Patcher
and select "DOS 3.3 PATCHED". This
option ignores checksum bytes and
epilogue sequences. As long as the
address and data prologue are standard
("D5 AA 96" and "D5 AA AD"), this will
allow me to read each sector. And lo
and behold, it works! I can read the
data from every sector on every track.

Given the (relatively) weak structural
protection, I used to turn to the DOS
3.3 master disk, patch the RWTS to
ignore checksums and epilogue bytes
(changing $B942 from "SEC" to "CLC"),
and run COPYA. Then, one fine day, and
completely by accident, I came across
an original disk with a bad sector. I
suppose this shouldn't surprise me.
These floppies are decades old by now;
it's amazing any of them work at all.

The point is, I shouldn't be using
tools that ignore potentially serious
read errors. There are other tools,
like Super Demuffin, that can convert a
disk like this (with non-standard
epilogue bytes) into a standard format.
It requires figuring out what the
actual epilogue bytes are, but it has
the advantage of surfacing a read error
if the original disk actually has a
read error.

So... no more COPYA+B942:18 patch. From
now on, it's Super Demuffin or Advanced
Demuffin to convert disks to a standard
format. Given that this disk is Pascal-
based, my AUTOTRACE program will be
essentially useless. (Note to self:
extend AUTOTRACE to extract the RWTS
from Pascal and ProDOS disks.)

The Copy ][+ nibble editor confirms the
standard address and data prologues,
but the address epilogue is "DE DE".
("DE AA" is the standard.) Further
inspection suggests that every track
uses the same encoding.

It's time for Super Demuffin.

Super Demuffin is a utility built on
top of Locksmith Fast Disk Copy. It
takes a disk that uses non-standard but
uniform structure, and it converts it
to a standard disk format. I've
included a copy on my work disk.

When you first run Super Demuffin, it
asks for the parameters of the original
disk. In this case, the prologue bytes
are the same, but the address epilogue
uses "DE DE" instead of "DE AA". I just
need to change that parameter (shown
below).

                 --v--

      SUPER-DEMUFFIN AND FAST COPY
Modified by: The Saltine/Coast to Coast


   Address prologue: D5 AA 96

   Address epilogue: DE DE EB    DISK
                        ^^     ORIGINAL
   was "AA"-------------++

      Data prologue: D5 AA AD

      Data epilogue: DE AA EB


 Ignore write errors while demuffining!


  D - Edit parameters
      <SPACE> - Advance to next parm
      <RETURN> - Exit edit mode
  R - Restore DOS 3.3 parameters
  O - Edit Original disk's parameters
  C - Edit Copy disk's parameters
  G - Begin demuffin process

                 --^--

Pressing "G" switches to the Locksmith
Fast Disk Copy UI. It assumes that both
disks are in slot 6, and that drive 1
is the original and drive 2 is the
copy.

[S6,D1=original disk]
[S6,D2=blank disk]

                 --v--

     LOCKSMITH 7.0  FAST DISK BACKUP


   R...................................
   W***********************************
HEX 00000000000000001111111111111111222
TRK 0123456789ABCDEF0123456789ABCDEF012
   0...................................
   1...................................
   2...................................
   3...................................
   4...................................
   5...................................
   6...................................
   7...................................
   8...................................
   9...................................
   A...................................
   B...................................
   C...................................
   D...................................
12 E...................................
   F...................................
[               ] PRESS [RESET] TO EXIT

                 --^--

(All four disks have the same non-
standard epilogue bytes, so I repeat
this procedure for each disk.)

Now I have a copy of each disk in a
standard format that can be read by any
third-party tool. That is, I can copy
these disks with COPYA or Locksmith
Fast Disk Backup, without patching the
DOS 3.3 RWTS beforehand. I can sector
edit the disk without messing with the
Sector Editor Patcher. &c.

Depending on how the original RWTS was
written, a demuffin'd disk may not be
able to read itself. Sometimes when a
disk is authored with non-standard
epilogue bytes, the developers just
patch the RWTS to ignore epilogue
bytes, while others patch the RWTS to
look for specific non-standard epilogue
bytes.  Demuffin'd disks in the latter
category will grind almost immediately
on boot, since as soon as the RWTS is
loaded, all further disk reads will
demand the original (non-standard)
epilogue bytes and not find them.

Booting the demuffin'd disk confirms
that this disk is in the latter
category; it starts grinding almost
immediately.

I'm not terribly familiar with the
layout of Apple Pascal disks, but I do
know that RWTS code is almost always on
track 0. So I put my demuffin'd disk 1
into slot 6, drive 1, fired up my
trusty Copy ][+ sector editor, and
disassembled every sector in track 0
until I found it.

The relevant snippet (on T00,S0D) looks
like this:

                 --v--

SECTOR EDITOR                   DRIVE 1

0E2F-   BD 8C C0    LDA   $C08C,X
0E32-   10 FB       BPL   $0E2F
0E34-   25 26       AND   $26
0E36-   99 2C 00    STA   $002C,Y
0E39-   45 27       EOR   $27
0E3B-   88          DEY
0E3C-   10 E7       BPL   $0E25
0E3E-   A8          TAY
0E3F-   D0 B7       BNE   $0DF8
0E41-   BD 8C C0    LDA   $C08C,X
0E44-   10 FB       BPL   $0E41
0E46-   C9 DE       CMP   #$DE
0E48-   D0 AE       BNE   $0DF8
0E4A-   EA          NOP
0E4B-   BD 8C C0    LDA   $C08C,X
0E4E-   10 FB       BPL   $0E4B
0E50-   C9 DE       CMP   #$DE    <-- !
0E52-   D0 A4       BNE   $0DF8
0E54-   18          CLC
0E55-   60          RTS

                 --^--

(That second "CMP #$DE" should be $AA.)

T00,S0D,$51 change "DE" to "AA"

Now my copy of disk 1 boots for a
little while, but then it starts
grinding again, and eventually it asks
me to insert the boot disk with
SYSTEM.PASCAL on it.

There are *two* RWTS's on this disk.
Why build one when you can have two at
twice the price?

I don't even know where to start
looking for the second one. Or do I?
The entire disk uses the same non-
standard epilogue bytes ("DE DE"). If I
do a sector search for "C9 DE", maybe
I'll get lucky.

Mirabile dictu! There are three hits,
and all of them are part of the second
RWTS. The first two are looking for the
first epilogue byte (presumably one is
for the address epilogue and the other
for the data epilogue). That's supposed
to be $DE, so I won't change those. The
third match is the one I want. The
code listing is almost identical to the
one I found on T00,S0D, so I won't list
it here.


T09,S0A,$7B change "DE" to "AA"

Success! The program boots and runs
without complaint. There doesn't appear
to be any further copy protection
beyond the custom disk structure.

Now, what about the other three disks?
Each is bootable, which means it has
its own RWTS on track 0, and each is
independent, which means it has its own
Pascal SYSTEM files. Each disk was
authored with the same non-standard
epilogue bytes. But I think the second
RWTS is part of a file, because it's in
a different sector on each disk. A
sector search for "C9 DE" lets me zero
in on them.

Disk 2:

T00,S0D,$51 change "DE" to "AA"
T08,S0A,$7B change "DE" to "AA"

Disk 3:

T00,S0D,$51 change "DE" to "AA"
T0C,S08,$7B change "DE" to "AA"

Disk 4:

T00,S0D,$51 change "DE" to "AA"
T0C,S08,$7B change "DE" to "AA"

Quod erat liberandum.

---------------------------------------
A 4am crack                     No. 128
------------------EOF------------------