Dual port SRAM

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
8bitMicroGuy
Posts: 314
Joined: Sun Mar 08, 2015 12:23 pm
Location: Croatia

Dual port SRAM

Post by 8bitMicroGuy »

I was thinking of making a GUI for my game that is basically a computer OS because the game is about a cyborg. According to my plans, the icons should dynamically load as well as the text in a non-monospace format like in Nova the Squirel or Super Bat Puncher. During the gameplay, there might be dialogues with text in non-monospace format too.

Now, as I know that during the rendering, I cannot write to VRAM via the PPU, I thought of what if I could write to it through MMC5 on one port while the other port is wired to the PPU cartridge pins. What do you think of the idea? This could simplify the rendering problem very much. It might even be possible to dynamically load new sprites during rendering.

The layout of the game would be like this:
  • First 8 scanlines are blanked out with black palette because they're not seen on the TV. Palette for the dialogue and character's face on dialogue loads. It's located on the MMC5's internal nametable
  • Next 4 lines (32 scanlines) for the text and the character's face combined with sprites and background to have 6 colors at the same time + transparency
  • Some scanlines are blanked out with black palette while bankswitching, nametable changing, palette changing and scroll changing is happening to load the game port.
  • Game port with mirroring 0101 to prevent glitches on the side during scrolling such as in SMB3
  • Some scanlines are blanked out. During the first hblank, black color loads as a background. Bankswitching, nametable, palette, scroll change for the status bar. Nametable is in the MMC5.
  • Next scanlines are used for the moving status bar that is in size 16 pixels while playing or 32 pixels if the pause menu or replay mode is activated.
  • Last 8 scanlines are blanked out because they're not seen on the TV and they mess up the sprites that are in y€<240,255] interval.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Dual port SRAM

Post by tepples »

The first question is where you plan to get MMC5 chips in quantity. Depending on in which directions you plan to make your game scroll, just about everything you describe can be done on an MMC3 with the TGROM board (Mega Man 4; Mega Man 6), which has a homebrew clone.

RHDE uses the same text library as Nova the Squirrel, and it's NROM-256. Mostly it's a matter of preparing an update in otherwise unused RAM near the stack ($0100-$017F) to be copied to VRAM as quickly as possible during the next vblank.

If you're trying to lay out the screen like this:
  • 0-7: Blank
  • 8-39: Dialogue
  • 40-47: Blank (replace palette)
  • 48-191: Playfield (vertical mirroring)
  • 192-199: Blank (replace palette again)
  • 200-231: Status bar
  • 232-239: Blank
You could lay out the nametable like this:
  • 0-31 (left screen): Status bar
  • 0-31 (right screen): Dialogue
  • 32-239: Playfield
If you're scrolling only left and right, you're done. If you're scrolling in all eight directions, you can set another split point for line 239 of the nametable to scroll back to line 32.

I'd like to see mock-ups of how you plan the screen to look, with all combinations of dialogue or no dialogue and large or small status bar.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Dual port SRAM

Post by tokumaru »

Is there something preventing you from updating the icons and the text across several vblanks? I mean, when you use vram for animated sprites and backgrounds you actually do need all the speed you can get, since animations constantly need new images, but icons and text? Those don't need to change rapidly at all, or your OS would look like a rave!

I'm no hardware expert, but I believe that even if you go with dual-ported RAM there will still be a lot of timing details to take care of, so this probably won't be as easy as simply dropping the RAM chip on the board and connecting the ports to the different buses.

If you ask me, I'd say you're trying to use a cannon to kill a fly. Games like Battletoads need much more vram bandwidth than icons and text could possibly need, and it makes do without any fancy hardware. Personally, I'd go with a large CHR-RAM chip, like 32KB or 64KB, that can still benefit from the mapper's fine bankswitching capabilities. This way you'd be able to load new content to off-screen buffers across several vblanks and switch it in once it's ready.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Dual port SRAM

Post by lidnariq »

8bitMicroGuy wrote:Now, as I know that during the rendering, I cannot write to VRAM via the PPU, I thought of what if I could write to it through MMC5 on one port while the other port is wired to the PPU cartridge pins. What do you think of the idea? This could simplify the rendering problem very much. It might even be possible to dynamically load new sprites during rendering.
I'm not entirely certain what you're doing, but what I think you're suggesting isn't supported by the MMC5.

The only dual-ported RAM in the MMC5 is the spare nametable, and it can only be used for a nametable. There's no ability to act as a bus master inside (the MMC5's PPU address lines are always inputs)
First 8 scanlines are blanked out with black palette because they're not seen on the TV.
Do you mean "disabled rendering"? 'Cuz if not, you should reconsider.
Last 8 scanlines are blanked out because they're not seen on the TV
You should definitely consider using an IRQ and disabling rendering here instead.
and they mess up the sprites that are in y∈(240,255] interval
Uh?
bankswitching, nametable changing, palette changing and scroll changing
I understand you really want to make the Most Amazing Game Ever And You Will Never Stop Until You've Done Everything but ... Seriously, write a game for the hardware first. Any game.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Dual port SRAM

Post by tokumaru »

lidnariq wrote:Seriously, write a game for the hardware first.
I have to agree with this... Your first project shouldn't need complicated customized hardware.

The NES comes with a number of limitations, some are easy to bend, while others are too crazy/expensive/invasive to be viable for homebrew projects... but if you feel like you absolutely need new hardware to make use of the platform, then maybe you're targeting the wrong platform.

When I joined this community, over 10 years ago, I was also trying to make the most awesome game ever, pushing the hardware's limits in every way possible and impossible, planning how to make use of every last MMC5 feature, and wondering how new mappers could expand the system even further! Multiple screen splits, mid-screen palette changes, forced blanking... I was like that for a while, and look where that got me... I'ts been over 10 years and I don't have a full game yet. I can tell you one thing though: once I gave up on trying to beat the platform, and embraced its limitations, my projects started progressing much more smoothly, and I feel like I have much better chances of finishing something now. And I don't even think I had to sacrifice much, gameplay-wise, compared to my over-ambitious designs.

Anyway, try focusing on creating a solid engine, that makes good use of the system's resources, and I bet you'll have much better chances of succeeding. Or switch to the SNES. :wink:
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Dual port SRAM

Post by tepples »

tokumaru wrote:Is there something preventing you from updating the icons and the text across several vblanks? I mean, when you use vram for animated sprites and backgrounds you actually do need all the speed you can get, since animations constantly need new images, but icons and text? Those don't need to change rapidly at all, or your OS would look like a rave!
Tooting own horn (RHDE): Icons and text need to change rapidly when the player is paging through several screens of icons and text, such as inventory or the available items in a shop. So it spreads out an update over three to six vblanks: more if the layout is being changed between shop and inventory, fewer when changing pages within a layout. And it's all NROM.
lidnariq wrote:
8bitMicroGuy wrote:Last 8 scanlines are blanked out because they're not seen on the TV
You should definitely consider using an IRQ and disabling rendering here instead.
Agreed, especially if you're turning off rendering in a part of the screen where you know that sprites aren't.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Dual port SRAM

Post by dougeff »

possible to dynamically load new sprites during rendering.
Yes, that is possible, with mapper bank-switching, like MMC3 does.
I'd like to see mock-ups of how you plan the screen to look, with all combinations of dialogue or no dialogue and large or small status bar.
Me too.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Dual port SRAM

Post by Bregalad »

To me it sounds like the NES is an unsuitable platform for what to do. The NES has no keyboard, only a 4-button controller and a 4-directional D-Pad, so it is incapable of acting like a computer desktop.

You should develop this for a platform like the Commodore 64, which by the way allows you to write to VRAM at any given time.
8bitMicroGuy
Posts: 314
Joined: Sun Mar 08, 2015 12:23 pm
Location: Croatia

Re: Dual port SRAM

Post by 8bitMicroGuy »

This is how the layout should look like.
Also, I change my mind. There will be 16 blanks below the dialog to prevent the character's face sprite mixing with the sprites of the game.
lidnariq wrote:
8bitMicroGuy wrote:Now, as I know that during the rendering, I cannot write to VRAM via the PPU, I thought of what if I could write to it through MMC5 on one port while the other port is wired to the PPU cartridge pins. What do you think of the idea? This could simplify the rendering problem very much. It might even be possible to dynamically load new sprites during rendering.
I'm not entirely certain what you're doing, but what I think you're suggesting isn't supported by the MMC5.

The only dual-ported RAM in the MMC5 is the spare nametable, and it can only be used for a nametable. There's no ability to act as a bus master inside (the MMC5's PPU address lines are always inputs)
If the dual-port RAM is connected as a WRAM to the MMC5 and to the CHR-ROM/RAM pins, it might be possible.

Also, I thought that the title screen would have the MMC5's 8x8 palettes instead of 16x16. The reason why I want MMC5's nametable is because the PPU's nametables should be used for the playfield only and 4-way scrolling while the MMC5's nametable is used for the status bar so that I don't have to wrap around on the scanline in the middle of the playfield.

This is gonna be lots of IRQs. How will I know on which one the rendering is? How will the checking process take long? Should I make a JMP table and a counter that counts whichth the IRQ currently is?
Attachments
Layout.PNG
Layout.PNG (7.08 KiB) Viewed 3636 times
Post Reply