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

Using $4020-5FFF

Using $4020-5FFF
by on (#16831)
I know that the disk system takes advantage of the $4020-5FFF address range for its system bios and registers, but I was wondering if there were any actual games which used this for anything? From what I can tell, all the better-known mappers stick into the $8000+ range, though I could be mistaken. CopyNES for example uses an even lower range to prevent conflict, but that'd require more hardware modification to get into than I had in mind.

I ask because I'd like to have some space for registers/ram/rom of my own, seperate from the games usual address space so that they (hopefully) won't interfere with it.

by on (#16832)
Namco106 and MMC5 are in that range (at least, probably some others too). My own Squeedo mapper uses $5xxx.

by on (#16834)
I'm unsure about this, but the cart can "watch" ALL writes in the whole NES memory aera, including existing RAM, CPU and APU registers. It is just a bit easier to stuck in $8000-$ffff because of the PRG /CE signal is set low automatically by the NES hardware when anything is read/written in the range $8000-$ffff, so that the cartridge doesn't have to do anything special.
Most places below $5000 contains either used memory space or mirrors of already taken memory space, so all cart have only $5000-$ffff left to do what they want. I think any card could "watch" PPU or APU writes and behave itself in function of them. I've heard the MMC5 does that.

Now I'm not exactly sure how does cart do watch writes and decode them.

by on (#16837)
Ah right, I forgot to check MMC5, since not many games ever used it. I also remembered that big list of mapper info in the NES Specifications page and skimmed over that, and while there's a few other small-time ones which don't matter, it seems MMC5 and Namco106 are the only ones to worry about.

I planned to "detect" real cartridges anyway, so I can probably alter that aspect to actually disable my additions to the system entirely upon detection of one.

Bregalad wrote:
Now I'm not exactly sure how does cart do watch writes and decode them.

My initial plan was to actually do all this decoding from the cartridge connection, which I figured was possible by starting out using an LS139, similar to how the NES itself does it, except in this case, using /CE instead of an A15 line would result in the output being swapped. $8000-FFFF should be active when the clock is high and /CE is low, and $0000-7FFF should be active when clock is high and /CE is high.

Decoding down to 8k segments would require the other half of the LS139 (also like how the NES does it AFAIK), and then decoding down more precisely than that is going to require a bit more complexity, especially to filter out NES registers at $4000-4020, and also provide gaps for my own registers. But I've gotten logic figured to have a memory map along the lines of:

$4000-41FF = NES registers (much space being wasted, but saves from using more decoding logic)
$4200-43FF = My registers (again, more wasted space)
$4400-45FF = Other registers or ram
$4600-47FF = ram
$4800-5FFF = rom

Normally I'd just try to use $5000-5FFF since it's simpler to decode, but I realized that I need to store some font tiles and such in with the code, and need to squeeze in as much space as possible. And if necessary, I can break those 512 byte pieces down a little further if I need many registers, but I think one or two will do it.

This may have been answered elsewhere, but did anyone ever figure out an accurate method for detecting a reset of the console?

by on (#16838)
The only limitation you have is the number of 74 circuits you want to use.
By using adress decoders (74xx39 for example) and various gates you may come to anything you want.