Phantasy Star II Improvement v4.4 | ReConstruct: Phantasy Star IV v1.2

[FlamePurge]

Thank you for the info, tryphon!

Minor update, nothing fancy, but I found out there are two strings for RGHT and LEFT in the ROM, so I decided to proper-case the body part labels. I put a dash between the label and the name of the equipment, though, so you won't worry about having to see something like "Head Luna Gear." Instead, it'll be "Head-Luna Gear."

Here y'are.

[FlamePurge]

Phantasy Star II has received an update!

- Rolf and Kain can now wear the Laconia Helm, instead of Rudo and Hugh.
- Hugh can now wear the Crystal Chestplate and the Laconia Chestplate.
- Nei can now wear the Snow Crown, the Laconia Dagger, the Fire Staff, the Truth Sleeves, the Green Sleeves, the Titanium Chestplate, the Ceramic Chestplate, the Crystal Chestplate, the Laconia Chestplate, and the Shune Boots.

[lory1990]

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 

[tryphon]

Regarding too long texts :

I faced this problem when working on a French retranslation of the game (French is more verbose than English, and the English script is oversimplified).

IIRC, texts can't exceed 256 bytes and long texts are handled by writing sequences (up to 4 I think) of dialogues ids (words) from 0xFFCD00, so that 0xFFCD00 refers to the first part of dialog, 0xFFCD02 the next part, and so on.

All of that is hardcoded, that means that you'll see in the program code things like :

Code Select Expand

move.w #$0142, (something_that_refers_to_0xFFCD00)
for a short dialog, and

Code Select Expand

move.l #$01420143, (something_that_refers_to_0xFFCD00)
for a long one (and even two move.l for very long dialogs).

It has for consequence that replacing a short dialog by a long one cause means hacking a little the code itself, which is painful.

So I came with the idea to add a control sequence that allow to specify the next dialogue_id inside the current dialog (I used 0xD0, I'm pretty sure it's unused in the game). So a long dialog would be, in the code :

Code Select Expand

move.w #$0142, (something_that_refers_to_0xFFCD00) # just like a short dialog
And in the data (text) of dialog #$0142 :

Code Select Expand

; dialog #$0142
It's a long, long, very long, [0xD0 0x0143]
; dialog #$0143
such a long dialog...
It could help to fix the 3rd issue.

I plan to write a inserter script that computes itself how to break dialogs, handles the ids and update the dialog_id table (and relocate dialogs at the end of the ROM to avoid deleting other data)

I've started a page on the Datacrystal wiki : http://datacrystal.romhacking.net/wiki/Phantasy_Star_II:Notes
It's still a WIP (I've found much more things than what I wrote) and I'll update it sooner or later, but feel free to contribute.

[lory1990]

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.

[tryphon]

It's a pretty straightforward hack. The routine that reads dialogs loads a character in d0 (at 0x11158), then compares d0 to all control codes known (from 0xBB = 'name of character' to 0xC4 = 'I don't remember'), and if not put the char in the display buffer (at 0x11268).

So I derived the program at this position (0x11268) and included a new test againt my handmade control code 0xD0, and perform the right thing todo (simply put the next word at position 0xFFCD00) :

Here the relevant parts of the program (I tested other hacks) :

The dervation :

Code Select Expand

00011268                            39          ORG     $11268
00011268  4EF9 000C0030             40          jmp     shunt_5
0001126E                            41  return_5:

The control code :

Code Select Expand

000C0030                            70  ;; $D0 tag in text : set next dialog
000C0030                            71  ;; usage D0 XX YY
000C0030                            72 
000C0030                            73  shunt_5:
000C0030  0C00 00D0                 74          cmpi.b  #$D0, d0
000C0034  6600 0014                 75          bne     sh5_suite
000C0038  1019                      76          move.b  (a1)+, d0 ; two byte read rather than a word read because data is not required to be aligned
000C003A  11C0 CD00                 77          move.b  d0, (dialog_id) ; dialog_id = $FFFFCD00
000C003E  1019                      78          move.b  (a1)+, d0
000C0040  11C0 CD01                 79          move.b  d0, (dialog_id + 1)
000C0044  4EF9 00011158             80          jmp     $11158
000C004A                            81  sh5_suite:
000C004A  14C0                      82          move.b  d0, (a2)+
000C004C  31FC 0001 CD10            83          move.w  #1, (window_state_flags).w
000C0052  4E75                      84          rts

[FlamePurge]

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

[tryphon]

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.

Could you please provide the address of the move.l you added ?

[lory1990]

Could you please provide the address of the move.l you added ?

At address $CF68 there's this line:

Code Select Expand

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 Expand

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 Expand


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.

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.

[tryphon]

@ Vivify93 : I can provide an ips to apply to a clean ROM, then you can apply your patches. The checksum would have to be fixed though. Are you okay ?

[FlamePurge]

@ Vivify93 : I can provide an ips to apply to a clean ROM, then you can apply your patches. The checksum would have to be fixed though. Are you okay ?

That'd be great, but would everything be alright? Like, I apply the Lutz fix to the ROM, then apply the Improvement, fix the checksum, and it'd be OK. I wouldn't have to fix the following again?

- LAC DAGGER's stats
- LACONIAMET's distribution
- Hugh being able to cast GIRES out of battle
- Uzo Island text
- Climatrol text
- Paseo old man's text

And all the changes I made will be OK too?

- Altered linebreaks and "push button" prompts in dialogue
- Proper casing, spelling changes, grammar issue fixes to various text
- Nei's equipment repertoire additions
- Enemy name expansions
- Lowercase letters on the naming menu (With lory1990's fixes)

[tryphon]

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.

Actually it was exactly what I proposed to do

That'd be great, but would everything be alright? Like, I apply the Lutz fix to the ROM, then apply the Improvement, fix the checksum, and it'd be OK. I wouldn't have to fix the following again?

- LAC DAGGER's stats
- LACONIAMET's distribution
- Hugh being able to cast GIRES out of battle
- Uzo Island text
- Climatrol text
- Paseo old man's text

And all the changes I made will be OK too?

- Altered linebreaks and "push button" prompts in dialogue
- Proper casing, spelling changes, grammar issue fixes to various text
- Nei's equipment repertoire additions
- Enemy name expansions
- Lowercase letters on the naming menu (With lory1990's fixes)

Provided you didn't enlarge the ROM, it's no problem. If you enalrged it, the easiest is to make my (our, since it's the same as lory1990's) patch directly from your modified ROM.

[FlamePurge]

I didn't change the ROM's size, nope. It should be all alright, then. Oh, will it work with the x4 EXP and MST patch?

[lory1990]

It will work because the fix doesn't overwrite the data changes for the x4 EXP and MST patch.

tryphon, I have the ips with the fix ready. Can I provide the link with the file? I'm asking because you were the first one who wanted to send the ips to vivify93, so if
you have it, go ahead. But if you still didn't get around to creating it, I will post the link with the ips
Also for your information I found a lot of free space in the middle of the ROM. It's just bytes with 00s, there are like 1000+ bytes free. I decided to apply the change
there rather than doing it at the end. It feels much cleaner this way, at least to me

[tryphon]

In fact, it's not cleaner nor safer. Trust me, I did it

Sometimes, lots of 00 are indeed data (think of a table, whose some entries are blank).

Enlarging the ROM is much safer (especially when the ROM is not really big, as it's the case here).

In this precise situation, I have no idea if PS2 blank space is actually blank.

Regarding your patch, please proceed, I didn't make mine yet It'd b a good idea to document this bug too.

[lory1990]

Thanks tryphon 

I moved the fix towards the end, though. There was no need to expand the ROM. There's a section of ROM padding and I'm totally sure there's no way other parts
of code can get that data.

vivify93, here's the link for the patch:

https://www.dropbox.com/s/45w6b3mcjkfrpgi/music_freeze_fix.ips

Apply this to any original UE ROM. There shouldn't be any problems with other patches so go ahead. Test and see how it goes.

[FlamePurge]

Thanks so much, guys! I'll add you to the project's credits page. With this, Phantasy Star II Improvement is officially finished!

Edit - Here you all are. Phantasy Star II Improvement, v1.0. I added tryphon to the hacking credits, too, but he was removed for some reason...

[Lariria]

Thanks so much, guys! I'll add you to the project's credits page. With this, Phantasy Star II Improvement is officially finished!

Edit - Here you all are. Phantasy Star II Improvement, v1.0. I added tryphon to the hacking credits, too, but he was removed for some reason...

Resubmit it. I approved that myself and I never saw tryphon's name.

[lory1990]

While fiddling with this new version, I found a minor glitch in the dialogue window when talking to Ustvestia:



There's a blue portion coming out of the window and I'll explain why it happens: at location $1B156 a new line starts (there's a C1 before that). Only 24 characters
can fit in one line and the following characters will of course go out of the window. At address $1B16E and $1B16F there two 00 which represent the space
character but technically they are just blue tiles. So you should immediately put the terminator C5 after the period and then pad with 00 what's left. In the end the fix is as follows:

$1B16E = C5
$1B16F = 00
$1B170 = 00

So you can resubmit the file with this glitch out of the way as well

[FlamePurge]

Resubmit it. I approved that myself and I never saw tryphon's name.

I will, then. Maybe I forgot to enter it? Whoops. Thanks, I.S.T.!

While fiddling with this new version, I found a minor glitch in the dialogue window when talking to Ustvestia:



There's a blue portion coming out of the window and I'll explain why it happens: at location $1B156 a new line starts (there's a C1 before that). Only 24 characters
can fit in one line and the following characters will of course go out of the window. At address $1B16E and $1B16F there two 00 which represent the space
character but technically they are just blue tiles. So you should immediately put the terminator C5 after the period and then pad with 00 what's left. In the end the fix is as follows:

$1B16E = C5
$1B16F = 00
$1B170 = 00

So you can resubmit the file with this glitch out of the way as well

Yikes, thanks, lory1990. I'll fix that right away.