Map piece editing

..is also now much faster.  You can pull each map editor to its own window, edit the piece, and see the composite map update when you hit OK.  Hasn't crashed yet, it's orders of magnitude faster, and it's barely using any CPU at all.  In other words, it's actually somewhat usable now.

Multi-window editing

This is something I got some requests for a while back.  Seemed useful to add.

Menus missing in the screenshots (like "Music" on the music editor window), but they're there now.

Composite Map Rendering/Editing

..is much improved.  Stabler and faster.  Everything else needs to be worked on still, particularly the "Map pieces."

.. and fixed a bug where apparently you couldn't edit the foreground section of tilesets.  Lovely.

Extended Hirom

Finished playing the 6 MB Extended Hirom version.  169 total changes to code to make it work, made painstakingly one by one by savestating before a crash, generating a code dump, and finding where it jumped to a patch of 00s instead of code (or in the trickier cases, where it read from zeros instead of data). 

Probably still some crashes in it that I didn't get to test.  This will go into some build of the editor in the near future... to be used only if the data you're trying to write exceeds 4 MB (and doesn't exceed 6 MB, in which case I can't fucking help you.) 

I guess there's some extended format that supports 8 MB as well, but it sounds like it's largely unsupported by emulators (did any game actually use it?  I get the feeling Tales of Phantasia is the only reason anyone bothers to support the 6 MB one..)

More stuff.

This is something I think we've all wanted to be able to do at some point.  This game is so much more fun to play when your movement isn't restricted by where the other characters are.  The "fix" I'm working on for this has its share of problems (for example, it flips the fuck out when you try to bring up a ring menu for someone offscreen), but I'd like to clean it up and include it as an automated fix... in fact, I think there's already a checkbox for it.

As for the ExHiRom patching, it's giving me an excuse to play through the game again (it's actually been a long time) to fix where it still crashes. I'm at Matango, as you may have guessed from the gif.  It's pretty stable so far and low on non-catastrophic glitches.  The only one I've noticed is some palleting issues with layer 3 (also visible in the gif) but I think this might just be a Snes9x issue.

ExHiRom

Converting to ExHiRom (which will effectively triple the potential size of the ROM, to 6 MB) seems to be.. doable, but it's going to require some code patches.

The addressing for SNES addresses C0xxxx-FFxxxx (HiRom ROM range, and typically how HiRom code accesses ROM) is the same, but it varies for the range (00xxxx-3F0000), which under HiRom points to ROM, but in ExHiRom points to the upper portion of the ROM (see http://slack.net/~ant/old/info/snes_super_flash_cart_64m.txt).

SOM, of course, is littered with code that jumps to 01xxxx, 02xxxx, etc - so either I patch this code (replacing 01xxxx with C1xxxx, etc), or copy a bunch of it to the 4xxxxx range (which is a waste of space that I'd rather avoid).

FuSoYa's expansion tool looks like it copies the ROM from 008xxx to the 408xxx range (to avoid such problems for 16-bit addressing?) but why does it not surprise me that SOM is actually calling out these types of addresses as 24-bit in some of the code... and using HiRom-style Cxxxxx, Dxxxxx etc in other parts of the code.  Meh.

Edit: So far, 64 24-bit address references changed in SomExHi.smc, and I've managed to get the game to play up until you fall down the waterfall, at which point it crashes.  Getting this to work for all code paths is going to be a long process.

ROM file sizes

"Export to ROM" now only expands if necessary.. changing fixed-size things won't bump your ROM up to 4 MB anymore.  If you added things, it first pads it up to 3 MB if necessary, then to 4.  If it goes over 4 (which won't play) it will warn you on the little status log thing.