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. |
User | Post |
Sukasa Posts: 18/2068 |
Probably not very hard, if you know all the SPC commands and that, as well as the location of it's program pointer in SMW (insert the new program, then repoint SMW to it).
Also, I've worked at the generator for a while, so most of the stuff is labeled, but I placed all the original offsets to the side, behind comments. Hyperhacker: Sounds quite possible, but I'd like to help--> I'm working on my own Sonic The Hedgehog game, and a new engine would make things easier for me, as well. after all, if the commands could be easily converted, well, write a nice little program for that, right? Hell, add in bass and support for other formats via an external converter, and you'd have a beautiful little engine right there! |
HyperHacker Posts: 114/5072 |
Originally posted by Mattrizzle I don't think it'd be much different than hacking music. Problem is the SNES sound processor, not to mention SMW's sound program, are quite limited. *wonders how hard it'd be to make a whole new sound engine for SMW, with its own format, and port SMW music to it* |
Sukasa Posts: 17/2068 |
OK, I'll upload it tonight and post it. I know I commented a bit of it, OMFG may it still be around on my backups...
EDIT: YES, IT JSL's TO 07:F7D2! Please wait while I upload it to freewebs... EDIT2: OK, try this address: bbgen.txt |
Mattrizzle Posts: 3/44 |
Sprite data isn't the only thing we haven't found. No one to my knowledge has hacked sound effects. I don't mean changing what sound effects are played, but being able to create your own.
All of the data surrounding the sprite tilemap data I've posted should be other things related to those sprites. I have looked in these areas and been successful in finding things like the speed of certain sprites. |
spel werdz rite Posts: 84/1796 |
You know, we found data for everything except sprite info. We have level data, overworld data, block data, graphics, palattes, even music. Not to mention those almost infinite little traces we have at Lunar Utopia. So when we rule out those areas, whatever is left must be enemy data. Eye guess there's nothing left. |
BMF54123 Posts: 36/876 |
Originally posted by MathOnNapkinsYeah, all this code does is load a sprite's parameters into memory; the actual sprite code takes care of the OAM and whatnot later (this is the stuff we need to dissect if we want to make custom sprites). Originally posted by SukasaThat would be great! I'm assuming it JSLs to $07F7D2 as well? If so, it means sprite generation has essentially been cracked wide open. |
Sukasa Posts: 11/2068 |
Cool. BMF, would it help if I posted my disassembly-by-hand of the bullet bill generator's code, to see if anyone could figure out what some of the sprite tables are? Perhaps someone could figure out what values are stored in the ROM locations looked at, and compare them to the bullet bill sprite's setting in MWR or something. |
Kailieann Posts: 49/808 |
Originally posted by MathOnNapkins Nope, I've only heard of JMP *, but needless to say that doesn't work on 65c186. Anyways, it occurred to me at work that this might solve a problem I've been stuck on for about a month. I'll see if I can come up with something. |
asdf Posts: 20/4077 |
Originally posted by BMF54123 Layer 3 hacking hasn't been done much. But this is great information, though. This is sure to kickstart the sprite editing automohacker. |
HyperHacker Posts: 96/5072 |
SMW is weird like that. In a lot of 2-byte tables, it stores all the low bytes, then all the high ones. Map16 has low bytes at 7Exxxx and high bytes at the same address in 7Fxxxx. |
MathOnNapkins Posts: 8/1106 |
Originally posted by Kailieann So I guess you've never heard of the infamous BRA #$FE? That's weird how none of those variables are in the OAM range. I guess they're converted later to something it can use. Even weirder how it seperates low and high bytes by such a large distances.* DMA[0]: write Mode: 0 0x000200->0x2104 Bytes: 544 (inc) V-Line:240 OBJADDR: 0000 *- LDA (X-location (low)) - STA $E4,X - LDA (X-location (high)) - STA $14E0,X |
Kailieann Posts: 46/808 |
Wait.. branch instructions use signed numbers?
Why was I not informed of this? |
BMF54123 Posts: 32/876 |
I found this while digging through my archive of the useful memory locations thread on the old OverClocked board: a disassembly of the routine the game uses to spawn a sprite (ex: the one that drops from the item box). Sprite hacking is the "final frontier" of SMW hacking, yet we hardly understand much more about them than we did two years ago (well, aside from mikeyk, but he never did reveal much of his data). I'm hoping that resurrecting this data will rekindle interest in the subject.
- LDX #$0B Empty slot loop (locate an empty sprite slot; this will become X) - LDA $14C8,X - BEQ (start of code) - DEX - BPL (empty slot loop) NOTE: I'm still working out exactly what should go here if an empty slot isn't found. You have to have 12 sprites on the screen before this happens, which is pretty rare, but still must be taken into consideration. The item box code just erases the last sprite loaded, but not before checking a couple of unidentified RAM addresses, and making sure the sprite isn't being held by Mario... If the sprite you're trying to spawn isn't vital to gameplay, then you could simply exit the routine here (the Yoshi berries do this). Start of code (set up the sprite) - LDA #$08 (sprite "active" status) - STA $14C8,X - LDA (sprite number) - STA $9E,X - LDA (X-location (low)) - STA $E4,X - LDA (X-location (high)) - STA $14E0,X - LDA (Y-location (low)) - STA $D8,X - LDA (Y-location (high)) - STA $14D4,X - JSL $07F7D2 (SNES) $07F7D2 - JSL $07F722 (SNES) $07F722 (clear various sprite tables - LARGELY UNDOCUMENTED) - STZ $164A,X - STZ $1632,X - STZ $C2,X - STZ $151C,X - STZ $1528,X - STZ $1534,X - STZ $157C,X - STZ $1588,X - STZ $15C4,X - STZ $1602,X - STZ $1540,X - STZ $154C,X - STZ $1558,X - STZ $1564,X - STZ $1FE2,X - STZ $1626,X - STZ $1570,X - STZ $B6,X - STZ $14F8,X - STZ $AA,X - STZ $14EC,X - STZ $15DC,X - STZ $15D0,X - STZ $163E,X - STZ $1656,X - STZ $1662,X - STZ $166E,X - STZ $167A,X - STZ $1686,X - STZ $187B,X - STZ $160E,X - STZ $1594,X - STZ $1504,X - STZ $1FD6,X - LDA #$01 - STA $15A0 - RTL $07F7D6 - JSL $07F78B (SNES) $07F78B - PHY - PHX - LDA $9E,X (sprite number) - TAX - LDA $07F3FE,X - AND #$0F - PLX - STA $15F6,X - JSL $07F7A0 (SNES) $07F7A0 - PHY - PHX - TXY - LDX $9E,Y (sprite number) - LDA $07F26C,X - STA $1656,Y - LDA $07F335,X - STA $1662,Y - LDA $07F3FE,X - STA $166E,Y - LDA $07F4C7,X - STA $167A,Y - LDA $07F590,X - STA $1686,Y - LDA $07F659,X - STA $190F,Y - PLX - PLY - RTL $07F79E - PLY - RTL $07F7DA - RTL NOTE: this is where you store various parameters for the sprite (speed, style, behavior, etc.) in the tables cleared @ $07F722. Kenny3900 identified some of the tables, but many are still undocumented. I'll post his info here later. [EDIT] Reorganized the list of parameter tables. Indicated ones that are either identified or automatically set by the above routine in bold, and indicated gaps where parameter tables *might* exist in blue. Everything not in bold needs to be identified. All tables are 12 bytes in size, one byte per sprite: $9E (sprite number) $AA $B6 $C2 $CE-$D7 $D8 (Y-location (low)) $E4 (X-location (low)) $14D4 (Y-location (high)) $14E0 (X-location (high)) $14EC $14F8 $1504 $1510-$151B $151C $1528 $1534 $1540 $154C $1558 $1564 $1570 $157C $1588 $1594 $15A0 (#$01 written here after tables cleared) $15AC-$15C3 $15C4 $15D0 $15DC $15E8-$15F5 $15F6 $1602 $160E $161A-$1625 $1626 $1632 $163E $164A $1656 $1662 $166E $167A $1686 $1687-$187A $187B $1FD6 $1FE2 |