The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.

Do-it-yourself Sonic the Hedgehog

TheSonicRetardTheSonicRetard Registered User regular
edited May 2008 in Games and Technology
NOTE: I just got the OK after about 2 days of hardcore discussion with the mods for this topics, but, much like my last topic, discretion is the name of the game. Before we begin with this topic, I'll post my usual ground rules for this topic:

*DON'T ASK TOO MANY QUESTIONS
We're treading a very fine line, and the mods reluctantly gave me a little leeway with the subject matter at hand, so I'm guiding this topic. Don't ask any questions related to roms, emulation or any of that. This is a topic on the inner workings of sonic the hedgehog and nothing else.

*DON'T BE DUMB
Kinda goes in line with the first rule. I'm using my discretion in guiding this topic, so I expect everyone who posts in this topic to do the same. If you know it's against the TOS for this site, don't talk about it. I suggest everyone read the rules if they're unclear about what can be discussed and what can't.

*FEEL FREE TO POST
Much like my (on hiatus) Ecco topic and the previous sonic topic, the format will be an open discussion. I'll post stuff, but in spurts. In the meantime, feel free to converse freely and ask questions.

In addition, I feel that, before I begin this topic, I owe an explanation about the state of the "The Things you didn't know about Ecco the Dolphin" thread. Simply put, I had to deal with some family stuff for about a week, and when I fixed that stuff up, I simply had lost my motivation to keep going. I write in a very finicky style, and unless I'm in the mood to write on a subject, I can't write on it. Prior to the stuff I had to deal with, I was gun-ho about the topic, but after I simply lost interest. I promise to eventually pick it back up, but in the mean time, this topic has been on my mind for a while. So without further delay, I present my second great sonic topic...


DO-IT-YOURSELF SONIC

INTRODUCTION

So, I got a lot of really good feedback on my last sonic topic, and people seemed genuinely interested. After speaking with some people in the sonic community, and having a long talk with the PA mods about if this topic is alright, I've been given the green light to go balls to the wall. Consider the last sonic topic to be the tip of the ice berg - that stuff is what's supposed to be common knowledge in the sonic community. It's beginners stuff. We're gonna go deep, and very in depth into sonic in this topic.

This topic is a very in depth, study into Sonic the Hedgehog, in the highest degree. This topic is basically a summery of the efforts of the sonic hacking community that I belong to, along with a nice little look into current projects that are going on.

I'll begin with a brief history of the scene I'm about to be talking about. I mostly refer to it as "The sonic community" but that label is very misleading. There are actually two sonic communities. The first is more accurately known as Sonic Fans - people who are fanatical about Sonic as a character. These tend to be fans the Archie and Saturday morning cartoons, as well as the furry community. I'll with hold my judgement of this community, but suffice to say I really don't belong to it.

No, the community that I and Blaze belong to is actually a more underground community that is known as the Sonic Hacking community. The extent of the organization within our community is staggering. It's a true hacking scene. The word hacker has a lot of malicious connotations these days, so let me clarify - I mean hacking in the truest sense of the word. Every member of the community is there simply because they have a thirst for knowledge and a passion for what they do. The community specializes in ripping sonic the hedgehog up into microscopic levels and examining every piece of it. We operate in true hacking style - we're fiercely competitive, but at the same time, everything that is found is expected to be fully shared. Thus, discoveries and knowledge grow exponentially.

It might surprise many members of this board to find out that I'm merely an average member in the Sonic Community. I'm officially registered as an oldbie, someone who was around when the community was founded back in 1997-ish. I've contributed, and I know a fair amount more than average, but no where near the top. The top dogs of the community are truly special people, who's efforts are going to be discussed in great detail in this topic.

A brief history of our community. We enjoy membership into the hundreds range, making us a much larger community than, say, the final fantasy hacking community (I see some guys from their community regularly posting updates on their fan engine... great work, by the by) or the mario hacking community, and we're much older. We formed in 1997 as a group devoted to compiling information on flat out strange shit in sonic the hedgehog - magazine scans of levels that don't exist, lost items, etc. Pretty much what I posted in the last topic.

Over the years, however, we changed out focus to hacking sonic games. Examining code, debugging, and way beyond. Today, our community enjoys a vast collection of tallented people. Chris Senn, the man who was in charge of Sonic Xtreme for the Sega Saturn, for example, is one of our most active members, and we have a few other members who work at sega.

It's through the efforts of hundreds of people working for about 10 years that this topic is possible. So enjoy, because you're in for a treat.

SO WHAT IS THIS TOPIC ABOUT SPECIFICALLY?

Not too long ago, the holy grail of the sonic community was achieved. Resident legend DRX managed to disassemble sonic the hedgehog in its entirety. For those who are unfamiliar, a disassembly is essentially the source code. Through years of effort, DRX disassembled sonic and today, thanks to him, we have the full source code in 68K assembly for Sonic 1, Sonic 2, Sonic 3, and Sonic & Knuckles. Of course, that's not to say the source code is useful - it's pretty much useless unless you have real hardware to burn sega genesis carts with, and a 68k sega genesis assembly kit, and on top of that, you need to be proficient in 68k assembly.

I will not provide any of that in this topic. A notice to anyone who has their hopes up, if you're expecting me to post the source code for sonic the hedgehog so you can compile your own game or something, you're going to leave disappointed. That is illegal, and not to mention it's against the TOS. It's all for the best anyways... I'm almost certain everyone in this forum doesn't have the 18 year old equipment necessary to take advantage of this because they probably weren't an official sega genesis developer.

Rather, what I will be doing is taking the sonic source code, routine by routine, and explaining how it works in plain, simple english. That is, I'm going to essentially explain the implementation of sonic the hedgehog on the whole. I remind everyone that this is a highly sensitive topic, and mods are eagle eying this topic, so please use discretion.

SO WHATS THE POINT OF ALL THIS

With all the limitations I just explained about the source code, and how it's mainly useless to everyone, you're probably wondering what's the point of this topic. People on this, and many other forums often complain about the lack of good 2D sonic games today. The Sonic community agrees. With Sonic source code in hand, several talented people have taken up the task of making the next great sonic game themselves. The result of in depth studying of the very information I'm about to talk about has directly lead to the following:

TheSonicRetard on
«13456713

Posts

  • Bob The MonkeyBob The Monkey Registered User regular
    edited April 2007
    Oh wow.

    I really appreciate everything you've given the forum, TSR, and it looks like what we already know is just the tip of the iceberg. Really looking forward to this thread.

    Edit: But wow, talk about leaving the thread on a cliffhanger. That was the Half-Life 2 of OPs.

    Bob The Monkey on
  • LewiePLewieP Registered User regular
    edited April 2007
    My God. I just got an image of Sonic dressed as Morpheus offering me either a red or a blue pill.

    How do I choose?

    LewieP on
  • Ninja BotNinja Bot Registered User regular
    edited April 2007
    Oh TSR and your ending your posts with cliffhangers. Now I'm not gonna do anything but read this thread tonight.

    Ninja Bot on
  • Gorilla SaladGorilla Salad Registered User regular
    edited April 2007
    LewieP wrote: »
    My God. I just got an image of Sonic dressed as Morpheus offering me either a red or a blue pill.

    How do I choose?
    Punch him in the face and steal his shoes.

    Gorilla Salad on
  • RookRook Registered User regular
    edited April 2007
    Should I serve you a cease and desist now? Or do you want to wait until you've put some hard work and effort into it.

    Rook on
  • Gorilla SaladGorilla Salad Registered User regular
    edited April 2007
    Rook wrote: »
    Should I serve you a cease and desist now? Or do you want to wait until you've put some hard work and effort into it.
    ARe you gonna use the snitch button?

    Gorilla Salad on
  • BearcatBearcat Registered User regular
    edited April 2007
    I think this is the apocalypse?

    Bearcat on
  • IShallRiseAgainIShallRiseAgain Registered User regular
    edited April 2007
    ooh I like it when you do these posts. Seeing as I plan on eventually becoming a programmer for a game developing company, I find your in-depth examination of the sonic the headhog games very interesting.

    IShallRiseAgain on
    Alador239.png
  • LaveLave regular
    edited April 2007
    I love you Retard. Guide me

    Lave on
    poirot1vi.gif
    Scholar and a Gentleman? Critical of bad science and religion? Skeptobot - Is for you!!
  • PataPata Registered User regular
    edited April 2007
    Rook wrote: »
    Should I serve you a cease and desist now? Or do you want to wait until you've put some hard work and effort into it.

    Ahahahaha.

    The various video game hacking communities have existed for years without any such thing.

    You really think they can be stopped? They already skirt the edges of legality.

    :^: Good thread TSR, I've wanted to make a thread like this with a broader scope but never felt I had the ability to convince the mods about it.

    Example: FuYoSa never got a C&D for Lunar Magic. Not going to say anymore about that though.

    Pata on
    SRWWSig.pngEpisode 5: Mecha-World, Mecha-nisim, Mecha-beasts
  • RookRook Registered User regular
    edited April 2007
    Pata wrote: »
    Rook wrote: »
    Should I serve you a cease and desist now? Or do you want to wait until you've put some hard work and effort into it.

    Ahahahaha.

    The various video game hacking communities have existed for years without any such thing.

    You really think they can be stopped? They already skirt the edges of legality.

    :^: Good thread TSR, I've wanted to make a thread like this with a broader scope but never felt I had the ability to convince the mods about it.

    I'm talking more about the
    several talented people have taken up the task of making the next great sonic game themselves.
    rather than anything else. I think we all know what's happened to pretty much every project out there trying to use someone elses license.

    Rook on
  • TheSonicRetardTheSonicRetard Registered User regular
    edited April 2007
    The following project have come as a direct result of the information I'm about to talk about in this thread:

    RETRO SONIC
    titlescreenph5.png
    Author: Taxman
    Status: RELEASED

    A fully coded fan sonic game written for the Dreamcast. Taxman was one of the first to jump aboard the C++ bandwagon and elevate his game above the normal "click n' create" trash the scene normally sees. Tax is a friend of mine, too, and he is one of the people who has helped me the most in my understanding of sonic the hedgehog.

    volcanictower01vu6.png
    retrosonic2plz4.png
    retrosonic4pvf6.png
    VIDEO
    VIDEO

    SONIC METTRIX
    spmtitleym4.gif
    Author: Stealth
    Status: RELEASED

    The first C++ sonic fan game released. Sonic fan games prior to this were normally made in Click n Create, a piss-poor cheap game creation software. This game was fully coded by stealth and plays remarkably similar to the real sonic the hedgehog. Although it's long since been abandoned and it's been eclipsed, it still is a milestone in fan game creation.

    wz1ox9.gif
    siz1jx6.gif
    siz2fn8.gif


    PRO SONIC
    98708562hj4eu9.png
    Author: Saxman
    Status: PENDING

    Thus far, the ultimate sonic project. Pro Sonic is Sax's masterpiece. It's a fan engine of epic proportions. This is the kind of engine I envision creating. It works almost exactly like the regular sonic engine, but it's way more powerful. Just check out the videos... stunning.

    74575608ua4fw5.png
    VIDEO
    VIDEO


    HEDGEHOG ENGINE
    sonicscreenky8.png
    Author: Me!
    Status: PENDING

    My own sonic game. All the information I'm gonna post in this topic is the logic I've been using to make my own sonic game. I hope that one day my game will be up there with Pro Sonic and Retro Sonic.

    ghzwarpedvk1.jpg

    And there have been countless hacks, fangames, and other little neat things created because of the knowledge that I'm going to talk about in a bit. So simply put, this stuff is important to people who specifically want to know how the game creation process goes.

    I'm gonna lead us through this topic sort of like I'm teaching out of a lesson plan. our first step in this process will be an introduction to 68k assembly.

    TheSonicRetard on
  • PataPata Registered User regular
    edited April 2007
    Rook wrote: »

    I'm talking more about the
    several talented people have taken up the task of making the next great sonic game themselves.
    rather than anything else. I think we all know what's happened to pretty much every project out there trying to use someone elses license.

    My point still stands.

    If Sega hasn't stopped them by this point, there's no way they're going to at all.

    Pata on
    SRWWSig.pngEpisode 5: Mecha-World, Mecha-nisim, Mecha-beasts
  • Recoil42Recoil42 Registered User regular
    edited April 2007
    TSR have my manbabies please

    Recoil42 on
  • MechMantisMechMantis Registered User regular
    edited April 2007
    Rook wrote: »
    Pata wrote: »
    Rook wrote: »
    Should I serve you a cease and desist now? Or do you want to wait until you've put some hard work and effort into it.

    Ahahahaha.

    The various video game hacking communities have existed for years without any such thing.

    You really think they can be stopped? They already skirt the edges of legality.

    :^: Good thread TSR, I've wanted to make a thread like this with a broader scope but never felt I had the ability to convince the mods about it.

    I'm talking more about the
    several talented people have taken up the task of making the next great sonic game themselves.
    rather than anything else. I think we all know what's happened to pretty much every project out there trying to use someone elses license.

    You forget the fact that there are some Sega people in this community. They already know about this.


    EDIT: Unless, of course, TSR is a fucking liar. Then they could get cease-and-desisted.

    MechMantis on
  • TheSonicRetardTheSonicRetard Registered User regular
    edited April 2007
    Oh, but before I begin, I'd like to take this opportunity to spill the beans.

    Sonic Rush sequel. "Sonic Rush Adventure"

    Sega will announce it in a few weeks, most likely.

    TheSonicRetard on
  • TheSonicRetardTheSonicRetard Registered User regular
    edited April 2007
    MechMantis wrote: »
    Rook wrote: »
    Pata wrote: »
    Rook wrote: »
    Should I serve you a cease and desist now? Or do you want to wait until you've put some hard work and effort into it.

    Ahahahaha.

    The various video game hacking communities have existed for years without any such thing.

    You really think they can be stopped? They already skirt the edges of legality.

    :^: Good thread TSR, I've wanted to make a thread like this with a broader scope but never felt I had the ability to convince the mods about it.

    I'm talking more about the
    several talented people have taken up the task of making the next great sonic game themselves.
    rather than anything else. I think we all know what's happened to pretty much every project out there trying to use someone elses license.

    You forget the fact that there are some Sega people in this community. They already know about this.

    Pachuka interviewed Yuji Naka back in 2003 or 2004.

    Suffice to say the big people at Sonic Team know about this. Especially since we've contacted and interviewed most of them one on one.

    TheSonicRetard on
  • PataPata Registered User regular
    edited April 2007
    Oh, but before I begin, I'd like to take this opportunity to spill the beans.

    Sonic Rush sequel. "Sonic Rush Adventure"

    Sega will announce it in a few weeks, most likely.

    Rad.

    <3s to TSR.

    So many <3s.

    Pata on
    SRWWSig.pngEpisode 5: Mecha-World, Mecha-nisim, Mecha-beasts
  • LewiePLewieP Registered User regular
    edited April 2007
    Oh, but before I begin, I'd like to take this opportunity to spill the beans.

    Sonic Rush sequel. "Sonic Rush Adventure"

    Sega will announce it in a few weeks, most likely.

    I had heard rumblings about this, they registered the trademark didn't they, I guessed it was either a DS sequal or an Adventure sequal with Rush in it.

    LewieP on
  • ZhouZhou Registered User regular
    edited April 2007
    The only thing you need to do is insert Sonic in Michael Jackson's Moonwalker.

    Zhou on
  • TheSonicRetardTheSonicRetard Registered User regular
    edited April 2007
    Luckily for me, DRX already has a great 68K ASM basics guide out there, so rather than me wasting my time retyping all the basics, I'll just paste it in it's entirety. Mind you, this won't get you programming genesis games, or even let you be proficient at reading 68K asm, but it'll let you get a basic understanding of the 68k asm code we'll be looking at a bit later.

    NOTE: For the purpose of this topic, I will spoiler any long chunks of 68K ASM as I post it. The reason being is that it's flat out ugly to look at.

    ASM GUIDE PART ONE
    BASICS
    Genesis has one CPU called 68000 (68k for short). It understands a set
    of 16-bit instructions, which are called machine code (like 4E75, 31FC
    etc.). But programming in hexes isn't very easy (well, it's not
    impossible... few years ago I programmed only using machine code =P),
    so nifty programmers made the assembly language. There is a program
    (assembler) which assembles this to machine code. Assembly is a bit
    more humanized. It's not BASIC, but it's not hard. I will try to make
    you understand this. I can't guarantee that it will be interesting =P


    Genesis has 64kb of RAM. You can store everything there. There is a VDP
    (graphics CPU) which controls graphics =P It has 64k of RAM (called
    VRAM - Video RAM), which can store patterns, sprites atributes, scroll
    data etc.

    Here's a map of 68k memory:

    $000000-$3FFFFF - ROM

    $400000-$9FFFFF - Unused

    $A00000-$A0FFFF - Z80

    $A10000-$A1001F - I/O

    $A10020-$BFFFFF - Miscellaneous

    $C00000-$C0001F - VDP

    $C00020-$DFFFFF - VDP mirrors

    $E00000-$FFFFFF - RAM (it repeats each $10000, so $E00000 is the same as $E20000 and $FF0000. Most games use $FF0000-$FFFFFF)

    There are three data types. Byte, word (2 bytes) and longword (4
    bytes). There is no unsigned or signed types like in C, because each
    data type can be treated as unsigned or signed. There are 16 registers
    which store temporary data (kinda like variables). Each one is a
    longword. There's 8 data registers called D0-D7 and 8 address registers
    (A0-A7). You should use A0 to A6, because A7 is the stack pointer (I'll
    tell you about it later). Hey, but what's the difference between
    address and data registers? Data registers store data, and address
    registers usually store pointers to some location in RAM. For example, address registers can be incremented or decremented.

    68000 stores data in Big Endian way. So longword $12345678 is stored
    $12,$34,$56,$78 in memory, compared to Little Endian $78,$56,$34,$12.
    x86 and Z80 use Little Endian. Z80 is for the music stuff... (x86 is
    the CPU in your PC)

    Don't worry if you don't get something or you forget all this stuff. You will get used to it.

    LET'S GET STARTED
    Now open the Sonic 1 disassembly in notepad. Many lines isn't there? =P

    Comments are marked by ; or *. The game code starts with label 'Entrypoint:'.

    Ok, let's start with the most interesting part of programming, programming XD. Ok, first command, MOVE.
    This command moves some data (constants, registers, RAM) into either
    another register or RAM location. JohnnyUK nicely called it 'copying'.

    Syntax: move source,destination

    Exapmles:

    move.w #2,($FFFFFE10).w

    move (a6),d3

    move.b ($FFFFFE12).w,(a5)+

    Looks complicated? Don't worry, I'll explain everything =) First, why .w, .b? If you use it, you will specify the data length being copied. If you don't the assembler will probably choose .l. .b is byte, .w is word and .l - longword.

    For example:
    move.b #1,($FFFFFE10).w

    before - FFFFFE10: 05 06 07 08
    after - FFFFFE10: 01 06 07 08

    move.w #1,($FFFFFE10).w

    before - FFFFFE10: 05 06 07 08
    after - FFFFFE10: 00 01 07 08

    move.l #1,($FFFFFE10).w

    before - FFFFFE10: 05 06 07 08
    after - FFFFFE10: 00 00 00 01

    I hope you get it =P Now, #x is a immediate value (a number, constant etc =P). Examples:

    #5 - decimal 5

    #$20 (hex) - decimal 32

    #%1001 (binary) - decimal 9

    #@777 (octal) - decimal 511

    #'SEGA' - ascii text (remember, this can be tricky. 1 letter - use .b, 2 letters - use .w, 4 letters - use .l)

    ($FFFFFE10).w is an absolute address. Locations in ram HAVE TO be .w. ROM addresses usually are .l. Some programmers (forgot the name of the game...) use .w
    for short ROM addresses, but that can cause serious bugs. Remember,
    never write anything to a ROM address ;) (real Genesis will crash)

    Examples:

    move.b #1,($FFFFFE12).w

    moves 1 (byte) to $FFFFFE12 in RAM (lives in Sonic 1)

    move.l ($12346).l,d0

    moves a longword from address $12346 in ROM to data register d0.

    move.w (a0)+,d0

    moves a word from the location at A0 to d0, increments a0 by 2 (length of word) after that.

    I'll explain the registers now (already told about it before, but let's
    revise XD). There are 16 registers - 8 data registers and 8 address
    registers. All registers are longwords. Data registers are called d0-d7 and can store any data. Address registers usually store pointers to some location in ROM or RAM, but they can also be used for data. Address registers are a0-a7, but don't use a7 because it's the stack pointer (I'll explain later). Registers are a nice way of storing temporary data. Eg.

    move.b ($FFFFFE12).w,d0 ;copy value at $FFFFFE12 to d0 (this is a comment =P)

    move.b d0,($FFFFFE13).w ;move d0 to $FFFFFE13

    Of course this could be done with:

    move.b ($FFFFFE12).w,($FFFFFE13).w

    but this is an example =P The biggest reason why use registers is that you can modify them without modifying the source, eg.

    move.b ($FFFFFE12),d0 ;copy $FFFFFE12 to d0

    add.b #2,d0 ;add 2 to d0

    ;do something with d0

    We have a new command, ADD. It adds a number to a register or a place in ram.

    Syntax: add source,destination

    Examples: add.b #2,($FFFFFE12).w ;increment $FFFFFE12 by 2

    add.l (a0),a0 ;increment a0 by value at a0

    add d0,d0 ;add d0 to d0 (d0 = d0 * 2)

    What is the difference between a0 and (a0)?

    a0 is the address, only a number. And (a0) is the value at this address. Have a look at this:

    $FFFFFE12: 01 ;some value in ram

    a0: $FFFFFE12 ;address

    (a0): 01 ;value at address $FFFFFE12

    You can postincrement or predecreament address registers:

    ;a0 is incremented by 1 (length of byte) after the instruction

    move.b (a0)+,d0

    ;a0 is decremented by 2 (length of word) before the instruction

    move.w -(a0),d0

    Exapmle:

    move.l (a0)+,d0

    before: a0: $00012345

    d0: $00000000

    $000012345: $FFFFFFFF

    after: a0: $00012349

    d0: $FFFFFFFF

    $000012345: $FFFFFFFF

    Hope you understand =)

    Now, the opposite of adding is substracting. You do it using SUB instruction.

    Exapmles:

    sub #5,a0

    sub.w (a0),($FFFFFE12).w

    sub.b d0,d1

    That would be the end of this chapter. In next lesson we'll learn about LEA,
    labels, comparing and branching depending on the results (like
    if...else). It's about 3 am and I'm a bit tired. If you don't
    understand something or you have any questions, ask on the forums =)

    COMPARES AND BRANCHES

    Yay, finally got some time to write another lesson (it's almost 12pm).
    Anyway, we'll learn about compares, branches and subroutines. But
    first, here's some additional info to the previous lesson:

    There are few types of MOVE. There's MOVEA, MOVEM, MOVEP and MOVEQ. Usually the compiler chooses the right one, but you sometimes have to choose the correct one (assemblers aren't very smart ;).

    MOVEA moves an address into an address register. The syntax:

    movea address,a0-a7

    As I said before, don't use a7. Just wait =) The address is an effective address (can be a register, immediate value etc.) Here are some examples:

    movea #$12346,a0 ;moves address $12346 to a0

    movea -(a1),a5 ;moves address at value at pointer

    ;in a1 to a5, decrements a1 before instruction

    movea d0,a3 ;moves d0 to a3


    I'll introduce the labels now :) Remember BASIC and goto function? Labels are similiar:

    somecode
    bra Label
    somecode

    Label:
    somecode

    BRA goes (jumps) to a label. Bcc instructions can branch on certain conditions, but they can be made with the CMP instruction. This means a bunch of new instructions ;) Here's the example code:

    game code
    game code
    bsr LifesSub
    game code
    game code

    LifesSub:
    cmp.w #$0102,($FFFFFE10).w
    bne TheLevelIsNot0102
    add.b #1,($FFFFFE12).w

    TheLevelIsNot0102:
    rts

    Oh my, so many new things. We created label 'LifesSub'. It's called by BSR, what's that? BSR means Branch to SubRoutine.
    Subroutines are like functions in C (or other programming languages).
    You can call them whenever you want. There is one important thing
    though, after the end of subroutine you have to put rts, which returns to the state before subroutine calling. Example:

    bsr Foo
    bsr Foo
    bsr Foo
    ...

    Foo:
    code
    rts

    Now, when Genny sees BSR (8 or 16 bit instruction, relative address) or JSR (32 bit absolute address, I'll tell about it later), it copies the next insruction PC
    (Program Counter - register which stores info about the current
    instruction location in ROM, like where the code is now, it's hard to
    explain ;) state to stack.
    I promised before that I'll tell you what the hell stack is. Stack is a reserved section in RAM (CAN be in SRAM, but it isn't tested yet ;) for temporary things, like our PC state. Now you see why RTS is important. RTS copies the PC state back from stack.

    So, what's the CMP thingy? It COMPARES two values. It's not exactly if...else statement like in C. BNE means 'Branch if Not Equal'. So if $FFFFFE10 (level) isn't $0102 (these two values are the same, equal), it branches. If it isn't, it doesn't. Simple, huh? There are many Bcc instructions, one of them being BEQ (Branch if EQual) which works opposite to BNE. I mentioned JSR some lines before. It is like BSR,
    but it doesn't branch, but jumps to a subroutine. What's the
    difference? Branch instruction is small (1 byte if branch is between
    -127...127 and 2 bytes if it's between -32 768...32 768) but it's
    limited. Some games like Sonic 3 & Knuckles use RAM for... code.
    Yeah, small parts of code that can be edited at any time. You can't
    branch to RAM, that's first. Second, the limitation. $8000 back or
    forth is not very big. There's the JSR. The instruction is longer (4 or
    6 bytes, depending on the type), but it's an absolute address (you can
    make a relative jsr insruction, but I've already told enough
    new things today...), so you can jump to any address in 68000 memory.
    For 68k memory map, see additional info. Examples:

    jsr $FFFFFFF0
    jsr Label
    jsr a0

    The absolute equivalent of BRA is JMP, which jumps to an absolute address without puting the PC on the stack.

    The last two things we're gonna learn today are MOVEQ and MOVEM.

    MOVEQ is similar to MOVE, but it means MOVE Quick. It's a faster (and smaller - 1 byte) instruction. You can only move 1 byte. Example:

    moveq #0,d0

    Clears ENTIRE d0, because when you moveq into a register, it sets the ENTIRE register.

    It clears the register! Move.l would take 6 bytes (hey, in old times space was worth more than gold), when moveq only 1.

    You can also use ADDQ and SUBQ (they can also change values in ram)

    Now, the last thing. MOVEM (MOVE Multiple).
    It can copy more than one register to a location in RAM or in reverse
    (RAM to more than one register). As I said before A7 is the stack
    pointer. So you can use stack, too! The reason why MOVEM was
    created are subroutines. Subroutines are called in many different
    places in ROM. And subroutines often use registers. Now if you don't
    want to change some important registers inside a subroutine, you should
    backup these registers before the subroutine and copy them back after.
    Don't get it? Look at the example:


    move.b #$10,d0
    bsr Subroutine
    move.b d0,d1
    ...

    Subroutine:
    ...
    moveq #0,d0
    ...
    rts


    Take a look at that code. We set d0 to $10, then the subroutine clears d0. After the subroutine, we move d0 to d1. That's not exactly what we wanted (it'll set d1 to 0, we wanted it to be $10). To fix that we can use movem:

    move.b #$10,d0
    bsr MovemSub
    move.b d0,d1
    ...

    MovemSub:
    movem d0-d2,-(sp)
    ...
    moveq #0,d0
    ...
    movem (sp)+,d0-d2
    rts


    Now it'll work! the SP is the stack pointer. You could use A7 (it's the same), but I use sp. We decremented sp, because if we didn't, we would change some important data in SP. and after that, we increment SP back to its state. The register list can be different. Eg.

    d0-d5 - d0, d1, d2, d3, d4, d5
    a5-a6 - a5, a6
    d1-d3/d6-d7 - d1, d2, d3, d6, d7
    d6-a1/a5-a6 - d6, d7, a0, a1, a5, a6

    There are many different possibilites... If you don't understand MOVEM,
    just skip it, and come back to it when you will know more about ASM. It
    took me 4 tries to understand that thing XD (and I didn't have any
    nifty guides *shot*)

    That's all folks! In next lesson I'll introduce some more Bcc instructions and maybe some bit operations? G'night.

    I'll post the rest of the guide in the next post.

    TheSonicRetard on
  • LaveLave regular
    edited April 2007
    TSR I was going to leave PA - to get my fucking life in order.

    Then you make this thread, nay cable, damn you and your awesome. Also if you're bullshiting about Rush 2 I'lll still love you.

    Lave on
    poirot1vi.gif
    Scholar and a Gentleman? Critical of bad science and religion? Skeptobot - Is for you!!
  • JimothyJimothy Not in front of the fox he's with the owlRegistered User regular
    edited April 2007
    Okay, at first I was utterly confused and had no idea what this topic was about, but the pictures certainly help. This is very cool.


    Oh, but before I begin, I'd like to take this opportunity to spill the beans.

    Sonic Rush sequel. "Sonic Rush Adventure"

    Sega will announce it in a few weeks, most likely.

    But now I'm confused again. If Sega's announcing it, then it's an official game, in which case it has nothing to do with this topic? And how'd you learn of this, Sega contact?

    If it's a Rush sequel I assume it's for DS, but "Adventure" makes me think it might be for consoles. I dunno, it gives me that "Sonic Adventure 3" vibe, maybe a fusion of Rush and Adventure, like how Super Paper Mario is a fusion of different Mario game styles.

    Jimothy on
  • LewiePLewieP Registered User regular
    edited April 2007
    Jimothy wrote: »
    And how'd you learn of this, Sega contact?

    If it's a Rush sequel I assume it's for DS, but "Adventure" makes me think it might be for consoles. I dunno, it gives me that "Sonic Adventure 3" vibe, maybe a fusion of Rush and Adventure, like how Super Paper Mario is a fusion of different Mario game styles.

    I found it here

    LewieP on
  • fragglefartfragglefart Registered User regular
    edited April 2007
    This, this is incredible.

    New old-school Sonic? Colour me hot for this thread.

    fragglefart on
    fragglefart.jpg
  • brynstarbrynstar Registered User regular
    edited April 2007
    This thread is going to be glorious, like all of your others TSR. I await the rest with great interest!

    brynstar on
    Xbox Live: Xander51
    PSN ID : Xander51 Steam ID : Xander51
  • darunia106darunia106 J-bob in games Death MountainRegistered User regular
    edited April 2007
    Oh, but before I begin, I'd like to take this opportunity to spill the beans.

    Sonic Rush sequel. "Sonic Rush Adventure"

    Sega will announce it in a few weeks, most likely.

    TSR, you are a now a legend among the boards.

    Also about ^. I think I speak for everyone hear when I say: hellz yes

    darunia106 on
    pHWHd2G.jpg
  • Gorilla SaladGorilla Salad Registered User regular
    edited April 2007
    Pro Sonic looks...it looks fucking amazing.

    Gorilla Salad on
  • TheSonicRetardTheSonicRetard Registered User regular
    edited April 2007
    ASM GUIDE PART TWO
    LOGICAL OPERATIONS

    Before we start with logical operations, I will show some more Bcc
    instructions as I promised. Apart from data registers, address
    registers and program counter, there's an another register (last one, I
    promise) called SR (status register). We are now only interested in 5 bits of it, named CCR (flag register). Everything moved to CCR will be copied in the lower byte of SR (this works in reverse). Anyway, CCR

    consists of 5 bits, which are flags. These flags are set or cleared
    when certain thing is being done with registers, or an instruction is
    called. These flags are:

    - C Flag (carry) - 9th bit of adding, shifting and bit rotation.
    - V Flag (overflow) - It'll be set when result can't be represented. Eg. when you add $01 (byte) to $7F (byte), the result is $80 and V flag will be set
    - Z Flag (zero) - Will be set when the result is zero.
    - N Flag (negative) - Will be set if the highest bit of result is set (in two complement it's the sign bit, so the signed negative)
    - X Flag (extended) - A copy of C flag.

    But what these things have to do with CMP and Bcc? In C, this code:

    something == 1

    will return 1 if it's true. Now, when you compare two values, Z flag is set when they are the same or is cleared when they're different. BEQ branches if Z flag is set and BNE will branch if Z flag is cleared. So... BEQ and BNE can be used not only when comparing two values. Look at that example:

    moveq #0,d0

    beq zflagisset

    rts

    zflagisset:

    It will branch, because the result of setting d0 to 0 is 0 and Z flag is set. And BEQ branches if Z flag is set. This comes in handy if you want to test if a number is null or not. Here's a list of Bcc instructions:

    instr conditions flags required

    BEQ Branch if equal Z = 1
    BNE Branch if not equal Z = 0
    BGE Branch if greater or equal (signed) N = V
    BGT Branch if greater than (signed) N = V, Z=0
    BLT Branch if lesser than (signed) N != V, Z=0
    BLE Branch if lesser or equal (signed) N != V
    BHI Branch if higher than (unsigned) C = 0, Z = 0
    BHS Branch if higher or same as (unsigned) C = 0 OR Z = 1
    BLO Branch if lower than (unsigned) C = 1, Z = 0
    BLS Branch if lower or same as C = 1 OR Z = 1
    BCC Branch if carry clear C = 0
    BCS Branch if carry set C = 1
    BVC Branch if overflow clear V = 0
    BVS Branch if overflow clear V = 1
    BPL Branch if plus N = 0
    BMI Branch if minus N = 1
    BRA Branch Always

    = means equal, != means not equal =P

    Enough of these branches, let's learn about bits...

    I really hope you know what bits and bytes are. If you don't, a byte
    consists of 8 bits, which can be either 1 (set) or 0 (cleared). Number
    7 is 111 binary. You can do fun stuff with bits. Eg. the keys pressed
    on joypad are all stored in one byte. Each bit of this byte represents
    a key:

    7 6 5 4 3 2 1 0
    S A C B R L D U

    The lowest bit is up, bit 1 is down etc...

    Now if you want to know if B is pressed, what should you do? You should use the AND instruction.

    AND operation compares all bits of two values and sets a bit in
    a new one if this bit was set in both of the values. I'm not an expert
    of logical operations so you can laugh =P Example:

    Value 1: 10101100
    Value 2: 11001010
    Result: 10001000

    Take a look at this code:

    move.b ($FFFFF604).w,d0 ;$FFFFF604 is the joypad output in Sonic 1

    and.b #$10,d0 ;you could use #%00010000

    beq Bnotpressed

    Imagine we press B, Up and Start. And instruction will look like that:

    SACBRLDU
    Value 1: 10010001 (keys pressed)
    Value 2: 00010000 (and)
    Result: 00010000

    The result is not zero so it won't branch! Nifty, isn't it? There are other:

    or.b #$8,d0

    OR sets the result bit if value 1 bit OR value 2 bit is set.

    Value 1: 00100100
    Value 2: 00001000
    Result: 00101100

    Next:
    eor.b #$24,d0

    EOR sets the result bit if one and ONLY one bit is set in value bits (like x86 xor).

    Value 1: 00101110
    Value 2: 00010100
    Result: 00111010

    And next:
    not.b d0

    NOT clears the bit if it was set and sets the bit if it was cleared. (changes all bits)
    Before: 01001001
    After: 10110110

    And now on with bit shifting. This operation moves bits by an ammount
    to the right or to the left. Eg. we'll shift a value 3 times to the
    right:

    Before: 00101000
    After: >>>00101000

    So after this it'll be:

    00000101

    Bit shifting is fun because one shift to the left multiples a number by
    2 and one shift to the right divides it by 2. The instructions:

    lsl.b #3,d0
    lsr.b #2,d1

    LSL shifts x bits to the left, LSR shifts x bits to the right. There's also bit rotating:

    rol.b #1,d0

    It'll rotate a number one bit to the left:

    Before: 10101010
    After: 10101010
    |
    ^
    01010101

    It works the same to the right. The last part of bits:

    bset #1,d0 ;sets bit 1 of d0
    bclr #2,d1 ;clears bit 2 of d1
    bchg #3,d2 ;changes bit 3 of d2 (like not)
    btst #6,d0 ;test if bit 6 of d0 is set, sets
    ;z flag if it's cleared else clears z flag

    homework:

    move.b #$4,d0
    or.b #$1,d0
    eor.b #$2,d0
    lsl.b #1,d0
    ror.b #2,d0
    btst #7,d0
    bne branch
    rts

    branch:

    Now your homework is to guess if it is going to branch or not. Bit operations are boring at first but you'll get used to them...

    EDITING GAME CODE

    n this chapter we'll learn how to search for wanted code and edit it.
    But before that, I'll show some arithmetic and data functions.

    First, the LEA (Load Effective Address) instruction. It loads an effective address into an address register. You should use this instead of MOVEA. Examples:

    lea ($FFFFFE10).w,a1
    lea ($12345).l,a2
    lea (Label).l,a3
    lea 4(a0),a4
    lea 4(pc),a5

    lea 4(a0),a4 loads the value at a0 + 4 into a4. lea 4(pc),a5 loads PC + 4 into a5.

    You can multiply and divide in 68k (which I didn't know for years, really XD). There are 4 instructions for it: DIVS (DIVide Signed), DIVU (DIVide Unsigned), MULS (MULtiply Signed), MULU (MULtiply unsigned). Examples:

    divu #5,d0 ;divide d0 value by 5 (unsigned)
    divs d1,d2 ;divide d2 value by d1 value (signed)
    mulu #3,d3 ;multiply d3 value by 3 (unsigned)
    muls d3,d0 ;multiply d0 value by d3 value (signed)

    As you know or not, unsigned $FE is $FE and signed $FE is -$2. There's a difference between multiplying by $FE and -$2:

    moveq #4,d0
    move.l d0,d1
    mulu #-$2,d0 ; d0 = $4 * $FE, d0 = $3F8
    muls #-$2,d1 ; d1 = $4 * -$2, d1 = -$8 ($F8)

    As you can see there is a difference. The last three instructions are different from the ones you have seen already. NOP does nothing. It really doesn't XD. It is used to make VERY small delays, to let hardware parts to act. Example (it doesn't do anything):


    move.w #4,d0
    nop ;it really does nothing =P
    moveq #0,d0

    The second instruction is ILLEGAL.
    It's not a real instruction, it's just a random word (depending on the
    assembler, normally TAS.B something) that will cause an illegal
    instruction interrupt (interrupts will be covered later).

    And the last one, DC. This instruction is to store data in ROM. Can be used as DC.B, DC.W and DC.L. I'll better show an example:

    dc.b $12,$24,$31,$21,$21,$31,$31,$12

    ;this will store $1224312121313112 in ROM.

    dc.w $0EEE, $0CCC, $0AAA, $0888, $0666, $0444, $0222, $0000

    ;a random palette ;)

    dc.l $1,$123141,$14144144

    dc.w %1110,1000


    The possibilities are endless. Here's our first real example:

    lea (Palette_Sega).l,a0
    lea ($FFFFFA80).w,a1
    move.w (a0)+,(a1)+
    rts

    Palette_Sega: dc.w $EEE, $EEA, $EE4, $EC0
    dc.w $EE4, $EEA, $EEC, $EEA
    dc.w $EEA, $EEA, $EEA, $EEA
    dc.w $EEC, $EEA, $EE4, $EC0
    dc.w $EC0, $EC0, $EEC, $EEA
    dc.w $EE4, $EC0, $EA0, $E60
    dc.w $EEA, $EE4, $EC0, $EA0
    dc.w $E80, $E00

    It loads the palette address to a0 and the palette address in ram to a1. Copies first color/colour (a0) to the first color in ram, then increments a0 and a1. This really works =)

    Now what I promised - editing the code in the game. Open the Sonic 1 disassembly. Search it for label 'PlayLevel:'. There's a bunch of variable settings (a list of RAM variables is in Guides>Sonic 1>RAM).
    I commented some stuff there. The thing we are interested in is editing
    the lives count. The RAM location that stores lifes is $FFFFFE12. Change it to 4. This would change the starting lives counter from 3 to 4 in game.


    If you understand 90% of what has been written here, then it's good.
    Hell, if you understand 20% of it, it's good XD. Assembler is not easy,
    and a smallest error can ruin all your work.

    "50% of the time spent programming an assembly language is correcting bugs." - an assembly programmer XD

    The more time you spend on it, the better you are at fixing those bugs XD

    The most common bugs:

    1) You MUST put a # before an immediate value (move.b #1,d0) If you won't, this will be treated as an address.

    2) When you move a longword into d0, then a byte, the upper bytes still are there! To clear d0 use moveq #0,d0 or clr.l d0

    3) This is the most annoying bug ever. PC must be ALWAYS
    even. if you insert one byte somewhere, the code after it will be all
    in odd addresses and the Genesis will crash. Also, try to load even ROM
    addresses into address registers, because that can be nasty, too. The
    best method to make sure an address will be always even is to put this
    before it:

    align $2

    or this:

    even

    This will make it always even. But remember, don't put it between the
    code, or it'll give you an illegal operation (it SHOULDN'T, because the
    PC is always even but...)

    You can align as many bytes as you want, eg putting this at the end will make the output rom size be a multiplication of $80000:

    align $80000

    With the knowledge you have (I hope you do) you should be able to find
    and edit the basic things like lives. Remember, the best method to
    learn is to discover everything on your own. Don't rely only on my
    guides, be creative =)

    Next chapter will cover loops and arrays (not C-like arrays...). Have fun.

    LOOPS AND ARRAYS

    Loops in 68k are very limited... Forget about while- or for-like loops ;) For loops, you use DBcc. Usually, programmers just use DBF or DBRA
    (which mean the same). First operand is a data register that will be
    decremented and the second one is a label where to loop if this data
    register isn't -1. Example:

    lea ($1234).l,a0
    lea ($FFFF1234).w,a1
    moveq #7,d0

    Loop:
    move.w (a0)+,(a1)+
    dbf d0,Loop

    This example will go back to the Loop label 8 times (d0 + 1). It's not that hard... I won't show the other DBcc instructions because they are practically useless. Maybe later, when I'll write an instruction list...

    Second part of this chapter will be arrays. Well, I call them arrays,
    but they really aren't. Those are just sets of bytes, words, longwords
    that are readed depending on some variable. For instance, we want to
    load a different music depending on the current level:

    moveq #0,d0 ;clear d0
    move.b ($FFFFFE10).w,d0 ;move level to d0 (00 - GHZ, 01 - LZ etc)
    lea (MusicArray).l,a0 ;load the music values array into a0
    move.b (a0,d0.w),d0 ;see the explanation
    rts

    MusicArray:
    dc.b $81,$82,$83,$84,$85,$86

    I thought 5 damn minutes about how should I explain this XD. The move.b (a0,d0.w),d0 instruction moves a byte at a0 + d0 to d0. Let's examine 3 possibilities (GHZ - 00, LZ - 01, MZ - 02)

    GHZ:
    d0 = 00
    a0 = $1234
    move.b (a0,d0.w),d0
    d0 = (a0 + d0)
    d0 = ($1234 + 0)
    d0 = ($1234)
    d0 = $81

    LZ:
    d0 = 01
    a0 = $1234
    move.b (a0,d0.w),d0
    d0 = (a0 + d0)
    d0 = ($1234 + 01)
    d0 = ($1235)
    d0 = $82

    MZ:
    d0 = 02
    a0 = $1234
    move.b (a0,d0.w),d0
    d0 = (a0 + d0)
    d0 = ($1234 + 02)
    d0 = ($1236)
    d0 = $83

    I hope you get it... This chapter was short but very important, so if
    you don't understand something, read it 10 times =P And you can always
    ask on the forums.

    And that's the basics of 68K ASM. This isn't really all that necessary to understand, and if you don't get it, then don't even worry about it. I'm gonna be posting snippits of the disassembly, but I'll also be explaining their logic in plain english. I included this guide in case people were interested in reading the source a little bit clearer.

    So, again, if you didn't get that and it looks like moon language to you, don't stress out over reading it. It's just for augmentation.

    Now, one final step before we can go on and talk about sonic's engine's inner working... we need to talk about the environment we're gonna be working with. Specifically, I'm gonna give a brief run down of how the sega genesis works...

    TheSonicRetard on
  • PataPata Registered User regular
    edited April 2007
    Yay.

    I eagerly await your discriptions on the abilties of that console.

    Pata on
    SRWWSig.pngEpisode 5: Mecha-World, Mecha-nisim, Mecha-beasts
  • EinhanderEinhander __BANNED USERS regular
    edited April 2007
    God damn it TSR I had things to do tonight.

    Had being the key word.

    Einhander on
  • cj iwakuracj iwakura The Rhythm Regent Bears The Name FreedomRegistered User regular
    edited April 2007
    Sonic Rush Adventure... more Naganuma OST, and I'm there.

    Shoot, I'd be down anyway. Is it made by the same team?

    cj iwakura on
    z48g7weaopj2.png
  • RamiusRamius Joined: July 19, 2000 Administrator, ClubPA admin
    edited April 2007
    So I'm curious, TSR, why do most (all?) of the games developed using the reverse-engineered engine use the Sega graphics? Is there a lack of good artists within the Sonic Hacking community?

    I mean, the image resources and everything must be separate somewhat from the code, why don't the Sonic Hackers make a game in the sonic style, using the sonic engine, but not using any Sega IP? Is the community oblivious about the legal ramifications, or are they aware of them, but just unconcerned about them?

    Ramius on
    1zxt8dhasaon.png
  • PataPata Registered User regular
    edited April 2007
    Ramius wrote: »
    I mean, the image resources and everything must be separate somewhat from the code, why don't the Sonic Hackers make a game in the sonic style, using the sonic engine, but not using any Sega IP?

    Heck, I can answer this. It's the same reason anyone makes a fangame.

    It's because they're Sonic fans and want to make a Sonic game. Not just some game that plays like Sonic, but a game with Sonic in it.

    Pata on
    SRWWSig.pngEpisode 5: Mecha-World, Mecha-nisim, Mecha-beasts
  • EinhanderEinhander __BANNED USERS regular
    edited April 2007
    I think that the more interesting option would be for a Sonic game to be made using new character sprites, as opposed to just using sprites from previous games in the series.

    Sonic and crew have gone through several design changes since the original game, so it wouldn't be that big of a deal from a gameplay standpoint to have a new fan made Sonic game released with original Sonic character artwork.

    Einhander on
  • TheSonicRetardTheSonicRetard Registered User regular
    edited April 2007
    Ramius wrote: »
    So I'm curious, TSR, why do most (all?) of the games developed using the reverse-engineered engine use the Sega graphics? Is there a lack of good artists within the Sonic Hacking community?

    I mean, the image resources and everything must be separate somewhat from the code, why don't the Sonic Hackers make a game in the sonic style, using the sonic engine, but not using any Sega IP? Is the community oblivious about the legal ramifications, or are they aware of them, but just unconcerned about them?

    Some people do make their own graphics:

    cosmicchasm2hg7.png
    palmparadiso20064tj1.gif
    xge3kc8.png
    woodworksingame2it1.gif

    Some even do it the way you're talking about - make a game that plays like sonic, without any reference to sonic. However, most people start their projects with a goal in mind - to make the sonic game THEY want to see made. it's the fan gamers mentality.

    Most just don't care that they're using someone else's IP. It's the same reason people spend hours drawing fan art, or writing fan fiction.

    TheSonicRetard on
  • BantryBantry Registered User regular
    edited April 2007
    Gah! Scarry moonspeak!

    Nevertheless, this thread is awesome. The Sonic Retard, I salute you.
    Oh, but before I begin, I'd like to take this opportunity to spill the beans.

    Sonic Rush sequel. "Sonic Rush Adventure"

    Sega will announce it in a few weeks, most likely.
    Part of me is overjoyed.

    The rest of me is wondering how sega's going to ruin this for everyone.

    The adventure part of the title sugests more playable characters...

    Oh crap they're putting shadow in it.D:

    ... Or I'm just paranoid.

    Bantry on
  • EinhanderEinhander __BANNED USERS regular
    edited April 2007
    I wouldn't mind a DS Sonic game with the exploration aspect from the first Sonic Adventure. I'd dig it even more if it had the 3D gameplay style from Sonic World on the Saturn.

    Enough to buy a DS, anyway.

    Einhander on
  • ObsObs __BANNED USERS regular
    edited April 2007
    It'd be cool if someone expanded the sonic spritework so he was more dynamic. Sonic should move more like a parkour athlete.

    Obs on
  • EvilBadmanEvilBadman DO NOT TRUST THIS MAN Registered User regular
    edited April 2007
    Absolutely intriguing. I hope this thread gets archived as soon as it runs the course.

    EvilBadman on
    FyreWulff wrote: »
    I should note that Badman is fucking awesome
    XBL- Evil Badman; Steam- EvilBadman; Twitter - EvilBadman
Sign In or Register to comment.