Here's something that I wanted to do since I first dealt with the NES in 2004. A single-chip cartridge. It can address max 32Kbytes PRG-ROM, and uses the internal 2Kbyte Name-Table RAM as CHR-RAM. The idea is also mentioned on the nesdev wiki, but as far as I know nobody has ever implemented it for real. So this should be the first ever working & totally handmade prototype cartridge:

Attachment:

NocashSingleChipComponentSide.jpg [ 30.58 KiB | Viewed 14734 times ]

Attachment:

NocashSingleChipSolderSide.jpg [ 35.87 KiB | Viewed 14734 times ]

The handcut edge connector with copper contacts isn't perfectly plan, and gold contacts might also help making it more reliable. As it's now, it is working only when pushing the cartridge around until all pins are having good contact. The other two things I've learned are that the pins must have 2.50mm pitch (2.54mm won't work), and that the PCB should be only 1.2mm thick (the proto is 1.5mm, inserting it - and especially removing it - works only with extreme force; like needing to use a pair of pliers to get it pulled back out of the NES).

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).

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:

That would be of course only working if it's having it's own mapper number. When assigning it as "Mapper 0" then Bit3 would mean "NROM with Four-Screen". Otherwise, with the own mapper number, it's pretty clear that the board cannot have memory for Four-Screen, so one could misuse the bit as "One-Screen" flag in that case.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.

Last edited by nocash on Mon Sep 24, 2012 11:17 am, edited 1 time in total.

It's cool someone eventually build a board that does this. I was actually going to make a board that does exactly this as well but with something slightly different - I was going to allow vertical and horizontal mirroring as usual exept the second nametable would be hardwired as blank - the internal chip disabled, and pull-down resistors to ensure the lines are at GND. This would allow to use one namtable normally + one blank nametable, and to have 64 tiles plus a blank tile.

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 !

I was suggesting that you use Mapper 7 for testing on many emulators, because you get CHR-RAM and single screen mirroring. Specifying Mapper 7 is the most direct way to request single screen mirroring for simple roms on any emulator. As long as you don't actually try to use the extra hardware features (like the remaining 6k of CHR RAM, and second nametable), it would run just the same as a mapper that restricts them.

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.

So... 64 tiles for sprites AND background. I wonder what kind of platformer I could make with this. I guess that with heavy CHR updating it wouldn't look so dull, just "minimalist". Flipping would surely help make the most out of the sprites, and the background patterns could gradually change as the player progresses through the level. Palette swaps could also add some more diversity to the graphics. Suddenly I feel like making a mock-up according to these limitations!

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).

Historically, a lot of old NROM games which don't use many tiles at the same time could easily have used a configuration like this if the idea would have ocurred to people. I imagine one 32kB ROM would be cheaper than 16kB+8kB back in the days, so that might have saved manufacturing costs slightly? Then again, it might not have mattered much compared to all other costs involved in making cartridge based games... especially in the NES market where the CIC was the biggest PITA...

So... 64 tiles for sprites AND background. I wonder what kind of platformer I could make with this.

This...(Stripped down, of course...My logo "Red moon games" is taking a lot of space...Text too, is not really needed.)

Quote:

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).

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.(And then release normal version as "extended" version...neat!)

Quote:

Seconded! I'd surely do my best to participate.

Yea, me too. If there will be any compo, of course.

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.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum