Current version: 0.03 - Download here
-> What does it mean?!
Features:
SMAll's graphical interface is based on a custom library I'm working on which is far from done. I realize the controls don't have all the features you're used to in Windows (for example, holding down a scroll bar to make it contiuously scroll), and I would eventually like to put all the bells and whistles into it, but for now, it's pretty spartan. I realize this.
-> Quick start guide
Tip: 'Allocate new' works just fine if you want to reserve a block of data, but it's not very useful because it doesn't link it to anything. Instead, I think you will get more use out of the forward link list. Right click it and use the link menu to create stuff such that it will be tied in to the rest of the ROM data.
Remember, anything you do which removes a back link from another object could potentially delete that object. That's why I made the trash bin though. To turn this auto delete off, use the check box (added in v0.03). To delete the trash, just delete the files (your rom)_trash.bin and (your rom)_trash.csv. These must be deleted at the same time, or you could horribly confuse yourself. It probably won't ever get big enough to worry about though. It seems like you'd want to keep a backup of all that stuff.
-> Known issues:
-> Change log:
SMAll stands for Super Metroid Allocator. It is a mysterious and powerful device. It is NOT a level editor. This will not let you move and place blocks on the screen. This is a memory/pointer management tool, to be used in conjunction with SMILE, the authoritative level editor for Super Metroid. In fact, the main window looks a lot like a disk defragmenter. Essentially that's what SMAll is, but there's no disk and you have to move things manually. Say you're making a really cool hack but you run out of room slots halfway through, and your central hub room needs 5 states to handle different game events. No room in Super Metroid has that many, and you hate hex editors. That's not going to stop you any more.
What you do from here is your choice. Click on segments. Use the + and - buttons to zoom in and out. The top left corner is your focus when you zoom. The lists to the side will display link information. You can click on an item in those lists to jump to that location. Right clicking things will give you several options. Some work better than others. SMAll is by no means finished, so don't despair if something isn't working right.
About size limitations:
The size of the file you can open is limited only by the SNES's address space, i.e. 0x8000 * 0x80 = 0x400000 = 4,194,304 bytes.
The maximum size of a new block you can allocate is the size of one bank, 0x8000 = 32,768. SMAll will automatically expand the ROM if (1) the data you've requested is able to be in any bank, such as level data, and (2) there is not enough contiguous free space anywhere else. For data which must be in a specific bank, like all the stuff in 8F (room headers, door out table, states, plm) it will simply fail if there is not enough contiguous free space. One assumption I made when writing SMAll, which I believe is incorrect, is that data can never cross bank boundaries. In reality, I think some level data actually does lie on the border between banks. Haven't tested this very well.
Saving / other programs:
SMAll is an in-memory editor. That means the entire ROM image is loaded into memory, and nothing is saved back to disk until you click the Save button. SMAll has a "smart" save feature which only writes changed data, so you can still make changes in other programs while you work in SMAll. Just make sure your changes in other programs don't conflict with the changes you make in SMAll. If there is a conflict, well, I honestly don't remember what it will do, probably throw an error. I know I made it recognize conflicts of this type, but I think the way it is handled was on my To Do list. Point is, you have to save before any of your changes will be visible in other programs.
Deleting / repointing
Basically, the way this works is, if you're not using something any more, it gets deleted. The way SMAll decides if it's being used is by the number of things that point to it, a.k.a. "back links". So, if you overwrite one door pointer with a link to new data, and don't copy the original data, that "door data" segment will probably be deleted. Also, if that door was the only entry point to another room, that room might be deleted, as well as all its level data, plm's etc. However, if there is another door somewhere in the rom which points to that room, it will not be deleted. There will be an option to turn this off in the future.
The pseudo code version of what I just said:
IF (you re-link a pointer to a new piece of data) OR (you delete a block of memory) THEN
FOR (all items referenced from that data)
reference count = reference count - 1
IF reference count == 0 THEN
delete this segment <-- this triggers the same function recursively
Deleted data / trash bin:
Yes, there is a trash bin. If you accidentally save your ROM after deleting some critical piece of level data, you can find it here. SMAll does not have an undo feature yet, but this will at least preserve the raw data so you can rescue it. There are 2 files which make up the trash: *_trash.bin and *_trash.csv, where * is the name of your rom file. The csv is a text file (comma separated values) which is formatted such that it can be opened in a spreadsheet like excel, or notepad either way you prefer. This text file is the master table which tells you where to find your data in the trash.bin file. It has fields for date/time deleted (format YYYYMMDD-HHMMSS), location in trash.bin, size, and type. If you want to rescue the data, use a hex editor to open *_trash.bin and go to the offset listed under "trash file address". Then copy (size) bytes from that location back to the rom file at (rom_pc_address). Note: Although all deleted data segments are saved here, any back link pointers which reference it are simply overwritten without backup. So, at least for now, you'll have to re-link the data after you rescue it from the trash. Also, more than one segment may be deleted at one time. These are listed separately. You can examine the time stamp in *_trash.csv to see if more things were deleted at the same time. The rescue process should be repeated for each of these which have the same time stamp, otherwise some pointers will be invalid and may cause stability problems when SMAll attempts to parse the missing data.
To empty the trash, simply delete those 2 files. They will be created again next time you delete something and save the rom. Make sure you delete them both. If you delete only the larger .bin file, your .csv will be invalid up to the point where new items are added.
[content edited out - go read forum if you're that curious]
Silver_Skree is correct. As long as you have a valid mdb.txt, it should be able to open anything. The only exception is if things have been relocated to a different bank (this is true for Redesign). Right now, the only kind of data that SMAll can read if moved to another bank is PLM's. I actually talked with Drewseph about plm's and got him to test SMAll. Unfortunately I don't have a copy of his mdb.txt, but he says he was able to open redesign with it and view the correct plm data. The mechanics of the program would allow me to easily redefine which banks contain all the different kinds of data; I just need to know how to find that value from parsing the rom. If anyone can help with that endeavor, let me know.
0.03 - Added a check box to enable/disable the Auto Delete feature. See above. Added support for linking states from room headers. Added an icon (Thanks, Qactis!)