The labels are defined in "levels.s". The data offset is $6000, the start of SRAM, which is where the data ends up by the time the game engine gets ahold of it.

I've got the doc you mention, but it's too incomplete to be really useful when writing something as complex as a level extractor. In particular, it doesn't cover the pointers or offsets at all.

I've managed to hack in three new block types. They are a qestion block with starman (object ID 0x0C), a hidden block with super mushroom or fire flower (0x0D), and a hidden block with special power up (0x0E).

I've also hacked a little bit on power ups and added a placeholder power up for the new ones. As I haven't implimented a method to select which power up the special block gives, it currently gives a black koopa shell that gives a one up.

You can download the source here.

I've managed to find a level editor that works in Wine (YY Mario Edit), so I may release a patch with the new blocks sometime soon. However, I have to go to work now.

True, I hard coded the end of world eight in the extraction portion of the code. There is really no concrete way to know where the SMB world map numbers end. As for SMBS, I don't really know. While it's easy to figure out by lookin' at the offsets in "levels.s" (37 with the current level set), I've never had any reason to check. My code simply produces as many as required and, as such, has no hard coded limit. (AFAIKT there is no limit whatsoever in the SMB engine itself, except the (eight bit derived) limit of 255 worlds and 255 levels (including pipe intro sequences) per world. Of course, with a room limit of 128 (32 indices times 4 types), that's way more than anyone needs.)

As for adding the extra blocks, it wasn't as easy as I thougt it'd be due to various complications. If I was willing to alter the IDs of existing objects, it would've reduced the changes by about a third, but would, of course, have broken every level. Adding power ups is actually really easy. (Makin' them do interesting stuff may not be.)

As I'm well on my way to implimenting the special powerups and intent to work on enemies soon as well, we're gonna' need some graphics hacking. (Actually, I'm pretty good with GFX myself, but my low res, limited color, works leave something to be desired.) Frantik, as evidenced by your (exellent, I would venture) work on Ultimate SMB, you've achived total mastery of SMB graphics. It would be great if you could produce what we need. (Provided you have the time, of course.)

While I can provide reference shots from the PC88 game if required, I'll simply refer you to related NES and SNES games for now.

From the original Mario Bros., we need (animated) sprites for the Fighter Flies and Side Steppers.

From Donkey Kong we need Barrels, Flaming Barrels, the Hammer Power Up and Hammer Mario (Jumpman in original DK) animation sequences. (I belive we need both small and super mario hammer animations, I'll check tommorow.) In regards to the Flaming Barrels, in SMBS, they look a lot like like Sparkies, so I'd suggest SMW as a reference as well.

The falling spikes have no real pre-SMBS precedence. Wikipedia claims they're supposed to be falling iceicles!? However, with the chosen pallet and (indistinct) sprites, they're pretty open to interpretation. They look pretty similar to the (clearly) spikes in SMW, so I'd recommend that as a reference again.

The wing power up looks pretty much exactly like a SMB3 P-Wing sans the P.

I'm tempted to recommend SMB2 (US, Doki Doki Panic) as a reference for the clock, but given the vastly different function of the item, perhaps that's a bad idea. Something distinct, but still clearly a clock, would be better. I'll post the PC88 graphic when I get the chance.

That only leaves the Hudson Soft Honeybee and the Unidentified Power Up. As the PC88 Honeybee looks more like a bad graphic of a treasure chest than a bee, I'm not sure what to recommend as reference. Perhaps I (or you) can find a good rendering of the Hudson logo to base it on. As I have know idea what the Unknown power up is even supposed to be, I've got no suggestions for references. (I'll post some screenies sometime soon.)

Finally (not to step on a fellow artist's toes), a brief bit on style. While the images in USMB are amazing, they're more SMB3 than SMB. I think it'd be better to stick to an (extreemly) old school style to better mesh with SMB. Of course, given your artistic brilliance, I proably didn't have to mention this, but whatever.

While I've specificaly asked frantik's help with graphics, anyone else who can push pixels is welcome to contribute as well. Given the enormity of this undertaking, more than two hackers working on it would be nice.

In regards to the special blocks, etc. I noticed the placeholders and they're pretty handy. On the other tentacle, editing raw SMB level data with a hexeditor isn't very easy. While I had some success with YY-ME, it's not really going to work out. While it can easily enough create 0x0E objects, its strange interpretation of the object IDs makes adding (real) 0x0C and 0x0D objects impossible. It's a pity SMB Utiliy seg faults under Wine as it's raw hex access feature is perfect for this sort of hack.

One way or another, I'll get the new blocks added where they need to go. What this project really needs is an open source (or, at least, source availble) SMB level editor. Unfortunately, AFAIK, there isn't one. I may end up implimenting one of my own. If I do, it wouldn't be like any other level editor out there. Instead, it'd be more like a special use hexeditor.

Anyway, I've got to work in the morning, so good night.

If you can't manage to get all the sprites into the CHR-ROM, don't worry about it for now. As long as you get the graphics themselves produced, then we can worry about squeezing them all in. I'll try to get some screenshots produced soon.

The hex values for the blocks I added are all listed in the post I made about them on Thursday.

The hudson bee is used in Milons secret castle. I think it adds a bar of energy to your  max hp. It also refills your health. Maybe you wanna see what it does in other hudson games.

It's gonna be trippy seeing this patch finished. Expanding the rom, object filled levels. New items. Pretty epic.

cool nice job with the selector blocks.  i will get the sprites created.  looks like the hammer mario is just regular mario with a hammer so no extra sprites needed cept the hammer which is good

and you can implement swimming with a single game genie code so it can't be too hard PIGOAP

Yeah, I don't think implimenting the wings will be too difficult. Basically, it'll just require adding one more timer to the game and a few conditionals. However, what makes that qualify as moderately difficult is the shear ease of implimenting the clock. The content of it's collision handler is literally one "inc" instruction. Anything is hard compared to that, ha ha.

As for the Hammer, that really will be hard. It's going to require a timer, new animation, and collision detection. I'll proably have to dig throught the bowels of the fireball code to figure out how to handle the animation and collisions.

The power ups with unknown functions are a bit irksome. Does anyone here have z80 skills they'd be willing to contribute? I have a pretty good idea where the code is located on the disk image. (Actually, I know where it's not, which is almost as good.) I do agree that the unknown one kinda looks like an atom. The comparison is even more apt when you know (which I forgot to mention) that it's pallet cycling animated.

frantik, once you get the sprites hacked in, please let me know what their tile numbers are so that I can replace the current placeholder graphics (inverted black koopa shells) with them. I'll also need to know which pallet (attributes) they should use. BTW, my build system rips the CHR-ROM from the latest world 1-4 patch.

I was wondering. Should I release the current code with the new blocks now or wait until we have a level data set that'll actually use them before I do so? Further, given that you're currently working on both editing the levels for new blocks and the graphics additions, are you planning releasing one or the other as soon as it's done, or are you going to wait until both are finished. Likewise, if you do release seperate updates, should I? Or should I wait until we have both for the next expanded ROM and source release?

You could modify the level data format (or create a new section of level data so as not to break compatibility with the editor you're using) to have it swap CHR pages as the player scrolls.

Example, if there are never any goombas and hammer bros on the same screen at the same time, you could put them at the same spot in the pattern tables, but have them on different CHR pages.  Then in your map data, have an indicator that the game should swap CHR when the user gets to certain points.  I believe SMB3 does something like this, but that's a total guess.

Getting it to swap wouldn't be that hard.  Your level format could be something like:

XX XX PP XX XX PP

Where 'XX XX' would be a scroll position, and 'PP' would be a page number assigned to that position.  Once the in-game scroll exceeds XX XX, you simply swap in the next page on the list.

yep

the way the SMB3 sprites freed up space is due the the fact there are fewer unique tiles.. in smb1 almost every frame has completely unique tiles.

actually I was thinking about what Disch said and perhaps the bowser graphics can be switched out because they are only used in the end castles.  also there is already code for a palette switch when the axe is loaded to make sure Bowser has the right palette.  this could ammended with a CHR-ROM page switch as well.   there are at least 16 bowser tiles so that could give us 4 whole sprites.  still not enough though for everything.  perhaps those object selector switches will also have to switch chr-rom pages?