Tales of Phantasia VWF Main Menu Issue?

[justin3009]

I've been wanting to do this for awhile and I actually figured out how to make the options into a VWF, but then comes some fun stuff!

Code Select Expand

$60/F2A0 C2 20       REP #$20                A:0000 X:AD03 Y:5106 P:envMxdizC
$60/F2A2 A2 46 20    LDX #$2046              A:0000 X:AD03 Y:5106 P:envmxdizC - Load X/Y coordinates of text
$60/F2A5 64 00       STZ $00    [$00:0000]   A:0000 X:2046 Y:5106 P:envmxdizC
$60/F2A7 A9 02 00    LDA #$0002              A:0000 X:2046 Y:5106 P:envmxdizC - Load Font Color
$60/F2AA 85 04       STA $04    [$00:0004]   A:0002 X:2046 Y:5106 P:envmxdizC
$60/F2AC A9 3D 75    LDA #$753D              A:0002 X:2046 Y:5106 P:envmxdizC - Load String
$60/F2AF 22 54 BD F0 JSL $F0BD54[$F0:BD54]   A:753D X:2046 Y:5106 P:envmxdizC - Loads bytes for text and VWF routine.

Now this code should set the coordinates to the top of the menu (Which it does), set the font color to white (Which it does) and then load the 'Naming' String.  Now, the STRING is where it's having issues updating.

- Notice it's loading 'Formation', right?  Well altering the 'string' pointer does absolutely nothing on the main menu.  From what I can gather, VRAM isn't updating to do so.  Which throws me off as it doesn't seem like there's any huge noticeable difference between the Main Menu itself and other menus to actually do this.  (I even put the code in similar spots to make sure and am currently trying to see what the difference is when loading the menus).

Why would this occur?  Is it because that there's some sort of initialization error to update the spot needed in VRAM?

The main portion that SHOULD change is E600 in VRAM.

[RedComet]

I would locate the address in VRAM where the tiles for that string and the part of the tilemap for that string is at. Then work backwards from there until you find the offending code. There's a lot of things that can cause bugs like this, so speculation on any of our part would probably be useless.

[justin3009]

E600 is where they appear in VRAM.  All the VWF text in the menu starts in that area (Though I haven't exactly figured out where it picks that up from).

I'll keep trying to work backwards.  VRAM has always been an ass for me with this kind of thing.

Though the best guess I can assume right now is that the main menu has code that is not being run or that there's something being run that's just not letting this work properly.

Edit: GOT IT!  Found a whole section of code specifically for VRAM updating!  It works now

[justin3009]

- Another issue :/

I load up Cless's Menu First.  Shows everything perfectly fine (Ignore some spacing issues on i and l)

I press over to go to Chester's screen and... yeah.  It's getting the length of the item names but it's not visually UPDATING them (Except on Panama Hat and Silver Cloak?  How is that even possible).

Basically it writes over some of the tiles, but others it just.. doesn't?  What the heck would cause that?

Edit: Strange, it seems that only certain VRAM areas are getting written to.  E7C0 gets written to, but E680 isn't.  Etc etc.. Why would this even occur?

[LostTemplar]

My first intuition would be that some of those transfers fall out of vblank because of their size (seeing all those VWF tiles that seems plausible).

[justin3009]

Forgot to mention, not ALL of those are VWF tiles.  Everything on that screen is pseudo-VWF (And other screens) to save time and lag less.  The only REAL VWF on that screen so far is purely the item names and 'Status' in the upper left corner when it's there.

[Nightcrawler]

I agree with Lost Templar. It's likely your transfers are not all fully executing during vblank. You can debug one of the failed transfers. I assume you're using DMA for this. In most debuggers, you can break right before the start of the transfer (before write to $420b) and check your vertical scanline count ('VC:' in Geigers. Not sure offhand if it's the same on other debuggers) and then see what it's at when it finishes on the next instruction (CPU pauses execution during DMA).

The transfer needs to start and finish entirely during vblank. Vblank period is line 225 to 0 (rollover to next frame).

Often times NMI takes a differing amount of time to run each frame. I've been caught by this type of thing a few times where the normal game's NMI code takes much of vblank and there's little time left over for me to do anything extra at the end. Then sometimes my transfer fail while other times they complete in time.

If you find your transfers are not finishing in time, you will need to use some trickery by doing smaller transfers per frame or splitting up your existing transfers across frames. Alternatively you could do a force blank if the transfer takes place between visual screen loads.

You should be noticing a theme here on all these issues. They're simplest to debug by working backwards. You see that VRAM is not getting written sometimes. So, check those transfers to those locations next. Either the transfer is not working (due to not being during vblank), there is a bug in the code, or the source data is not as you expect. It can only be one of those few things! Break it down to simple steps and make it easy for yourself.

[justin3009]

VRAM is where I always get screwy with.  I've never had any real experience with it until Mega Man X2/X3 and that was a HUGE difference than this.  Though, I'm understanding how it works slowly.

From what I can assume it's probably not in vblank, which even then still confuses me.  Why would the next items work while others don't?  They're literally in consecutive order in the same code.  So unless Vblank suddenly just... stops mid writing than that would be it.  (Then again this is NOT on a black screen to load screen.  It's instantaneous so it's more likely vblank issue).

I'll take a look at the VC in a second and see what's up.

Edit: Hm.  I can't really seem to find anything noticeably different.  I'm clearly missing something.

Edit 2: Everything updates on the screen but the weapon and accessories.  That's.. odd.  It seems to be something with the VRAM position.  Cause if I swap out the weapon and body's VRAM locations, weapons will update but the body won't.

Code Select Expand

$C2/EF0C A9 18       LDA #$18                A:0151 X:2000 Y:2556 P:envMxdizc
$C2/EF0E 8F 01 43 00 STA $004301[$00:4301]   A:0118 X:2000 Y:2556 P:envMxdizc
$C2/EF12 A9 01       LDA #$01                A:0118 X:2000 Y:2556 P:envMxdizc
$C2/EF14 8F 00 43 00 STA $004300[$00:4300]   A:0101 X:2000 Y:2556 P:envMxdizc
$C2/EF18 A9 80       LDA #$80                A:0101 X:2000 Y:2556 P:envMxdizc
$C2/EF1A 8F 15 21 00 STA $002115[$00:2115]   A:0180 X:2000 Y:2556 P:eNvMxdizc
$C2/EF1E A9 7E       LDA #$7E                A:0180 X:2000 Y:2556 P:eNvMxdizc
$C2/EF20 8F 04 43 00 STA $004304[$00:4304]   A:017E X:2000 Y:2556 P:envMxdizc
$C2/EF24 C2 20       REP #$20                A:017E X:2000 Y:2556 P:envMxdizc
$C2/EF26 A9 89 7A    LDA #$7A89              A:017E X:2000 Y:2556 P:envmxdizc
$C2/EF29 8F 02 43 00 STA $004302[$00:4302]   A:7A89 X:2000 Y:2556 P:envmxdizc
$C2/EF2D A9 90 73    LDA #$7390              A:7A89 X:2000 Y:2556 P:envmxdizc
$C2/EF30 8F 16 21 00 STA $002116[$00:2116]   A:7390 X:2000 Y:2556 P:envmxdizc
$C2/EF34 A9 80 05    LDA #$0580              A:7390 X:2000 Y:2556 P:envmxdizc
$C2/EF37 8F 05 43 00 STA $004305[$00:4305]   A:0580 X:2000 Y:2556 P:envmxdizc
$C2/EF3B E2 20       SEP #$20                A:0580 X:2000 Y:2556 P:envmxdizc
$C2/EF3D 22 52 D9 C9 JSL $C9D952[$C9:D952]   A:0580 X:2000 Y:2556 P:envMxdizc - It may have something to do with this.  Modifying the 89 7A value causes some interesting issues on the items that update (Though this just may be RAM editing nothing more).

Edit 3: This definitely has something to do with it.  Modifying the tiles at 7E7A89 modifies the weapon data.  It's skipping weapons and accessories for some reason.

Edit 4: Got something!  Changing C2/EF34 A9 80 05 to A9 00 08 effects everything on screen EXCEPT the weapon for updating.  So it's definitely missing SOMETHING.

Edit 5: If I bump everything up in VRAM by 100 bytes, it all updates fine.. but I don't want that.  I NEED to have it effect the entirety from beginning to end.

Edit 6: Got it! Had to look up on an old guide about the storage to :4302.  Noticed that it was exceptionally similar to some other data.  Changed it to A9 69 79 (Which is where the whole DMA storage or reading starts in this game).  Then changed :2116's data to A9 00 73 so it loaded the correct area in VRAM to load things from.  Voila!  Worked like a charm! (Best part is since there's so little VRAM, there's hardly any kind of lag in the menu when switching character screens!)

[Nightcrawler]

Congrats! Make sure you turn off the 'Squelch' option in Geiger's debugger. You're missing a lot of information in your traces that way including the VC (vertical counter) that I was talking about earlier.

Also under special tracing, there is a DMA option. Turn it on right before this transfers executes and step through. When DMA executes, you'll see a great little summary of it. That helps by translating into something meaningful without trying to process all those registers in your head.

I'm sure you're already aware, but in case you aren't, when you talk about VRAM addresses like $E720, that's an effective byte address. However, when setting $2116 for VRAM writes, it will be half of that because VRAM is word addressed in those registers. You'd see $7390 as you do in this transfer.

[justin3009]

I keep forgetting about the cut in half deal!  That would certainly explain a lot then!  And I will definitely have to turn that off.  Especially if I'm missing that much information.

Thank you for help and reminder!