logo
 drop

Main

Community

Submissions

Help

103871513

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
4
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.

5
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.

8
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.

http://www.romhacking.net/forum/index.php?topic=19727.0

10
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.

11
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.

12
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*

14
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 *

15
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.

16
Programming / Re: RDP emulation?
« on: June 16, 2014, 11:25:29 am »
Since you provide no frame of reference, can you tell me what RDP you're talking about? I assume it's remote desktop protocol, but I don't understand why you would refer to this as "emulation"...

17
ROM Hacking Discussion / Re: Thinkin about starting my own FR hack
« on: May 20, 2014, 10:22:11 am »
My guess would be Pokemon Fire Red.

18
- This topic has been closed at the request of the TC. -

19
As a note for anyone happening by, translation requests belong on this wiki article, not forum posts: http://datacrystal.romhacking.net/wiki/Translations_Request_List

20
Programming / Re: Extremely Confused on VRAM Issue
« on: August 17, 2013, 01:51:14 pm »
It does not log DMA transfers the way that Geiger's does, for example. However, you can set read / write breakpoints on vram in BSNES at which point it will break in the middle of the DMA transfer (continuing to "step into" I believe will remain in the dma transfer until all bytes have been written or read, then the S-CPU will resume stepping). Keep in mind I use a relatively old version of the BSNES debugger (v0.67 so the available features and dynamics might have changed).

Pages: [1] 2 3 4 5