So I've done quite a bit of work on this glitch, and this seems like the best place to share my knowledge of how the glitch works.
As some background, the inventory is stored in the following order: first the quantity for each weapon, then the quantity for each armor, then the order in inventory for all your weapons (you always 'have' all weapons in your inventory, just with quantity 0), then the order for your armor. Then there are fields like your stats, timer, familiar level, then several pointers. Also, an equipped weapon doesn't count towards your quantity (as is clear by the fact that equipping something you only have one of removes the text from your inventory).
The glitch starts with save corruption, the point of which is to get you sorting menu to have at least 1 extra S.Sword sort, but usually entirely S.Sword. I will assume you get all 11 S.Swords in the sort menu. Also, I will say you own an item if you have at least 1 of it. The sorting program works as follows:
0) Start from the start of the inventory.
1) For each type listed in the sort menu, put all owned items of the type in order next in the inventory.
2) After that, put all unowned items in their original order.
3) If there are left over spaces, fill in the spaces with item value equip to the index in the inventory (like slot 168 gets item 168).
So when you start with 1 Short Sword, it multiples to 11, then 121, then filling your inventory when you use the sort command. Unowned spaces towards the bottom get erased first when doing this, so occasionally you want to move these spaces to the top. Also, if you have alot of non-sword swords, you can restore some high values to your inventory after you've destroyed it by doing a sort without a short sword in your inventory.
Once your inventory is missing some values, you can start swap overflowing shenanigans. This exploits how the game behaves when you get a new item (an item with quantity 0. It is allowed to be in your hand). This can be from buying it, unequipping it, or picking it up. The intended behavior is that it swaps the item up from its current location to the first empty slot (recall all items are in inventory from the beginning). The function is:
You are getting item X.
1) From the beginning of the inventory, search for the first slot containing an unowned item. If you find slot with value X, stop. Let Y be the value of the empty slot. Store X in that slot.
2) Continue searching for the first slot containing value X. Store Y in this location.
(Note these values are bytes).
The problem is this searches even past the inventory bounds if it doesn't find X. It will swap using the first empty slot, even if that slot is in the armor area of inventory or beyond (note: by empty, I mean you have none of that WEAPON, even if you have an armor in that slot). Typically, this is used by choosing a byte in memory you want to modify, and dropping an item with that value (X). You set the value of the first empty slot to whatever you want to store in that byte. Then the swap puts the desired byte in that location (if that is the first byte with value X).
If you put a value above 89 in the armors, you get a glitched armor where the quantity is equal to the weapon value is a slot in your inventory. This is because directly after armor quantities in inventory are your weapon item values. For example, equipping armor #92 reduces the item value in slot 3 of your weapons by 1.
Using this, you can control pretty precisely the items in your inventory (at least for values 1-168). For item values above 99, you can chain equip glitch armor to quickly reduce the value down to up to 99. For other values, unequipping glitch armor works so this method doesn't work anymore. Instead, you have to equip the glitch armor, swap another slot with the weapon 'glitch slot', unequip it, then swap it back and reequip the glitch armor. By repeating this process, you can slowly reduce the item value of a slot (while increasing the item value of a different slot). However, you cannot increase an item value beyond 99.
There is a pointer with initial value 0x80138460 that I refer to as the Music Pointer just after the main inventory stuff. By changing its value, you can change almost any spot in memory, though a bit uncontrollably. If you reload the shop music, it will change a large block, which is useful if you point it to data, but will cause crashes if changing code. However, there is often a smaller change when you change the pointer, even if the song doesn't get reloaded. It seems to be effected by the byte 0x90 from the pointer location, but I don't really understand it. By setting the pointer to 0x800F52B0, you change an instruction that causes the PC to jump to a spot just after the inventory, from which you can jump into the inventory using some swap overflow shenanigans. However, there is hopefully (maybe probably) some superior value that will get control directly into the inventory, from which total control can be obtained.
