As promised, I've cleaned up the source code and am providing it here for interested hackers. Also, I've produced a new patch which incorporates the small changes I made while cleaning it up.

On the surface, nothing (should) have changed. Under the hood, things are a little bit different. I restored the level looping code. We don't need it, but I figured that others might be interested in the ROM expansion for thier own projects, so that makes it easier on them. I also made a few minor code changes, mostly to organize things nicely and to optimize a few inefficient hacks.

Now that I've gotten that out of the way, I guess I'll have to go back to my orginal "next step" and fix the inverted pipe graphics.

Cool, I'm gonna play these patches before hitting the bed.  :thumbsup:

EDIT: I found this bug...



Stuck in a brick *Laughs like Peter Griffin*

I played through both patches, everything else went smooth...  :beer:

Are there any complete maps of both the original PC88 version and this version? If not, can they be made availiable? I want to be able to look at both versions side by side w/o playing them or watching videos.

There is one thing about the .PY file in the TOOLS directory: Python support in Windows 98 isn't supported anymore. So you might have to rewrite it to another language!

I would go with the programming language called Euphoria. It supports a whole lot of OSes, Including Windows.

(or make an EXE using PY2EXE, Although it is not even a good idea in windows 98)

In regards to Python not being supported on Windows 98, well '98 is no longer supported by Microsoft either. My position is that Windows is unsupported by my code. Sure, seeing as it's written in Python and I avoid OS specific modules, it should work wherever Python is supported, but if it doesn't I don't loose much sleep over it. While it may seem elitist, I got fed up with Windows back when I was running Windows 95, and I've never looked back.

One thing I did consider doing, but decided against was to provide the contents of the "data" directory to provide easier build support for non un*x users. In retrospect, perhaps I should have done so.

As for rewritting the level extrator in another language, I have no interest in doing so, especially if the only reason to do so it for '98 support. Python is my language of choice and I only code in other languages if there is a compelling reason to do so. I don't feel that in this case there is.

In regards to the new blocks, I actually started my investiagion by looking at DecodeAreaData, so I know how to handle that part. Additionally, I've looked at the metatile stuff and the BumpBlock routine, so I've got a pretty good idea as to what's required to add new blocks.

However, on further investigation, I've discovered a few things that may complicate matters. SMB object IDs are seven bits long. However, for normal objects, they're divided into two classes. If any of the upper three bits of the object ID are set, the object is considered a Large Object. If none of the upper three bits are set, the object is a Small Object.

This effectively limits the number of Small Objects (which blocks are) to sixteen. SMB uses twelve small objects, all which we need. In addition we need seven more blocks. This presents a bit of a problem. However, five of the additional blocks are all hidden blocks containing the (rare) new power-ups. I've considered several methods whereby all five of these blocks could be represented by a single object. How exactly that would work out depends on whether any given level or world requires more than one of them.

I've considered two methods. The first would be to simply hardcode the power-up based on the current world (or level, if required). This would proably be the simplest, but it'd be inflexible and wouldn't work if any level requires more than one new power-up. The other method I considered is to use an unused special row object to set the power-up type. This would be more flexible, but it would require a free byte of memory to store the power-up (memory is pretty tight in SMB, but I could use the SRAM) and would expand the size of the level data by two bytes for each special power-up.

The other snag is that the bump block code expects the block objects to be a sequencial range of IDs. Unless I can come up with a work around for this, adding any blocks would require renumbering three objects, specifically, the WaterPipe, EmptyBlock, and Jumpspring objects. I'd rather not do this as it'd require even more special effort on the part of anyone editing levels for the modified engine (frantik in the case of our port).

However, I think I can work around the issue by allowing the block handling code to treat these objects as blocks, but simply ignore them. I've yet to investigate whether this will cause any issues, but I think it should work. It's not as clean as I'd like, but renumbering existing objects seems be a bit excessive. (I'd do it if it was a solo project, but I have others to consider and would prefer not to break too many existing tools.)

So anyway, that's the state of the investigation in adding custom blocks. I'm going to go hack the code and see if what I've figured out in theory works in practice.

Oh, and one last thing. The current source release and expanded patch are missing one change from frantik's patches. The size of the platforms isn't fixed at six tiles. It's a pretty easy thing to fix, but I forgot all about it.

If you wish to port the level extractor to another language, feel free to do so. The struct module is used to access raw binary data, which, as a very high level language, Python doesn't have direct support for. Basically, struct.unpack turns a string containing binary data into Pythonic high level types and struct.pack does the opposite. What sort of data it deals with is specified by the format string. For the full details, see the struct module documentation. While it looks complicated, it's actually pretty easy to use.

Please keep in mind that the level extractor isn't the cleansest code around. In fact, if it weren't basically required as part of the SMBS for NES build proccess, I wouldn't have released it in it's current state. At some point in the future, I intend to clean it up, make it's features more generic, add a user interface (command line, of course), and package it as a general purpose SMB level manipulation utility. At such time I will proably release stand alone binaries (created with Freeze and PyExe) in addition to the source release.

Finally, I've yet to decide on a license for the level extractor or other original source code produced for this project. While the SMB dissassembly and most of the modified code are derivative works of Nintendo owned code and are legally grey or outright illegal, other code, such as my mapper drivers, the level extractor, and the build scripts are all copyrighted by me. The current copyright notice on this code, "All Rites Reveresed", is a placeholder that will be filled in with a proper licence statement once I decide on a licence. That said, I will be using some sort of open license, so anyone producing derivative code in the interim will not suddenly be denied the right to do so.

On a different matter, my work on the block code was interrupted by other conserns, so I haven't produced any results as of yet. I hope to get at least some work done on it later tonight.

To assist frantik with building his own level extration tool and to allow building of the ROM by persons without Python, you can download a pack containg the level data here.

The level data is spit into two files. One is a ".bin" file containing the level headers (pointers, etc.) and data, and the other is a ".s" file containing machine generated ASM code that defines lables required by the main source code and other administivia. The generated ASM is included in two places in the source proper. Due to some conditional compilation options, the file does different things at these to locations.

The first place in in the main banks where there the level data originally was. Here it defines a number of lables and includes the portion of the binary that contains the level headers. The other location is in the dedicated level bank. Here it included the level enemy and object data. (Which is copied into SRAM on boot up.)

The reason that the level data was split from the level headers is that the total size is greater than 8k, so it wouldn't all fit in SRAM. By leaving the headers in the main bank, the level data proper fits into the SRAM.

The SMB level headers are fairly complex and not documented anywhere I could find. If you need any help understanding their format, please let me know. (I've been thinking about writing a comprehesive doc on the SMB level data format, but it's only one item on a long list, so it may be some time before (if ever) I get around to it.)