Sonic and Sega Retro Message Board: Erik JS - Viewing Profile - Sonic and Sega Retro Message Board

Just something interesting I found inside the EXE file of the demo version of Need For Speed: Carbon (EU). I opened nfsc_demo.exe in a text scanner and I found what looks like function names; I don't know how they work exactly but their effects are plain obvious judging by their names. They start at 0x005DDA60.

One which caught my attention is at 0x005DE4AC, EnableBarriers, which probably is what creates a "neon wall" in order to prevent the player from going out of the course during a circuit race. My idea was to get rid of it so I could go out of course and explore the scenario a bit more. The first method I tried was replacing that string with 0's. It didn't work. Then I tried to overwrite it with DisableBarriers (0x005DE514); it has space enough for that but also fails. I was able to locate the pointer for such string, it's at 0x0026B255, I tried to redirect it to DisableBarriers but it failed too. Also, with the help of a disassembler I tried to nop some instructions, but everything goes the same as always (at the end of countdown, the game crashes). Since my knowledge about x86 ASM isn't that big, I already ran out of ideas.

Is there anyone able to help me on this? Or anyone who has some experience with this regarding NFSMW (as those strings appear there too)?

http://www.gamershel...oad_16011.shtml

I hadn't any luck with this, but one friend of mine already downloaded it and sent me the requirements:

Quote

I'm not impressed with such requirements, but that's good, so most of us will be able to play this.

Also, my friend said that the installer has a bug. It requires 764MB of free disk space, but as you click 'Next' the program will show an error message if the selected drive has less than 7640MB (7,4GB).

It's available at GameSpot too, but download speed is bad for free accounts. Post other download links if you find them.

I worked on this some time ago, and I just begun working again since last week. As the name says, this tool fixes pointers from coordination flags F6/F7/F8. The original project started with only S2-3K in mind, but now it supports S1, doing little-endian/big-endian conversions. Features like "Ristar to S1" and voice fixing for S2 were implemented as suggested and oriented by Tweaker and R. Solaris, so they get credit for this tool.

First you'll have to extract a music from a Sonic game and save it as .bin or .dat (you can get music locations here). Then open the file and fill the address list with locations of pointers from coordination flags F6, F7 and F8. You have the choice of using the SCAN button for that, but remember that it's not 100% accurate. Once this is done, just pick one of the five kinds of conversion available and hit the FIX button, which will ask you for a new filename for saving.

WARNING: This program was made under Microsoft Visual Basic 2005, so you'll need to have .NET Framework 2.0 installed on your computer. Controls use Windows XP visual styles, so the program's look may vary from computer to computer.

EDIT: Link updated
http://www.fileden.com/files/2006/8/15/169...ointerFixer.rar

In sometime between January 6th-7th I figured out the format of pointers to 68K banks. As you can realize from Tweaker's guide, banks are always multiple of $8000, and there's nothing in 68K to change them. That's because they are stored in Z80 RAM. I disassembled S2 sound driver and I can tell you, for instance, it's nothing like setting a variable to $1F that'll make Z80 acceess bank stored as 68K's $F8000 ($8000 x $1F). I got the Sega2f doc, and it only helped to find the actual Z80 address that does bank switching. The explanation there, though, wasn't in English for me. :P

First, let's put straight how music is accessed in S2. 68K code sets a RAM address ($FFFFFFE4) to have the value of the desired music. Somewhere else, one of those permanent functions checks that address to see if it has changed since last time. If so, it writes the music value to Z80 RAM ($A01B88). This last step involves more than a single move.b d0,$A01B88, because it's needed to stop Z80 processing before attempting to handle its data. After that, 68K makes Z80 resumes its operation. Z80 also has a constant function which checks to see if 1B88h is something but $80 (no music). Depending on that value, Z80 switches bank in order to play musics ($F8000), continue music (if $9C; F0000) or sound effects ($F8000). The bank is nothing but a space of $8000 bytes that is mirrored from a certain 68K memory space, so that's why music pointers in S2 are little-endian.

The bank switching, as said previously, isn't done by a single value assignment. On the other hand, it's done by a single memory address, which happens to be $A06000, or just 6000h for Z80. That's exactly what's written in Sega2f document:

Quote

What such masterpiece of English language is saying is that bank is determined by a sequence of 9 values written one after other to 6000h. It sounds strange, but it works, believe me :P. Now, why is it a sequence of 9 values? As banks rely on multiples of $8000, it was not hard for me to fugure what they mean. Heh, they're indeed bits, and as you know (I hope), a bit can be one out of two values: 0/1, yes/no, true/false, etc. So they're nothing but a bunch of flags for the following bank values:
$8000
$10000
$20000
$40000
$80000
$100000
$200000
$400000
$800000

Sum everything and you'll have $FF8000 which is the hightest bank Z80 can access (and also the last $8000 bytes of Genesis memory). Yes, Z80 can access 68K RAM, but I don't see any practical use for it, as it would limit working space for 68K. I'm not sure about 68K SRAM, but it should be accessible too.

So how S2 sound driver does bank switch? It's actually something weirder than a "move.b #1, 6000H", but it follows such pattern. Let's see part of a Z80 disassembly from S2:

00000C79: AF  XOR A
00000C7A: 1E 01  LD E,01h
00000C7C: 21 00 60	LD HL,6000h
00000C7F: 73  LD (HL),E
00000C80: 73  LD (HL),E
00000C81: 73  LD (HL),E
00000C82: 73  LD (HL),E
00000C83: 73  LD (HL),E
00000C84: 77  LD (HL),A
00000C85: 77  LD (HL),A
00000C86: 77  LD (HL),A
00000C87: 77  LD (HL),A

This is always used for bank switching in S2. This part refers to the bank for musics but continue ($9C). LD (HL),E does the role of 1 and LD (HL),A does the same for 0. In byte terms, 73 is 1 and 77 is 0, for this case (and the rest of S2 sound driver). If you align that with the bank values you'll get $F8000, which is where music is stored in S2. During the Z80 halt in 68K code, before writing the value at 1B88h, you can put a check to see if certain condition is true, so you can alternate between one bank or other in order to play more musics than $1F - you still use the same values for music; the use of unused values like those after $70 in Sound Test is possible, but it requires Z80 reprogramming which I'm not able to do with my current knowledge, plus this method is enough for all S2 hacks that demands more musics.

Using the code shown above as "guinea pig", here's the code for a little music hack I did:
http://www.sonicforc...S/soundplay.txt - the code was compiled and inserted into unused space in ROM, and in $1084 I put a jmp «code location».
http://www.sonicforc...JS/soundfix.txt - this is a fix for when musics are played through FFE2 due to SEGA's bad programming, because the funtion at $1376 is supposed to play SE. This will redirect sound requests lower than $A0 to 135E. Just compile and put a jmp «code location» in 1376. If this fix is not applied, sound $98 will fuck up at certain events when new music is playing. The previous code only sets bank when music is requested at FFE4. This isn't a bad fix, because you can't hear two musics at the same time anyway. :P
http://www.sonicforcecorp.talkhost.info/Er...s2musichack.rar - the ROM, with a new music for testing. First, play all songs from 01 to 1F in Options screen to make sure every original is still there. Then, enter DEZ by any way, or set level RAM address to 0E and play music 0A.

Now, here are the locations for all groups of 9 flags that serves to bank switching:
009Ah: SE
00D2h: DAC
062Ch: SE
06FAh: SEGA
097Bh: SE
0C6Fh: Continue
0C7Fh: Musics
0F3Fh: SE

If you want to make permanent changes in bank switching (in order to reallocate music), do the following:
- decompress sound driver with SDC;
- using a hex editor, go to a flag group location and change them;
- recompress the edited sound driver using SDC;
- put the new compressed sound driver back into the ROM, overwritting the old one in $EC0E8;
- fix the size of compressed sound driver at $EC050;

Side info:
- Z80 RAM's 0000-1FFF is 00474-02473 in GST savestates;
- You can use Korama's GSavestate for easy editing of Z80 RAM;

Special thanks to (no particular order):
drx - hosts Sega2f doc - http://www.hacking-cult.org
R. Solaris - helped me figuring out the meaning of bank switching in Sega2f doc
Tweaker - great music guide, plus sent me a music to test my sound driver experiments
M' (aka Kusanagi) - Portuguese friend. He gave me webspace at Sonic Force Corp.
MSN contacts who played my music hack and didn't leaked it (you know who you are)

I haven't found a collision viewer anywhere, so I deducted that one should be made. Sonic Collision Viewer (aka SCV) is a program that allows you to see the structure of collision boxes in Sonic games, so you'll be able to assign collision indexes easily to new 16x16 block mappings.

The idea of making this program came after a chat with Yuski the Dog. He, like me, was complaining about the lack of a collision viewer for Sonic games. At the first time, I really hadn't any idea how I could make such program. After finding out that a bunch of TextBoxes was a stupid idea, I worked hard on trying to get the PictureBox to do something. Fortunatelly, I learned how to use the PaintPicture method, and then the dream of the collision viewer was coming true.

EDIT: newest version uploaded
http://geocities.yah...br/scv1.0.3.zip

Special thanks to Esrael, Nemesis and JoseTheBest. And Yuski.