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 |
HyperHacker Posts: 1797/5072 |
Only if you're just linking to say "hey join my forum". There's nothing wrong with linking to useful information, as long as it's not like on a ROM site or something. |
Tauwasser Posts: 22/46 |
I thought linking to other forums was bad, so I didn't
http://romhackersworld.de.vu/ "Pokémon-Hacking" / "Downloads" / "Gold Silber Tools" / "AgiXP". No source available, but a nice German documentation here. cYa, Tauwasser |
HyperHacker Posts: 1760/5072 |
Well then, why not link to some of those tools, or better, their source codes? At least give some names to search for? Just saying "there's programs that do it" is fairly pointless. |
Tauwasser Posts: 21/46 |
It's not "I found this a long time ago" , rather "It's already been found out and implemented into several tools, so stop wasting time"
cYa, Tauwasser |
HyperHacker Posts: 1750/5072 |
I'm sorry, but what does "I found this a long time ago" have to do with the thread? I'm suddenly reminded of those Pokémon communities... *shudder* |
Tauwasser Posts: 18/46 |
Old stuff - all known to the Pokémon Community already Heck there's even a wonderful German compression tool out
cYa, Tauwasser |
Neil Posts: 3/3 |
no more. |
Raccoon Sam Posts: 340/1040 |
Broken link |
Neil Posts: 2/3 |
There's a archive with the pokemon compression and qbasic source code for a decompressor here. Not sure if there's a basic interpreter on the mac, but if there is i guess you could modify this slightly to suit your needs. |
Tauwasser Posts: 16/46 |
Originally posted by FreeDOS +Originally posted by Unicorn_Poop This actually very much resembles the compression used in Pokémon Gold, Silver and Crystal. The gb-routine just seems a little improved because there is no use for a Sigma Fill but rather a RLE for 00-Bytes. It's interesting that they have about the same layout cYa, Tauwasser |
MathOnNapkins Posts: 393/1106 |
Originally posted by BGNG Um... from the SNES point of view, 3bpp is not the simplest form. It cannot display graphics in a 3bpp "encoding". 3bpp must be padded out to the actual 4bpp encoding in order to be displayable. And since there are few ways of eliminating one bit of color depth, there are many ways to store graphics as 3bpp. Tile Edit Pro just happens to support one such type. It certainly couldn't view the 3bpp "graphics" I was trying to look at in Secret of Mana a while ago. |
Raccoon Sam Posts: 330/1040 |
So uh.. Is there a way to make a ROM decompressor so we Mac user could edit the Gfx too..? |
FreeDOS + Posts: 444/1312 |
Originally posted by Unicorn_Poop Or the better option and use <tt> plus (the board doesn't like <pre>, so go into a text editor and replace ' ' with ' '): +--------------------------------------------------------------------------------------------------------------+ |=Decompression=Routine=[$80:B0FF-$80:B270]====================================================================| +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ |=Command=Name=|=Hex=|=Binary====|=Syntax==================|=Range======|=Notes================================| +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $00 | %00000000 | | | Copies the next (# + 1) bytes from | | Direct Copy | .. | CMD..... | [%000xxxxx : xxxxx = #] | 1-32 bytes | Compressed Data (CD) to RAM. | | | $1F | %00011111 | | | | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $20 | %00100000 | | | Writes the next byte (# + 1) bytes | | Byte Fill | .. | CMD..... | [%001xxxxx : xxxxx = #] | 1-32 bytes | deep to RAM. | | | $3F | %00111111 | | | | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $40 | %01000000 | | | Writes the next word (# + 1) bytes | | Word Fill | .. | CMD..... | [%010xxxxx : xxxxx = #] | 1-32 bytes | deep to RAM. | | | $5F | %01011111 | | | | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $60 | %01100000 | | | Writes the next byte to RAM. Then | | Sigma Fill | .. | CMD..... | [%011xxxxx : xxxxx = #] | 1-32 bytes | adds 1 to that byte and writes it | | | $7F | %01100000 | | | again...etc. Writes (# + 1) times. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $80 | %10000000 | | | Copies (# + 1) bytes from the RAM | | Library Copy | .. | CMD..... | [%100xxxxx : xxxxx = #] | 1-32 bytes | address provided in the next two | | | $9F | %10011111 | | | bytes. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $A0 | %10100000 | | 1-32 bytes | Much like the Library Copy. The only | | EORed Copy | .. | CMD..... | [%101xxxxx : xxxxx = #] | $7F:0000 - | difference is that all data copied | | | $BF | %10111111 | | $7F:FFFF | is EORed with %11111111. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $C0 | %11000000 | | 1-32 bytes | Subtracts next byte from Y, the RAM | | Minus Copy | .. | CMD..... | [%110xxxxx : xxxxx = #] | 0-255 from | offset, and copies (# + 1) bytes to | | | $DF | %11011111 | | current Y | current Y. Can copy last tile. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $E0 | %111 000 00-->Bits 8 9 of X (aka #) | 1-1024 | Extends the range of previous CMDs | | | | ||| --------------------- | bytes | from 1-32, to 1-1024 bytes deep. | | | | CMD----->Command Code. Any one | | | | Extended CMD | .. | of the previous 7 CMD | $7F:0000 - | Specifically, Bits 7-5 flag the ECMD,| | | | patterns can go here. | $7F:FFFF | & Bits 4-2 are interpreted as a CMD. | | | | --------------------- | RAM | Bits 1-0 & the next byte are treated | | | $FE | %111 111 11 | | as a 10-bit value for X, aka #. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | | | | | | | Terminate SR | $FF | %11111111 | [%11111111] | ---- | Terminates Sub Routine | | | | | | | | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ |
Unicorn_Poop Posts: 6/15 |
Wow, I didn't relize it, but the forum butchered my notes. In Notepad, just line up the verticle bars ( | ) with the pluses and you should have a nice table.
Of note, the address in the table's title is the Decompression Routine's ROM address in Super Metroid only. Also, I forgot to mention the data used to control the Decompression Routine's Input and Output is located directly after the JSLs that lead to the execution of the routine. So, if you don't know where to locate this data, just look for JSLs to SMW's Decompression Routine. You can find the routine's address if you watch where in the program the game writes new level data to RAM. |
Guy Perfect Posts: 257/451 |
Originally posted by HyperMackerel Well there you have it, then. A reason. (-: |
HyperHacker Posts: 1713/5072 |
Originally posted by BGNG An SMW editor for the DS? ...Hey, that's not a half bad idea. |
Unicorn_Poop Posts: 5/15 |
I'm decoding all of Super Metroid right now, and I decoded the compression routine long ago. I'm almost positive that most Nintendo games use the same compression routine, so these notes should be valid for your purposes.
Copy and Paste this into Notepad with the Lucida Console font. +--------------------------------------------------------------------------------------------------------------+ |=Decompression=Routine=[$80:B0FF-$80:B270]====================================================================| +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ |=Command=Name=|=Hex=|=Binary====|=Syntax==================|=Range======|=Notes================================| +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $00 | %00000000 | | | Copies the next (# + 1) bytes from | | Direct Copy | .. | CMD..... | [%000xxxxx : xxxxx = #] | 1-32 bytes | Compressed Data (CD) to RAM. | | | $1F | %00011111 | | | | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $20 | %00100000 | | | Writes the next byte (# + 1) bytes | | Byte Fill | .. | CMD..... | [%001xxxxx : xxxxx = #] | 1-32 bytes | deep to RAM. | | | $3F | %00111111 | | | | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $40 | %01000000 | | | Writes the next word (# + 1) bytes | | Word Fill | .. | CMD..... | [%010xxxxx : xxxxx = #] | 1-32 bytes | deep to RAM. | | | $5F | %01011111 | | | | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $60 | %01100000 | | | Writes the next byte to RAM. Then | | Sigma Fill | .. | CMD..... | [%011xxxxx : xxxxx = #] | 1-32 bytes | adds 1 to that byte and writes it | | | $7F | %01100000 | | | again...etc. Writes (# + 1) times. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $80 | %10000000 | | | Copies (# + 1) bytes from the RAM | | Library Copy | .. | CMD..... | [%100xxxxx : xxxxx = #] | 1-32 bytes | address provided in the next two | | | $9F | %10011111 | | | bytes. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $A0 | %10100000 | | 1-32 bytes | Much like the Library Copy. The only | | EORed Copy | .. | CMD..... | [%101xxxxx : xxxxx = #] | $7F:0000 - | difference is that all data copied | | | $BF | %10111111 | | $7F:FFFF | is EORed with %11111111. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $C0 | %11000000 | | 1-32 bytes | Subtracts next byte from Y, the RAM | | Minus Copy | .. | CMD..... | [%110xxxxx : xxxxx = #] | 0-255 from | offset, and copies (# + 1) bytes to | | | $DF | %11011111 | | current Y | current Y. Can copy last tile. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | $E0 | %111 000 00-->Bits 8 9 of X (aka #) | 1-1024 | Extends the range of previous CMDs | | | | ||| --------------------- | bytes | from 1-32, to 1-1024 bytes deep. | | | | CMD----->Command Code. Any one | | | | Extended CMD | .. | of the previous 7 CMD | $7F:0000 - | Specifically, Bits 7-5 flag the ECMD,| | | | patterns can go here. | $7F:FFFF | & Bits 4-2 are interpreted as a CMD. | | | | --------------------- | RAM | Bits 1-0 & the next byte are treated | | | $FE | %111 111 11 | | as a 10-bit value for X, aka #. | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ | | | | | | | | Terminate SR | $FF | %11111111 | [%11111111] | ---- | Terminates Sub Routine | | | | | | | | +--------------+-----+-----------+-------------------------+------------+--------------------------------------+ |
Guy Perfect Posts: 256/451 |
1) Lunar Compress is a Windows-only app, isn't it? That won't help people developing for the DS. (-:
2) There's a difference between compression and encoding. 3bpp is the encoding. LZ2 is the compression. One of them expresses the data in its simplest form (encoding), and the other exists to make the encoded bit stream smaller (compression) |
BMF54123 Posts: 295/876 |
Er, yeah, I knew that.
So, technically, SMW uses "layered" compression... |
MathOnNapkins Posts: 392/1106 |
Originally posted by BMF54123 3bpp is not a format, it's another type of compression. So if you have decompressed something and the product is 3bpp, it is still compressed. |
This is a long thread. Click here to view it. |