Discussion in 'Engineering & Reverse Engineering' started by Tweaker, May 29, 2008.
Uh, another thing:
I just ported the S2 Clone Driver to my hack, but it gives me a lot of errors. I think I did everything as said in the github install guide, I'll just link the whole disasm. Can somebody please help? I have no idea what I did wrong.
Lol, yeah. That guide is weird. I tried to port clone driver in s2 too, but rom hasn't work on most of emulators, and in music has worked only psg channels ○_○
I took a look, and thankfully they are all very simple fixes. First off, it looks like you accidentally included "Sonic-2-Clone-Driver-v2/engine/Sonic 2 Clone Driver v2.asm" twice in the main s2.asm file. Delete the instance near the end, immediately above the include for ErrorHandler.asm.
Secondly, replace all of the jmps and jsrs to PlaySound2 with PlaySound, as PlaySound2 doesn't exist in in the clone driver.
Finally, remove the JmpTo_SoundDriverLoad and SoundDriverLoad labels in s2.asm, as those are equated to SMPS_Setup within the driver's setting file.
That should fix all of the problems preventing it from assembling, but unfortunately it looks like there is a problem with the build script or tools that's preventing it from actually completing the build process: it fails due to some sort of error while trying to run fix_header. That unfortunately is beyond what I am capable of helping with.
It might be because I --'d a lot of stuff in the Lua. It wasn't compiling otherwise.
EDIT: Nope, still doesn't work.
Hello, it's me with a question once again.
I tried porting the Sonic 2 level select to Sonic 1 using this guide, but when I tried to compile it, these errors came out of the console:
> > > s2_menu.asm(125):25: error #1320: range overflow
> > > $FFFFFBA0
> > > lea $FFFFFBA0(A2), A2
> > > ~~~~~~~~~
> > > s2_menu.asm(130):25: error #1320: range overflow
> > > $FFFFFF10
> > > lea $FFFFFF10(A2), A2
> > > ~~~~~~~~~
> > > s2_menu.asm(167): warning #180: address is not properly aligned
> > > move.w #$0000, ($FFFFF7B9).w ; Inicializa o contador das anima******es do men
I tried adding a "even" before the include before EndOfRom, but it didn't work.
Any help please? I know this is like the 4th question I asked in a 48 hour span, but I don't know how to fix this.
...I'm confused as to why that tutorial instructs users to change that $FBA0(a2)" to "$FFFFFBA0(A2)", since the latter is AFIAK not a valid 68K effective address (though if anything this could be an ASM68K vs AS difference exposed by the Git disasm shifting to AS as the default branch). Anyhow, that addressing mode, address register indirect addressing with displacement, is limited to a 16-bit signed displacement (so only up to four hex digits, 32 KB in either direction), which would explain the range overflow. Try removing the $FFFF and see what happens.
The second one is a classic gotcha: you're trying to do a word operation at an odd address, which is not allowed on the 68K. In any case, the offending line is redundant, since the "move.w #$0000,($FFFFF7B8).w" immediately before it will also clear $FFFFF7B9, so just remove it. (Why that mistake appears in the unaltered file is beyond me though).
> ...I'm confused as to why that tutorial instructs users to change that $FBA0(a2)" to "$FFFFFBA0(A2)
I'm to blame for writing that part years ago as I was used to the yee old ASM68K 2005 disassembly back then.
At some point, I should just write the guide mainly focusing on compatibility with all disassemblies and teaching people how to port code straight from Sonic 2 to 1 rather than using Esrael's code which is known for its incompatibility problems on modern hardware and disassemblies. So don't be surprised if this gets reworked on at some point.
In an ideal world it would have been lovely for a 16-bit range to be accepted since... the instruction is treating the index as a 16-bit range word, and it would certainly help aestheticly in some circumstance where ease of use/seeing at a glance would benefit.
Unfortunately the assembler is treating the values internally as a 64-bit double long-word. To appease the assembler you'd have to add another eight F's, i.e:
The alternative is to use the positive value and prefix it with the minus symbol:
I have a feeling the latter is what they expected you to use and they likely used this method in their own programming experience with no consideration for acceptable alternatives.
I also believe the 32-bit version would have worked on a prior 32-bit version of AS, and thus the value range is based on the assembler, not on the language, asm68k has the same problem...
I did it! All I had to do was remove *all* of the music compression part in the .lua and change the Size_of_Mega_PCM_Guess in the Settings.asm, now everything works fine!
Hello, it's me with a question again:
Is there a way, or a guide, to port the sprites from Sonic 3 to Sonic 2 [Is it as simple as just replacing the .bin files]? I tried searching it on Google, but I could not find anything related. If I missed something on the Forums, can someone send me a link?
You can swap sprites through the games, you just need to edit graphics, mappings and dplc format in sonmaped/flex 2 (load as s3 game mode, output as s2 game mode) and use the palette converter for getting best results in graphics look.
Maybe it sounds hard, but actually, it's pretty simple. Btw, don't forget that you need to edit animations, to make it use right frames for animations!
I think it's all. Good luck!
I feel dumb for saying this, but is the ''So, you want to start hacking Sonic?'' forum still relevant in 2023? I want to know what to be studying and what tools to be using, but the page seems to not have been updated since 2008, so I wanted to make sure.
I ported Knuckles using the guide from SCHG, but after replacing the SFX $# things with their SndID counterparts, it now gives me this error.
> > > Knuckles.asm(571):9: error #1320: range overflow
> > > #SndID_Slide
> > > moveq #SndID_Slide,d0
> > > ~~~~~~~~~~~~
Any idea how to fix this?
Change "moveq" to "move.w". Assuming the next error isn't going to be "it doesn't exist" it should be fine.
I thought moveq was different than normal moves so did not think of that. Thanks!
I think the other way to do it is to write
though I could be wrong about this.
Welp, haven't posted here in ages, doubt anyone missed me, but I have returned to the nether once again to ask a simple question-
How does one go about editing Sonic 1's attract mode and credits demo reels? I can edit the start positions easy, but I'm unsure how to give the game a different set of inputs to follow, and the hacking guide doesn't seem to have it...
Either load the demos into a hex editor or convert them to ASM. Every input has two bytes: one for which buttons are held, the other being how long they are held.
Alternatively, you can enable the unused demo recording subroutine and direct the output to somewhere in RAM and then dump the output.
Can you explain both methods to me? I'm torn between them, they both sound like decent ways of doing it.
Separate names with a comma.