those videos on the beginning of the thread show playthrought in the game, so how did they do that, warp zones? or is this corrupted level passable?

Yeah, there are a handful of new enemies. Mostly they come from the original Mario Bros. I hope we are able to add them.

All this talk about level 4-4 made me decide to see what I could do with the corrupted section. At first I tried hacking in a little placeholder data, just to make the level passable. So I hacked in my data, dropped the modified level 4-4 in place of level 1-1 and gave it a test. To my surprize, it didn't render correctly. It seemed like it was skipping part of the data or something, so I did some experimentation. When I changed things around, it still didn't render correctly, but as I experimented, I came to the conclusion that at a particular column, it was rendering the data from a fixed point, regardless of the preceeding data.

Then I remembered that I had taken a brief glance at the 16 bytes of data just before the tile data in one of the levels and that they looked like accending pointers. At the time, I just filed it away for more investigation later. Now I had a pretty good idea what they where. So I checked them out a little more, and sure enough, they pointed to spots in the level data.

In particular, they point to the start of each 20 column chunk of the level. Note that although the game displays 20 columns per screen, these pointers don't line up with the screens. This is because the screens overlap, while the chunks pointed at, don't. (I wonder if the game at one point didn't have the overlap, or if it's was just a handy size.)

Armed with this new bit of information, I went back to editing the level. Sure enough, once I got the 20 column chunks to line up at the addresses pointed to by the headers, it rendered properly. Once that was done, I got to thinking that knowing the specific compressed and uncompressed size of the corrupted data could give some indication of what the missing data looked like, so I did some more experimentation.

The corrupted data covered the end of one chunk and the begining of the next one. The last level arrangement before the corruption was a small tunnel, so I experimented with that. I found that if I continued the tunnel all the way to the end of the chunk, the next chunk would end up in the right spot. At that point I was pretty happy, because, that indicated (to me at least) a very high probability that I had recreated that part of the layout correctly. The next chunk wasn't so easy, untill I had a breakthrough.

I had remembered seeing castle bits in the extra data at the end of some of the levels I'd rendered earlier. In particular, I remembered seeing a bit I knew for a fact was from level 4-4. (If you look at the extra data present at the end of many of the levels, it becomes apparent that once apon a time they where all filled in with one of a small number of levels.) So I started looking at the other levels.

I located the peice I had seen before, but it was of no use. It was part of the non-corrupted data. (Which makes perfect sense, how else would I have recognized it?) But, figureing that that level couldn't be the only one that once had level 4-4's layout, I kept looking. Eventually, I hit pay dirt. Amazingly, at the very end of level 5-1, there was a chunk of data that exactly meshed with the uncorrupt part of the second chunk. When I pasted it in, it filled all but two bytes of the chunk. It was pretty easy to figure out what those bytes where and once I did, everything went together smoothly.

Wondering if I'd actually figured it out, or if I was simply fooling myself, I gave it a test run. Everything seemed to mesh perfectly. In particular, the data I reconstructed had a room with two pipes in it, one enterance and one exit. When I went through the pipe that used to drop you to your death in the corrupted part, it now placed you neatly on top of the first pipe. I'd consider that a success.

As I ponder this, I can't help but think that it was way too convient for it to work out like that. Does this project have some kind of divine intervention or something? I have a more realistic theory, but it's still pretty shaky. What if, the floppy the image was ripped from had bad blocks, but was subjected to some sort of bad block relocation?

That would explain why the missing data was handy elsewhere on the disk. That doesn't exactly jive with the fact that the other levels have extra data, but the apparent souce of that data isn't corrupted. It also dosen't explain where the bytes I had to recreate by hand went. (Perhaps those blocks when bad after the relocation. Or perhaps they're around elsewhere, but I missed them.) Also, if that's the case, it doesn't seem to have been a standard practice. PC88WIN doesn't know anything about it, and happily serves up the bad data.

However, if it was block relocation, that could explain why some people may have gotten past 4-4. (I haven't checked out the videos to be sure.) Perhaps some other PC-8801 emulator (there are several) knows about such things and did the the right thing. (Or perhaps there's a better dump somewhere.)

Anyway, the point of this long post is that I now have a version of 4-4 that I'm about 97% sure is correct. I'll get a render of it posted some time soon.

P.S. I'll check out the video and should be able to give some more info on the enemy in question.

Also, since the original PC-8801 version of SMB Special was produced by Hudson Soft (under license from Nintendo), their trademark "bee" logo is seen towards the end of W1-1, which gives Mario the continue option (just as it does on Adventure Island for the NES).

damn Karatorian yer pwning this game lol.. even restoring corrupted data  :woot!:  i should have some free time to work on it this weekend so hopefully we'll have a playable world 1 or something

edit:  got 1-2 and 1-3 done.. gonna look at the castles and mod the ground sets.  also patched in an upside down pipe & red piranha plants patch from betaworld so that's done at least

edit2:
i was just thinking.. are buzzy beetles in this game?  if not they could be the barrells pretty easily

modified the ceiling bits and i also made a new title screen which is more in line with the original game

I think this should be a group effort, right now we got the guy trying to make the level renders as close as possible to SMB special, after that probably have to pass it off to some others who can make the ips patches, and try to get this as close as possible to the original. I'd like to see how close to the original we can get this.

I've managed to figure out almost all the movement codes. I'll give a little explanation of how they all work.

Normal Sprites

0x00    Not Moving
0x40    Moving Left
0xC0    Moving Right

Elevators

Elevator movement codes consist of two parts. The low nybble contains the elevator size and the high nybble contains the elevator's movement type. The direction the elevator moves in is controlled by the which one of the two elevator sprites is used and isn't encoded in the elevator movement code.

0x01    Medium
0x02    Large
0x04    Small

0x00    Self Moving
0x10    Falls When Stepped On
0x20    Sideways Self Moving
0x40    Left Half of Linked Pair
0x80    Right Half of Linked Pair

Firebar Sprites

Firebar sprites are also controlled by two parts. The first part is the sprites inital position. The Firebar animation has 16 positions. Position 0x0 is straight up and the positions proceed clockwise from there. The second part is the direction of movement 0x00 is clockwise and 0x80 is counter clockwise.

However, the inital postitions are somewhat misleading because the timing of how when you switch screens can affect thier positioning. This can even effect firbars that are offscreen. For instance, the third screen of 1-4 has two firebars that have the same inital position. However, they are only sometimes in sync. In my experimentation, the second firebar was usually a step or two ahead of the first one.

I'll see what I can do about getting some of this information incorporated into the renderer.

The two movement codes I haven't quite pieced together (mostly due to not checking them out yet) are 0x01 and 0xC0. The 0x01 is used by fireballs and inverted pirana plants. While I think for the pirana plants it simply means move down, I don't know what it means for the fireballs. The 0xC1 code is uses by parakoopas and cheep cheeps, I don't know what it does, but I figure the 0xC0 part means move to the left.

In regards to level 4-1, the info you've gleaned from the videos is correct. All the firebars in that level move clockwise and start in the up position. The elevator/platform is a large one and falls when stepped on.

Clearly, this is a group effort. There are a lot of things that people can do. I'm almost done deciphering the level data and after that I intend to look into ASM stuff. frantik is currently working on building the levels and I'm sure he would appreciate some help in that department. Once we start to hack in extra enemies and/or power-ups, we will need someone to make graphics for them. We will need play testers to check that everything works correctly and make sure that the levels are accurate. Plus, I'm sure there's some tasks I haven't even thought of yet.