It is currently Wed Sep 26, 2018 2:01 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 95 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next
Author Message
 Post subject: Single Chip Cartridge
PostPosted: Mon Sep 24, 2012 10:31 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 633
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
NocashSingleChipComponentSide.jpg [ 30.58 KiB | Viewed 11007 times ]

Attachment:
NocashSingleChipSolderSide.jpg
NocashSingleChipSolderSide.jpg [ 35.87 KiB | Viewed 11007 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).

EDIT (27 sep 2012): The corresponding mapper is now defined here: http://wiki.nesdev.com/w/index.php/INES_Mapper_218


Last edited by nocash on Thu Sep 27, 2012 11:32 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 10:40 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20574
Location: NE Indiana, USA (NTSC)
I'm glad to see someone finally building this.

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?


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 11:13 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 633
Getting an own mapper number for it would be coolest :-)

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

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.

Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 11:14 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4079
Mapper 7

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 11:22 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 633
Mapper 7... like AOROM?
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.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 11:51 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7524
Location: Chexbres, VD, Switzerland
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 !


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 11:54 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4079
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.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 12:09 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10819
Location: Rio de Janeiro - Brazil
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).


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 12:21 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
Cool stuff. I think it would be great configuration for a coding compo.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 12:36 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2083
Location: WhereverIparkIt, USA
Very cool!

I like your "brute force" method of making your own 72 pin connector ;)

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 12:47 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7524
Location: Chexbres, VD, Switzerland
Quote:
So... 64 tiles for sprites AND background. I wonder what kind of platformer I could make with this.

Games doesn't have to be platformers, you know ?

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.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 1:11 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10819
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Games doesn't have to be platformers, you know ?

But this is the kind of game I want to use to put this scheme to the test... problem?

Quote:
It will look almost as good as any other NES game, as you say thank to heavy CHR updates.

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.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 1:12 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10819
Location: Rio de Janeiro - Brazil
Shiru wrote:
Cool stuff. I think it would be great configuration for a coding compo.

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


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 1:21 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 410
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...


Top
 Profile  
 
PostPosted: Mon Sep 24, 2012 1:29 pm 
Offline

Joined: Wed Feb 17, 2010 5:42 pm
Posts: 383
tokumaru wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 95 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group