Steve Nickolas

Here's the disk image I'm using:
http://www.brutaldeluxe.fr/crack/DONKEYKONG.DSK

On this image, the track usage map appears to be:

00000000000000001111111111111111222
0123456789ABCDEF0123456789ABCDEF012
# ########################

(i.e., tracks $00 and $05-1C, 25 tracks total, contain data.)

The title screen shown during load appears to be on part of tracks $0B,
$0C and $0D, where it's upside-down and oddly interleaved but present.
This screen can be taken out - it'll never be seen in a file crack anyway.

All the fullscreen images are inverted and weirdly interleaved, and
there's 5 more:

15/16 (0F/10) = main title
18/19 (12/13) = level 1 (barrels)
21/22 (15/16) = level 2 (girders)
24/25 (18/19) = level 3 (platforms)
27/28 (1B/1C) = level 4 (pie factory)

(note that this isn't the original level ordering but all US releases are
this way. on the Japanese arcade version you ALWAYS play barrels, pie
factory, platforms, girders.)

OK, so there's 6 screens of 8K each - 48K just for graphics - out of a
total of 100K. That's 52K of everything else... including sprites.
Ouchamagoucha. Maybe there's other redundancies?

-uso.

Antoine Vignau

On 2 jan, 23:25, Steve Nickolas <lyricalnan...@usotsuki.hoshinet.org>
wrote:
> Here's the disk image I'm using:http://www.brutaldeluxe.fr/crack/DONKEYKONG.DSK
>
> On this image, the track usage map appears to be:
>
> 00000000000000001111111111111111222
> 0123456789ABCDEF0123456789ABCDEF012
> # * *########################
>
> (i.e., tracks $00 and $05-1C, 25 tracks total, contain data.)
>
> The title screen shown during load appears to be on part of tracks $0B,
> $0C and $0D, where it's upside-down and oddly interleaved but present.
> This screen can be taken out - it'll never be seen in a file crack anyway..
>
> All the fullscreen images are inverted and weirdly interleaved, and
> there's 5 more:
>
> 15/16 (0F/10) = main title
> 18/19 (12/13) = level 1 (barrels)
> 21/22 (15/16) = level 2 (girders)
> 24/25 (18/19) = level 3 (platforms)
> 27/28 (1B/1C) = level 4 (pie factory)
>
> (note that this isn't the original level ordering but all US releases are
> this way. *on the Japanese arcade version you ALWAYS play barrels, pie
> factory, platforms, girders.)
>
> OK, so there's 6 screens of 8K each - 48K just for graphics - out of a
> total of 100K. *That's 52K of everything else... including sprites.
> Ouchamagoucha. *Maybe there's other redundancies?
>
> -uso.

AArrrrrgggghhhh, you want to remove the title screen, nnnoooooooooooo
rreeesssspppeeeecccctttt (ah ah)

Steve Nickolas

On Mon, 2 Jan 2012, Antoine Vignau wrote:

> On 2 jan, 23:25, Steve Nickolas <lyricalnan...@usotsuki.hoshinet.org>
> wrote:
>> Here's the disk image I'm using:http://www.brutaldeluxe.fr/crack/DONKEYKONG.DSK
>>
>> On this image, the track usage map appears to be:
>>
>> 00000000000000001111111111111111222
>> 0123456789ABCDEF0123456789ABCDEF012
>> # * *########################
>>
>> (i.e., tracks $00 and $05-1C, 25 tracks total, contain data.)
>>
>> The title screen shown during load appears to be on part of tracks $0B,
>> $0C and $0D, where it's upside-down and oddly interleaved but present.
>> This screen can be taken out - it'll never be seen in a file crack anyway.
>>
>> All the fullscreen images are inverted and weirdly interleaved, and
>> there's 5 more:
>>
>> 15/16 (0F/10) = main title
>> 18/19 (12/13) = level 1 (barrels)
>> 21/22 (15/16) = level 2 (girders)
>> 24/25 (18/19) = level 3 (platforms)
>> 27/28 (1B/1C) = level 4 (pie factory)
>>
>> (note that this isn't the original level ordering but all US releases are
>> this way. *on the Japanese arcade version you ALWAYS play barrels, pie
>> factory, platforms, girders.)
>>
>> OK, so there's 6 screens of 8K each - 48K just for graphics - out of a
>> total of 100K. *That's 52K of everything else... including sprites.
>> Ouchamagoucha. *Maybe there's other redundancies?
>>
>> -uso.
>
> AArrrrrgggghhhh, you want to remove the title screen, nnnoooooooooooo
> rreeesssspppeeeecccctttt (ah ah)
>

The only difference between the title screen and the main menu is the
Mario replaced by the select options. The copyright's still there. >:P

If not possible to crack to a single file, it MAY still be possible...to
crack to *ProDOS*, which only uses a little over 256 bytes of lower-48
memory, and which would be arguably more useful than the old DOS 3.3 type
cracks of yore.

-uso.

Antoine Vignau

Level pictures reside at $7F83 (routine at $6BDB, loaded from $2000 to
$3FFF, sector-- and track--)
- $13 and $12
- $16 and $15
- $19 and $18
- $1C and $1B

Probably level and sprite data reside at $7F87 (routine at $6C28,
loaded from $A700 to $B6FF, sector--)
- $11
- $14
- $17
- $1A

You have 12 tracks of 4 KiB each = 48 KiB.
Then add the program + its data.

You need to pack it with efficiency,
Antoine

Steve Nickolas

When partly loaded, I dumped a postmortem. Looks like B600-BFFF is a
normal RWTS? Would it be hard to just gut this code and have it use a
ProDOS-8 disk file instead, say "DKONG.OVL", and read from that as if it
were a disk image?

-uso.

Steve Nickolas

Replying further to myself:

On Tue, 3 Jan 2012, Steve Nickolas wrote:

> When partly loaded, I dumped a postmortem. Looks like B600-BFFF is a normal
> RWTS? Would it be hard to just gut this code and have it use a ProDOS-8 disk
> file instead, say "DKONG.OVL", and read from that as if it were a disk image?
>
> -uso.
>

On the crack, the first 10 sectors of the disk correspond to the top 10
pages of RAM (B600 and up). Calls into this space from outside seem to
always vector through B7B5, "Disable interrupts and call RWTS". The
"postmortem" is a memory image taken during the pause while the title
screen is displayed (with Mario jumping the barrel). In all 3 cases I
saw, AY was set to B7E8. There seem to be only these 3 cases outside of
the RWTS image itself anywhere in the disk image.

I would have to investigate somewhat deeper to determine how it figures
what sectors to load, and write a sort of "RWTS Emulator" to patch in,
which would become part of DKONG.SYSTEM. The remainder of the disk image
consisting of the part used by the non-RWTS portion would be a single
file, so all in all there would be 3 files on the disk - PRODOS,
DKONG.SYSTEM and DKONG.DATA. (There is plenty enough room on a 5.25" disk
for this.)

The two files DKONG.SYSTEM and DKONG.DATA could be placed on any type of
ProDOS-compatible device and run from anywhere.

I may also consider vectoring Ctrl-Reset into a block of code containing a
ProDOS BYE call, so that a two-finger salute would exit to whatever
program selector was active, e.g., GS/OS or whatall, and perhaps have the
run code detect the IIgs and clock it down to 1 MHz.

-uso.

Steve Nickolas

Replying to myself because LOL STATUS.

I am understanding the program as 3 phases:

1. Bootstrap phase 1 - that loads the core routines off disk.
2. Bootstrap phase 2 - that contains the RWTS and gets the rest of the
program going.
3. Everything else - which uses the code loaded in phase 2 to swap itself
in and out of memory as needed.

Phases 1 and 2 are track 0 (phase 1 is the boot sector), and will
correspond to DKONG.SYSTEM in the final version - a relocator to move the
phase 2 code up to B600-BAFF, (BB00-BEFF will be the buffer ProDOS uses
during file reads) and an emulation of the phase 2 code. Phase 3 is the
bulk of the disk image stored in a file called DKONG.DATA.

The key is, I guess, to make sure the bootstrap is emulated - to minimize
the amount of patches necessary to DKONG.DATA - and to make sure the
resulting files are viable. I guess right now I need to do a boot trace,
which is something I am really not very well-versed in...lol

-uso.

Antoine Vignau

On 3 jan, 05:36, Steve Nickolas <lyricalnan...@usotsuki.hoshinet.org>
wrote:
> Replying to myself because LOL STATUS.
>
> I am understanding the program as 3 phases:
>
> 1. Bootstrap phase 1 - that loads the core routines off disk.
> 2. Bootstrap phase 2 - that contains the RWTS and gets the rest of the
> program going.
> 3. Everything else - which uses the code loaded in phase 2 to swap itself
> in and out of memory as needed.
>
> Phases 1 and 2 are track 0 (phase 1 is the boot sector), and will
> correspond to DKONG.SYSTEM in the final version - a relocator to move the
> phase 2 code up to B600-BAFF, (BB00-BEFF will be the buffer ProDOS uses
> during file reads) and an emulation of the phase 2 code. *Phase 3 is the
> bulk of the disk image stored in a file called DKONG.DATA.
>
> The key is, I guess, to make sure the bootstrap is emulated - to minimize
> the amount of patches necessary to DKONG.DATA - and to make sure the
> resulting files are viable. *I guess right now I need to do a boot trace,
> which is something I am really not very well-versed in...lol
>
> -uso.

I'd rather set the memory usage as the following:
- $B700..B7FF: the original RWTS code and IOB
- $B800..$BBFF: the 1 KiB ProDOS file buffer
- $BC00..$BCFF: if necessary, 256 bytes for disk<->RAM manipulation
- $BD00..$BEFF: a rewritten RWTS entry point (handles all RWTS
functions: read/write/format)
- $BF00..$BFFF: the ProDOS MLI buffer

$B7B5 should not be considered as the official RWTS entry point but
the one used to load DOS 3.3. The official entry point if $BD00, set
by DOS 3.3 in a vector in page 3 (can't recall right now).

It would be safer to keep the $B700 page as it contains useful data
(first stage of DOS 3.3 load and a IOB) and the $BD00..$BEFF pages for
a rewritten RWTS entry point.

Your first system file may, first set the ProDOS prefix, then load a
text file divided into two parts:
DISPLAY NAME OF THE DOS 3.3 PROGRAM 1,PRODOSNAME1
DISPLAY NAME OF THE DOS 3.3 PROGRAM 2,PRODOSNAME2
Load that list, display it on the screen, let the user select the
program s/he would like to launch.
Upon selection, move the PRODOSNAMEx to $BEF0..$BEFF and use it for
file operations.
Open the file, read page 1, move it to $B700..$B7FF and execute (pass
X=#$60 as an argument)

Your rewritten RWTS entry point should handle read/write/format
(forget about format now). For each sector to load/save, move the
marker in the file. What is great is that it is easy to compute the
track/sector (following info in hex values) into a file position (it
is a three-byte info):
T0/S0 = FP $000000
T1/S0 = FP $001000
T1/S8 = FP $001800
T8/S9 = FP $008900
T10/S5 = FP $015000
T22/S0 = FP $022000
I let you write the TS to file position routine

Eh, that's fun!

Steve Nickolas

On Mon, 2 Jan 2012, Antoine Vignau wrote:

> I'd rather set the memory usage as the following:
> - $B700..B7FF: the original RWTS code and IOB
> - $B800..$BBFF: the 1 KiB ProDOS file buffer
> - $BC00..$BCFF: if necessary, 256 bytes for disk<->RAM manipulation
> - $BD00..$BEFF: a rewritten RWTS entry point (handles all RWTS
> functions: read/write/format)
> - $BF00..$BFFF: the ProDOS MLI buffer

That's kind-of overkill, not? I'm not talking about a general-purpose
method, just one that will work for this specific program. xD

> $B7B5 should not be considered as the official RWTS entry point but
> the one used to load DOS 3.3. The official entry point if $BD00, set
> by DOS 3.3 in a vector in page 3 (can't recall right now).

Well, yeah. But B7B5 was the entry point I detected being used in the
code, so that's where I focused.

-uso.