Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Rom Hacking: hukka | 2 guests
Acmlm's Board - I2 Archive - Rom Hacking - Zelda 3 Hacks Database + Hyrule Magic Guide | |
Pages: 1 2 3 4 5 6 7Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
SePH

Geldman
Level: 33

Posts: 207/459
EXP: 219339
For next: 9840

Since: 06-23-04
From: Québec
Caliss de libéraux

Since last post: 6 days
Last activity: 14 hours
Posted on 09-07-04 07:56 AM Link | Quote
Originally posted by DurfarC
This indicates that I have the wrong ROM, and that Lunar IPS works fine (my english = )...


Well personally as for me, all the ips files I've received worked just fine. Be sure to patch the original unmodified rom of Zelda 3... For exemple, if you edit some parts of the original rom then save it, don't try to patch this modified rom with the ips patches.. Well if all doesn't work, just PM me so I can provide you with links to the *working* patched hacks.
DurfarC

Beezo
Level: 33

Posts: 16/483
EXP: 218551
For next: 10628

Since: 09-04-04
From: Norway

Since last post: 20 days
Last activity: 12 hours
Posted on 09-07-04 06:40 PM Link | Quote
I used the unmodified ROM (of course).
Devil_Evilone_RA

Tektite
Level: 14

Posts: 16/64
EXP: 11455
For next: 1616

Since: 06-19-04
From: Canada

Since last post: 18 days
Last activity: 18 days
Posted on 09-15-04 04:07 AM Link | Quote
I was wondering, could you take off my hack, it was just getting know the rom. (also cause my work is SAD! and the music @$#%@ up)
SePH

Geldman
Level: 33

Posts: 208/459
EXP: 219339
For next: 9840

Since: 06-23-04
From: Québec
Caliss de libéraux

Since last post: 6 days
Last activity: 14 hours
Posted on 09-15-04 01:08 PM Link | Quote
Well at least you tried to release something compared to many people who never shown anything... I don't know what this community will need in order to get more people working on Z3, but oh well... Do you really wanna continue working on your hack? Cuz sometimes, I stop working completely on mine for weeks then get back to it later on.
Omega45889

Panser
Level: 30

Posts: 194/335
EXP: 148978
For next: 16891

Since: 03-22-04
From: Vancouver Canada

Since last post: 5 days
Last activity: 6 hours
Posted on 09-15-04 10:16 PM Link | Quote
I didnt know that Devil_Evilone_RA ever released something publically. Was it any good?
MathOnNapkins

Math n' Hacks
Level: 67

Posts: 454/2189
EXP: 2495887
For next: 96985

Since: 03-18-04
From: Base Tourian

Since last post: 1 hour
Last activity: 32 min.
Posted on 09-16-04 12:35 AM Link | Quote
Originally posted by Uchiha Itachi
Well at least you tried to release something compared to many people who never shown anything... I don't know what this community will need in order to get more people working on Z3, but oh well... Do you really wanna continue working on your hack? Cuz sometimes, I stop working completely on mine for weeks then get back to it later on.


I have never released anything because when I do, I want it to be really good. While I like Zelda 3, I find that it is many respects a limited game. A game I have played so much I can't really find anything interesting to do in it anymore. You'd be amazed at how amusing it is to change certain sections of code. One time I routed all sprite handling functions to the one that controls the buzzards. So everytime a sprite appeared on the screen it morphed into some odd ball shape and started spinning around me. Very fun. Can you imagine fighting off all the sprites on the screen when they're attacking you thus?

But anyways, once I get good enough to add/modify certain features of the game, like weapons, additional controls, etc. I might release something. It's coming, I swear

SePH

Geldman
Level: 33

Posts: 209/459
EXP: 219339
For next: 9840

Since: 06-23-04
From: Québec
Caliss de libéraux

Since last post: 6 days
Last activity: 14 hours
Posted on 09-16-04 06:08 AM Link | Quote
Originally posted by MathOnNapkins
You'd be amazed at how amusing it is to change certain sections of code. One time I routed all sprite handling functions to the one that controls the buzzards. So everytime a sprite appeared on the screen it morphed into some odd ball shape and started spinning around me. Very fun. Can you imagine fighting off all the sprites on the screen when they're attacking you thus?

But anyways, once I get good enough to add/modify certain features of the game, like weapons, additional controls, etc. I might release something. It's coming, I swear




Wow, are you saying that you actually managed to change bytes within the actual rom to make fun things happen? Well, that's a good thing considering that I'm sure a lot of people don't share their finds...
MathOnNapkins

Math n' Hacks
Level: 67

Posts: 455/2189
EXP: 2495887
For next: 96985

Since: 03-18-04
From: Base Tourian

Since last post: 1 hour
Last activity: 32 min.
Posted on 09-16-04 06:52 AM Link | Quote
Oh that? Those are more like amuzing accidents that happen when I'm trying to figure out what a particular piece of code does. So I'll erase portions of code. It's actually a pretty primitive technique called NOPing subroutines. You can do that, or you can make a subroutine return prematurely to get different effects. Sometimes you break the code (i.e. crash the game) and sometimes you get functional insanity (the above).

The buzzard code thing was quite fun because you would kill an enemy, and it would drop a rupee, then the rupee would start flying at you trying to kill you. Though many of the enemies were harmless, it was still fucking cool.

I also got it so that enemies on the screen don't have to hit link to hurt him. (i.e. by disabling hit detection.) It's really interesting trying to get past even one or two screens with this "feature".


(edited by MathOnNapkins on 09-16-04 01:17 AM)
SePH

Geldman
Level: 33

Posts: 210/459
EXP: 219339
For next: 9840

Since: 06-23-04
From: Québec
Caliss de libéraux

Since last post: 6 days
Last activity: 14 hours
Posted on 09-16-04 12:55 PM Link | Quote
LOL, that's something to try out then. The thing is that you have to remember what you change, otherwise you'll be in trouble. Those two effects were cool enough feature tho. The ruppee killing you, adds insanity to the hack itself..
MathOnNapkins

Math n' Hacks
Level: 67

Posts: 461/2189
EXP: 2495887
For next: 96985

Since: 03-18-04
From: Base Tourian

Since last post: 1 hour
Last activity: 32 min.
Posted on 09-16-04 01:59 PM Link | Quote
Originally posted by Uchiha Itachi
LOL, that's something to try out then. The thing is that you have to remember what you change, otherwise you'll be in trouble.



True that, I was just trying to figure out what I edited about 30 min ago in a file called 2Zelda.smc. That's my guinea pig rom file for testing anything and everything. I keep pure copies of my rom on ice on my online accounts, just in case. (Read only )

I have most of what I know documented, so it's not a hard procedure to go and reverse it usually. Most of the time I can search in the hex editor for EAEAEA and sure enough I'll find a NOPed routine.

Killer rupees, mwa ha ha. It's not out of the question.
Euclid

Cheep-cheep
Level: 23

Posts: 106/193
EXP: 65528
For next: 2195

Since: 03-15-04
From: Australia

Since last post: 24 days
Last activity: 7 days
Posted on 09-16-04 03:48 PM Link | Quote
I'm usually not a fan of "NOPing routine experiment" but it does sometimes produce good results.

I mostly deal with "adding extra code when this happens", finding a 4 byte instruction to do a JSL, jump to somewhere, redo the code you used, add extra routine. The good thing about this is that i can be sure that there's nearly no side effects. For example, adding code to make you lose rupies when hit by an enemy.
MathOnNapkins

Math n' Hacks
Level: 67

Posts: 463/2189
EXP: 2495887
For next: 96985

Since: 03-18-04
From: Base Tourian

Since last post: 1 hour
Last activity: 32 min.
Posted on 09-17-04 02:36 AM Link | Quote
You do have a point. Though for me, NOPing is much more to the point. You'll have a good idea of where and how you broke something. And plotting out a new jump location also takes more time. I can swap hex files at will and reload my pure rom if something goes haywire, test it in my emu with a save state, and badda bing badda boom I'm there.

Of course, I don't just NOP and then generalize what a procedure does. I proceed to look at that code and disassemble it, comment it, etc. I also employ other methods, like reindexing jump tables to swap certain behaviors, using cheat codes to isolate variables, and editing data tables and observing the effects.

The one bad thing about NOPing though is that if you're not initially aware of the structure of the machine language in some places, you may end up crashing your emu, not just the game. And that does suck a fat one, but it happens fairly rarely for me.
d4s

Panser
Level: 29

Posts: 70/325
EXP: 142151
For next: 5734

Since: 03-23-04

Since last post: 13 days
Last activity: 1 day
Posted on 09-22-04 06:34 AM Link | Quote
Originally posted by MathOnNapkins
You do have a point. Though for me, NOPing is much more to the point. You'll have a good idea of where and how you broke something. And plotting out a new jump location also takes more time. I can swap hex files at will and reload my pure rom if something goes haywire, test it in my emu with a save state, and badda bing badda boom I'm there.



i have to say that i recently played around with zelda 3, too and if you wanna
patch routines fast, flexible and -most important- easy to maintain, you HAVE to get WLA DX, its a multiple platform assembler sporting 65816 and spc700 support
and it also has the ability to patch roms directly.

heres an example, should be fairly easy to understand.
just for the record, this routine replaces the "get next pointer for decompressed graphics block"-loader in zelda 3.
i coded this because i wanted to move the graphics in the rom around, especially to get around the problem with recompressed gfx blocks that are bigger than the original ones.
this way, wla dx relocates all graphics blocks dynamically every time i compile my code.
hell, i could even move it from one bank to another in a matter of seconds.
enough of the rambling, here is the example:
==========================================================================================
; HACK
;==========================================================================================
; hooktrap for compressed gfx pointer loading routine

.BANK 0 SLOT 0 <----apply patch on bank 0, offset $e7783
.ORG $E783




JSL (CompGfxPointerLoader+10354688) <------jump to my code, hirom(so i have more space per bank, lorom is soooo annoying)
JMP $E79C






==========================================================================================
; Patch
;==========================================================================================
;custom loader for zelda 3s compressed 3bpp gfx

.BANK 33 SLOT 0 <----selects wich bank to use
.ORG 0
.Section "Main Intro Code" overwrite <-------let wla dx dynamically handle the ORGing and overwrite rom(although zelda has nothing in bank 33 cause its just 8mbits.

CompGfxPointerLoader:

PHP ;save cpu status
PHB ;save last bank
LDA.B #(:CompGFXBankTable+192) ;get bank where the pointertable is stored
PHA ;push that shit on the stack
PLB ;get current data bank from stack
SEP #$30 ;index/mem 8bit
STZ $00 ;
LDA.B #$40 ;set up destination
STA $01 ;decompression buffer
LDA.B #$7F ;in wram, 7f400
STA $02 ;
STA $05 ;
LDA CompGFXBankTable,y ;get next pointer
STA $CA ;store bank
REP #$30 ;index 16bit
TYA
ASL A ;wish asl y was possible.
TAY ;multiply pointerselector by two cause thats
LDA CompGFXTable,y ;a two byte table.
STA $C8 ;store offset in $c8 and $c9
TYA
LSR A ;my mommy told me to
TAY ;leave things like
LDA $C8 ;i found them, so there!
PLB ;restore data bank
PLP ;restore cpu status
RTL ;

now, we also have a nice 2 byte pointertable + seperate banktable, not the ugly splitted shit that
was there in the first place.(a seperate pointertable for each bank, lo adress and hi adress, wich is hard to follow)




(edited by d4s on 09-21-04 09:37 PM)
(edited by d4s on 09-21-04 09:40 PM)
(edited by d4s on 09-21-04 09:44 PM)
(edited by d4s on 09-22-04 10:28 AM)
MathOnNapkins

Math n' Hacks
Level: 67

Posts: 521/2189
EXP: 2495887
For next: 96985

Since: 03-18-04
From: Base Tourian

Since last post: 1 hour
Last activity: 32 min.
Posted on 09-22-04 12:36 PM Link | Quote
^ Very nice. When I'm not tired out of my gourd I'll take the time to browse it more carefully. Thanks for the tip, though I will not be patching for a while. It's nice to know what's out there.
d4s

Panser
Level: 29

Posts: 71/325
EXP: 142151
For next: 5734

Since: 03-23-04

Since last post: 13 days
Last activity: 1 day
Posted on 09-22-04 07:26 PM Link | Quote
actually, the above routine has a small flaw causing bad behaviour sometimes.(some routines like to set up the decompression buffer themselves and
jump to the pointerloader some opcodes later, didnt notice that in the first place)
i fixed it, but i doubt that anyone here will use it at all so i'll leave it that way.

if you have questions concerning asm hacks for zelda 3, feel free to ask.
i'd say i have quite a good overall understanding of the code and the core functions so it might be easier for me to do certain things than for someone who had to trace and document everything first, especially if he/she isnt that experienced when it comes to 65816 assembler.

Euclid

Cheep-cheep
Level: 23

Posts: 111/193
EXP: 65528
For next: 2195

Since: 03-15-04
From: Australia

Since last post: 24 days
Last activity: 7 days
Posted on 09-22-04 08:19 PM Link | Quote
Nice, now i can write my own patch (i didn't know how to use those .BANK stuff )

what i usually do is write it in the rom straight away (which takes a while, have to convert all those crap to opcode hex values, and i'm kinda sick of it)
d4s

Panser
Level: 29

Posts: 72/325
EXP: 142151
For next: 5734

Since: 03-23-04

Since last post: 13 days
Last activity: 1 day
Posted on 09-22-04 09:15 PM Link | Quote
Originally posted by Euclid
Nice, now i can write my own patch (i didn't know how to use those .BANK stuff )

what i usually do is write it in the rom straight away (which takes a while, have to convert all those crap to opcode hex values, and i'm kinda sick of it)


yeah, thats the point, and most important, you dont have to manually calculate adresses for jumps etc.

and i would like to see you rearranging and repointing large data arrays in hex.

even simple NOPs or BRAs to test routines work better when done with wla dx cause you can keep better track of all your changes in a textfile and if you corrupt something, you just can comment out the stuff that broke something and recompile, no need to get a clean rom or work with ips patches.



(edited by d4s on 09-22-04 12:16 PM)
MathOnNapkins

Math n' Hacks
Level: 67

Posts: 528/2189
EXP: 2495887
For next: 96985

Since: 03-18-04
From: Base Tourian

Since last post: 1 hour
Last activity: 32 min.
Posted on 09-22-04 11:49 PM Link | Quote
Originally posted by d4s
Originally posted by Euclid
Nice, now i can write my own patch (i didn't know how to use those .BANK stuff )

what i usually do is write it in the rom straight away (which takes a while, have to convert all those crap to opcode hex values, and i'm kinda sick of it)


yeah, thats the point, and most important, you dont have to manually calculate adresses for jumps etc.

and i would like to see you rearranging and repointing large data arrays in hex.

even simple NOPs or BRAs to test routines work better when done with wla dx cause you can keep better track of all your changes in a textfile and if you corrupt something, you just can comment out the stuff that broke something and recompile, no need to get a clean rom or work with ips patches.



Well I'll give it a try but I'm skeptical. I can test the effects of a modification in seconds flat using savestates (almost always, if something was in memory or VRAM and not being loaded after the save state occurs I suppose that would be a conundrum, but not one that the wla dx would easily solve either.) and keeping a read only rom on hand. I usually only modify one or two bytes at a time when testing, however, this would be useful for longer stuff, like when I'm testing out how to change Link's speed under certain conditions and such. I'll use it for my actual hacking, not testing, probably.
Euclid

Cheep-cheep
Level: 23

Posts: 112/193
EXP: 65528
For next: 2195

Since: 03-15-04
From: Australia

Since last post: 24 days
Last activity: 7 days
Posted on 09-23-04 06:27 AM Link | Quote
Originally posted by d4s
yeah, thats the point, and most important, you dont have to manually calculate adresses for jumps etc.

and i would like to see you rearranging and repointing large data arrays in hex.

ha those jump addresses are very annoying ok, especially if you accidentally forgot some instructions and have to redo all the jumps again.

With large data arrays i'll probably write a simple program to do the job instead
d4s

Panser
Level: 29

Posts: 74/325
EXP: 142151
For next: 5734

Since: 03-23-04

Since last post: 13 days
Last activity: 1 day
Posted on 09-23-04 04:55 PM Link | Quote
Originally posted by MathOnNapkins
Originally posted by d4s
Originally posted by Euclid
Nice, now i can write my own patch (i didn't know how to use those .BANK stuff )

what i usually do is write it in the rom straight away (which takes a while, have to convert all those crap to opcode hex values, and i'm kinda sick of it)


yeah, thats the point, and most important, you dont have to manually calculate adresses for jumps etc.

and i would like to see you rearranging and repointing large data arrays in hex.

even simple NOPs or BRAs to test routines work better when done with wla dx cause you can keep better track of all your changes in a textfile and if you corrupt something, you just can comment out the stuff that broke something and recompile, no need to get a clean rom or work with ips patches.



Well I'll give it a try but I'm skeptical. I can test the effects of a modification in seconds flat using savestates (almost always, if something was in memory or VRAM and not being loaded after the save state occurs I suppose that would be a conundrum, but not one that the wla dx would easily solve either.) and keeping a read only rom on hand. I usually only modify one or two bytes at a time when testing, however, this would be useful for longer stuff, like when I'm testing out how to change Link's speed under certain conditions and such. I'll use it for my actual hacking, not testing, probably.


well, after all, its a matter of personal taste.
im extremely happy with wla dx, but that doesnt mean it has to be like that for everyone else, of course.

oh, and that speed thing also got my attention.
what i found most annoying in zelda 3 was the fact that
when running over ladders, you would be slowed down extremely.
i wrote a quick fix to get around that shit, but changing the speed under certain
conditions sounds interesting, too.
maybe speed arrows allowing you to boost or enemy attacks that slow you down.

or is something like this already in the game?
i have to admit that its rougly 10 years ago that i've beaten the game, so when im hacking it now, i permanently stumble across features and im like:
"oh,wow, i didnt know that one...or...do i..?" XD


(edited by d4s on 09-23-04 07:58 AM)
(edited by d4s on 09-23-04 07:59 AM)
Pages: 1 2 3 4 5 6 7Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Rom Hacking - Zelda 3 Hacks Database + Hyrule Magic Guide | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.011 seconds.