Here's what you can do at the moment. Watch the videos posted on YouTube and then download them using keepvid.com. Then get Replay Converter and convert them to WMV, and then if you have Sony Vegas you can save the shots.

Just played 1-1, it's nice to see the level done on an NES, when I get around to it, I'll work on the title screen tomorrow, it won't be fancy or anything, just trying to help motivate the hack to be done... ^______^'

...

Here's the screen, I can't sleep until the meds kick in...



Like I said it ain't anything fancy...

Whoops, I forgot to upload the file so here.

G'nite! ^^'

I'd be interested if the format is not too complicated. I could probably even automate the ripping and inserting, provided you get any missing features hacked into the engine. PM me and we can discuss the details.

Edit:

I did some looking and made a little progress. The disk image format the ROM is in is kinda arcane and it took me a while to get any info on it. I eventually had to poke around the source code of an obscure utility that convered another disk image format into d88. Here's what I've learned so far. (Some of this may be wrong, there are no docs that I could find.)

The disk is split up into 256 byte sectors, which each have a 16 byte header. This means each sector takes up 272 bytes in the disk image. The disk image also has it's own header, which is 672 bytes long. Empty sectors are marked in a strange way. If the sector is empty, it's filled with the same byte as the third byte of the sector header.

Using this basic info, I coded up a little util to do some handy things. The first thing I did was compile a list of non-empty sectors. These sectors are broken up into four chunks as follows:

With this information in hand, I started some experimental hex editing. I guessed that chunk 0 was some sort of header or bootstrap and that chunk 1 was proably the program code, so I started with chunk 2. I seem to have been at least a little bit correct.

I zeroed out all of sector 640 and started the game up in the emulator. I immediatly died due to time up, although the level layout wasn't changed (at least on the first screen). Oh well, at least I'm on to something.

I also did a quick look to see if i could locate the game's graphics. (Not that you'd likely have any use for them, but I was curious where they are. I suspect chunk 3.) I didn't find them, but that's no real surprize. The tool I was using only supports 1BBP, NES, and Gameboy formats. I guess I'll need to locate a more featurefull graphics viewer and give it another try. (Or someone here who's feeling ambitious could do so).

My primative tool also has support for dumping the raw sector data without the headers. This might be an easier format to work with than the original as you don't have to deal with skipping the headers every sector. Which would make doing things like using a graphics tool or disassembler (the CPU is a Z80 clone BTW) more productive. If anyone is interested, I could post the dumps I made, just ask

Anyway, now I'm off to do some more investigating.

Due to a brain fart on my part, the above map of what's empty and what has data is incorrect. While looking through the massive list of pages that my proggie said had data in them, I didn't pay enough attention and only spotted the major gaps. My code was fine, but the manual post proccessing I did was totally bogus.

The particular details are that chunk 2 and chunk 3 are actually a bunch of smaller chunks and are likely all level data. As I was hacking on the level data, I noticed some blank pages where listed as having data on my map. So I checked my software and it was fine, but my wetware was buggy (I'm starting to suspect each of the groups of non-empty sectors (there's about 28 of them) starting at sector 640 is a single level.)

I'll get a better map posted sometime, but in the meantime, I can report that I'm making some progress. While I can't be sure of the details yet, I'm managed to decipher some of the basic map data. Apparently, the maps are stored using a basic run length encoding scheme.

Single tiles are encoded as a single byte. Runs are encoded by starting with a byte that has the length of the run minus one anded with 0xC0. (So a run of 2 is C0, a run of 3 is C1, etc.) Following the run indicator, there is a byte that indicates the tile to be repeated. The map appears to be stored vertically in rows of 12 tiles. As the game displays 12.5 tiles, I'm currently missing something.

I'm currently working on mapping out what tile is what. I've also managed to find the enemy data and the some other level data, but I haven't tried to decipher it yet. Other than the time limit, which, for level one is at 0x02AAB3. (From the looks of the enemy code, it uses a similar RLE scheme.)

If you want to mess around with the level data, the first level's tile data starts at or around 0x2ACD0. Be careful of the sector headers, I don't know if the emulator cares if they're correct or not, but it's proably best not to mess them up. The two sectors before that contain the enemies and other level one data. The chunk that straddles the sector border is apparently the enemy data (zeroing it out removes all the enemies). The stuff before that in the first sector of the level (sector 640) is some other stuff. (Probably special events like pipes.)

Hack and enjoy.

I've made some more developments. I've discovered that I slightly misunderstood the RLE. The lenght of the runs is one longer than I though it was. It's actually run_byte ^ 0xC0 + 2. With this information, things started to make a lot more sense. It turns out that the level is stored in columns of 13 tiles each, which solves that little mystery. One complication I've ran into is that each level seems to end on a run indicator byte without a following tile. I thought some special value which only looked like a run indicator was being used as an end of level indicator, but the one I got for levels one and two aren't the same, so I'm not sure how that works at the moment. Perhaps there's a level length indicator in the data I haven't looked at yet and the last byte is something else.

I've written a little utility that dumps a level's tiles out to an uncompressed binary file. I've also included an option to render the level as a PNG, mostly to check my results. So far they seem to be good. If you want, I could post the renders of the first few levels so that you can verify the results.

If you want to check out the level data, the tile data starts 0x220 bytes from the start of the level data. (This is not counting the sector headers, which my current tool chain strips out before doing anything else.) For instance, level one is stored in sectors 640 to 649. If you extract those sectors from the disk image (without the headers), the tile data starts 0x220 bytes from the start. This is in the third sector of the level, with 32 bytes of some other data before the tile data.

So far, I've been able to locate level data by using my program to find groups of non-empty sectors. While this works, it's a kludge and I'd like to be able to figure out how the game itself locates the data. There's proably some sort of pointer table, but as it's stored on a disk, I don't think it'd be quite as simple as the usual ROM pointer tables. Is there anyone here who knows their way around a Z80 thats willing to take a look at the code? (If not, I think my method will work, but it's rather ad hoc.)

Next up on my adgenda is looking into the enemy data. I've got a pretty good idea where it's located, so I've simply got to figure out it's format. After that, I guess I'll have to see if I can figure out what any of the other data is.

Anyway, I think I can write a program that'll output the levels in a conviently usable binary form, but I'm not so sure about converting them to SMB format. From the little bit of looking I did into the format, it seem to be pretty complicated. I could proably do it, but it'd probably be easier for someone who knows how to deal with the format already.

In that case, it would be good to have a discussion of the interchange format the two programs should speak. SMBS basically stores it's maps as grid of tiles, while SMB stores it's maps as a list of objects with coordinates. I'd prefer to simply output a grid of tiles and let the other program deal with turning them into object lists.

Do any of the SMB level editors have support for a save format that's a grid of tiles, or do they all just store things in SMB native format?