Descargar SxROM Mario Bros. ROM Hack

SxROM Mario Bros.
    -readme-

~*~*~*~*~*~*~*~*~*~*~*~


Table of Contents


	I) What (the FAQ)

	II) Specs

	III) Routines


~*~*~*~*~*~*~*~*~*~*~*~


I) What (the FAQ) 


"'SxROM'. Wtf is that?!?"

	It's a family of NES cartridge boards, all of which use MMC1.


"Wtf is MMC1?"

	"MMC" stands for Memory Management Controller. It's how Nintendo produced games that were technically more than the NES could handle- by putting additional hardware *on* the individual cartridges themselves!


"Oh, okay. What about the '1'?"

	MMC1 was Nintendo's first attempt at creating a MMC, and it was a pretty good one. A lot of the early classics used it: Zelda 1, Zelda 2, Metroid, Kid Icarus, Ninja Gaiden, Mega Man 2 and Final Fantasy (not to mention all four Dragon Warrior games).


"What about all the other NES games?"

	Other MMC's were created over time to allow for whatever game designers felt was necessary to adequately execute their game(s). That said, MMC1 and MMC4 were hands-down the most popular.


"How many?"

	It's hard to say for certain, but the number is probably in the low triple-digits. Some were only used once, for a single (and usually obscure) game. Some were only used on games not released outside of Japan. Others were proprietary MMC's used exclusively by third-party developers.


"Wtf's a third-party developer?"

	Any company producing games for a first-party developer (Nintendo, Sony, Sega prior to Y2K). Capcom and Konami were probably the two most popular third-party developers for the NES. 


"So who's the second party?"

	You, teh consumer. (It could be argued that homebrew NES games are second-party creations by second-party developers.)


"Is 'MMC' the same as a 'mapper'?"

	Not exactly. The words are used somewhat interchangeably, but the term "mapper" is used to refer to how various NES emulators replicate the features of specific MMC's. Mappers are basically virtual MMC's.


"So what's this all got to with Mario?"

	The original SMB1 was one of the few games that didn't need any extra whizbangs hidden on the cartridge to run properly. That made it efficient to produce, but caused problems about a decade later when ROM hacking came into the picture.


"What problems?"

	Well, for starters, SMB1 is notoriously tight on space. There are a few unused bytes scattered around the ROM, but nothing large enough to really do anything worthwhile.


"WTF is you talkin' about? SMB1 is the most hacked ROM on the planet!"

	True. But the vast majority of those hacks are just graphic/text replacements. 


"Nuh-uh, man. I've seen hacks with all new levels, freezing iceballs, autoscrolling... I even seen one where some lunatic replaced the entire soundtrack with early-90's European buttfuck music!"

	(...ahem, thank you!) There *are* impressive hacks out there, but they all had to either: (A) rewrite entire sections of code in order to make room for their changes, or (B) expand the ROM.


"..."

	Exactly. ROM expansion is the process of creating empty space entirely out of thin air, then integrating it into the original game. It's doable, but it's something that takes a fair amount of precision to do correctly.


"Any fuckwit can just add 00's to the end of the file."

	Yep. And those same fuckwits can sit and watch as their emulators refuse to read the new data, glitch up during gameplay and/or refuse to play entirely.


"So, what then?"

	First off, mapperless games such as SMB1 need to be assigned a mapper in order to gain the ability to bankswitch.


"WTF is bankswitching?"

	The NES is only capable of visualizing 32k of program code at any given time. Pretty much every game created after 1985 contains more than 32k of data. Bankswitching allows us to swap blocks of data in & out of the NES' field of vision at strategic points during gameplay.


":-("

	Look at it this way: the NES is like your computer monitor in that there's only so much you can see at once. The mapper is like your taskbar at the bottom of the screen, and the programs/files you've got lined up down there are the individual memory banks. When one of them becomes super-relevant, it can be brought to the forefront. When its importance wanes, it's either minimized or obscured by another window. 


":-|"

	Right. Now, imagine life without a taskbar. That's the position SMB1 is in. Its entire 32k code is locked in place by virtue of genetics. Even if we add extra data to the end of the ROM, there's no way to swap it in during gameplay. Thus, it might as well not even be there.


":-S"

	This patch converts the original SMB1 ROM to MMC1 to be used as a template for more ASM-heavy hacks. It features a 16kB bank of swappable PRG-ROM free for development. Additionally, the music/sound handler has been moved to its own bank, allowing for significant musical expansion as well as freeing up over 3kB of space in the hardwired bank!




II) Specs


	Here's a handy layout comparison of the original SMB1 ROM and SxROM Mario Bros. (Address ranges are as they appear in hex editors, header NOT included.)


Bank		SMB1			Function
-----------------------------------------------------

0		0000-3FFF		(lower bank of PRG-ROM)

1		4000-7FFF 		(upper bank of PRG-ROM)


~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~


Bank		SxROM Mario Bros.	Function
-------------------------------------------------------------

0		0000-3FFF		(SMB1's Bank-0; no changes)

1		4000-7FFF		(free space)

2		8000-BFFF		(pAPU routines; mostly free space)

3		C000-FFFF		(SMB1's Bank-1; 3296 bytes of free space)




III) Routines


	1) New Reset Vector

SMB1's reset vector was $8000. SxMB's reset vector is $FFD4. This is to allow for proper handling of the CHR-ROM, as well as various Register-0 elements. The routine is as follows: 






	2) Bankswitch Routine

SxMB is designed to swap out 16kb banks in the [8000-BFFF] range. To perform a bankswap, load the Accumulator with the desired bank number, then JSR to $FFC0. The Bankswitching Subroutine ends with RTS, so make sure your code is set up accordingly.

Also, because all audio processing occurs during V-blank, and because the entire sound engine has been relocated to Bank 2, the NMI routine has been altered to swap back to Bank 0 upon completion of pAPU execution. Those wishing to make use of Bank 1 would do well to establish some kind of ......


	3) pAPU Handling

The original SMB1 performed all audio processing during V-Blank. SxMB goes the extra mile by relocating the entire sound engine to its own data bank. The relevant portion of the NMI has been altered accordingly, as well as a minor detour to facilitate the 3296 contiguous bytes of free space at $F2F0.


As an added bonus, the data addresses you see while editing in a hex editor are identical (header notwithstanding) to their in-game appearance. (In other words, if a certain song's data begins at $B300 when viewed in Translhextion, it'll also be viewed as $B300 by the CPU during gameplay.)



~*~*~*~*~*~ Floppyright 2012 ~*~*~*~*~