It is currently Thu Dec 14, 2017 3:15 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Dual port SRAM
PostPosted: Tue May 17, 2016 3:00 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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.


Top
 Profile  
 
 Post subject: Re: Dual port SRAM
PostPosted: Tue May 17, 2016 3:16 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject: Re: Dual port SRAM
PostPosted: Tue May 17, 2016 3:29 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: Dual port SRAM
PostPosted: Tue May 17, 2016 3:29 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6520
Location: Seattle
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)

Quote:
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.

Quote:
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.
Quote:
and they mess up the sprites that are in y∈(240,255] interval
Uh?

Quote:
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.


Top
 Profile  
 
 Post subject: Re: Dual port SRAM
PostPosted: Tue May 17, 2016 3:57 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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:


Top
 Profile  
 
 Post subject: Re: Dual port SRAM
PostPosted: Tue May 17, 2016 4:11 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject: Re: Dual port SRAM
PostPosted: Tue May 17, 2016 4:22 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1868
Location: DIGDUG
Quote:
possible to dynamically load new sprites during rendering.


Yes, that is possible, with mapper bank-switching, like MMC3 does.

Quote:
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


Top
 Profile  
 
 Post subject: Re: Dual port SRAM
PostPosted: Wed May 18, 2016 1:20 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
 Post subject: Re: Dual port SRAM
PostPosted: Wed May 18, 2016 4:47 am 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
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 1700 times ]
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group