[Andlabs]

Here's an edit of the introductory level, right before and immediately after you meet Espio. This is just a random hex edit, so don't expect much =P




BE SURE YOU ARE AT THIS SPOT, OTHERWISE KNUCKLES AND ESPIO WILL NEVER "MEET" AND THE GAME WILL TRY FOREVER.



So yeah, I might be looking further into this later.

(EDIT - I switched to doing asm research. Man we need a RESEARCH thread icon.)

This post has been edited by Andlabs: 01 February 2010 - 04:48 PM

[Thorn]

Oh, I've certainly noticed. I've been checking Recent Changes on the Wiki every hour or so to see what you've done; I'm a bit of a Chaotix nut and the prospect of level design or getting a level rip for Sonic 2 (I know that the level palette uses up more colors, though, so it'd be hard) has my attention. I spent some time yesterday trying to get the data read by SonED2 by uncompressing it and recompressing it the way used in Sonic 2, but had no luck. Anyway, please have my babies, <3, etc.

Actually, while there's a topic on it, lemme ask a question on Chaotix that maybe somebody knows the answer to... there's a bit of a lead-in to this one, but it's been bugging me for years, so I might as well ask. I remember looking around a few years ago and noticing the code "FFADC1:05 | Enable Grow (Leader) (Only works if Always Have Shield is enabled)" (now available on the Wiki). Cut to a few years later, and I gain a greater understanding of the innards of classic Sonic. I understood that there's actually a word at $FFADC0 that says how many frames are left on either a Grow or Shrink item, and that the "Always Have Shield" requirement is a lie... rather, it only triggers on specific levels like World Entrance 2 (Final Boss). I then found that the code for other levels is always on some offset of $40 away from that code, e.g. $FFAE00 is that word's location in Botanic Base 1 Morning. I spent some time compiling a list of where that code moves to for different levels and times of day -- I think I found something like six codes, all multiples of $40 apart, that worked for every level and time of day. The list has been lost to time, unfortunately, but I could always recreate it.

I'm sure that the effects of the values in RAM after this word move around between levels too, probably as a group of $40 bytes, so that list might have detailed the movements of a large chunk of RAM. Question is, why does it move in there first place, and is there some sort of logic behind where it moves to? Is this due to the game, or is it just a quirk with 32X hardware or 32X PAR codes? $40 was also the size of an SST in Sonic 2, which also held values for power-up time left: is this related? Or is this all nothing and I'm totally overthinking it?

This post has been edited by Thorn: 29 January 2010 - 12:15 PM

[Andlabs]

Ha, thanks. And this information proves useful. I keep coming across a function that handles up to $40 blocks of data $40 bytes in side, starting at $FFAD08. However, 8 allocated zones * 7 allocated acts * 4 allocated times of day == $E0 supported blocks, so I may be wrong.

In any case, one could assume the real offset for enable grow is $39(aN). The following code looks relevant:

CODE

ROM:0088418C; ---------------------------------------------------------------------------
ROM:0088418C
ROM:0088418C loc_88418C:                ; CODE XREF: sub_883B32+644j
ROM:0088418C                 tst.w   $26(a6)
ROM:00884190                 bne.w   loc_884074
ROM:00884194                 moveq   #0,d0
ROM:00884196                 subq.b  #1,$39(a6)
ROM:0088419A                 bne.s   loc_8841C0
ROM:0088419C                 move.b  $38(a6),d0
ROM:008841A0                 addq.b  #4,d0
ROM:008841A2                 cmpi.b  #$20,d0; ' '
ROM:008841A6                 bcs.s   loc_8841AA
ROM:008841A8                 moveq   #0,d0
ROM:008841AA
ROM:008841AA loc_8841AA:                ; CODE XREF: sub_883B32+674j
ROM:008841AA                 move.b  d0,$38(a6)
ROM:008841AE                 move.b  #3,$39(a6)
ROM:008841B4                 move.w  word_8841E6(pc,d0.w),0(a4)
ROM:008841BA                 move.w  word_8841E8(pc,d0.w),$C(a4)
ROM:008841C0
ROM:008841C0 loc_8841C0:                ; CODE XREF: sub_883B32+668j
ROM:008841C0                 subq.b  #1,$3B(a6)
ROM:008841C4                 bne.s   locret_8841E4
ROM:008841C6                 move.b  $3A(a6),d0
ROM:008841CA                 addq.b  #1,d0
ROM:008841CC                 cmpi.b  #4,d0
ROM:008841D0                 bcs.s   loc_8841D4
ROM:008841D2                 moveq   #0,d0
ROM:008841D4
ROM:008841D4 loc_8841D4:                ; CODE XREF: sub_883B32+69Ej
ROM:008841D4                 move.b  d0,$3A(a6)
ROM:008841D8                 move.b  #8,$3B(a6)
ROM:008841DE                 move.b  byte_884206(pc,d0.w),4(a4)
ROM:008841E4
ROM:008841E4 locret_8841E4:                ; CODE XREF: sub_883B32+692j
ROM:008841E4                 rts
ROM:008841E4; END OF FUNCTION CHUNK FOR sub_883B32

In this case, a6 is the value of $FFFFE028, which is set to the value of the first entry in the above array. When a level is loaded, the entires are cycled away:

CODE

ROM:00880D64; =============== S U B R O U T I N E =======================================
ROM:00880D64
ROM:00880D64
ROM:00880D64 sub_880D64:                ; CODE XREF: DoGameMode+56Ep
ROM:00880D64                            ; DoGameMode+1A28p ...
ROM:00880D64                 moveq   #0,d0
ROM:00880D66                 lea     ($FFFFE026).w,a0
ROM:00880D6A                 move.w  d0,(a0)+
ROM:00880D6C                 move.w  d0,(a0)+
ROM:00880D6E                 move.w  d0,(a0)+
ROM:00880D70                 move.w  d0,(a0)+
ROM:00880D72                 move.w  d0,(a0)+
ROM:00880D74                 move.w  #$7FFF,(a0)+
ROM:00880D78                 lea     ($FFAD08).l,a0
ROM:00880D7E                 moveq   #$3F,d7; '?'
ROM:00880D80                 move.w  a0,($FFFFE026).w
ROM:00880D84
ROM:00880D84 loc_880D84:                ; CODE XREF: sub_880D64+28j
ROM:00880D84                 lea     $40(a0),a1
ROM:00880D88                 move.w  a1,(a0)
ROM:00880D8A                 movea.w a1,a0
ROM:00880D8C                 dbf     d7,loc_880D84
ROM:00880D90                 move.w  d0,-$40(a0)
ROM:00880D94                 move.l  d0,($FFFFCA9E).w
ROM:00880D98                 move.l  d0,($FFFFCAA2).w
ROM:00880D9C                 move.w  d0,($FFFFE1A2).w
ROM:00880DA0                 move.w  #$D45E,($FFFFD01E).w
ROM:00880DA6                 move.w  #5,($FFFFE01E).w
ROM:00880DAC                 move.w  #$F,($FFFFE020).w
ROM:00880DB2                 move.w  #$3F,($FFFFE022).w; '?'
ROM:00880DB8                 move.w  #$3F,($FFFFE024).w; '?'
ROM:00880DBE                 rts
ROM:00880DBE; End of function sub_880D64

This is called by more than just the level loader, so at this point I'm not entirely sure. And then there's this... thing:

CODE

ROM:00880DC0; =============== S U B R O U T I N E =======================================
ROM:00880DC0
ROM:00880DC0
ROM:00880DC0 sub_880DC0:                ; CODE XREF: sub_8AAB9C+2AEp
ROM:00880DC0                 move.l  #$FF0000,d0
ROM:00880DC6                 move.w  ($FFFFE032).w,d0
ROM:00880DCA                 bmi.s   loc_880DE2
ROM:00880DCC                 cmpi.l  #$FF0D08,d0
ROM:00880DD2                 bcc.s   loc_880DDC
ROM:00880DD4                 move.l  #$FFAD08,d0
ROM:00880DDA                 bra.s   loc_880DE2
ROM:00880DDC; ---------------------------------------------------------------------------
ROM:00880DDC
ROM:00880DDC loc_880DDC:                ; CODE XREF: sub_880DC0+12j
ROM:00880DDC                 move.l  #$FF8000,d0
ROM:00880DE2
ROM:00880DE2 loc_880DE2:                ; CODE XREF: sub_880DC0+Aj
ROM:00880DE2                            ; sub_880DC0+1Aj
ROM:00880DE2                 movea.w d0,a0
ROM:00880DE4                 subi.l  #$FFAD08,d0
ROM:00880DEA                 neg.w   d0
ROM:00880DEC                 andi.w  #$7FC0,d0
ROM:00880DF0                 beq.s   loc_880E12
ROM:00880DF2                 lsr.w   #6,d0
ROM:00880DF4                 add.w   d0,($FFFFE024).w
ROM:00880DF8                 move.w  ($FFFFE026).w,d1
ROM:00880DFC                 move.w  a0,($FFFFE026).w
ROM:00880E00                 subq.w  #1,d0
ROM:00880E02
ROM:00880E02 loc_880E02:                ; CODE XREF: sub_880DC0+4Aj
ROM:00880E02                 lea     $40(a0),a1
ROM:00880E06                 move.w  a1,(a0)
ROM:00880E08                 movea.w a1,a0
ROM:00880E0A                 dbf     d0,loc_880E02
ROM:00880E0E                 move.w  d1,-$40(a0)
ROM:00880E12
ROM:00880E12 loc_880E12:                ; CODE XREF: sub_880DC0+30j
ROM:00880E12                 clr.w   ($FFFFE032).w
ROM:00880E16                 rts
ROM:00880E16; End of function sub_880DC0

But in any case there is just no single code to enable grow and shrink, nor a proper series, but rather a code based on the value of another memory address at any given point in time.

..................

EDIT
Apparently the value of $FFFFE028 depends on... the last address that level mappings are loaded to. Stay tuned.

This post has been edited by Andlabs: 29 January 2010 - 01:28 PM

[Thorn]

Hm, cool that my crazy anecdote actually ties into something. Regarding the 8 *7 * 4 you're pointing out, I know that when I compiled that chart, I found the word that handles frames left on grow or shrink (and again, likely other data in a set of $40 bytes, but I didn't know that before I started Sonic hacking) was always in one of six different locations. While there's other RAM that "moves" too based on the level from some experimenting I did, I don't think you're looking at nearly 8 * 7 * 4 different possibilities, even if that many are plausible.

Again, that word also seems to be dependent on another flag somewhere... if you activate a PAR code over it after hitting a shrink, even after the original item wears off, it'll stay tied to that item until another Grow box is hit. I never did find the flag. Of course, this isn't just about those two items, but those were the easiest to observe the "moving RAM" phenomenon if only because they were some of the only ones the GSHI had incorrectly listed as a code.

Here's a bit from a text file I found on my computer, but the chart saying which level everything was tied to is long gone, and you probably have that info available right there in the disassembly. Some of what I found was useless, but I'll put it all in anyway.

Beginning of game (Introduction 0): $FFAE00 plus...
$00: Byte? - horizontal compress - unknown scale
$01: Byte - horizontal scale (doesn't work properly via PAR code in Kega Fusion)
* $80 - 2x horizontal
* $40 - 4x hor
* $20 - 8x hor
* etc.
$02: Byte? - vertical compress
$03: Byte - vertical scale - see horizontal scale above
These values remain consecutive in other levels, but are located elsewhere in RAM.

Introduction - Evening Portion (3): $FFAE00 plus...
$00: Word - remaining frames of a Grow/Shrink item. Grow item triggers by default if this is set before a Grow/Shrink item is opened, and if either item is opened over the course of the level, the last item used dictates the effects. There must be a flag elsewhere.
$02: Word? - Unknown; defaults to 0500
$04: Word? - Unknown; defaults to 0100
$06: Word? - Unknown; defaults to 0100
$08: Word - Defaults to AE48. At 0000, partner Espio is gold, and arm disappears, and body disappears in waiting animation. Further experimentation needed.
These values remain consecutive in other levels, but are located elsewhere in RAM.

Best of luck from here on out, because that's the end of the little experiments I did way back when and I don't even know what's useful and what's not. If there's any busy work I can help with, like re-charting how some of these values move around, let me know.~

[DigitalDuck]

Beginning of game (Introduction 0): $FFAE00 plus...
$00: Byte? - horizontal compress - unknown scale
$01: Byte - horizontal scale (doesn't work properly via PAR code in Kega Fusion)
* $80 - 2x horizontal
* $40 - 4x hor
* $20 - 8x hor
* etc.

It does work properly (sort of). When you input a PAR code into KEGA Fusion in the format "xxxxxx:00yy", it automatically assumes that you only want to change byte xxxxxx to yy, rather than the expected xxxxxx to 00 and xxxxxx+1 to yy. Hope that makes sense.

[Andlabs]

It does work properly (sort of). When you input a PAR code into KEGA Fusion in the format "xxxxxx:00yy", it automatically assumes that you only want to change byte xxxxxx to yy, rather than the expected xxxxxx to 00 and xxxxxx+1 to yy. Hope that makes sense.

Wow, that's just dumb. Does it use sscanf() to parse these codes?!

Anyway I'm still going at it, stay tuned.

[DigitalDuck]

It does work properly (sort of). When you input a PAR code into KEGA Fusion in the format "xxxxxx:00yy", it automatically assumes that you only want to change byte xxxxxx to yy, rather than the expected xxxxxx to 00 and xxxxxx+1 to yy. Hope that makes sense.

Wow, that's just dumb. Does it use sscanf() to parse these codes?!

Anyway I'm still going at it, stay tuned.

It's like that deliberately. It provides a useful way of changing only one byte instead of two, which (I believe) the original Pro Action Replay couldn't do. If you do need to change xxxxxx to 00 and xxxxxx+1 to yy, you can always use "xxxxxx:0000 + xxxxxx+1:00yy".

This post has been edited by DigitalDuck: 29 January 2010 - 04:21 PM

[Andlabs]

Meh.

Also turns out I was wrong:

CODE

ROM:00883B16 sub_883B16:                        ; CODE XREF: DoGameMode+89Ap
ROM:00883B16                                    ; ROM:0088651Cp
ROM:00883B16                 lea     ($FFFFE272).w,a5
ROM:00883B1A                 lea     ($FFFFE028).w,a6
ROM:00883B1E
ROM:00883B1E loc_883B1E:                        ; CODE XREF: sub_883B16+18j
ROM:00883B1E                 move.w  (a6),d0
ROM:00883B20                 beq.s   locret_883B30
ROM:00883B22                 movea.w d0,a6
ROM:00883B24                 moveq   #0,d0
ROM:00883B26                 move.b  6(a6),d0
ROM:00883B2A                 jsr     sub_883B32(pc,d0.w)
ROM:00883B2E                 bra.s   loc_883B1E

This looks like an event loop, though I'm not entirely sure. So $FFFFE028 must be the first in a list of pointers to handle events. The problem is that I can't find anything that writes to this address; only reads.

I'm going to save this for later. But thanks Thorn for the information; it may prove useful soon enough.

This post has been edited by Andlabs: 29 January 2010 - 04:41 PM

[Andlabs]

I just found code to handle monitors, meaning I now know where grow and shrink come into play. I'll provide details soon.

[Thorn]

^ Hah, I kept trying to stress that I wasn't trying to change the topic onto those items and that they just happened to show the relocated values in RAM well enough for you to see the phenomenon as a whole, but I think you've already gone into it so deeply that I'll just watch what you find. :P

@DigitalDuck: You'd think that to just change a byte, you would simply type something like FFADC1:05 (see the PAR codes on the Wiki). The way Fusion does it is completely unintuitive, but at least now I know, thanks.

[Andlabs]

^ Hah, I kept trying to stress that I wasn't trying to change the topic onto those items and that they just happened to show the relocated values in RAM well enough for you to see the phenomenon as a whole, but I think you've already gone into it so deeply that I'll just watch what you find. :P

Not really, no, this just happened to have happened. My real focus is the object status table format, which the grow and shrink monitors involve. If I can find where they're stored, I can finally interpret the bulk of this code.

I can also provide this little tidbit: offset $30 is the flags for the player; bit 0 on indicates the player has a shield.

[DigitalDuck]

@DigitalDuck: You'd think that to just change a byte, you would simply type something like FFADC1:05 (see the PAR codes on the Wiki). The way Fusion does it is completely unintuitive, but at least now I know, thanks.

You can; Fusion will automatically change FFADC1:05 to FFADC1:0005.

[Andlabs]

Okay, I think I figured it out. There's a set of object status blocks that the game allocates to a series of slots. You have six slots to work with; to access them you multiply the slot # by 2 and call a function, which places the OST into that slot and returns the pointer to the OST. The slots are words starting at $FFFFE026. So for $FFFFE028, you would pass the number 2.

I'm still slowly figuring this out, so don't worry :D

[Mercury]

Ironically, I was screwing around in gens Kmod the other day, looking at Chaotix's OST. I didn't get very far before life intervened, so I haven't gone back.

I'm no brilliant hacker or anything, and this is very crude, but it's what I learned, if you can make any sense of it.

//not the same values when in introduction level. why ram diff when not in normal zones?

AD50: XX XX XS XS YY YY YS YS //XX,Y: P1.x,y; XS,YS: frac(P1.x,y);YS: frac(P1.y);
AD58: ?? ?? ?? ?? XO XO YO YO //XO,YO: P1.x,y-cam.x,y;
AD60:
AD68: ?? XF WW HH ?? ?? ?? ?? //XF: P1.facing; WW: P1.width; HH: P1.height;
AD70: AA BB FA ?? ?? ?? ?? ?? //AA,BB: Image & Subimg?; FA: Floor Angle;
AD78: ?? ?? ?? ?? AA BB ?? ?? //AA, BB: see *1;
AD80: ?? ?? ?? ?? XS XS YS YS //XS,YS: see *2;
AD88:
AD90: XA XA ?? ?? YA YA ?? ?? //XA,YA: P1.armx,y;
AD98: ?? ?? ?? ?? XO XO YO YO //XO,YO: P1.armx,y-cam.x,y;
ADA0:
ADA8:
ADB0:
ADB8:
ADC0:
ADC8:
ADD0:
ADD8:
ADE0:
ADE8:
ADF0:
ADF8: ?? ?? II II ?? ?? ?? ?? //II: Muteki timer for P1: starts at $04B0, decreases by $0001.
AE00:
AE08:

AE10~AECF: P2's RAM

~

DFE8: CX CX CY CY UX UX UY UY //CX,Y: cam.x,y; UX,Y: unlimited cam.x,y; "unlimited": exceeds zone boundaries

~

FDE0: ?? ?? ?? ?? CX CX CY CY //CX,Y: cam.x,y; why this copy?

Footnotes:

*1: These two bytes are used for 3 different things.
• When holding the other character, they are set to weird values, and AA changes when you turn around.
• BB is set to $60 when character takes damages. Counts down by $01 until touches ground.
• After character finishes falling offscreen (see *2), AABB is set $0400. It then counts up by $0002 until it reaches $0800, at which point the character sucks back onto the screen.
• AABB is also used for something when Calling the other character.

*2: Scaling factor for character sprite.
• When XS,YS is $0100, the character is drawn normally.
• When the character is knocked off the screen, XS and YS start decreasing by $0002 until they reach $0010, at which point the character has "finished falling off the screen" (see *1). When they come back, XS and YS start increasing by $0002 until they reach $0100 again, at which point the character is "back".
• When the character hits a Grow Monitor, XS and YS decrease by $0002 until they reach $0080, at which point the character is exactly twice their size.

And yes, I'm well aware that I am total bollocks at presenting information.

[Andlabs]

Thanks, this information will be very useful. But this also makes the situation even more confusing than ever. I'm going to go turn the following funtion to C; this is the one that grabs an OST and puts it in a slot, but from what I can tell it will give you a different OST each time? :S

Syntax Highlighted Code: ASM

ROM:00881702 ; =============== S U B R O U T I N E =======================================
ROM:00881702
ROM:00881702
ROM:00881702 GetOSTAtSlot:                           ; CODE XREF: DoGameMode+584p
ROM:00881702                                         ; ROM:00884A98p ...
ROM:00881702                 move.l  d7,-(sp)
ROM:00881704                 lea     ($FFFFE01E).w,a0
ROM:00881708                 move.w  -2(a0,d0.w),d7
ROM:0088170C                 lea     ($FFFFE026).w,a0
ROM:00881710                 adda.w  d0,a0
ROM:00881712                 tst.w   ($FFFFE026).w
ROM:00881716                 beq.s   loc_88172E
ROM:00881718                 tst.l   d0
ROM:0088171A                 bpl.s   loc_881724
ROM:0088171C
ROM:0088171C loc_88171C:                             ; CODE XREF: GetOSTAtSlot+20j
ROM:0088171C                 move.w  (a0),d7
ROM:0088171E                 beq.s   loc_881736
ROM:00881720                 movea.w d7,a0
ROM:00881722                 bra.s   loc_88171C
ROM:00881724 ; ---------------------------------------------------------------------------
ROM:00881724
ROM:00881724 loc_881724:                             ; CODE XREF: GetOSTAtSlot+18j
ROM:00881724                                         ; GetOSTAtSlot+28j
ROM:00881724                 tst.w   (a0)
ROM:00881726                 beq.s   loc_881736
ROM:00881728                 movea.w (a0),a0
ROM:0088172A                 dbf     d7,loc_881724
ROM:0088172E
ROM:0088172E loc_88172E:                             ; CODE XREF: GetOSTAtSlot+14j
ROM:0088172E                 move.l  (sp)+,d7
ROM:00881730                 ori     #8,ccr
ROM:00881734                 rts
ROM:00881736 ; ---------------------------------------------------------------------------
ROM:00881736
ROM:00881736 loc_881736:                             ; CODE XREF: GetOSTAtSlot+1Cj
ROM:00881736                                         ; GetOSTAtSlot+24j
ROM:00881736                 move.w  ($FFFFE026).w,(a0)
ROM:0088173A                 move.w  a0,d7
ROM:0088173C                 movea.w (a0),a0
ROM:0088173E                 move.w  (a0),($FFFFE026).w
ROM:00881742                 clr.w   (a0)
ROM:00881744                 move.w  d7,2(a0)
ROM:00881748                 moveq   #0,d7
ROM:0088174A                 move.w  d7,4(a0)
ROM:0088174E                 move.l  #unk_881768,$10(a0)
ROM:00881756                 move.l  d7,$20(a0)
ROM:0088175A                 move.l  d7,8(a0)
ROM:0088175E                 move.l  d7,$C(a0)
ROM:00881762                 movem.l (sp)+,d7
ROM:00881766                 rts
ROM:00881766 ; End of function GetOSTAtSlot
ROM:00881766
ROM:00881766 ; ---------------------------------------------------------------------------
ROM:00881768 unk_881768:     dc.b   0                ; DATA XREF: GetOSTAtSlot+4Co
ROM:00881769                 dc.b   0
ROM:0088176A                 dc.b   0
ROM:0088176B                 dc.b   0
ROM:0088176C                 dc.b $80 ; Ç
ROM:0088176D                 dc.b   0

EDIT

CODE

void *GetOSTAtSlot(int OSTnum)
{
    int d7;
    int *a0;

    d7 = 0xE01C[OSTnum];
    a0 = 0xE026 + OSTnum;
    if (*0xE026 == 0) // no entries in the list
        return a0;
    if (OSTnum > 0) {
        for (; d7 >= 0; d7--) {
            if (*a0 == 0)
                break;
            a0 = *a0;
        }
        if (d7 < 0) // not found
            return a0;
    } else
        while ((d7 = *a0) != 0)
            a0 = d7;
    *a0 = *E026;
    d7 = a0;
    a0 = *a0;
    *E026 = *a0;
    *a0 = 0;
    (*a0)[2] = d7;
    (*a0)[4] = 0;
    (*a0)[0x10] = unk_881768;
    (*a0)[8] = (*a0)[0xC] = (*a0)[0x20] = 0;
    return a0;
}

Now I'm thinking that these values at $FFFFE026..$FFFFE030 are really a queue or stack of some sort...

This post has been edited by Andlabs: 30 January 2010 - 03:24 PM