 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by Trax |
| Pages: 1 2 3 4 |
| User | Post | ||
Trax Red Tektite                  Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Hi people...
I just discovered this site, but I started hacking at least a year ago. But that's good to see that some people like Zelda II (I thought I was the only one in the world). I was writing a compilation of the things I already know about the Zelda II ROM, but it seems most of the info is already on www.datacrystal.org . Anyways, I still think it can be useful, since I provide information along with the data offsets. There's info on the overworld, on the magic usage and most of the text. The file is not complete, but it's there : http://www.bwass.org/divers/z2rominfo.txt I made an editor for the overworld (screenshot : http://www.bwass.org/divers/z2me.jpg) some time ago (Mac OS X only, sorry), but I could never find a way to avoid the scrambled tiles after a palace petrifies, even though I could understand why. This is my best guess so far (in case you don't know already : When you complete a palace, the game puts 0B (1 unit mountain) at the offset of the palace, instead of 02. The problem is, if you edit the overworld using for example Dwedit's editor, there's a strong possibility that you will modify the number of bytes that define the strips of terrain BEFORE the palace. If you do this without changing the offset byte that's supposed to turn to 0B, the result will be that a strip more than one unit long will turn into one unit of mountain. All the tiles shift and everything is screwed up... Dwedit should know about this issue, because there's a tool called "NEW MASS" in his editor, that is supposed to do the job. Does it ? (edited by Trax on 05-02-06 12:43 AM) |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Having made an editor like yours some time ago, I suggest that you use separate gif files for all 16 tiles, using the default graphics, and concentrate on the algorithm. And THEN, when everything is fine (loading, saving, etc), try to make your editor take the graphics from the cartridge itself...
That's funny because your editor is almost exactly like mine, except for the "current" tile... See by yourself : http://www.bwass.org/divers/z2me.jpg I'm currently rewriting the entire code from my old project. Although I use Obj-C, I think the algorithms can be quite similar. Drop me a line if you need help with algo... |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Actually, I think Death Mountain/Maze Island area's height is less than the 2 others (unless you use very long stripes of terrain all the time). But I'm pretty sure they all have the same width. I use a matrix of 64X1 at the beginning, and I add rows as the regions are added to the matrix. This way, the matrix is always the right size, no matter the height...
I just realized that there are 4 places in West Hyrule where two groups of the same kind of terrain are adjacent without the first being 16 tiles long (0xF?). This makes the original ROM yield 797 groups instead of the allowed 801. I spend some time on that "problem", thinking it was en error in my algorithm... By the way, I did some research about the overworld palettes, and it seems that some of them are shared by more than one tile. For example, the color at 0x1C471 is used for road, mountain, rock, cemetery, bridge and spider... (edited by Trax on 05-09-06 12:18 AM) |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Oh well, I guess Zelda can't possibly be as popular as SMB3, right ?
Anyways, the major traphole about the overworld resides in the palaces and their respective pointers. If the order of the palaces are modified, your code must be aware of this, because North Palace never turns to rock, so it must be skipped when it comes to assigning coordinates pointers to palaces. In Western Hyrule, you have 4 palaces, including one to skip (North Palace). In Eastern Hyrule, you have 3 palaces, including one to skip (Great Palace), and one that is hidden in the desert (6th Palace), which makes it extra hard because you need to reserve a single desert unit to allow the palace to appear at this precise location. In Death Mountain, there's only the 4th Palace. |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Does anyone know exactly where are located the graphics data for the OverWorld ? This is crucial if we want to get the actual graphics from the ROM instead of premade, default gif files... | |||
|
Trax Red Tektite  Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| For both. When you blow the flute in the desert, the game modifies a byte (from 04 to 02) in memory. If that byte is more than 1 square long (i.e. the high bits are not 0), a glitch occurs and nothing happens (according to my experience). Since the spot that is supposed to be changed into a palace is surrounded by desert, you must tell your editor to save a byte (04) for that spot. If you don't take this into account, the desert strip will go on and the 6th palace won't appear...
I hope my explanation isn't too confusing... By the way, does anyone know where are the bytes that determine the location of Link to make the 6th palace appear upon blowing the flute ? |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| The most complete Zelda II editor is DWEdit's. You can modify the overworld, the side-scrolling areas and the palaces, as well as items and enemies. I think it only works under DOS. Correct me if I'm wrong...
Next, there's Sword, made by Arthus, which is not complete, but has potential, and will run under Windows. We don't have much information about it. But we have a screenshot... And finally, there's ZII Map Editor, by Trax (hey, that's me), which runs under Mac OS X. The overworld editor works correctly, except for the 6th palace's trap. I also made ZII Game Editor, that allows to change magic usage, experience for level up, text, etc, but it's not fully functional. Both progs will eventually be mixed into one... |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Well, you're asking for a lot of things at the same time...
What do you mean by "moving caves" ? If you mean, move their location on the overworld map, I don't think Dwedit does that (again, correct me if I'm wrong), although the data about this IS already cracked. Creating new caves can be two things : either you shorten an existing cave and use the remaining space to make another one. Or you use free space on the ROM to make a new cave from scratch, assuming you can tweak the pointers accordingly... And if I remember well, the enemies are stored as "enemy groups" in the ROM. For each cave section, you have a specific set of enemies defined elsewhere in the ROM. In that sense, you are not completely "free" to add or remove enemies. The limitations of the game are still there... |
|||
|
Trax Red Tektite  Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Well, did you test it to see if everything works correctly ? That's the logical thing to do when you make a ROM hack...
Besides, you have no contact information. At least include your email address... |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Text hacking in Zelda II is well known since a very long time, so I don't think it'd be pertinent to post such information here. Check www.datacrystal.com to get any information about Zelda II that is already cracked. For the rest, if you want something more than "just a post", send me an email and I'll answer your questions... | |||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| I've got a question here...
On datacrystal, there's the locations of the enemies' hit points. This said, what is Link's sword's "force" or "damage" then ? And how much the damage goes up with each level ? Anyone has a hint about that ? |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| That's good, but I suspect you are using an unheadered ROM, because your offSets have a difference of 0x10. And you should add 0x010000 to the offSets. I tested and I got these exact addresses for Link's attack power :
1E67D - 1E684 |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| I see, so you were talking about the RAM offSets...
The addresses I wrote are from the ROM... Most of the time, there are 16 bytes added at the beginning of the ROM file, and that data is used by emulators to know the composition of the ROM, for example the number of CHR and Graphics banks, stuff like that. Since your offsets seemed 0x10 off mine, I thought it was because you're using an unheadered ROM... |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Dammit, it seems totally unreal to me, because the data is on datacrystal.org since a very long time...
For my part, I found the offset pointers for all the dialogs... I guess it's good news for translators... (edited by Trax on 07-03-06 09:42 PM) (edited by Trax on 07-03-06 09:43 PM) |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| I don't know what exactly you are doing to get these results, but I never experienced such glitches when moving key locations. I did it with many locations to test palettes and enemies, and I always return from the scroll view at the same location... | |||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Feel free to add your findings to the database, then...
As for the ROM, I don't think it's enough to screw everything up, but it's still a possibility. Try a few different ROMs, modify only one thing and test. That leads to my other hypothesis : if you used the same ROM for hacking the caves themselves (scrolling part), maybe some pointers were corrupted in the process, yielding unexpected results. That's why you should only change one location pointer, and test... |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| I updated DataCrystal, and I took some time to rearrange sections more logically...
About the bits, it's quite puzzling because if we look at the data we currently have : (0000 0000) - Normal uses Link's Palette (1000 0000) - Normal uses second Sprite Palette (Orange) (0100 0000) - Normal uses third Sprite Palette (Red) (1100 0000) - Normal uses fourth Sprite Palette (Blue) (0001 0000) - Steals Experience Points (0010 0000) - No Damage from Sword (needs Fire) There's no bit left for stealing information. The first two determine the palette used, the 3rd one determines whether the enemy is armored or not, and the 4th one is whether the enemy steals points or not. There must be some other information about enemies hidden elsewhere in the ROM... |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| The "gliding glitch" is actually a glitch in the game itself. The only way to avoid this is to use an emulator with an option that allows right and left at the same time... And turn it off... | |||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Good. This thread is about anything ASM related for Zelda II - Adventure of Link. Fell free to discuss about anything ASM related. I'll start with a question that raised when I tried to decompose the Zelda II ROM from the very beginning. There's something I don't understand, but seems quite fundamental...
I open a normal Zelda II ROM with a Hex Editor. I skip the first 16 bytes and I get started. I also have a reference to the 6502 processor's opcodes. So I get this at 0x10 : 21 6B : Logical AND performed on the accumulator 0A : Arithmetic Shift Left performed on the accumulator Immediately after that, I get : E0 DA E6 DE F4 F4 E8 EF DE EB Which stands for "GAME OVER", according to the ROM's text table. From that point, I don't get it. How does the emulator (or even the real NES) manages to go on with the game if the next instruction is, in fact, simple text data ? Of course, I'm missing something here. But what exactly ? Is it because the init instructions take place elsewhere in the ROM ? I request your help here... |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6285 days Last view: 6285 days |
| ||
| Alright, NetSplit, I remembered the Reset vector thing I saw in another document, and now I got the beginning. Now I have to descrambled all the opcodes, and it's not easy. Is there any way to know what is the content of what is called the Zero Page ? Many opcodes refer to the Zero Page, but if you don't know what is the data out there, you can't understand what the opcodes is supposed to do...
Is there anyone else who did something interesting by hacking code in Zelda II ? If we could find a way to alter enemy behavior, that would be very interesting... |
| Pages: 1 2 3 4 |
| Acmlm's Board - I3 Archive - - Posts by Trax |
