Ok, I got another idea. IF, you have extra space left after doubling the size of the rom, perhaps you could dedicated that to unnique graphics, and code, and you could have those swapped in and out on a stage by stage basis. Like say, a stage requires a certain sprite, well, have the sprites not being used in vram, swapped out for the new sprite used in the extra space. So that way you won't have to replace enemies.

Another idea, at least for the hammer powerup. If you don't have space to draw it in, use the hammer bros hammer graphics, in it's pace, and try to make it replicate the SMBS hammer behavior.

That was a great project so far. I wish I could be in this project. But unfortunely, I have no sound card to play SMB Special with PC-88.

World 4-4 is kind of interesting too. May struck the idea for my next plus series project. Plus the level rips aren't that easy to design if I had to be in the project.

After looking at the layout and code structure of the ROM, I've found a nice way to gain a lot of space (about 3k) for additional code and data in the "hardwired" bank. This is by relocating the sound engine and data into another bank. The sound engine code is cleanly contained and there is only one entry point into it from the rest of the code. By relocating the sound portion of the code into another bank, and replacing the only entry into the code with a far call rather than a standard function call, a big chunk of space can be freed up.

Additionally, as ROM sizes have to be powers of two anyway, this also gives us a whole 16k bank of PRG-ROM to do whatever we need to with. Furthermore, the sound code would only use about 3k of it's bank, so there'd be another 13k or so there to work with as well. All in all, I think there'll be more than enough space.

While this may seem like a drastic fairly drastic change, it's pretty much neccessary to do something of the sort. Based on doppleganger's ROM map, there's only about 42 bytes of unused space in the SMB PRG-ROM. While I could proabably manage to squeeze the mapper handling code into such a small space, it wouldn't leave much room for anything else. This way, I free up a large area in the high bank, which is often the most useful area.

I should have a working demo of the expanded ROM some time soon. Once I get that done I'll start integrating the changes frantik has already made.

frantik: How much additional space for levels do you think you'll need? I know, as the saying goes, it's hard tellin' not knowin', but what would your estimate be? If we could manage to fit all the levels, other changes, and game engine (sans sound) into 32k, it would definetly simplify things.

If you still have some space left in the original rom then I would suggest trying to make another level or two with it if u got enough space. Beacause you never know how much space the next 4 worlds are gonna take. If they got even more blocks laying around then the first four levels your gonna need whatever space you can get.

You can either use mapper 69 (Sunsoft's FME7 mapper) or mapper 5 (MMC5) to help expand levels in new expansion at $6000-7FFF, or use MMC1 or MMC3 to put levels in WRAM/SRAM @ 6000-7FFF. Although I'd use the MMC5/FME7 space more than the usual WRAM/SRAM.

By The Way: I might try to create a SMB-SPECIAL style one-screen level changer. (one with and without expansion levels) But if I have the nessicary time to do it. (I am currently using SMB1 Disassembly by Doppleganger to do my hacks)

I came up with the idea in the first place.

Also, I do not want to lose the scrolling for this hack. It was my idea to have a version of SMBS in which the screen scrolls. Combine SMBS with NES engineering...

Actually, in SMBS there is looping in parts of World 7-4 (you have to use pipes to advance to other parts of the stage, a la World 8-4 in SMB for NES):
http://www.youtube.com/watch?v=b9KvjAQIW_o

Like the NES version, World 8-4 in SMBS also makes use of pipes to advance from one part of the stage to the next:
http://www.youtube.com/watch?v=azPuClxuMUI

~Ben (SMB2J-2Q)

Well, I've finished my SMB MMC1 expansion proof of concept hack. It doesn't currently do anything noticable, but things have changed "under the hood". As mentioned above, I've moved the sound engine into a bank of it's own. The call from the main loop into the sound engine has been replaced with a call to a custom function that switches banks, calls the real sound engine entry point, and then switches banks back. The only other change was the addition of a call to a mapper setup function in the startup routine.

So far, in my limited testing, everything appears to work perfectly. As I've said, it doesn't do anything noticable, put I've posted it to my website, just in case anyone wants to check it out or do some more testing, etc.

My next step is going to be working on intergrating the changes frantik has made so far. It shouldn't be too difficult, but we may run into complications down the line. I'm not sure how flexible the level editor frantik is using is and whether or not it'll be able to edit the expanded rom directly. If not, I'll have to come up with some sort of exportation and importation tools.

In regards to the looping, in SMBS, if you walk past the end of chunk 16, you end up back at chunk 1. It's not the same effect, and it isn't actually used in any of the levels, so I think we could safely reclaim that bit of code, but given the amount of space I've gained, I don't think it'd be neccessary.

As I'm building from ASM sources, I can simply expand the area used to store the levels. The following code will simply be pushed down into the area that was previously occupied by the sound engine. As doppleganger's source is completely cleaned up, with labels and defines for everything, relocation of code is completely transparent. (After relocating the sound engine, I didn't have to edit it at all.)