Basic Questions and Answers Thread

I believe ValleyBell's SMPSConv is superior to Music Pointer Fixer.
To answer Pacguy's question though, Sonic 2 uses a Z80 sound driver, which uses absolute pointers within a ROM/RAM bank. In order to properly convert the music, you need to supply the -o {offsetval} command, to specify the starting address of the music within the bank.
However, if you're using flamewing's SMPS2ASM, you can find rips of all the Sonic music (including S2B) here.

 

I actually tried looking through Flamewings rips. It appears to be just the final versions rips, and nothing else. As for the -o parameter, how would I figure out what that value is? Some googling, and even fiddling with the disassembly and a hex editor haven't yielded anything that works. I've gleaned that the music I'm trying to convert is at address $FA49E in the beta rom, and I've been reading over this article section on Sonic Retro with no luck. I feel like I'm missing something obvious...

 

While it only gives you the offset of the music pointers (you'll need to scroll to beneath the list of smps types), this article is a good starting point, I suppose.

edit: I can't confirm as I'm not currently at my pc, but I believe smps2asm had a specific parameter for saxman-compressed files? Maybe I'm wrong and it's tied to the program's Sonic 2 format, but I'd say it's worth checking.

 

The pointer is just the music's address shortened to a word value ($FA49E becomes $A49E) and has bit $F set (so if it was $649E, it would become $E49E).

 

You should probably spend a moment to learn about Z80 ROM window and banks. This will help a ton when dealing with anything Z80 related in the future.

 

So $A49E already has bit $F set... using just $A49E or flipping the bit off (making $249E) doesn't generate a usable file in either case. The S2 beta songs are uncompressed by default, right?

I can't find a clear place to learn about that type of thing. Any suggestions? I've mostly just found lackluster wiki articles.

 

Hello I have little question
It has been years since I have done hacking stuff so i just want to be sure, the max level width and height on Sonic 1 is 16384x2048 pixels right?

 

Correct.

 

Yes, that is correct. 64 columns and 8 rows of 256x256 chunks, for a total of 16384x2048 pixels. Sonic 2 has 128 columns and 16 rows of 128x128 chunks, which actually gives the same total size in pixels. Sonic 3 & Knuckles is more variable, able to have more rows or more columns.

 

I hate to be a bother and bring this up again, but I honestly don't see why my approach isn't working; I'm worried I might be using a weird version of SMPS2ASM or something...

So the value I believe to be the correct offset value for the HPZ simon wai beta music (music slot 86 in the beta) is $A49E. It matches what this article says it should be, and is relevant to the rom itself; in the offset table in the rom (located at $F8000, not sure if that's a good name for it) the 6th word has the word $9EA4, which when properly swapped gives back $A49E, which matches the tracks location in rom ($FA49E).

However, I wanted to make 100% sure that I was doing it right, so I decided to double check. This segment of the aforementioned article says that the first word in the song is the pointer to the songs voices table. So, I took the value there ($6AA8), byteswapped it ($A86A), then subtracted $A49E (my predicted offset value). This resulted in the value $3CC. When I went to that point in the singled out .bin file for just the song, the first couple of values there almost perfectly corresponded to the values at the beginning of the voices table in the final song. Obviously, there are differences, but they start out with the same 6 bytes, which I highly doubt is coincidental. Here's a badly made screenshot showing my findings:



Am I missing something painfully obvious? I'm running out of ideas as to what I could possibly be doing wrong. I can't help but wonder if the program is at fault. Again, I apologize for keeping this going so long, I just really want to test out these songs

 

The reason, is because Sonic 2's Z80 has operators 2 and 3 swapped around.

The reason is to do with slot operators. A slot operator is an operator that gets fed into, but doesn't feed into another operator. It is the last operator to perform its envelope transactions before outputting the wave.



Here is a diagrammatic list of all algorithms, the "slot operators" are the ones inside the [ ] brackets. For algorithms 0 to 3, only operator 4 is the slot operator, 5 and 6 have operators 2, 3 and 4 as slot operators, algorithm 7 has all four as slot operators. But it's algorithm 4 which is note-able since it has operators 2 and 4 as the slot operators.

The Z80 version of the driver alters operators 2 and 3 in reverse, this is to ensure that all slot operators are processed together, the idea was to speed up the way the volume is controlled with the slot operators. If the slot operators are all together, then you don't need to program a way of skipping over non-slots to get to them. Ironically, this was reverted back to the original expected way in Sonic 3's Z80, as they found a faster and more efficient solution.

The tool converted the voice correctly, operators 2 and 3 have been swapped around properly as expected, so don't worry.

 

I hate to correct you, but my issue is that the converter doesn't output anything other then header data; all other data, including voices, is left blank. The screenshot shows a comparison between the beta song I'm trying to convert, and the final song in ASM, which obviously is intact and works just fine (since I took the working ASM file as is from my disassembly). I want to convert the beta song. For some reason, when I give SMPS2ASM the correct offset value, it spits out this instead of a functional song ASM. No notes, no voices, it's just header data and a bunch of empty labels

I'm honestly wondering if I should just go through the bother of figuring out how to convert it manually at this point, why isn't this working?

 

I had the same problem. SMPS2ASM has trouble working with offsets other than $8000. MusicPointerFixer is really helpful when it comes to fixing pointers. Just convert it from its original offset to $8000.

In case you haven't used it before, what you have to do is first click "SCAN", choose the music's format, and type in the offset. Then, you choose "S2B/S2F/S3K Fix", click "FIX" choose the format again, and then type the original offset in the first box, and $8000 in the second.

 

That fixed it for me! Thank you so much, I've been unable to find anything about SMPS2ASM or this specific issue on my own

EDIT: Quick question, can you soft reset on hardware? Doing that in emulator can mess up my hack

 

That's another problem I had. It seemed to be from a tutorial I followed which removed the checksum check. I probably followed it incorrectly or something. I replaced the code at GameProgram with the original game's code and that fixed it.

I believe pressing the reset button is a soft reset while turning it off anf on is a hard reset. This is shown by how pressing the reset button with an Everdrive when in-game can return you to the menu where you left off at.

 

Is the 7th status bit (7th bit of $22 in the object ram structure) unused for all objects in Sonic 2, or do some objects use it? I have some big plans, and I need to be able to set a free flag that any potential object could be modified to use. This page says that it's either unused or "unknown". I'm gonna need some certainty on that if I'm going to have any hope of using this flag somewhat universally. If the use cases are limited to specific objects, I'd really like to know what those are

 

Bit 7 is set to indicate that an enemy has been damaged. Additionally, objects with child sprites enabled (bit 6 of render_flags) use offset $22 as sub5_x_pos. There are also several other objects that set bit 7 of the status.

 

Ahhh, so this is a problem for way back via an older post. I was wondering why you didn't mention specifically what the problem was in that specific post. I had to assume it was a voice issue, as you highlighted around the voice data area, and stopped the highlight on a voice in that screenshot, right before operators 2 and 3.

In that case, nevermind, sorry for wasting your time, but I'm glad your issue has now been fixed~

 

I hate to ask the exact same question over again, but is status bit 2 actually unused as well? And where can I find more reliable info on these things? I've been using the Sonic Retro pages for my entire hacking career, but they're clearly outdated...

EDIT: I'm aware that Sonic and Tails use them, but I'm not concerned with player objects

 

Basically I just searched s2.asm for "#7,status(a", which would catch any btst, bset, bclr, and bchg instructions that act on bit 7 of an object's status. Of course, that won't catch move, or(i), eor(i), and(i), or tst instructions, but it's a start.