Cart sizes

[+Karl G]

I've noticed that a lot of devs seem to work very hard to avoid going over 48K for their projects. I was wondering if that was a matter of principle, wanting to avoid bankswitching, or something related to the cost of producing carts that are larger than 48K?

 

For the last point, how much of a difference does the size of the ROM matter in terms of cost and practicality of producing carts?

[+Mitch]

Nowadays the price difference is fairly minimal. Adding a sound chip is a different story.

 

Mitch

[+Muddyfunster]

My early efforts were definitely about avoiding bank switching and all of the perceived (incorrectly it would turn out) voodoo that went with it. Most of my more recent projects would really be 48K or 128k bank switched. E.X.O. being the exception due to what I want to do with the game.

 

Danger Zone stayed at 48kb due to how I'd structured the 160B sprites, lots graphic blocks in one place helped with that. It was early in my learning of 7800 and 7800 Basic, looking back I'd maybe make some different design choices based on what I know now. I think bank switching that original design would have been really complex due to the number of combinations of player aircraft and I'm not sure it would have worked how I wanted it to.

 

As Mitch says, the cost difference between 48k, 128k or even 512k is really pennies. I think Al told me that 256k or 512k need an extra widget or 2 but again it's a few pennies in the scheme of things.

 

 

[BydoEmpire]

I can't speak for others, but for my first game I have two reasons to not go over 48k. 1) it forces me to make choices, finish the game, and not just keep adding stuff because I can and 2) there is plenty to learn and get working within that limit.  That said it is actually fun to have to find places to optimize the code and save a few bytes so I can add something.  It's not really working hard to stay within 48k... it's harder to have endless space and actually finish something!  Future projects will certainly be bigger.

[Revontuli]

So much of it is structuring the game's code, and the fact you go from having 48K ROM *all* the time to 32K of ROM *some* of the time.  If you plan ahead to use multiple banks, it's generally not a big deal, but adjusting your game to go from 48K to 49K can be a major headache.  Accessing graphical blocks, as Muddyfunster pointed out, can play a lot into this as you have to deal with extra space taken by DMA holes and the like, and being able to access any graphic you want at any time will probably be the first thing you'll miss going multi-bank.  

 

12 hours ago, BydoEmpire said:

1) it forces me to make choices, finish the game, and not just keep adding stuff because I can

...

it's harder to have endless space and actually finish something!  Future projects will certainly be bigger.

...and this.  A hundred times this.  One of the reasons I'm doing the series of games the way I am is to finish them - I've learned a lot about how to *start* a game, but I need a lot more practice on the trickier aspects of *finishing* them.  Polishing, testing, printing, publishing all take time, effort, and a learning curve, and getting a game to that point is something I've been able to do and have a lot of fun with on the 7800 (and 2600). 

 

As for my current project and going multi-bank, Dragon's Havoc is riding that knife edge - I feel like I've gotten 90% of the features I wanted with about a kilobyte of ROM remaining, and while I kinda wish I had another 5k or so to play with, doubling/tripling/quadrupling the ROM space would tempt me with features and a change of scope, that, while potentially cool, could very well mean I'd just never finish it.

 

I do have some ideas on how I'd structure and take advantage of a larger ROM structure, especially with what I've learned from my previous games (I'm already sketching out a project to follow Dragon's Havoc) but 48K is keeping me honest right now  

[BydoEmpire]

I've learned that with songwriting as well.  Everyone has a hard drive full of cool riffs.  Being able to take those riffs, turn them into an actual and complete song, iterate on it, tweak it, polish it, rewrite bits, and finish it.  That's the art and craft of songwriting. Ideas are a dime a dozen, in games and music and pretty much any creative endeavor.  The process of finishing a work teaches you the process.

 

I must say, the last month of "rewrite something to free up 20 bytes so I can add one additional bit of code" has been much more fun than I thought it would be. It's like a treasure hunt - where are the potential optimizations?  Plus, I'm learning a bit about which operations in 7800basic translate to more or less expensive code.

 

+1 to @Revontuli's comment about refactoring after the fact.  When I explore bank switching, it'll be from the ground up with a relatively simple project that's more focused on that.  Learn the system, get it working, and then build on a solid and simple base; rather than have to go retest and/or rewrite a bunch of things that were already working.

Edited April 4, 2021 by BydoEmpire

[Shawn]

The difference in cost for the eprom is a non-issue BUT you do need to add a PLD to the mix to control the bankswitching. They are only a couple bucks each but they do add to the production cost and time it takes to build each cart as that is another chip to solder in place. You also then need more resistors, those are only pennies but add 2 more solder points for each one required. 128k you are looking at 3x 3.3k resistors and a 1.uf capacitor.  48k game you only need a 7402 and a .1uf cap on top of the 27512 eprom. 

[+Pat Brady]

The entire point of developing for any old platform is to see what you can do with certain constraints. Cartridge capability is one of them.

 

IMO a large ROM makes sense for something like E.X.O., whereas for 7ix — which does now use cart RAM, necessary to push this game beyond the resolution shown in the old demo, but already a luxury that BITD might not have been granted to a port of a moderately-popular arcade game from 1981 — bankswitching would feel extravagant.

 

I guess that counts as "matter of principle."

 

Just to be clear: I am not criticizing or second-guessing anybody else's choices. Filling up a large ROM is a valid choice, just not the only valid choice.

[+Karl G]

39 minutes ago, Pat Brady said:

Just to be clear: I am not criticizing or second-guessing anybody else's choices. Filling up a large ROM is a valid choice, just not the only valid choice.

Certainly. I should also make clear that I'm not doing so, either. I was curious about the motivations for the individual devs here. I was asking because I was weighing the pros and cons of a larger ROM size for Space Peril.