The game being made for testing the cartridge is here: http://nocash.emubase.de/magicflr.htm - the NES version of the Magic Floor game that I've also ported to a bunch of other systems. It's a simple search game, somewhere between addictive and annoying. The binary is only 4Kbytes, and the CHR graphics are nicely fitting into 1Kbyte (the unused half of the 2K name table memory). The current version works both on the above cartridge, as well as normal NROM game (with 8K CHR-RAM instead of the name table RAM), so you can also test it with existing hardware or emulators.
The jumper is allowing to strap the VA10 name table address signal to PPU address lines A10, A11, A12, or A13. Which may all have some benefits. A10 and A11 would be the normal Vertical/Horizontal mirroring - that may be useful when using both Name Tables (where one would need to squeeze CHR data into unused NT locations), and may be also useful for using the whole 2K as OBJ memory (without using the BG layer). A12 would be One-screen BLK0 (with both BLK0 and BLK1 mapped as CHR-RAM). And A13 would be the most common case: One-screen BLK1 (with only BLK0 mapped as CHR-RAM).
Ah, and the name table chip select is simply this: /VCS wired to GND (so the 2K RAM is always selected).
EDIT (27 sep 2012): The corresponding mapper is now defined here: http://wiki.nesdev.com/w/index.php/INES_Mapper_218
The next question is how to emulate this. The obvious signal for this would be an NES 2.0 header with zero CHR ROM and zero CHR RAM, but that leaves what sort of mirroring to choose. Can't A12 already do everything A13 does, plus the ability to enable rendering late or disable it early to add a few more tiles?
For the VA10 mapping, UNIF can define all four modes (Two-Screen H/V and Single-Screen BLK0/BLK1). The normal NES format can define only Two-Screen H/V... I was thinking of using the "Four Screen" flag here. Like so:
Code: Select all
VA10 Effect on iNES Byte 6 UNIF "MIRR" to Name Tables Bit3.Bit0 Bit7-0 PPU.A10 Two-Screen, Vertical Mirroring 0.1 01h PPU.A11 Two-Screen, Horizontal Mirroring 0.0 00h PPU.A12 One-Screen, BLK0 1.0 02h PPU.A13 One-Screen, BLK1 1.1 03h
A bit messy, but it's the best solution I could think of.
Hmmm, now that you say it, A12 could in fact do anything that A13 can do.
Having the ability to define both A12 and A13 would be nice because A13 is a bit "straighter" than A12 (having the memory more clearly divided into NT and CHR-RAM). Oh, and with A13 the CHR-RAM is mapped to 0000h - with address LSB and MSB both 00h - that can save two "valuable" bytes of program code. That's maybe not too much saved memory, but the mapper might be a nice platform for people trying to squeeze as much of code into as less memory as possible. So other people might prefer A13, too.
No, that one allows to select BLK0 or BLK1 via the mapper (by software).
In this case, it's a "hardwired" selection, needs to be stored somewhere in the ROM image header.
I was actually going to make a game for this configuration, and to make it as "normal" as possible, that is it shouldn't have crappy graphics that would make the player immediately think "oh this game is ugly because it has only a single chip".
I won't tell more because it's trade secret
PS : Oh and I emulated it using mapper 0 simply, I just made sure to restrict myself to a single nametable and 64 tiles, which is pretty simple to do. Of course if I would rely on mirroring of tiles, it would break the emulation, but obviously I would not want to do this !
Looks like NES 2.0 doesn't let you explicitly specify single screen mirroring in the header. Did anyone ever decide on a mapper number for this?
If nobody else decides, I'd say make it NES 2.0 submapper of mapper #7, so old emulators can still play it.
An unmodified mapper 7 ROM should work on this board as long as the limitations are respected, since the write to $8000-$FFFF necessary for selecting mirroring would be ignored. 32KB of ROM would be tough for a platformer though, because of all the level maps and such. I wouldn't mind adding a 74161 in order to have access to a few more pages of ROM (and mapper 7 could still be used).
- Posts: 2100
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
I like your "brute force" method of making your own 72 pin connector
Games doesn't have to be platformers, you know ?So... 64 tiles for sprites AND background. I wonder what kind of platformer I could make with this.
And don't worry I'll release an awesome game that requires a single chip someday, just leave me some time. It will look almost as good as any other NES game, as you say thank to heavy CHR updates.
But this is the kind of game I want to use to put this scheme to the test... problem?Bregalad wrote:Games doesn't have to be platformers, you know ?
I believe games can easily look just like early NES games, and even somewhat better, but making them look like, say, Kirby's Adventure is surely not possible.It will look almost as good as any other NES game, as you say thank to heavy CHR updates.
This...(Stripped down, of course...My logo "Red moon games" is taking a lot of space...Text too, is not really needed.)tokumaru wrote:So... 64 tiles for sprites AND background. I wonder what kind of platformer I could make with this.
32kb is NROM size, right...? Well, Inversion have over 30 levels. The 64 tiles limit is a small problem. I might convert Inversion if there's any compo for this chip programming.32KB of ROM would be tough for a platformer though, because of all the level maps and such. I wouldn't mind adding a 74161 in order to have access to a few more pages of ROM (and mapper 7 could still be used).
(And then release normal version as "extended" version...neat!)
Yea, me too. If there will be any compo, of course.Seconded! I'd surely do my best to participate.
The project itself is nice thing. Forces us to have even more limitations than NROM.
Call me crazy, but for some weird reason, I like it.