----------The Writing Workshop---------
A 4am crack                  2015-04-23
---------------------------------------

Name: The Writing Workshop
Genre: productivity
Year: 1985
Authors: John A. Oberschelp
Publisher: Milliken Publishing Company
Media: 12 single-sided 5.25-inch discs
OS: Diversi-DOS (T02,S02 has the string
  "C1982 DSR" in reverse)
Other versions: none (preserved here
  for the first time)
Similar cracks: Tangrams Puzzler, also
  by Milliken (4am crack no. 139)

I have 12 disks. They are not numbered.
Five explicitly state on the disk label
that they are "copyable for classroom
use." None of those five are bootable
(beyond a message saying they are a
data disk of some sort). On the bright
side, I successfully copied each of
them with COPYA.

  - File Cabinet Diskette 1
  - File Cabinet Diskette 2
  - Help Files
  - Mechanics Checker II (Word List)
  - Spelling Checker II (Word List)

The other seven disks are bootable and,
I'm assuming, copy-protected:

  - The Milliken Word Processor
  - Brainstorming
  - Branching
  - Nutshelling
  - Mechanics Checker I (Driver)
  - Spelling Checker I (Driver)
  - Proofreader

Each disk appears to be independent of
the others. To use a different part of
the program, you are expected to reboot
with the appropriate disk.

I'll start with "The Milliken Word
Processor."

                   ~

               Chapter 0
 In Which Various Automated Tools Fail
          In Interesting Ways


COPYA
  immediate read error

Locksmith Fast Disk Backup
  can't read any track

EDD 4 bit copy (no sync, no count)
  no read errors, but copy boots DOS
  then puts a "." in the top-left
  corner of the screen and reboots

Copy ][+ nibble editor
  modified address and data epilogue
  bytes ("DF AA EB") on every track

Disk Fixer
  ["O" -> "Input/Output Control"]
    set Address Epilogue to "DF AA EB"
    set Data Epilogue to "DF AA EB"
  Success! All tracks readable!
  ...except T02,S05
  ...identical error on all disks, so
    probably intentional
  T00 -> looks like a DOS 3.3 RWTS
  T11 -> DOS 3.3 disk catalog
  T01,S09 -> startup program is "BOOT"

Why didn't COPYA work?
  modified epilogue bytes (every track)

Why didn't Locksmith FDB work?
  modified epilogue bytes (every track)

Why didn't my EDD copy work?
  probably a nibble check during boot

Next steps:

  1. capture RWTS with AUTOTRACE
  2. convert disk to standard format
     with Advanced Demuffin
  3. find nibble check and bypass it

                   ~

               Chapter 1
In Which We Attempt To Use The Original
    Disk As A Weapon Against Itself


[S6,D1=original disk]
[S6,D2=blank 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

]BRUN ADVANCED DEMUFFIN 1.5

["5" to switch to slot 5]

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

["6" to switch to slot 6]

["C" to convert disk]

                 --v--

ADVANCED DEMUFFIN 1.5    (C) 1983, 2014
ORIGINAL BY THE STACK    UPDATES BY 4AM
=======PRESS ANY KEY TO CONTINUE=======
TRK:..R................................
+.5:
    0123456789ABCDEF0123456789ABCDEF012
SC0:...................................
SC1:...................................
SC2:...................................
SC3:...................................
SC4:...................................
SC5:..R................................
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 one read error
on track $02, but the rest of the disk
copied without a hitch. The original
disk gives no indication of a bad
sector, so either this sector is unused
(and I got lucky) or this is part of
the copy protection.

Let's see if I can launch the program
from my work disk.

]PR#5
...

]CATALOG,S6,D2

C1983 DSR^C#254
169 FREE

ERROR #8 I/O ERR


Wait, what?

                   ~

               Chapter 2
   Hide Your Disk Catalog With This
  One Weird Trick! Crackers Hate It!


The demuffin'd copy ought to have a
catalog (I saw it on the original disk
with Disk Fixer), but now it has
suspiciously vanished.

Turning again to my trusty Disk Fixer
sector editor, I see the problem. Track
$11 does have a catalog, but the
pointer to the first directory sector
has been intentionally corrupted.

                 --v--

-------------- DISK EDIT --------------
TRACK $11/SECTOR $00/VOLUME $FE/BYTE$00
---------------------------------------
$00:>00<F1 0F 03 00 00 FE 00   @qOC@@~@
$08: 00 00 00 00 00 00 00 00   @@@@@@@@
$10: 00 00 00 00 00 00 00 00   @@@@@@@@
$18: 00 00 00 00 00 00 00 00   @@@@@@@@
$20: 00 00 00 00 00 00 00 7A   @@@@@@@:
$28: 00 00 00 00 00 00 00 00   @@@@@@@@
$30: 05 FF 00 00 23 10 00 01   E.@@#P@A
$38: 00 00 00 00 00 00 00 00   @@@@@@@@
$40: 00 00 00 00 FF FF 00 00   @@@@..@@
$48: FF FF 00 00 3F FF 00 00   ..@@?.@@
$50: 00 00 00 00 00 00 00 00   @@@@@@@@
$58: 00 00 00 00 00 00 00 00   @@@@@@@@
$60: FF FF 00 00 FF FF 00 00   ..@@..@@
$68: FF FF 00 00 FF FF 00 00   ..@@..@@
$70: FF FF 00 00 03 FF 00 00   ..@@C.@@
$78: 00 00 00 00 00 00 00 00   @@@@@@@@
---------------------------------------
BUFFER 0/SLOT 6/DRIVE 1/MASK OFF/NORMAL

---------------------------------------
COMMAND :

                 --^--

Third-party utilities can not catalog
this disk or work with any of its files
(every DOS file function routes through
this pointer), but the original disk
obviously has no problem. But how does
the original disk know? I scoured
"Beneath Apple DOS" until I found the
answer on page 8-28:

                 --v--

B011-B036 Read a directory sector
; (If CARRY flag is zero on entry, read
  first directory sector. If CARRY is
  one, read next)
; Memorize entry code.
; Set buffer pointers (B045).
; First or next?
; If first, get track/sector of
  directory sector from VTOC at offset
  +1,+2.
; Otherwise, get track/sector from
  directory sector at offset +1,+2. If
  track is zero, exit with error code
  (end of directory).
; Call RWTS to read sector.
; Exit with normal return code.

                 --^--

So, to read the first sector of file
names and other metadata, this routine
is supposed to look at the VTOC sector
buffer (read from T11,S00 and stored at
$B3BB..$B4BA). The VTOC says "hey, the
first sector of files and stuff is in
TF1,S0F" so DOS goes and tries to read
track $F1, sector $0F, which obviously
won't work.

But the DOS on this disk made one small
modification to that routine. (This is
stored on T01,S0F.)

B011-   08          PHP
B012-   20 45 B0    JSR   $B045
B015-   28          PLP
B016-   B0 08       BCS   $B020
B018-   AC BD B3    LDY   $B3BD
                                ------
B01B-   A2 11       LDX   #$11  << hey
B01D-   EA          NOP         << now
                                ------
B01E-   D0 0A       BNE   $B02A
B020-   AE BC B4    LDX   $B4BC
B023-   D0 02       BNE   $B027
B025-   38          SEC
B026-   60          RTS
B027-   AC BD B4    LDY   $B4BD
B02A-   8E 97 B3    STX   $B397
B02D-   8C 98 B3    STY   $B398
B030-   A9 01       LDA   #$01
B032-   20 52 B0    JSR   $B052
B035-   18          CLC
B036-   60          RTS

Instead of getting the track number
from the VTOC, it hard-codes track $11.

Now that I've identified the problem,
the fix is straightforward. If I change
the VTOC header (T11,S00) to point to
the actual first directory sector
(T11,S0F), DOS 3.3 or any other copy
utility should be able to read the
entire catalog. This disk doesn't care
either way, since it never looks at it.

T11,S00,$01 change "F1" to "11"

Now I should be able to catalog it from
my work disk.

]PR#5
...

]CATALOG,S6,D2

C1983 DSR^C#254
169 FREE

 B 058 M
 B 059 M2
*A 004 BOOT
*B 011 ANIMS
*B 012 ASCII
*B 012 ASCII80
*B 002 EMPTY
*B 004 C
*B 004 D
*B 002 FASTMOVE
*B 033 TITLE
*B 012 ASCII1
*B 012 ASCII2
*B 012 ASCII3
*B 012 ASCII4
*B 012 ASCII5
*B 012 ASCII6
*B 033 TITLE80

]RUN BOOT
...works...

[S6,D1=copy]

]PR#6
...grinds...

My copy just grinds on boot, which
tells me that the RWTS is looking for
specific (non-standard) epilogue bytes
and failing to find them. So I need to
patch the RWTS to standardize the
epilogue bytes.

For future reference (mostly mine),
here's a nice chart of the memory
locations for all the prologues and
epilogues in a DOS 3.3-shaped RWTS. If
the RWTS stores $B700 in T00,S01 (most
do), then $B8xx will be in T00,S02;
$B9xx in T00,S03; and so on.


                0x |  read | write
    ---------------+-------+-------
                D5 | $B955 | $BC7A
      prologue  AA | $B95F | $BC7F
     /          96 | $B96A | $BC84
    ADDRESS -------+-------+-------
     \          DE | $B991 | $BCAE
      epilogue  AA | $B99B | $BCB3
                EB |       | $BCB8
    ---------------+-------+-------
                D5 | $B8E7 | $B853
      prologue  AA | $B8F1 | $B858
     /          AD | $B8FC | $B85D
    DATA ----------+-------+-------
     \          DE | $B935 | $B89E
      epilogue  AA | $B93F | $B8A3
                EB |       | $B8A8
    ---------------+-------+-------


I spent way too much time making that.

Here are the patches to normalize the
RWTS.

T00,S02,$9E change "DF" to "DE"
T00,S03,$35 change "DF" to "DE"
T00,S03,$91 change "DF" to "DE"
T00,S06,$AE change "DF" to "DE"

]PR#6

                 --v--

      ATTENTION!

THE DISK DRIVE YOU ARE USING IS
OPERATING AT AN UNSAFE SPEED.

OPERATION OF THIS PROGRAM ON THIS DRIVE
MAY DESTROY THE PROGRAM.

PLEASE HAVE YOUR DRIVE SPEED CHECKED,
OR USE ANOTHER DISK DRIVE.

                 --^--

I am not making this up.

                   ~

               Chapter 3
    In Which We Walk The Fine Line
   Between Bullshit and Misdirection


I should note at this point that my
copy is actually a disk image being
managed by a CFFA3000 card. I sector-
copied the disk image back to a
physical floppy and booted it, and it
displayed the behavior I was expecting
(load DOS, print ".", then reboot --
just like my failed bit copy). Then I
copied the disk image to a modern PC
and ran it in two different emulators;
each time, it gave me the message about
the drive operating at an unsafe speed.

I'm about to give up on this DOS and
just blow it away and replace it with a
fresh copy of DOS 3.3. I've already
confirmed that the program itself loads
when I boot from my work disk. But now
I want to know whether this DOS is
really checking the drive speed, or if
that's just bullshit and misdirection.

So here we go.

]PR#5
...

]BLOAD BOOT0
]CALL -151

*801L
.
. nothing unusual
.

*BLOAD BOOT1

*FE89G FE93G     ; disconnect DOS

*B600<2600.2FFFM ; move RWTS into place

*B700L
.
. nothing unusual, until
.
B747-   4C 03 9B    JMP   $9B03

This usually jumps to $9D84, the DOS
cold start vector. I don't know what's
at $9B03 yet, but I can find out.

*C500G    ; because I overwrote DOS
...

]CALL -151

*9600<C600.C6FFM

; set up first callback
96F8-   A9 4C       LDA   #$4C
96FA-   8D 4A 08    STA   $084A
96FD-   A9 0A       LDA   #$0A
96FF-   8D 4B 08    STA   $084B
9702-   A9 97       LDA   #$97
9704-   8D 4C 08    STA   $084C

; start the boot
9707-   4C 01 08    JMP   $0801

; first callback is here -- set up
; second callback
970A-   A9 17       LDA   #$17
970C-   8D 48 B7    STA   $B748
970F-   A9 97       LDA   #$97
9711-   8D 49 B7    STA   $B749

; continue the boot
9714-   4C 00 B7    JMP   $B700

; second callback is here -- copy all
; of DOS to lower memory so it will
; survive a reboot
9717-   A2 25       LDX   #$25
9719-   A0 00       LDY   #$00
971B-   B9 00 9B    LDA   $9B00,Y
971E-   99 00 2B    STA   $2B00,Y
9721-   C8          INY
9722-   D0 F7       BNE   $971B
9724-   EE 1D 97    INC   $971D
9727-   EE 20 97    INC   $9720
972A-   CA          DEX
972B-   D0 EE       BNE   $971B

; reboot to my work disk
972D-   4C 00 C5    JMP   $C500

*BSAVE TRACE2,A$9600,L$130

*9600G
...reboots slot 6...
...reboots slot 5...

]BSAVE BOOT2,A$2B00,L$2500
]CALL -151

*FE89G FE93G

*9B00<2B00.4FFFM

*9B03L

; well that explains the "." in the
; top-left corner of the screen
9B03-   A9 AE       LDA   #$AE
9B05-   8D 00 04    STA   $0400

; turn on drive motor (always suspect)
9B08-   AE F8 05    LDX   $05F8
9B0B-   BD 89 C0    LDA   $C089,X

; this is a wait loop
9B0E-   A9 0A       LDA   #$0A
9B10-   20 37 9B    JSR   $9B37

9B13-   A9 05       LDA   #$05
9B15-   85 03       STA   $03
9B17-   20 4B 9B    JSR   $9B4B

*9B4BL

; find next address prologue
9B4B-   AE F8 05    LDX   $05F8
9B4E-   BD 8C C0    LDA   $C08C,X
9B51-   10 FB       BPL   $9B4E
9B53-   C9 D5       CMP   #$D5
9B55-   D0 F7       BNE   $9B4E
9B57-   BD 8C C0    LDA   $C08C,X
9B5A-   10 FB       BPL   $9B57
9B5C-   C9 AA       CMP   #$AA
9B5E-   D0 F3       BNE   $9B53
9B60-   BD 8C C0    LDA   $C08C,X
9B63-   10 FB       BPL   $9B60
9B65-   C9 96       CMP   #$96
9B67-   D0 EA       BNE   $9B53
9B69-   A0 00       LDY   #$00

; capture address field in $0200..$0205
9B6B-   BD 8C C0    LDA   $C08C,X
9B6E-   10 FB       BPL   $9B6B
9B70-   99 00 02    STA   $0200,Y
9B73-   C8          INY
9B74-   C0 06       CPY   #$06
9B76-   90 F3       BCC   $9B6B

; do some bit math on the sector number
; (result is in accumulator on exit)
9B78-   AD 02 02    LDA   $0202
9B7B-   38          SEC
9B7C-   2A          ROL
9B7D-   2D 03 02    AND   $0203
9B80-   85 06       STA   $06
9B82-   AD 04 02    LDA   $0204
9B85-   2A          ROL
9B86-   2D 05 02    AND   $0205
9B89-   60          RTS

Backtracking to $9B1A...

*9B1AL

; store the result of the suspicious
; bit math
9B1A-   85 01       STA   $01

; another wait loop
9B1C-   A2 A8       LDX   #$A8
9B1E-   A9 07       LDA   #$07
9B20-   20 37 9B    JSR   $9B37

; another call to the subroutine that
; looks for an address field
9B23-   20 4B 9B    JSR   $9B4B

; compare the two results and branch to
; $9B34 if they're different
9B26-   85 02       STA   $02
9B28-   C5 01       CMP   $01
9B2A-   D0 08       BNE   $9B34

; do this whole thing several times
9B2C-   C6 03       DEC   $03
9B2E-   D0 E7       BNE   $9B17
9B30-   EA          NOP

; success path is here
9B31-   4C A9 9B    JMP   $9BA9

; failure path is here
9B34-   4C 0C 9C    JMP   $9C0C

*9C0CL

; turn off drive motor
9C0C-   AE F8 05    LDX   $05F8
9C0F-   9D 88 C0    STA   $C088,X

; clear screen
9C12-   20 58 FC    JSR   $FC58

; this subroutine prints a zero-
; terminated string that follows, then
; resets the program counter to
; continue execution after the string
9C15-   20 8A 9B    JSR   $9B8A

9C18..9CEB is the ATTENTION message

; munge reset vector
9CEC-   A9 00       LDA   #$00
9CEE-   8D F4 03    STA   $03F4

; hang forever
9CF1-   4C F1 9C    JMP   $9CF1

That seems to be the path that my disk
image takes on both the CFFA 3000 card
and under emulation. It really is using
a timing loop and repeated sector reads
to check the drive speed. The fact that
it fails under emulation is a result of
imperfect emulation, not any malice on
the part of the author. He honestly
cares about my drive speed. He never
even gets as far as checking if my disk
is original.

If the drive speed check passes,
execution continues at $9BA9. This is
the actual copy protection.

*9BA9L

; position drive on track $02
9BA9-   A9 02       LDA   #$02
9BAB-   8D EC B7    STA   $B7EC

; don't actually read, just seek
9BAE-   A9 00       LDA   #$00
9BB0-   8D F4 B7    STA   $B7F4
9BB3-   A9 B7       LDA   #$B7
9BB5-   A0 E8       LDY   #$E8
9BB7-   20 00 BD    JSR   $BD00
9BBA-   B0 43       BCS   $9BFF

; look for address prologue
9BBC-   20 4B 9B    JSR   $9B4B

; if not T02,S05, try again
9BBF-   C9 05       CMP   #$05
9BC1-   D0 F9       BNE   $9BBC

Aha! Remember that one unreadable
sector on track $02? The one that even
the disk's own RWTS couldn't read? It
turns out that sector is part of the
copy protection.

; look for a custom prologue
9BC3-   A0 63       LDY   #$63
9BC5-   AE F8 05    LDX   $05F8
9BC8-   BD 8C C0    LDA   $C08C,X
9BCB-   10 FB       BPL   $9BC8
9BCD-   C9 D5       CMP   #$D5
9BCF-   D0 F7       BNE   $9BC8
9BD1-   BD 8C C0    LDA   $C08C,X
9BD4-   10 FB       BPL   $9BD1
9BD6-   C9 AA       CMP   #$AA
9BD8-   D0 F3       BNE   $9BCD
9BDA-   BD 8C C0    LDA   $C08C,X
9BDD-   10 FB       BPL   $9BDA
9BDF-   C9 AD       CMP   #$AD
9BE1-   D0 EA       BNE   $9BCD
9BE3-   BD 8C C0    LDA   $C08C,X
9BE6-   10 FB       BPL   $9BE3
9BE8-   C9 AD       CMP   #$AD
9BEA-   F0 F7       BEQ   $9BE3

; look for an unreasonable number of
; sync bytes (64) in a row
9BEC-   C9 FF       CMP   #$FF

; anything else just fails immediately
9BEE-   D0 0F       BNE   $9BFF
9BF0-   BD 8C C0    LDA   $C08C,X
9BF3-   10 FB       BPL   $9BF0
9BF5-   C9 FF       CMP   #$FF

; fail immediately
9BF7-   D0 06       BNE   $9BFF
9BF9-   88          DEY
9BFA-   D0 F4       BNE   $9BF0

; ultimate success path is here -- jump
; to the DOS cold start vector and
; continue the boot as normal
9BFC-   4C 84 9D    JMP   $9D84

; failure path is here -- calculate the
; boot slot and reboot
9BFF-   8A          TXA
9C00-   4A          LSR
9C01-   4A          LSR
9C02-   4A          LSR
9C03-   4A          LSR
9C04-   09 C0       ORA   #$C0
9C06-   8D 0B 9C    STA   $9C0B
9C09-   4C 00 C6    JMP   $C600

On further reflection, it occurs to me
that the drive speed check was added
because the copy protection was fragile
and failed if the disk speed was off
(even on original disks where it was
supposed to pass). So it's technically
accurate to say that the drive speed is
off, but it's still misdirection. (And
the part about destroying the program
is just bullshit; drives don't work
like that.) The program itself works
fine; all access is through standard
DOS 3.3 calls, and DOS is very tolerant
of minor drive variations. The only
thing that can't handle it is the copy
protection. But rather than fix that
(or, you know, give up on the idea of
copy protection altogether), they added
a layer of bullshit on top of it.

Anyway, there are no side effects to
this copy protection. If it succeeds,
it jumps to $9D84 as usual. That means
I can safely bypass the entire thing by
changing the JMP that started it all,
at $B747.

T00,S01,$48 change "03 9B" to "84 9D"

All seven protected disks use identical
protection. The RWTS I captured from
this disk also works to convert the
other six. They each have an unreadable
T02,S05; they each need their RWTS
patched to read standard epilogue
bytes; they each call $9B03 instead of
$9D84.

Quod erat liberand one more thing...

                   ~

               Chapter 4
  In Which All Copies Are Protected,
      But Some Are More Protected
              Than Others


Here's what worries me: these programs
deal with data disks (to store your own
documents or read the word list disks
or other disks labeled "copyable for
classroom use"). Those disks are
unprotected. Some disks deal with this
by using a flexible RWTS that can read
and write the standard and non-standard
RWTS. But this disk is not doing that.
Its RWTS is strict -- remember, I had
to patch it just to get it to boot far
enough to call its nibble check (which
failed, but we're past that now).

That means that something, somewhere,
is fiddling with the RWTS at runtime.

According to my handy dandy RWTS chart,
there are four memory addresses that
correspond to the four patches I made
on disk to get the RWTS to read a
standardized disk:

  $B89E (T00,S02,$9E)
  $B935 (T00,S03,$35)
  $B991 (T00,S03,$91)
  $BCAE (T00,S06,$AE)

Turning to my trusty Disk Fixer sector
editor, I searched for "35 B9" (one of
the RWTS epilogue bytes) and found two
matches. Both look like this:

T12,S0E
----------- DISASSEMBLY MODE ----------
000E:A9 DE          LDA   #$DE
0010:8D 9E B8       STA   $B89E
0013:8D 35 B9       STA   $B935
0016:8D 91 B9       STA   $B991
0019:8D AE BC       STA   $BCAE
001C:20 F2 52       JSR   $52F2
001F:2C 57 C0       BIT   $C057
0022:2C 50 C0       BIT   $C050
0025:2C 52 C0       BIT   $C052

That's "resetting" the RWTS to standard
values after the program is loaded into
memory, so it can read and write from
the data disk. That's OK; it's already
standard values on my copy, but setting
it again won't hurt anything. I found
similar code on each of the seven
protected disks. But on some of them, I
also found a different pattern:

T12,S0D ("Brainstorming" disk)
----------- DISASSEMBLY MODE ----------
00CB:A0 00          LDY   #$00
00CD:EE 9E B8       INC   $B89E   <-- !
00D0:EE 35 B9       INC   $B935   <-- !
00D3:EE 91 B9       INC   $B991   <-- !
00D6:EE AE BC       INC   $BCAE   <-- !
00D9:20 0C 40       JSR   $400C
00DC:CE 9E B8       DEC   $B89E   <-- !
00DF:CE 35 B9       DEC   $B935   <-- !
00E2:CE 91 B9       DEC   $B991   <-- !
00E5:CE AE BC       DEC   $BCAE   <-- !
00E8:A5 F1          LDA   $F1
00EA:D0 33          BNE   $011F

That's, um, bad. The INC instructions
change the epilogue bytes in memory
from the standard $DE to the non-
standard $DF. Then the DEC instructions
change them back.

Changing each INC and DEC instruction
to a "BIT" will neutralize the RWTS
fiddling.

"Brainstorming" disk
T12,S0D,$CD change "EE" to "2C"
T12,S0D,$D0 change "EE" to "2C"
T12,S0D,$D3 change "EE" to "2C"
T12,S0D,$D6 change "EE" to "2C"
T12,S0D,$DC change "CE" to "2C"
T12,S0D,$DF change "CE" to "2C"
T12,S0D,$E2 change "CE" to "2C"
T12,S0D,$E5 change "CE" to "2C"

There is similar INC/DEC logic on two
other disks.

"Branching" disk
T12,S07,$C9 change "EE" to "2C"
T12,S07,$CC change "EE" to "2C"
T12,S07,$CF change "EE" to "2C"
T12,S07,$D2 change "EE" to "2C"
T12,S07,$D8 change "CE" to "2C"
T12,S07,$DB change "CE" to "2C"
T12,S07,$DE change "CE" to "2C"
T12,S07,$E1 change "CE" to "2C"

"Nutshelling" disk
T0E,S06,$F8 change "EE" to "2C"
T0E,S06,$FB change "EE" to "2C"
T0E,S06,$FE change "EE" to "2C"
T0E,S05,$01 change "EE" to "2C"
T0E,S05,$07 change "CE" to "2C"
T0E,S05,$0A change "CE" to "2C"
T0E,S05,$0D change "CE" to "2C"
T0E,S05,$10 change "CE" to "2C"
T12,S08,$77 change "EE" to "2C"
T12,S08,$7A change "EE" to "2C"
T12,S08,$7D change "EE" to "2C"
T12,S08,$80 change "EE" to "2C"
T12,S08,$86 change "CE" to "2C"
T12,S08,$89 change "CE" to "2C"
T12,S08,$8C change "CE" to "2C"
T12,S08,$8F change "CE" to "2C"

All other disks appear to be "single
load." They load the program into
memory, standardize the RWTS in memory,
then work solely with data disks until
reboot.

Quod erat liberandum.

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