News: 11 March 2016 - Forum Rules

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - umaggot

Pages: 1 [2]
Programming / Re: Faxanadu - Assembly
« on: June 19, 2011, 10:59:58 am »
Oh wow, that is a lot of help! Yeah, I caught on to how my instructions were pointless at times eventually; considering the LDA after the TAX was just going to change A anyway, the first LDA was a complete waste! As for JMP, that makes sense! I've been using - Opcodes as a reference, but I never honestly understood a decent chunk of it. It did help, but I sometimes need a little more English and a little less machine. So what you're saying, is that the zero flag applies to A, X, and Y -- and not just A? Yeah, that resource you've linked confirms it! Hey, thanks for the help, I'll keep this in mind!

As fascinated as I was to learn so many neat tricks, I've come to feel even more foolish; the bug that makes his chest disappear probably has to do with *what* I'm loading. I'm saving and loading PPU instructions as well. It just hit me like a ton of bricks while I was trying to rule out the cause. I looked at the SRAM and that's when it hit me. I'll work on altering the load code first, so that it doesn't load carelessly. I'm kindof surprised that the PPU is really affected so much by it, considering how often that it changes.

If it somehow isn't fixed after that, then I won't really know what to do.

// Being more specific has naturally lead me to writing a longer load code. Now the game insists on crashing -- so I either overwrote something important, or I did the math wrong on the specified addresses. I've condensed it as much as I could according to your quidelines, but I probably have to find another way. I'm too exhausted to finish up right now, I've been losing sleep on this project. I'll be back and hopefully can report some good news later on.

// Well, then. I think I just figured out what the culprit is. It's either an error in the dump, or a bug that was corrected for the US/EU release. I've spent way too long trying to figure that out!

Programming / Re: Faxanadu - Assembly
« on: June 19, 2011, 01:44:10 am »
I asked on IRC about necroposting, and I believe I have a good enough reason to, so here goes:

It's me again, it's been a long time. I was wondering if there is a more efficient way to write my code?

Code: [Select]
New code at the bottom of the message.
This code was embarrassing; I realized how many flaws it had on my own.

I already know some things; like if I changed CPX #$FF to #$00, and got rid of the duplicate code, that would reduce the space it takes up. I assume that X only goes up to FF, and the reason that I even bothered putting in a TAY is because I thought somehow, the Y register would help; I could probably get rid of that and just LDA #$00 TAX, which would still take up the same amount of bytes. There's probably an easier way, right? Ultimately, I just want it to load $0390-058F (Though data in $058F is unnecessary) to A and store it to $6000-61FF. The code works, but is too long and I believe it overwrites something important because of its length; I can see through the character's chest when he's climbing ladders, while wearing Studded Mail. (Could that be PPU related?)

This is an older code I've had saved in notepad, by the way; the current version JSRs to load item text, saying "GAME SAVED" instead of printing a mantra.

// Here's what I have so far, new code.

Code: [Select]
A9 00     LDA #$00
AA        TAX
BD 90 03  LDA $0390,X @ $0390 = #$00
9D 00 60  STA $6000,X @ $6000 = #$00
E8        INX
E0 00     CPX #$00
D0 F5     BNE (LDA $0390,X)
BD 90 04  LDA $0490,X @ $0490 = #$00
9D 00 61  STA $6100,X @ $6100 = #$00
E8        INX
E0 00     CPX #$00
D0 F5     BNE (LDA $0490,X)
A9 5E     LDA #$5E ;Item message ID "GAME SAVED"
20 0E 8C  JSR $8C0E ;Display item message
60        RTS

I feel foolish for using so many unnecessary register transfers. Even still, though, I wonder if there was a shorter way to write this.

Programming / Re: ARM/THUMB compared to 6502 ASM?
« on: May 17, 2011, 06:22:59 am »
I've been trying to post a reply since yesterday, I didn't want anyone to think I was ignoring them. Anyway, I appreciate the links very much. I have actually seen a couple of those, as well as a few by King Mike and the old developer of No$GBA -- it really is a shame that dev version is no longer available for release. I'll definitely give VBA-sdl-h a shot, as well as Boycott Advance. In regards to the workload, I'm a hobbyist first and foremost; if and when I get it done is all up to me, so no promises.

As for the hack itself, you're more than likely right about that. I've been working most of it out in my head, and if I could, I'd rather be doing a GameCube hack to port over the maps, enemy and boss data -- and keep the bigger screen and single player functionality as it had worked there. Instead, I would more than likely just get rid of the other 3 Links altogether, and either give the single Link super powers (or basically Titan Mitts and Iron Boots) to push and pick up larger blocks, and handle larger switches. Granted, a Minish Cap system could possibly give the same desired effect, I know that it wouldn't always work. One can't pull apart an enemy or play baseball (basically) with it alone -- and it's nearly impossible to defeat the jelly-like creatures that you bounce off of without teamwork. Using map hacks could make those three possible to defeat (holes) -- but I think making a piece of the enemy stay in place, slowing down an enemy's regeneration, and allowing an enemy to be destroyed when it lands would give a similar effect. Bosses are tricky as well. The snail would require a longer stun time -- and the invisible remaining weakness would have to show itself, the plant would require that pulling an area would work just as well as pulling all areas -- and red petals must be replaced by green, the Death Mountain boss' attack would either be deflected by the boss itself or it would have to act as though one hit was good enough to damage it, and Vaati would be a combination of the above changes. As for traps or level changes, I'd have to make every switch sticky, and change any instance of color-specific blocks to green.

There's a lot of work, but as I said, if and when all depends on me. No promises, but I really do appreciate the resources. Thank you for the help! In the meantime, I have some bugfixes to upload and a retranslation that needs tending to. (King Mike's resources have proven invaluable with the latter.) I'll be back sooner or later.

Programming / ARM/THUMB compared to 6502 ASM?
« on: May 14, 2011, 01:53:08 am »
I have a general question about ARM/THUMB hacking; it's mainly about getting started. Granted I've worked with ASM two years ago -- and fairly recently as well, GBA hacking seems to be a whole new ballpark. I usually use a combination of a cheat finder, debugger, and hex editor, not unlike what FCEUXDSP has. What I want to know is this: how could I apply the same principles -- ruling out addresses with a cheat finder, and then using a debugger to stop all of the action immediately when the address and function I'm looking for has been called, in VBA (or VBALink)?

For a game specific example, The Legend of Zelda: Four Swords for the GBA. I've been using the cheat finder to call out differences between when linked, and when unlinked -- specifically, in-game and after forcing a disconnect (in-game error screen). I haven't been using any specific numbers in the search. The problem is that I can't seem to find any specific address that calls for a link connection. I've tried checking for different address bit sizes as well, but I still end up with 0 entries by the time I'm done comparing. When I had only a handful of addresses that I saved from the search, I'd only managed to successfully find an "A button prompt" cheat (which tells you to press A on the title screen, but doesn't allow you to actually do so and enter the game). My goal is to make the game entirely single-player. If I had to take a guess, I would say that it has something to do with a multiplayer-specific call, that is made on the second VBA Link window. I don't claim to know exactly what I'm talking about, but just out of curiousity, if that were the case -- how would I work around it?

That should just about do it for questions, thank you for taking the time to read this.

Pages: 1 [2]