Super Mario Bros Special SLROM or SKROM?

Hey all,

Been a long time. I've forgot if the SMB Special hack is actually needs ram a la SKROM or is it just a vanilla SLROM?
NES Mapper program I was using is saying it's got ram but I wanted to double check here that it wasn't just a false
positive as I've had that happen in the past where some software has detected files as needing ram when they didn't.
SMB Special came to mind as being one of these false positives I had in the past. Been so damn long since I messed
with this title I figured I'm better off just asking

Thanks,

Shawn

I don't know about this hack in particular, but a regular old iNES header doesn't say whether games have WRAM in the cartridge. If the ROM has an NES 2.0 header though, then a tool can indeed tell you for sure whether the cartridge needs WRAM. If you wanna know for sure, you can always open the game in an emulator that lets you inspect RAM (FCEUX, Mesen, etc.) so you can see if there's any activity in the $6000-$7FFF range.

Please provide the exact link to the exact hack you're talking about. There are quite literally hundreds -- I am not exaggerating in the least -- of hacks of Super Mario Bros.

https://www.romhacking.net/hacks/527/

And if that does actually use ram does anyone by chance know of one that doesn't?

EDIT: I had a friend double check and this version I linked to does in fact need the PRG RAM

This patch is for a very specific SMB ROM that does not seem to exist any more, or possibly was "correct" but had wrong bits in the header. The patch README includes the CRC32/MD5 of the ROM that its intended to be patched against:


Let's just say that in a particular repository of nearly 14,000 ROMs, including bad dumps, absolutely none match MD5 8e3630186e35d477231bf8fd50e54cdd. We do not trade ROMs on this forum, so...

I think I've found your ROM.
You must search for Super Mario Bros. (W) [!].nes
That's the one that matched the md5sum and the crc32 that's on the RomHacking page.

Maybe the Readme is incorrect?
Hope this helps.

Edit: The Readme's MD5 is for the headerless ROM.

I wasn't looking for a rom but thanks for looking none the less. I already have the rom I only posted the romhacking patch link to show which game I was talking about.

OK so I a little change of pace here. Does anyone have a pinout for adding PRG RAM to a SLROM pcb? I've done this before with a TLROM board to add ram to an MMC3 game but I've never done so with MMC1. I've tried google and the search function here on the forum but haven't found what I'm looking for. I'm sure a couple address lines will have to be routed to the mapper chip but I have no clue which.


EDIT: I've found this on an old ROMLAB mirror. This should do it

https://image.slidesharecdn.com/romlabo ... 1408061043

Fisher's response was to me. Apparently I wasn't clear with my comment, so I'll explain:

You're asking about a romhack that provides an IPS/UPS patch. For me to find out what this romhack does to the header -- if anything -- and thus answer your original question, I have to apply the IPS patch to the appropriate source ROM of SMB.

The README that comes with the romhack gives the checksum of the original source ROM they based their patch on (it is important you only patch the IPS patch against the proper source ROM -- that's why they gave the checksum in the first place). But I could not find this exact ROM in over 14,000 ROMs.

Fisher pointed out that the IPS patch is against the headerless ROM, i.e. a raw .bin file, which also means the README is lying (it states the filename is smb.nes not smb.bin; .nes files have a header, raw .bin files do not).

OK, sorry for any miscommunication.

So I built up a board and it works for the most part. It's acting almost like it has horizontal\vertical mirroring mixed up but there is no h\v on this board or at all with any MMC1 boards that I recall. I've attached pictures of my work in case something stupid is eluding me. Video shows what I mean better than I can describe. Maybe I've not routed the ram correctly? I believe I have though which is why I'm stumped. What I'm describing can be seen the clouds for example but it'w much worse when in use. The playfield doesn't line up or appear as it should at all.

I made a short video but it went over the 5mb attachment limit. Hoping what I've shown will tell the tale well enough.

Are you sure this romhack has been tested on actual hardware before?

And you're correct, there is no H/V solder dot on MMC1 -- it's controlled by 6502 code that tweaks the mirroring directly in real-time.

Yes I built this up on a real cart in the past. It's been a few years but I have made it successfully before.

What does the header say about NT mirroring? Sometimes cartridges bypass the mapper-controlled mirroring and go for a hardwired configuration. If that's not the case, make sure that the software is initializing MMC1's mirroring correctly, not relying on power-on settings.

OK Thanks. I've taken the cart apart for now and I'm making something else with the parts. It was just on a whim that I thought about making this SMB Special. Thanks for all the replies

Re: built this on cart in the past and it worked: Excellent, that's good to know.

I finally figured out the patch idiocy. I had to read the patch README closely. The checksums they give are from FCEUX, which for whatever reason decides to give checksums of only raw PRG/CHR (i.e. without header), which makes the checksums given very confusing. The IPS file is intended to patch against the actual .NES file, the romhackers just chose to use "FCEUX checksums" in their README. Here are the proper file checksums of everything:


Anyway...

The difference as you know between SKROM and SLROM is that SKROM contains an 8KByte SRAM chip for PRG-RAM, mapped to the $6000-7FFF region. I have no idea if the romhack would use/need the extra RAM for anything -- if so, it could potentially explain bugs, like if they were storing MMC1 register values in temporary variables located there. Let's try to find out.

The pictures you provide aren't fully indicative of the problem, but I *think* I know what's being depicted -- when you scroll horizontally, the screen has a weird sort of "half-scrolled catch-up" thing going on. Yeah, that's usually wrong mirroring. Let's get into it further. I'm using NestopiaUE 1.49. The game does play fine. Here's the details:

Header before patch (i.e. stock SMB):

Header after patch:

You'd think it wants horizontal mirroring, but I'm suspecting not (given that it's a horizontal-scrolling game). Let's check FCEUX:


Cute -- vertical. This could be from an internal database that's forcing the mirroring though... so which mirroring is true? Let's keep using FCEUX to find out, which lets you force/set mirroring in real-time:

Upon loading the game in FCEUX and getting the title screen, I checked the mirroring under Nametable Viewer. It's set to Vertical (this option can/will change based on the 6502 code that configures the MMC1). I play a bit -- it's still vertical. If I switch the mirroring to horizontal in the GUI while at the title screen, and then start the game, I get the exact behaviour (I think) you're describing -- a kind of broken/half-scrolling method that's wonked out.

So in summary:

1. This romhack actually uses vertical mirroring, best I can tell. If triple verification is needed, I can happily go look at the MMC1 writes for mirroring and determine from that. But vertical makes the most sense, IMO.

2. This romhack claims to need PRG-RAM, which means you need to use an SKROM board. Whether or not the battery is needed is unknown to me; maybe this romhack retains high scores? I don't know. If a battery is needed, this link can help: https://wiki.nesdev.com/w/index.php/SxR ... _retention . I checked inside of FCEUX's debugger + memory viewer -- there is a lot of data in the $6000-7FFF range, so this game definitely needs PRG-RAM.

Otherwise, Wizardry is an example of an SKROM game that has a battery. There's probably others.

HTH.

Do notice that the information you posted before says "Solder Pad", not "Mirroring". The solder pad labels on Nintendo's PCBs refer to name table arrangement, which is the opposite of the mirroring nomenclature used by emulators. So what you're seeing here is actually consistent: the solder pad marked "H" results in the name tables being arranged side by side, and mirrored vertically. The solder pad marked "V" would stack the name tables vertically, mirrored horizontally. It's very confusing that whoever created the iNES header went with "mirroting" instead of the convention that was clearly used in the PCBs.

However, since the MMC1 has dynamically controlled mirroring, the H/V setting in the header does nothing. Unless some emulator is using that information when it shouldn't.


The emulator might be selecting vertical mirroring automatically (by default or from the header setting), which an actual MMC1 isn't guaranteed to do. Only debugging will tell if the mirroring is being properly configured.

I was curious about the 6502 code aspect of it, so I used Mesen. At boot, it does tweaks MMC1's registers like so:


Maybe it changes things later on (as stated, you can change mirroring dynamically with MMC1), but yeah, vertical.

I've always remembered it as: "vertical mirroring is more intended for horizontally-scrolling games, horizontal mirroring is more intended for vertically-scrolling games". I assumed that the H and V on the solder pads correlated with that. Gah. This explains a couple decades of confusion that I'd run into on occasion. Yup, too bad Marat didn't just call the NES header bit "screen layout" or "nametable organisation" to correlate it with the silkscreening. Ah well, at least from an actual address range perspective it makes sense.

Thanks!

Hey!
I had a similar problem when I did my translated Legend of Zelda repro.
I think the pictures in this post shows nicelly what I did.
I'm not sure if I had cut any track of the PCB, and I can't be sure by looking at the picture, but I can happilly check it tomorrow, when it's day here.
Of course, if the OP still cares.

I've been explaining what I call the "nametable arrangement" nomenclature in previous posts dating back to roughly January 2009. The oldest extant revision of the "Mirroring" page on NESdev Wiki also contains "arrangement". (I can't tell when or by whom that was added because edit history prior to June 2009 was lost.)

I guess the "reverse" engineers lived up to their name by reversing the terms.