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.