NES code portability

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
Secamline
Posts: 44
Joined: Sat Aug 15, 2020 4:25 pm

NES code portability

Post by Secamline »

Hi everyone!

Since it's the holiday season I watched Home Alone 1 & 2 for the hundredth time. This reminded me of the video game adaptations made at the time. Specifically Home Alone 2 which was ported both to the NES and the SNES. The graphics and sound are different but other than that it's pretty much the same exact game.
So I was wondering, considering that the SNES's 65C816 is compatible with the NES's 6502, when porting a game from the NES to its successor, can the code that handles the game's logic simply be "pasted" into the new game? In fact I ask myself the same question every time I play Super Mario All Stars.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: NES code portability

Post by calima »

"Mostly", "it depends". Organization is different.
User avatar
Secamline
Posts: 44
Joined: Sat Aug 15, 2020 4:25 pm

Re: NES code portability

Post by Secamline »

Ok I see. At least now I know it's possible to some degree.
Does anyone know if SMAS shares some pieces of code with Super Mario Bros. 1 through 3? (I don't expect anyone to know about the terrible Home Alone games though :wink: )
User avatar
Dwedit
Posts: 4921
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: NES code portability

Post by Dwedit »

Super Mario Allstars SMB1 and Lost Levels managed to have one notable bug not present in the NES version: When you break a brick, you get *sucked in* to the brick instead of bounced back from the brick.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
strat
Posts: 409
Joined: Mon Apr 07, 2008 6:08 pm
Location: Missouri

Re: NES code portability

Post by strat »

EAD's first SFC project was porting SMB3 so it's likely that game at least is mostly the same.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: NES code portability

Post by psycopathicteen »

Is VRAM arranged the same way on both versions of SMB3?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES code portability

Post by tokumaru »

psycopathicteen wrote: Wed Dec 30, 2020 11:50 am Is VRAM arranged the same way on both versions of SMB3?
I doubt it, considering the weird height of NES name tables. But that's the kind of thing that's expected to change between ports anyway, while the game logic has a much better chance of being reused.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: NES code portability

Post by psycopathicteen »

tokumaru wrote: Wed Dec 30, 2020 12:03 pm
psycopathicteen wrote: Wed Dec 30, 2020 11:50 am Is VRAM arranged the same way on both versions of SMB3?
I doubt it, considering the weird height of NES name tables. But that's the kind of thing that's expected to change between ports anyway, while the game logic has a much better chance of being reused.
I mean, are the tiles and sprite patterns in the same spot?
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES code portability

Post by rainwarrior »

psycopathicteen wrote: Wed Dec 30, 2020 2:14 pm
tokumaru wrote: Wed Dec 30, 2020 12:03 pm
psycopathicteen wrote: Wed Dec 30, 2020 11:50 am Is VRAM arranged the same way on both versions of SMB3?
I doubt it, considering the weird height of NES name tables. But that's the kind of thing that's expected to change between ports anyway, while the game logic has a much better chance of being reused.
I mean, are the tiles and sprite patterns in the same spot?
Mesen-S seems the best tool to compare this.

It still has a "two screens high" arrangement, but there's 3 layers now instead of just 1, and it's wider than the screen now, so it has no seam.

The tiles have a similar arrangement, but they are redrawn in 4bpp and aren't constrained to pages of 256 tiles. The MMC3 bankswitching function to animate them seems to be duplicated with DMA.

So I don't know if that's a "no" or a "yes" to your question that probably deserves a much more complicated answer.
puppydrum64
Posts: 160
Joined: Sat Apr 24, 2021 7:25 am

Re: NES code portability

Post by puppydrum64 »

In theory you can but of course the memory mapped locations for NES and SNES are different (I assume) so you'll need lots of conditionals. Chibiakumas.com is a good place to get started with this sort of thing. Keith's 6502 test roms are built to run on any 6502-based system.
User avatar
za909
Posts: 248
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Re: NES code portability

Post by za909 »

This kind of "direct port" might actually be more possible to the PC Engine. The console is capable of mimicking most NES mapper capabilities pretty well, and the entire system is very much like an NES on steroids. The CPU itself is similarly a 6502 successor, so you just need to redesign the code that interacts with the hardware and you're almost good to go. There are ports of the Mega Man games for it, which turned out pretty functional.
User avatar
nia_prene
Posts: 17
Joined: Sat Dec 04, 2021 2:50 pm

Re: NES code portability

Post by nia_prene »

Yes game logic is portable, but anything with rendering is going to need to be altered. I would imagine Nintendo kept some logic code from SMB1-3 for SMBAS to cut costs but interacting with the SNES PPU is quite different from the NES. This is one of the reasons why game makers insist on keeping game logic separate from rendering, it allows for portability, as well as keeps new designers from backing themselves into a corner with frame caps, bugs etc.. If time and budget were not an issue, rewriting logic would be preferable as the SNES has some very useful added op codes and registers.

From what I have read, Nintendo actually spent some time trying to make the SNES backwards compatible (correct me if I am wrong) and that is why we have identical registers for reading controllers, but eventually abandoned the compatibility to compete in the console with a more robust system. Overall, yes the code is portable from a cost/dev perspective but absolutely not from a "copy-paste" perspective.
Post Reply