Small request if possible, since the 2P zone names, Options screen text and the credits text can be changed easily in the asm file, would you be able to implement a system for the Level Select text?
That could be potentially confusing for someone just glancing over the code though. Apart from that, if we could also agree on some sorta common name templates that'd be good. For example, Xenowhirl uses XXX_SwitchTbl, XXX_States, XXX_subtbl, and possibly others for jump tables, while Hive just uses XXX_Index for everything. I personally like Hive's system more. It is possible, but it'd be very hard to do since the text is stored as an Enigma-compressed plane map. It's probably a better idea to have an external program which can uncompress the plane map, convert it to text form, and then re-convert the edited text file back.
<!--quoteo(post=233729:date=Oct 10 2008, 06:44 PM:name=SOTI)--><div class='quotetop'>QUOTE (SOTI @ Oct 10 2008, 06:44 PM)
<!--quoteo(post=233733:date=Oct 10 2008, 11:00 PM:name=nineko)--><div class='quotetop'>QUOTE (nineko @ Oct 10 2008, 11:00 PM) [/quote] That would be quite awesome
I agree, for nameless temporary symbols, it is cleaner not to keep the old label. A few times JmpTbl_ is used as prefix. Even though it might be useful to easily distinguish between jump tables and data pointers, I guess it's best to simply use _Index as suffix. Now that looks interesting. Does it support different plane sizes (I.e. not only 40*28)? Also like the existence of the option "show pure hex". Feeding it with 8x8 tiles and displaying these would be a bit too much to ask I guess though...
<!--quoteo(post=233811:date=Oct 10 2008, 11:36 PM:name=qiuu)--><div class='quotetop'>QUOTE (qiuu @ Oct 10 2008, 11:36 PM) The same Level Select as above, in hex mode. <!--quoteo(post=233811:date=Oct 10 2008, 11:36 PM:name=qiuu)--><div class='quotetop'>QUOTE (qiuu @ Oct 10 2008, 11:36 PM) Now, we're going offtopic here, this is Sonic 2's split disassembly thread. Please let's not talk about my level select editor here anymore, I will start a proper thread in E&RE when the time comes.
It's possible to have a macro convert nonstandard text strings from ascii. I've dropped the "Obj01_" prefixes from Sonic 1. The only reference to object numbers I've left is in the names of the object asm files (and the object layout itself, which can't easily be changed).
Yeah, and it's done a lot of places already in the disasm (off the top of my head, intro text, credits text, 2P zone names, options text, title card letter selection text). The problem here is that the data is being compressed after conversion, so implementing it in the disasm itself would probably require modification of s2p2bin, similar to what Xeno had to do to get the sound driver working. Speaking of this, any chance of posting some of the new labels from your S1 disasm, so we can get an idea of what sort of names you've been using?
Or you could put it in a separate file, and in build.bat, assemble it separately, compress it, and incbin/binclude it.
I'd like to suggest what I consider an "improvement" to declare the labels for the RAM variables. I just tested this and I was quite surprised that it worked, but before making the change, I want to get some opinions. Here's how the last few RAM variables are currently declared in the disassembly: Code (ASM): Demo_mode_flag = ramaddr( $FFFFFFF0 ) ; 1 if a demo is playing (2 bytes) Demo_number = ramaddr( $FFFFFFF2 ) ; which demo will play next (2 bytes) Ending_demo_number = ramaddr( $FFFFFFF4 ) ; zone for the ending demos (2 bytes, unused) Graphics_Flags = ramaddr( $FFFFFFF8 ) ; misc. bitfield Debug_mode_flag = ramaddr( $FFFFFFFA ) ; (2 bytes) Checksum_fourcc = ramaddr( $FFFFFFFC ) ; (4 bytes) And here's another way to declare them: Code (ASM): phase $FFFFFFF0 Demo_mode_flag: ds.w 1 ; 1 if a demo is playing (2 bytes) Demo_number: ds.w 1 ; which demo will play next (2 bytes) Ending_demo_number: ds.w 1 ; zone for the ending demos (2 bytes, unused) ds.w 1 Graphics_Flags: ds.w 1 ; misc. bitfield Debug_mode_flag: ds.w 1 ; (2 bytes) Checksum_fourcc: ds.l 1 ; (4 bytes) dephase !org 0 Notice how the unlabelled variable is easily noticeable. I believe this method would be better because we don't have to type the addresses for every variable. Also, it makes it easy to give several labels to the same location (this would be useful for *_End labels, amongst others). However, I only tested this as well as Chunk_Table and Level_Layout. I don't quite understand the problem ramaddr tries to solve, but if this method makes it happen again, then we won't be able to use it.
Yeah, that'd work perfectly for this case, dunno why I didn't think of that. Obviously the sound driver needed to reference addresses in the main ASM file so it couldn't be used for that though. Eh, I don't really like it, it makes it less obvious what the real address is (although it does enable the size of the variable to be read off at a glance). About ramaddr, it's used for stuff like this: Code (ASM): cmp.w #MainCharacter,a0 Without ramaddr, MainCharacter would be taken as $FFFFB000 and AS would complain about it not fitting in a word (you'd have to use MainCharacter&$FFFF instead). With ramaddr, the equate gets internally converted to -$5000 (I know $FFFFB000 and -$5000 are exactly the same thing in 32-bit mode, but AS isn't smart enough to figure that out apparently), so AS can easily shrink that into a word, and you don't need to AND by $FFFF each time you want to use the word-sized form of a RAM equate.
Woah, AS failure o_o; Anyways, I guess that works better for new programs rather than for disassemblies that need to be exact =P
I thought I could add a comment about how to use the MESSAGE directive to show the address of a variable at build-time. As for unlabelled variables, we should put the address in a comment, because it's most likely they're the ones we'll be looking for. I think AS can use 64-bit integers internally, so that would explain why it doesn't work. We would either have to use a negative number (and only this number would be written as a negative number) or a 64-bit number (probably not portable, and not very intuitive) with PHASE, unless ramaddr itself works with PHASE (and I can't see why it wouldn't). Code (ASM): phase ramaddr($FFFF0000)
Double post, because I really want this stuff in. I just tested with those problematic variables: using the current equates, I tried to remove the use of ramaddr in Object_RAM and it gave me errors (as I expected). Using phase with or without using ramaddr works. I'll leave it anyway, in case the problem reappears on other systems.
Looking at it again it's sorta grown on me (well technically IDA does the exact same thing in a RAM segment but the addresses are prefixed to each line so I didn't notice that much), so I'm cool with having it in. The only real issue I can see with it is that it makes relocating a single variable harder, although on the other hand it makes swapping variable blocks (as was done in S&K for a few variables) much easier.
I just tried to commit the work I did on the Monitor code and there's a conflict in s2.asm, s2.constants.asm and changelog.txt. What should I do?
If you're using TortoiseSVN, read section 5.6 (Daily Use Guide > Resolving Conflicts) of the help file (accessible from the Start Menu). You may also want to read TortoiseMerge's help file if you don't understand how it works. Don't forget to mark the conflict as resolved when you're done.
It might be a good idea to split s2.asm up, to help avoid this kind of thing (also to improve readability).
I've been thinking about splitting that file, but that won't really help fix the conflicts, as they usually happen when 2 or more people changed the same line(s).
