ORACLE OF SEASONS HACKING GUIDE BY JIGGLYSAINT
Contents:
1. Introduction
2. Dungeon editing
3. Overworld editing
4. Sprite and object editing
5. Dungeon maps editing
6. Warp editing.
Introduction
This is a documentation of various data in the Oracle of Seasons ROM It's purpose is for educational value, and also to aid in the creation of a level editor. Please note that Oracle of Ages shares the same data format, but they do not share the same rom offsets.
I first became interested in hacking Oracle of Seasons long ago, so long ago in fact, that the actual cartrage wasn't even released yet! Yes, I obtained a Japanese rom, and no, I can't give it to you, sorry. Anyway, after playing the game for a while, I thought I'd have some fun and do a little searching. This was my first introduction to the game's very unique dungeon level format. I'll go into more late, but let's just say that this format took quite a while to crack. It's my hope that somebody is able to build a working level editor for this game, because wouldn't we want new dungeons to crawl arround in?
Dungeon Editing
In Oracle of Seasons, the overworld and dungeons each have a different level format. This is actually not surprising, since just about every 2d Zelda with the exception of The Adventure of Link and Link's Awakening, has this feature. The Oracle Games are no exception to this rule, and I am starting with the dungeon format because it's the one I found first without any outside help, and because it's so messed up that you've got to see it to believe it.
Anyway, to get started, let me first explain the three data parts to the dugeon room editing. The first part is a series of bytes, each in rows of 16, with the exception of the last byte on the row being 00(a dungeon room is 15 blocks wide, but some rows are differnt). Each row represents 15 blocks, by byte ID, that is placed in a level. For example, there may be a series of 15 blocks that have 13 floor tiles sandwiched between 2 wall tiles. If you change one of the floor tiles to somthing else, you will make a change. However, you will seem to edit more than just one piece of the dungeon. It will seem like you've edited a good portion of the whole dungeon! What this means is that this row is used many, many times in the rom bank, and that changing this row alone will not yield a good level edit.
The second piece of data is found later in the ROM, and it contains an unbroken chunk of data that is very hard to read unless you have a good starting place. This is the room's row data. The format is actualy easy, yet very difficult. At the start of a room there is one byte that starts it all off. In many rooms it's an FF. Why? Well FF is 256 in decimal, but more importantly it's 8 bits, or 11111111. See, if you read the bitstring from the right, like you are supposed to, each bit that's turned on represents a two byte pair that is actually a combination pointer/row size value. If the bits are turned off, the corrosponding data will, instead, be a block ID value, exactly like the ones used to make up the rows. So FF means that there will be 8 rows of data used, or 16 byes. If 00 was used, the next 8 bytes would be 8 blocks, each byte a different block. The room will continue to read this data in this format untill the room is fully defined, which is 15 rows by 11 columns.
Now, to describe the two byte pairs: This is by far the most unique compression system I've seen, and had the privilage of actually figuing out. Each nybble in this pair has a function. The first nybble of the first byte is half of a pointer, and it points back to the row. The first nybble points to the row between 256 bytes of data. That is, depending on the other pointer, that nybble will reference 256 bytes. The second nybble is part of the length indicator. It tells the game what byte on the row to start at. However, by default, it will add 3 tiles, so the very minium a row can be is 3 tiles. Anything less and you need to use the individual tile ID's. The next nybble, or the first nybble in the second byte is when the row ends. If the length overflows, it will use some of the next row as data. The game uses this overflow a lot, so be careful. The last nybble is which set of 256 bytes to use. Because of this method of pointers, only 16 pages of data can be referenced, which is fine since each bank contains exactly 16 pages.
The last bit of the data comes right after the row definitions, and they are the room pointers. They arn't tradditional pointers, but are relative. That means that starting at the start of the dungeon data, one byte is what out of 256 bytes the pointer starts, and the second is what out of 256 pages the pointer starts.
6. Warp Editing
Warp data starts at arround 13000 or so. At 13457 are 8 pointers that lead to 8 warp data sections for 8 "regions". The regions are as follows: 0 - Overworld, 1 - Subrosia, 2 - Maku Tree, 3 - houses and such, 4 - dungeon bank 1, 5 - dungeon bank 2, 6 - side scrolling sections bank 1, 7 - side scrolling sections bank 2.
After the region pointers is the start of the warp data. How the data works, is there are 4 bytes. The first byte is a branch, if set to 40, it will affect the last 2 bytes of the 4. The second byte tells the game what room or section of the map to put the warp(s). The third byte is the destination byte, and is a reletive pointer to the destination room and co-ordinates. The last byte is a nybble byte, where the first nybble is from 0 to 7, and is the region selector. The last nybble is the warp action(stairs uses 2, doors use 4, ect). Now, if the first byte is set to 40, then the last 2 bytes become a pointer to special data that is used in multiple warps on the same screen. For example, the very first set of 4 bytes uses this. The second byte is D4, for the Hero's Cave. The next two bytes point to the new values, which are 4 bytes like the last, except the room byte is replaced by a co-ordinate byte of where on screen it's located(normally it's assumed that if you enter a door or stairs, you activate the warp, but if there's more than one this tells the game to read it as such). Then the next two are same as usual. The first byte is used to connect more than one string together. If the first byte of the next set of 4 bytes is set to 80, that data will be used on the same screen as the previous set of bytes.
Destination values start at 12d5e, and their pointers start at 12d4e. Destination values consist of 3 bytes. The first is what screen you end up on, the second byte is the x/y co=ordinates, and the last byte is direction and maybe exit action. For example, dungeon entrances tend to have the second byte as FF, and the third as 93. I think it basically tells the game to ignore normal co-ordinates and just make the entrance in the bottom centre of the screen.
Ring chest values:
00 - no chest
01 - no chest
02 -
03 -
04 - Discovery Ring
05 - Moblin Ring
06 - Steadfast Ring
07 - Blast Ring
08 - Rang Ring L-1
09 - Octo Ring
0a - Quicksand Ring
0b - Armor Ring L-2
0c - Spin Ring
0d - Snowshoe Ring
0e - Power Ring L-1
0f - Power Ring L-3
10 - Subrosian Ring
11 -
