I don't have time to look at it in detail at the moment, but I've just remembered there's another flag in Sonic 2 that allows you to lock the controls. It's used whenever Sonic is under the control of an object such as the tubes in CPZ. See if you have better luck with this: Code (ASM): move.b #$81,obj_control(a0) ; lock controls clr.b obj_control(a0) ; unlock controls If your disassembly doesn't have the obj_control label, use $2A(a0) instead.
Question One: Many of the SCHG How-to's make reference to misc/muslist1.bin / misc/muslist2.bin, but it does not seem to be present in the Community SVN. I think it's part of the main .asm, but I'm just looking for confirmation here, as following this how-to seems to rely on changing some values in that data in order for the rom to build properly. Question Two: While following this tutorial/how-to, I have now found myself unable to successfully build, as it gives me an error: Code (Text): Op-code not recognised psgn_1: binclude sound/psgn1.bin and for all the sound files the guide tells me to get, and I have no idea how to fix it. (The build process actually aborts due to too many errors.) I think it's because the pointers have been changed, but I'm still kinda new at asm, so that's why I'm posting here.
Answer One: This has been discussed once before though I cannot find the topic explaining, I do assume they're working on possibly a second guide for SVN as well as the older predecessor disassemblies. Answer Two: Change "binclude" to "incbin", if the assembler you're using is "asm68k", then it'll feature "incbin" rather than "binclude".
Ah, that did it. Unforunately, it then spawned another 250 or so errors, "not defined" for all the sound files and indexes that are used in all of the split files. If the guide told me what I was doing, rather than how to do it, I'd probably have a better idea of how to fix it. I might clear out everything I've done on this, and do some other stuff first, because this isn't going so well.
May I ask what you are trying to do in the first place? Sounds like you want to add a new sound driver.
Yeah, I was following the guide to port Sonic 3's sound driver into Sonic 1, but much errors were had. I've restored from a backup, and have started working on other stuff for now. Since the guide is mostly "Find this, replace it with this" a hundred times, provided I find out why it was getting all antsy, I can just do that later.
Well, did you ever download the driver files and put them in the folder it requires? I got my custom version of the S3 driver working fairly well in Sonic 1 No-Name. And not to be offensive to anyone, but the SVN disassembly isn't really that great. Well except those equates, they are kinda helpful at times, but that's it for me.
Yeah, I did download the driver files. And the svn is what I was pointed to, so that's what I used, though the other does seem to be a be a bit more useful for following the how-tos. Since you said you got it working fine, though, I tried again, but still got the same errors. Just a bunch of: Code (Text): \_INC\LEVELHEADERS.ASM(20) : Error : Symbol 'musicindex' not defined \_INC\LEVELHEADERS.ASM(20) : Error : Symbol 'ptr_mus81' not defined \_INC\LEVELHEADERS.ASM(21) : Error : Symbol 'musicindex' not defined \_INC\LEVELHEADERS.ASM(21) : Error : Symbol 'ptr_mus82' not defined \_INC\LEVELHEADERS.ASM(22) : Error : Symbol 'musicindex' not defined \_INC\LEVELHEADERS.ASM(22) : Error : Symbol 'ptr_mus83' not defined \_INC\LEVELHEADERS.ASM(23) : Error : Symbol 'musicindex' not defined \_INC\LEVELHEADERS.ASM(23) : Error : Symbol 'ptr_mus84' not defined \_INC\LEVELHEADERS.ASM(24) : Error : Symbol 'musicindex' not defined \_INC\LEVELHEADERS.ASM(24) : Error : Symbol 'ptr_mus85' not defined \_INC\LEVELHEADERS.ASM(25) : Error : Symbol 'musicindex' not defined \_INC\LEVELHEADERS.ASM(25) : Error : Symbol 'ptr_mus86' not defined \_INC\LEVELHEADERS.ASM(26) : Error : Symbol 'musicindex' not defined \_INC\LEVELHEADERS.ASM(26) : Error : Symbol 'ptr_mus86' not defined As I said, for what seems to be all the sounds and music. I still need to find the equivalent of muslist.bin in the svn, too, which is the last step before it supposedly works properly.
The music list is no longer a separate file, and uses constants as defined in Constants.asm. Check the data at labels MusicList and MusicList2.
Where in the 2007 S2 disasm does it set the character's height after jumping onto an object? Because for some reason Amy gets Tails' height...
Trying to edit Sonic and Tails on the Sonic 2 title screen...but I can't find the mappings file when trying to open it in SonMapEd, which file is it? (Using the 2006 Disassembly)
Tried both, it leaves the player running on the spot after performing the attack. Not sure about the 2006 dissassembly but the title screen uses plane mappings that won't open in MapEd, your best chance is either use PlaneEd or edit the tiles by predicting the mapping placement on MapEd (oh a few blocks of Sonic are in another graphics tile file I think it's A Few Menu Blocks or something similar. Not sure if that has a mappings file either though keep in mind while editing the titles).
Hmm...looks like I'm gonna need to figure out how to get PlaneEd to work then..XD Thanks for the info
Probably a rather silly problem, but I'm using the SVN disassembly of Sonic 1, and every time I make a significant edit "s1built.bin" disappears and all that's left is a "sonic.lst" in its place. Maybe it's my fault for using the SVN version in the first place, but what's going on?
While I'm not sure myself (Being one who does not use the SVN versions), I would assume that "sonic.lst" would be a list of errors in your source code, maybe try opening that file with a text document editor of somekind, something like a simple notepad and see what's inside.
^ Actually you can't open it in a text editor, but I opened it in a Hex editor. It looks like it contains the data from the disassembly, but look for errors.txt to see the list of errors, or build the ROM using Command Prompt if you don't have a error list.
I solved it; SonMapEd seems to output its mappings files (what I was doing when this happened) with no formatting and with a bunch of garbage, I.e. in a way that the SVN disassembly can't properly read. All I had to do was format it and make it line up with the original mappings code. Sorry 'bout that.
Right, so in Sonic 2 the EHZ Boss is Object 56...in the 2006 disassembly there are three files for it's mappings...56_a, b and c...I've tried loading each one in SonMapEd but it's still not loading the mappings...Will this be another case of guesswork? Or can I get it to load them properly?
I've fixed this myself. For anyone adding characters to Sonic 2, you need to go to Sonic_ResetOnFloor_Part2, and make it look like this: Code (ASM): Sonic_ResetOnFloor_Part2: ; some routines outside of Tails' code can call Sonic_ResetOnFloor_Part2 ; when they mean to call Tails_ResetOnFloor_Part2, so fix that here _cmpi.b #1,0(a0) ; is this object ID Sonic (obj01)? beq.s + ; if so, continue _cmpi.b #$4C,0(a0) ; is this object ID Amy (obj4C)? bne.w Tails_ResetOnFloor_Part2 ; if not, branch to the Tails version of this code bra.w Amy_ResetOnFloor_Part2 + btst #2,status(a0)
My brain tells me, I knew the answer at some point. However, I'm pretty sure I don't know it anymore. Basically, what I'm asking, why is there a "Tails got through" and "Miles got through" text in Sonic 2? Just played EHZ 1 with Tails only to see which text he displays me (because I never really looked at it) and it was the Tails one. Is the Miles one unused or what's its usage?
