click

Seeing that it's public, others can feel free to help out as well. You can make use of the ROM/RAM map to get started and submit information you find there.

--------------------
My blog. I could post stuff now and then

That's great, but which .ASM files are SMB3? I've been adding SMB3 data in a long time and it can come in handy for me.

Ah, the banks for the games are written in the README file in the root of the project directory. Here they are anyway for reference


Rest of the banks are stuff like graphics (and nothing else?)

--------------------
My blog. I could post stuff now and then

New updates. See first post to view the files.

I have updated the disassembly to
1) make it assemble-able in asar through a script and
2) fix minor errors which resulted in very, very weird things.

Furthermore, I added an Assembly directory which is basically an assemble-able version of the disassembly. I made the assembly to find errors in my disassembly. This is because when there are errors, there will be mismatches in the binary data of the original and assembled ROM.

The conversion gets done through the files in AssembleDis. Eventually I plan to update AssembleDis to
1) exclude unused labels so that the code is even more readable and more flexible to edits and
2) Edit references to ROM addresses by adding DATA or PNTR to it (such as LDA $9004,y becoming LDA DATA_009004,y)

But this'll be near the end. For now, documenting has my priority again!

This all was possible thanks to p4's help.

Also, I'm still open to help. Feel free to discover new RAM addresses, or even help out with the files themselves by documenting stuff!

--------------------
My blog. I could post stuff now and then

This is just awesome!
Didn't spel werdz rite make his works on MushROMS open source during last C3?
And now, Ersanio and P4plus2 are making seemingly significant progress with the disassembly, otherwise, I doubt Ersanio would have put all of this on gitlab and posted about it.

I'm so glad to hear this, wish you guys good luck in the future as well.

Thank you! I'm trying to work on this whenever I have time/not tired. Combined with my internship it's pretty difficult.

I'm hoping to finish up the last pieces of important data of SMB1:
- Background map16s. There's a map16 page for every type of background (e.g. underwater, castle, etc.)
- Background tilemaps. I mean, besides map16 the background has to be built somewhere of course
- Above two, but for layer 3
- Object generation during levels. I found two pointer tables regarding generation of objects. One is for vertically extendable rectangle objects (like bricks, pipes, etc.) but I can't figure out what the other one is for. The other one has stuff like stairs, castles at the beginning/end of the levels, and ??? SWR should have this information
- Palette data SWR should have this information
- DMA routines so they can be hacked for our own needs
- Sprite routines and tables. It's a mess in SMB1 but in case we want custom sprites in the future...
- Level data is already covered in the ROM map. As for the format, it shouldn't matter because it's going to get changed with MushROMs. It's only useful for level editor developers. SWR should have this information

I'm not going to bother with trivial stuff too much anymore like rescuing toad, how the game over screen is built, etc. I'd like to focus on things people really want: editing levels.

After all of this, I'd like to move on to SMB3 or SMB2.

As for MushROMs, yeah SWR did make it open source, along with the ASM hacks used for ExGFX and all. Come to think of it, I could check his ASM hacks to find more data.

--------------------
My blog. I could post stuff now and then

I'll take note of that. Thanks! Having said that though, wow, building a background with code instead of a huge table? That just makes it more complicated to edit it. Oh well, situations like these are what ASM hacks are for.

e: on a semi-related note, I found the ASM hacks SWR made to alter SMB1. The ASM hacks include:

- Custom GFX
- Custom levels themselves
- Custom level format
- Map16 expansion
- Custom palettes

Looking at the hijacks, I can probably locate some useful data. Nothing about backgrounds though. That's one info SWR probably seriously needed.

--------------------
My blog. I could post stuff now and then

WELP it seems like you are right Matt, SMB1 generates backgrounds with algorithms as well. For example the game generates the black background ceiling thing and then the repeating cave pattern in cave backgrounds using a loop. Didn't look beyond that but I assume the game also generates the pillars lanterns etc with a loop and pastes it over the generated background.

If we ever decide to stick the background tilemap in tables instead, maybe it'll be wise to RLE them somehow. They can go up to 1kB in size.

--------------------
My blog. I could post stuff now and then

Seems like Gitlab (the place where I put the code in public in first post) is down after Kieran did his server maintenance. No worries though, I still have a local copy and no progress is lost (because no progress was made). I'll see if I can get it up again.

Two days ago I started working on the disassembly again, with the main goal fixing tables and giving ROM access instructions labels (e.g. LDA $8000 becomes LDA DATA_008000). This is in order to make the disassembly split-disassembly compatible.

I noticed that most tables in my disassembly aren't distinguished. For example, two separate tables with separate functions would still be in one table in the disassembly. In order to see which tables are marged, I attempt to assemble the disassembly and see which 'tables are missing'. For example, if it says that DATA_00D000 doesn't exist, it most likely means that it's merged with some table very close by.

Of course, I am fixing these errors.

--------------------
My blog. I could post stuff now and then