It is currently Tue Jul 16, 2019 5:19 am

All times are UTC - 7 hours



Forum rules


1. NO BLATANT PIRACY. This includes reproducing homebrew less than 10 years old, with the exception of free software.
2. No advertising your reproductions, with the exception of free software.
3. Be nice. See RFC 1855 if you aren't sure what this means.



Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Mar 06, 2019 1:04 pm 
Offline
User avatar

Joined: Mon Mar 30, 2009 4:40 pm
Posts: 316
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


Top
 Profile  
 
PostPosted: Wed Mar 06, 2019 2:13 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11375
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Wed Mar 06, 2019 3:39 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4151
Location: A world gone mad
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.


Top
 Profile  
 
PostPosted: Wed Mar 06, 2019 3:41 pm 
Offline
User avatar

Joined: Mon Mar 30, 2009 4:40 pm
Posts: 316
koitsu wrote:
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 :(


Top
 Profile  
 
PostPosted: Wed Mar 06, 2019 4:12 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4151
Location: A world gone mad
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:

Code:
    smb.nes              0xd445f698    0x8e3630186e35d477231bf8fd50e54cdd

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...


Top
 Profile  
 
PostPosted: Wed Mar 06, 2019 6:44 pm 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 943
Location: -29.794229 -55.795374
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.
Code:
811b027eaf99c2def7b933c5208636de  3337ec46  Super Mario Bros. (W) [!].nes

Maybe the Readme is incorrect?
Hope this helps.

Edit: The Readme's MD5 is for the headerless ROM.
Code:
8e3630186e35d477231bf8fd50e54cdd  Super Mario Bros. (W) [!].nes.bin


Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 12:41 pm 
Offline
User avatar

Joined: Mon Mar 30, 2009 4:40 pm
Posts: 316
Fisher wrote:
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.
Code:
811b027eaf99c2def7b933c5208636de  3337ec46  Super Mario Bros. (W) [!].nes

Maybe the Readme is incorrect?
Hope this helps.

Edit: The Readme's MD5 is for the headerless ROM.
Code:
8e3630186e35d477231bf8fd50e54cdd  Super Mario Bros. (W) [!].nes.bin


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.


Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 12:42 pm 
Offline
User avatar

Joined: Mon Mar 30, 2009 4:40 pm
Posts: 316
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


Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 2:03 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4151
Location: A world gone mad
nintendo2600 wrote:
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.

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).


Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 3:42 pm 
Offline
User avatar

Joined: Mon Mar 30, 2009 4:40 pm
Posts: 316
koitsu wrote:
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.


Attachments:
DSCF9046.JPG
DSCF9046.JPG [ 802.69 KiB | Viewed 4201 times ]
DSCF9047.JPG
DSCF9047.JPG [ 863.01 KiB | Viewed 4201 times ]
DSCF9042.JPG
DSCF9042.JPG [ 267.53 KiB | Viewed 4201 times ]
DSCF9041.JPG
DSCF9041.JPG [ 238.18 KiB | Viewed 4201 times ]
Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 4:00 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4151
Location: A world gone mad
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.


Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 7:26 pm 
Offline
User avatar

Joined: Mon Mar 30, 2009 4:40 pm
Posts: 316
koitsu wrote:
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.


Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 7:33 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11375
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 8:02 pm 
Offline
User avatar

Joined: Mon Mar 30, 2009 4:40 pm
Posts: 316
tokumaru wrote:
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 :)


Top
 Profile  
 
PostPosted: Thu Mar 07, 2019 8:25 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4151
Location: A world gone mad
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:

Code:
Source:  811b027eaf99c2def7b933c5208636de *Super Mario Bros. (W) [!].nes
Patched: d0443cd132e2642673599794ebd6ad75 *patched.nes

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):
Code:
4E 45 53 1A 02 01 01 00 00 00 00 00 00 00 00 00

System:       NES-NTSC
Board:        NES-NROM-256
PRG-ROM:      32k
CHR-ROM:      8k
Solder Pad:   H:1 V:0
Battery:      No
Dump:         OK

Header after patch:
Code:
4E 45 53 1A 04 01 13 00 00 00 00 00 00 00 00 00

System:       NES-NTSC
Board:        SxROM (non-standard), Mapper 1
PRG-ROM:      64k
CHR-ROM:      8k
W-RAM:        8k
Solder Pad:   H:1 V:0
Battery:      Yes
File:         patched.sav

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

Code:
 PRG ROM:    4 x 16KiB
 CHR ROM:    1 x  8KiB
 ROM CRC32:  0xb25c00ab
 ROM MD5:  0x682b381e2e8ea3a53ea2d201d9fbd15c
 Mapper #:  1
 Mapper name: MMC1
 Mirroring: Vertical
 Battery-backed: Yes
 Trained: No

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group