nesdev.org

sorry i guess i am misunderstanding the TSB TRB, figured resetting a bit, would be the same as simply writing a 0 to it, i'm going to have to halt my progress to get this worked out.

TSB/TRB (and others) are what are called "read-modify-write" instructions.

You can think of TRB as basically being a quicker way to do this:

Alright I guess I'll need to do this over with the nes $2000 & $2001 bits. Sucks cause I'm at the part where I am converting the chr data, wish I understood better earlier. My new plan is to break down those bits from nes $2000 $2001, have DP registers set aside where they get modified correctly, then sent properly to the snes equivalent addresses.

Edit - Ok, I see what I've been doing wrong with TSB/TRB. I've been using it incorrectly, thinking it was setting/resetting bits of the current value loaded in A. *slaps head. I figured out that's not how it's used, it's used as an absolute address or direct page address.

The game I'm working on has a fair amount of unused zero page registers, so with my port I'm going to have dedicated registers within DP, that will contain the appropriate bits to be stored, and then those registers will be stored into the snes addresses.

Its going to taken time for me to redo those massive routines I wrote, but I'm glad that I finally get how to use them correctly.

I apologize to all of you that have tried explaining, and I kept misunderstanding.

Once I get that complete, I'll be able to move on with the chr tiles being uploaded to vram, I'm already doing conversions of pointers and bank id's for how the chr needs to be loaded into my port. Very exciting.

Ok I'm just about done fixing my TRB/TSB issues, (i work full time so my times limited) and I want to ask about mirroring. This game uses the mmc3 $A000 address to set either horizontal or vertical mirroring. The gameplay is always displayed on the NES nametable address $2000.

My question is, is this the same as simply setting the BG1 mode to 32x64? If that's the case, then I plan on just simply setting BG1 to always be 32x64.

Right now I haven't gotten to the point of having anything written to the screen, and right now my BG1 is set as 32x32. So when it comes time for the game to switch over to vertical mirroring, I have it setup to switch the BG1 mode to 32x64. But I want to know if I can just simply set it as 32x64 and leave it as that?

Edit - I think I'm confusing myself with how the NES $2000 bits #2 & #1 and #0, allow you to select which Nametable to have displayed on the screen $2000/$2400/$2800/$2C00. I have this incorrect in my port, cause I have it messing with the $2107 tilemap size. I should set the tilemap size, to what the current mmc3 mirroring is set to in the original game. Does the SNES have a similar function as to the NES's Nametable selection?

NES nametables are 30 tiles high, so it's not exactly the same as 32 tile high SNES maps.

Vertical Mirroring (side scrolling) is the same as 64x32 SNES.

Horizontal Mirroring (up or down scrolling) is similar to 32x64 SNES, but might require code changes, since NES screens are only 30 tiles tall.

Both 64x32 and 32x64 SNES modes will have the 2nd screen directly after the 1st screen in VRAM (unlike NES horizontal mirroring).... and attribute data will be per tile on SNES (16 bit tile and attributes), whereas NES puts all the attribute bytes at the end of the nametable.

Thanks for that info dougeff, but is the snes able to select which part of the 32x64/64x32 screen to have displayed? The nes $2000 #2,#1,#0 bits select which $20/$24/$28/$2C Nametable to display, does the snes have the same thing? If not I'll bypass this part of the code in my port and simply rely on the mmc3's selected mirroring.

SNES scroll registers are 16 bit. That is how you manage it.

Oh ok, I understand. I forgot that's scanline based. I know what to do for that thank you!

infidelity wrote: ↑Tue Mar 16, 2021 9:22 am Thanks for that info dougeff, but is the snes able to select which part of the 32x64/64x32 screen to have displayed? The nes $2000 #2,#1,#0 bits select which $20/$24/$28/$2C Nametable to display, does the snes have the same thing?

You select the Name Table (or Map) by the $2107-$210a registers for each Background.
Take a look here.

NOOPr wrote: ↑Tue Mar 16, 2021 9:31 am

infidelity wrote: ↑Tue Mar 16, 2021 9:22 am Thanks for that info dougeff, but is the snes able to select which part of the 32x64/64x32 screen to have displayed? The nes $2000 #2,#1,#0 bits select which $20/$24/$28/$2C Nametable to display, does the snes have the same thing?

You select the Name Table (or Map) by the $2107-$210a registers for each Background.
Take a look here.

Thank you, that I already knew and have functioning properly now, i just forgot that its scanline based when it comes to viewing which section of the tilemap you want displayed. I over-thought the process.

dougeff wrote: ↑Tue Mar 16, 2021 9:16 am NES nametables are 30 tiles high, so it's not exactly the same as 32 tile high SNES maps.

Horizontal Mirroring (up or down scrolling) is similar to 32x64 SNES, but might require code changes, since NES screens are only 30 tiles tall.

Code changes? I fear now my vertical portions of the game will look off.

Actually I took a look at the smb1 port, looked at the tilemap and noticed like you said, that only 30 tiles are present, but it showes the bottom 2 tiles unfilled. I'm thinking maybe as long as I dont have tiles written into that area, my vertical scrolls should still look seamless?

Keeping the code the same... Writing only 30 tiles high per map and skipping 2 is going to leave a 2 tile high gap.

Maybe you could put the 2 nametables on 2 different layers and shift them so the top of one lines up to the bottom of the other.

There is probably 3+ other ways you could deal with this, none of which are easy to explain.

1. HDMA or IRQ to a mid screen Y scroll change.

2. Use mode 2 and use offset per tile shifts.

or

3. Change the code so that it just uses the full 32 tile high screens fully.

Any other suggestions, guys?

If you're using two tilemaps stacked on top of one another, it should be possible to simply treat them as though they're only 30 rows high. This will result in what would have been the top two rows of the second map being written into the bottom two rows of the first map.

If you don't need to wrap from the bottom of the second map to the top of the first one, this should be all you need. If you do need to do that, you'll need some other workaround.

Definitely more than 2 vertical screen scrolls, in the game I'm working on. Glad this is being discussed now, I'm nowhere near ready for screen construction, so this is good timing here.

Ok so here's an update to where I am with this port.

8 bit colors point to their 16-bit equivalent, and are loaded into cgram.

I fixed my issues with the misunderstandings of the TSB/TRB usage, bits are now set properly in the registers I have set aside, for the various snes addresses.

I've set this port to use Mode 2. I was manually inserting gfx into vram, so I can see how the tile properties work. I was having a difficult time getting the right choice in palettes for my test tile, but when I set the tilemap to Mode 2, I was able to have the first byte dedicated to any tile id from 00-FF (just like the original nes game) and the second byte, I figured out the rightmost bits set the palette #0=1st, #4=2nd, #8=3rd, #C=4th. When the time comes for the drawing routine, I'll need to come up with a routine that looks at the original attribute for the 16x16 block, and use the palette from that, for the current tile. Sounds easier said than done, but I wont be there for a few days I believe.

Right now I'm back where I left off, at the point where the rom begins pulling up the chr data to be loaded and stored into vram. I've began converting the values, such as the bank id for the gfx location, the amount of bytes to transfer, the hi byte address for the gfx location, and the hi byte address for the vram location. (glad I picked a chr-ram title to port) The game pretty much does all the hard work, for preparing all the data that I'll need to use with DMA, I just need to tweak the code for DMA usage. I'm going to hold off on converting the entire table of chr data, I want to see at least the copyright screen and pre-intro chr tiles being injected properly.