 |
| 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 |
|
| | ||
1 user currently in Rom Hacking:  hukka |
| Acmlm's Board - I2 Archive - Rom Hacking - Has anyone even considered creating an editor for Mario RPG? |
 |  |  |
| Pages: 1 2 3 4 5 6 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
Sukasa Boomboom Error 349857348734534: The system experienced an error. Level: 57  Posts: 1033/1981 EXP: 1446921 For next: 39007 Since: 02-06-05 From: *Shrug* Since last post: 6 days Last activity: 1 day |
| ||
| None I could find, but I'll look again. Also, as an Idea I figure that the 65816 must send instrucitons to the SA-1, but they will probably be in the first part of the ROM, so try using geigers debugger or whatever, and try also compiling a version like Fu did, except to trace the SA-1. At any rate, I'll go look now. EDIT: Well, shit. I can't find anything on google, so my next trip is to the ZSNES boards. I'll be back with some news tomorrow, if I can get on tonight. EDIT2: Here's a link to the thread/topic. SA-1 Documentation (edited by Darkflight on 06-27-05 10:57 PM) (edited by Darkflight on 06-27-05 11:07 PM) |
|||
|
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 |
|||
|
Sukasa Boomboom Error 349857348734534: The system experienced an error. Level: 57 Posts: 1039/1981 EXP: 1446921 For next: 39007 Since: 02-06-05 From: *Shrug* Since last post: 6 days Last activity: 1 day |
| ||
| OK, so with your logs, and if need be anything that gets posted at the ZSNES boards, we should be on our way to being able to decipher what goes on in the SA-1 and what goes on in the 65c816, right? It would figure that the two have slightly different opcode lists and access limits and all, so... yeah. Anyways, Sprite mapping = where they are spawned at, right? Anything else you guys might need that I could try to get at the ZSNES boards? EDIT: You notes are cryptic to me, but I think I have an idea of how the sprite mapping work, location wise. I'll link to a 16-color bmp. I hope it is right, but at least it is somthing to work off of, even if it is cryptic. (edited by Darkflight on 06-27-05 11:48 PM) |
|||
|
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) |
|||
|
Sukasa Boomboom Error 349857348734534: The system experienced an error. Level: 57 Posts: 1040/1981 EXP: 1446921 For next: 39007 Since: 02-06-05 From: *Shrug* Since last post: 6 days Last activity: 1 day |
| ||
| OK, one thing I need to ask is how to interpret the logs; I can't udnerstand them and as such can't do anything with them apart from what you commented. Any help on that? | |||
|
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 |
|||
|
Sukasa Boomboom Error 349857348734534: The system experienced an error. Level: 57 Posts: 1042/1981 EXP: 1446921 For next: 39007 Since: 02-06-05 From: *Shrug* Since last post: 6 days Last activity: 1 day |
| ||
| Then as an idea, try looking at the four terrapins as one sprite, or 4 sprites with one control ASM, collectively controlling them. BTW, is the SA-1 little or big endian? EDIT: How big is a full log file, zipped into a .rar? I might want to look at it, if I could download it from freewebs or some other site. Maybe I could make some sense of what goes through the SA-1, as I have a 65c816 opcode listing I could use as reference. (edited by Darkflight on 06-28-05 12:40 AM) |
|||
|
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) |
|||
|
Sukasa Boomboom Error 349857348734534: The system experienced an error. Level: 57 Posts: 1045/1981 EXP: 1446921 For next: 39007 Since: 02-06-05 From: *Shrug* Since last post: 6 days Last activity: 1 day |
| ||
| Wonderful. I'll decode this shit and let's figure out what this baby does, shall we? | |||
|
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) |
|||
Spralwers Micro-Goomba Level: 5 Posts: 13/13 EXP: 519 For next: 10 Since: 07-02-05 From: Bolton, MA Since last post: 118 days Last activity: 66 days |
| ||
| I corrupted offset 392C00 to 3A2CFF and it messed up the battlefield. . .I don't know if you guys found this, but I'm just reporting it in. | |||
d4s Panser Level: 29  Posts: 250/325 EXP: 142151 For next: 5734 Since: 03-23-04 Since last post: 13 days Last activity: 1 day |
| ||
Originally posted by giangurgolo good work, buddy, but you know that smrpgs compression is supported by lunar compress for a couple of years now, right? no need to reinvent the wheel. some notes concerning the sa1: sa1 registers are mapped to bank $00-$3f (mirror: $80-$bf), $2200-$2400. the sa1 i-ram is located in the same banks from $3000-$3800. you can think of it as some sort of scratchpad ram. keep in mind that the sa1 can map different rom banks to different locations. that means 2 reads of bank $c0 will probably access different rom locations if the mapping was changed between the reads. this was done to support 64mbit roms while maintaing the $00:8000 / $80:8000 / $c0:0000 mirroring of the rom. since mario rpg is only 32mbits wich fits into the standard memory map without bankswitching, you'll probably not have to worry about that, but you should still be aware of the bankswitching-system being present. (edited by d4s on 07-06-05 03:34 PM) |
|||
|
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. |
|||
|
Omega45889 Panser Level: 30  Posts: 280/335 EXP: 148978 For next: 16891 Since: 03-22-04 From: Vancouver Canada Since last post: 5 days Last activity: 6 hours |
| ||
| WOW, SPECTACULAR... i am going to start working on an editor tomorrow morning. Ive got lots of free time to code right now, so i think ill see what i can come up with. Great work giangurgolo. Keep it up, and well have an editor in no time. | |||
|
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) |
|||
|
Omega45889 Panser Level: 30 Posts: 283/335 EXP: 148978 For next: 16891 Since: 03-22-04 From: Vancouver Canada Since last post: 5 days Last activity: 6 hours |
| ||
| Ok, i have learned a TON about programming today. I am pretty sure i know how i am going to program this sucker. Ill see about comming up with a layout tomorrow sometime. Ive also got to program the Rom corrupter i want to release to replace the current crap out there. All tomorrow i tell you... all tomorrow... |
|||
|
d4s Panser Level: 29 Posts: 254/325 EXP: 142151 For next: 5734 Since: 03-23-04 Since last post: 13 days Last activity: 1 day |
| ||
Originally posted by Omega45889 imo, the idea of rom corrupting to find data is crap. looking through disassembled code is superior in any way. apart from being more precise, its also faster than data corruption if youre used to it. anyway, good luck on that editor =) (edited by d4s on 07-11-05 01:40 PM) |
|||
|
Omega45889 Panser Level: 30 Posts: 286/335 EXP: 148978 For next: 16891 Since: 03-22-04 From: Vancouver Canada Since last post: 5 days Last activity: 6 hours |
| ||
| Oh, i completely agree... corruption is more or less trial and error, and i have never relied upon corruption to find data, but back when i was a noob, i tried to use the different corrupters out there, and they were all shit that never worked, and crashed randomly. I can spend like 3-4 hours and code a simple and reliable corrupter for the noob hackers out there. Ive spent like an hour on it, and its starting to shape up. Besides, i just came up with the idea this morning. I am going to have to go through that SMRPG data in detail before i begin, but i have a relativly good idea about what im gonna do. I dont believe there is quite enough data to make an editor, but there is enough to get the GUI going, editing levels and such. After ive got that, its a simple matter of expanding arrays, ect and adding new features as more stuff gets documented. I just have one question. I have never dealt with compression in detail before, I have an idea of how it works, but nowhere near enough knowlege to decompress the gfx and read them directly from the ROM. I plan to do this, but i need someone to help me out with the compression. I know that Lunar Compress supports the SMRPG format, which I intend to just rip and use in my editor. Can someone supply me withe the areas of compressed gfx? Im not a data guy, and im too busy to bother finding it right now. |
|||
|
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) |
|||
|
Sukasa Boomboom Error 349857348734534: The system experienced an error. Level: 57 Posts: 1183/1981 EXP: 1446921 For next: 39007 Since: 02-06-05 From: *Shrug* Since last post: 6 days Last activity: 1 day |
| ||
| Wow. That's a lot of great stuff you guys have done. Is there anything I could be doing right now to help? |
| Pages: 1 2 3 4 5 6 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Rom Hacking - Has anyone even considered creating an editor for Mario RPG? |
| | |
