Getting Started on a VWF?

[justin3009]

There is an $11 in $210b and $210C  is $00. If you look at the details on those registers, you'll see there is a nibble for each of the 4 background layers tile bases. That's why BG3 and 4 have a base of $0000 and BG 1 and 2 have $2000.

Ah okay, that makes more sense now then.  Got it!

Yes. That whole paragraph is a fancy way of saying the tilemap will vary in the size it takes in VRAM depending on the tilemap size you use for the background. Toggle the last two bits of $2109 to see the tilemap effects on that layer. The background size will change from 1 to 4 maps to make up the entire layer.

Yep, I was taking a look at that earlier.  It does some really crazy things to the tilemap when it expands on sizes like that.

Okay, I'm starting to understand this bit by bit.

So what I need to do is hijack the routine that basically loads 7E0604 and gets the Tilemap data, correct?  So would I have to drop how it gets the value from VRAM and make it read from ROM instead.  Then transfer that from ROM to RAM to VRAM?
-------------------------------------------
Edit: This is on topic but I had to take a test run

Code Select Expand

$7E/22A2 BD 03 06    LDA $0603,x[$06:0603]   A:000A X:0000 Y:0000 P:envMXdIzc
$7E/22A5 8D 05 43    STA $4305  [$06:4305]   A:0002 X:0000 Y:0000 P:envMXdIzc     ;set transfer size (low byte)
$7E/22A8 9C 06 43    STZ $4306  [$06:4306]   A:0002 X:0000 Y:0000 P:envMXdIzc     ;set transfer size high byte to 0
$7E/22AB E8          INX                     A:0002 X:0000 Y:0000 P:envMXdIzc
$7E/22AC E8          INX                     A:0002 X:0001 Y:0000 P:envMXdIzc
$7E/22AD E8          INX                     A:0002 X:0002 Y:0000 P:envMXdIzc
$7E/22AE E8          INX                     A:0002 X:0003 Y:0000 P:envMXdIzc
$7E/22AF 8E 02 43    STX $4302  [$06:4302]   A:0002 X:0004 Y:0000 P:envMXdIzc    ;X+4 = low byte of source address
$7E/22B2 A9 06       LDA #$06                A:0002 X:0004 Y:0000 P:envMXdIzc          ;high byte of source address = 6
$7E/22B4 8D 03 43    STA $4303  [$06:4303]   A:0006 X:0004 Y:0000 P:envMXdIzc
$7E/22B7 9C 04 43    STZ $4304  [$06:4304]   A:0006 X:0004 Y:0000 P:envMXdIzc  ;bank byte of source = 0 (so read from RAM 00:06XX) [ Makes it read from 7E0604)
$7E/22BA A9 01       LDA #$01                A:0006 X:0004 Y:0000 P:envMXdIzc
$7E/22BC 8D 0B 42    STA $420B  [$06:420B]   A:0001 X:0004 Y:0000 P:envMXdIzc    ;do transfer
$7E/22BF 8A          TXA                     A:0001 X:0004 Y:0000 P:envMXdIzc     ;this is effectively increasing X by the amount of transferred data
$7E/22C0 7D FF 05    ADC $05FF,x[$06:0603]   A:0004 X:0004 Y:0000 P:envMXdIzc
$7E/22C3 B0 FE       BCS $FE    [$22C3]      A:0006 X:0004 Y:0000 P:envMXdIzc
$7E/22C5 AA          TAX                     A:0006 X:0004 Y:0000 P:envMXdIzc
$7E/22C6 E4 A5       CPX $A5    [$00:00A5]   A:0006 X:0006 Y:0000 P:envMXdIzc   ;I'm assuming $A5 is the total amount of data to transfer

I removed this entire routine, rather, hijacked it and did a test run at 409FB0 and copied/pasted Sailor Moon - Another Story's screwed up routine to get the font/vram and junk.  It WORKED.  It actually read the letter from ROM and stored it into VRAM accordingly.  But the issue being is I don't understand HOW it worked nor do I want to use that games as it's just an ugly screwed up mess from hell.

But I now know that the routine that's been quoted is INDEED what needs to be replaced.  So that's a big step!

[Nightcrawler]

So what I need to do is hijack the routine that basically loads 7E0604 and gets the Tilemap data, correct?  So would I have to drop how it gets the value from VRAM and make it read from ROM instead.  Then transfer that from ROM to RAM to VRAM?

What are you going to read from ROM? For a VWF, you're going to create dynamic tiles in RAM (since you no longer will have one letter per tile). You will be copying those tiles to VRAM and then altering the tilemap to now point to those tiles.

[justin3009]

I apologize heavily for having so many troubles with understanding all of this :|

Code Select Expand

$7E/2283 A9 01       LDA #$01                A:0006 X:0031 Y:0000 P:envMXdIzc
$7E/2285 8D 00 43    STA $4300  [$06:4300]   A:0001 X:0031 Y:0000 P:envMXdIzc
$7E/2288 A9 18       LDA #$18                A:0001 X:0031 Y:0000 P:envMXdIzc
$7E/228A 8D 01 43    STA $4301  [$06:4301]   A:0018 X:0031 Y:0000 P:envMXdIzc
$7E/228D 18          CLC                     A:0018 X:0031 Y:0000 P:envMXdIzc
$7E/228E A2 00       LDX #$00                A:0018 X:0031 Y:0000 P:envMXdIzc
$7E/2290 BD 00 06    LDA $0600,x[$06:0600]   A:0018 X:0000 Y:0000 P:envMXdIZc
$7E/2293 8D 15 21    STA $2115  [$06:2115]   A:0080 X:0000 Y:0000 P:eNvMXdIzc
$7E/2296 BD 01 06    LDA $0601,x[$06:0601]   A:0080 X:0000 Y:0000 P:eNvMXdIzc
$7E/2299 8D 16 21    STA $2116  [$06:2116]   A:00EA X:0000 Y:0000 P:eNvMXdIzc
$7E/229C BD 02 06    LDA $0602,x[$06:0602]   A:00EA X:0000 Y:0000 P:eNvMXdIzc
$7E/229F 8D 17 21    STA $2117  [$06:2117]   A:0008 X:0000 Y:0000 P:envMXdIzc
$7E/22A2 BD 03 06    LDA $0603,x[$06:0603]   A:0008 X:0000 Y:0000 P:envMXdIzc
$7E/22A5 8D 05 43    STA $4305  [$06:4305]   A:0002 X:0000 Y:0000 P:envMXdIzc     ;set transfer size (low byte)
$7E/22A8 9C 06 43    STZ $4306  [$06:4306]   A:0002 X:0000 Y:0000 P:envMXdIzc     ;set transfer size high byte to 0
$7E/22AB E8          INX                     A:0002 X:0000 Y:0000 P:envMXdIzc
$7E/22AC E8          INX                     A:0002 X:0001 Y:0000 P:envMXdIzc
$7E/22AD E8          INX                     A:0002 X:0002 Y:0000 P:envMXdIzc
$7E/22AE E8          INX                     A:0002 X:0003 Y:0000 P:envMXdIzc
$7E/22AF 8E 02 43    STX $4302  [$06:4302]   A:0002 X:0004 Y:0000 P:envMXdIzc    ;X+4 = low byte of source address
$7E/22B2 A9 06       LDA #$06                A:0002 X:0004 Y:0000 P:envMXdIzc          ;high byte of source address = 6
$7E/22B4 8D 03 43    STA $4303  [$06:4303]   A:0006 X:0004 Y:0000 P:envMXdIzc
$7E/22B7 9C 04 43    STZ $4304  [$06:4304]   A:0006 X:0004 Y:0000 P:envMXdIzc  ;bank byte of source = 0 (so read from RAM 00:06XX) [ Makes it read from 7E0604 ]
$7E/22BA A9 01       LDA #$01                A:0006 X:0004 Y:0000 P:envMXdIzc
$7E/22BC 8D 0B 42    STA $420B  [$06:420B]   A:0001 X:0004 Y:0000 P:envMXdIzc    ;do transfer
$7E/22BF 8A          TXA                     A:0001 X:0004 Y:0000 P:envMXdIzc     ;this is effectively increasing X by the amount of transferred data
$7E/22C0 7D FF 05    ADC $05FF,x[$06:0603]   A:0004 X:0004 Y:0000 P:envMXdIzc
$7E/22C3 B0 FE       BCS $FE    [$22C3]      A:0006 X:0004 Y:0000 P:envMXdIzc
$7E/22C5 AA          TAX                     A:0006 X:0004 Y:0000 P:envMXdIzc
$7E/22C6 E4 A5       CPX $A5    [$00:00A5]   A:0006 X:0006 Y:0000 P:envMXdIzc - Check for background scroll
$7E/22C8 D0 C6       BNE $C6    [$2290]      A:0006 X:0006 Y:0000 P:envMXdIZC
$7E/22CA 64 A5       STZ $A5    [$00:00A5]   A:0006 X:0006 Y:0000 P:envMXdIZC

This is the full routine for everything that's been labeled and such from the heavy help of everyone thus far.

Removing this whole routine.. actually does some extensive damage to the game per se.  No text shows up anymore, icon palettes don't update, text doesn't update, some graphics load incorrectly etc..


September 13, 2013, 03:18:48 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
Okay, sorry about the double post, but this is getting.. frustrating.

Here's what I had in mind doing:

1. When the text pointers are being picked out, set a VRAM location storage for transferring. [ Which would be at $0100 ]

2. When the text picks an actual letter to print, it takes that value and multiplies it 4 times, which results in the correct area in ROM. (IE: 49 * 2 * 2 * 2 * 2 = 490.  Location of font is at 3E:8000 so adding it would result in 3E:8490)  It'd store the value say at: 7E0200 for 9084 then 7E0202 would be 3E: Thus being 3E8490 for 'I'

3. It'd count how many bytes to store (Being a fixed width of 08 at the moment).  So it'd load two bytes at a time, start storing them at 7E0210.  It'd decrease the width by one byte at a time while increasing the graphic counter by two at a time resulting in a 16 byte transfer to RAM.

4. At 7E2290, I'd remove all the code essentially and then:

Load $0100 for VRAM location and store that to $2116
Store $0080 to $2115 (Which I think is a trigger for VRAM writing?)
Store $0001 to $4370 (I think this has something to do with DMA)
Store $0018 to $4371 (Same as above I think)
Store $0210 to $4372 so it has a base of xx:0210 for reading from RAM
Store $007E to $4374 so it reads 7E:0210 for reading from RAM
Store $0016 (?) to $4375 so it knows how many bytes to read? (I think)

Gah.  I'm just confused on how to get this all going.

[Nightcrawler]

The only way to tackle anything complex is to break it down into simpler achievable steps. Try step one (Basically your step 2).

Change the text routine to figure out where to pull a character from ROM. Debug that routine until it works as expected and you have the correct location at 7E0200.

If you get that done, try the next small step which is to retrieve that character from ROM and store in RAM somewhere. Put that code immediately after. Again, debug until you get it right.

Ok, so now you know you can pull characters from ROM and write them to RAM. Now you need to work understanding how to transfer that data to VRAM. Don't worry about what the game does. Just slap a DMA transfer or a manual transfer immediately after the code you wrote to store the character in RAM. Put a infinite loop right after that so it freezes so it doesn't even advance. Then debug this code until you can successfully figure out how to transfer a tile to VRAM yourself! You can debug this by seeing if the DMA triggers correctly in Geiger's debugger, taking a savestate and examining it in VSNES, or checking VRAM in an emulator that might allow you to view it.

Lastly, directly after your transfer (continue to forget about the game), you'll want to go for some tilemap changing code to reference the tile you just placed in VRAM. You can check for a successful tilemap change using savestate, VRAM hex viewer etc.

Summary
The idea here to to take the game out of the equation so you understand the fundamentals. The way it is now what the game does is confusing you on top of struggling with the fundamentals. So, separate the two for now. By the end of this exercise you'll have figured out how to retrieve a character from ROM, copy it to RAM, and then get that into VRAM. Then change the tilemap to reference your character on screen.

Finally, when you've figured out the basic mechanics of printing a letter to the screen, you can worry about what the game is doing.

[justin3009]

Got it so far!  Stores the letter perfectly in RAM and now I'm working on transfering to VRAM.

DMA[0]: CPU->PPU Mode:1 0x7E0210->0x2118 Bytes:10 (inc) V:075 VRAM: 0100 (1,0) word

It's definitely triggering and says it's storing to 0100 in VRAM (And there is DEFINITELY data from RAM), but for some reason it's not showing up at all in VRAM at all.  Like, purely 00 00 00 00 keeps getting written when it's clearly taking from 7E0210 where there's data constantly there.

Code Select Expand

$40/A010 A9 18       LDA #$18                A:0000 X:0000 Y:000B P:envMXdIZc
$40/A012 8D 01 43    STA $4301  [$06:4301]   A:0018 X:0000 Y:000B P:envMXdIzc
$40/A015 A9 01       LDA #$01                A:0018 X:0000 Y:000B P:envMXdIzc
$40/A017 8D 00 43    STA $4300  [$06:4300]   A:0001 X:0000 Y:000B P:envMXdIzc
$40/A01A A9 80       LDA #$80                A:0001 X:0000 Y:000B P:envMXdIzc
$40/A01C 8D 15 21    STA $2115  [$06:2115]   A:0080 X:0000 Y:000B P:eNvMXdIzc
$40/A01F C2 21       REP #$21                A:0080 X:0000 Y:000B P:eNvMXdIzc
$40/A021 A9 00 01    LDA #$0100              A:0080 X:0000 Y:000B P:eNvmXdIzc ;VRAM store location
$40/A024 8D 16 21    STA $2116  [$06:2116]   A:0100 X:0000 Y:000B P:envmXdIzc
$40/A027 A9 10 00    LDA #$0010              A:0100 X:0000 Y:000B P:envmXdIzc ;How many bytes to transfer
$40/A02A 8D 05 43    STA $4305  [$06:4305]   A:0010 X:0000 Y:000B P:envmXdIzc
$40/A02D A9 10 02    LDA #$0210              A:0010 X:0000 Y:000B P:envmXdIzc ;2-byte Base Pointer to read from
$40/A030 8D 02 43    STA $4302  [$06:4302]   A:0210 X:0000 Y:000B P:envmXdIzc
$40/A033 E2 20       SEP #$20                A:0210 X:0000 Y:000B P:envmXdIzc
$40/A035 A9 7E       LDA #$7E                A:0210 X:0000 Y:000B P:envMXdIzc ;Bank to read from (Results in 7E:0210)
$40/A037 8D 04 43    STA $4304  [$06:4304]   A:027E X:0000 Y:000B P:envMXdIzc
$40/A03A A9 01       LDA #$01                A:027E X:0000 Y:000B P:envMXdIzc
$40/A03C 8D 0B 42    STA $420B  [$06:420B]   A:0201 X:0000 Y:000B P:envMXdIzc
$40/A03F 6B          RTL                     A:0201 X:0000 Y:000B P:envMXdIzc

Code Select Expand

02 7E 1C 7C 7A 06 7C 1C 70 10 02 7E 7E 7E 00 00 - This is what's currently at 7E:0210 as an example.  But VRAM just consistently keeps storing 00 00 00 00 00 00

[Nightcrawler]

You can only transfer to VRAM during vblank or it will fail. Do a quick test and try it on ZSNES and it will probably work as-is.

You'll need to wait for vblank by using register $4212 and bit 7 (vblank flag).

Something like this should get you going right before your DMA code starts:

Code Select Expand


waitforvblank:
lda $4212
bpl waitforvblank

For actual final code, you'd probably want to do some fancier code to either wait for a fresh frame, or determine if you're already in vblank and how much time is left to know if you complete the transfer. These types of things will avoid periodic timing glitches that could occur with the simple check. That's a topic for another day though!

[justin3009]

Success!  The only thing now is trying to get the Tilemap/base to construct properly. (I'm still really confused on what these are/how they work)

Get that going properly and I'll still re-organizing all the code to be proper/clear out when new dialogue, etc..

Edit: Oh.  I went to VRAM at $1000 to edit the tilemapping and had it go sequential at like 21 08 22 08 23 08 etc.. Well THAT makes sense on the construction.  Just need to figure out how to make it NOT do that.

Edit 2: WAIT! I think I found a method though it's not absolutely perfect!

It uses the reading from 7E0604 to read dialogue and tilemap.  So what I did was force a hardcoded setting of $20 for a value there and each letter it increases by 1.  So it reads 20 08 21 08 22 08 etc as it goes MAY not be the best coding and it has a couple bugs, but it's working!  It's almost a decent dynamic tile reading!

Do you have any pointers on making it look more.. cleaned up?

[Nightcrawler]

Congrats. That sounds like a reasonable approach to me. To clean it up, you'd probably want as few game hooks as possible. So, you can think about how to more smartly integrate it with the game code. Also things like if you're still using your new DMA transfer, perhaps you want to figure out how to get the game's original transfer to handle what you want. Or, sometimes it's a cleaner approach to disable several of the games routines and replace with your own replacements. There's more than one right answer.

I'd say get it working perfectly and worry about optimization and cleanliness later.

[justin3009]

I still plan to VWF this but right now just dynamic tiles takes an importance.

Edit: Fixed an issue, though I need to move everything to a new ROM soon.

I had to incorporate a new text command which set the VRAM value back to $100 and then set the letter value back to $20.  Then altered a 00 command to hit ABOVE 7E0604 and reduced the counter by two bytes.

The value to set VRAM and such again would be '84' (Which goes completely unused along with about 4-5 other values) in the English ROM.  So once I port the code over to a regular ROM, I can start modifying the text with the new value to see if it causes any discrepancies in the game itself.  If not, then onto the next step of actually implementing a VWF!

Edit 2: Moved everything to a fresh MMX3 Rom.

Erased the 'new' command and am trying to rework it so it uses no commands and does the storage/loading automatically.

The issue right now is that when the letters scroll, 7E0604 MUST be 00 00 otherwise it'll result in writing letters to the side of the screen.  So at this point I'm trying to store the letter value to another area in RAM before it scrolls then load it after it scrolls.  It's pretty.. iffy right now.  Once I can get this to be automatic it should solve basically every problem I've ran into.  I just hope I can get this working right.

Edit 3: Got most of it!  All dialogue in game seems to work.  Just when you swap characters it.. gets weird.  If you let the game run normally it'll bug up, but if you do a breakpoint then it prints the letters correctly (What the heck is up with that?)

And 'GET WEAPON' text is bugged as well.

[justin3009]

I think Mega Man was almost a bad choice to use this style of dialogue writing with how it scrolls Layer 3 and writes over it.  Keeping the original style really creates a ridiculous challenge, though, not completely impossible.  It's just a pain in the butt to work around.  Otherwise if it was removed to go with the Mega Man & Bass+ system, it'd just wipe it clean and write over which would remove every single problem.

But onto the previous project I had!  Sailor Moon: Another Story.

- Temporary tilemap editing in action! (Placeholder font!)

Edit: Quick question.  I'm trying to have the game pull the font from ROM without using pointers like the original system.. but the font is 8x16.  It works fine for 8x8 but I have no clue what I should do for 8x16.  Do I really need to use pointers for each letter?

[henke37]

What is a pointer? It is a variable storing a memory address. What address space does the memory address use? Is it even measured in bytes?

[KingMike]

The pointer is a memory address.

As to why 8x16 doesn't work for you, justin, well that's an issue with that game's code.
You will have to look at the code. So, an 8x8 works. What is so different about an 8x16? What does an 8x16 do?
How can it be changed?
If the font is uncompressed, then that would mean each character is the same size. Then rip out that part where it reads the pointer table to each character (probably something like FONT_POINTER = POINTER_TABLE[ CHARACTER_HEX_VALUE ]) and replace it with that does like NEW_FONT_POINTER = CHARACTER_HEX_VALUE * SIZE_OF_A_FONT_CHARACTER + BASE_ADDRESS_OF_FONT in whatever is necessary with the code.

[justin3009]

That's what I've been trying to do, but right now I'm just going to have to redo the entire code in general.

What the game does is use pointers to get each letter.  It uses that to load the graphics and then stores it into VRAM.  It's a literal ROM --> VRAM transition for this games dynamic tiles.

I cheated a little and looked at Chrono Trigger's routine for handling it's letter size and kind of hijacked that.  It loads all letters but it loads a chunk of excess (Which is to be expected without any alterations to the routine).  So I'm going to pick out an empty RAM spot and start storing the graphics there to get everything sorted out first.  After that, I'll need help fully understanding VWF implementation.  Though, I do think I have a general idea.  I'll post that once I get the basics working as I don't want to overwhelm myself.

Edit: Actually, Chrono Trigger's method works amazingly well if I'm understanding this right.

What it does is store each letter into a location in RAM, like the usual junk.  VRAM doesn't store it letter per letter basis, but rather, it stores it by a block of RAM.  A whole line of text essentially gets stored into 7EF000 in RAM with Chrono Trigger.  Each time a new letter is written, that block gets transferred to VRAM.  Now when it needs to update a location in VRAM, it updates whenever it does a new line.  The RAM location stays the same, just the location gets shifted in VRAM.

So it's not letter per letter but rather block per block (Same block).  Not sure how efficient this is but I think it's actually quite nice and makes it a lot easier to deal with.

Edit: Got most of it working.  Still a couple errors now since I updated the routine.  Font/Tilemap error.  Fix that then I can start putting in the VWF values.  Hopefully that'll solve the issues then!

[justin3009]

Bringing this up again, but I have another question on VWFs.

http://board.byuu.org/viewtopic.php?f=9&t=3490

This topic states 'Dynamic Rendering' and 'Static Rendering', unfortunately, the article listed in that topic is gone.

What exactly are Dynamic/Static rendering?  From what he said, he uses static rendering in Bahamut Lagoon.  I'm wondering what exactly it is as I'd LOVE to try and port that into Tales of Phantasia.  TOP's VWF, even in little amounts, lag so ridiculously hard that it's just obnoxious.  I'm wondering if that'd be a way to per se 'fix' the issue.

[BRPXQZME]

Internet Archive's got your back.

[justin3009]

The biggest limitation is speed. Rendering an entire screen full of item names at 2bpp on a 2.68MHz CPU is indeed painful. Combined with limited Vblank time to transfer the tile data, you can find yourself needing up to 2000ms to render a full screen. And during this time, you will see the new items slowly replacing old items as you flip through screens, with significant lag.

When you are requested to write an item into the tile map, simply ensure that you are in Vblank, index into your block of all pre-rendered item names, and then DMA it over. This takes about one scanline per item.

Is he basically saying that instead of having the screen consistently writing to the screen, only have it update when needed and just replace the tile map instead of VRAM entirely?

[Gemini]

Basically he says "screw real time rendering & shifting, prerender 8x8 tiles!", which sacrifices ROM space for speed and makes everything look shiny and nice. You're still going to need dynamic rendering somewhere, due to variables, counters, and such, but you gain a lot of speed due to not using the CPU for shifting tiles around every time. Byuu also suggests to use the SRAM as a scratchpad of sorts, so that WRAM doesn't get polluted by custom data the hacker needs. Of course, this approach won't work with anything like dialog with timed progression each 2-3 frames or so; it this case you're gonna have to use dynamic, but most games allow the hacker to do so thanks to canvas rendering.

[justin3009]

Pre-render the 8x8 tiles?  (I'm not exactly sure what this means but I'll take a whack at understanding).

Do the tiles get spaced out and stored to RAM BEFORE VBlank or anything occurs, then it just transfers it over?  I'm pretty sure my understanding is lacking hard.

[Gemini]

It's pretty much a simple DMA copy of the tile data from ROM to VRAM. You pre-assemble in ROM all the 8x8 stuff you need for menus and such and then copy whatever is necessary at runtime.

[justin3009]

So it's basically doing everything in one swoop (For the most part) instead of going through a bunch of shifts trying to get what it needs during the transfer?

Edit: I just took a look at Bahamut Lagoon's code for the VWF a bit.

I guess it varies HEAVILY in terms of how it does it's graphic storage.  If I'm seeing this right, most other games go through a loop to store the graphics, while Bahamut Lagoon's just loads code after code after code storing each couple bytes in a consecutive sequence instead of using a loop.

Edit 2: Actually, it's pretty similar at points with Chrono Trigger's VWF if what I'm seeing is right.