nesdev.org

Hi All

I’m already aware that loopy converted SMB2() to MMC3, but its struck me that the MMC3 mapper is overkill for this game. As it’s a 64K programme, wouldn’t it be possible to just go straight to CNROM (or even MMC1), or was there some lynch-pin in the code that forced the MMC3 conversion from the original (FDS) code?

I’m still thinking of both converting some cart games to FDS and visa versa, and this may be a good place for me to start, but before I do, I’m wondering if I’d be wasting my time.
Thanks for any input!

CNROM can't switch PRG so you aren't going to get more than 32KB PRG out of it.

I haven't checked it, but does SMB2J use sprite 0 hit for its status bar (like in SMB1) or the cycle counting feature of the FDS system? If it's the latter I think it may be it a bit hard to convert to CNROM.

thefox wrote:CNROM can't switch PRG so you aren't going to get more than 32KB PRG out of it.

If PRG-ROM size is the problem, you could use GxROM, which can be easily constructed from CNROM through the rewiring of a few pins.

Still, there's much more to take into consideration than just the PRG-ROM size... Like Gilbert observed, the method used to display the status bar is one of them.

Yeah. I've just checked. SMB2J uses the cycle timer IRQ for the status bar. The IRQ routine is at $61A2. It would be just hard to put it in a mapper without any cycle-counting/scanline IRQ and it seems that MMC3 is the easiest to found mapper to have such a feature (not to mention that Sprite 0 Hit is a "polling" method and so game logic and timing may be messed up even after it's successfully converted).

Patch it to use the same status bar routines that SMB used and it'd probably be fine; I wonder why NCL changed it, but I doubt there would be many major timing inconsistencies unless the design is radically different from the original game... Now that I know this, it makes more sense that MMC3 was chosen though.

I mean, it's not a big deal (I have many FDS systems, so it's certainly not to benefit *me*), but a lot of people seemingly want it on cartridge (which has its own problems, see below), and I figured it'd be easier for them as CNROM or MMC1. The MMC3 patch is for the pirate cart version as I remember (and not the original FDS version) anyway, which used a custom mapper and that's why Loopy converted it.

One major problem with a cart version of the game is that whenever you beat the game, there is a write to the disk to add a star on the title screen. After you have eight stars, you can access World-9, so for a cart, you'd need to pre-program all eight stars, or never play the entire game, or you'd have to beat it eight times consequentially without losing power. The best way is to give it a save routine via battery-backed RAM, but this would require way too much recoding to be worthwhile.

It's amazing to think how differently designed the game is from the original, as it looks very little different, and the only really new innovation was the power-down system. The jumping mechanics can be patched into SMB with an IPS, so aside from poison mushrooms you could effectively turn SMB into SMB2(J) with a level editor, a bankswitched set of five extra levels and some pointers (after world 8 to L9, and after world D to actual ending). I wonder how much unused code there is, and what was left out of the game that had originally be tossed about as an idea. Flying was planned for SMB, but didn't actually appear until SMB3, and other things, like climbable objects in stages and bullets were dropped out of the original game, but some still have echoes in the code.

It might be fun to do that, actually. Then again, I think a 2-player IPS for the FDS version (retaining Luigi's jumping mechanics) would be more entertaining and certainly more useful.

2-player alternating? Why?

2-player simultaneous? Not enough palette space.

Xious wrote:Patch it to use the same status bar routines that SMB used and it'd probably be fine; I wonder why NCL changed it, but I doubt there would be many major timing inconsistencies unless the design is radically different from the original game...

Normally I'd agree with you, but the status bar in SMB1 is not very well coded. Since the game runs all its logic inside the NMI, when the game logic takes longer than a frame to compute it misses an NMI and things go wrong with the status bar (it shakes, and some say the game can even crash). Now, depending on the overall structure of SMB2j, that may or may not be a huge problem.

tepples wrote:2-player simultaneous? Not enough palette space.

I believe it is possible, as long as you do some color remapping. I wonder if the CPU could handle the extra work and not lag all the time, though. I mean, the game already lags when the enemy count is high, imagine what will happen if you add an extra player, which is much more complex than a dumb enemy...

tokumaru wrote:

tepples wrote:2-player simultaneous? Not enough palette space.

I believe it is possible, as long as you do some color remapping. I wonder if the CPU could handle the extra work and not lag all the time, though. I mean, the game already lags when the enemy count is high, imagine what will happen if you add an extra player, which is much more complex than a dumb enemy...

I agree. In a two-player SMB Your collision detection CPU usage would double, at least.. What sould happen if P1 jumped on top of P2? Or shot him with a fireball? Are these conditions to be detected? Are they fatal?

When I took my game from 1-player to 2-player simultaneous, the CPU usage jumped way up. My collision detection needs more than doubled. In my own game, when its just 1P, I have the following collisions to check for each frame:

1. Yar vs Qotile (or Swirl)
2. Yar vs Qotile's shield (to eat a cell, get bounced back)
3. Yar's gun vs Qotile shield.
4. Yar's Zorlon cannon vs Qoltile / Swirl.
5. Yar's Zorlon cannon vs Qotile's shield (removes cell)
6. Yar's Zorlon cannon vs each of the destroyer missiles (I added an extra one).
7. Yar vs each destroyer missile.
8. Yar vs his own Zorlon cannon (might be fatal or give +4 trons, depending on direction of travel).

Each of these checks is made using a rough hit-box, and if a collision is possible, the routine does a detailed pixel check (this part is expensive, but adds realism).

When there are two Yar's, double each of the above, and add:

1. Yar vs Yar (not coded yet, but they will bounce off of each other).
2. Yar's Zorlon cannon vs the other Yar (A vs B).
3. Yar's Zorlon cannon vs the other Yar (B vs A).

That being said, I would bet that many developers on nesdev could re-create SMB (or similar) from scratch, with simultaneous multi-player, if they were sufficiently motivated. And they could probably do a better job that the original authors. We have MUCH better dev tools than they had in the 80's.

Personally, I think that re-creating SMB as defined above would be easier than trying to hack the existing game to support 2-P mode.

clueless wrote:We have MUCH better dev tools than they had in the 80's.

Don't forget more knowledge about the platform. I'm pretty sure that developers back then were tossed into projects with little more than poorly written manuals about the PPU and APU. We have been studying the NES for years, and know a lot of details that programmers back then didn't.

tokumaru wrote:

clueless wrote:We have MUCH better dev tools than they had in the 80's.

Don't forget more knowledge about the platform. I'm pretty sure that developers back then were tossed into projects with little more than poorly written manuals about the PPU and APU. We have been studying the NES for years, and know a lot of details that programmers back then didn't.

Speaking of doing cool things on the NES... How is your Sonic-like game going? Got any updates, screen-shots, maps, etc?

tokumaru wrote:

clueless wrote:We have MUCH better dev tools than they had in the 80's.

Don't forget more knowledge about the platform. I'm pretty sure that developers back then were tossed into projects with little more than poorly written manuals about the PPU and APU. We have been studying the NES for years, and know a lot of details that programmers back then didn't.

Very good point. Although, I would have assumed that Nintendo's in-house dev teams would have had a direct line to the hardware engineering team...

When I was in college ('94-'99), my first semester programming class was taught by a really (40+ years) tenured professor. This guy was sharp, but an old fart. He tried to impress upon us that when he was younger code was manually encoded into punch cards. You only got one run per day on the shared main-frame to test your code. You _HAD_ to get it right really quickly, and without the benefit of debuggers, single-stepping, profilers, ICE (in-circuit emulation) or any of the tools that we have today. Back then, most developers poured over their code in print-outs, running it in their heads and on paper.

Fast-forward to the late 70's when developers were creating Atari 2600 games. Testing a game was time-consuming (burn an EPROM or use an expensive device with dual-port ram called a 'frob'). There was no easy way to "printf()" on the 2600 (maybe play sounds to indicate calculation results I would guess...) And the 2600 is much harder, imho, to code for than the NES. But those guys created some really intricate games. ET was written in 6 weeks. I think that Adventure took 6 months, I could be wrong though (I read Warren Robinet's interview on this once, a long time ago). Some 2600 developers had access to a 6502 simulator that ran on a PDP-11, but I don't recall whom it was.

By the time the NES was out, one could test non-hardware specific 6502 code on a variety of home computers.

Imagine how we would change our development habits if we didn't have emulators to test in. It is so easy to load a ROM image info FCEUX, set a break point, fire it up and examine the machine state. I'm totally spoiled doing this.

We have a large amount of docs, knowledge, a huge pool of fellow developers to collaborate with and really good tools.

I don't have an interest in making a SMB-like game, but I'm confident that several people here could do so given how much better the total developer experience is for us.

tepples wrote:2-player alternating? Why?

2-player simultaneous? Not enough palette space.

2-Player alternating. Even the concept of simultaneous play causes far too many issues. Why? To give players the ability to choose which character to use in 2-player mode, rather than just passing one controller back and forth, and to allow for more competitive play.

Or just for kicks.

I'm not sure I see any piont in a 2P-simultaneous mode. Look at how boned other games that use this medium turned out. 'Battletoads' is a prime example. Even 'Contra has its issues, like death by being scroll-trapped SMB just doesn't lend itself well to this kind of concept.

Many NES games were simply coded on the actual HW, some in real-time, like some FDS titles, via developer tools. Now we have faster systems to test code, debug and whatnot, but it also comes down to physical HW limitations. Unless you design a custom mapper, or rely on certain quirks, you can't do a lot without sacrifice components from harder-to-get games. Ideally, games should either use a custom mapper (the the coder creates), or use MMC1, as we can make them with new parts. Until we have an MMC3 or MMC5 clone, or better yet, a VRC6 clone we're not going to do anything too intricate, unless you want to destroy carts to make it.

Even so, you cant make t in any quantity, or indefinitely, as you'd be dealing with a limiting factor of availability and the cost factor of modding original games.

Xious wrote:One major problem with a cart version of the game is that whenever you beat the game, there is a write to the disk to add a star on the title screen. After you have eight stars, you can access World-9, so for a cart, you'd need to pre-program all eight stars, or never play the entire game, or you'd have to beat it eight times consequentially without losing power. The best way is to give it a save routine via battery-backed RAM, but this would require way too much recoding to be worthwhile.

Actually, that's exactly what I did. If you use a MMC3 cart with battery backed RAM, it will save the number of times you beat the game (it's the first byte in ram, if you want to try it out).

Oh my, that's awesome. Also, I'm glad to see that you're still around dude!