Phantasy Star Disassemblies

Discuss anything related to the Phantasy Star series

Re: Phantasy Star Disassemblies

Postby dee_ehn » Fri Jan 23, 2015 10:52 am

Thanks. Figures it was a multiplier I was missing.

I've dabbled in windows a bit already, having expanded a few static entries. I had less success when I messed with the window for character stats.

This is a lot more organized than what I'm used to, but my lack of familiarity with the assembly language makes it a bit more difficult for other reasons.

I'm hoping to, at least for a start, overhaul menus to be more pleasant to look at. At a later point I"d like to get a variable width font going, which I think can be done given the amount of unused VRAM I seem to notice. My experience with fonts though is minimal, and I'd have to hijack the game's already nightmarish compressed font routine.
dee_ehn
Pinchant
Pinchant
 
Posts: 7
Joined: Thu Jan 22, 2015 7:48 pm

Re: Phantasy Star Disassemblies

Postby lorenzo » Fri Jan 23, 2015 6:01 pm

The character stats windows are dynamic, so I hope that with my explanation you can change the size of those windows correctly as well.

A variable width font is a must if you want full names for every item, technique, etc. Although it's hard to implement it, it's much better than moving and resizing the windows which can be frustrating and look ugly.
lorenzo
Blastoid
Blastoid
 
Posts: 92
Joined: Thu Dec 25, 2014 12:57 am
Location: Italy

Re: Phantasy Star Disassemblies

Postby dee_ehn » Sat Jan 24, 2015 2:31 pm

The only thing holding me back from looking at cleaning up basic dialogue at this point is the name entry screen. I've got the mapping working (mostly, pressing Right doesn't work perfectly when done on the bottom row), but the actual positioning of the blinking cursor is off. It'll blink on the first row, then the third row, then the fourth, then the sixth, then it goes off the window until it loops. The positioning code still assumes the old window dimensions and contents, and I can't figure out what affects that.
dee_ehn
Pinchant
Pinchant
 
Posts: 7
Joined: Thu Jan 22, 2015 7:48 pm

Re: Phantasy Star Disassemblies

Postby lorenzo » Sat Jan 24, 2015 7:59 pm

Take a look at the piece of code which starts from label Obj_InputWindowBlinkCursor until Obj_NameDestinationTile... The functionality you're talking about is implemented here. The index for the cursor is saved at offset $32 for this particular object, so it's $32(a0) in the code. In the main section of this object it moves the index at this address to register d1, so keep track of this. You should see some comments I made regarding joypad buttons... The processor will perform additions or subtractions depending on which button was pressed, and these operations affect the d1 register. If it helps, try to experiment with the original data before implementing yours.
lorenzo
Blastoid
Blastoid
 
Posts: 92
Joined: Thu Dec 25, 2014 12:57 am
Location: Italy

Re: Phantasy Star Disassemblies

Postby dee_ehn » Tue Jan 27, 2015 8:33 pm

Got everything on the naming screen except the bottom row working. I may have to just expand the window down another row and move the text, as it doesn't want to cooperate. It functions fine though, visuals aside.

I'm having a huge issue now. I keep having resets on regen and exodus when I open half of the menus in the game. Resets (doesn't crash) on the techs, status, equip, and order windows. I can't actually figure out what is going on, and it only seems to happen in the accurate emulators. Fusion runs the game fine.

Note that I have edited the techs window, status window , and the stats window on the equip menu, but not the order menu. I tried setting a RAM address to trigger a break point via write, but I'm seeing little progress. I'm hoping the game isn't overflowing VRAM or something.
dee_ehn
Pinchant
Pinchant
 
Posts: 7
Joined: Thu Jan 22, 2015 7:48 pm

Re: Phantasy Star Disassemblies

Postby lorenzo » Wed Jan 28, 2015 11:13 am

I don't think expanding the window will do you any good since the cursor starts from a fixed position. Remember that every element has separate functions and are linked together at some point. Windows graphics are one thing, the functionality for selecting characters is another, and so is the blinking cursor.

Onto the resets... Hmm... That's very hard to say. I'll list some possible causes, but at a certain point, if you still have that problem, you need to try expanding one window only keeping the other data as the original, so that you can narrow down your troubleshooting places.

First of all, there's something I didn't leave a comment on in the "ps2.constants.asm" file. There's a constant defined for the size of the dynamic windows:

dyn_windows_size = (DynamicWindowsEnd-DynamicWindowsStart)+$B2

That's the size of all the bytes which are stored in RAM. Do you see the +$B2? It's allocating more space. That's not necessary... Replace it with 2. You need two bytes more than the actual number of bytes for the windows otherwise the last dynamic window (Ustvestia song tracks window, fyi) will display 2 wrong tiles at the bottom right corner of that window. I mentioned so that you can have more spaces in RAM and that +$B2 will not overwrite other data in RAM. Having said that I really doubt that what you have is a RAM overflow because there's relatively lots of free space for the window buffer (window_art_buffer)... that is unless you expanded your windows by a lot.

Is there an alignment problem? Like, did you get a warning from the assembler that your data may not be aligned? The m68k has problems dealing with odd addresses and that can result in crashes. On a side note, you said you have resets and not crashes... But I'm afraid that what you experience are crashes. Crashing happens when there is an illegal instruction, data or something else, and code is directed to one of the routines defined in the vector table at the start of the ROM. You'll see that most of them are ErrorTrap thus, whatever illegal instructions you may have, the processor will jump to the ErrorTrap routine. It simply does nothing for a few cycles and then reinitializes the data (reset). So in a sense it's a reset, but it's due to a bad instruction or data somewhere in the hardware.

When you open the ROM with your chances in Kega Fusion, can you see everything correctly, meaning everything is like you wanted them to be? This may sound silly, but did you make sure you changed the instructions that process these windows?

Speaking of emulators, Kega Fusion is really bad in terms of accuracy, sometimes it ignores the problem that data is on odd addresses and the game will work just fine. The best emulator to test with is Regen; I was told by an experienced Mega Drive hacker that it is about 95% accurate regarding real hardware emulation, which is very good. So use that all the time when making changes and testing.

If you want, can you also show some screenshots with the windows you changed? You're not forced to post them here, you can PM me as well. Also if it can help, send me the relevant code snippets you edited, so I can take a look as well.
lorenzo
Blastoid
Blastoid
 
Posts: 92
Joined: Thu Dec 25, 2014 12:57 am
Location: Italy

Re: Phantasy Star Disassemblies

Postby Tryphon » Thu Jan 29, 2015 7:55 am

I bet on an alignment error too.

To my knowledge, Exodus is the best emulator in term of accuracy, but you need a monster to run it (I can't have more than 6fps on my machine, which is a weak one, I have to admit).

Regen is a good compromise bettween speed and accuracy but :
* there are some bugs
* it's closed source
* and I'm not sure it's maintained by its author

The first two points are true for Exodus though.

I have to give another try to various hacks of Gens.
Tryphon
Scorpius
Scorpius
 
Posts: 357
Joined: Wed Mar 28, 2012 11:29 pm

Re: Phantasy Star Disassemblies

Postby dee_ehn » Thu Jan 29, 2015 8:12 am

I can actually run exodus fine, but I can't just launch a game straight into it. I have to keep it open, which pretty much consumes an entire screen. Easier to just attach rom execution to regen.

I seem to have traced down at least some of the problem. Expansion of the status window at all, even with no other factors, causes a crash. I have no idea why.
dee_ehn
Pinchant
Pinchant
 
Posts: 7
Joined: Thu Jan 22, 2015 7:48 pm

Re: Phantasy Star Disassemblies

Postby lorenzo » Thu Jan 29, 2015 11:42 am

The main issue I have with Regen is that it can't load SRAM most of the time. I mean it says that it saves after powering it off and I can see that it places the file in the SRAM folder, but it doesn't work. I need to find out what the cause is.

Back to the windows... I probably screwed up a little with the dynamic windows labelling. I found that when the start of the dynamic windows is loaded, I made it start from the location of the first window, not the start of the whole section. Now, it's not that, because some windows can be expaned, and some cannot... Maybe there's some labelling that's wrong, could be an alignment problem, or it's the routine that deals with the VDP and drawing the character. It could be a bug that's in the routine and it's noticeable by tweaking the windows.

Having said that, I'll have to interrupt the disassembly of the PSIII and focus on the windows. Well, at least I can start identifying and labelling all the windows, fix the labelling of the dynamic ones and take a look at the routine for drawing them. I'm sorry dee_ehn... you were doing a great job. After I'm done cleaning up and fixing this, I'll upload an update on RHDN. Will let you know when it's up.

EDIT: I took a quick look, and it's only at this location LoadDynWindowsInRam that I load the first window instead of the start of the whole window. Replace the line

lea (loc_15650).l, a1

with lea (DynamicWindowsStart).l, a1

EDIT2: OK, I debugged and figured out where the problem lies. Some dynamic windows must start at an odd location because when they are processed in the code with the move.l instructions at some point the RAM address that contains the art tiles is even! So it was an alignment problem; I won't have to update my disassembly for now.

First of all, here's the part it crashed on me:

Code: Select all
loc_100A6:
   move.w   #0, (window_index_saved).w
   lea   $FFFFC038.w, a3
   move.w   (character_index).w, d1
   lsl.w   #6, d1
   adda.w   d1, a3
   lea   (window_art_buffer+loc_15B95-DynamicWindowsStart+$10).w, a1
   move.b   (a3)+, (a1)+
   move.b   (a3)+, (a1)+
   move.b   (a3)+, (a1)+
   move.b   (a3)+, (a1)+
   addq.w   #6, a1
   move.b   (a3)+, (a1)+
   move.b   (a3)+, (a1)+
   move.b   (a3)+, (a1)+
   move.b   (a3)+, (a1)+
   suba.w   #$36, a3
   suba.w   #8, a1
   move.w   (a3)+, d0
   bsr.w   loc_11364
   lea   (loc_11456).l, a2
   move.w   (character_index).w, d1
   lsl.w   #3, d1
   adda.w   d1, a2
   adda.w   #$11, a1
   move.l   (a2)+, (a1)+     ; <-- by changing a window a1 is odd, so this causes the crash
   move.l   (a2)+, (a1)+


As you can see in the comment, that a1 is what caused the crash. It's even in the original code when it gets there, but if you change the size of the windows it might end up being odd <_<. Stupid thing.

For now the best solution would be to write a macro named "odd" so that it aligns at each odd address. It should be placed before a dynamic window which starts at an odd address. Fortunately I didn't name any label for the dynamic windows, so it should be easy. Look at the "ps2.macrosetup.asm" and write a macro there... Just look at the one named "even", it's the opposite logic. Even knowing this, it won't be so easy since you need to count the number of bytes for each window you wanna change and then make sure they will be even when processing the instructions. Hope that was clear.

Another thing is that instead of move.l, you can split into mulitple move.b and write one byte at a time. It should work even if the destination address is odd, but I'm not 100% sure.

Maybe I can release an update with the odd macro so that people will not run into this problem, well not so easily, but still better than nothing.
lorenzo
Blastoid
Blastoid
 
Posts: 92
Joined: Thu Dec 25, 2014 12:57 am
Location: Italy

Re: Phantasy Star Disassemblies

Postby lorenzo » Thu Jan 29, 2015 7:56 pm

OK, I don't know what I was thinking, but other parts of code use multiple move.b instructions to move data in memory to prevent writes at odd addresses. You can even see this above the line that causes the crash in the code I posted earlier. So, yeah, those move.l should be split into move.b instructions. The same thing should be checked for the other pieces of code that process the bytes for the dynamic windows. I probably should do this myself and put comments where these buggy instructions are located explaining that they should be written as move.b, so that people can see it. So there will be an update. I will try and see if I can label some of the windows because most of them are still in raw addresses.
lorenzo
Blastoid
Blastoid
 
Posts: 92
Joined: Thu Dec 25, 2014 12:57 am
Location: Italy

Re: Phantasy Star Disassemblies

Postby dee_ehn » Fri Jan 30, 2015 12:34 am

Also noticing the game crashing if the display window for meseta value is changed. Might be a similar issue.

Edit: expanded it an extra tile and it works. Odd.
dee_ehn
Pinchant
Pinchant
 
Posts: 7
Joined: Thu Jan 22, 2015 7:48 pm

Re: Phantasy Star Disassemblies

Postby lorenzo » Fri Jan 30, 2015 10:01 am

Yeah, because the window for the meseta is located above the window that caused the crash, and the same goes for other windows which may have the same problem. Originally some windows start from an odd address and in this situation everything works. However when you change size of a window, all subsequent bytes are shifted either up or down, so the addresses may change parity. Don't put in any extra bytes just to align them "correctly"... The code that references them is not safe. As I said, you need to turn any word or long-word sized instructions into byte ones.

The tiles for the dynamic windows are loaded in RAM and are later referenced as such:

lea (window_art_buffer+loc_XXXXX-DynamicWindowsStart).w, a1

This is generic of course. After the tiles are loaded in any address register, you need to trace this register and check how access (reads and writes) is done: when you see, for instance,

move.l (a2)+, (a1)+

replace instructions such as this with byte sized instructions, so it becomes

move.b (a2)+, (a1)+
move.b (a2)+, (a1)+
move.b (a2)+, (a1)+
move.b (a2)+, (a1)+

or to be more concise you can use

rept 4
move.b (a2)+, (a1)+
endm
lorenzo
Blastoid
Blastoid
 
Posts: 92
Joined: Thu Dec 25, 2014 12:57 am
Location: Italy

Re: Phantasy Star Disassemblies

Postby lorenzo » Mon Feb 02, 2015 2:06 pm

Hi. I edited the first post which includes a description of the features and links of the disassemblies, links to tutorials and resources to assembly programming and consoles related to the PS series.

Besides I think this thread should be about general questions on the disassemblies and programming, not game-specific otherwise it will be harder to look for references and answers that have already been found or discussed. So I'll be opening a thread for PSII since it's the only game whose disassembly is publicly available at the moment.

One last thing, I finally updated my PSII disassembly which now includes ID's and constants for the windows. It also has comments near the instructions that can cause the crash problem mentioned in previous posts. I did something useless for the sound driver in my first release: I defined a constant named SoundDriverSize which is used to re-align the code correctly after the whole Z80 code. I realized that it could've been easily done by putting the labels at the start and at the end of the Z80 code...That is the size. Yeah, it was a very simple thing to do, but I was influenced by the Sonic the Hedgehog disassemblies which had to do something like this since the sound driver is compressed, but it was not necessary in this case. It's my fault of course, I'm not blaming them =)

Having said that, I uploaded the disassembly on RHDN, but it must still be approved, so wait a day or two if you want the update. If you don't care about the sound driver or windows, the version that you have right now is fine. I didn't change anything else.

That's all for now. Have a nice day!
lorenzo
Blastoid
Blastoid
 
Posts: 92
Joined: Thu Dec 25, 2014 12:57 am
Location: Italy

Re: Phantasy Star Disassemblies

Postby lorenzo » Sat Mar 07, 2015 11:19 pm

Hello, everyone! Great news for PSIII fans: the disassembly for this game has been uploaded and approved on RHDN. Link is in the OP.

I've only started working on it, so don't expect explanations and meaningfully named labels for most parts in the code other than what's already been discovered. In particular I made use of the Aridia program by Hugues Johnson, got information that was there and included it in the disasm.

I'll briefly talk about some features and things you may be interested in changing.

The game script is organized in a way that you can have different dialogues for the same character depending on the events that happen in the game. The engine makes this very easy and doesn't require any knowledge of assembly. Of course, knowing how to program the basics is always good, but if you don't want to bother learning asm, this is not bad at all in my opinion. I wrote some explanations at the start of the main game script section, so you get a general idea.

I read some threads from people who wanted to expand the level tables so that you can reach lv 99: it is now possible to do that without, again, any knowledge of asm. Besides you can change how often technique power grows, stats and initial equipment for characters, and expanding item and enemy names. I wrote comments explaining some of this stuff.

I found out a few bugs and how to fix them: I explain how to go about them... Search for the word bug or glitch and you should see them. For now I put everything in one document (the asm file), but most likely in future releases I will write a separate file explaining information such as bugs, events, etc.

Another thing that may interest music hackers: The sound driver is completely disassembled and commented to some extent, so you can have a basic idea on what's going on. It's all in Z80 assembly and can be expanded or reduced at will just like the other m68k code. While I converted every raw data to Z80 by myself, all the information was provided by ValleyBell, a user on Sonic Retro and has his own website. He researched and made available many sound drivers for Mega Drive/Sega Genesis games. He really did a great job! I included some of his text files for this game in the "sound" folder so you have a better understanding of it hopefully.

I will continue looking into this disassembly and try to figure out as much as I can. Needless to say, feel free to ask questions and/or post any problems you may run into.

Have fun!
Last edited by lorenzo on Sun Mar 08, 2015 11:55 am, edited 1 time in total.
lorenzo
Blastoid
Blastoid
 
Posts: 92
Joined: Thu Dec 25, 2014 12:57 am
Location: Italy

Re: Phantasy Star Disassemblies

Postby Tryphon » Sat Mar 07, 2015 11:45 pm

Great ! It'll be really useful :)
Tryphon
Scorpius
Scorpius
 
Posts: 357
Joined: Wed Mar 28, 2012 11:29 pm

PreviousNext

Return to Phantasy Star

Who is online

Users browsing this forum: No registered users and 2 guests

cron