Sonic and Sega Retro Message Board: Basic Questions & Answers thread - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 352 Pages +
  • ◄ First
  • 350
  • 351
  • 352
    Locked
    Locked Forum

Basic Questions & Answers thread NEWBIES: Start here!

#5266 User is offline bluemanga 

Posted 15 October 2014 - 11:33 AM

  • Posts: 5
  • Joined: 03-May 14
  • Gender:Male
  • Location:UK
Thanks once again :) seems there's a lot to look into lol. I'll be sure to explore all the things you mentioned.

#5267 User is offline E-122-Psi 

Posted 22 October 2014 - 08:48 AM

  • Posts: 1399
  • Joined: 29-December 09
  • Gender:Male
  • Wiki edits:41
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?

#5268 User is offline flamewing 

Posted 22 October 2014 - 02:57 PM

  • Elite Hacker
  • Posts: 761
  • Joined: 11-October 10
  • Gender:Male
  • Location:Brasil
  • Project:Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
  • Wiki edits:12
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.

#5269 User is offline E-122-Psi 

Posted 23 October 2014 - 12:04 PM

  • Posts: 1399
  • Joined: 29-December 09
  • Gender:Male
  • Wiki edits:41
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.
This post has been edited by E-122-Psi: 23 October 2014 - 12:20 PM

#5270 User is offline MainMemory 

Posted 23 October 2014 - 12:56 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 3195
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
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?

#5271 User is offline E-122-Psi 

Posted 23 October 2014 - 01:36 PM

  • Posts: 1399
  • Joined: 29-December 09
  • Gender:Male
  • Wiki edits:41
Well that's had some effect, now it's just making errors for all lines that branch to Sonic_Load_PLC.

#5272 User is offline pacguy 

Posted 23 October 2014 - 02:13 PM

  • ASM amateur
  • Posts: 9
  • Joined: 27-July 14
  • Gender:Not Telling
  • Location:Nowhere
  • Project:Robotnik Returns, Buizel in Sonic 2, Untitled S2 hack
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
This post has been edited by pacguy: 23 October 2014 - 04:22 PM

#5273 User is offline E-122-Psi 

Posted 24 October 2014 - 03:03 AM

  • Posts: 1399
  • Joined: 29-December 09
  • Gender:Male
  • Wiki edits:41
The guide doesn't seem to mention the example I need. It's a message claiming the code isn't properly aligned:

Sonic_Load_PLC:

		moveq	#0,d0
		move.b	$22(a0),d0



I added an even above the first line of code but it just leads to all cases of this not aligning:

		jsr	(Sonic_Load_PLC).l


#5274 User is offline pacguy 

Posted 24 October 2014 - 03:33 AM

  • ASM amateur
  • Posts: 9
  • Joined: 27-July 14
  • Gender:Not Telling
  • Location:Nowhere
  • Project:Robotnik Returns, Buizel in Sonic 2, Untitled S2 hack
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...

#5275 User is offline Clownacy 

Posted 24 October 2014 - 06:45 AM

  • Needs to make an avatar
  • Posts: 226
  • Joined: 06-July 13
  • Gender:Male
  • Project:Project Sand
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:

SupSonAni_Walk:		dc.b $FF,$77,$78,$79,$7A,$7B,$7C,$75,$76,$FF
SupSonAni_Run:		dc.b $FF,$B5,$B9,$FF,$FF,$FF,$FF,$FF,$FF,$FF
SupSonAni_Push:		dc.b $FD,$BD,$BE,$BF,$C0,$FF,$FF,$FF,$FF,$FF
SupSonAni_Stand:	dc.b   7,$72,$73,$74,$73,$FF
SupSonAni_Balance:	dc.b   9,$C2,$C3,$C4,$C3,$C5,$C6,$C7,$C6,$FF
SupSonAni_Duck:		dc.b   5,$C1,$FF
SupSonAni_Transform:	dc.b   2,$6D,$6D,$6E,$6E,$6F,$70,$71,$70,$71,$70,$71,$70,$71,$FD,  0
	even

; ---------------------------------------------------------------------------
; Sonic pattern loading subroutine
; ---------------------------------------------------------------------------

; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||
; loc_1B848:
LoadSonicDynPLC:

	moveq	#0,d0
	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.
This post has been edited by Clownacy: 24 October 2014 - 06:55 AM

#5276 User is offline E-122-Psi 

Posted 24 October 2014 - 09:28 AM

  • Posts: 1399
  • Joined: 29-December 09
  • Gender:Male
  • Wiki edits:41
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.
This post has been edited by E-122-Psi: 24 October 2014 - 11:24 AM

#5277 User is offline KingofHarts 

Posted 27 October 2014 - 06:02 PM

  • Amigo
  • Posts: 1379
  • Joined: 07-August 10
  • Gender:Male
  • Location:CHICAGO, IL
  • Project:Finding a job, Sonic Triad Studio, Sonic 1 REV C
  • Wiki edits:1
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!

#5278 User is offline MarkeyJester 

Posted 27 October 2014 - 06:57 PM

  • Driving The Last Spike
  • Posts: 1535
  • Joined: 22-July 08
  • Gender:Male
  • Location:Japan
  • Wiki edits:16
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):

		moveq	#0,d0
		move.b	($FFFFFE10).w,d0
		add.w	d0,d0
		move.w	Deform_Index(pc,d0.w),d0
		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:

Deform_Index:	dc.w Deform_GHZ-Deform_Index, Deform_LZ-Deform_Index
		dc.w Deform_MZ-Deform_Index, Deform_SLZ-Deform_Index
		dc.w Deform_SYZ-Deform_Index, Deform_SBZ-Deform_Index
		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:

		jmp	Deform_Index(pc,d0.w)

Into:

		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:

		moveq	#0,d0		; <<<---- Clear long-word of d0 (entire register)
		move.b	($FFFFFE10).w,d0
		add.w	d0,d0
		move.w	Deform_Index(pc,d0.w),d0
		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...

  • 352 Pages +
  • ◄ First
  • 350
  • 351
  • 352
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users