 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Rom Hacking:  hukka |
| Acmlm's Board - I2 Archive - Rom Hacking - Interesting Stuff...Changing a Mapper |
 |  |  |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
Rockman Flurry Level: 26 Posts: 203/250 EXP: 96387 For next: 5888 Since: 03-17-04 Since last post: 18 days Last activity: 16 days |
| ||
| I got a new computer the other day, so right now I'm using the new computer. Since my SMB3 hack, Mario Journey, is on the other computer, I'm taking a break from it to learn some more NES stuff. My interests right now are Mapper and TSA hacking. I read on DahrkDaiz' site that he added a MMC4 mapper to Super Mario Bros. in his Mario Seasons hack. I'm trying to reproduce what he did, in an attempt to learn more about the NES. Super Mario Bros. doesn't have a mapper, so I guess adding one can only mean for more possibilities. If you change 0x06 in the header of the ROM file, you can change the mapper. But depending on how the game works, according to Disch, you may have to change the game's original code, or possibly add new code to allow the new mapper to function properly. Adding a mapper to Super Mario Bros., without touching the rest of the code, surprisingly, the game still runs, however... The graphics are messed up. This is the title screen. This is the blank screen before you enter the level. This is the beginning of Level 1. Changing the mapper affected all the graphics except the sprites. If you want to know why the sprites weren't affected, take a look at the NES Tech document. I'm about to find out how to fix this up. I'll post new pics if I do. Just wanted to show you guys this, because this is very interesting stuff, and if you are interested in taking your skills further, read the NES Tech document and FireBug's document at Zophar's Domain. They are very useful. (edited by Rockman on 05-01-05 05:32 AM) |
|||
Dish Spiny Level: 38 Posts: 379/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| For common mappers I'd recommend Kevtris' page as your main point of reference: http://www.tripoint.org/kevtris/mappers/mappers.html Firebug's doc has several mappers which Kevtris doesn't cover, but Kevtris' docs are more recent/accurate. Especially if you're going with MMC1 or MMC3 -- Firebug's doc is pretty unreliable. Also be weary of mappers with bus conflicts (UNROM -- mapper 2, CNROM -- mapper 3, AOROM -- mapper 7, and other simple mappers) -- most emus aren't strict when emulating those conflicts -- but some are. If you choose such a mapper be sure to do reg writes properly -- and test it in several different emus (Nintendulator is probably the best to test with -- it sacrifices everything for accuracy). As for your graphics problem -- it looks like whatever emu you're doing is zeroing the CHR swapping regs (which is probably what its supposed to do). If you want to correct this problem you'll have to cut off the Reset vector and add some code which writes desired values to the CHR swapping regs -- it also might not be a bad idea to prep the PRG swap reg as well -- even though it doesn't seem to be needed in this particular emu. MMC4 is especially weird in this area because of its latch behavior -- tiles FD and FE are special tiles which automatically swap CHR when they're drawn to the screen. You may want to consider going with a more common mapper (MMC3 perhaps?). It always confused me why DD chose MMC4 for Mario Seasons. If you want to stick with MMC4 I can provide more details on how the latched CHR swapping works, if you're interested. |
|||
|
Rockman Flurry Level: 26 Posts: 205/250 EXP: 96387 For next: 5888 Since: 03-17-04 Since last post: 18 days Last activity: 16 days |
| ||
| Thanks for the information Disch. I have to tell you this though. I changed the mapper to MMC3, like you suggested, and the game runs fine! No graphical glitches what-so-ever. Thats good right? | |||
dan Snap Dragon Level: 43  Posts: 558/782 EXP: 534516 For next: 30530 Since: 03-15-04 Since last post: 20 hours Last activity: 14 hours |
| ||
| The hard part is actually expanding the game so you can actually make use of the mapper's features. | |||
|
Dish Spiny Level: 38 Posts: 380/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| It's good -- but unreliable. It comes down to how the emu inits the mapper regs. Register state is pretty much undefined on startup. AFAIK, the only thing that's for certain on the MMC3 on startup is that $E000-$FFFF will contain the last 8k of PRG. Everything else is undefined and should be prepped by the game. It just so happens most emus default to swapping the first 8k of CHR in and the first 16k of PRG at $8000, with the last 16k of PRG at $C000 -- satisfying SMB. However this behavior should not be relied on. So anyway -- to make this hack proper and stable across any emu (and on the real system) -- you'd have to have the Reset vector jump to somewhere in the hardwired bank ($E000-$FFFF) -- where you prep all PRG swapping regs before accessing any other PRG in the game. And you'd have to prep the CHR swapping regs before any drawing is done, as well (and before any data is pulled from CHR -- SMB reads title screen info from CHR-ROM, iirc, so you'd have to swap in the proper CHR banks before it does that). Anyway -- it's good that it's working -- but at the same time it's kind of bad because if the emu just happens to run the game without you having to do the required prepwork -- it may pull you away from doing the job right. Prepping MMC3 isn't exactly a small amount of code either -- it'll take a fair amount of free space (which I hear SMB doesn't have a lot / any of). Here's a sample of what you'd need to do. Note this should be in the hardwired bank ($E000-$FFFF) -- which the Reset vector should jump to first thing: That's a good 70+ bytes you'll need. Although you can problably shrink it by putting some stuff in a subroutine and JSR to it... but it'll still take a good amount of work. MMC4 would have considerably less prepwork to do -- but remember ANY mapper is going to require prepwork. Don't expect the emu's defaults to work all the time (even if they do!). EDIT: Optimized a bit. This uses 43 bytes: I think I have an idea of how to shrink it further....... EDIT again: down to 26 bytes. Lookup tables are awesome: That's about as small as I'll be able to get it. (edited by Disch on 05-01-05 07:41 AM) (edited by Disch on 05-01-05 07:47 AM) |
|||
|
Rockman Flurry Level: 26 Posts: 206/250 EXP: 96387 For next: 5888 Since: 03-17-04 Since last post: 18 days Last activity: 16 days |
| ||
| Seems a little complex. I'll try to put it to use though. But, how could it be hard to expand the ROM for this game to work for this new mapper? I have to add new code right? | |||
|
Dish Spiny Level: 38 Posts: 381/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
It may seem complex, but it isn't really. If you look at the 8 swapping modes MMC3 does:All my code does is insert the desired default values for all those modes. Swapping on the MMC3 involves 2 writes. First you set the swap mode with a write to $8000, then you write the bank you want to swap to to $8001.
Expanding the ROM is as simple as adding a bunch of extra PRG or CHR banks to the ROM (keep the sizes in powers of 2 -- 8k -> 16k -> 32k -> 64k, etc) and adjusting the header according. However actually USING these new banks does actually take some work -- and yes, it does mean you'll have to add some new code (this is what dan was saying earlier). CHR expansion is easy -- all you have to do is swap in the desired CHR bank and the graphics will change immediately (until another CHR bank is swapped in) PRG expansion takes a bit more work. If you want to access code/data in a new bank you made, you'll have to swap in that bank -- take what you need from that bank, then swap the game's original bank back in. |
|||
DahrkDaiz Red Super Koopa  Acmlm's Mosts 2005 Best ROM Hacker Level: 45  Posts: 632/885 EXP: 643520 For next: 16644 Since: 03-15-04 From: K-Town Since last post: 4 hours Last activity: 4 hours |
| ||
| And to make sure your bank swapping isn't interrupted by an... er.. interrupt! And yes, it CAN happen (and has happpened to me several times with my SMB3DX hack) so you'll want to make sure to modify the interrupt handling code to check for or back up any bank swapping that may be in the progress when an interrupt happens. | |||
Shadic Cukeman Level: 27  Posts: 243/304 EXP: 111073 For next: 5086 Since: 08-20-04 From: Somewhere, Over the Rainbow! Since last post: 9 days Last activity: 2 hours |
| ||
This mapper stuff is pretty interesting... I actually thought about doing the same thing.. Except I can't romhack.  |
|||
|
Rockman Flurry Level: 26 Posts: 208/250 EXP: 96387 For next: 5888 Since: 03-17-04 Since last post: 18 days Last activity: 16 days |
| ||
Originally posted by ShadicWell then...... What are you waiting for? READ. You will have a test on it tomorrow; 20 multiple choice; 10 questions; and a summary. Just kidding. But seriously, ROM hacking isn't that hard. If you have seen some hacks you like, and you would like to contribute too, just take some time to learn the basics. If you have some free time, and you are bored, look into it.  |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 4346/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Originally posted by Dahrth Vader Or disable interrupts.  |
|||
|
Dish Spiny Level: 38 Posts: 385/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Well SMB3 needs IRQs for the status bar to display right. But SMB doesn't use IRQs, so the I flag can stay high the entire time and it won't be a problem. |
|||
drjayphd Beamos What's that spell? pimp! Level: 56  Posts: 989/1477 EXP: 1387410 For next: 10766 Since: 03-15-04 From: CT Since last post: 2 hours Last activity: 2 hours |
| ||
Originally posted by RockmanOriginally posted by ShadicWell then...... Psst: The question about the proper ratio of cocaine to baking soda for making crack? You won't get that from that doc... guy who made the test was listening to too much Master P. It's 7:1. But read it anyway... it's quite informative.Originally posted by Rockman Yeah, basically, everyone has to start somewhere. Why not the basics? It's all you REALLY need... although you can do some fucking badass stuff when you change the mapper, as you can see. |
|||
Parasyte Bullet Bill Level: 35  Posts: 497/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
Originally posted by R2H2 It is often easier to look through the interrupt handlers for any code using the 'swappable' bank. For example, Metroid has a vector address in every swappable bank that is called during VBlank. So I stuck an RTS instruction in the vector, and no more interrupt problems. Disabling interrupts entirely could have had very bad effects (like slow-down due to not handling frame advances), not to mention it would just take up more PRG space. And as we all know, every byte counts. |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Rom Hacking - Interesting Stuff...Changing a Mapper |
| | |
