don't click here

Basic Questions & Answers thread

Discussion in 'Engineering & Reverse Engineering' started by Tweaker, May 29, 2008.

  1. GerbilSoft

    GerbilSoft

    RickRotate'd. Administrator
    2,971
    76
    28
    USA
    rom-properties
    Basically, if S3 mode is enabled, S&K uses a different set of data for e.g. title screen, level order, and other things that are different. It also enables the S3-only level music, which isn't present in S&K standalone, by pointing it to addresses in the S3 cartridge. (You can verify this by going into S&K's level select, then trying to play S3 music - it won't do anything.)

    For S2 mode, the 256 KB ROM gets full control of everything. It loads data from the S2 cartridge, but everything else is from the extra ROM. (They didn't have enough space in the 2 MB main ROM, hence the need for an extra ROM and the control registers)
     
  2. Aerosol

    Aerosol

    Not here. Moderator
    11,164
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    Oh ok, great. Now I know! Looks like the way the lock-on works isn't dependent on the way the Genesis works either. Thanks Gerbil.
     
  3. RetroKoH

    RetroKoH

    Member
    1,670
    29
    28
    Project Sonic 8x16
    With knowing how this works. Do you know why exactly S1 and Knuckles couldn't work like the others? Obviously they wanted the avoid the palette issues... but they could've simply used Knuckles palette over Sonic's and made everything else that was normally blue, grey instead... much like how they did with Sonic 2... e.g. the grey shield.

    Was there more to that? The only thing off the top of my head is that the art limit in Sonic 1 would need to be expanded to fit Knuckles. Could this not have been done?

    EDIT - Having been working with putting Knuckles in Sonic 1 lately... I'm surprised I forgot this... The above palette fix doesn't work with the emeralds... I'm sure there are other things I'm overlooking as well.
     
  4. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    19,311
    1,011
    93
    Long-term happiness
    As I understand it there are lots of issues. There are different chunk sizes, the palette problems being worse than in S2, a lack of time to do both.... + - gliding onto conveyor belts? =P  
     
  5. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    I have tried porting software scrolling Routines from Sonic 1 into Sonic 2 before, and had some trouble with it.
    Today, I decided to give if another go, this time using KingOfHarts HG disassembly of Sonic 1 as a base.

    Well, after some work, I got my first Software Scrolling routine ported from Sonic 1; I ported Green Hill Zone's. Originally, I was using the Nick Arcade prototype's GHZ software scrolling, but I managed to got Sonic 1's working just as well, so I'm using that.

    I moved on to Zone 2 (Which is supposed to use Marble Zone's software scrolling), and that's where I'm having a problem.

    Currently, this is what I have

    Code (Text):
    1. SwScrl_MBZ:
    2.         move.w  (Camera_X_pos_diff).w,d4
    3.         ext.l   d4
    4.         asl.l   #6,d4
    5.         move.l  d4,d1
    6.         asl.l   #1,d4
    7.         add.l   d1,d4
    8.         moveq   #2,d6
    9.         bsr ScrollBlock3
    10.         move.w  (Camera_X_pos_diff).w,d4
    11.         ext.l   d4
    12.         asl.l   #6,d4
    13.         moveq   #6,d6
    14.         bsr ScrollBlock5
    15.         move.w  (Camera_X_pos_diff).w,d4
    16.         ext.l   d4
    17.         asl.l   #7,d4
    18.         moveq   #4,d6
    19.         bsr ScrollBlock4
    20.         move.w  #$200,d0
    21.         move.w  (Camera_Y_pos).w,d1
    22.         subi.w  #$1C8,d1
    23.         bcs.s   loc_6590
    24.         move.w  d1,d2
    25.         add.w   d1,d1
    26.         add.w   d2,d1
    27.         asr.w   #2,d1
    28.         add.w   d1,d0
    29. loc_6590:
    30.         move.w  d0,(Camera_BG2_Y_pos).w
    31.         move.w  d0,(Camera_BG3_Y_pos).w
    32.         bsr ScrollBlock2
    33.         move.w  (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w
    34.         move.b  (Scroll_flags_BG).w,d0
    35.         or.b    (Scroll_flags_BG2).w,d0
    36.         or.b    d0,(Scroll_flags_BG3).w
    37.         clr.b   (Scroll_flags_BG).w
    38.         clr.b   (Scroll_flags_BG2).w
    39.         lea (TempArray_LayerDef).w,a1
    40.         move.w  (Camera_X_pos).w,d2
    41.         neg.w   d2
    42.         move.w  d2,d0
    43.         asr.w   #2,d0
    44.         sub.w   d2,d0
    45.         ext.l   d0
    46.         asl.l   #3,d0
    47.         divs.w  #5,d0
    48.         ext.l   d0
    49.         asl.l   #4,d0
    50.         asl.l   #8,d0
    51.         moveq   #0,d3
    52.         move.w  d2,d3
    53.         asr.w   #1,d3
    54.         move.w  #4,d1
    55. loc_65DE:      
    56.         move.w  d3,(a1)+
    57.         swap    d3
    58.         add.l   d0,d3
    59.         swap    d3
    60.         dbf d1,loc_65DE
    61.         move.w  (Camera_BG3_X_pos).w,d0
    62.         neg.w   d0
    63.         move.w  #1,d1
    64. loc_65F4:      
    65.         move.w  d0,(a1)+
    66.         dbf d1,loc_65F4
    67.         move.w  (Camera_BG2_X_pos).w,d0
    68.         neg.w   d0
    69.         move.w  #8,d1
    70. loc_6604:      
    71.         move.w  d0,(a1)+
    72.         dbf d1,loc_6604
    73.         move.w  (Camera_BG_X_pos).w,d0
    74.         neg.w   d0
    75.         move.w  #$F,d1
    76. loc_6614:      
    77.         move.w  d0,(a1)+
    78.         dbf d1,loc_6614
    79.         lea (TempArray_LayerDef).w,a2
    80.         move.w  (Camera_BG_Y_pos).w,d0
    81.         subi.w  #$200,d0
    82.         move.w  d0,d2
    83.         cmpi.w  #$100,d0
    84.         bcs.s   loc_6632
    85.         move.w  #$100,d0
    86. loc_6632:
    87.         andi.w  #$1F0,d0
    88.         lsr.w   #3,d0
    89.         lea (a2,d0),a2
    90. Bg_Scroll_X:
    91.         lea (Horiz_Scroll_Buf).w,a1
    92.         move.w  #$E,d1
    93.         move.w  (Camera_X_pos).w,d0
    94.         neg.w   d0
    95.         swap    d0
    96.         andi.w  #$F,d2
    97.         add.w   d2,d2
    98.         move.w  (a2)+,d0
    99.         jmp loc_66EA(pc,d2)
    100. Loop_Bg_Scroll_X:
    101.         move.w  (a2)+,d0
    102. loc_66EA:      
    103.         move.l  d0,(a1)+
    104.         move.l  d0,(a1)+
    105.         move.l  d0,(a1)+
    106.         move.l  d0,(a1)+
    107.         move.l  d0,(a1)+
    108.         move.l  d0,(a1)+
    109.         move.l  d0,(a1)+
    110.         move.l  d0,(a1)+
    111.         move.l  d0,(a1)+
    112.         move.l  d0,(a1)+
    113.         move.l  d0,(a1)+
    114.         move.l  d0,(a1)+
    115.         move.l  d0,(a1)+
    116.         move.l  d0,(a1)+
    117.         move.l  d0,(a1)+
    118.         move.l  d0,(a1)+
    119.         dbf d1,Loop_Bg_Scroll_X
    120.         rts
    If anyone is willing to help, I posted what each ScrollBock means below in terms of what routine it correlates to in my Sonic 2 disassembly:

    ScrollBlock1 is SetHorizVertiScrollFlagsBG
    ScrollBlock2 is imported from Soinc 1, I'll post that below.
    ScrollBlock3 is SetHorizScrollFlagsBG
    ScrollBlock4 is SetHorizScrollFlagsBG2
    ScrollBlock5 is SetHorizScrollFlagsBG3

    My imported ScrollBlock2 looks like this:

    ScrollBlock2:
    move.w (Camera_BG_Y_pos).w,d3
    move.w d0,(Camera_BG_Y_pos).w
    move.w d0,d1
    andi.w #$10,d1
    move.b (Verti_block_crossed_flag_BG).w,d2
    eor.b d2,d1
    bne.s ++
    eori.b #$10,(Verti_block_crossed_flag_BG).w
    sub.w d3,d0
    bpl.s +
    bset #0,(Scroll_flags_BG).w
    rts

    + bset #1,(Scroll_flags_BG).w
    + rts

    Anyone know what might be wrong?
     
  6. Clownacy

    Clownacy

    Tech Member
    1,076
    638
    93
    My own implementation ended in a similar way, and has yet to be successful. If I've implemented yours properly, we're having the same problem, except for the misplaced squares all over the place that eventually start overwriting the background with the underground art, and some weird shaking.
    [​IMG]
    Curiously, my REV00 port works perfectly. An interesting thing to note is that the REV00 code uses ScrollBlock3 which is actually REV01's ScrollBlock2. ScrollBlock2, from what I understand, handles MZ's unique Y-Scroll, and isn't used by any other zones except for REV00's GHZ.

    There's no need to port Bg_Scroll_X, it's already in Sonic 2 under the name SwScrl_HPZ_Continued.

    The art is misplaced, you're probably already aware of that. From what I've observed, some underground art is above the first cloud layer, several clouds are on the same layer as the mountains, and the underground art doesn't even fully appear, with the underground section being set against the same corrupt overworld art on loop, these copies, however, don't scroll. That said, I'm curious about what handles mapping background art.

    Since the REV00 background, which depends on ScrollBlock3/2, works, I would assume that ScrollBlock2 has been ported correctly, however, if you comment out the branch to ScrollBlock2, along with the obvious disabling of the Y-Scroll, the underground art above the highest cloud layer vanishes, but the clouds on the same layer as the mountains remain, also, in your case those weird squares vanish.

    Here's my own attempt, where I simply stuck to finding equivalent RAM variables and labels, keeping the code vanilla:

    REV00
    Code (Text):
    1. SwScrl_MZ:
    2.     move.w  (Camera_X_pos_diff).w,d4
    3.     ext.l   d4
    4.     asl.l   #6,d4
    5.     move.l  d4,d1
    6.     asl.l   #1,d4
    7.     add.l   d1,d4
    8.     moveq   #0,d5
    9.     bsr.w   SetHorizVertiScrollFlagsBG
    10.     move.w  #$200,d0
    11.     move.w  (Camera_Y_pos).w,d1
    12.     subi.w  #$1C8,d1
    13.     bcs.s   loc_6402
    14.     move.w  d1,d2
    15.     add.w   d1,d1
    16.     add.w   d2,d1
    17.     asr.w   #2,d1
    18.     add.w   d1,d0
    19.  
    20. loc_6402:
    21.     move.w  d0,(Camera_BG2_Y_pos).w
    22.     bsr.w   ScrollBlock2    ; REV00 ScrollBlock3
    23.     move.w  (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w
    24.     lea (Horiz_Scroll_Buf).w,a1
    25.     move.w  #223,d1
    26.     move.w  (Camera_X_pos).w,d0
    27.     neg.w   d0
    28.     swap    d0
    29.     move.w  (Camera_BG_X_pos).w,d0
    30.     neg.w   d0
    31.  
    32. loc_6426:
    33.     move.l  d0,(a1)+
    34.     dbf d1,loc_6426
    35.     rts
    36. ; End of function SwScrl_MZ

    REV01
    Code (Text):
    1. SwScrl_MZ:
    2.     move.w  (Camera_X_pos_diff).w,d4
    3.     ext.l   d4
    4.     asl.l   #6,d4
    5.     move.l  d4,d1
    6.     asl.l   #1,d4
    7.     add.l   d1,d4
    8.     moveq   #2,d6
    9.     bsr SetHorizScrollFlagsBG
    10.     move.w  (Camera_X_pos_diff).w,d4
    11.     ext.l   d4
    12.     asl.l   #6,d4
    13.     moveq   #6,d6
    14.     bsr SetHorizScrollFlagsBG3
    15.     move.w  (Camera_X_pos_diff).w,d4
    16.     ext.l   d4
    17.     asl.l   #7,d4
    18.     moveq   #4,d6
    19.     bsr SetHorizScrollFlagsBG2
    20.     move.w  #$200,d0
    21.     move.w  (Camera_Y_pos).w,d1
    22.     subi.w  #$1C8,d1
    23.     bcs.s   loc_6590
    24.     move.w  d1,d2
    25.     add.w   d1,d1
    26.     add.w   d2,d1
    27.     asr.w   #2,d1
    28.     add.w   d1,d0
    29. loc_6590:
    30.     move.w  d0,(Camera_BG2_Y_pos).w
    31.     move.w  d0,(Camera_BG3_Y_pos).w
    32.     bsr ScrollBlock2
    33.     move.w  (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w
    34.     move.b  (Scroll_flags_BG).w,d0
    35.     or.b    (Scroll_flags_BG2).w,d0
    36.     or.b    d0,(a3)
    37.     clr.b   (Scroll_flags_BG).w
    38.     clr.b   (Scroll_flags_BG2).w
    39.     lea (TempArray_LayerDef).w,a1
    40.     move.w  (Camera_X_pos).w,d2
    41.     neg.w   d2
    42.     move.w  d2,d0
    43.     asr.w   #2,d0
    44.     sub.w   d2,d0
    45.     ext.l   d0
    46.     asl.l   #3,d0
    47.     divs.w  #5,d0
    48.     ext.l   d0
    49.     asl.l   #4,d0
    50.     asl.l   #8,d0
    51.     moveq   #0,d3
    52.     move.w  d2,d3
    53.     asr.w   #1,d3
    54.     move.w  #4,d1
    55. loc_65DE:  
    56.     move.w  d3,(a1)+
    57.     swap    d3
    58.     add.l   d0,d3
    59.     swap    d3
    60.     dbra    d1,loc_65DE
    61.     move.w  (Camera_BG3_X_pos).w,d0
    62.     neg.w   d0
    63.     move.w  #1,d1
    64. loc_65F4:  
    65.     move.w  d0,(a1)+
    66.     dbra    d1,loc_65F4
    67.     move.w  (Camera_BG2_X_pos).w,d0
    68.     neg.w   d0
    69.     move.w  #8,d1
    70. loc_6604:  
    71.     move.w  d0,(a1)+
    72.     dbra    d1,loc_6604
    73.     move.w  (Camera_BG_X_pos).w,d0
    74.     neg.w   d0
    75.     move.w  #$F,d1
    76. loc_6614:  
    77.     move.w  d0,(a1)+
    78.     dbra    d1,loc_6614
    79.     lea (TempArray_LayerDef).w,a2
    80.     move.w  (Camera_BG_Y_pos).w,d0
    81.     subi.w  #$200,d0
    82.     move.w  d0,d2
    83.     cmpi.w  #$100,d0
    84.     bcs.s   loc_6632
    85.     move.w  #$100,d0
    86. loc_6632:
    87.     andi.w  #$1F0,d0
    88.     lsr.w   #3,d0
    89.     lea (a2,d0),a2
    90.     bra SwScrl_HPZ_Continued
    91. ; End of function SwScrl_MZ

    ScrollBlock2
    Code (Text):
    1. ScrollBlock2:
    2.     move.w  (Camera_BG_Y_pos).w,d3
    3.     move.w  d0,(Camera_BG_Y_pos).w
    4.     move.w  d0,d1
    5.     andi.w  #$10,d1
    6.     move.b  (Verti_block_crossed_flag_BG).w,d2
    7.     eor.b   d2,d1
    8.     bne.s   ++
    9.     eori.b  #$10,(Verti_block_crossed_flag_BG).w
    10.     sub.w   d3,d0
    11.     bpl.s   +
    12.     bset    #0,(Scroll_flags_BG).w
    13.     rts
    14. +
    15.     bset    #1,(Scroll_flags_BG).w
    16. +
    17.     rts
    18. ; End of function ScrollBlock2

    EDIT: Quoted due to new page.
     
  7. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    I tried both routines, though I'm oping to get 01 working, since revision 01 had better scrolling.
    Incidentally, your Revision 00 port is working very strangely for me. The background itself is scrolling correctly, but it reacts to every movement Sonic makes, and one if starts scrolling, it doesn't stop. Also, the faster Sonic goes, the faster the background moves while standing still. This leads me to believe I may have labeled a ScrollBlock wrongly after all, even though GHZ's software scroll works.

    As for Revision 01, in short, it's working better, I must have gotten an equate wrong or something.
    The randomly appearing blocks are gone in your version, and the scrolling itself seems to be working properly, but I am still getting some symptoms:
    [​IMG]
    The cloud layer and underground layers are still appearing wrong for me. That's the only bug I'm experiencing at the moment minus the Labyrinth Zone ripple, which I had put in Hidden Palace and will be easy enough to fix (Just check the water flag).
    Are you getting similar symptoms?
     
  8. Clownacy

    Clownacy

    Tech Member
    1,076
    638
    93
    Yes, my REV01 has never fully worked, sorry if I made you think I was providing you with a fix. But the REV00 issues... Did you use the provided ScrollBlock2 and unmodified SetwhateverScrollFlags? I had ported the scrolling data from my largely modified disassembly to a fresh HG disassembly a while back with no issues. Could you try there and see if the code works?

    I just recreated the squares. At some point, I don't remember when or why, but I... well, look here:

    Yours
    Code (Text):
    1. loc_6590:
    2.     move.w  d0,(Camera_BG2_Y_pos).w
    3.     move.w  d0,(Camera_BG3_Y_pos).w
    4.     bsr ScrollBlock2
    5.     move.w  (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w
    6.     move.b  (Scroll_flags_BG).w,d0
    7.     or.b    (Scroll_flags_BG2).w,d0
    8.     or.b    d0,(Scroll_flags_BG3).w        <-------
    9.     clr.b   (Scroll_flags_BG).w
    10.     clr.b   (Scroll_flags_BG2).w
    11.     lea (TempArray_LayerDef).w,a1
    12.     move.w  (Camera_X_pos).w,d2
    I was cross comparing our code when I found this:

    Mine
    Code (Text):
    1. loc_6590:
    2.     move.w  d0,(Camera_BG2_Y_pos).w
    3.     move.w  d0,(Camera_BG3_Y_pos).w
    4.     bsr ScrollBlock2
    5.     move.w  (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w
    6.     move.b  (Scroll_flags_BG).w,d0
    7.     or.b    (Scroll_flags_BG2).w,d0
    8.     or.b    d0,(a3)                        <------
    9.     clr.b   (Scroll_flags_BG).w
    10.     clr.b   (Scroll_flags_BG2).w
    11.     lea (TempArray_LayerDef).w,a1
    12.     move.w  (Camera_X_pos).w,d2
    Why the heck did I do that? Whatever it did, changing it back to Scroll_flags_BG3 caused the squares to begin appearing! Scroll_flags_BG3 is used by ScrollBlock5 aka SetHorizScrollFlagsBG3, however, commenting out the branch to it doesn't affect the squares, it just disables the mountain layer's scrolling.

    On a side note, not to be rude, but aren't you supposed to not quote posts directly above yours? I only quoted because of the page-break.
     
  9. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    I kinda just hit the quote button out of instinct. My bad.

    Unfortunately, the effects seem to carry even into an otherwise unmodified disassembly for some reason. Are you sure you didn't change something the pasted version by mistake? My Scroll Block 2 is the same one you posted to me, and in fact, all the scrolling routines in my disassembly are unmodified besides adding a secondary label, ScrollBlock#:
     
  10. Clownacy

    Clownacy

    Tech Member
    1,076
    638
    93
    Ooooooooops, I'm an idiot, when renaming SwScrl_MZ from Deform_MZ I accidentally deleted the first command, sorry, corrected:

    Code (Text):
    1. SwScrl_MZ:
    2.     move.w  (Camera_X_pos_diff).w,d4
    3.     ext.l   d4
    4.     asl.l   #6,d4
    5.     move.l  d4,d1
    6.     asl.l   #1,d4
    7.     add.l   d1,d4
    8.     moveq   #0,d5
    9.     bsr.w   SetHorizVertiScrollFlagsBG
    10.     move.w  #$200,d0
    11.     move.w  (Camera_Y_pos).w,d1
    12.     subi.w  #$1C8,d1
    13.     bcs.s   loc_6402
    14.     move.w  d1,d2
    15.     add.w   d1,d1
    16.     add.w   d2,d1
    17.     asr.w   #2,d1
    18.     add.w   d1,d0
    19.  
    20. loc_6402:
    21.     move.w  d0,(Camera_BG2_Y_pos).w
    22.     bsr.w   ScrollBlock3
    23.     move.w  (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w
    24.     lea (Horiz_Scroll_Buf).w,a1
    25.     move.w  #223,d1
    26.     move.w  (Camera_X_pos).w,d0
    27.     neg.w   d0
    28.     swap    d0
    29.     move.w  (Camera_BG_X_pos).w,d0
    30.     neg.w   d0
    31.  
    32. loc_6426:
    33.     move.l  d0,(a1)+
    34.     dbf d1,loc_6426
    35.     rts
    36. ; End of function SwScrl_MZ
    EDIT: I'm getting 404s when trying to download a fresh disassembly... strange.
     
  11. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    I'm suprised I missed that too.

    I'm hoping at some point I'll be able to figure out the Rev 01 effects, but at least this works perfect. Thank you very much, Clownacy! It works fine now.
     
  12. RetroKoH

    RetroKoH

    Member
    1,670
    29
    28
    Project Sonic 8x16
    As many who browse this thread would know, I'm putting a basic Knuckles in Sonic 1 hack together... to be ported to my Sonic 1 REV C project. I've run into a slight issue however, as it relates to DPLC's. For one particular frame in Knuckles' Ending specific sprites...
    [​IMG]
    THIS ONE

    ... I've got a DPLC request that calls for $1A tiles to be loaded to VRAM. Said request looks like the following:
    Code (Text):
    1.  
    2. EndKnuxDynPLC_51A:
    3. dplcHeader
    4.     dplcEntry   3, $38A     ; standard sprite
    5.     dplcEntry   $10, $38D   ; standard sprite
    6.     dplcEntry   1, $39D     ; standard sprite
    7.     dplcEntry   4, $39E     ; standard sprite
    8.     dplcEntry   2, $467     ; SOCK OVERLAY
    9. EndSonicDynPLC_51A_End
    The two added tiles at the bottom are for an overlay to make Knuckles' socks appear green. This appears properly in EVERY other sprite except this one. This clipping from the VRAM shows why:
    [​IMG]
    The long yellow rectangle was added by me, and reflects the empty VRAM space where the tiles should be loaded... there's more than enough for 3 tiles...[​IMG]
    There are 3 tiles NOT loaded to VRAM, the 2 overlay tiles, and one of Knuckles original tiles that is supposed to go on the bottom part of his fist... take a close look at his hand in this screenshot.
    [​IMG]

    You'll also notice the socks aren't green, rather they are blue... this is the result of the lacking overlay tiles.

    I've expanded the art limit, and have NOTHING being written to that part of VRAM so I don't know what the deal is... These are custom Knuckles sprites made specifically to counter the palette limitation... the standard ones used in normal zone gameplay appear correctly, EXCEPT for this frame as well... with the one tile for his fist not appearing.

    So yea I'm stumped...
     
  13. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,220
    472
    63
    Japan
    The interesting thing about this is that only 17 (hex) tiles have transfered in your VRAM image there. Which just so happens to be Sonic 1's original Sonic art transfer amount.

    Code (Text):
    1.         move.l  #$94019370,(a5)
    Where the "01" and "70" are 0170 together. This is 02E0 bytes divided by 2 (a.k.a. 17 tiles), you'll find these in various places in the v-blank routines of Sonic 1 (loc_CD4, loc_DAE, loc_ED8 & loc_FAE). To increase the number of tiles is to add 10 to the 0170 for every additional tile you want transfered each time.

    BUT...

    Given that you've shown me a macro tells me this is probably based on an up to date disassembly where the lables may differ, and the DMA setup isn't raw assembly. I did try to find a recent disassembly, but I don't know which one yours is, and the HG thingy seems to be down anyway.

    EDIT: I've just realised that you've said you have "expanded the art limit", I don't know if this above is what you meant, so I'll leave it above just in-case.

    The only other explanation I can think of is the RAM space where Sonic's art is loaded to before it is transfered. The DPLC loading routine in the original Sonic 1 game loads art from ROM to RAM at C800 - CADF (I.e. FFC800 - FFCADF) holding the 17 tiles before the transfer. You're attempting to transfer 1A tiles, this means you need 340 bytes of RAM storage (I.e. from RAM C800 - CB3F). If RAM CAE0 - CB3F is used by anything else (which could be a posibility), then your art might just be overwritten in RAM before it has a chance to transfer.

    However, this does depend on whether or not you've changed the art loading routine. I know a few people have resorted to porting Sonic 2's dynamic art loading system which causes the game to make a DMA transfer directly from ROM to VRAM, instead of ROM to RAM to VRAM.

    I think we're gonna need more info about your game/source.
     
  14. RetroKoH

    RetroKoH

    Member
    1,670
    29
    28
    Project Sonic 8x16
    I use the HG disasm of Sonic 1. If it's any help, the HG port of your Sonic 1-Two Eight project that I posted uses the same source, so aside from the obvious changes there, it's identical to the one you'd normally find on HG anyway.
    The macro is MainMemory's macro, used for mappings and DPLC's... to the best of my knowledge... this only makes editing the mappings and DPLC's easier... because I don't think it edits anything else in that regard, though I could be mistaken.

    By "expanding the art limit"... I apologize, I should've been more specific. I meant following this guide: http://info.sonicret...s_and_art_limit
    Ironically, or coincidentally enough... if there is no irony there to be had, it is your old guide.

    Aside from that, I haven't changed much else... other than removing points from the Main PLC to make room for the tiles (Not the most feasible solution but I can fix that at a later time...)

    I'll try looking at RAM that I have available. I can think of plenty of ways to free up RAM so that's not too much of an obstacle... luckily for me, everything is equated so moving stuff around is also a piece of cake. I'll give it a go and report back.

    EDIT: I went the route of using the Sonic 2 DMA transfer... Took a page out of ReadySonic for that one, actually, so thanks to Mercury on that note. Now it all works out well. Thanks for the tips Markey!
     
  15. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,220
    472
    63
    Japan
    Then if that be it the case, I would make the immediate assumption that it is in fact the transfer size in the v-blank routines.

    Yours might be...

    Code (Text):
    1.         DMA $02E0,SonicArtRAM,$70000083
    Or at least something similar like that, where the 2E0 is the size of the art transfer. Simply increasing the value should solve the problem.
     
  16. RetroKoH

    RetroKoH

    Member
    1,670
    29
    28
    Project Sonic 8x16
    Code (Text):
    1.  
    2. writeVRAM   v_sgfx_buffer,$2E0,vram_sonic ; load new Sonic gfx
    3.  

    I did notice that... those lines get replaced with what I ultimately went with. Thank you for the tip though!
     
  17. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    Okay, so I am back again, jumping into a new hacking experience, and I need a little bit of help.

    First thing is something pretty simple.

    I want a single level in my Sonic 2 hack (Pretty much, for a Cutscene.), where the characters (Sonic and Tails normally), both have a hard speed cap of $600. While I do have some code for this, it's literally comparing the MainCharacter's inertia to $600, followed by the Sidekick. Is there a better way to do this?

    This is my current code, which is only used for going left, but it wouldn't be hard to make it work for left AND right.. It'd just be sloppy and waste several cycles I could probably save.

    Code (Text):
    1.   cmpi.w #-$600,(MainCharacter+inertia).w
    2.   bgt.s +
    3.   move.w #-$600,(MainCharacter+inertia).w
    4. +
    5.   cmpi.w #-$600,(Sidekick+inertia).w
    6.   bgt.s +
    7.   move.w #-$600,(Sidekick+inertia).w
    8. +
    Any wisdom on making this could quicker to run while achieving the same purpose would be greatly appreciated.

    Now, my second question.. Is.. Not so easy. As far as I can tell.
    I'm trying to port a platform object from Sonic 1, and while the platform appears properly now, if Sonic touches the top, he gets teleported a million, billion miles into the sky away. The object of $2F (The sinking and rising platforms from Marble Zone). Is there any advice on how to change the code so it works as needed?

    Here is an excerpt of code that handles the collision:
    Code (Text):
    1. ; ===========================================================================
    2.  
    3. LGrass_Slope:               ; XREF: LGrass_Action
    4.         moveq   #0,d1
    5.         move.b  width_pixels(a0),d1
    6.         addi.w  #$B,d1
    7.         movea.l objoff_30(a0),a2
    8.         move.w  x_pos(a0),d2
    9.         bsr.w   SlopeObject
    10.         bra.s   LGrass_Display
    11. ; ===========================================================================
    12.  
    13. LGrass_Solid:               ; XREF: LGrass_Action
    14.         moveq   #0,d1
    15.         move.b  width_pixels(a0),d1
    16.         addi.w  #$B,d1
    17.         move.w  #$20,d2
    18.         cmpi.b  #2,mapping_frame(a0)
    19.         bne.s   loc_AF8E
    20.         move.w  #$30,d2
    21.  
    22. loc_AF8E:
    23.         movea.l $30(a0),a2
    24.         bsr.w   SolidObject
    25.  
    26. LGrass_Display:             ; XREF: LGrass_Action
    27.         bsr.w   DisplaySprite
    28.         bra.w   LGrass_ChkDel
    If more information is needed, please drop me a PM, and I'll give you all the code I have for the object.
    It should be noted that my ExitPlatform label is loc_19D62 in my s2.asm.

    If anyone knows anything, I would really appreciate help, I have pretty much no experience with setting up platform objects for Sonic 1, and minimal experience with doing so for Sonic 2.
     
  18. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,220
    472
    63
    Japan
    Code (Text):
    1.         move.w  #$0600,d1               ; prepare speed cap amount
    2.         move.w  (MainCharacter+inertia).w,d0        ; load character's X speed
    3.         cmp.w   d1,d0                   ; is the character moving right too fast?
    4.         bgt.s   MainXRight              ; if so, branch
    5.         add.w   d1,d0                   ; advance left maximum speed to 0000
    6.         bpl.s   MainXOK                 ; if the result is positive, speed is slower than -600
    7.         neg.w   d1                  ; reverse speed cap to negative maximum (left)
    8.  
    9. MainXRight:
    10.         move.w  d1,(MainCharacter+inertia).w        ; save new speed
    11.  
    12. MainXOK:
    13.         move.w  #$0600,d1               ; prepare speed cap amount
    14.         move.w  (Sidekick+inertia).w,d0         ; load character's X speed
    15.         cmp.w   d1,d0                   ; is the character moving right too fast?
    16.         bgt.s   SideXRight              ; if so, branch
    17.         add.w   d1,d0                   ; advance left maximum speed to 0000
    18.         bpl.s   SideXOK                 ; if the result is positive, speed is slower than -600
    19.         neg.w   d1                  ; reverse speed cap to negative maximum (left)
    20.  
    21. SideXRight:
    22.         move.w  d1,(Sidekick+inertia).w         ; save new speed
    23.  
    24. SideXOK:
    For a reasonably optimised speed cap, probably not the best and not as small, but certainly quicker.

    As for your platform issue, looking at the code, it doesn't seem accurate to the original. For example.

    Code (Text):
    1.         movea.l $30(a0),a2
    2.         bsr.w   SolidObject
    When in fact, the original Sonic 1 code does not call the routine "SolidObject". Instead it calls "SolidObject2F", a special type of SolidObject routine designed specifically for object 2F to help deal with the sloping in conjunction with the solidity.
     
  19. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    Thank you for helping me with the code for the Speed Cap.
    After you told be about SolidObject2F's special routine, I decided to try porting it once again. I tried this in the past, and had no success, but my ASM knowledge is better now, so I have had *partial* success.

    For one, the routine is from Sonic 1, so Tails doesn't collide with it. I should be able to fix that with relative ease though, if I just compare to the other solid object routines.

    What gets me, is when Sonic leaves the platform:

    [​IMG]
    Sonic does not fall off of the platform when walking off of it.
    I will post my SolidObject2F, though I'm sure that's not the problem.

    Code (Text):
    1. SolidObject2F:              ; XREF: Obj2F_Solid
    2.         lea (MainCharacter).w,a1
    3.         tst.b   Render_Flags(a0)
    4.         bpl.w   Solid_Ignore
    5.         move.w  X_pos(a1),d0
    6.         sub.w   X_pos(a0),d0
    7.         add.w   d1,d0
    8.         bmi.w   Solid_Ignore
    9.         move.w  d1,d3
    10.         add.w   d3,d3
    11.         cmp.w   d3,d0
    12.         bhi.w   Solid_Ignore
    13.         move.w  d0,d5
    14.         btst    #0,Render_flags(a0) ; is object horizontally flipped?
    15.         beq.s   Solid2f_notflipped  ; if not, branch
    16.         not.w   d5
    17.         add.w   d3,d5
    18.  
    19. Solid2f_notflipped:
    20.         lsr.w   #1,d5
    21.         moveq   #0,d3
    22.         move.b  (a2,d5.w),d3
    23.         sub.b   (a2),d3
    24.         move.w  Y_pos(a0),d5
    25.         sub.w   d3,d5
    26.         move.b  Y_Radius(a1),d3
    27.         ext.w   d3
    28.         add.w   d3,d2
    29.         move.w  Y_pos(a1),d3
    30.         sub.w   d5,d3
    31.         addq.w  #4,d3
    32.         add.w   d2,d3
    33.         bmi.w   Solid_Ignore
    34.         move.w  d2,d4
    35.         add.w   d4,d4
    36.         cmp.w   d4,d3
    37.         bcc.w   Solid_Ignore
    38.         bra.w   loc_19A2E
    For you, Solid_Ignore would be loc_19AC4.

    Edit: I removed a bunch of unnecessary stuff.. Working with the object for a while, I realized the problem must be my SolidObject routine. I'n not quite sure what I need to do to make it work, but I'll keep trying.
     
  20. Clownacy

    Clownacy

    Tech Member
    1,076
    638
    93
    Say, notice something here?

    JAP Sonic 1
    [​IMG]

    Sonic 1 Two-Eight HG
    [​IMG]

    My ROM
    [​IMG]

    It's those clouds near the mountain, along with where some of the cloud 'cuts off' (to the left of the second tallest pillar in the Two-Eight screenshot)!

    Sonic 1 Two-Eight (main change being 128x128 chunks) works fully with the REV00 background, but not the REV01, just as our ROMs (also 128x128 chunk) don't.