Language…
17 users online:  AmperSam, Cardioid, DanMario24YT, Dark Prince, DasFueller, Green, GRIMMKIN, Kwat1, Rykon-V73, Serena,  Shoujo, Skewer, SMW Magic, Tulip Time Scholarship Games, vktr, W3aper,  yoshi3706 - Guests: 311 - Bots: 471
Users: 64,795 (2,373 active)
Latest user: mathew

Posts by Kil

Kil's Profile → Posts

Originally posted by Ersanio
Quote
Mario's control RAM

Do you mean $15-$18? If so, interesting... If this truly doesn't have side effects I might consider updating LevelASM in the patches section once again.


I truly think you should. I've already manually moved the one in my rom and it got rid of a lot of hassles.
Apparently marioexgfx and sample tool (overworld routine) both hijack from the same spot so one of them will break, but I think it may have been fixed in the latest version of marioexgfx.
Even if your overworld has no samples, samples from a level will carry into the overworld if that hijack gets overwritten, but if you're not using the new version there won't be any problem so whatever.
If you're using custom music for the level, you can't switch to any of the vanilla songs normally. The song "01" dwon't exist in the sound ram at that time.

If that's not it, who knows.
In what way is the music crashing for you? From what I've tested, the main causes of addmusic music crashing in accurate emulators are

1. Echo never gets turned off.
In vanilla smw when you die or complete the level, the normal death/goal music (and a few others) sets the echo LR volume to 0. This stops the echo that still exists in the buffer. I don't remember the details exactly since it's been a few months, but when you change songs, the sound left in the buffer can end up playing eternally. The only way I've found around this is to have every song start off by setting the L&R echo volume to 0.

SMW's only vanilla song with echo is the cave music, so it seems they didn't really code the spc engine to prevent this.

By the way, here's the exact echo command used by the cave music which you could find by digging around a bit in the music data. I use it by default since it seems to cause the least amount of problems and sounds decent.

Code
$EF $F6 $21 $21 $F1 $04 $6C $00 $F2 $DC $15 $15
Remember to change the $F6 to reflect the channels you want echoed though


2. Some versions of addmusic store stuff in the echo ring buffer space because... they're bad?
According to some japanese info http://d.hatena.ne.jp/GOCHA/20070428/smwmusicspec , some versions of addmusic actually store data in the $6000 area, which will be destroyed as soon as echo starts. With carol's addmusic, you're probably fine.

3. Echo delay too big.
You don't appear to be having this problem.

4. Bad percussion commands
I haven't had a chance to look into this one too much, but I noticed that using the percussion instruments in certain ways crashes the music instantly.


By the way, if you can't find the problem, do you want to send me an ips of the hack in question? The fact that custom music still crashes for everyone on real emulators still bugs me and I want to drop the hammer of justice on it.
By the way, it turns out addmusic 1.22 by carol does use $6000 by default. I can't imagine why.
Yeah I'm afraid it starts at $6000. The echo buffer can be moved, but I won't say it's easy.

Here's what anomie's doc says about the echo ring buffer

Quote
$6d rw ESA - Echo ring buffer address
aaaaaaaa

This forms the high byte of the start address of the echo ring buffer
(the low byte is always 0)
. When echo buffer write is enabled in FLG,
all voices marked in EON will be mixed together, mixed with the FIR
output (adjusted by the echo feedback volume), and output into the
ring buffer (4 bytes, 2 per stereo channel). And every sample, one
entry (4 bytes) will be removed from the ring buffer and passed into
the FIR filter.

The size of the buffer is controlled by EDL (kil: EDL is our echo delay that can't exceed $04, otherwise the echo eats up the data at $8000). The echo buffer will wrap
within 16 bits, if the ESA and EDL values combine to specify a buffer
that would go beyond address $FFFF.

Note that the register is accessed 32 cycles before the value is used
for a write; at a sample level, this causes writes to appear to be
delayed by at least a full sample before taking effect.

ESA is accessed during cycle 29.


You might be able to feed this register a different echo buffer address, but you would have to sacrifice something. You could maybe use $7000, but then you wouldn't be able to use any delays higher than $02, and also make sure your music data doesn't take up all of $6000~6FFF and begin eating into the new echo buffer.

A maybe more sane solution ice man found would be to recompile carol's perl addmusic, which has a freespace setting one can change (which is set to $6000 by default). Basically get it to store its data somewhere that isn't stupid. Since I still use romi's, I don't know much else about this problem.
Right. I wish I knew more about what was going on in ARAM, but I don't know a whole lot about what data is what, what is free, where the sound effect data is, etc. One thing I know is the location of the samples.

Here's a really primitive and incomplete ARAM map for SMW I was making a few months ago. Stuff containing question marks is probably just a wild guess, or something I wasn't able to figure it out at the time.

Code
$0000~0001	- ?
$0008~000B	- ?
$0014~0015	- during data upload, points to destination of current upload
$0030~003F	- 2 bytes per channel. points to next (or current?) music data byte for each channel in ARAM
$0044		- main timer, increases after every tick of spc register $fd?
$0045		- high byte of main timer $0044
$0046		- ?
$0047		- ? holds 1 when there is a key on event
$0048		- ? some kind of a bitwise indicator of current channel being processed

$0050		- forced to 0 (high byte of next addr)
$0051		- "tempo"

$0060		- loaded with d4 (Set patch command)
$0061		- forced to 0 (high byte of next addr)
$0062		- engine sends this to $2c rw EVOLL - Left channel echo volume
$0063		- forced to 0 (high byte of next addr)
$0064		- engine sends this to $3c rw EVOLR - Right channel echo volume

$01CF		- stack

$0240~024F	- low bytes = channel 0-7 volumes. high bytes = ??

$0280~028F	- low bytes = channel 0-7 panning. high bytes = ??

$02B0~02BF	- low bytes = channel 0-7 current note value 
		 	  high bytes = pitch modifier/tuning value? FF = (almost) 1 semitone higher

$02D0~02DF	- low bytes = channel 0-7 pitch modifier/tuning value. high bytes = ??

$0500~??	- Start of spc engine code. Not sure where it ends

$1295~		- table of initial dsp settings (tied to $12A1, contains the values sent to dsp reg adresses)

$12A1~??	- table of initial dsp settings (contains the dsp register addresses themselves)

$6000~		- Echo ring buffer default address (see DSP register 6D)

$8000~		- table of samples. contains the start address and the loop setting of each sample. (see DSP register 5D)
$DFFF		- between $8000 and $DFFF sits all of the sample data


Music data in vanilla smw typically gets stored somewhere in that big black space before $6000, but I don't know the details.

There seems to be nothing at the beginning of $F000 (the boot rom is towards the end of it) but I don't know if that memory is special in some way.

For more detailed info just check anomie's SPC and DSP documents.
http://www.romhacking.net/community/548/

For digging around in ARAM, I recommend bsnes debugger, which has a memory editor that can view ARAM and is accurate.
Speaking of addmusicM, is there a translation of the readme files and whatnot? I wouldn't mind doing one if not. Apparently it can do a lot of interesting stuff, such as output stuff back to the SNES cpu from inside the music program, as well as send stuff, really whatever you want, directly to the dsp registers.
Can I ask if you changed any of the hijack points? I have some custom stuff of my own that piggybacks off of sample tool routines, and to find where the smws hack is in the rom it just uses the last 3 bytes of the hijack JSL as a pointer to it.
At this point all I can recommend anymore is addmusic_m, if you can put forth the effort to get it up and going.

Romi's sometimes uses the echo buffer depending on how big your music data is. It starts writing data at around $5600, and that can easily reach up to the echo buffer.

Carol's is sure to crash as soon as you turn echo on.

I don't know about older addmusics but they most likely use the echo buffer as well.
SNN's theory is probably right. When switching songs, the sound code doesn't turn echo off automatically. Here's a very interesting snippet from anomie's DSP document about the echo on/off flag

Code
        e = When set, the echo ring buffer (see ESA and EDL) will not be
            written. Echo processing on the buffer will continue as normal,
            just the buffer itself will not be updated and so the echo samples
            will loop forever.


Songs that don't use echo should probably start off by disabling echo as it will carry over from a previous song. Not only that, but I believe there will still be problems unless the songs turn both the left and right echo volumes to 0.
Originally posted by S.N.N.
burp

yeah it's a custom boss battle theme in 7/4 time for someone. eheh.


That's cool
These are some great finds. I didn't think it was used in that many games.

Right, that fade out is a feature that came with the smw spc engine. To change the volume using the snes cpu you would have to add that functionality to the sound code. The regular sound code only understands a handful of things from the audio ports: play sound effect, start song, fade out ($80), time running out/speed up music($don't remember), go into upload mode ($FF)
(restricted)
Good work. More people should make good clean polished custom bosses like this.