Carts for New Games - NESdev BBS

Carts for New Games
by pigpen on 2010-11-03 (#69450)

I've been reading into a lot of cart hardware documents but it's hard to wrap my head around, especially since i'm thinking with a focus on newly made games whereas most documents are aimed at reproductions.

So say you wanted to make a game cart with as little donor parts as possible and as much resources as possible, what would be an ideal setup?

by MottZilla on 2010-11-03 (#69452)

Talk to RetroZone aka RetroUSB. If you mean that you designed and programmed a game yourself you wish to sell, they could help you bring it to market. If its something on a smaller scale, you can buy some PCBs and Cartridge Shells.

http://www.retrousb.com/index.php?cPath ... 8b34447cf0

by blargg on 2010-11-03 (#69453)

Retro Zone has PCBs, shells, and CIC clone, all new parts. Looks like about $12-$17 USD for everything except the EPROM/SRAM chips.

Re: Carts for New Games
by tepples on 2010-11-03 (#69456)

pigpen wrote:
So say you wanted to make a game cart with as little donor parts as possible and as much resources as possible, what would be an ideal setup?

SUROM is probably the most advanced mapper that can be replicated for sale without a donor cart. RetroZone has a board that can substitute for any common MMC1 board, including SUROM. But MMC1 doesn't have a scanline counter or a dedicated PRG bank slot for sampled sound playback, so you won't be able to do A. complex raster effects and sampled sound playback at once or B. lots of different samples (like a Sunsoft bass or Klax sound effects). These are generally considered MMC3 features; if you need them, and your game uses the same mapper configuration and ROM size as a game for which a reproduction guide exists, you can follow that guide.

by MottZilla on 2010-11-03 (#69459)

Or if you have RetroZone partner with you to produce the game I would bet that MMC3 could be used. Other mappers besides MMC1 are used in reproductions they sell.

by 3gengames on 2010-11-03 (#69460)

MottZilla wrote:
Or if you have RetroZone partner with you to produce the game I would bet that MMC3 could be used. Other mappers besides MMC1 are used in reproductions they sell.

So they have MMC3, Just no board available? -has a sad moment-

by Dwedit on 2010-11-03 (#69461)

The entire sunsoft DMC samples set for bass is only 5k in size, you'd just need less code in your fixed bank if you wanted to use those.

by MottZilla on 2010-11-04 (#69474)

65024U wrote:
MottZilla wrote:
Or if you have RetroZone partner with you to produce the game I would bet that MMC3 could be used. Other mappers besides MMC1 are used in reproductions they sell.

So they have MMC3, Just no board available? -has a sad moment-

There is no reason if you were going to produce a new game that you couldn't put a MMC3 clone mapper on a CPLD. Given that RetroZone created the PowerPAK, and reproductions that don't use standard mappers, I don't think MMC3 is an issue for them.

by 3gengames on 2010-11-04 (#69476)

True.

And yes, It's easier to order boards from RetroUSB and make nice carts without rewiring and such, so you can use them to save time and learn, then use donors that are easy to find/cheap/easy to find to make some other stuff to play around with. For NROM, I use just SMB, DH, Hockey carts. Easy to find, not expensive, PLENTIFUL, so I don't feel bad and they're going twords a good cause. As for MMC1, It's harder to find the right and cheap donor, so sometimes RetroUSB would be easier to obtain boards. (Like SXROM, No USA released game uses it)

Hope this info helps.

by pigpen on 2010-11-04 (#69484)

What about circuit chips?
You can certainly get much bigger ones then were available for most NES games along with new ones like FlashMemory.

by tepples on 2010-11-04 (#69485)

pigpen wrote:
What about circuit chips?

What do you mean by this? Google "circuit chips" doesn't help.

Quote:
You can certainly get much bigger ones then were available for most NES games along with new ones like FlashMemory.

Sure, there are bigger flash chips than the 29F040 used by SUROM, but they aren't always 5.0 V 8-bit parallel NOR flash like the 29F series. A lot of big flash chips are 3.3 V, or I2C serial, or block-organized NAND. To use serial or block memory effectively, you need a big PRG RAM. FDS (disk is serial) and PowerPak (CF is a block device) do this, but I have my doubts that a game can.

by pigpen on 2010-11-04 (#69486)

tepples wrote:
Sure, there are bigger flash chips than the 29F040 used by SUROM, but they aren't always 5.0 V 8-bit parallel NOR flash like the 29F series. A lot of big flash chips are 3.3 V, or I2C serial, or block-organized NAND. To use serial or block memory effectively, you need a big PRG RAM. FDS (disk is serial) and PowerPak (CF is a block device) do this, but I have my doubts that a game can.

Which is why i was asking in the first place what would be an ideal setup for a new game.

by 3gengames on 2010-11-04 (#69489)

pigpen wrote:
tepples wrote:
Sure, there are bigger flash chips than the 29F040 used by SUROM, but they aren't always 5.0 V 8-bit parallel NOR flash like the 29F series. A lot of big flash chips are 3.3 V, or I2C serial, or block-organized NAND. To use serial or block memory effectively, you need a big PRG RAM. FDS (disk is serial) and PowerPak (CF is a block device) do this, but I have my doubts that a game can.

Which is why i was asking in the first place what would be an ideal setup for a new game.

I'd worry about NROM first, with 32K program and 8K graphics. If your 1st game is over that, you might be getting a -tad- froggy.

And as for it, yeah it can be done, but you have to make/hack the hardware in and write games. I know I am making a 1MB SN2ROM (My name for it) for messing with a project next up in the future. It can be done, but sometimes is just better to get to this a lot later.

by Memblers on 2010-11-04 (#69491)

It depends on what the requirements are. There's not much of a limit to what you can put on an NES cart, but you'll have to define what you meant about resources.

Having an ideal setup, would require an ideal game for an example.

I had completed 4 NES board designs (the 3 oldest ones are pictured here), I have a couple more planned, one of them sooner, it's a pretty decent and should be pretty cheap. Here's the (planned) specs:

-PRG (FlashROM) $8000 and $C000 are banked independently, 512kB max.
-CHR-RAM Is banked, also twice independently, at $0800-$0FFF and $1800-$1FFF. the rest is fixed. (16 * 2kB)
-registers at $5000-$5007
-(optional) WRAM is banked (4 * 8kB)

The other one I'll be doing later (complete Squeedo redesign) will be pretty extreme in it's capabilities.. and will be more expensive, for it.

by pigpen on 2010-11-06 (#69565)

65024U wrote:
I'd worry about NROM first, with 32K program and 8K graphics. If your 1st game is over that, you might be getting a -tad- froggy. :o

I'm not sure what that means but im not asking about this stuff for my first game...im asking to keep my conceptual knowledge ahead of my technical knowledge so i know what direction to head in.

by 3gengames on 2010-11-06 (#69568)

pigpen wrote:
65024U wrote:
I'd worry about NROM first, with 32K program and 8K graphics. If your 1st game is over that, you might be getting a -tad- froggy.

I'm not sure what that means but im not asking about this stuff for my first game...im asking to keep my conceptual knowledge ahead of my technical knowledge so i know what direction to head in.

Well if you are making a game,. even if it's not your first, if it's your first on a NES, use NROM.

But anyway, yeah, the MMC1 repropak can make a lot of games work on it that are MMC1. Pretty much all of them, even MMC1 boards not used in the USA like SXROM. But the most commonly used mapper is MMC3 it seems, and that is not on a repropak yet, so for games like that, donors are needed and the one with the right hardware will be needed, since it can't be added like the repropak, which you add what you need to the MMC1 board.

by tokumaru on 2010-11-06 (#69581)

65024U wrote:
if it's your first on a NES, use NROM.

Personally, I do not a agree that everyone's first NES game has to be an NROM game. UNROM and CNROM for example are very decent mappers for beginners, as long as they understand the concept of bankswitching, since these are not as restrictive with the graphics.

I for example have never finished a NES game (yet), but I've done a lot of practicing and I know I can do a lot more than what NROM would allow me to, so my first game will most likely not be on an NROM board.

What you can't expect is that mappers do all the work for you. Using an MMC5 will not automatically make your game great if you can't think of interesting ways to use the mapper's features.

Also, using a mapper doesn't mean you have to make a big game and fill up 512KB of ROM, you could very well make a 32KB MMC3 game just because you're interested in its scanline counter. If you understand how the scanline counter works, it will actually be much easier to use it than go with NROM and have to monkey around with time code, sprite 0 hits and DPCM IRQs to achieve a similar effect.

by MottZilla on 2010-11-07 (#69597)

tokumaru is right. While I agree with the idea behind NROM first if you mean don't bite off more than you can chew, in practice for an actual game even if it is your first you should use whatever mapper you want.

Most people don't actually release their first NES programs as they are still learning and likely just making things to test out. They aren't yet making a full game. And tokumaru is right again that a mapper doesn't dictate if your game is fun or not. There are great games that use no mapper or very simple mappers like SMB1 and Castlevania/MegaMan. There are also pretty bad games, even horribly awful games that use very complicated mappers. Just see mapper 90 for some great examples of this.

by 3gengames on 2010-11-07 (#69604)

Heck no, NROM games (especially Mario) show that NROM is very flexible despite the size not being huge. I just really don't think that a mapper shouldn't really be used while your still learning so you can learn your way around other hardware first and make something playable within a small space, so then when you get the extra space, it's easier to cope with the fact you want from 16/32K to 256K and such.

by tokumaru on 2010-11-07 (#69640)

65024U wrote:
Heck no, NROM games (especially Mario) show that NROM is very flexible despite the size not being huge. I just really don't think that a mapper shouldn't really be used while your still learning so you can learn your way around other hardware first and make something playable within a small space, so then when you get the extra space, it's easier to cope with the fact you want from 16/32K to 256K and such.

tokumaru wrote:
Also, using a mapper doesn't mean you have to make a big game and fill up 512KB of ROM, you could very well make a 32KB MMC3 game just because you're interested in its scanline counter.

It seems you completely ignored my comments about space. Using a mapper isn't necessarily about getting more space... You might pick the MMC3 for its scanline counter, or UNROM so that you can use CHR-RAM in order to be able to animate your background tiles, and so on, but that doesn't mean you have to use more than 16/32KB. You are just allowed to, and that's a good thing.

Most absolute NES newbies do start with NROM programs, but like MottZilla said they never get released because they are not complete games, just tests used for learning. Also, just because a person just got started with the NES, that doesn't mean they are complete newbies to classic console programming. Some have already worked with other platforms, and already have a good understanding of bankswitching and other common aspects, they are just getting acquainted to the 6502 or the PPU, and there is no need for these people to hold back.

Another important point is that a smaller program is not always simpler than a large program. consider this: an uncompressed screen on the NES is 1KB large (32x32 tiles + 64 attribute bytes). If I'm a newbie and want to make a game with several (100 or so) screens, what would you say is easier: using UNROM to store all the uncompressed screens across the available banks or spending a lot of time understanding how compression works and coding compression and decompression algorithms? I'd say it's much easier to code a 3-line bankswitching function and use the uncompressed maps. I know this is a crude example, but it goes to show that smaller isn't always the same as simple.

by 3gengames on 2010-11-07 (#69642)

Yes, It isn't always about getting more space that's needed, but I mean, why use something with such a feature and abilities and not tap anything more complex at all then *just* that feature? It doesn't make sense to me kinda but oh well.....It's just kind of a "Waste of Resources" thing it seems to do such a thing.

Yeah, a MMC3 demo would be fine to test stuff and you have to do some to learn to use stuff like that. But to only make a 32K game not something with lots of levels and such seems almost like a waste IMO.

I hope we get a MMC3 cart on RetroUSB soon....that'd be epic.

by NESHomebrew on 2010-11-07 (#69643)

65024U wrote:
I hope we get a MMC3 cart on RetroUSB soon....that'd be epic.

If you want pics, I've got em

by 3gengames on 2010-11-07 (#69645)

Haha, nah. I think I'll just stare at the MMC1 board and act like it's the same thing.

by MottZilla on 2010-11-07 (#69647)

65024U wrote:
I just really don't think that a mapper shouldn't really be used while your still learning

The problem is that even developers of games, like Sivak, are still learning things. You probably never stop learning things. Honestly I don't see why mappers are such a big deal. I can agree to the point that if you never developed a NES game before you shouldn't grab MMC5 and start some crazy complex game using every feature it has. But using a mapper like MMC1 or UNROM or CNROM is perfectly reasonable. The concept of bank switching is not exactly that hard to grasp.

by tepples on 2010-11-07 (#69654)

tokumaru wrote:
consider this: an uncompressed screen on the NES is 1KB large (32x32 tiles + 64 attribute bytes). If I'm a newbie and want to make a game with several (100 or so) screens, what would you say is easier: using UNROM to store all the uncompressed screens across the available banks or spending a lot of time understanding how compression works and coding compression and decompression algorithms?

You'll need metatiling even if only to align game objects with the attribute grid. Most games' collision appears to be based on metatiles as well, apart from single-screen puzzle games such as LJ65.

As for using UNROM just for its CHR RAM: BNROM is the same thing, just with 32 KiB bankswitching so that you can forget about the bank register entirely on 32 KiB games.

by tokumaru on 2010-11-07 (#69658)

tepples wrote:
You'll need metatiling even if only to align game objects with the attribute grid.

I know that and you know that, but maybe the newbie that just learned how to use a name/attribute table editor doesn't, and if he wants to make a game with what he knows, he'll need more than 32KB or PRG-ROM.

But like I said, that was a crude example. The bottom line is that having more space can actually make things simpler some times, since you won't need to think of ways to cram a lot of data in the little space you've got.

I think that the reasoning most people use is that it's easier to generate 32KB of data than 128KB, and that might even be true if you are generating all your data with .db statements by hand, but once you use tools like map editors and music trackers you can generate a lot of data in no time, and it sure will be easier to spread that data across several program banks than invent crazy ways to compact the data and make it fit in 32KB.