Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - MathOnNapkins

Pages: [1] 2 3 4 5
ROM Hacking Discussion / Re: Uyjulian's SPC to IT Converter Project
« on: October 05, 2015, 10:42:12 am »
Moderator's Note:
This topic was split off from a different topic that was more general concerning converting SPC files to MOD files. Also serves as a bump because the origin thread is currently higher up.

Moderator's note: This thread had the tail end of it split off into another thread. It can be found here.

Personal Projects / Re: Castlevania Aria of Sorrow spoofs update
« on: September 01, 2015, 06:57:46 pm »
Yes, please update your original thread. You can edit the original post and bump the thread (but don't bump it too frequently please). We don't need tons of threads for the same project / subject.

ROM Hacking Discussion / Re: A question about SNES SPC Data
« on: July 22, 2015, 01:47:37 pm »
SPC files consist of a minimum 256 byte (but could be larger) header meant for music players, a 64 kilobyte savestate of the S-SMP RAM, and a 256 byte savestate of the S-DSP registers. They are laid out in that order in the file. If you don't know, the S-SMP is what is commonly referred to as the SPC or the SPC-700, and it's the microprocessor along with 64K of ram. The S-DSP is another component that actually generates and mixes all the audio output. It's somewhat tightly coupled with the "SPC-700" as a whole. I don't know the specific techniques that people use to dump SPC files, but I imagine it could involve intentional slow down and possibly manipulation of game variables via cheat codes or use of a debugging emulator.

This approach only works, of course, if all of the song's data is held within the APU's (S-SMP) RAM at the time the savestate is stored. There was a small push in the past to rip SNES audio in a formats more analogous to that of the way PSX and GBA music is stored. In such a format, code on both the S-CPU and the S-SMP side would have to be packaged into the image. But again, one would only need such a format for music that needs updates from the S-CPU side after having been put into motion.

The long and short of it is that people doing SPC rips probably don't need to know all the specific information you're asking about, but I imagine for some games it could be of use if things were to go wrong, or they wanted to start the SPC at a specific time index (rewind, essentially). I imagine a lot of people doing rips just figure out enough to get the songs they want to play and then just savestate at an opportune time. Some games also have sound tests, which would make things much easier.

As for how you find music in a game, that could vary somewhat depending on your skill level and skill set. As someone that can debug pretty well, I might just look for writes to the $002140-3 registers and that would tell me at some point when music was being uploaded to the S-SMP.

General Discussion / Re: Crystal Pepsi Comeback?
« on: June 12, 2015, 03:35:29 pm »
I have to wonder if the only difference in the flavor came from the lack of "caramel coloring" or similar. Either way, I remember liking Crystal Pepsi, and not understanding why it has been much maligned over the years. Put me down for a 2-liter, at the very least.

Personal Projects / MOVED: Project Turles
« on: May 14, 2015, 08:16:34 pm »
This topic has been moved to ROM Hacking Discussion.

The topic posted has inadequate material for a personal projects. This subforum has extra requirements, please read the subforum rules, edit your initial post in the relocated thread and contact a moderator to have it moved back once it conforms to personal project guidelines.


Programming / Re: Higan/BSNES issue..maybe?
« on: April 20, 2015, 11:41:36 am »
Set a breakpoint on the place where it should execute into that assembly, and see where it goes. It's possible that the way you have addressed it is faulty. $53:XXXX probably needs to be addressed with hi-rom style addressing. Or not. I really don't know what it should be, as that probably depends on the PCB of Mega Man X3 how memory is addressed. Also, Higan at some point added these XML files for doing memory mapping of the rom and that could be making different assumptions than other emulators. Or the range in question is not included in the XML file so it's just reverting to some default.

I can't say I'm surprised you'd see different behavior across emulators for this type of situation.

This topic has been locked due to thread necromancy. If anyone related to this project would like to reopen it at some future time, please notify a forum moderator via PM.

General Discussion / Re: Pokemon GBA ROM Hack Ranking
« on: February 13, 2015, 03:01:57 pm »
*topic has been closed, as it is a duplicate of http://www.romhacking.net/forum/index.php/topic,19267.0.html*

Front Page News / Re: ROM Hacks: New Final Fantasy 6 Hack: Last Hope
« on: July 14, 2014, 11:48:59 am »
* Topic locked to prevent further necrobumpage. If the topic creator would like to reopen it at some later date, please contact a moderator *

Programming / Re: RDP emulation?
« on: June 16, 2014, 01:42:06 pm »
Oh right, that thing. That explains why your code looks like Open GL code or something similar.

Pages: [1] 2 3 4 5