Your images aren't showing up!
Here's some of what I learned:
There are 8 palettes, of 3 colours each. They all share the same background colour. Backgrounds then get 4 colours, while for sprites, that colour is transparent.
(I better preface this with: This is how it works in Final Fantasy 1 and I may be wrong about how it works in other games.)
Palette data is stored at $3F00 in RAM. It's $20 bytes (hex) total, or 4*4 decimal. The first 16 bytes are background colours, the second 16 bytes are sprite colours. 4 sets for each. So $3F15 is the first colour for the second set of sprite palettes. When loading them up, usually the game has backup palettes saved in a buffer, that it then copies over to $3F00 when its time to set them for real.
Sprite data is stored at $0200, known as OAM, and I don't know what that stands for. Each 8x8 block of pixels is its own sprite tile. This tile is in CHR RAM, and I can't say for certain where that is, because I think it can change depending on the mapper and what the game is doing with its graphics. Going with my Final Fantasy 1 knowledge, bot the background and sprite CHR have 256 tiles each, which usually get loaded in chunks beforehand. I don't know what CHR really stands for either! But re: sprites...
Each sprite has 4 bytes in OAM ($0200). The first byte is Y, vertical, position, in pixels. So $7F is like halfway down the screen or something. The second byte is the tile ID, that tells it what 8x8 graphic to use from the sprite CHR. The third byte is attributes, this gets a little messy, but if you just want to know about colours, then numbers 0-3 set the colour. $0 is the first set of sprite palettes, $1 is the second, $2 is the third, and $3 is the fourth. This only accounts for 2 BITS of the sprite's attribute byte. The other bits decide if its flipped upside-down or backwards, or if its behind or in front of background tiles. The third byte of the sprite's info is the X, or horizontal position, again in pixels.
Since the pixel positions can go up to 256 and the screen is only 240 pixels high (I forget how wide), setting an X or Y position of $F0 hides the sprite "off screen" Final Fantasy 1 just flood-fills the sprite RAM area with $F0 to basically tell the game not to draw any sprites this way.
So next time you look at $0200 in RAM, every 4 bytes is 1 8x8 pixel sprite tile. The next 4 are the next sprite, and so on. The game doesn't have to fill this in order, either. But every $10 bytes is a 4x4 sprite usually. To update sprite positions, new X and Y positions are written. FF1 likes to COMPLETELY wipe the sprites out every single frame and re-draw every single byte from a buffer! I think this is because this part of RAM decays faster or something, so if you don't keep updating even the tile ID, it will end up garbling itself?
Background tiles get their colour from the attribute table, which is an 8x8 grid. Each square of the grid is composed of 4 smaller squares, which can be filled with 4 8x8 pixel tiles. The easiest way to think of it is the blocks in Super Mario Bros. Every group of 4 tiles is its own colour. But to figure out what colour that is, the game has to do a bunch of gross math to figure out the colours of the other blocks that share its attribute box.
The best program for visualizing this is - https://www.romhacking.net/utilities/1087/
Each corner of the square can be a different palette set. That utility will use 1, 2, 3 and 4, but the game will probably refer to the palettes as 0, 1, 2, and 3. So NES games set 16 tile colours at once with just 1 byte of attribute data! Now I'm wondering how Tetris games do it, but I haven't played one in forever... I know the MMC5 mapper has a switch that gives up some CHR RAM for having a higher fidelity attribute table, where every 8x8 pixel tile can have its own colour set, but that's the only outlier I know of.
I hope that explained anything a little better... I'm basically re-learning this every month on my own, then I forget and have to read up on it again, so I hope I'm not forgetting something. Its all fresh in my mind so I could forget an obviously trippy bit...
The best learning tool to see how things are working is an emulator like Mesen, then open up the PPU Viewer and switch between the tabs, pausing and unpausing to see things change, mousing over tiles to see bits of information about them in the side panels. Really helps piece it all together.
For the pointers--see if you can set a breakpoint for when they're read? Then see what is happening after its loaded. It sounds to me like the game is reading the pointer, then maybe doing some extra math on it to fix it up right to point to the proper string. Its hard to tell without the pictures though...