News: 11 March 2016 - Forum Rules

Author Topic: Faxanadu - Assembly  (Read 17590 times)

umaggot

  • Guest
Faxanadu - Assembly
« on: January 04, 2009, 01:50:09 pm »
Allow me to preface this by stating that I'm relatively new to assembly, but I've had much success so far. I'm a little embarrassed to be posting this script, as sloppy and inefficient as it is, but I feel at a loss here -- for something that is seemingly very simple. I've been wondering about SubRoutines and JuMPing, and how they may be affecting the code overall. I've rerouted the script from the "use item" segment to an unused area (to add new/unused items) and here's what I have:

LDY $03C1 = #$15 ;Loads the item hex
AND #$11 ;Checks if the item hex is 11 (Is the item a Brown Potion?)
BNE $FCF9 ;If it isn't 11, it branches to the original item use script (Which has been moved)
BRK ;Giving myself free space.
BRK ;Twice. I don't remember why I did this.
JSR $FCED ;Jump to SubRoutine -- Brown Potion used text.
JSR $C8DC ;Removes item picture.
JSR $C4BF ;Removes item.
JMP $C506 ;MP recovery.
RTS ;ReTurn from Subroutine -- back to the original code.


Using any item from Wing Boots, to the Brown Potion is fine -- but items without a script (or with new scripts) beyond the value $11, proceed to use the Brown Potion script. I've confirmed this by corrupting the area where the new scripts point to and pointing the Brown Potion script to that, instead of the original item use script. It refuses to read the new data at all, and simply proceeds beyond the BNE line. This also confirms that the original item use script as I've moved it, isn't the problem -- it's definitely the script that I've posted here.

If you need additional information, feel free to ask. I look forward to and will appreciate any and all assistance with the matter.

I hope that this doesn't belong in "Script Help and Language Discussion Rules", I hope that you'll forgive me if I've posted this in the wrong area. Both boards seem to be "the right board", but as far as I can tell, the other one is mostly for translation help?

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: Faxanadu - Assembly
« Reply #1 on: January 04, 2009, 02:01:23 pm »
1)  AND does not do what you might be thinking it does.  It's for bitmasking -- turning off specific bits, and/or isolating bits you're interested in.  It is not for comparing full values.  For that you probably want CMP.

2)  Don't use BRK!  If you just want to fill blank space, use NOP (opcode $EA).  BRK forces an interrupt and is very dangerous unless you know what you're doing.  I'm surprised your game hasn't been crashing -- faxanadu must have an empty IRQ routine.

3)  You're using LDY to load the item index -- but AND (and CMP) both work with A, not Y.  Switch that to LDA and use CMP -- or if you need it to be in Y (like for one of the later JSRs), then use LDY and CPY (CPY = same as CMP, but uses Y instead of A)


To clarify CMP/CPX/CPY for you....

CMP simply compares the value in A with the given value (we'll call it 'm'), and sets Z and C flags appropriately.  You can then check Z (with BNE/BEQ) or C (with BCC/BCS) to jump to different areas depending on the outcome of the CMP.

if Z is set, then A=M
if C is clear, then A<M
if Z is clear, then A != M
if C is set, then A >= M

so....

Code: [Select]
LDA $03C1    ; item index
CMP #$11     ; compare to $11
BEQ index_is_11
BCC index_is_less_than_11
BCS index_is_greater_than_11

CPX and CPY are exactly the same, but with X and Y instead of A
« Last Edit: January 04, 2009, 02:11:07 pm by Disch »

umaggot

  • Guest
Re: Faxanadu - Assembly
« Reply #2 on: January 04, 2009, 02:26:49 pm »
Oh, thank you very much! This is very helpful to know, as the information that I've been following is entirely in technobabble. Would it be alright with you if I credited you in-game for your assistance?

I believe that it should be CPY, as the game pointed out "LDY $03C1 = #$15", which was myself checking an item that was beyond $11 via cheats. When the debugger shows me this value, it's showing me the specific variable of bit "Y" in the RAM at $03C1 as-is at that point in time, correct? I'm not really sure what the difference is between A, Y and X, but I've assumed that these are all their own specific bit-values, their own labels for the relative address(es) -- am I correct?

// Wow, alright. That makes sense! I understand BEQ, but I'm positive that I want it to BNE -- I'll modify this post if I have any problems. It's definately not CPY as I'd thought, so I'll attempt your code.

// That worked! The Brown Potion code is flawless now, thanks again!
« Last Edit: January 04, 2009, 02:38:42 pm by umaggot »

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: Faxanadu - Assembly
« Reply #3 on: January 04, 2009, 02:43:44 pm »
Oh, thank you very much! This is very helpful to know, as the information that I've been following is entirely in technobabble. Would it be alright with you if I credited you in-game for your assistance?

It wouldn't bother me, no.  But it does seem rather unnecessary.


Quote
I believe that it should be CPY, as the game pointed out "LDY $03C1 = #$15"

Yeah -- if you're using LDY, then you want CPY.

Quote
When the debugger shows me this value, it's showing me the specific variable of bit "Y" in the RAM at $03C1 as-is at that point in time, correct?

Your terminology is a little funky here.  Not like it matters but I'm bored so here's some random ramblings:

- $03C1 is an address
- each address houses one 'byte' of information
- a byte can be any number between $00-$FF
- there are 8 'bits' in a byte
- bits are binary (bit = "binary digit") so each bit can only be either 0 or 1
- A, X, and Y are 'registers', which is just a fancy word meaning they're variables
- A, X, and Y are also one byte in size

Anyway to really answer your question... when it says "LDY $03C1 = #$15", then that means that, at the time the debugger was snapped, the byte at address $03C1 was $15.  It tells you absolutely nothing about the contents of Y (but for that you can look elsewhere in the debugger).

Quote
I'm not really sure what the difference is between A, Y and X, but I've assumed that these are all their own specific bit-values, their own labels for the relative address(es) -- am I correct?

A, X, and Y do not have an address.  And they're all exactly the same.  They're just variables... all they do is hold a number.  The only thing that really makes them different is how they can be used by instructions.  ADC, for example, can only add to A, not to X or Y.  DEX/DEY work with X and Y, but not with A.  You can use X and Y for indexing (LDA $0123,X   STA $0234,Y), but you can't use A for indexing.


EDIT-

Glad to hear you got it working.  :thumbsup:

creaothceann

  • Hero Member
  • *****
  • Posts: 2619
  • SPINESHARK
    • View Profile
    • creaothceann's website
Re: Faxanadu - Assembly
« Reply #4 on: January 04, 2009, 03:03:55 pm »
If it helps - these 'variables' are small RAM cells in the processor.

umaggot

  • Guest
Re: Faxanadu - Assembly
« Reply #5 on: January 04, 2009, 03:17:08 pm »
Awesome! Thank you for correcting me! I'll keep all of this information in mind, as I definately don't want to spout incorrect information while I blog and record my progress. ;) I'll make sure to keep to this topic incase I have any future inquiries, but I should be good for quite some time now. :)

umaggot

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: Faxanadu - Assembly
« Reply #6 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.
« Last Edit: June 19, 2011, 03:40:43 am by umaggot »

snarfblam

  • Submission Reviewer
  • Hero Member
  • *****
  • Posts: 595
  • CANT HACK METROID
    • View Profile
    • snarfblam
Re: Faxanadu - Assembly
« Reply #7 on: June 19, 2011, 10:19:43 am »
It would definitely help to have some easy-to-use reference, so you can look at the details of a particular instruction, or even look over the document to familiarize yourself with the instruction set.

Code: [Select]
A9 00     LDA #$00
AA        TAX
You can load directly to any of the registers (not all addressing modes are available for all registers). So you could change this to
Code: [Select]
LDX #$00



Code: [Select]
E8        INX
E0 00     CPX #$00
D0 F5     BNE (LDA $0390,X)
Another thing to be aware of is that when an instruction modifies a register, it also modifies the processor status flags, which often means you can skip the compare instruction.

The compare instructions (CMP, CPX, CPY) work by setting processor status flags, and the branch instructions branch only if the appropriate processor status flag is set. CPX sets the Z (zero) flag to indicate equal or clears the Z flag to indicate not-equal. BEQ and BNE branch based on the value of the Z flag (BEQ branches if Z is set, BNE branches if Z is clear).

The thing is, INX also affects the Z flag. If INX causes X to be zero, the Z flag is set, and if INX causes X to be non-zero, the Z flag is cleared. So you don't need to compare to zero. The Z flag already tells you whether X is zero, which means you can skip the CPX instruction all together.
Code: [Select]
; In this case you can think if BEQ as "branch if zero" and BNE as "branch if non-zero"
INX
BNE branchTaregt



Another thing I see: you can "interleave" your copy routine. In other words, you can copy more than one byte in the same loop, which means you don't need two loops. This can make some loops trickier or harder to change down the road if you ever need to (i.e. it's less "maintainable"), but in this case it might be a good idea.
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)
Would become
Code: [Select]
    LDA #$00
    TAX
LoopTop:
    LDA $0390,X  ; Copy byte from first block
    STA $6000,X
    LDA $0490,X  ; Copy byte from second block
    STA $6100,X
    INX
    CPX #$00
    BNE LoopTop



One last thing:
Code: [Select]
20 0E 8C  JSR $8C0E ;Display item message
60        RTS
There's a trick you can use here. Any time you have a JSR that is immediately followed by an RTS, you can change the JSR to a JMP and get rid of the RTS. The result will still be the same. This is called a tail call.  It works because when you call a subroutine with JMP, the RTS at the end of that subroutine causes the processor to return from your routine.



I'll leave it up to you to put it all together. With all those things combined, you could reduce this routine from 15 instructions to 9.

umaggot

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: Faxanadu - Assembly
« Reply #8 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 6502.org - 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!
« Last Edit: June 21, 2011, 11:36:54 pm by umaggot »

umaggot

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: Faxanadu - Assembly
« Reply #9 on: June 28, 2011, 04:56:43 am »
So to bring you up to speed, I'm working on an SRAM hack. It's mostly done, but there's a 15-second delay (ouch!) after the game is saved, and the save icon is written over with a garbled Japanese character. I've been trying to use the cheat feature to figure out if it can somehow be fixed by writing to a relevant address in the RAM, but I'm not getting any bites. I've also been using the debugger to step through the code, but it just goes in a big circle and would take a painfully long time to step through until I'd actually find what's causing the icon to be written over. So just for the sake of curiousity, is there an easier way? I've also looked through SP's disassembly and have tried experimenting with the most relevant bytes that I've seen, but I'm not getting any hits.

// If it helps, I set a break point for $61FF -- and it seems that the cursor blinks AND the game saves repeatedly, during all of those 15 seconds. In reality, it only needs to save once.

July 03, 2011, 01:13:46 am - (Auto Merged - Double Posts are not allowed before 7 days.)
The Faxanadu SRAM (J) Open Beta patch is here!

This patch is for the Japanese version only. It will NOT work on the US/EU versions. This patch will allow you to save the game, when you would've otherwise received a mantra.

If you find any bugs or glitches, *please* let me know! Thank you!

I've already played through it twice, and I've noticed that an armor is replaced at some point in Branch. If I had to take a solid guess, it'll have something to do with obtaining the Battle Suit. I haven't yet tested to see whether or not this is just a bug in my copy of Faxanadu (J), but I am aware that my copy has a bug that prevents a part of the Studded Mail from appearing while climbing a ladder.
« Last Edit: July 03, 2011, 01:13:46 am by umaggot »

frsj8112

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
Re: Faxanadu - Assembly
« Reply #10 on: April 04, 2015, 04:37:24 am »
Hi, sorry for waking a topic from the dead, but I would looooooooooooooooove a SRAM version of Faxanadu (US). I've started looking into umaggot's SRAM hack, but I'm still too much of a noob to understand how to re-use his work.

I thought that I could try to implement a save-to-sram-every-clockcycle-routine, just to see if I can save the amount of gold.

Can someone give me some pointers, I would to learn more. And yes I've been checking 6502.org as well  ;)

umaggot

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: Faxanadu - Assembly
« Reply #11 on: April 04, 2015, 09:34:28 am »
Hey there, frsj8112. (and everyone) I'm sorry I've been out of the game for so long. My website is currently down (presumably due to inactivity), but I'll be restoring it at some point. I haven't worked on this in ages, but I have every intent of finishing my work and releasing both a retranslation, and a normal "US" version with SRAM and all of my bugfixes (which includes anything that needed fixing as mentioned in this topic -- all of those bugs have been addressed since). I'm sorry for the wait.

frsj8112

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
Re: Faxanadu - Assembly
« Reply #12 on: April 04, 2015, 09:52:49 am »
Awesome umaggot!!

I'd really love to see SRAM functionality in the US version, have you hacked that ROM too?  :angel:

90s Retro Gamer

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Re: Faxanadu - Assembly
« Reply #13 on: April 04, 2015, 11:57:06 am »
Allow me to preface this by stating that I'm relatively new to assembly, but I've had much success so far. I'm a little embarrassed to be posting this script, as sloppy and inefficient as it is, but I feel at a loss here -- for something that is seemingly very simple. I've been wondering about SubRoutines and JuMPing, and how they may be affecting the code overall. I've rerouted the script from the "use item" segment to an unused area (to add new/unused items) and here's what I have:

LDY $03C1 = #$15 ;Loads the item hex
AND #$11 ;Checks if the item hex is 11 (Is the item a Brown Potion?)
BNE $FCF9 ;If it isn't 11, it branches to the original item use script (Which has been moved)
BRK ;Giving myself free space.
BRK ;Twice. I don't remember why I did this.
JSR $FCED ;Jump to SubRoutine -- Brown Potion used text.
JSR $C8DC ;Removes item picture.
JSR $C4BF ;Removes item.
JMP $C506 ;MP recovery.
RTS ;ReTurn from Subroutine -- back to the original code.


Using any item from Wing Boots, to the Brown Potion is fine -- but items without a script (or with new scripts) beyond the value $11, proceed to use the Brown Potion script. I've confirmed this by corrupting the area where the new scripts point to and pointing the Brown Potion script to that, instead of the original item use script. It refuses to read the new data at all, and simply proceeds beyond the BNE line. This also confirms that the original item use script as I've moved it, isn't the problem -- it's definitely the script that I've posted here.

If you need additional information, feel free to ask. I look forward to and will appreciate any and all assistance with the matter.

I hope that this doesn't belong in "Script Help and Language Discussion Rules", I hope that you'll forgive me if I've posted this in the wrong area. Both boards seem to be "the right board", but as far as I can tell, the other one is mostly for translation help?

Umaggot, see if you can find the line of code with the Pendant bug. The Pendant item is supposed to increase your strength but instead it decreases it.

Someone made a hack fixing this issue.
http://www.romhacking.net/hacks/753/

You can disassemble the patched ROM and compare your assembly with this one.

umaggot

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: Faxanadu - Assembly
« Reply #14 on: April 04, 2015, 07:09:53 pm »
Quote
I'd really love to see SRAM functionality in the US version, have you hacked that ROM too?

I could probably make a US patch by using the US version as a base when creating a patch from the JP version. There would be a bit of the original code copied over, as well.

Quote
Umaggot, see if you can find the line of code with the Pendant bug. The Pendant item is supposed to increase your strength but instead it decreases it.

Someone made a hack fixing this issue.

That someone was I, and it has been already fixed for the Retranslation and general bugfix patches. :) In addition, there were a few armor and shield bugs (items being replaced because the game was checking for amount of shields instead of armor, AND vice-versa! ...also swords!) that I've ironed out.
« Last Edit: April 04, 2015, 07:57:04 pm by umaggot »

frsj8112

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
Re: Faxanadu - Assembly
« Reply #15 on: April 06, 2015, 02:36:48 am »
OK I've made "some" progress with the US rom.

I've implemented umaggots LOAD Routine in the US rom approximatly where the "Mantra is in the wrong" text is located.
Then I managed to find a JSR which is activated when A or B is pressed down.
I then JSR:ed to umaggot's LOAD-routine and then the data from my copied .sav-file is transfered to $0390 etc. So that does work :-)

But then the game crashes and won't boot up to the game.
umaggots check for if the .sav-file is empty and if so, jump back to the title screen does in fact work.

« Last Edit: April 06, 2015, 04:59:25 am by frsj8112 »

umaggot

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: Faxanadu - Assembly
« Reply #16 on: April 06, 2015, 07:29:56 am »
It's checking for 4 bytes, identified as name data. The US version doesn't allow you to create name data, so it fails the SRAM check.

// Except... you copied the .sav from the JP version? ... I have no idea.
« Last Edit: April 06, 2015, 07:36:09 am by umaggot »

frsj8112

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
Re: Faxanadu - Assembly
« Reply #17 on: April 06, 2015, 07:31:01 am »
OK, what can be done to go around that? :-)

umaggot

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: Faxanadu - Assembly
« Reply #18 on: April 06, 2015, 07:44:24 am »
I believe the check is in the first 4 bytes of SRAM. Look for a line scanning the area, and disable the branch. It's looking for 00 bytes, so we're possibly looking for BEQ. Change the BEQ:XX bytes to NOP.

frsj8112

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
Re: Faxanadu - Assembly
« Reply #19 on: April 06, 2015, 08:17:27 am »
Yes I used the sav-file that was generated by saving-in-game with your hack.

Here's the rom with your hack implemented and with an empty .sav-file

https://youtu.be/3YnPN85az5Q

And here it is with a non-empty .sav (generated from the japanese version)

https://youtu.be/2ZbM82CKCH8