------Reading for Meaning: Level 2-----
A 4am crack                  2014-10-28
---------------------------------------

"Reading for Meaning: Level 2" is a
1985 educational program distributed by
Hartley Courseware, Inc. The title page
credits Vera Gierman as "content
author" and gives the version as
"03.11.86" (probably an American-style
date stamp, i.e. March 11, 1986).

The original disk is double-sided. Both
sides are bootable and appear to be
independent of one another.

COPYA fails miserably and immediately.
EDD 4 bit copy works, and the copy
boots and runs without complaint. This
tells me that there is some structural
protection (i.e. data is stored on the
disk in a non-standard way) but
probably no secondary protection
(e.g. an assembly language routine that
executes during the boot process to
determine whether it's booting from the
original disk).

The original disk appears to boot a
modified DOS 3.3. Listening to the disk
drive, it quickly moves out to track 2,
then back to track 1, then track 0,
then swings out to track $11 to read
the disk catalog and load the startup
program (HELLO or similar). You can
hear a lot just by listening.

Turning to my trusty Disk Fixer sector
editor, I go to "Input/Output Control"
(press "O") and set CHECKSUM ENABLED =
NO. 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",
respectively), 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. So no more COPYA+B942:18
patch. From now on, it's Super Demuffin
or Advanced Demuffin to convert disks
to a standard format. Let's see if
AUTOTRACE can capture the RWTS from the
original disk. If not, I'll have to
resort to manual investigation.

[S6,D1=original disk]
[S5,D1=my work disk]

]PR#5
...
CAPTURING BOOT0
...reboots slot 6...
...reboots slot 5...
SAVING BOOT0
CAPTURING BOOT1
...reboots slot 6...
...reboots slot 5...
SAVING BOOT1
SAVING RWTS

For those of you just tuning in, my
work disk uses a custom program that I
affectionately call "AUTOTRACE" to
automate the process of boot tracing as
far as possible. For some disks, this
just captures track 0, sector 0 (saved
in a file called "BOOT0") and stops.
For other disks that load in the same
way that an unprotected DOS 3.3 disk
loads, it captures the next stage of
the boot process as well (in a file
called "BOOT1"). BOOT1 contains sectors
0-9 on track 0, which are loaded into
memory at $B600..$BFFF. This generally
contains the RWTS routines which the
program uses to read the rest of the
disk.

If the RWTS is fairly normal as well
(and my AUTOTRACE program just spot-
checks a few memory locations to guess
at its "normalcy"), there's a good
chance I'll be able to use a tool
called Advanced Demuffin (written in
1983 by The Stack) to convert the disk
from whatever weird format it uses to
store its sector data into a standard
disk readable by unprotected DOS 3.3
disks or any other third-party tools.
In this case, AUTOTRACE extracts the
RWTS routines (generally loaded from
track 0, sectors 2-9 into $B800..$BFFF)
and saves *that* into a third file
called "RWTS".

If anything looks fishy or non-
standard, AUTOTRACE just stops, and I
have to check the files it saved so far
to determine why. But in this case, it
ran all the way through, automatically
capturing BOOT0, BOOT1, and RWTS files.
Now I use plug that RWTS file into
Advanced Demuffin and try to convert
the data on this disk to a standard
format.

[S6,D1=original disk (side A)]
[S6,D2=blank disk]
[S5,D1=my work disk]

]PR#5
...

]BRUN ADVANCED DEMUFFIN 1.5

[press "5" to switch to slot 5]

[press "R" to load a new RWTS module]
  --> At $B8, load "RWTS" from drive 1

[press "6" to switch to slot 6]

[press "C" to convert disk]

This disk is 16 sectors, and the
default options (copy the entire disk,
all tracks, all sectors) don't need to
be changed unless something goes
horribly wrong.

                 --v--

ADVANCED DEMUFFIN 1.5    (C) 1983, 2014
ORIGINAL BY THE STACK    UPDATES BY 4AM
=======PRESS ANY KEY TO CONTINUE=======
TRK:...................................
+.5:
    0123456789ABCDEF0123456789ABCDEF012
SC0:...................................
SC1:...................................
SC2:...................................
SC3:...................................
SC4:...................................
SC5:...................................
SC6:...................................
SC7:...................................
SC8:...................................
SC9:...................................
SCA:...................................
SCB:...................................
SCC:...................................
SCD:...................................
SCE:...................................
SCF:...................................
=======================================
16SC $00,$00-$22,$0F BY1.0 S6,D1->S6,D2

                 --^--

The disk's own RWTS gave no read errors
on any track. (I repeated the procedure
for side B. No errors on either side.)
This is the power and the genius of
Advanced Demuffin. Every disk must be
able to read itself. So, let it read
itself, then capture the data and write
it out in a standard format.

]PR#5
...
]CATALOG,S6,D2

C1983 DSR^C#001
031 FREE

*A 004 HELLO
*A 006 CREDITS
*A 042 MG
*A 032 CREATE LESSON
*A 020 STU PLAN
*A 011 PWL
*B 002 IR
*B 004 HRBX
*B 008 SMALL CHARS
*B 010 LARGE CHARS
*B 011 PICDRAW
*B 008 GOOSEW
*B 004 GARBAG
*B 003 SMILES
*T 019 STU.FILE
 T 025 SET L
 T 025 SET M
 T 026 SET N
 T 025 SET O
 T 022 SET P
 T 022 SET Q
 B 005 LAMB
 B 006 SLEEPING
 B 007 HEYDIDDLE
 B 004 HANDY
 B 005 NIMBLE
 B 003 HILL
 B 004 BOYBLUE
 B 004 OATS
 B 005 CROOKED
 B 004 SWIM
 B 004 SPIDER
 B 004 WINKIE
 B 005 LONDON
 B 004 RAIN
 B 003 PUSSY
 B 005 BIRD
 B 005 RHODY
 B 005 HUBBARD
 B 004 CONTRARY
 B 005 LOCKET
 B 003 ROW
 B 004 HUSH
 B 005 SHAFTOE
 B 005 BETTY
 B 006 TINKER
 B 004 HICKORY
 B 006 GEORGIE
 B 003 LOCK
 B 004 PEASE
 B 005 HUMPTY

]RUN HELLO

Success! The program loads and runs
without complaint. All further disk
access is done through standard DOS
functions. (It even runs from drive 2!)

While that's excellent progress, I'm
not quite done yet. Booting the
demuffin'd disk directly just grinds
endlessly, because it still has the
original RWTS on it. That is, it still
assumes that the data on the disk is
stored in a non-standard format. But
that's not true anymore, because
Advanced Demuffin just normalized the
disk format. So I need to patch the
RWTS on my copy so it can read itself.

A lot of disks need this sort of post-
demuffin patching, and I got tired of
doing it manually, so I wrote a program
to do it for me. It is called,
unsurprisingly, Post-Demuffin Patcher.
It prompts you to select a slot and
drive, then reads the demuffin'd disk,
checks for a modified DOS 3.3-shaped
RWTS, and applies the necessary patches
so the disk can read itself. (It can
also detect and bypass some nibble
checks.) I've included a copy of Post-
Demuffin Patcher on my work disk; the
full source code is currently available
at <https://archive.org/details/
PostDemuffinPatcher4am>.

[S6,D1=demuffin'd copy of side A]

]PR#5
...

]BRUN PDP

T00,S02,$9E change DA to DE
T00,S03,$35 change DA to DE
T00,S03,$91 change DA to DE

(This is the actual output of the
program. Post-Demuffin Patcher prints
out the changes it is going to make
before it writes them to the disk.)

]PR#6

Success! The disk boots and runs with
no complaint. (I ran PDP on side B and
it made identical modifications, and
now both sides boot and run.) There
doesn't appear to be any further
protection. Hooray for automation.

Except...

In the process of making disk images
out of these working floppies, I came
across another problem: both the
original disk and my working copies use
disk volume 001. (It actually said that
when I ran a CATALOG from my work disk,
but I didn't even notice it at the
time.) Why is this a problem? Well,
.dsk disk image files don't have any
way of storing the volume number. They
are purely a sector dump; that's just
the nature of the file format. The
volume number is stored in the address
field, but .dsk files don't store the
address field. Emulators assume that
every .dsk image uses disk volume 254.

OK, so if .dsk files don't store the
volume number, then why does it matter?
Well, besides appearing in every
sector's address field on a physical
floppy disk, the volume number is
stored in three different places when a
disk is initialized:

1. $B7EB (T00,S01,$EB), in the RWTS
   parameter table used by boot1 to
   load DOS from tracks 0-2 ["Beneath
   Apple DOS", p. 8-35]

2. $AA66 (T01,S09,$66), in the parsed
   keyword table used by DOS to load
   the startup program (and every other
   file loaded after that) [ibid.,
   p. 8-21]

3. $B3C1 (T11,S00,$06), in the VTOC
   header [ibid., p. 8-32]

My (non-working) disk images have a $01
in each of those locations. Using my
trusty Disk Fixer sector editor, I
changed each of them to $FE. (Again,
this patch is identical on both sides.)

T00,S01,$EB change 01 to FE
T01,S09,$66 change 01 to FE
T11,S00,$06 change 01 to FE

Success! The disk images boot and run.
There doesn't appear to be any further
copy protection.

(Note to self: add this to a future
version of Post-Demuffin Patcher.)

Quod erat liberandum.

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