Basic Questions & Answers thread NEWBIES: Start here!
Posted 22 October 2014 - 02:57 PM
Posted 23 October 2014 - 12:04 PM
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.
Posted 23 October 2014 - 02:13 PM
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
Posted 24 October 2014 - 03:03 AM
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:
Posted 24 October 2014 - 06:45 AM
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.
Posted 24 October 2014 - 09:28 AM
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.
Posted 27 October 2014 - 06:02 PM
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!
Posted 27 October 2014 - 06:57 PM
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:
(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...