Test ROM for TNROM/TQROM (MMC3) with 32KB CHR-RAM

In case anyone cares, I've created a test ROM for TNROM or TGROM boards that have been retrofitted with 32KB of CHR-RAM and rerouted to allow all 32KBs to be bank-selected. This configuration is also possible with the development boards that Infinite NES Lives is planning to release soon, and I intend to use in a homebrew project.

Currently the latest SVN version of Nintendulator's mapper pack supports this.

Note that an iNES 2.0 header must be used for the ROM to describe this configuration.

Link to Project Page

Cool! Good stuff. It seems to work fine in MoarNES.

Here's an another test for >8KB CHR-RAM with iNES2 (I modified my image converter to use CHR-RAM):

http://thefox.aspekt.fi/ines2-chr-ram-test.zip

Are you release the sourcecode?

No.

Finally getting around to testing this out on my boards. Trying to figure out if I'm getting the right output just to be sure of things here.


8 images? I'm only seeing something like 4. A boy, a girl, and some verbage inbetween the two. I'm guessing that's right though since emus show me the boy and cut up verbage and that's it. Correct?


thefox,

I tested yours out too, I'm wondering if you might not be waiting long enough before writing to the PPU? The image only loads up after reset for me (broke at power on) and when it's running there is some glitching. It looks better than an improperly configured emu though as I can actually see a single woman.

EDIT: I can provide images/video of any of the above upon request.

If you're talking about the 2 required PPU vblank waits, those should be there. As I remember it, the code should be the same as in my other CHR-ROM-based image conversions (except for the fact that these ones upload the tiles to CHR-RAM)... Of course it's possible that a bug or two crept in.

BTW it requires 64KB of CHR-RAM, maybe that's part of the problem?

Ahh... Didn't pay that much attention, that would probably help. Although I've found 3 vblank waits to be better practice depending how you count them. $2002 is unknown at startup so you have to toss out the 'first' one and then wait for two frames. Some would count that as 3 vblanks. Since I get nothing on power up and glitching on reset I'm guessing something like that might be going on too.

Most people read $2002 (and throw out the result) before the 2 wait loops. I wouldn't say that counts as waiting 3 frames, since the first $2002 read isn't doing any waiting... =) I too in the past have waited more than 2 frames just to be sure, but I guess that 2 frames already provide more than enough breathing room, since last time I checked the PPU needed only 1 frame or so to become stable.

Maybe my PPU is just slow and cranky, but 1 frame is certainly not enough for me. I'd say around half the homebrew roms I test out on my NES suffer from this issue... Powerpak hides this issue.

I based my comment on quietust's post about the visual 2C02 and this wiki page (both say the PPU needs about 1 frame to start functioning properly). I imagine that waiting a single frame in software might be too tight and might cause problems in some cases, which is precisely why 2 frames appears to be perfectly safe. I'm not suggesting that anyone waits less than 2 frames, but more than that shouldn't be necessary either.

Also, the code you linked to isn't properly waiting 1 frame, as the VBlank flag could be set right on the first read and there'd be no waiting at all... the correct way to wait for *at least* 1 frame is this:

But like I said, I wouldn't recommend waiting only 1 frame even if it works (I haven't personally tried!), 2 frames is safer.

EDIT: If you look at that wiki page, it's clear why waiting only 1 frame isn't enough: it seems that the Vblank flag is usually clear on power up (apparently there are exceptions), and gets set around cycle 27384, while the PPU is not fully functional until cycle 29658.

I noticed the code (probably copy&pasted somewhere...) doesn't make sure the flag is cleared before the wait loops, so try this one with 3 wait loops if it makes a difference for the power-on behaviour: http://thefox.aspekt.fi/ines2-chr-ram-t ... -waits.nes

The only "digital" thing that necessitates waiting is that there's an internal reset signal active before the point where the VBlank, sprite zero, and overflow flags are cleared (it's driven from a reg that's cleared by the same signal as those) - see http://wiki.nesdev.com/w/index.php/PPU_power_up_state . If additional waiting is needed, then that would have to come down to analog effects I think. Seems weird that it would take that long to settle though...

I print a warning in my emu when regs are written during the reset period. You see lots of commercial games doing it (though they still work), so I suspect it wasn't widely known how it worked even back then. Emulating the write suppression does break some demos though (like the NY2011 one, which will still work on powerpak though since it starts running after the first frame there).

I guess the reason you're seeing it in commercial games is that they are zeroing out $2000 and $2001 in their init code, which seemed to be the "standard" thing to do, regardless of whether it had any effect or not.

Also remember that on Famicom the reset switch isn't connected to the PPU, so there these writes are significant!

Out of curiosity, I checked couple of first-party games to see how they do their initialization:

- Duck Hunt waits for vblank once, then zeroes $2000 and $2001
- Excitebike first zeroes out $2000, then waits for vblank twice
- Pinball waits for vblank once, then zeroes $2000 and $2001
- Soccer zeroes out $2000 and $2001, then waits for vblank once
- SMB writes $10 to $2000, then waits for vblank twice
- SMB3 zeroes $2001, writes $08 to $2000, then waits for vblank twice

Ah, yeah, had forgotten about that.

Unless I'm mistaken.... this also isn't guaranteed to wait at least 1 frame. This only waits until the first VBlank is detected... so if it starts up like 4 scanlines before VBlank, then this will only wait 4 scanlines.

AFAIK, you need to have 2 full polling loops:




I'm not sure if this matters on a NES, as the startup time might be fixed so that it always starts up in vblank... but on the Famicom I think startup time is random.

Well spotted, my mistake!


This seems to be the most logical way. In fact, what we're doing here is waiting for 2 VBlanks, not 2 frames (which I believe is the source of confusion). According to the wiki, when the first VBlank happens the PPU isn't ready for use yet, so it's only logical that we wait for the next one.

That's cool!

Wonder if this is practical for mass production but man I'd love to have that much VRAM (much less any VRAM at all, ha) to work with. Can 2kb be allocated for 2 extra nametables? (I'll hazard a guess that it doesn't work that way.)

Very good point, I actually never thought about this!

But, in your "fixed" code, what if...
1) an NES system is reset during vblank (so the vblank flag is currently TRUE)
2) thus the first loop exits immediately
3) in the 2nd loop, since we're in the middle of vblank, it'll take less than 262 scanlines to reach the next vblank, so the total wait time could be less than the required 29658 CPU cycles

Note that according to http://wiki.nesdev.com/w/index.php/PPU_power_up_state on NES the PPU vblank flag stays unchanged on PPU reset.

So it seems to me that the extra "bit $2002" before the two polling loops is required.

EDIT: Moreover, since the PPU will always come out of reset at scanline 0, the 2nd loop will always wait for approximately 241 scanlines if the vblank flag was TRUE before reset was triggered.

Another very good point! So I guess that the minimum wait that's still safe consists in a BIT $2002 command followed by 2 waits for VBlank, which coincidentally is what I have been using in my programs, without giving much thought to it.

This is exactly what I've found to be true on my NES as well. The code I linked to had a second vblank wait at the end. So I was running with to waits and no initial BIT $2002 initially. Things were always garbled at power on, but okay after reset. I resolved the issue initially by adding another wait, but was then able to replace it with the BIT $2002 before the first loop.

thefox, I tested you original rom out again and wasn't able to steadily replicate the original issue I was seeing the day before. I wanted to re-verify what I had seen before testing the new rom. The day I saw issues my NES had been running for several hours, so I'm curious if having the PPU all warmed up might have attributed to the consistency of failing initially. I'll try to remember to try again after I've been running my NES for awhile.



It's plenty practical. I'm producing boards right now that have 32KB of CHR-RAM. The second version of my boards is actually just finished being fabricated and it supports 32KB and 128KB CHR-RAM options, those will be in production shortly. As for extra nametables, that's actually possible too. Although to simplify things a little I'd probably just put all 4 NT's in the cart's CHR-RAM and just disable NES's CIRAM (aka VRAM). You wouldn't necessarily have to make it a non-standard mapper either in regards to emulation. You could emulate it as MMC3 presumably with 4screen mirroring, and 128KB of CHR-RAM. In practice though, you'd have to consider the last (or first) 4KB as off limits for pattern table data. You could do the same thing with 32KB of CHR-RAM also (4KB NT, 28KB PT).

You could even go as far as to bank switch the Nametables by adding nametable select registers to the mapper. That's a little extreme though, but entirely possible without much hassle in hardware. Emulating it would be a different story, but all you have to do to gain mapper support a from a few emulators is build a game or good demo for it. "If you build it, they will come."

But then you have to know how to program an emulator to add support for your game's mapper in the first place.

Coming from the guy who wrote a test rom for a mapper that didn't yet exist in emus nor hardware? Which then promptly gained support in emus, powerpak, and production carts? I think you single handedly proved my point with the multi-discrete mapper.

My 'build it' implied easily programmable hardware that would allow you to get by without an emu. At least to the point of a functioning demo. It would still be drastically better than the multiple eprom method that our favorite licensed games were developed with. Personally I prefer testing each build on the real hardware anyways, the only thing I appreciate emus for is debugging video with PT/NT viewers.

There is also a Sprite viewer on BizHawk, Nintendulator, and a couple other emulators!

BTW yeah, 8K CHR-RAM is still pretty ok, but more CHR-RAM to me makes animation easier!!!

With SRAM prices today 8KB SRAMs is effectively a thing of the past, as 32KB SRAM is cheaper and more readily available. If you're intending to put your project on hardware the only 'cost' difference between 8KB and 32KB of SRAM is the logic needed to bankswitch the extra RAM in.

That's True, since 8k can be more expensive nowadays, and having more RAM makes it so that availibility of memory space truly improve coding for systems like this, other programs requiring RAM expansion such as a couple of VS unisystem games (of which also sometimes comes with 2 2a03 CPUs according to the wiki) prove to be an example of bankswitching RAM