Basic Questions and Answers Thread

I'm having a bit of a problem figuring out how to add a rotating palette to MZ's lava in my hack.


It consists of four colours with the RGB values:


#1 - C22


#2 - 800


#3 - C40


#4 - C80


In HEX the numbers of the locations are $8 to $B on the fourth palette line.


These are the colours in my palette line I want to rotate.


Below is the code I'm using. It is based off of GHZ's rotating palette code.

Code:

PalCycle_MZ:   		              	; XREF: PalCycle

        	subq.w    #1,($FFFFF634).w  

        	bpl.s    locret_1A80                  

        	move.w    #7,($FFFFF634).w  

        	move.w    ($FFFFF632).w,d0  

        	addq.w    #7,d0                        

        	cmpi.w    #6,d0                          

        	bcs.s    loc_1A60

        	moveq    #0,d0

            rts

I tried tinkering with it to see what the code does, but nothing seems to work. Do you guys see anything faulty with the code? I'm hoping to learn something useful. Yes I added a rotating pallete binary file for MZ and told the ROM to "incbin" it, if you know what I mean.


(I'm sorry if it seems like too much. If it is tell me. I would have also changed the code boxes to ASM boxes but I can't seem to find the button on the new interface. BTW, I also attempted to find the address of "($FFFFF634)" and "($FFFFF632)" but the "Go To" function in my hex editor has a character lock on digit too short. D: )


EDIT: NVM; The "code" boxes display the ASM appropriately I believe.

[/CODE]

 

Yeah, I'm still kinda bad at ASM. Thank you though for helping to explain what each address does and how to work with these obscure patterns of code. In this field I leave a lot to be desired.

 

Hey, don't feel bad, something as basic as palette cycling is one of the best things to start working with when learning the assembly language (and machine itself), I respect people who try something that isn't completely out of their league and work upwards =)

 

I'm attempting to import level art into SonED2 with the help of this tutorial, but this part throws me off.


"Locate the project file in your disassembly and open it using notepad. Use this to track down the individual files for the 8x8's, 16x16's, 128x128's, layout, objects and rings and delete them all."


So I open ghz1.sep with Notepad, but I'm unsure which parts to delete. What are the "individual files" that I should delete?


EDIT: Never mind. I got some help from Tweaker over AIM. Sorry for posting this beforehand.

 

I'm having trouble when I resized a little Marble Zone Act 2.


In my hack, Sonic make a pose after pass through the signpost and then, after the results screen, he starts to walk and go out of the screen...


Well, my problem is that when Sonic go out of the screen, the boss music start to sound for a second or so and then start Marble Zone Act 3 normally....


Any idea of how to fix this?

 

Check when the level number is set. Maybe it's set to act 3 before your animation ends, so when the program runs the dynamic events, it loads the boss because the level's number is 3.

 

The number of the act is not changed until Sonic was out of the screen... My code compare Sonic X position with the right screen limit... when both are the same, then, go to next stage...

Code:

.

.

.

  

[/CODE]

 

It all depends on how your animation is working. If there's a check of some kind to tell the program when the animation is done, you can use that to either check whether the animation is done or not and delay the level number change until it's done, or move the part of the program that changes the level number there.

 

There is no check for that, only the code I showed... any idea of how to do it correcly?

 

Edit: Nevermind its lvl_size.bin, thats been edited.

 

That is already done. My problem is that exactly when Sonic go out of the screen, the boss music start to sound for a second or so and then the song fades out and start Marble Zone Act 3 normally....

 

Same happens with me when loads the 4th act from my Marble Zone. The points counts normally. During the fade out I can listen the boss song so the screen fades to black and next act loads. If it's the special stage, the special stage bg appears glitched. during the special stage gameplay I can see the background glitch. Strangely, it happens only on Marble Zone.

 

Actually I got this error with ghz, but I think mine was a titlecard problem but I got the same bugs as you but for ghz. If only I could remember what I did to fix it.

 

If I enter in the Special Stage everything works correctly at all without any kind of bug. For me it only appears when Sonic goes out of the screen...

 

Hey, I'm back with Sonic 2 badnik porting trouble.


Well, the problem is when I reach to a place where I place the badnik, the game crashes. I even made sure the mappings are in Sonic 1 format. Here's the code:


*code removed*


EDIT: Thanks, vladikcomper. Your "rts" tip worked really well!


I'm so silly for not figuring out before it was the mapping and art loading routine ._.

 

As I see, the ported code is quite not bad comparing to the original one in Sonic 2's disasm.


But few touches and replacements are done pretty roughly. While the code is quite large and object is complicated, this gives many reasons to crash.


Here are few things you should pay attention to:


1) At the very beginning, in loc_37E30, you commented out a branch to LoadSubObject. The object you're using requires some sub-objects, so this may be critical.


2) You replaced jump to DisplaySprite3 with DisplaySprite. The are NOT the same, they do different things. You should port DisplaySprite3 subroutine from Sonic 2.


3) There is a branch to loc_366D6 in your code. That code in Sonic 2 was located somewhere in another object's code. Have you ported it too?


4) Nice to see that you replaced objoff_3B(a0) with common $24(a0). But ensure it's not used by other code for different purposes. In Sonic 2, it could be. $3B(a0) might be used for a reason and, basically, the code will remain work if you replace $24 back to $3B. I can't say if $24(a0) is actually used by something else, just check it out.


There can be even more things to work on. The object you chosen to port is actually pretty hard.


No big port is possible without bugs or crashes in the process. It's normal. Just learn how to deal with them and they will be gone quickly. Know how to debug your code properly. There are many ways and techniques to do it.


For example, you can put a RTS before routines, this way you can see what code crashes the game.


The most powerful way is using a debugger emulator. When the game crashes, check out the processor's stack, it may clearly explain what subroutines lead to a crash.

 

This is something that sounds really usefull... could you explain a little more on how to do this and what emulators to use please?

 

Of course, but first let me tell about good debugging in general. I have been programing in M68K ASM for about 2,5 years already and formulated few techniques for myself. These are pretty helpful for me, and I hope they will be so for others.


First of all, you should enable code listing (please correct me if I named this thing wrongly, I'm quite bad in these terms), so the assembler (or compiler) will generate a LST file for you. This is for Hivebrain's Disasm users, SVN-disasm already has it (but still seems quite messed up for me =\).


To do it, open build.bat file and append this line with ',,sonic1.lst' as shown:

Code:

asm68k /o op+ /o os+ /o ow+ /o oz+ /o oaq+ /o osq+ /o omq+ /p /o ae- sonic1.asm, s1built.bin,,sonic1.lst

LST file is priceless for code debugging as it shows the actual offset of every ASM-instruction in the ROM. Besides it, you can also learn how instructions look like in machine code.



Here is a good use of LST file. When Sonic 1 crashes, it usually displays an error message showing you an offset where the error occurred. You may find that code using LST file. Unfortunately, this rarely helps as ILLEGAL INSTRUCTION, LINE 1010 EMULATOR and LINE 1111 EMULATOR errors are usually caused when the code branches somewhere you didn't expect due to a bug or program error. For example:

Code:

    	moveq    #0,d0

        move.b    $24(a0),d0

        move.w    ObjXX_Index(pc,d0.w),d1

        jsr    ObjXX_Index(pc,d1.w)

    	bra   DisplaySprite

Few comments on last two lines before BRA as many people don't understand them:


MOVE.W moves to d1 a word value from address of ObjXX_Index+d0, where d0 is a value of $24(a0). To get the first word of list ObjXX_Index $24(a0) should be $00, for second word - $02, for third one - $04 etc. That's the reason why $24(a0) is always multiple of 2. The value itself has a form of Routine-ObjXX_Index, read: "Routine offset minus ObjXX_Index offset". I call it a relative routine offset.


JSR jumps to the address ObjXX_Index+d1. Where d1, as you know, is relative routine offset (Routine-ObjXX_Index).


Let's use math!


ObjXX_Index + d1 = ObjXX_Index + (Routine - ObjXX_Index) = ObjXX_Index + Routine - ObjXX_Index = Routine.


Cool right? So JMP jumps straight to routine offset.


Obviously, if you use $24(a0) when there are no 'routines' for them in ObjXX_Index, you will end up with nothing good. JSR will go somewhere we don't expect it to and... crash. Let's talk about it in terms of debugging.


The error message in game will refer to a random place jumped by JSR. That offset won't tell us anything useful.


In this case I would advise to apply some tricks, like cutting off routines using RTS at the beginning of them, but if you want to see an example of using a debugger emulator, here you are!


I generally use these two emulators for debugging:


Exodus


Regen 0.97D (D stands for 'Debug', a special version for debugging)


Exodus I find the most effective and useful, but that's just me. I'm awared of some other emulators like Gens' mods with better debuggers, but this one is enough for my purposes. Exodus is good to see VRAM, debug VDP as well as M68K code. Its only disatvatage is that it's incompleted and emulates really slowly. Regen with debugger is helpful in dumping any kinds of memory as well as previewing VRAM.


A quick debugging example with Exodus:


Open your game, make it crash, then go to Debug -> Main 68000 -> Call Stack, you will see a detailed stack info.


One of the last items should be a call marked as 'Exeption'. In your case it happend when M68K couldn't run instruction and called the vector of the error so the game could parse it. Sonic 1 uses such vectors to display error messages, other Sonic games don't.


Find the list item above the 'exception', the problematic place is close! Display Disassembly window (Debug -> Main 68000 -> Disassembly), switch off 'Track PC counter'. Then you can enter the offsets listed in Call Stack. This can help to find buggy code, again not always. If I had a JMP in my example, you wouldn't find it so fast, because it doesn't store anything in the stack. Also, this kind of code debugging requires good code understanding.


Wow, what a giant post I did. Maybe, I should write a complete guide?

 

Thats some awesome information there, a lot of my debugging is guesswork and experimentation so its good to learn a few more accurate methods.... yes a guide would be awesome.