[no subject]

1C15-   C6 41       DEC   $41
1C17-   C6 43       DEC   $43
1C19-   D0 EE       BNE   $1C09
1C1B-   4C 8F 24    JMP   $248F

which then is:

248F-   4C 4D AA    JMP   $AA4D

Since this is converted, but not moved.

$AA4D is the entry point to fire up DOS and it takes over from there.  Ther=
e is a HELLO program on the disk, which contains a line to BRUN RAMLOADER, =
which is the other file present in the catalog.  RAMLOADER loads into $300,=
 and basically is a short routine to set up an I/O control block and call t=
he RWTS entry point to read from track $16 sector $00 into $200 and then of=
f it goes.  But aha, there=92s the address of the RWTS entry - $B6D5.  Bing=
o.

030F-   A9 03       LDA   #$03
0311-   A0 16       LDY   #$16
0313-   4C D5 B6    JMP   $B6D5

Now, the only remaining mystery is why won=92t tracks $13 and $14 sectors $=
E and $F read from regular DOS?  I could tell from a nibble dump that track=
 $13 had a data marker on a couple sectors of D5 AA D3, and track $14 had D=
5 AA DD.  But just changing a normal D5 AA AD to those still wouldn=92t rea=
d them.  Setting $B942:18 would, and at first glance it looks like the resu=
lting data is =91good=92 (these are the sectors where HELLO and RAMLOADER r=
eside, and can see the correct data for them).  But if these copies are use=
d, the program won=92t work.

Here=92s why (ignore the addresses, this is taken from a pre-relocated list=
ing and should be $Bxxx):

38AF-   BD 8C C0    LDA   $C08C,X
38B2-   10 FB       BPL   $38AF
38B4-   C9 EE       CMP   #$EE
38B6-   D0 E7       BNE   $389F
38B8-   49 AD       EOR   #$AD
38BA-   F0 0B       BEQ   $38C7
38BC-   D0 00       BNE   $38BE
38BE-   BC 8C C0    LDY   $C08C,X
38C1-   10 FB       BPL   $38BE
38C3-   B9 00 BB    LDA   $BB00,Y
38C6-   2C A9 00    BIT   $00A9
38C9-   A0 56       LDY   #$56
38CB-   88          DEY
38CC-   84 26       STY   $26
38CE-   BC 8C C0    LDY   $C08C,X
38D1-   10 FB       BPL   $38CE
38D3-   59 00 BB    EOR   $BB00,Y
38D6-   A4 26       LDY   $26
38D8-   99 00 BD    STA   $BD00,Y
38DB-   D0 EE       BNE   $38CB

This is what the code looks like before DOS has a chance to start up.  But =
when DOS starts, there=92s this bit of code in it:

AADD-   A9 C5       LDA   #$C5
AADF-   8D B4 B8    STA   $B8B4
AAE2-   A9 31       LDA   #$31
AAE4-   8D B5 B8    STA   $B8B5

This will result in:

B8AF-   BD 8C C0    LDA   $C08C,X
B8B2-   10 FB       BPL   $38AF
B8B4-   C5 31       CMP   $31
B8B6-   D0 E7       BNE   $389F

There=92s code elsewhere in the DOS that sets the values of #$D3 and #$DD i=
nto address $31 when those sectors are to be read.  But what=92s more inter=
esting is that when $31 is set to the normal #$AD, the EOR #$AD will result=
 in zero and the branch will be taken.  This skips over reading an extra ni=
bble! (which is then used to lookup in the read translate table).  When $31=
 is set to #$D3 or #$DD, this extra read is not skipped, and those sectors =
then read correctly.  When read with the $B941:18 setting (and those marker=
s), the bytes are decoded OK, but are off by an extra byte, causing the cod=
e to fail. Neato.

So, to overcome this and capture those four sectors correctly, Advanced Dem=
uffin is called in.  Since the DOS is already captured (just run the routin=
e at $1B03 and stop the jump to $AA4D; it=92s already left sitting at $1D00=
-$3FFF, just boot a slave disk and save it out) and the RWTS entry is conve=
niently known, the only =91trick=92 getting Advanced Demuffin to work is to=
 tweak the IOB a bit to set up $31 with a #$D3 or #$DD as needed (and use t=
he DOS after the mod to $B8B4 has been made to compare to $31).

Then to get the DOS to no longer mess with the extra byte and the changing =
marker, I opted to simply tweak the code to store C9 AD at $B8B4 instead of=
 C5 31, thus bypassing the concern completely (the rest of DOS will still c=
onditionally set $31 to the #$D3/#$DD/#$AD values, but it no longer will ma=
tter).

That=92s pretty much it.  DOS is captured, and the rest of the data is conv=
erted.  The only remaining task is to put DOS back onto tracks $00-$02 and =
create a loader to get it into the correct location, and then jump to $AA4D=
 to let the program continue as if nothing were different.  Rather than doi=
ng anything particularly fancy, I opted to squeeze a simple loader complete=
ly into track 0, sector 0 (and even then, only half of it).  I let the ROM =
routine load all of track $00, and then just used the now-loaded RWTS to lo=
ad the rest of it before jumping to $AA4D.  And I had just enough bytes lef=
t to put a one-liner note on boot, so as to distinguish from other versions=
.

So lots of interesting bits in this one, and it was a good opportunity to r=
e-learn some of this stuff after 25 years away from it.

]HR