The 15th Man Project: ASM Thread

I haven't been looking at / editing the code directly yet, but I've been thinking about how to add a new magic list.

The way I see it, there are a few plausible ways to go.

#1.

The idea proposed by Edrin earlier in the thread. This should work, and be seamless to the player, and it should free up enough empty space in the memory.

I had an idea where instead of having a byte per spell, having a byte per esper followed by a bit per spell, then let the game figure out which spells the character knows from there...

So, to restate the idea, instead of storing in memory the %learned for each spell, we would store the MP earned (or AP earned, or whatever you want to call it) for each esper. And then we would calculate "does the character know the spell?" by a formula involving all the Espers that teach that spell. For instance, %learned for Bolt 1 would be: (AP-for-Ramuh * 10) + (AP-for-Bismarck * 20) + ... whatever (are there any others that teach bolt?).

This would work. As Edrin said, there is also the matter of items that teach spells. We would have to basically treat each item as an esper. We still have room, I think? But it would mess with the ability of other modders to freely edit which items teach spells.

#2.

Spells only go up to 100%, but they're stored in a byte which can hold up to 255%. We could make each spell take up only 7 bits. This would mean we would need to do a little bit shifting every time the spell list is loaded. But it should free up more than enough room for an extra spell list (almost two).

I can't see too many drawbacks to this, other than the difficulty writing it, which I hope wouldn't be TOO bad. It could be combined with Edrin's idea #1 for even more space saving.

#3.

Both the most interesting and least interesting idea. A brute force approach that may or may not have serious drawbacks.

Expand SRAM and use it as extra working memory.

I recently used SRAM to store a cache of palette-usage data for my palette hack, in space outside any save game. There are a little less than $200 bytes of free space of SRAM which can store something or other.

What's even more interesting, though, is that you can expand the amount of SRAM to many times its original size just by editing one byte of the ROM.

I don't believe anything stops us from using SRAM as extra working memory. According to docs, it takes only slightly longer to save/load SRAM, compared to regular ram (8 cycles versus 6). After expanding SRAM to 2x, 4x, even 8x or possibly 16x its original size, we could (maybe) use it to store anything we want. Both expand the size of save game, and use it as extra working memory, to store constantly-updated values of character stats, spells, and so on (which are then copied to a "save game" partition of SRAM, when you save).

With this, we could add new spell lists, new spells, new Espers, even whole new characters, without much problem. There are hardcoded limitations that make it hard to have more than 16 character "slots", I'm aware of. Event scripts assume PCs are numbered 1-16, and 17+ refer to NPCs. But, still, it would be no problem to find room for a new spell list.

Are there significant drawbacks to this? I've goggled for it.

Many of the results pertain to real hardware. Most people who "know" seem to say it is no big problem to use SRAM as working memory on a real cart. Though few SNES games actually do it. It doesn't "wear out" or anything. It's just a kind of RAM. It costs less power to keep it active, as long as you don't actively read or write to it. That's why it's easier to back up by battery. The power savings go down, and it might even become less efficient than regular ram if you read/write it often. That might be why it's not OFTEN used as working RAM on real hardware. But it can be.

On emulators, certain emulators may cause problems. Some emulators (ZSNES) can optionally NOT reload SRAM when you reload a save state. This is so you don't accidentally overwrite your save game. That causes problems, though, on the few games that use SRAM as working memory. So, it would be a problem under certain circumstances, for people who use emulators and save states with the wrong options set.

It also could potentially be a problem for emulators for systems like the Wii and DS and PSP, which write files to flash media, which DOES wear out if written too often. But, I think those emulators don't actually write SRAM that often. They just save it in their own RAM, and write it when you exit the emulator.

I don't know. There is actually pretty little information about this. The best way to figure it out might be just to test it on various emulators, and see how many problems it causes. But, if it worked, it could potentially facilitate a lot of things, including but not limited to the 15th character hack.