 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| Acmlm's Board - I3 Archive - ROM Hacking - Looking for SMB1 Info and Docs (contains info and addresses) |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | |||
QBRADQ Goomba                  Since: 01-18-06 From: Eastern Oklahoma Last post: 6634 days Last view: 6634 days |
| |||
| Hello all! I'm new to NES hacking (and hacking in general), however I do have a strong background in programming and a decent understanding of the 6502 instruction set as well as the NES arcitechture. Currently I am seeing what I can do with SMB1 ASM hacks to implement in my girlfriend's SMB1 project.
I've found some info on the net, such as Dahrk Daiz's smb.txt (partial map info) and the SMBRE (which I don't find just terribly useful). I also have a ton of docs for the 6502 and NES, think I am covered there. Anyway, there are some major deficencies in my info. Here's what I'm looking for: FCEUXDSP documents and useage guides (I still feel like I am not using it to the full potential). SMBUtil docs in English (mainly for my GF). Better map format and data descriptions (addresses would be fabulus!) General variable and table addresses, the more the marrier. Any hacks or docs involving adding a memory mapper to a MAP0 ROM. Any other tips or info you can think of. Anyhow, I'm still googling for all this information, but the going is slow. If anyone happens to know any of this info off-hand, or knows where resources are located that may be of assistance, that would help a whole heck of a lot. And seeings hows I'm asking for info, I might as well give some too, in case anyone is interested. Here's what I've found today: COPY/PASTE of personal note files ahead! Skip if you are not interested!
As you can see, I am finding some stuff out on my own. I'm also getting much more proficient at it. Any info / tips would be appreciated. Hope someone finds that info useful. 01/21/2006 - Edited code tags to use proper HTML bracets *slapps head* ... but now I can't turn off smilies... QBRADQ (edited by QBRADQ on 01-22-06 12:20 AM) |
||||
Raccoon Sam Boomerang Brother Custom Title    Since: 11-20-05 From: Correct Last post: 6283 days Last view: 6283 days |
| |||
| Awesome.
Tell us more about this stuff. It's interesting. |
||||
Googie   390  Since: 11-22-05 From: Corona Queens New York Last post: 6286 days Last view: 6286 days |
| |||
Well, I'm about to head out the door for work, but I hope this'll be helpful to you. Welcome to the board btw.  |
||||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6284 days Last view: 6284 days |
| |||
Hint:
|
||||
|
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6634 days Last view: 6634 days |
| |||
| @ HyperHacker
Like I said, it's a copy / paste 
@ HispanikPanik THANK YOU!!! I was able to find nearly a meg's worth of information from that one link! Things are starting to look good for me, as much of this information is stuff I was still hacking for. Should save a lot of time. Also, I suppose I'll elaborate on one point. One of the major things I am trying to do is to add a memory mapper to SMB1 to facilitate expanding the tileset, sprites, and level data. I don't know if it's been done before (although I suspect it has), however, here's how I see it going down: 1) Use the SMB Trainer hack to open up $7000 - $7FFF. 2) Replace the first OPT in the level loading routine with a JMP into a memory map manager sub near $7000. 3) Use that sub to swap out the page containing the level data (I think that's $C000+ page, have to check). 4) Excecute the first instruction of the loading sub, then JMP back to the second. 5) Finaly, at the end of the sub, JMP back into the $7000 page, remap the rom like SMB expects it to be mapped, execute the real last statment, then JMP back to the origional sub. That's what I have in mind ATM, but I'll have to do some digging to see exactly how this will all pan out. Thanks again for the link. QBRADQ BTW, when I'm ready to realease my notes in a distributable format, it'll most likely look nice. |
||||
insectduel Lantern Ghost Not welcome here anymore.  Since: 11-18-05 From: Bronx, New York Last post: 6526 days Last view: 6321 days |
| |||
| Try This http://www.freewebs.com/insectduel/smbstuff.htm as well. I'd plan to update more data after I found some data in Hyper Mario Bros. 5. Found the Palette and the Brick Scenery which I could Edit in any form and in any way.
(edited by insectduel on 01-19-06 01:00 PM) |
||||
|
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6634 days Last view: 6634 days |
| |||
| Thank you very much. The Level and Enemy Data is quite welcome. That should help me out as I try to decipher the pointer tables.
There are some things that I am having trouble with getting my head around regarding levels however. First off, in your list, only one underground bonus area is listed, however there are several in the game (four that I can remeber off-hand). Perhaps these four are four different pages of the same map? That would make sense to me, as there are only 34 table entries for object data in the ROM. However, there seems to be 38 entries for mob data, which is even more confusing (could be that the info I have is wrong, I'll verify once I figure out the pointer tables). Heh, just thought of a fifth bonus area. Anyway, great info. Thanks for the link. Once I have some more data and a comprehensable method of orgonizing and presenting it, I'll post it. Later, QBRADQ |
||||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6284 days Last view: 6284 days |
| |||
Originally posted by QBRADQ Use a monospace font then. |
||||
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6563 days Last view: 6563 days |
| |||
Originally posted by QBRADQ I don't know of any docs, really. However the process isn't too complex provided you know your 6502 and are familiar with the desired mapper. The hardest parts of such an undertaking are 1) Gathering the necessary free space for mapper-related code and 2) doing things "properly" and taking care of all the loose-ends. Just getting the game to work in an emulator is only half of the task -- since many emus will run games even if they have those itty bitty errors. Note -- if parts of this goes over your head feel free to ask for clarifications. I know sometimes I get overly descriptive and some times I'm not descriptive enough. The first step is to figure out what you'll want out of a mapper. More PRG/CHR, of course. But do you also want an IRQ counter? SRAM? Some mappers offer these while some mappers don't. The most likely candidates for mappers are: MMC3 (mapper 4) -- The most popular mapper -- allows for 8k PRG swapping, and mixed 2k/1k CHR swapping. Has RAM @ $6000, allows you to switch between Vert/Horz mirroring in-game, and has a scanline IRQ counter (however it causes some restraints on how you use your graphics, should you choose to use it). This mapper is very widely supported, well documented, and moderately easy to use. MMC1 (mapper 1) -- Another very popular mapper, but older, so it's more restrictive. Slightly bigger PRG banks (16k or 32k), much bigger CHR banks (4k or 8k). Controllable mirroring (Horz, Vert, or 1screen), and RAM @ $6000. The biggest downside to this mapper is how you have to write to regs -- it involves 5 writes to complete a full register write, since bits can only be written one at a time. This will make for a pretty hefty mapper-init routine and pretty large swap routines (you'll need a bit more free space). No IRQ counter. Very widely supported by emus, well documented, and a bit more cumbersome, but still pretty easy to use. Alternatively, you can go with MMC5 (mapper 5). This is the super-fantastic-ultra-powerful mapper which includes too many features to list here. The biggest issue with this is emu support (while MMC5 is supported by most emus, you are gambling with emu compatibility should you choose to use this mapper). Another issue is prep-work. There are a LOT of things you have to set up at the start of the game to get this mapper going -- and it will take a significant chunk of ROM space. Plus it comes down to "how much power do you need" -- and if all you're looking for is more PRG space, then MMC5 wouldn't be the best option, as most of its more advanced features will probably go unused. Sticking to basic features, though, this mapper (once set up), is frighteningly easy to use, and is extremely customizable (1k,2k,4k, or 8k CHR banks.... 8k,16k, or 32k PRG banks) and gives a bunch of little perks (8x8->16 multiplier, an extra pattern table when in 8x16 sprite mode -- giving you 512 tiles for sprites instead of the usual 256). After having a mapper picked out -- you'll need to move the Reset Vector so that it points to the hard-wired bank. This can be a problem with SMB, as it has the Reset vector going to $8000 -- which is a swappable bank on most mappers (all of above listed). Odds are you'll have to move it to $E000-FFFF, which means you'll have to free up some space in that area in the ROM. We're talking at least 20 or so bytes -- depending on which mapper you go with and how much prep work is involved (MMC3 will probably be the easiest here). In the reset routine, you'll have to do some basic mapper prepwork after the game shuts off the PPU, but before it jumps to a swappable bank or turns the PPU back on or draws anything. A typical reset routine might look something like:
I'm not sure how SMB's looks -- but it can't be too far off. Mapper prep involves setting pretty much every mapper register to what you want it to be. The contents of registers are unreliable at startup, which is why you should set them to what you want before you rely on them being anything specific. This pretty much means that you'll have to write to every mapper register at least once to set it up. You can see how this would be space-consuming for MMC5 -- since there's a bajillion registers. MMC1 is pretty consuming too... there's only 4 regs, but they each take 5 writes, so you end up having to make 20 writes. MMC3 can be pretty big too, but it's probably the smallest of the 3. I should note that with MMC1, before you do any reg writes, you should reset the MMC1 by writing $80 to any reg -- you only have to write it once (LDA #$80 STA $8000 will do) The most important thing to prep right away is the PRG registers. Once you prep the PRG regs you can jump to other banks which have free space. This should be the first thing you do -- and this is the part that should be in the 'hardwired' bank. After PRG regs are set up, you can jump to a free bank and do the other prepwork. Other prepwork involves setting CHR pages, mirroring modes, disabling mapper IRQs (unless you want them) and anything else the mapper entails. Like I said, this usually means you'll have to write to each mapper reg at least once. Once that's done, you just swap in the original banks (if you changed them) and you can return to the game's normal reset routine and the game will continue as normal. |
||||
|
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6634 days Last view: 6634 days |
| |||
| HyperHacker: Yea, that would have been smart. I did use code tags when I first put it in, just noticed I used square brackets though. Damn PHPbb has spoiled me Edited it, looks nicer but the tabulation is skwad.
Anyway, thanks Disch, that really helps. I wasn't entierly sure when the mapper init code should be called. As for where to put it, I was figuring on using a trainer for the mapping code (512 bytes, ain't too shabby). Also, your sumation of mappers has help me, as I have been having an uneasy time settling on one. Finaly, I thank you greatly for english MMC3 documentation
However, I am starting to reconsider this. I'd like to point out that this is my first major NES hack attempt. Only thing I've done before now are the basic newbie stuff, like removing the life decrement instruction. I'll go into the details of exactly why I am attempting this hack to give greater clarity, then explain my plan as of now. Perhaps someone may give sugestions based on this. Problem and Purpose: The purpose of this hack is to expand the levels in SMB1 as much as possible. While the number of worlds within SMB1 is limited to a maximum of 8 (due to several objects having only three bits to signifiy thier world of operation), the number of levels within those worlds appears to have a maximum of 256 when disregaring graphical artifacts during display, and a maximum of 9 when considering such artifacts. Finaly, all level data is referanced via soft-coded arrays of addresses, which themselves may be relocated with only minor effort, and thus expanded. However, the number of worlds and levels is not the consern, rather it is the content of those levels. In SMB1, the level data is layed out (mostly) in two byte chuncks, each representing one object or monster in the game. The ROM area dedicated to this level data is a continus area consisting of 4458 bytes, of which the first 1086 bytes are dedicated to monsters, and the final 3371 bytes are dedicated to objects. This is the only real limiting factor on what you can do with an SMB1 level mod project. My aim is to eliminate this limitaton, or more acuratly, to lessen this limitation. Proposed Solution: What I propose to do is to swap-out the area of ROM containing the level data durring the level incrementation process, thus giving the origional level handling code access to appropriote data durring the run of the level (this data is referanced throughout gameplay, one object and mob at a time). Execution: The following is assuming that I use MMC3 as the mapper for this project. This may change. Again Disch, thank you SO MUCH for English MMC3 docs! Also, note the lack of a trainer. Reading over those mapper and map specs again has given me some good ideas. Memory areas hA000 - hBFFF and hC000 - hDFFF will be swapable, however, only hA000 - hBFFF will be swaped out. This leaves the origional interupt handlers in hard-wired banks. This also allows a large amount of custom code to be in this hard-wired bank, because... The level data starts within the first 8K of ROM, then overlaps into the second. The last 724 bytes of the first 8K ROM segment consists of the level data pointer tables, folowed by level data. This will be overwritten with the mapper-handling code, a new (and presumably expanded) level progression table, new (and again, presumably expanded) level data pointer tables, and finaly a level-bank table (indicating which PRG-ROM bank contains the data for a given level). NOTE: Given that each level will require six bytes worth of table space (one for level progression, one for ROM bank indication, and four for data pointers), all these tables could be slaved off onto a dedicated ROM bank. However, this would require insertion of mapper management code in a few additional places (just before the game starts loading the level headers, when it re-reads a few tables, and before it starts processing level data). This is possible though, because the origional code stores the data pointers into RAM before loading data, and never referances the pointer tables durring gameplay. The area of CPU-ROM space containing our actual level data will hA000 - hBFFF. The first 3734 bytes of data here were origionaly used for the last chunk of level data. They will be overwritten with our level data, and the rest of the ROM information will be copied into each ROM bank (I know, it's not size-effective, and that irks my non-hacker soul, but hey, this is a hack ).
On a final note, all referances to the origional tables (excluding the world offset table, as that doesn't need to be (and in fact, can't be) expanded, and will stay in place) will be replaced with the appropriote offsets. This isn't a big chore either, because there are only a few instructions in the program which referance these tables. Overall Flow: NOTE: This assumes that the optional slaving-out of the custom tables onto a dedicated ROM bank is being used. Also note that this is all from memory, it's 0100h where I live, and I'm a little bit out-of-sorts, so this may not be entirely acurate. I'll give an update durring the acutal implementation. The RESET interupt will be redirected to our MMC3 init routine (which will live at h9D2C RAM). The start of this routine will be a copy/paste of the first few instructions from the real RESET interupt routine (starts at h8000 if interested). Following this, we'll set up the MMC3 and swap-in the appropriote banks (the correct hC000 bank mainly), and init whatever RAM variables are used. Finaly, we'll JMP into h8007, which will complete the RESET interupt routine, and RTI for us. At the start of the level incrementation process, one three byte instruction (most likely the LDA instruction itself) will be replaced with a JSR into our memory-mapping code. This mapping code will simply swap the hA000 bank out with the bank containing our tables. Finaly, the replaced instruction will be executed and then we'll RTS. Now, durring the level incrementation process (which happens on the last v-blank before the level or or world display starts) the game actualy reads in the headers for the level it's about to load (which happens before the first h-blank of the first frame of the level, odly enough). So, it's back to the mapper management code to swap-in the bank containing our level data, then back to the incrementation code. OK, now we're at the actual level loading code. This is the frustrating bit. For (apparently) no good reason, the game decides it needs to index a few tables again. So, we'll need to re-load the table bank, then re-load the level data bank before processing. That should be it. Project Managment and Development: Odviously, there is no SMB1 map editor that's going to understand my garbled mess of pigion shittle. Furthermore, I'm not going to spend the time to make one. That'd be re-inventing the wheel, all be it in the fourth dimension (like that makes any sense). Rather, map development will consist of the existing tools along with a few back-end support programs. Here's how I see it going down for the time being: 1) Load up a copy of the base ROM (In this case, the output of a working good dump passed through smb_fix by YY) in an SMB1 map editor. We are currently using SMB Utility. NOTE: I can't seem to get ahold of SMB Reformer, most docs I find are in non-germanic character sets, and all binary distrobutions have been encrypted (RAR + Password). Any link or sugested search string would be appreciated! 2) Edit some level to taste, and in acordance with the back-end support utilities (this will most likely be 1-4, as this level's data is the first to appear in both the OBJ data section and the MOB data section, and as such the addresses do not get mucked around by SMBUtil. 3) Use the back-end software to strip the level data from the ROM image. The software will then output the raw level data, a new copy of the ROM bank to contain the data, and finaly output a new compiled ROM with appropriotly updated tables and addresses. NOTE: This software will be writen by myself. Heck, compaired to NES hacking, x86 C++ looks as simple as HTML to me now
Nice Side Effects of this Method: One of the nice bits about this hole thing is that by using a mapper, CHR-ROM banks could be specified on a per-level basis, and swaped out appropriotly. The potential for this should be odvious. Specificaly, in our own useage, sections of the game would have particular themes corresponding to the storyline (which will be, I assure you, very simple and to-the-point like any good platformer title with a story). Also, I was kind of hoping to swap out music data on a per-level basis. However, the music data for SMB1 happens to be stored in the high/high PC address space (hE000 - hFFFF), and that can not be swaped-out by MMC3. I suppose the music pointers could be mucked around with, though I haven't read up on it (and I do have the docs). Anyway, it's not a big concern. Neither I nor my partner have any desire to modify the music, even though I do have the educational background. My compositions sound like poop anyhow. Finaly Notes: I really hate that I typed all this up, and yet messed up on some terminology. This whole time I refered to everything as levels. As far as SMB1 is concerned, a level is all the gameplay between level and world incrementations. Most of the time when I have refered to a level (specificaly level data and level pointers and addresses, exclusive to level increntation and level progression) what I was really refering to was maps. This is actualy why the game re-reads pointer tables at map-load, because in some cases these map-loads are not preceeded by level incrementations. This is the case in all bonus maps, and possibly at other times. OK, I've made some long forum posts in my time, but that's by far the longest. I'ma save this one localy
Any ideas? Faults? Suggestions? The main things I am concerned about are the choice of memory mapper (MMC3) and the implementation (the Overall Flow section). QBRADQ |
||||
|
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6563 days Last view: 6563 days |
| |||
Originally posted by QBRADQ This cannot be assumed to be the state at powerup. For example -- doing that setup (making $C000 swappable and $8000 fixed) will make $8000 immediately swapped to the 2nd-last 8k of PRG in the ROM... however most emus will start emulation in the other mode ($8000 swappable, $C000 fixed), and will default $8000 to the first 8k of PRG. However... note that on startup, EITHER mode could be in effect, since the game has not yet specified by writing to the mapper... and the state of mapper regs is undefined at powerup (could be random). So ANY 8k of PRG could be swapped in at $8000 on startup -- there's no way to know which (or at least, it's not safe to assume). But this comes down to how anal you want to be. It's pretty much a given that most/all emulators will put the first 8k of PRG at $8000 on startup... but some people (such as myself) might consider that to be very sloppy to rely on that behavior. With MMC3... the only area guaranteed to be at a fixed bank is $E000-FFFF -- which will always be the last 8k in the PRG (and you'll note if you look at any commercial mapper 4 game -- all their reset vectors are always within that range). This means that if you want to be 100% proper, you must change the reset vector to somewhere in that range and free up at least a few bytes to set PRG swap modes and maybe swap in your desired PRG banks. Other vectors (NMI, IRQ) don't matter... since they won't be used until after you've prepped everything anyway (so whatever area they point to will have the proper bank swapped in when they're jumped to).
If you know where it is and are able to move it, this would be an ideal place for your new reset routine. With enough space you could stuff PRG/CHR swap routines in there too... get that over with as well.
You could take it a bit further and swap CHR every X frames for animated backgrounds ;D. CHR swapping is a great thing. You mentioned something about using a trainer to hold some prepwork (but then later you turned around and said you weren't going to do it, so I'm a little unsure on what you are planning regarding that). At any rate, I would seriously advise against using a trainer, as it would be problematic in newer emulators (trainers are sort of a defunct/depricated "feature" of iNES, and may not be supported by newer emus). The rest of your plan looks good from what I can tell. I'm not all too familiar with SMB specifically, but you seem to be on the ball and are keeping an eye on all the loose ends. It's nice to see more people with real talent come into the picture ;D. Best of luck to you on this, man. |
||||
|
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6634 days Last view: 6634 days |
| |||
| Thank you for the input. As far as the trainer goes, I've decided against it, mainly because I was unsure of how it would interact with the WRAM bank of the MMC3. Now with your input on it, it's easy to stick to that decision.
I have some docs on the music and where it's at, but honestly I can't understand what I'm being told. *sigh* I just did a code log of all the music in the game (including saving the princess in 8-4), but forgot to save it as a data log. Only got the stripped .NES. Anyway, looks like all the music is in fact used. Anyway, I am fairly sertain that I can just take out the referances to a few bars of music, and put some mapper init code there. Just enough to set up the mapper and ensure that the correct bank is at h8000. I really wish I knew what all that data after hE000 is, but so far the only thing I've found is the music. Anyway, I'll write up the mapper init code here in a bit to see exactly how much room I'm going to need. Perhaps the princess theme will large enough to hold it. If not, I'ma have to have a new plan. OK, next post should be my mapper code. Hope someone out there can tell me if it'll totaly mess everything up
EDIT: Also, I have a question regarding the memory mappers. On the origional hardware, the largest board with MMC3 had 512K PRG-ROM and 256K CHR-ROM. Are there limitations like this on emulators? And if so, how do I know what those limitations are? Thanks, EDIT: Ok, here's the code I'm planning on putting in (30 bytes total)
Any problems? Other than where to put it
QBRADQ (edited by QBRADQ on 01-22-06 04:52 PM) (edited by QBRADQ on 01-22-06 05:19 PM) |
||||
|
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6563 days Last view: 6563 days |
| |||
| That should be good for the minimal PRG swapping stuff -- although you should probably disable IRQs and should DEFINATELY swap CHR banks in and set mirroring (quite a hefty bit of work). Although this stuff doesn't need to be put in the hardwired bank, since you can swap to a free bank (if you expand the ROM), then JSR to it and finish all your prepwork crap and RTS back.
You might even be able to put some of that other init stuff in the swapped bank too, if you're really pressed for space. Assuming you expand to 64k PRG, using 8k banks (page 7 is the last 8k in the ROM) ... I'd probably do something like the following:
I wasn't sure exactly which pages you want where, since having $C000 swappable makes it pretty weird, so I just flipped around $8000 and $C000 from the "norm". When this code completes you'll be set up with the following: - PRG page 6 @ $8000 - PRG page 1 @ $A000 - PRG page 0 @ $C000 - PRG page 7 @ $E000 - Vertical mirroring - cartridge RAM enabled and ready for use - first 8k CHR swapped in ppu$0000 in normal ascending order - MMC3 IRQs completely shut off (until re-enabled via a write to $E001) This code uses 20 bytes of the hardwired bank, and several bytes of a free bank (page 3) -- I didn't count how many. It could probably be optimized some more, but I figure since it's in a completely new bank you won't be pressed for space. |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - Looking for SMB1 Info and Docs (contains info and addresses) |
| |
