News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

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 - lory1990

Pages: 1 2 [3]
41
Quote
Could you please provide the address of the move.l you added ?

At address $CF68 there's this line:

Code: [Select]
move.w #$1690, ($FFFFCD00).w
This is called when you have all the Nei items and talk to Lutz. I simply replaced the move.w with move.l and added the other text pointer to process:

Code: [Select]
move.l #$16901693, ($FFFFCD00).w
The value for the byte before pointer 1693 must be C4 to make the routine return so that it can process the other text. Since there are 5 pointers for these lines,
we can process them one by one with multiple move instructions:

Code: [Select]
move.l #$16901691, ($FFFFCD00).w
move.l #$16921693, ($FFFFCD04).w
move.w #$1694, ($FFFFCD08).w                ; this pointer is also used for the old man in Paseo for some reason...

Again inserting C4 at the end of every of these pointers is necessary for it work. I prefer the first solution since it's only a line of code.

Quote
Thanks for the fixes, lory1990! I think fixing the music bug is beyond my capabilities, though, unfortunately...

You're welcome  :)
 
Actually for the music bug I found another solution, although this requires adding code at the of the ROM. It's up to you. If you're interested I can walk you
through the lines you need to edit and add.
Basically at the part where Lutz says those lines we jump to the end of the ROM and we add our fix there and we return from there. This way data stays aligned and the game won't crash. This is much shorter than having to change the lines. This is also based on tryphon's idea when he wanted to implement the control sequence and break the dialogue and then add the code at the end.

I tested it and it works and it doesn't take long.

42
Yeah, my fix was exactly using a move.l instruction so it can process the sequence of bytes separately to avoid overwriting the sound RAM.

Can you please elaborate about the control sequence, the one by adding D0 when you want to break the dialogue? It sounds interesting and either you or I can help
fix this bug without losing the original text.

I'll certainly consider contributing to the wiki page. I prefer disassembling the code better to have a much clearer idea of things and I'm in the middle of figuring out
all the objects, map indexes and other stuff, but I'll get to contributing to it at some point.

43
Hello everyone. I got a reply from vivify93 saying that I could post here what I found out about the bugs and their respective fixes.

The only "hard" bug to fix is the music freeze in the Esper Mansion. I will start posting the simple ones and explain that bug later in this post.

1) Accessing the lowercase x and y:

  This is very simple. You just need to fix a couple of numbers and I'll also explain what happens in the original code.

  In your ROM go to address $16B7. The value for that is 31. Change it to 33.
 
  Then go to address $16BD and change the value 0F to 11.

  Done. Now the explanation: the value 31 (or 49 in decimal) in that location is used in a compare instruction. 31 is the position of the uppercase Z in the original and
  in your hack is the lowercase w. What the instruction says is that once you reach that position and the next value that is compared to 31 is greater than 31, it
  subtracts 15 to the result (0F in hex). So when the cursor is on the lowercase w and you press right, it subtracts 15 and it goes the lowercase i. We changed the
  first value to 33 (51) so now it compares the next value to 33 and when they are equal it subtracts 11 (or 17) and it goes back to lowercase i.

2) Wrong message pointer for old man in Paseo

  Go to location $E6BB. You should see the value 94. Now I found an unused piece of text in the section where pointers for Central Tower are referenced. I think
  that's the line this old man is supposed to say but it's only an assumption. Moving that text to the location we want would be tricky using only a hex editor.
  So what we're going to do is give the old man the same lines as the other old men in Motavia. The old men generally use the following text pointers:

  - 9D = Biohazards are gone, but the heavy atmosphere of this planet somehow stays the same...
  - 9E = I've seen your face somewhere...

  So replace 94 with either 9D or 9E and it should be fine.

  For your information text pointers used when you speak to people in towns or dungeons start at location $E6B0

3) Music Freeze in the Esper mansion

  Now it gets kind of complicated. First the explanation of why the bug occurs: the data used for loading and displaying text are in location $FFCD40 in the RAM.
  When you talk to Lutz in the Esper Mansion after you get all the Nei items, it loads the text at location $2019E. The bug happens because the sequence of bytes
  used for text is too long. At a certain point it overwrites the values from $FFD000 on: this part of RAM is used for the sound. That's why the music no longer works,
  it's given the wrong values. It may also overwrite sections of RAM beyond the sound part and that could also be the reason why the game freezes when you get
  to Noah if you don't reload the game.

  Okay I have a couple of solutions even though one is probably not even worth it but this is what I came up with anyway:

  - Simply cut the text. The whole piece of text that is being loaded starts from $2019E ends at $2057A. Just decide what you want the master to say using less
    bytes. I'll give you in another post the maximum number of bytes you can use without it glitching so that you can plan ahead. If you decide to work on it and I
   somehow forget to provide you with the number, just tell me  :)

  - The other solution requires adding a piece of code. I did this by splitting the whole sequence in two and and loading the two text separately. Unfortunately this
    shifts all the bytes forward and using a hex editor this will result in having all wrong pointers. So a workaround I thought of is that I assemble the ROM with
    this bug fix so that you can keep the whole text, but then you'll have to recreate your hack by changing the values again, keeping in mind that all data after
    inserting the code will be shifted forward.

   I really don't think you'd want to go with the second one considering that you'll have to start from scratch. If I can think up something else I'll let you know.

 I hope this is clear enough. If something doesn't work or other bugs show up, please tell me  :)

Pages: 1 2 [3]