Actually, as Florent had commented about this, I think we ought to use the Sharp X1 version of the game as the foundation, because the X1 port is better overall as it actually scrolls from one screen to the other, as opposed to the PC88 port which flashes to black between screens.

~Ben

There seems to be a problem in 7-4 – this level doesn't quite match the original SMBS counterpart.

[EDIT: More detail... there's an extra page at the start of the level, page 4 (should be page 3) is mixed up – the pipe should be above the passage. And page 10 (page 9 in the original) cannot be passed if Mario is big, but that's not the case in the original.]

[EDIT 2: Almost forgot to mention... I'm using the 20090219 patch.]

That aside... what's the status of this hack? That is, what has been done so far yet not released, and what is yet to be done?

I have read the entire thread, though that was a couple of days ago. Somewhere in there I got the impression that some of the enemies were at least partially implemented. It also confirms that I have the latest available patch (there's a link to a 20090224 patch, but it's broken; however, I think the only fix in that was to allow it to run on an actual NES).

Still, just to satisfy you, I re-read from page 32. The main things that were planned but never happened seem to be the enemies, power-ups, and credits; however, there is mention that some work had been done towards implementing some of the enemies. I was wondering if anyone knew more specifics (eg, which enemies)

I have no idea whether the flagpole and drawbridge were lowered; no mention is made of this. Ditto for the modification of Bowser's behaviour, though I suspect that might have been done.

I ask because I'm toying with the idea of picking up the project, if I can find Karatorian's latest source. I'd really like to see this finished. (Side note: are either Frantik or Karatorian still around?)

No promises though.



Oh, is there some way to dump the levels from the NES version into images, so that they can be easily compared to the original? I know there are some notable differences, and I'd like to be able to see them all...

Sure.

That ceiling needs to be moved over two tiles, if I recall correctly.

In regards to anyone wondering about the status of this hack, consider it about done. Frantik has mentioned that he wants to fix a few bugs, but other than that, there's nothing going on.

As for myself, until I got the urge this morning, I was taking an indefinite break from rom hacking (sometimes it's just more fun (and less bother) to write your own code). As for planned, but unimplemented features (power-ups and enemies), nothing substantial has been done in that department. There is pleanty of room in the PRG for code to implement them and a scheme whereby the CHR rom could be bankswitched was developed, but it never really went beyond that. (A decision was made to push such features off to a post 1.0 release.)

If anyone is interested in carrying this project forward, I'll be glad to provide what support I can. In particular, I really ought to release the long promised 1.0 source release. (Provided it's agreed we've reached 1.0...) To that end I suppose I should work on cleaning up some of the custom tools used to build the hack. Hopefully I'll find the time soon.

Ok, the current source code is availble here:
http://static.karatorian.org/gaming/nes/smbspecial-src-20100306.tar.bz2

If you're interested, I've still got the data that I ripped from the x1 version. As I recall it's pretty much the same as the pc88 version. It consists of a couple of tools to extract level data and a set of images generated from that data.

Edit

I've been thinking about how to make the build process less convoluted. As it currently stands, it's quite the process to get it all working. The dependancies for a fully automated build are pretty involved. They are, at the moment:

• make
• cc65
• uips
• python
• various file utils

Of those, I think I can eliminate several of them.

Make is only required to automate the build. I have complete instructions in the source code package as to how to build it manually. However, given the complexity of the build proccess, it'd be a pain to pull off by hand. A less sophisticated automatic build could probably be made using a batch file or two and I'll look into setting that up.

CC65 is required as it's assembler is the one I used. It may not be strictly required, but to build a NES game from source, you need some assembler, so you might as well get the one I used. It's cross-platform and readily availible, so I'm not worried about this requirement.

UIPS is used by the build proccess to apply frantik's patches to get the ROMs to extract the level data out of. It's also used to patch the CHR image extracted from SMB. Any IPS patcher could be used, but UIPS has the handy convience of being command line based, so it can be used from a script. As any ROM hacker should have a patch utility, this isn't really a concern.

Python is required to run the level extracting utility. Recently I've been experimenting with PyInstall, which can make standalone applications out of Python scripts. It seems to work pretty well, so I should be able to release a Win32 version of the level extractor. Most Linux distros and OS X ship with Python pre-installed, so that should cover all the major platforms.

The level extractor isn't strictly required if you have the files it produces. However, without it, there's no easy way to edit the levels, so the source would be of pretty limited utility. Honestly, I wish there was a SMB level editor that was flexible enough to handle a ROM that been expanded like this. Then I wouldn't have to worry about is so much. I could just ship the binary blob and say, use editor such-and-such. Are there any SMB level editors with source availible?

The file utilities are the tricky bit. Generic stuff like copy and delete are easy enough, but the real stickler is dd. dd can do a lot of things, but it's basic function is to copy bytes from one file to another. It can start take offsets for the source and desination files and copies the specified number of bytes. Currently, I'm using it to extract a bunch of data from roms produced by frantik's patches. I'm sure there are similar tools availble, but unless I can script them from a batch file, that means the user has to extract the data by hand and that's tedious and error prone. (Plus it's just replacing one requirement with another.)

I'm currently extracting the demo, title screen, and scenery from the patched ROM. I could ship all of those as binary blobs, but then they become difficult to edit. I also use it to extract the CHR ROM from SMB (which then needs to be patched). I suppose I could ship the CHR too, but I don't know if that's wise. Any opinions?

I'm thinking of doing the following. In the Win32 package, I'll provide all the extracted data. The builder will be required to provide the patched version of the CHR (the patch is included). Then they'll be able to build it just by running a simple batch file. I'll include the standalone version of the level extractor. That should allow for editing the levels. If they want to edit anything else, they'll have to edit the binaries directly, or use whatever means they have to extract the data from the ROM they edit. That should bring the requirements down to cc65 and an IPS patcher. Any comments?

And it's up:

bz2: http://static.karatorian.org/gaming/nes/smbs-20100307.tar.bz2
zip: http://static.karatorian.org/gaming/nes/smbs-20100307.zip

So I guess this makes Beta 3. So test the heck out of it. Speaking of which, it's been so long since I worked on this, I can't remember, where there any outstanding bugs (on the ASM side of things)?