 |
| 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 |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by giangurgolo |
| Pages: 1 2 3 |
| User | Post | ||
|
giangurgolo Level: 10 Posts: 1/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| I posted some data over at the rustedmagick.com message board last year, but I've since cleaned things up a bit and have found out roughly where the sprite mapping data is located (what sprites are assigned to whatever area) and have a better grasp of the battle script system. The sprites are mapped by the SA-1 chip and I'm going to be honest and say that I don't have the slightest notion how it (the chip) works, but I have found the data so I've got something to work off of. I don't know if there's been any talk of an editor being made for this game but I think with what I have here someone with good enough programming skills could put together a pretty decent one. Since this is the most active romhacking board I could find I figured it would get more attention and hopefully inspire a hack. Here's what I've gathered over the months of off and on hacking: rom data I have several other documents explaining some things there in detail (battle scripts, spell animations, enemy/spell/item stats) but I'll see if anyone is even interested yet before putting it here. |
|||
|
giangurgolo Level: 10 Posts: 2/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| Thanks for the help, Darkflight! I actually found the sprite mapping data with Geiger's snes9x debugger, which had SA-1 logging support added in the later builds. From the logs of the SA-1 tracing, it looks to me that it works in a similar manner to the normal CPU which is why I almost instantly found the data once the SA-1 support build was released. Immediately after I got the news I DL'd the debugger, loaded up the ROM and found it in no time at all. The SA-1 logs are much larger than the normal ones (nearly twice the size) so I assume it's a pretty busy chip in this game. here are some more documents I'm posting if anyone might be interested: monster battle scripts and common commands spell animation pointers item, monster, spell statistics primitive understanding of sprite mapping sprite mapping would be the most important thing to have in a level editor |
|||
|
giangurgolo Level: 10 Posts: 3/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
If you need any (partial) logs (full logs run from 30 MB to 200 MB) I'll see if I can find anything specific.Originally posted by Darkflight Yeah; for instance if you new where the data was you could change the monster/treasure chest/trampoline etc etc whatever sprites in any area (including townsfolk and the like) to something else. It's just a matter of finding where the data is and finding out how it works. Townsfolk, treasure chests, and other non-monster-documented sprites are given a value to determine that they are not monsters. Each data block contains a value that determines if you should engage in battle if you touch the sprites. here's a PAR-code for example that modifies the ASM code to disable all battle engagements with monster sprites (well mostly, Dry Bones are still battle-effective): C08C7000 For the Terrapin in the sprite-mapping document I posted above, I still haven't figured out how to change each patrolling Terrapin individually; there's a value that changes all four at once but I still haven't found each individual. (edited by giangurgolo on 06-27-05 11:46 PM) |
|||
|
giangurgolo Level: 10 Posts: 4/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| here's a string of SA-1 code (as you can see it involves essentially the same process as normal CPU): $C0:8B81 64 6C STZ $6C [$00:006C] $C0:8B84 A9 D4 LDA #$D4 $C0:8B86 48 PHA $C0:8B87 AB PLB $C0:8B88 C2 20 REP #$20 $C0:8B8A A5 30 LDA $30 [$00:0030] $C0:8B8C 0A ASL A $C0:8B8D AA TAX $C0:8B8E BD 02 80 LDA $8002,x[$D4:800A] this is a pointer to something, but it doesn't point to the data at D4848A $C0:8B91 85 6E STA $6E [$00:006E] $C0:8B93 E2 20 SEP #$20 $C0:8B95 BC 00 80 LDY $8000,x[$D4:8008] this is the pointer to the data $C0:8B98 C4 6E CPY $6E [$00:006E] $C0:8B9A D0 08 BNE $08 [$8BA4] $C0:8BA4 B9 00 00 LDA $0000,y[$D4:848A] <---this (D4800A) is the indexed accumulator where the sprite mapping data for the Bowser's Castle, 2nd room Terrapins begins that's just beginning of the code; there's a lot more going on that I have yet to understand to get a firm grasp on mapping sprites, because many of the values in that block (#$00 is the byte value for TERRAPIN, the first monster on the list) won't effect the four moving Terrapins but the two individual ones blocking the door can be easily changed |
|||
|
giangurgolo Level: 10 Posts: 5/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| An 82 MB archived log is about 4.58 MB (zip format). I was able to fit it on my FTP so here it is. (edited by giangurgolo on 06-28-05 01:04 AM) |
|||
|
giangurgolo Level: 10 Posts: 6/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| I've found the compressed GFX, tilesets, and tile solidity sets. I've also found the decompression routine for compressed GFX and compressed tilesets. 160000 - 1600D9 PTR to Tilesets 160034 Mario's Pipehouse 1600DA - 16FDE8 Tilesets 16FDE9 - 16FFFF -------- 170000 - 17006B PTR to Tilesets (unconfirmed as of yet) 17006C - 17FC80 Tilesets (unconfirmed) 17FC81 - 17FFFF -------- 180000 - 18006F PTR to Tilesets (unconfirmed) 180070 - 18FC80 Tilesets (unconfirmed) 18FC81 - 18FFFF -------- 190000 - 190071 PTR to Tilesets 190072 - 19FEDD Tilesets 19374E Mario's Pipehouse (inside) 19FEDE - 19FFFF -------- 1A0000 - probably more tilesets 1B0000 - 1B009F PTR to Tile Solidity sets 1B00A0 - 1BFC12 Tile Solidity sets 1BFB78 Mario's Pipehouse (inside) 1C0000 - more tilesets? 1D0040 - 1D243F Room headers (2nd byte changes message box) 1D0BDA Sunken Ship - Puzzle Room Passageway 1D0D8A Mario's Pipehouse Check smrpg_addresses.txt for the full list. This stuff wasn't actually that trivial to locate; I just used values in a ZST savestate from the decompressed GFX and tilesets to search for in the actual ROM and found it pretty fast. Finding tilesets for each area/room isn't hard at all and is just a matter of documentation. Now the decompression routine will take some time to figure out, but I have the full string of code used for each data block (it uses the same ASM routine for each type of compressed data) so I'll try and decipher as much as I can. what's been discovered so far, tested with the layout of inside Mario's Pipehouse NOTE: all of this is executed with the SA-1 chip (edited by giangurgolo on 07-01-05 04:13 PM) |
|||
|
giangurgolo Level: 10 Posts: 7/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| monster stats start at 390226 and are 16 bytes each, but they are not in the same order as the monster list you'll have to go by the pointers, which are 2 bytes each and start at 390026; multiply the monster # (in hex of course) by 2 and add it to 390026 to get the pointer here's a byte list for the monsters and a stat guide I don't know how PIPES gets the monster stats, if the stats are read from the ROM itself from the pointers or are already embedded in the program's code. Which monsters aren't working when you change them, and what kind of stats are you trying to change? (edited by giangurgolo on 07-02-05 02:10 PM) (edited by giangurgolo on 07-02-05 02:13 PM) (edited by giangurgolo on 07-02-05 02:25 PM) |
|||
|
giangurgolo Level: 10 Posts: 8/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| Also, make sure it has a header...if you have a v1.0 ROM that still doesn't load properly it probably doesn't have a header. Just use snestool to add one. | |||
|
giangurgolo Level: 10 Posts: 9/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
Originally posted by Spralwers I justed tested and PIPES doesn't work at all in this area. When you try to change the enemy's FP, it changes the speed instead (the program doesn't even have an option for changing speed or evade rate even though it's in the stats). Same goes for all the other stats. I guess the only way you'll be able to change this is in a hex editor. Also, if you want to change the monster's EXP and coins, you need to look at the smrpg_stats.txt document I posted for the offsets for those. I explained how to find the stats in my post: take the monster's hex number in the byte list I supplied, multiply by 2, and add to 390026 to get the pointer. For instance, if you want to change The Big Boo's stats, take the byte number (#$12) double it (#$24) and add to 390026...to get 39004A. The pointer here is 02A6, which means The Big Boo's stats start at 3902A6. SMRPG can be a pretty difficult game to hack depending on what data you're dealing with, but monster stats are pretty simple (except for the fact that I haven't figured out what those three unknown bytes are for). |
|||
|
giangurgolo Level: 10 Posts: 10/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| It's definitely lacking a header, and that message you got is because you have no header. The Yoshi's Island ROM with the (M3) symbol after it doesn't have a header, if that's what ROM you have. Regardless, you need a header. So you need to add #$200 bytes of zeros to the beginning. |
|||
|
giangurgolo Level: 10 Posts: 11/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| You need to add 158 to 390026, not 390226. 390226 is where the stats start at...you need to find the pointer first. Pointers start at 390026. Each pointer is two bytes long. When you add 158 (the Hammer Bro's byte you doubled) to 390026 you get 39017E, which is where Hammer Bro's pointer (A60B) is at. Flip those two byte to get 0BA6...which means Hammer Bro's stats start at 390BA6. Unfortunately, that Hammer Bro you used is the wrong one (which is why there was no change) because according to the stats his speed is at a phenomonal 99. The correct Hammer Bro byte is 1B (check the monster list). Do the same procedure here...double it to get 36, then add to 390026 to get 39005C, his pointer (260C). Flip the bytes (0C26). The real Hammer Bro's stats are at 390C26. (edited by giangurgolo on 07-03-05 06:43 PM) (edited by giangurgolo on 07-03-05 06:43 PM) |
|||
|
giangurgolo Level: 10 Posts: 12/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| Hey thanks! That makes sense anyways because there's already a byte dedicated to ailment proneness so why would ailments be included in elemental weaknesses? Appreciate the discovery w/byte 12, too, I'll be sure to document this one. |
|||
|
giangurgolo Level: 10 Posts: 13/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| 260C is at offset 39005C. We arrived at offset 39005C by doubling the monster byte and adding it to 390026 (390026 is where the first pointer, Terrapin's, is at). Pointers are 2 bytes each and are at offsets 390026 - 390225 (they end right before where the monster's stats start at 390226). Since there are 256 monsters, there would be 256 pointers...and since pointers are 2 bytes each, there are 512 ($200) bytes of pointers. Finding the monster's pointers are fairly easy once you get the hang of it. The reason I stress that you follow the pointers and not the stats to find a monster's stats is because if you look at the pointers in subsequent order, they aren't in numerical order. One monster's stats could be far away from the next monster's stats. |
|||
|
giangurgolo Level: 10 Posts: 14/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| yeah I found out a couple of days ago about Lunar Compress and SMRPG's compression support so all of that logging and 'deciphering' was a wasted effort =\ If someone wanted to make a tile editor they'd just need to know the right code to decompress the data, since finding the offsets is just a matter of looking through trace logs of the SA-1 chip's activity. Unfortunately, the snes9x debugger's breakpoint option isn't capable of tracing the SA-1, so you would need to make trace logs when entering every room (there are about 470 rooms in total) so it would take probably take weeks to document every single room's tile arrangements. I have, however, been able to document the room headers in just a day's worth of tracing using one breakpoint. Here's the file: room headers The room header data format is explained in the file. Room header data would need to be referenced when changing a room/area's tileset, if someone would want to change tiles to something in a different tileset. If one's desire is only to change tiles to something else in the same tileset, it's just a matter of decompressing the data, changing the tiles, and recompressing it, and room header modification would not be necessary. I can't foresee any possibility of expanding a room's layout without deleting other tile data, since there is very little extra space in each bank to use for extra tiles. This applies to tile solidity, since it uses the same principles, and has neighboring banks to the tile assignments. here's some bitmaps of just a few of many tilesets that I have yet to document Tile solidity uses FF to apply an impassable tile, and any other value from 00-FE designates the height of the tile. |
|||
|
giangurgolo Level: 10 Posts: 15/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| here's a near complete documentation of all accessible area tile maps in order to switch between tiles from different tilesets, the first five values in each area's area layout data (check bottom of document for tile group descriptions) can be changed to something else; each byte is described an area list is supplied with all areas' layout byte to locate the layout data; the offsets listed in this document are the area headers, starting at $1D0040 (not to be confused with the layout data, which starts at offset $1D2440) and are 18 bytes long each it is in order of the 1st byte of each block, that is, the byte pointing to the layout data therefore it is NOT in order by offset; for an ordered list of area headers by offset click here EDIT: okay, I've documented the palette sets for each area and have just located the entrance/exit field data in the ROM it's quite simple, and I've documented the bytes with a description of each value
also, I've changed the filenames of the other documents to something a little shorter, so if you want the whole collection just download this archive because the older posts with the file links are obsolete (edited by giangurgolo on 07-09-05 08:17 PM) (edited by giangurgolo on 07-11-05 12:39 AM) (edited by giangurgolo on 07-11-05 10:04 PM) |
|||
|
giangurgolo Level: 10 Posts: 16/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| Compressed GFX start at 0A0000 and end somewhere in bank 130000...I believe bank 120000 and 130000 are the compressed graphics for all of the battlefields. I'll see if I can document what I can in attempt to identify whatever often indiscernable graphics turn up in an editor. EDIT: I don't really need to document it...read the paragraph after next in this post to see why. When decompressing with Lunar Compress, always start one offset after the pointer's value...compressed data blocks usually have a header of 0x01 and use F# as the indicator for how the data is compressed. Decompression starts at the F#. The bytes that lead to the compressed GFX to use for tiles are the first five bytes in the area data (check nfo_area-maps.txt). There should be some descriptions on the bottom for each byte and what GFX to read from. The tilesets (hardly any documentation I've done on these; NOT the same as tilemaps) arrange the GFX from 8x8 tiles to 16x16 tiles to call with the tilemaps. I don't think it'd be really necessary to include this in the editor, since through testing I noticed it seemed to properly arrange the tiles no matter what types of GFX it read from. To calculate the area's compressed GFX pointers (the first five bytes) just add #$0048, double, and compare to the first 2 bytes in bank 0A0000 (read by little endian, like a pointer) and if it is greater than or equal, it subtracts the byte from the pointer and moves to the next bank (0B0000) and does the same thing. This is a pretty simple procedure for moving from bank to bank that I'm not sure needs explaining, but I'm elucidating just in case. If you have any specific questions, I'll try to answer them to help with the development. EDIT: added the tilemap offsets for all battlefield data in nfo_tilemaps.txt and added the compressed GFX pointer bytes to nfo_area-maps.txt. (edited by giangurgolo on 07-11-05 09:37 PM) (edited by giangurgolo on 07-11-05 09:42 PM) (edited by giangurgolo on 07-11-05 10:02 PM) (edited by giangurgolo on 07-12-05 07:59 PM) (edited by giangurgolo on 07-12-05 08:08 PM) |
|||
|
giangurgolo Level: 10 Posts: 17/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| study this tutorial I wrote demonstrating the arrangement of 16x16 tiles with the 8x8 tiles from decompressed GFX in banks 3B0000 through 3E0000 16x16 tiles are arranged in banks 3B0000 through 3E0000 although I don't know about 3E0000 because I haven't documented anything there yet knowing this is vital to understanding the links between the crucial data, which goes in this order: tilesets read compressed GFX pointers from area layout data, decompressed GFX are arranged in 16x16 tiles, and 16x16 tiles are mapped here's an updated tilemap offset collection with the tileset offsets added; I was wrong about tilesets and their significance in tile mapping because that's where the whole tile-arranging thing takes place before it maps the tiles thanks for the feedback I've gotten this is about as much as I'm going to do...it's up to the programmer to try to comprehend it and do what they wish remember, if there are any questions about these processes just ask |
|||
|
giangurgolo Level: 10 Posts: 18/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
actually the tileset format has already been decoded (I'm guessing you were speaking hypothetically) this is the first part of the decompressed tileset for Mario's Pipehouse (and many others) which is the whole block (1000h bytes) and this is just a selection of the first 80h bytes as seen in Hex Workshop the selection is a single 16-tile row of 16x16 tiles...each 16x16 tile is 8 bytes (in the tileset data) so a single row of 16 16x16 tiles would be 128 bytes; however, the tops and bottoms of the tiles aren't in subsequent order...for instance  the selection on top is the top half of the first tile in the set the selection on bottom is the bottom half of the first tile in the set that's the way it looks in a tile editor...in a ZST the graphics are arranged so that they're easiliy recognizable, which is because the top/bottom halves of the tiles are directly below each other on separate rows; the halves are 40h bytes apart tile rows are 128 (80h) bytes each so it works within a row here's an example where HW displays 64 bytes each row so that the top/bottom halves are displayed right above/below each other  each box of 8 bytes is a 16x16 tile...every two bytes is an 8x8 tile; try to look at it as GFX seen in a tile editor; the byte 00 1C (or 1C 00 in big endian) is a transparent 8x8 tile...here I'll show you:  consider this image directly correspondent to the last one according to the five 16x16 tiles selected...as you can see, the first two are blank because they both share the values 00 1C for every little 8x8 tile in the 16x16 tile arrangement |
|||
|
giangurgolo Level: 10 Posts: 19/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| remember that the low byte is the tile number...we're looking at little endian format so the grid you made should have the low byte if only the tile number is shown 1C is the high byte for the blank tiles I didn't have an explanation as to how to read an 8x8 tile: if a tile editor would be reading the 8x8 tile, in order to find what GFX section the tile is reading from follow these steps (this has a tile example): step 1: start with tile 0CC6 step 2: subtract 0x40 from the high byte only if it is greater than/equal to 40h, to cancel the mirroring 0CC6 (no modifications this time) step 3: divide high byte by four 03C6 remainder is 0, so it is from section 1 of GFX quotient is 0x03 so it uses palette 3 (from 0-7) (edited by giangurgolo on 07-14-05 06:03 PM) |
|||
|
giangurgolo Level: 10 Posts: 20/42 EXP: 3346 For next: 1068 Since: 06-04-05 Since last post: 31 days Last activity: 22 days |
| ||
| sorry if this is off topic but is there anything that's capable of converting a long string of hex numbers to decimal form? not individually, I mean like an entire document...say, a list of hex values like this: 000A 0014 000A 0010 001E 0050 001E 0020 002B ...and so on any help would be greatly appreciated! |
| Pages: 1 2 3 |
| Acmlm's Board - I2 Archive - - Posts by giangurgolo |
