don't click here

Basic Questions & Answers thread

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

  1. bluemanga

    bluemanga

    Member
    5
    0
    1
    UK
    Hey everyone, I have a question, or you could say it's seeking advice depending on how you view it. I've basically learned a little bit of m68k, but I want to make sure the knowledge is sinking in. So basically, there are a couple of good guides out there, but what I want to know is how I can apply myself. To really learn and gain a good understanding of how these things work. I thought it would be nice if some of you, were to perhaps give tips on how you taught yourselves the assembly language, or any interesting methods you came up with. I'm basically asking this, because I do want to be pushed in the right direction, but hopefully get to learn a little bit more about this community as well :) So I just wanna know some methods on learning the language, and how to apply what I learn in the context of hacking Sonic 1, for instance. Hope I made sense lol, thanks for your time.

    - Joe
     
  2. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    406
    63
    Japan
    I don't know about giving advice, as it's all hazy.

    People have their own opinions and definitions on what good programming is, and this will give you a major contradiction. The truth is, everyone's method is more or less decent enough if it actually works, so it's a varied definition, and depends on the person.

    If you're interested in a few guides/referrences though, a search engine like Google will bring up pretty much all the information you'll ever need. If you google "68k reference manual", you'll be massaged by an endless list of pdf manuals. A Google search of "68k tutorial" brings up a fair few good links too (Interestingly enough, the first result of "68k tutorial" on Google is my very own tutorial!! Score one Markey?!).

    Of course, if you have the odd minor question about a specific instruction or on usage of instructions together, then asking here occasionally doesn't hurt.
     
  3. RetroKoH

    RetroKoH

    Member
    1,662
    22
    18
    Project Sonic 8x16
    I can go ahead and personally recommend Markey's guide right away as a primer for first learning ASM. It's what I picked up when I started learning how to hack. I've also got his guide he wrote on music editing... MJ here just has a way of making it much easier to understand.
     
  4. bluemanga

    bluemanga

    Member
    5
    0
    1
    UK
    Thank you, it's certainly a step in the right direction. The reference manuals that can be found seem very handy too. I'll make sure to ask any other questions as I progress lol. So In the mean time, I was wondering in what ways you can get involved in the community, or if there are any interesting things taking place. Thanks.
     
  5. RetroKoH

    RetroKoH

    Member
    1,662
    22
    18
    Project Sonic 8x16
    Well, there's always the annual hacking contest, which has grown A LOT during the few years in which I've been a member. Even if you don't have a hack to submit, you can always speak to Ayla or Spanner or someone about hosting a video workshop, or even doing media for the contest on YouTube or whatever... This usually gets officially announced at around the end of the year... as far as when the contest begins, so look out for that in this ERE forum.

    There is also SAGE, which tends to change as far as when it is held. This year we had a "2 Act" event. For that, I'd say ask around and keep your eyes glued to the Home Page for upcoming news. You can do the same for any and all IRL events Sonic-related as well.

    Let's see... what else? The wiki? Interviews... SEGA RETRO could use some assistance too... There are a lot of ways you can get involved. Also if you really wanna dig deep for something to do, say... testing for others' hacks, and the like... I'd say give people a PM and ask, OR even better... IRC. For that don't use the link at the top of the page, go to Mibbit. I'm not on there that often but when I am, I find the Retro members that frequent the IRC are good to talk to as well. Even find people on Skype if you can.

    That was a mouthful... but don't tl;dr. Look through it all and also see for yourself what's going on as well.

    Best wishes!
     
  6. bluemanga

    bluemanga

    Member
    5
    0
    1
    UK
    Thanks once again :) seems there's a lot to look into lol. I'll be sure to explore all the things you mentioned.
     
  7. E-122-Psi

    E-122-Psi

    Member
    2,470
    612
    93
    I'm having an odd problem with the S3+K disassembly where I try to build it and makes an error for EVERY SINGLE LINE. All I've done is edit some sprites. Anyone know where this problem is coming from?
     
  8. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    65
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    A good rule of thumb is to look for the very first error and fix it. Assemblers tend to be very poorly written compared to compilers, and certain kinds of errors make them to think everything after is an error. In AS, this tends to be an operand that goes out of range in some addressing modes.
     
  9. E-122-Psi

    E-122-Psi

    Member
    2,470
    612
    93
    The thing is the cmd window states next to EVERY line is not properly aligned and I have no way of backtracking to the first error since the window doesn't allow you to go much far back as the first hundred or so.

    EDIT: Skip that. With lightning reflexes (I.e.. dumb luck) I managed to find what seems to be the starting line, the beginning of Sonic_Load_PLC. Still have no idea what's wrong with it though.
     
  10. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    First off, this is exactly why the S2 disassembly outputs errors to a separate file. Secondly, if it says that line is not properly aligned, did you try putting an 'even' directive before it?
     
  11. E-122-Psi

    E-122-Psi

    Member
    2,470
    612
    93
    Well that's had some effect, now it's just making errors for all lines that branch to Sonic_Load_PLC.
     
  12. Pacca

    Pacca

    ASM amateur Member
    42
    16
    8
    Labyrinth Zone
    Sonic 2 CD Remix
    Selbi made a guide on general error fixing in the tutorials section of SSRG. From what I can see, your suffering from branch errors, which are a well covered part of his guide.

    Edit: SSRG appears to be unstable right now, so you might have to wait a bit...

    Edit2: It's up and stable now, you should be able to read Selbis guide now. Also, since I'm feeling nice, here's a link to it
     
  13. E-122-Psi

    E-122-Psi

    Member
    2,470
    612
    93
    The guide doesn't seem to mention the example I need. It's a message claiming the code isn't properly aligned:

    Code (ASM):
    1. Sonic_Load_PLC:
    2.  
    3.         moveq   #0,d0
    4.         move.b  $22(a0),d0
    5.  
    I added an even above the first line of code but it just leads to all cases of this not aligning:

    Code (ASM):
    1.         jsr (Sonic_Load_PLC).l
     
  14. Pacca

    Pacca

    ASM amateur Member
    42
    16
    8
    Labyrinth Zone
    Sonic 2 CD Remix
    Plopping an even after the line in question usually does the trick. If that doesn't work, I'm not sure what the issue is...
     
  15. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    What are you talking about?

    Psi, if you put the even before the first instruction but AFTER the label, that is your problem. Look, above LoadSonicDynPLC is a bunch of 'dc.b's. Clearly, one of those end on a goofy address. I mean, look at this:

    Code (ASM):
    1. SupSonAni_Walk:     dc.b $FF,$77,$78,$79,$7A,$7B,$7C,$75,$76,$FF
    2. SupSonAni_Run:      dc.b $FF,$B5,$B9,$FF,$FF,$FF,$FF,$FF,$FF,$FF
    3. SupSonAni_Push:     dc.b $FD,$BD,$BE,$BF,$C0,$FF,$FF,$FF,$FF,$FF
    4. SupSonAni_Stand:    dc.b   7,$72,$73,$74,$73,$FF
    5. SupSonAni_Balance:  dc.b   9,$C2,$C3,$C4,$C3,$C5,$C6,$C7,$C6,$FF
    6. SupSonAni_Duck:     dc.b   5,$C1,$FF
    7. SupSonAni_Transform:    dc.b   2,$6D,$6D,$6E,$6E,$6F,$70,$71,$70,$71,$70,$71,$70,$71,$FD,  0
    8.     even
    9.  
    10. ; ---------------------------------------------------------------------------
    11. ; Sonic pattern loading subroutine
    12. ; ---------------------------------------------------------------------------
    13.  
    14. ; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||
    15. ; loc_1B848:
    16. LoadSonicDynPLC:
    17.  
    18.     moveq   #0,d0
    19.     move.b  mapping_frame(a0),d0    ; load frame number
    That even there comes after the potentially wonky data, and before both the code and the label. "warning: address is not properly aligned" means that the address isn't aligned. All you have to do to fix that is even out the address. How to do this is obvious: in your case, Anim - Sonic.asm doesn't have an even (or a newline, for that matter) at the end. That 0 at the end of byte_12CA4 is supposed to be the even (but nobody's bothered to equate it), so that's what kept it working in hacks that didn't tweak the anim files. Just slap an even at the end of that file, and you're good to go.

    I don't know if you've picked up on this yet, but the 68k can't process instructions or perform word/longword operations on odd addresses. That's why these errors exist.

    Actually, using a listing file would have helped here. You could have opened sonic3k.lst, and looked for that label. Then you could backtrack and find where the addresses became odd. In your case, all you'd have to do is scroll up a few lines, and you would have found one of your animations. Problem solved.
     
  16. E-122-Psi

    E-122-Psi

    Member
    2,470
    612
    93
    I put an even after the link to the animation file. That seemed to do it. Thanx. :D

    I'm still stuck on the Sonic 1 coding question on the previous page by the way (pathetic aren't I?), if anyone knows any other numbers or locations that would be different when porting from Sonic 2, please notify me.
     
  17. RetroKoH

    RetroKoH

    Member
    1,662
    22
    18
    Project Sonic 8x16
    Quickie based on this guide: SCHG - Adding Levels in Sonic 1

    I've added 3 zones to my Sonic 1 hack - Let's just call them: Bridge (7), Jungle (8) and Sky Base (9). The numbers in parentheses are their ID in the engine.

    So far, after following the guide for each zone... and mind you, at this point they are more or less duplicates of GHZ, MZ, and SLZ, respectively... I'm having trouble with one level, and that is SKBZ. Trying to load the level results in seeing the title card, and then a series of LINE1111 EMULATOR crashes occuring. Running it in ReGen results in the ROM debugger window, and then the game just stops. Running it in KEGA however, allows me to continue to play the level after spamming the C button a few times. Upon playing the level, EVERYTHING else is ok... So IDK why ONLY this level gives me grief.

    To make things better... there is another bug which I believe to be related, and it occurs at the end of ANY zone... when the Got Through card appears there are garbled tiles sprinkled along the screen. These will also occur in the SS results screen too... If I were to guess, I'd say this were somehow PLC related... though I've honestly got no real idea.

    HERE is a rar of screengrabs of the essential visuals of what's going on, along with a RAM dump of the crash itself.

    Any help pointing me in the right direction to BOTH bugs would be great. Thx guys!
     
  18. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    406
    63
    Japan
    Without a copy of the ROM, please take the information I present here with a grain of salt...

    Given you're recieving FX instruction errors, I'll lead to the assumption that it's a specific jump operation somewhere. Since the guide and levels deal with jump tables, I'd immediately run and assume one of those is to blame. However, given how carefully you've written your post, I'd say you've done everything you've been told to carefully and the problem is not ignorance (I.e. missing a symbol out or something stupid). So, it must be something that the guide is missing...

    Here is an example of one of the several jump tables it insists on being expanded on (which is fair play):

    Code (Text):
    1.         moveq   #0,d0
    2.         move.b  ($FFFFFE10).w,d0
    3.         add.w   d0,d0
    4.         move.w  Deform_Index(pc,d0.w),d0
    5.         jmp Deform_Index(pc,d0.w)
    The problem I'm guessing is to do with signed negative relative addressing... Imagine for a moment, you're table:

    Code (Text):
    1. Deform_Index:   dc.w Deform_GHZ-Deform_Index, Deform_LZ-Deform_Index
    2.         dc.w Deform_MZ-Deform_Index, Deform_SLZ-Deform_Index
    3.         dc.w Deform_SYZ-Deform_Index, Deform_SBZ-Deform_Index
    4.         dc.w Deform_GHZ-Deform_Index
    The first word will be something like 0014 (14 bytes away from the start of table), the next one will be 0142 (142 bytes away), the next one will be 2044 bytes away, etc. Well... What if, you have so much code from the start of that table, that the distance from the start of that table and the 9th zone's routine is further than 7FFF bytes away? That would make it 8000+, and although the assembler would not complain about assembling it (as it's a valid assemble-able value). The instruction "jmp Deform_Index(pc,d0.w)" will treat 8000 to FFFF as negative, and will attempt to jump to something before the table instead of after the table like its suppose to.

    If that is the case, then the simplist solution is to change:

    Code (Text):
    1.         jmp Deform_Index(pc,d0.w)
    Into:

    Code (Text):
    1.         jmp Deform_Index(pc,d0.l)
    (The .w to .l)

    This does however require that the upper word of d0 must be clear, otherwise you'll end up with an unpredictable jump address. For the deformation jump table though:

    Code (Text):
    1.         moveq   #0,d0       ; <<<---- Clear long-word of d0 (entire register)
    2.         move.b  ($FFFFFE10).w,d0
    3.         add.w   d0,d0
    4.         move.w  Deform_Index(pc,d0.w),d0
    5.         jmp Deform_Index(pc,d0.w)
    ...the register's upper word is already cleared, so all you would need to do for deformation is change the .w to .l and that's it. The same would apply to; the palette cycling, the art animating, the level draw table, etc (Basically every jump table in that guide). Change the .w to a .l, and ensure d0's upper word is cleared before attempting the jump.

    This is the only theory I have right now, so apologise in advance if it is not the solution to your problem. But give it a go, and see what happens...
     
  19. E-122-Psi

    E-122-Psi

    Member
    2,470
    612
    93
    Does anyone know how to extend the number of sprites Sonic displays in Sonic 3 before it switches to his Sonic Extra file. I take it has something to do with this code, but I'm unsure what that line is doing to estimate it:

    Code (ASM):
    1.         move.l  #ArtUnc_Sonic,d6
    2.         cmpi.w  #$1B4,d0
    3.         bcs.s   loc_12CF8
    4.         move.l  #ArtUnc_Sonic_Extra,d6
     
  20. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    bcs is equivalent to blo (Branch if LOwer), so if d0 (probably the frame number) is less than $1B4 (unsigned), it will skip loading the extra file, and use the normal art instead.