nesdev.org

Yeah you're right.

I got a second sprite to display by changing Spritebuff2 (aka $0600) from #$54 to #$50. So instead of it being equal to #%01010100, it's now #%01010000. I guess I forgot how binary worked for a minute which is why I couldn't figure out what exactly was going on with this part. I expected that changing it to %#00010100 would work for some reason.

Following what HihiDanni just said sort of bumped me in the right direction causing me to realize this, and now I have a second sprite on the screen without glitches. I only needed that one DMA transfer section for it to work just like being told.

Now it's the same sprite as my first, not the different one that I'm trying to get to display, but I'll probably figure it out within the next day or so. It has to do with telling it somewhere the correct VRAM address which I likely overlooked and did wrong, so time to study some more snes code on the wiki.

EDIT: Yeah I don't know. Can someone point me in the right direction as to change what displays as the second sprite? Right now It's only showing my first one for both sprites. I am trying to get my second sprite at VRAM $9000, $0800 to show instead.

I'm just using that LoadBlockToVRAM code. Not sure why it's not linked to my 2nd sprite already the same way the DMA transfer code did it but I haven't been able to find out how to change it. I could get it so that some of that ONE working sprite's 16 tiles are used for another sprite and then tell it to use for example the 4th tile row only for sprite 2 using the 3rd byte of the low table but then I'm reducing the possible usable tiles for that 1st sprite just because there's no possible way to just load another different file for my 2nd sprite. I just don't see why using a different image file for a different sprite which is at a different VRAM address, allowing more versatile graphics, has to be such a nearly impossible task.

If it's displaying a copy of the first sprite there's only two ways that should happen - either your data in VRAM has another copy of the first sprite, or else your OAM data is pointing to the wrong sprite. In the main OAM table where each sprite has 4 bytes, the third byte should be set to select which sprite in the allocated region of VRAM to display, that's my guess where your problem is, it's probably still set to zero.

Are you sure? Byte 3, or the one that is in the cccc cccc format, points to which tile of the sprite to use from my understanding of it. If I start changing values of the 3rd byte, it just cycles through tiles. I mean I didn't just type in every value from 0 - 255 but it's like, in increments of #$40, just add + #$40 to get to the next row of tiles. For example, 00 shows the first row of my first sprite, #$40 shows the 2nd row, #$80 is responsible for the 3rd row and #$C0 is the 4th row in my 4x4 sprite tile that got made with pcx2snes.
To get to the next column, just add #$04. For example, setting byte 3 to #$44 sets it to row 2, column 2, whereas #$40 is row 2 column, 1 and #$48 is row 2 column 3. Since my sprite is only 4x4, setting it to something like #$50 just makes it sort of glitch but #$4C is fine.

None of these options show me the 2nd sprite that I'm trying to display which is stored in the VRAM at $9000 and is $0800 in size.

What is it that I'm missing?

You could load the ROM into SNES9x 1.42 (or ZSNES) and make a savestate that you load into vSNES. From there you can see the status of the system - and even change it via the hex editor.

I sort of got it to work by just putting a crap ton of sprites on one single tilemap and loading that ONE sprite tilemap into VRAM. Then and only then will it let me use those using byte 3 of the low table. It works OK except I can't have more sprites than will fit in one rom bank.
I think I read somewhere that if the other tilemaps start after like $6000 or $8000 or something they won't show up which is my problem right now. Even though I'm using a massive amount of sprites in one file that's like $3800 in length, it starts at $6000 and I can still use every tile in that map. Whenever I get around to doing that, I'll put another sprite into a different bank starting at $0000, keeping the one I have in a different one and if it works I'll post about it here.

Sounds like a lot of guesswork.

Ditch any framework files you're using (they often only help if you already know what they're doing with the hardware), read regs.txt again and write a new test ROM from scratch.