News:

Don't forget to visit the main site! There's lots of helpful docs, patches, and more!

Main Menu

SMAll release thread

Started by DFPercush, December 24, 2010, 03:57:34 PM

Previous topic - Next topic

DFPercush

(original title: Merry Christmas, Zebesians!)

Edit: Attachments removed - please download the latest version from http://dfpercush.metroidconstruction.com/small/

As my gift to all of you, I give you SMAll version 0.01. SMAll stands for Super Metroid Allocator, and is a memory management tool. It still has a few issues, so I don't make any guarantees (read: back up your data). When I have the time, I will make a help file, howto, and faq for it. For now, just play with it and see what you can do. Hint: Right click stuff.

Basic howto: To open a rom, click on the first text box and choose the .smc file. Then you must provide a current mdb.txt from SMILE. I recommend making a copy of the SMILE folder for each rom you want to edit. SMAll will write back to this mdb.txt and also levels.txt (i think that's the name of it) so you can edit your new rooms in smile. Also, if you want to create a new room, I recommend using the "Create new link" feature from the forward link list, rather than "allocate new" from the main right-click menu. You'll have to select a "door" data segment first which can be found in bank $83.

For the coders in the audience, there is some C++ source that will allow you to put most of SMAll's functionality into your own program. Watch out for pc addresses vs. snes srom addresses, there's really no standard at this point.

James, my FTP password isn't working. It's been a couple of months since last time I logged in. Did it expire?

Let me know if anyone has problems running it on older OS'es. Only windows is supported right now. This version is compiled with Visual Studio 2010 so idk how far back that will be compatible. If it's a problem, I can recompile it with another compiler.

Join the discussion on IRC! In addition to #metconst, there is also #small for issues specific to working in small.

---------------
Edit: Version 0.02 was built using MSVC 6 debug build. For some reason, the release build has certain errors that don't happen in debug mode. Until I figure out why, this is available. It's larger and slower than the retail build but apparently more stable. More to come later. Also included a couple of header files in the source that are necessary to compile libSmall.cpp.


gunnargumpert

Just a qu.

I wanted to test it out to the Redesign ROM - since i reinstalled Windows, it's the only ROM left. Might it be possible, not to work with Hacks? Or is it a file size limit to 3mb? Well, Redesign has 4 MB - many other Hacks also are bigger than 3mb.

Did some other guys succsesfully open a Hack, ore eben a ROM?

I'm using Win7, by the way - but there should be no compatibility issue. Ultimate should be able to handle every OS - so it night be this proplem: Programm "I don't open this ROM, you mothafucka. I'll not open Hacks!"


Cadarot

#3
Quote from: gunnargumpert on December 24, 2010, 10:04:29 PM
Just a qu.

I wanted to test it out to the Redesign ROM - since i reinstalled Windows, it's the only ROM left. Might it be possible, not to work with Hacks? Or is it a file size limit to 3mb? Well, Redesign has 4 MB - many other Hacks also are bigger than 3mb.

Did some other guys succsesfully open a Hack, ore eben a ROM?

I'm using Win7, by the way - but there should be no compatibility issue. Ultimate should be able to handle every OS - so it night be this proplem: Programm "I don't open this ROM, you mothafraka. I'll not open Hacks!"
...

Quote from: gunnargumpert on December 24, 2010, 10:04:29 PM
I wanted to test it out to the Redesign ROM - since i reinstalled Windows, it's the only ROM left.
......

Quote from: gunnargumpert on December 24, 2010, 10:04:29 PM
Redesign ROM
FFFFFFF....

Quote from: gunnargumpert on December 24, 2010, 10:04:29 PM
Redesign
[spoiler][/spoiler]

ONTOPIC:
I'll be sure to check this out after Christmas. Do want

gunnargumpert

I'm not totaly shure, if you guys got, what i meaned.

Well, is this programm able, to view Hacks correctly? This will tell, if it even should be possible.

Just a qu., F.S.666:
Why did you quote and mark REDESIGN? No job, man?

zephyrtronium

As long as one has all the necessary information, there is no reason why one cannot use this program with a hack. That said, Redesign has protection against retards trying to hack it, which happens to be what is preventing you from using this program on it.

Silver Skree

This requires an accurate mdb.txt to open any hack; it just needs a starting point and it can follow the doors through the hack and scan the ROM like that. There's no functionality for manually setting a start-scan address, but you should be able to tell it where a room to start scanning at is in the future.

So gunnar, to answer your question: Yes, it can open any SM ROM as long as you have the correct mdb.txt from SMILE.

igo

Anyone worth their salt could manually scan the rom and document the mdb.txt needed for any hack already made. It might take awhile, but it's certainly possible.

Quietus

From what I understand of Gunnar's question, it sounded like he received the error message quoted at the end of his reply, and was asking what may be causing it.  He asked whedther it could be a size issue, as Redesign is bigger than the standard ROM.

I may be misunderstanding, but that's how I read it (before everybody went psycho-at-gunnar-for-no-reason-again). :O_o:

Qactis

SMAll doesn't have an icon!  :cry:

I took a stab at a 4bpp icon using only the gravity suit palette

[spoiler=Preview][/spoiler]

Note: Will make a high-quality one later

Silver Skree

Also, if you have questions about SMAll, it has an IRC channel to itself. On esper, #SMAll. Drop by if you need or want a hand using it and we'll help you as best we can. If we're there. It is christmas right now, after all!

DFPercush

#11
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.

@Gunnargumpert:
[edit] I remembered. You're talking about "Irregular format not supported (yet)." This happens when you try to create a new link of type "state" from a room header. That's because the address of the state pointer within a room header is not always the same. It takes a special function to read the room header, therefore different code has to be used to create new pointers. That part of the program has not been written yet. Don't worry, it's coming soon. And the "FU" is just a joke. The scenario is supposed to be you saying FU to me because I didn't let you do something. The same thing will happen if you try to create a link to BG data.

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.


Kasel

I'll give this a try eventually.  I do have one question (It might have been answered but I'm exhausted at this point in time and I'm too lazy to read everything posted) but is it okay to run this program on a hack in progress?  Meaning I'm still doing a lot of work on mine and the rooms aren't even close to being completed.  I should probably just hold off on it...

Katelyn


DFPercush

#14
Version 0.03 is now available.
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!) Other minor bug fixes.
http://dfpercush.metroidconstruction.com/small/

Qactis

No problem. I'm not happy with the end product, but I know why (that was my first attempt at an .icon)! :D It took me at least 10 signatures before I was decent at making them, and probably 15-20 before I considered myself -good- at it. So I'm going to make another shot at a high quality icon for .04 for you, as soon as I finish a forum banner and some other projects that also had to be put on the back burner thanks to IRL stuff and work in Assembly