 |
| 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 SMW Hacking. |
| Acmlm's Board - I3 Archive - SMW Hacking - New Hacker - Looking for some info; clearly worded ASM questions. Please help if you can. |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
1169 Red Goomba                Since: 03-27-06 From: Gold Coast, Australia Last post: 6647 days Last view: 6647 days |
| ||
| == Background (skip to Questions if you don't need to know) ==
Hi, I am new to SNES hacking. During the day I am a analytical scientist, and have a background in programming. I am even grounded in ASM (I used to write software for electronic cash registers) � I am telling you this only because I am trying to get the point across that I am not an idiot; I am simply someone looking for intelligent discussion and information. I have been at SNES hacking (specifically SMW hacking) for a few days now, and this is about the sum of my knowledge: - Custom Blocks: Understood. A good RAM address/offset list would be nice though. I have made a few play-around blocks; and I have implemented the SM3 pipe hack into my ROM. - Map16: I know enough to use custom blocks, and have figured out (with help) all the oddities of the Lunar Magic Map16 editor. - Entrance/Exits: I am pretty sure I understand them; have played around with them for hours and can achieve what I want. == Questions == 1) I have asked for a link to a good RAM map in another thread; but hear I will ask a specific question. I want to set various flags that a) will be accessible from any where; and b) will be saved when the game saves (as in a SMW save; not a state dump). Anyone know where I might find such memory space? 2) How do I get custom code to fire once during the loading of a particular level? I want to replace the sprites used for various monsters for a particular level (but I want them to remain the same in other levels). I am currently looking at LevelASM and it seems brilliant; but at the same time it seems overkill for what I want to do. Also it fires every frame (I realise I could set a flag (if I had a bloody RAM map of free flag space; but it seems messy). 3) How do I temporarily alter the behaviour of monsters? Specifically I want to "freeze" monsters . . . I know how to change which sprites they use to render, so I can 'graphically' freeze them already; but I want to make them a) stop moving; b) act like a harmless block. I originally started searching the memory for a "act like" variable for sprites; but then I realised this logic was probably flawed as I don't want to freeze all of a sprite type; only a particular instance... e.g. the troopa I just hit with my "fire" ball. . . . Any help you can provide will be much appreciated. Don't be afraid to just point me at other threads (though if they are long, a page number might be nice if you have something specific in mind); or to even just point me at RAM addresses as a starting point. |
|||
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
Large blocks of $55s in the RAM is free space, which you can use for whatever you want to. (Some empty blocks can be found in the RAM map.) As for saving, you have to modify the SRAM (a piece of battery powered RAM memory in the cart). I'm not sure where in the RAM the SRAM is, but you can find that information here.
The best way would probably be to patch the sprites' routines instead. If, say... you want to make a green koopa act differently, you can alter the koopa code to jump somewhere else depending on, for instance, level number.
The only way I can think of is to patch the sprite's walking routine with something that jumps to the original walking code if a byte (in a new sprite table, for instance) is cleared, and otherwise ignore that routine. |
|||
|
1169 Red Goomba Since: 03-27-06 From: Gold Coast, Australia Last post: 6647 days Last view: 6647 days |
| ||
Thanks, it is a useful start. Atleast I know where SRAM is now 
I guess my question though is more along the lines of, are you aware of an research in to how the saving mechanism works. My theory would be that there are particular blocks of SRAM which are related to the various games (1P Game 1, 1P Game 2, etc) and when the cames are cleared the related block of SRAM is zero valued. Ofcourse perhaps flags are just dupicated for the various games and there is a sub-routine which zero values address by address (not an entire block). So I was wondering if anyone had any information on the save mechanism in SMW . . . I have looked through all the ASM traces and ROM/RAM maps I can find and haven't seen anything . . . if no research exists I guess I will just start digging; but I am secretly hoping some does. Also, (once again I have looked through all the ROM/RAM maps and ASM traces I could find), is there any research on the location of the various sprites routines . . . e.g. where are they located in ROM? And (I suspect this might be buried in the link provided above; but I haven't had time to read it all yet) does any know how flexible the various (specifically sprite) routines are in the ROM, do they have enough of a buffer to allow the insertions of op-code jumps; or do you really have to decompile it and work with ASM; and when recompiling does it screw the ROMs ability to work with Lunar Magic? |
|||
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: 6333 days Last view: 6333 days |
| ||
| Most of the time you'll have to patch into them to have them jump to some free space elsewhere. All you really have to do is replace as many instructions of it as you need with a jump/call, and make sure to execute those instructions somewhere in your new code. | |||
|
1169 Red Goomba Since: 03-27-06 From: Gold Coast, Australia Last post: 6647 days Last view: 6647 days |
| ||
Originally posted by HyperMackerel /slaps self in head My head wasn't in hacking mode when I wrote the question you answered . . . lol. Sorry for that noobish question. (My previous ASM experience was more along the lines of creating code - not modifying it; and the biggest question I had to keep asking myself was: how much room is there for expansion?) (edited by lynch82 on 03-29-06 10:11 PM) |
|||
Glyphodon Since: 11-18-05 Last post: 6373 days Last view: 6354 days |
| ||
| Good RAM address places? No, not really. There are a number of places where you can drag up information, but all are either new and lacking addresses or designed for ROM addresses but expanded or are inoperable like in the archived board areas or the old somnolence memory map.
You might want to try the old, old board archive thread, although most of its contents (if not all) have been added to the somnolence memmap which I have since learned is not the best reference at all. I'm probably the one you saw saying that. As for recompiling the entire rom, I doubt that'd be a very good idea. You should compile tiny sections of code and copy and paste the results via a hex editor into your rom. But since I do all my opcode manipulation in hex, I don't know much about this. (edited by Glyph Phoenix on 03-30-06 01:29 AM) |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - SMW Hacking - New Hacker - Looking for some info; clearly worded ASM questions. Please help if you can. |
| |
