This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Pattern table address bits fiddling mid-frame

Pattern table address bits fiddling mid-frame
by on (#182632)
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?
Re: Pattern table address bits fiddling mid-frame
by on (#182633)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182634)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182635)
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).
Re: Pattern table address bits fiddling mid-frame
by on (#182637)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182639)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182640)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182642)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182649)
Zlib to the rescue, you have so much time while displaying the current frame to decompress the next one.
Re: Pattern table address bits fiddling mid-frame
by on (#182654)
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?
Re: Pattern table address bits fiddling mid-frame
by on (#182655)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182656)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182692)
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
Re: Pattern table address bits fiddling mid-frame
by on (#182693)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182694)
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.
Re: Pattern table address bits fiddling mid-frame
by on (#182695)
I was going to use a pattern compression scheme based on LZSS by tokumaru which works nice and is fast enough. I don't care leaving the user sit for a couple of seconds between scenes. [*]

Memblers wrote:
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


I will check that out too, thanks.

[*] BTW, the original compression routine by tokumaru was coded using WSH and was kind of slow. I ported it to freebasic, in case somebody is interested. A tad faster, and portable.
Re: Pattern table address bits fiddling mid-frame
by on (#182707)
lidnariq wrote:
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.


The cost difference between MMC3 and simpler mappers is far greater than the cost of WRAM, again according to INL. I have quoted my sources, you have not. According to what numbers is 1.35$ an increase of 33%? If that were true, you could get a board without RAM made for 4$, including the mapper and soldering work.

zlib has superior compression to any other compressor available on the NES, according to benchmarks I made and posted here. Using a less efficient one to save money is just fine, but you have not shown it would be a significant difference.

I do like being told I'm wrong, but I'm right in this case ;) Unless you can show me where I can get MMC1-level boards made for 4$.

edit: Corrected the cost, it's 4$.
Re: Pattern table address bits fiddling mid-frame
by on (#182710)
Cost of a SST39SF010 FLASH ROM in qty 100: $1.02
Cost of a IS62C256 5V SRAM in qty 100: $1.25
Cost of a 74HC161 in qty 100: $0.25
Cost of a 74HC20 in qty 100: $0.20
Cost of at ATTiny13 in qty 100: $0.90 (avrciczz)
Cost of a PCB made the cheapest way: $0.50/ , give or take, by panelizing three boards onto one 10x10cm producing thirty boards using one of the "ten 10x10cm boards for $10+shipping" deals

Cost of the now-deprecated XC9536XL: $1.54 per, now, but it's all new-old-stock, will run out before too much longer, and there's no volume discounts anymore. (MMC1 class)
Cost of the now-deprecated XC9572XL: ≈$3 per, same caveats. (two make MMC3 class)
Cost of a voltage clamp and 3V CPLD MAX3000A: ≈$3 per

Cost of hard gold plating on the card edge: $2 per (q.v. memblers)

You can do the math. I stand by $4 as a good proxy for a discrete logic boards that lacks PRG RAM.
Re: Pattern table address bits fiddling mid-frame
by on (#182713)
Thanks. Soldering everything yourself, for more than a couple boards is not something I'd do at least.

4$ vs 5.35$, on a board sold for 30-60$? The difference is insignificant to me, but you're right about the 33% increase.

FWIW, Aliexpress lists that SRAM, qty 100, for 0.64$.