Basic Questions & Answers thread

Thanks MainMemory. Initially I still have no idea but that is where the challenge is now that I know what direction to go in and how to approach it. Thanks again.

 

Well, guess what? I have another question (as usual).

Looking at the level select code for Sonic 2, I found a small routine that will write the sound test number when selecting a sfx in the sound test box (loc_965A/LevelSelect_DrawSoundNumber). I do not exactly understand this code, but how can I copy and modify this code so that it will write the copyright symbol on a tile on the VDP at, say, plane tile X,Y? Basically what I want to do is make the game replace a tile with the copyright symbol once a zone is (c)ompleted, since the game is in a loop at the level-select menu. I've seen something similar done with the display of the grade results shown on the level-select in S3&K: The Challenges.

Below is a mockup showing what I want done for my hack

Before zone (EHZ) is completed:


After zone (EHZ) is completed:

 

I suppose this only need to be done as the screen is loaded. If that is the case, we can use a relatively simple method to achieve that. The level select's foreground plane map is decompressed in RAM and stays there as long as the screen is loaded. It is used later on to highlight the currently selected level as you use the d-pad to change the selection. In your mock-up, the X and © symbols are highlighted, so I'll assume that's what you want. We can overwrite some parts of the in-memory plane map before it is sent to VRAM to be displayed.

Code (Text):

1. ; loc_92F6:
2. MenuScreen_LevelSelect:
3.     lea (Chunk_Table).l,a1
4.     lea (MapEng_LevSel).l,a0    ; 2 bytes per 8x8 tile, compressed
5.     move.w  #make_art_tile(ArtTile_VRAM_Start,0,0),d0
6.     bsr.w   EniDec
7.     lea (Chunk_Table).l,a1
8.     bsr.w   LevelSelect_DrawCompletedLevels ; <-- add this line
9.     move.l  #vdpComm(VRAM_Plane_A_Name_Table,VRAM,WRITE),d0
10.     moveq   #$27,d1
11.     moveq   #$1B,d2 ; 40x28 = whole screen
12.     bsr.w   JmpTo_PlaneMapToVRAM    ; display patterns

Add the line indicated above, then add the LevelSelect_DrawCompletedLevels routine somewhere:

Code (Text):

1. LevelSelect_DrawCompletedLevels:
2.     move.w  #$1B,$50*3+$24(a1)
3.     rts

This simply overwrites the 1 (or X in your hack) next to EMERALD HILL with the copyright symbol (tile $1B). $50*3+$24 is the offset from the start of the in-memory plane map: $50 is the number of bytes per line ($28 tiles, which take 2 bytes each), 3 indicates that we want to write on the 4th line (the first line is 0), and $24 is the position of the tile * 2 (because there are 2 bytes per tile). I'll leave it to you to add tests/comparisons and branches and to figure out the offsets for the other Xes.

 

Just another quick question regarding sound porting: why do some of these pointers in the sfx pointer table (@ $1e4000) of MegaMan: Wily Wars (E) point backwards? The pointers should be pointing farther and farther away each time from the base offset $1d8000. I discovered this while running SMPSCalc on these pointers and noticed some extremely large size values for sfx (because it was going backwards).

Look at the picture below to see what I mean:


Is there another rule I need to know about SMPS z80(banked) sound porting regarding these "hiccups"? Or could this be something strange that is specific to MegaMan: The Wily Wars?
I would like to know what is up with that tonight if possible, because tonight I will be ripping MMWW's sfx, and I want to do it right.

 

This is perfectly normal: they point backwards because the data is there. In some cases, this is because of a loop in the music/SFX; on others, they are re-using something (a set of voices, a music/SFX track) defined for an earlier music/SFX. This is also not unique to SMPS z80 (banked or otherwise) either -- SMPS 68k also has it.

For example: in S3&K, the sounds played when you get the fire, bubble and lightning shields use the same FM track data, which is defined only for the fire shield. The other two shields reference this, which mean they "point backward". If you are wondering, the differences between the 3 sounds are timing and instrument changes.

 

Some tools that will help you made by Devster (Joseph Norman).
Check out the rest of his site for some other interesting programming stuff

Some tools:
ImaGenesis 4000 beta
SGTD (Sega Genesis Tile Designer) 0.51 beta
And don't forget SonMapED for importing sprites.

 

Ah the joys of being a newbie! *Laughs* As the Newbie I am, my question is this: How does someone hack a Sonic game period? Now before everyone and their mother yells at me saying I didn't read the Hacking guides, I DID read them. However they may as well be written in Japanese because I don't understand it, hence why I'm here. I've downloaded a ROM of Sonic 3 & Knuckles but what am I suppose to do with it? How do I use these fancy hack programs to hack this Internet downloaded Sonic 3 & Knuckles ROM? May I have help please?

 

The primary and original way to hack a rom file requires a "hexadecimal/binary" editor of some kind, you can find these editors for free by searching the internet. By using a hexadecimal/binary editor you can open the rom and alter the data within in order to obtain different results, the code you'll find in the rom will range from machine code (CPU instructions) to uncompressed/compressed data (art, display, sounds). Of course, knowing where this data is and how to modify it is tricky, there are documents on our wiki that display these locations and some guides to help you understand how to modify them:

http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles
http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles/Art_Editing
http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles/Art_Editing/Palette_Locations
http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles/Object_Editing
http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles/Object_Editing/Pointer_List_1
http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles/Object_Editing/Pointer_List_2
http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles/Object_Editing/Other_Objects
http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles/Level_Editing
http://info.sonicretro.org/SCHG:Sonic_3_%26_Knuckles/RAM_Editing

In todays standards most people tend to use what is known as a "disassembly" which is a deconstruction of the rom binary data into something more easier to change and work with. These will contain the compressed and uncompressed data files seperated into folders of different files, with the machine code data being reversed engineered back into it's mnemonic text form, most disassemblies will also come with programs such as an "assembler" with compression/decompression, aligning/padding and rom header fixing applications, to allow you to repack the machine code, the art/sound files back into a rom for people to play your changes, out wiki also has a page for all of these:

http://info.sonicretro.org/Disassemblies

There are tools also you can use which may help you to edit the data more easily, some of the highly recommended tool are:

http://info.sonicretro.org/SonED#SonED2
http://info.sonicretro.org/S2LVL
http://info.sonicretro.org/SonMapEd
http://segaretro.org/Tile_Layer_Pro?rdfrom=http%3A%2F%2Finfo.sonicretro.org%2Findex.php%3Ftitle%3DTile_Layer_Pro%26redirect%3Dno
http://info.sonicretro.org/RotSprite
http://info.sonicretro.org/PlaneED
http://segaretro.org/The_Sega_Data_Compressor?rdfrom=http%3A%2F%2Finfo.sonicretro.org%2Findex.php%3Ftitle%3DThe_Sega_Data_Compressor%26redirect%3Dno

There are many other tools available which you can use instead of the above list.

 

Now that's what I call a post! It told you exactly what everything is and why and gave links to tools to use to hack the ROM. Thank you MarkeyJester for the post. (I'm sure somewhere down the line I will need more help, but that's a given) but as for the information you've provided it is a MAJOR help. My Newbie senses are tingling *Laughs* due to the joy mind you. P.S. I'll never be able to look at Tom the same way again. *Laughs*

 

Alright, I have just two questions :P.

#1: With the Sonic 2 .svn disasm, is it possible to manually change the titlecards? Just want to know if it is possible before I might needlessly ask Selbi to make a .svn compatible version of his utility, Sonic 2 Text Code Generator. I found a label named "TitleCardLetters" which contains the Title cards:

Code (Text):

1.  
2. TitleCardLetters:
3.  
4. TitleCardLetters_EHZ:
5.     titleLetters    "EMERALD HILL"
6. TitleCardLetters_MTZ:
7.     titleLetters    "METROPOLIS"
8. TitleCardLetters_HTZ:
9.     titleLetters    "HILL TOP"
10. ; And etc.
11.  

Changing the contents of the string after "titleletters", though produces unexpected results. For example, changing "EMERALD HILL" to "TITLE CARD", produces "ETIELCAR D AA" for the Title card in-game. It looks like as if the game merged the titlecards "TITLE CARD" and "EMERALD HILL" somehow.

------------------------------------------

#2: Regarding sfx porting, how does one determine the length of the sfx with backwards pointers?

That still just blows my mind :P. I am trying to port the sfx from MegaMan: The Wily Wars, which has a SMPS z80 (banked) sound driver. I made the (hopefully correct) assumption that each sfx has the length of the difference of the next pointer minus the current pointer, and that each pointer is subtracted by $8000 (since bit 15 is stripped since the sfx is from a SMPS z80 banked game). As shown in my SMPSCalc program while calculating pointers for the game's sfx:

But for those with backwards pointers, I believe my program is incorrect using the current rules

'-------------------------------------------

One more thing, could somebody port the sfx below to relative pointers, just so I can test it in my ROM to see if I extracted it correctly? I don't see any pointers/coord flags at all that would make it not play as-is. Yet it doesn't play once inserted into the hack, nor in a new Sonic 1 disasm. BTW, my hack is using the Sonic 2 clone driver, which accepts relative pointers in songs/sfx. (My laptop, which has the hex editor, is getting repaired, so I won't be able to make the changes myself. Therefore, I will need a download of the modified sfx from said porter)

The sfx:

Code (Text):

1.  
2. 9e 9e 9e 9e 44 00 00 00 00 00 00 85 38 39 8b 8a
3. 8a 8a 8a 8a 8c 00 00 00 00 00 42 43 be bf 8b 8a
4. 8a 8a 8a 8a
5.  

 

These labels change only what letters are loaded; you still need to change the mappings for object $34 for the frame corresponding to the zone in order for it to display correctly.

There is no easy way and, to a large degree, it is a matter of convention. You need to decide whether or not you want to include those parts that are "elsewhere" in the SFX, and stick with that. You can, for example, copy to the sfx the parts that are "elsewhere" and define the length considering this. Or you can do otherwise, and discard any parts elsewhere. And strictly speaking, the length of sfx with non-backwards pointers can be just as undefined by just pointing to a location after a subsequent sfx. The only "sure-fire" way would be to parse the sfx entirely, looking for data in all pointers and making sure to keep track of the highest FM voice used. You then would copy all the data used, including all needed voices (if any) and see the total size. Even this method is flawed -- it would result in some data duplication (any shared voices or shared tracks) and would not work for any sfx that uses any sort of "global" FM voice bank.

It doesn't seem to be a valid SFX. Either that or Megaman has different SMPS headers for sfx that S1/S2/S3/SK uses. Even if you didn't post the sfx header, it still looks wrong as a sfx track -- all those 00's.

 

I already expected stuff like this is going to happen. Looks like the SVN version didn't do it much better than the original version did. =P

As flamewing said, the mappings still need to be re-done, and sadly, those weren't modernized yet (they can be found at Obj34_MapUnc_147BA). It looks like I really need to extend my program, to fully work with everything.

However, even though it's been a while since I worked with that thing (not to mention that I never do stuff on Sonic 2), I'm pretty sure, that you can use the program to generate the mappings, while manually changing the text strings at TitleCardLetters. Technically, the system ain't different.

 

Is it possible to play Sonic 2 music uncompressed in Sonic 2 Z80 Driver? The reason I asked this question is because in Sonic 2, there is a lot of unused RAM that I want to use for testing out new stuff at RAM $F100 - $F5FF. Thanks!

 

Yes it is; to do so, you must make sure that:

1. Any uncompressed song must have absolute (within bank) pointers;
2. for each uncompressed song, you have to open 's2.sounddriver.asm', find the master playlist (label zMasterPlaylist or zbyte_11F5h) and add a +20h to the song's id (see the extra life entry for example).

Oookay... what has that got to do with that? This unused RAM segment is unused -- you can use it for whatever you want, whether or not you are using compressed/uncompressed music. The S2 sound driver decompresses music (and itself) to z80 RAM; this is separate from main RAM.

 

Thanks! I'll give it a try.

Thanks! I don't have to worry about that anymore. I just ported GHZ to Sonic 2 sound driver.

Because of Sonic 1 Sound Driver.

 

For that case, I would like to suggest that you take a look at this post of mine where I explain how to change the S2 sound driver to make it easier to add more songs (due to its poor bank-switching support, which means you can run into size limitations when adding music and sfx).

 

Thank you for that! I will credit you for it too. But I believe that there's more work to be done in s2.sounddriver at location zPlaySoundByIndex. I'm not sure what to do so I'll just test it out.

 

I am working on an enhanced version of that post which I will add to the wiki. If you are using the SVN version of the sound driver file, there are no other changes other than those from my post -- unless you want to completely remove compression for all music, stripping it off from the sound driver. The version I am working on will give choices such as better master playlist that includes speed shoes tempo (I noticed I kept forgetting to add them), an alternate (S3- and SK-style) way to do speed shoe tempo (that doesn't need the mentioned playlist improvement and does away with separate speed shoe tempos altogether), it will modify the value used for 'no song in queue' from $80 (so that it does not need to be taken care of), and maybe even add an option to have relative pointers in z80 SMPS -- I still have to check how feasible that last one would be, but I think it is doable.