 |
| 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 |
|
| | ||
| 0 users currently in ROM Hacking. |
| Acmlm's Board - I3 Archive - ROM Hacking - Zelda II - ASM Hacking |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
Trax Red Tektite                  Since: 05-01-06 From: Québec Last post: 6284 days Last view: 6284 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... |
|||
|
jeff Double metal axe   Since: 11-17-05 Last post: 6284 days Last view: 6284 days |
| ||
| i don't really have much time to look at it(or the rom, even), but i'm sure it's just stuff in front of it to show where to put it on the screen, but to be honest, i couldn't tell you... i doubt GAME OVER can be even a good sequence of code... but if it did that'd be awesome(although f4 isn't even a valid opcode). (edited by jeff on 07-30-06 07:04 PM) (edited by jeff on 07-30-06 08:44 PM) |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828  Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6285 days Last view: 6285 days |
| ||
| Some NES games have the graphics stored at the beginning of the ROM, and the code elsewhere. In the actual cartridge the code and graphics would be stored on two separate chips. | |||
NetSplit Paratroopa Since: 11-18-05 Last post: 6446 days Last view: 6446 days |
| ||
Yeah, you're definitely missing something.  I'm no expert on this since I almost never have reason to deal with it, but the last 6 bytes of loaded ROM are essentially pointers to stuff the game should do at certain times. These 3 vectors are the NMI vector, Reset vector, and IRQ/BRK vector, respectively. NMI is related to drawing to the screen, Reset is used for the beginning of the game's code, and BRK for where to go when coming across a BRK instruction. When the game is powered on, the appropriate vector (the reset vector, I'd assume ) is used to tell the game where to start executing code. That's how you'll find the start of the game's code; the beginning of the ROM is not necessary (maybe even never?) the start of the code.
As I said, I'm not an expert on this stuff. I was intentionally vague in some spots because of that. If anyone wants to go more in depth or sees an error in this post and wishes to correct me, feel free to do so. |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6284 days Last view: 6284 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... |
|||
|
NetSplit Paratroopa Since: 11-18-05 Last post: 6446 days Last view: 6446 days |
| ||
| Zero page stuff is just like any other RAM, except there are opcodes made to address it specifically so you can save ROM space by having shorter code. Each game uses zero page RAM differently, so you'll either have to read the code to figure out what it's doing with specific RAM addresses or, better yet, use FCEUXD. FCEUXD has a cheat console, debugger, and hex editor that'll let you observe and modify RAM and game code / data. By observing what sorts of things cause changes in RAM and what sorts of things happen when you modify the contents of RAM, you can easily figure out what various RAM values do.
As far as hacking code in Zelda 2, I'm not aware of any assembly hacking that has been done with that game. However, changing enemy behavior isn't all that hard. The game likely uses enemy IDs to grab the appropriate pointer from a pointer table to the location of enemy AI for specific enemies. AI isn't necessarily complex; some AI can be very simple. You just need to know all about the RAM for sprites (x velocity high / low, x position high / low, y velocity high / low, y position high / low, sprite flags, sprite health, that sort of thing) and then dealing with sprite AI can be pretty easy and creating your own sprite AI from scratch becomes fairly simple. |
|||
|
Trax Red Tektite Since: 05-01-06 From: Québec Last post: 6284 days Last view: 6284 days |
| ||
| I see...
For now, my PC behaves like a dumbass, so I can't rely on it for emulation. So I use RockNES on my Mac, which is good, but there's no function related directly to hacking or debugging. I don't have access to RAM contents... By the way, I got a hint about the flying sword, for those who want to make the flying sword fly farther, or even infinitely. At 18E6, I replaced 0A by CA, and it makes the sword flies infinitely. But its effects are still limited to the normal range. Beyond the normal range, the sword goes through everything, until it hits the screen border... If anyone knows ASM better than me, that may be a good start... And if anyone want to take the time to find pointers like described by NetSplit, that'd be good too. Enemy IDs are on DataCrystal. There's probably other data in RAM that points to code related to enemy AI... |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - Zelda II - ASM Hacking |
| |
