Register | Login | |||||
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
| |
Acmlm's Board - I3 Archive - - Posts by QBRADQ |
Pages: 1 2 |
User | Post | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I 1Z 1337 H@X0RU W111 A11 D13 BV M3h G1u3 M3h ROMZ ND PR0NZ!!11!1!
But seriously... Hello all, my name is Brad. I'm a long-time programming and emulation enthusiast, yet oddly enough the two have never met untill now (accept for some minor NES ASM, but whatever). Anyhoo, now I'm doing some SMB1 hacking, and loving it. I come to this board because it seems to be the only place where ROM hacking is still discussed out in the open. I come for pointers and tips, and to share what I have figured out and have yet to discover about one of my favorite NES games, Super Mario Brothers. Look forward to hearing from you guys, QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 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) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
All very relevant questions, not just to the ROM hacking / modding / f'ing-with community, but to the IT community as a whole. For instance, a friend of mine describes himself as a hacker, yet he has never used a hex editor (calls it archaic (however you spell that fancy word for old and outdated)), programs in Visual Basic (of all disgusting things, if you can even call that programming (I call it scripting)), and struggles with C++ (like it's that hard).
Even more wide-spread is the usage of deriviatve forms of the word, such as hacking. As in "He's really hacking away at that router", or "I hacked my Counter Strike so that all my enimies are birght red (When I did that, I called it cheating )". Am I a hacker because I reverse-engineer NES ROM dumps (for the past week I might add, I'm new to this)? Am I a hacker because I use nested parenthasise in forum posts? Am I a hacker because I misspell every other word, have issues with my mother, drink a butt-load of Dr. Pepper, and can quote Star Trek: The Next Generation episode numbers and titles from memory? Or am I not a hacker because I keep long-lasting and loving social relationships? In 1981, a Hacker was a distinguished human-being, one worth capitolizing his referance title even. In 1981, a Hacker was that guy that was always poking around in your companies main-frame, talking with his (few) friends about 0E something-or-another, and toggleing-in opperatinoal base-systems (now called Opperating Systems) at the control console from memory. Then, in the mid-80's, a Hacker became that guy on the evening news that got busted stealing millions of dollars from a bank and going to jail for a long time. Then, even stranger, in the early 90's a hacker (notice the lack of capitolization) became that guy on the evening news who crashed a bunch of computer systems. Then in the mid-90's, the entire paradigm was shiffted, the box became many, and the suits prevailed (I'm making fun of managment terms by the way, f'ing little... yea, it's a public forum, so...). (h)ackers became crackers, crackers became white males, people that new what the hell was going became "IT Professionals", and hackers were again elite people, but now they wore funny hats like Carmen San Deago. Ahh, the late 90's. .COM stocks crashed like the Hindenburg, more CEOs committed suicide than Nazi officers durring the Nuriburge trials, and tech intersets when into a recesion unheard of since "The Grapes of Wrath". Crackers became people that made pirate copies of video games, white males were once again refered to as honkies, twelve-year-olds t@!k1nG l!3k tH!3 asking you're ASL in a Yahoo chat room became 1337 hackers (who never once attended a 2600 meeting, like that makes a differance anyway), and people that knew what the hell was going on became "Computer Terroists". Now, a Hacker is a poser, someone trying to get attention by calling himself a criminal. There are still those from the old-school that admit to being a hacker, but rarely will they boast of this fact in public. People that know what the hell is going on are call "People that know what the hell is going on", people that can barley alter the IP tables on a Windows server are called "Network Administrators", people that use Linux are call "That odd kid in the back", and anyone that can alter a program with nothing but a hex editor are called "smart". So, am I a hacker? HELL NO! Am I a programmer? No. I'm just a guy, a 22-year-old kid trying to make a living. I administer Windows servers, and they call me a "Network Technician". I alter NES programs with a debuger and a hex editor, and I'm call a "Nerd". I write C++ programs on the Windows platform, and people have the audacity to call me a "Programmer" or "Coder". I'm just a lucky guy. I know who I am, what I do, and where I stand. I am Q damn it! And not that shit from Star Trek! I administer Windows for a living (like that's hard). I review hex dumps and play NES games and Call of Duty 2 for entertainment. And finaly, when I hack into SMB1 and show my loving girl friend how to alter a level's data, I'm "The greatest geek-man on Earth" I am Brad. I do stuff, and this stuff might envolve hacking. But I am not a hacker, I am Brad, or Q if you don't know me in real life. Umm, OK, so I am bored. Here's the only opinion I have on the subject: Using SMB Utility to change the levels of SMB1 (no matter what you do with it, as long as you only use SMB Utility) you're a modder. That's right, just like those guys that make the AWP in Counter Strike do even more damage, or make a Quake 3 MOD where every hit is an insta-gib. You are a pansy in the overall scheme, though we may enjoy you're work. Those that are elite, and deserve to be called a hacker, are either so odvious to "Those that know what the hell is going on" that they need no title, or secretive to the point that you'd never know who they are. Then again, that's just my two coins. QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 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) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
You could just get a full-sized keyboard and hook it up. That's what I always do | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yea, so pansy was the wrong word. Basicaly I was trying to say that by using an editor, a person is mearly using the knowlage of the rom that someone else has packaged into a nice GUI. That person is not, however, learning anything about the underlining process.
Someone who gains the knowlage required to actualy do these things is doing something more significat. However, unless that person shares said knowlage with the community, they contribute nothing, and are themselves insignificat. Finaly, just because you change a ROM with a hex editor doesn't mean your changes are any good. And on the other side of that coin, just because you used a game editor and are ignorate on the underlying process, doesn't mean your work is bad. Really what I was getting at with that whole long post was that the elite never say they are, and that most of the elitists are little whiny bitches. The ignorant may contribute to the masses, and thier work may well be enjoyable. The fact that they are ignorant does not detract from thier work. However, the truly elite contribute to not only the masses, but to the ignorant as well, by making thier work posible. Anyway, I don't really care what you call it. Modifing any software through any means that was never intended to be altered by a third party is hacking I suppose. I just think modding is a more fair term to use for those who use pre-made applications alone to change the game (more fair to both the person who made the application, and to the person doing the modding). So, like I said before, I may be hacking SMB1 at the moment, but I'm no hacker. Not only am I not on par with those origional Hackers in terms of skill or understanding, I also have no desire to attract that kind of attention to myself. I get credit for my work, but it comes in the form of my friends and family enjoying my efforts, not from posturing to a bunch of people online. That being said, I like you guys and appreciate your comments, suggestions, and help. QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Umm, I'm sure we all apreciate your efforts, but for the above to be useful to anyone, the gramar needs to be worked on a lot.
I'm not trying to flame you or anything, I'm just saying you might want to slow down and read over your work, and try to make it a bit more comprehensable. If that's not possible for some reason, someone here may be willing to do a post-edit if you'd like. QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yea, that's a lot more readable. Thanks for the info, I'll have to mess around with that sometime. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hi there.
If you want to get into NES / editing, grab FCEUXD SP, which is by far the most awsomesque NES debuging environment on the face of creation. As far as NES docs, check out nesdev.parodius.com. That site's got just about every non- specific doc there is. Finaly, if you happen to be into SMB1 haxorizing (sorry, behind censorship firewall ATM) , I can e-mail you a nice collection of docs. Later, QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LINK -> VBA Homepage | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Xenesis, if you're needing general infromation on how to use cheat searchers and debugers, you might want to have a look at the following link.
Also, interdpth, you might also want to take a look to see how these tutorials are orgonized. Link to romhacking.net << Very long URL Anyhoo, these tutorials cover using FCEUd to implement a few hacks on NES titles. They cover modifiying the jump height in Metroid, implementing a password generator for The Adam's Family: Puglie's Scavanger Hunt, and finaly reverse-engineering the graphics compression in The Goonies II. I know they don't directly cover hacking techniques for the GBA, but they do give very good info about how to properly abuse a good debuger. QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Welp, it looks like I'm going to be leaving SMB1 alone for a while. Too much real life (and SMW) getting in the way. So, I figured I'd share with you all what I've figured out about SMB1's map data and how it gets addressed.
Ok, I realize this is quite long (and unfinished). If you're already familiar with SMB1 map hacking, then you can probly skip down to section 5. The main thing this document brings to the table that has been a mystery in the past is how the map address tables are indexed. In his document, Dahrk Daiz leaves only the addressing in the dark. Basicaly this document fills in the gaps. Hope you all enjoy! Also, how would I go about submitting this to acmlm.org when I get around to finishing it? WOW! The forum really did a number on the HTML OpenOffice generated :D I'll try to figure something out... EDIT: Here's a link to a MS 97-XP .doc file. Much easier on the eyes. It's Geocities though... Can't read a DOC? Tired of MS Office? OpenOffice.Org is the answer :D SMB1MapData.txt by
This
S-1
S-2
Before
Basic
SMB1 This
Mushroom
These
The
This
Warp
These
Warp-Zone
A
Game
Level A
This
Map A
Again,
World A
Map
Castle
The
Ground
Sometimes
Underground
Underground
Underwater
Even
Basically,
S-3
S-4
S-4-A
Level
QBRADQ (edited by QBRADQ on 02-02-06 05:07 PM) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Well, here's my two coins:
I started h@ck1ng SMB1 because my girlfriend wanted to make a level mod. We messed around with it for a few days, and then she lost interest (first time working on software, she didn't realize how much work is involved ). After that, I continued working on what I was doing (map data addressing, adding a mapper, etc). SMB1 isn't exactly easy, depending on what you want to h@ck. The music data is straight jacked, and the map data addressing method is so convoluted (and in some places, redundant and bugged) that attempting to mess with it without the aid of a pre-existing editor is a real pain. Anyway, I suppose the main reason why I liked h@ck1ng SMB1 (and now SMW) is the fact that there isn't too much to change. The mechanics of the g@m3s provide a simplistic method of play, the enemies by themselves provide a mild element of danger, but the levels are where it's all at. Change the levels, leave everything else alone, and you can make something much different (and hopefuly more enjoyable) than the origional. The only real problem I see with people using SMB1 as a spring-board into is the over abundance of bad examples. There are so many truly terrible SMB1 hacks out there that many may get the impression (as my girlfriend did) that making nearly impossible levels, replacing the graphics with stuff that looks like cr@p, and throwing hammer brothers all over the place equates to a good hack. Thus, the cycle of svck repeats. Anyway, I'm looking into some other, less abused for the time being. Till I sink my teeth into something, I suppose I'll be fairly quite. Always reading here though PS: I'm at my vocational school ATM, behind censorship software remincent of Red China. Hence the @'s and 3's. QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
*Warning: Over Confident Coder*
I'd put my money on the idea that the Big N's SPC does not support the interupt routines. And when you think about it, why would it? The SPC is itself controled via interupts from the main CPU. We are talking about the SNES's sound processor right? The SNES is a lot like the NES, right? Maybe I should read more... QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Wow Hyper, I actualy agree with you That's really how I got into ROM h@cking to begin with. My girl wanted to make her own levels for SMB1, so I got in on the back-end. Personaly, I prefer making SMW levels (more flexable), but hey
QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sounds fun. qbradq .at. gmail .dot. com
I could process quite a few chunks. My system doesn't do anything for 16 hours a day (no net access at the house yet ). QBRADQ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QBRADQ Goomba Since: 01-18-06 From: Eastern Oklahoma Last post: 6645 days Last view: 6645 days |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hello again.
Umm, I thought I had been posting to this board over the past few weeks, but none of the posts have gone through. Not sure what that's about, so I will be monitoring this one closely to see what's going on (possible I was forgetting to hit "Submit Thread" on the preview page). NOTE: Using snes9x1.43.ep9r8 Anyway... what brings me here to ask for help is something that is frustrating the heck out of me. I'm hacking into an SNES ROM that's almost untouched (I'll be telling you what game it is once I have enough info to post). I've been looking for the map data, but had to start out with the few values that I knew. So, I found the RAM locations for enemy stats and the like, then traced where those came from in the ROM. Then, I figured out how this data was indexed, and where the index is stored in RAM. However, I've now hit a wall while trying to trace where the index values are loaded from ROM. I've set a write breakpoint for 7EE83D, which is the RAM address of an enemy index value (8-bit, P->M=ON), but the breakpoint never trips. I can open up the hex viewer and watch the value change as expected, yet the breakpoint doesn't trip. Only on rare occassion (when the enemy loaded in at 7EE800 - 7EE9FF drops an item) does the breakpoint trip. At this point, the index value is set to 0xEA (possibly others, I've only seen this happen twice) no matter what the index value of the enemy was. So... I used some creative save states and the "Frame Advance" feature to get a full CPU trace of the frame preceeding, the frame of, and the frame after the index value is set. Being nearly 90,000 operations long, I couldn't got through the entire trace by hand, so I used OpenOffice's spreadsheet application to search through it. The only time the program makes referance to an E83D address is when it reads the index value before loading the enemy data. Digging a little deeper, I discovered that there are four DMA transfers (two General DMA, and two H-DMA) that occur at the begining of the frame in which the index value changes (I didn't look at the other frames). I thought this might be something, like the program is DMA'ing a bunch of data into the 7EE800 - 7EE9FF range on enemy load. However, from my understanding of the SNES's DMA, you can only transfer between the CPU and PPU. This has indeed be frustratting. I have yet to attempt and trace the DMA opperations to see what is going on with those. Questions 1) Is a CPU-ROM to CPU-RAM DMA transfer possible? 2) Are there any known bugs with snes9x1.43.ep9r8's debugger that might be makign it miss some instruction (specificaly something to do with storing to a relative memory address)? 3) Has anyone else come upon a similar problem? And if so, what was the solution? Thanks, QBRADQ (edited by QBRADQ on 02-17-06 05:50 PM) |
Pages: 1 2 |
Acmlm's Board - I3 Archive - - Posts by QBRADQ |