It is currently Tue Dec 12, 2017 3:44 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Nov 10, 2016 5:37 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 362
While I'm quite busy at the moment with several projects, I keep thinking that creating a visual novel / graphical adventure engine for the NES would be a nice project to take in the future. I was thinking about using an oversize UNROM (2MB or 4MB), having the main interpreter in the fixed bank, and script/text/graphic/music data split accross thre remaining 127 or 255 banks, maybe in compressed form, and page them in and use the assets when needed.

To have the best looking graphics, it would be nice to use 256 patterns for such purpose and 3 palettes. I'd have the text font in bank 1, and the patterns used to build the image in bank 0.

The question is simple. ¿Can I switch bits 3 & 4 from PPUCTRL in mid frame, via for example a sprite zero hit? that would allow me to have the image in the top two thirds of the screen, for example, and text/menus in the bottom.

Would this be feasible?

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 5:45 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 453
Location: Denmark (PAL)
I wouldn't do something like this using CHR-RAM. That sounds like it would be unnecessarily complex, especially considering the lower part with the text always would contain the same pattern table.
I'd suggest using a PCB that allows bank switching the CHR-ROM, and just do this mid frame. This is the method most games with cut scenes (eg. Ninja Gaiden) use.


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 5:50 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 362
I've thought of that but I aiming principally for two things:

- The cart is easy to manufacture.
- The game can be played (and tested, and developed) in most emulators.

I need a fairly amount of PRG ROM space (text heavy games) and CHR space as well, for the images. Forgive my lack of knowledge in mappers, but as far as I know I could get nice results using MMC3, but MMC3 boards are expensive. Maybe an oversize GNROM would do the trick? but those only use one byte for the paging bits, so I'm somewhat limited. Plus you can only page in the whole 32K of PRG and 8K of CHR, which is not pretty in this case.

As most of the time during each frame the game will be sitting down doing nothing waiting for VBLANK, I think that organizing the input routines wisely before and after the sprite zero hit wait loop the think could be doable - of course if the chr bank used to draw the nametable can be switched mid-frame without tons of glitches.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 6:02 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
Quote:
an I switch bits 3 & 4 from PPUCTRL in mid frame, via for example a sprite zero hit?

Yes you can.

Quote:
and script/text/graphic/music data split accross thre remaining 127 or 255 banks,

Be careful, the iNES format will in practice limit you to 128 banks in total. (technically 255 but it's not a power of 2).


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 6:50 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 453
Location: Denmark (PAL)
I guess you have an advantage in your game format that you'd probably like to have a bunch of completely black scanlines between the graphics and the text anyway, so you COULD write the patterns to CHR during these lines, if you really want to keep your entire game in PRG. I don't think I've ever heard of a licensed game doing it like that(?), but of course that shouldn't stop you.

How many cycles does it take to write all the necessary ASCII characters to CHR RAM? Since it's always the same amount of static uncompressed data, I guess you could do it relatively fast.


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 7:18 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19334
Location: NE Indiana, USA (NTSC)
na_th_an wrote:
¿Can I switch bits 3 & 4 from PPUCTRL in mid frame, via for example a sprite zero hit? that would allow me to have the image in the top two thirds of the screen, for example, and text/menus in the bottom.

Yes. A lot of title screens do this, such as those of RHDE and Haunted: Halloween '85.

Bregalad wrote:
the iNES format will in practice limit you to 128 banks in total

NES 2.0 doesn't. I could probably whip up a test ROM for oversize UNROM with 32 Mbit (4 MiB, 256 UNROM banks).

But in practice, 8-bit parallel flash memories larger than 4 Mbit (512 KiB, 32 UNROM banks) will be hard to find. You'll likely have to end up going with one or more of these: surface-mount packaging such as TSOP instead of DIP, level shifters to interface 3.3 V memory with a 5.0 V system, and a multiplexer for adapting a 16-bit flash (27C322 or equivalent) to an 8-bit data bus.

As for scheduling the updates: Showing a mock-up might help us understand what you're trying to do so we can better understand the tradeoffs that you'll have to make.

RHDE and other games using my proportional font engine write 28 characters to a 128x8 pixel line buffer (128 bytes at 1bpp) in each frame.


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 7:22 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6509
Location: Seattle
na_th_an wrote:
I've thought of that but I aiming principally for two things:

- The cart is easy to manufacture.
Depending on what exactly you mean by "easy to manufacture"... you can't get new DIP memories larger than 512 KiB.

Used 1MiB DIP 'PROMs are rather expensive. AIUI, the 4 MiB 27'322 UVEPROM is pretty affordable, but requires more support hardware... unless you throw away half of the capacity. Used 27'160s might be the only affordable part that DIP, 5V, and not require bus width translation.

Quote:
Forgive my lack of knowledge in mappers, but as far as I know I could get nice results using MMC3, but MMC3 boards are expensive. Maybe an oversize GNROM would do the trick? but those only use one byte for the paging bits, so I'm somewhat limited. Plus you can only page in the whole 32K of PRG and 8K of CHR, which is not pretty in this case.
Without designing a new mapper (which isn't hard, but is a different skill), I'd probably recommend either GNROM or Mapper 70 with-CHRRAM-instead-of-CHRROM.

A NINA-001 subset (no PRG-RAM, decode banking registers over a wider range), might be a sweet spot, too.


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 7:51 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 362
Thanks to everybody for the answers.

Sumez wrote:
I guess you have an advantage in your game format that you'd probably like to have a bunch of completely black scanlines between the graphics and the text anyway, so you COULD write the patterns to CHR during these lines, if you really want to keep your entire game in PRG. I don't think I've ever heard of a licensed game doing it like that(?), but of course that shouldn't stop you.

How many cycles does it take to write all the necessary ASCII characters to CHR RAM? Since it's always the same amount of static uncompressed data, I guess you could do it relatively fast.


I wouldn't be writing the charset each frame. That's why I wanted to switch bits 3/4 in the PPU CTRL, so I can have the image patterns in bank 0 (first 4 Kb), and the text patterns in bank 1 (last 4Kb). The nametable would be 100% laid off before starting, with bank 0 configured as the background pattern table, then when the raster reaches the point where text start, I would switch to bank 1, so the data in the nametable would be rendered as text from there on.

tepples wrote:
na_th_an wrote:
¿Can I switch bits 3 & 4 from PPUCTRL in mid frame, via for example a sprite zero hit? that would allow me to have the image in the top two thirds of the screen, for example, and text/menus in the bottom.

Yes. A lot of title screens do this, such as those of RHDE and Haunted: Halloween '85.


Great. Thanks.

tepples wrote:
But in practice, 8-bit parallel flash memories larger than 4 Mbit (512 KiB, 32 UNROM banks) will be hard to find. You'll likely have to end up going with one or more of these: surface-mount packaging such as TSOP instead of DIP, level shifters to interface 3.3 V memory with a 5.0 V system, and a multiplexer for adapting a 16-bit flash (27C322 or equivalent) to an 8-bit data bus.


Didn't know that. Still, I think 4Mbit (512KB) will suffice for a mid-sized adventure if compression is used wisely.

lidnariq wrote:
Without designing a new mapper (which isn't hard, but is a different skill), I'd probably recommend either GNROM or Mapper 70 with-CHRRAM-instead-of-CHRROM.

A NINA-001 subset (no PRG-RAM, decode banking registers over a wider range), might be a sweet spot, too.


I will research those, too. Thanks.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 12:19 pm 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 601
Zlib to the rescue, you have so much time while displaying the current frame to decompress the next one.


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 1:46 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19334
Location: NE Indiana, USA (NTSC)
Decompress it to what RAM? The NES has only 2K, not nearly big enough for a whole pattern table, and both halves of the CHR RAM are occupied with displaying the current frame. Or did you mean large CHR RAM, which is very slow for LZ77-type methods such as zlib because it must be read or written only during vblank or forced blank, and unreliable to read on NTSC while using DMC? Or WRAM, where a third memory is expensive to install on the board?


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 2:05 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3968
Compression is good. Tokumaru made a compression program that beats 7-zip for NES tile data.
Then for text, you usually use DTE (dual-tile encoding), where one byte encodes multiple characters. The dictionary is usually generated by a program that scans your text and looks for the best pairs to use.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Thu Nov 10, 2016 2:29 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19334
Location: NE Indiana, USA (NTSC)
I imagine a pixel-oriented codec such as tokumaru's would tend to run slowly, on the order of maybe four tiles per frame. But it might be suitable for a large CHR RAM, as you could display a picture in one bank, decompress the next picture to the other, and copy four decompressed tiles to VRAM during vblank.

I made a DTE encoder in Python and decoder in assembly language for my robotfindskitten port. It and Huffword are static-dictionary text codecs that work well even with extremely limited RAM.


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 3:06 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3487
Location: Indianapolis
If you do want to consider a newer (but cheap/simple) mapper with 512kB, one of them is my own GTROM aka Cheapocabra. It has bankswitched CHR-RAM, and bankswitched nametables. It doesn't have WRAM, but it does have extra PPU memory at $3000-$3EFF that can be used without affecting any graphics. It does have some emulator support in FCEUX.
http://forums.nesdev.com/viewtopic.php?f=4&t=12716


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 4:51 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 601
tepples wrote:
Decompress it to what RAM? ...Or WRAM, where a third memory is expensive to install on the board?


To the 8kb WRAM. I don't think it's that expensive, got a number?

edit: INL's page would put the cost of one WRAM, without battery, at 1.35, including the work of soldering it.


Top
 Profile  
 
PostPosted: Fri Nov 11, 2016 5:05 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6509
Location: Seattle
So ... given that na_th_an explicitly is trying for something cheaper than MMC3 ... and that adding PRG RAM will increase the cost to manufacture by at least 33% ... you're advocate using zlib rather than a compression format that's actually designed for the paucity of RAM in the NES because ... you don't like by told you're wrong??

Zlib is explicitly a bad match for the NES. There already exist solutions that are good matches that don't compress tremendously worse.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 4 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:  
Powered by phpBB® Forum Software © phpBB Group