Getting Started on a VWF?

[Spikeman]

Strange. Perhaps you could post a patch? It's kind of hard to tell what's going on without looking at it in an emulator. (Actually you should post patches of both cases, so we can compare them.)

My first thought is maybe it is drawing the characters as sprites, or maybe there is some weirdness going on in the tilemap. Hard to tell exactly without looking at it actually running.

In that third picture, is that how the VRAM is actually laid out when the game is running? Or how you are storing the graphics in the ROM?

Also, there are really pointers to each character? That sounds a little unnecessary...

(Also, I assume you know about the translation that has already been done? Apparently it has a VWF implemented. Might be helpful for you to take a look at how they implemented it.)

Edit:

I'm looking at the game in no$sns right now (what debugger have you been using?), and I think I answered my own questions.

The font is being written to BG3, so the problem isn't due to sprites. I think my thought that it may be the tilemap is indeed the case. Now keep in mind I'm looking at the unmodified ROM. It looks like the tiles making up the first character are at 7E87, 7E88, 7EA7, 7EA8. If you look at the corresponding tile addresses, they are 6100, 6108, 6110, 6118. This explains the problem you're having -- the tilemap is still laid out like it is an 16x16 font, but it looks like you're trying to do an 8x8 font.

First, are you trying to do an 8x8 font or an 8x16 font? I thought an 8x16 is what you were aiming for.

Next, it looks like you are only modifying the behavior of the game when it comes to loading the VRAM tiles. You're also going to need to figure out how to modify the tilemap. It's probably the case that the tilemap is just set once, and you can just edit it somewhere in the ROM.

BTW, feel free to contact me on MSN or AIM, maybe I can help out better that way.

[justin3009]

http://www32.zippyshare.com/v/14973755/file.html - Patch is here.

Code Select Expand

$80/B8AF 69 20 00    ADC #$0020              A:0000 X:0002 Y:0420
- The code here is what's doing the odd storage.  Currently it's 08 so the letters are side by side.  The normal value is 20.  This is the VRAM Storage/Spacing of letters type.. thing.

The third image: Yep, that is how they get thrown into VRAM.  Though it's two separate images pasted together (They both appear on the top line with the 'works' bit).  It's just show casing a comparison between the VRAM storage that occurs with a simple change of a byte from 08 to 20.  The graphics in ROM are directly side by side, which is more or less how it'd be represented with the 'Doesn't work' bit.

Yeah, there.. really is.  It's pretty strange.  This game does a lot of unnecessary things from what I've seen.

And yes, I've taken a look at FuSoYa's VWF and I couldn't exactly follow it well.  It seemed to flow with the normal code but then it broke into a HUUUGEE section of code that I couldn't even exactly begin to follow correctly.  (Doing it this way is much more of a hassle but it's a perfect example of a learning experience I NEED to do).

[Spikeman]

Sounds good. After a little bit more investigation, it seems that your problem is definitely the tilemap. It looks like it is being set once, and then only the VRAM is modified. You'll need to modify the tilemap so it interprets the VRAM the way you want it to.

Right now it's laid out like this: (lines are the boundaries between characters)

Code Select Expand


6100  6108  |  6120  6128  | ...
6110  6118  |  6130  6138  | ...


For an 8x16 you'd want this:

Code Select Expand


6100  |  6110  |  6120  |  6130  | ...
6108  |  6118  |  6128  |  6138  | ...


For an 8x8 you'd want this:

Code Select Expand


6100  |  6108  |  6110  |  6118  | ...  | 61B8  (this is the rightmost tile of the first row)
--------------------------------------------
61C0  |  61C8  |  61D0  |  61D8  | ...


Does this make sense? Your next goal should be to find the tilemap in the ROM and modify it appropriately.

Also, don't know if you saw, but I can help you out over IM or IRC if you'd like.

Edit: Just tried your patch, I'm getting a blank screen at the beginning of the game (sound plays fine though)... is Bisyoujyo Senshi Sailor Moon - Another Story (J).smc the right ROM?

[justin3009]

I totally didn't see that one bit.  Over IM or IRC would work fine if it's a possibility.  I'll try to see if I can modify the tilemap as needed.

And yes, it should be.  It's an unheadered ROM as well, probably should have stated that before I hopped into bed.

Edit: Well got home later than I thought I would due to the flooding going on everywhere up here.  But I'm.. having issues even finding the Tilemap or what does all that placement.  Or rather, I'm not exactly sure what's causing the placement.

Edit 2: I haven't actually worked on this much the past few days.  Really trying to get used to my new job.  Sucks getting home at 2AM.  But I decided to try copy/pasting from FuSoYa's translation to see if I can get a VWF and such to work.  I did.  But it's.. yeah I have to figure out what everything is.  I think the translation has a DTE in it (I think I'm using the incorrect term.  It's basically the single byte that loads up a specific word from a table to print).  But this would explain WHY there's so much more code.  So essentially if I want to borrow from Fusoya's (Which I really, really don't want to do if I don't have to), I'll have to start dissecting every piece to figure out what is what.

Also, I still have no idea about that Tilemap issue before hand :/  I'm not really sure 'how' you can find it.

[justin3009]

I know I'm jumping around on so many projects but I keep coming back to this and working with VRAM.  I'm REALLY understanding it more and more.  I'm almost certain at this point I could get a decent start on coding it a bit but I feel like I'm missing something still when it comes to Mega Man X3, rather, I have all the pieces of the puzzle but I'm just not clearly seeing everything.

I've found the locations on how it stores the font into VRAM (Really stupidly obvious routine that's used everywhere, not sure how I didn't notice that) and can easily remove it.  That's a no-brainer.  I've also noticed that the letter values correspond to how they're written in VRAM.

So for example, 'I' is letter 49.  It's location in VRAM was '0490'.  And then this is where I get lost.  I still have no clue how it's dragging that letter value, doing what it needs to do, and picking out the spot in VRAM to do so.  I can't honestly seem to get a good trace, step, or anything to see how that occurs.  I'm trying to figure it out completely so I can have it read from ROM for the font (For fixed width needs) but it's like there's something clearly missing or I'm oblivious to it.

7E00C7 may have something to do with it as well.  It's always 00 for VRAM junk.  Altering it I think changes which '1000' section in VRAM to read from but I'm not 100% sure.

[Nightcrawler]

You can't transfer anything to VRAM on the SNES (DMA or otherwise) without setting the VRAM write location to $2116/$2117. That's where the start location of writes will be. From there it either DMA a block of data or manually write to $2118/$2119. Once you find the starting location there, you can work backwards to see where it came from.

[justin3009]

It's not writing TO VRAM at this point (That I know of).  Writing the font to VRAM happens right away at the very beginning of the game.  That's easily removeable.  The issue I'm having now is how it's technically 'reading' from VRAM to get the correct letter from the tilemap and paste it onto Layer 3 screen.

I can't seem to find that bit at all.

[Nightcrawler]

The tilemap is in VRAM as well. There are registers to tell the hardware where in VRAM the tilemap is for a specific layer. The text routine will come up with a tilemap entry for each letter. In most cases, it will store those entries in in RAM and then the entire tilemap RAM block will be DMA'd to the appropriate place in VRAM each frame (usually during NMI). Although it's possible to write each tilemap entry individually.

So, all you need to do is capture the transfer of the tilemap to VRAM. It's the same steps as capturing the font (or anything) to VRAM.

[justin3009]

Code Select Expand

$7E/2296 BD 01 06    LDA $0601,x[$06:0601]   A:0080 X:0000 Y:0000 P:eNvMXdIzc - Location to write on Layer 3
$7E/2299 8D 16 21    STA $2116  [$06:2116]   A:00A1 X:0000 Y:0000 P:eNvMXdIzc
$7E/229C BD 02 06    LDA $0602,x[$06:0602]   A:00A1 X:0000 Y:0000 P:eNvMXdIzc
$7E/229F 8D 17 21    STA $2117  [$06:2117]   A:000A X:0000 Y:0000 P:envMXdIzc

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
$7E/22A8 9C 06 43    STZ $4306  [$06:4306]   A:0002 X:0000 Y:0000 P:envMXdIzc
$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
$7E/22B2 A9 06       LDA #$06                A:0002 X:0004 Y:0000 P:envMXdIzc
$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
$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
$7E/22BF 8A          TXA                     A:0001 X:0004 Y:0000 P:envMXdIzc
$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
$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

Not sure what the rest of it is but it's reading the location on where to place it on screen from there.  Then I think it sets DMA channel or something.  I THINK that's on the right track?

Edit: Sigh, it just leads back to the original junk found from the text.  42A6B9 is where it's loading the coordinates from, color, etc..  Thus the 'storage' from the VRAM bit there.

Edit 2: Letter is stored to 7E0604.. usual stuff I had before.  I'm falling back into that loop.

Edit 3: Setting a read breakpoint on 7E0604 does this.

DMA[0]: CPU->PPU Mode:1 0x000604->0x2118 Bytes:2 (inc) V:235 VRAM: 0AA1 (1,0) word
$7E/22BC 8D 0B 42    STA $420B  [$06:420B]   A:0001 X:0004 Y:0000 D:0000 DB:06 S:02EE P:envMXdIzc HC:0192 VC:235 FC:29 I:00

[KingMike]

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
$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
$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


[justin3009]

;bank byte of source = 0 (so read from RAM 00:06XX

So would that effectively make it read from 7E:0604 since X is 04? (It ALWAYS stays 4 apparently)

[KingMike]

Yes, since I believe the first 8K of WRAM (0000-1FFF) is mirrored across most LoROM banks.

[justin3009]

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

Okay.  So basically this huge chunk of area (OR at least the top portion) sets it to read from 7E0604 which gets the letter value.  In this case, the letter value is 49 for 'I' reading from 0490 in VRAM.

I'm starting to get a bit lost again, no surprise there.  Pretty much RIGHT away after though this whole thing gets overwritten in general by the next letters/backgrounds etc.. so I'm lost now on where to go from here.

But now, since that's figured out that the whole area section there is reading from 7E0604, does it load the data there as 49 then... just pick the right selection in VRAM (0490)?  I'm.. really not sure.

Edit: 7E00A5 isn't the length as far as I know of.  Looks like it's actually used for Layer 1/2 scrolling if it's being used.

[Nightcrawler]

Do you know what a tilemap is, it's format, and how it works on the SNES? I'm not sure you understand exactly what you're looking for sometimes. A tilemap entry is always 2 bytes per tile. So, your single byte text letter is going to turn into a 2-byte tilemap entry. It's a simple conversion here as the game uses $49 $08 as the entry for the tilemap. I highly suggest using VSNES to play around. It will tell you precisely where in VRAM the tilemap is for a given layer in any savestate with text on it. You can then edit the VRAM bytes of said tilemap to see what happens. If you understand how a screen is put together, this stuff is much simpler.

Your text is on layer 3. The tilemap is stored at effective VRAM location 0x1000. This DMA transfer handles transfer of a single 2-byte tilemap entry of 'I' from 7E:0604 to the specific address this tile entry goes at in the tilemap in VRAM. In this game, each tilemap entry gets transferred individually it seems.

I assume your actual text string has 0x49 only, right? If so, there's a small routine that turns that into 0x49 0x08 that gets stored at 7E:0604 for the tilemap entry. For VWF purposes, you're going to hijack that routine. You're no longer going to do that simple conversion anymore, and you won't be using the static font anymore that is stored in VRAM. You'll be building new dynamic tiles and make the tilemap entries point to those new tiles.

[justin3009]

Do you know what a tilemap is, it's format, and how it works on the SNES? I'm not sure you understand exactly what you're looking for sometimes. A tilemap entry is always 2 bytes per tile. So, your single byte text letter is going to turn into a 2-byte tilemap entry. It's a simple conversion here as the game uses $49 $08 as the entry for the tilemap. I highly suggest using VSNES to play around. It will tell you precisely where in VRAM the tilemap is for a given layer in any savestate with text on it. You can then edit the VRAM bytes of said tilemap to see what happens. If you understand how a screen is put together, this stuff is much simpler.

Your text is on layer 3. The tilemap is stored at effective VRAM location 0x1000. This DMA transfer handles transfer of a single 2-byte tilemap entry of 'I' from 7E:0604 to the specific address this tile entry goes at in the tilemap in VRAM. In this game, each tilemap entry gets transferred individually it seems.

I assume your actual text string has 0x49 only, right? If so, there's a small routine that turns that into 0x49 0x08 that gets stored at 7E:0604 for the tilemap entry. For VWF purposes, you're going to hijack that routine. You're no longer going to do that simple conversion anymore, and you won't be using the static font anymore that is stored in VRAM. You'll be building new dynamic tiles and make the tilemap entries point to those new tiles.

I didn't completely realize it was 2 bytes until a couple days ago.  Forgot about the palette byte that comes right after.  The palette byte is loaded directly AFTER the letter is loaded (When it gets stored to 7E0604)

I've known how the screen's been put together for the most part, or so I thought anyway.  I thought that was mostly covered in the previous pages.

The tiles start at right at the beginning of VRAM (The letters and everything included).  Isn't the Tilemap basically just how the letters are arranged on screen, rather how it sets them up?

I know I have to hijack the routine and such.  I'm most likely missing the most obvious thing that's been already mentioned by you and others.  I'm literally trying to figure out how it's picking the value from the Tiles.  It gets 7E0604 values for color/letter but then I'm not sure HOW it takes that value from VRAM and uses it to get the actual tile from VRAM.

[Nightcrawler]

I'm not sure HOW it takes that value from VRAM and uses it to get the actual tile from VRAM.

That's exactly what the tilemap does. It indexes other tiles in VRAM and maps where to put them on the screen. That's a function of the hardware. In other words, the tilemap in VRAM references other tiles also in VRAM. There will be no game code that reads any map from VRAM and fetches tiles from VRAM. That's a hardware function (defined by the related hardware registers) acting on the tile map and tile data in VRAM at any given time.

Again, I recommend using VSNES to play around with the registers and VRAM hex data to understand how it works.

[justin3009]

THAT'S what I didn't know.  I didn't know it was a hardware function at all.

Okay, I'm checking out VSNES.  It's making a little bit more sense to a point.  The 'name base address' I'm pretty sure I've messed with before to a point.

The tilemap address.. I didn't know altering the byte changed tilemap size as well.  That whole thing is a new bit of information to me.

Code Select Expand

$7E/212D A5 CE       LDA $CE    [$00:00CE]   A:009F X:0000 Y:0200 P:eNvMxdIzc - Load tilemap data (Sets as $1000)
$7E/212F 8D 09 21    STA $2109  [$06:2109]   A:000A X:0000 Y:0200 P:envMxdIzc - Stores
$7E/2132 A5 C7       LDA $C7    [$00:00C7]   A:000A X:0000 Y:0200 P:envMxdIzc - Load tile base data
$7E/2134 8D 0C 21    STA $210C  [$06:210C]   A:0000 X:0000 Y:0200 P:envMxdIZc - Stores tile base data

Traced this bit now as well.

All that's setting the Tile Base to $0000 in VRAM and then the tilemap to $1000.  I think that's what I've seen anyway.

So it picks the letter '49' (I) from 7E0604.  It's 49 08 now and that gets used as the index for tilemap entry and placement on screen basically?

Edit: Semi off topic in a way, but isn't Tilemap editing for a sprite basically it's Sprite Assembly?  So isn't this essentially just a background layer assembly/construction to put into other terms?

[Nightcrawler]

All that's setting the Tile Base to $0000 in VRAM and then the tilemap to $1000.  I think that's what I've seen anyway.

So it picks the letter '49' (I) from 7E0604.  It's 49 08 now and that gets used as the index for tilemap entry and placement on screen basically?

Yes, that's correct. Read the section 'Tile Maps and Character Maps' from Anomie's register doc. You'll see how to interpret the tile index/number from the two byte entry. That indexes into the tile base area to the tile with the 'I' on it.

Edit: Semi off topic in a way, but isn't Tilemap editing for a sprite basically it's Sprite Assembly?  So isn't this essentially just a background layer assembly/construction to put into other terms?

Not really. These tilemaps are for background layers. None of this applies to OAM sprites. They're very different and have their own format and tables (which also can be tinkered with in VSNES to learn).

[justin3009]

The tile character data is stored at the address pointed to by registers
$210b-c, starting at byte address:
  (Base<<13) + (TileNumber * 8*NumBitplanes)

210B/210C gets stored twice it seems.  Each resulting in '11' as the byte.

So would it be like Tile Number = 49 * 8 * 2 = 490 (Which is actually where 'I' is stored in VRAM)

Starting at the tilemap address, the first $800 bytes are for tilemap A. Then
come the $800 bytes for B, then C then D. Of course, if only A is required
something else could be stuck in the empty space.

Does this apply to all background layers?

[Nightcrawler]

210B/210C gets stored twice it seems.  Each resulting in '11' as the byte.

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.

So would it be like Tile Number = 49 * 8 * 2 = 490 (Which is actually where 'I' is stored in VRAM)

That part is correct.

Does this apply to all background layers?

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.