2600 in 2006

Hi there!

 

How do people decide what size cart to shoot for, and how to choose between cutting back on a game or going to a larger cart?

 

That's a very interesting question. Things to consider:

 

From a commercial point of view, 4K are still $5 cheaper than "more". Also the mini game contest is demanding a limit of 4K. Also once you go for bankswitched, the overhead doesn't make that much a difference between 8/16/32K, so to sum it up, it comes down to a decission between

 

4K or more

 

I think it's always case by case. I can only give examples of my own projects:

 

Gunfight was simply done at the time with 3.5K.

 

With Star Fire I already had 2 different 4K binaries, one with the game, one with the intro, so 8K was the easy way to combine both. Also, this way I could easily reserve some 3K for Pauls music.

 

Seawolf was start to finish targetted as a 4K submission for the mini game contest and it just fit.

 

Crazy Balloon was almost the same, only I was prepared to go to 8K in case I couldn't fit everything in. But when I managed to squeeze some nice music, a title screen, an end screen, all arcade levels and more into 4K, it was done for me.

 

Colony 7, was again started as 4K contest entry, I'm again prepared to go to 8K, only this time I'm certain that the final game won't fit. There's no SFX code, no music in yet and I'm down to 2 pages of ROM. So there'll hopefully be a working contest snapshot without music or title screen, and an 8K store version later.

 

Regarding Strat-O-Gems, I personally would've kept it at 4K. It seemed complete, polished and charming that way and I'm not sure if $5 extra are really justified for the difference of the two versions. Especially having PAL/NTSC in one binary seems to be an unnecessary overkill gimmick. I wouldn't know anyone *needing* both versions of a game

 

For the worm game, I personally think 1K ROM for 2 bytes of RAM is an unacceptable compromise, if that helps your descission any

 

Greetings,

Manuel

Unless you want to compete in the Minigame contest, just go for the size the game may need.

 

Even Thrust started as a 4K binary, later became 8K and finally I needed ~12k, so I made it 16k. I had to reorganize some code regularily (especially in the non-kernel banks), but that was never a really big problem.

 

IMO more important is, if you want to use (or need) extra RAM. That's something which should be decided pretty early.

All the games I've written so far have started out as 4K games and then were switched, if they were switched, as more room became necessary.

 

Cutting back on a game is something you really shouldn't do, I think. Though I do agree, to some extent, with Manuel's thoughts regarding SOG. PAL+NTSC is probably overkill, though accomodating multiple TV standards on a single cart seemed to be all the rage. Heck, M-4 is switchable as well. If I had to do it again, though, I would change that.

 

Anyway...

 

Running Man (unfinished demo) was targetted for 4K and when it became apparent that it wouldn't fit I abandoned the project.

Go Fish! was also targetted for 4K; the 2nd bank was added pretty much solely for the music and the title screen.

M-4 was targetted for 1K, but after writing a 2.5K binary I found myself unwilling to make the necessary cuts to get it down to 1K, so I added the title screen and some other small enhancements and it ended up at around 3.5K.

Reindeer Rescue was an expansion/modification of Running Man; I knew from the start that it would be more than 4K, I was thinking 8K or 12K. It ended up needing 16K.

 

Sheesh, after reviewing, it looks like I need to take my initial estimate of ROM size and double it.

Regarding Strat-O-Gems, I personally would've kept it at 4K. It seemed complete, polished and charming that way and I'm not sure if $5 extra are really justified for the difference of the two versions. Especially having PAL/NTSC in one binary seems to be an unnecessary overkill gimmick. I wouldn't know anyone *needing* both versions of a game

 

Dual-system capability alone would not have justified going from a 4K cart to something bigger. Even the speech would not have. The thing that pushed Strat-O-Gems over 4K was the Atarivox/Memcard "instant replay" and the saving of great plays. I would agree that for people without an Atarivox or Memcard there isn't much new to justify the extra $5 cost, but I wanted to do something that would help make the Atarivox/Memcard a "must-have" and there was no way that was going to fit in a 4K cart. If I'd offered a 4K cart for people who don't have an AtariVox/Memcard today, they wouldn't be able to use those things if they got them later.

 

Since a 32K cart was the same price as 8K, I figured I may as well use the space to maximum advantage; since Albert indicated it would be easier for him to deal with one .bin than two, I included both PAL and NTSC versions in the same cart.

 

FYI, a rough breakdown of SOG memory usage in bank order

 

2x4K -- Main game kernel (PAL/NTSC) and AtariVox code

2x4K -- Main game (PAL/NTSC)

2x4K -- Title screen/instant replay/Great play kernel (PAL/NTSC)

4K -- Original Strat-O-Gems

4K -- Atarivox speech data (about 1K, common to PAL/NTSC) and Boot Menu

 

PS --Although the SOG info page doesn't mention it, the 32K cart includes the original 4K version. Hold fire on startup to bring up the game menu, then push and hold fire while pulling down.

 

PPS -- The instant replay and record-play-saves function really is neat. I highly recommend that anyone with Strat-O-Gems at least spend the $10 for a Memcard. Having great plays recorded really adds a new dimension to the game.

I agree that the Memcard stuff was worth pushing it over 4K.

Hi there!

 

I agree that the Memcard stuff was worth pushing it over 4K.

 

Definitely!

 

Greetings,

Manuel

For the worm game, I personally think 1K ROM for 2 bytes of RAM is an unacceptable compromise, if that helps your descission any

 

Before making a tradeoff like that, it's often necessary to ascertain (1) whether the memory is really saved, or whether another 'critical depth' still needs it at a different time in program execution; (2) whether there aren't already another couple spare bytes available.

 

Unrolling loops often not only saves loop overhead, including the memory required for a loop counter, but it also often allows other useful things to be done. For example, in Strat-O-Gems, the scan lines within a row of gems are not looped, because I compute the colors differently on different rows. The top three rows of gems are in a 3-high loop, and I might have been able to figure a way to loop the scan lines within each row, EXCEPT that I use some of my spare cycles during each row to precompute the colors for the fourth row of gems (note that this computation ends up getting done three times when it only needs to happen once, but the cycles exist so that's harmless). When I added the remaining-gems counter to Strat-O-Gems deluxe, I added another unrolled version of that loop. I could perhaps have used the same loop as I'd been using for all three of the top rows, but I needed some of the 'spare' cycles that precomputed the row 3 colors to instead generate and show the gem counter. Had I been trying to squish things into 8K, I could probably have figured out how to get everything in the one loop, but I was in a rush.

 

Incidentally, in Strat-O-Gems, the 'next gem' indicator sprite is positioned to the right of the central area. In Strat-O-Gems deluxe, it's to the left but I use 'two copies wide' mode. On the row where the level indicator is shown, the sprite appears in front of the playfield. On the other rows, it shows an extra copy of the 'next' gem but is covered up by the playfield.

 

To be sure, sometimes even when the first few iterations of a loop need to be unrolled, it can be useful to loop the rest but sometimes it may be cleaner to just unroll the whole thing.

Hi there!

 

For the worm game, I personally think 1K ROM for 2 bytes of RAM is an unacceptable compromise, if that helps your descission any

Before making a tradeoff like that, it's often necessary to ascertain (1) whether the memory is really saved, or whether another 'critical depth' still needs it at a different time in program execution; (2) whether there aren't already another couple spare bytes available.

 

A feeling I have, is when seeing all your required stunts like minimalizing stack usage and tradeoffs like the one above, all of this before you can even post a demo of your work, is that possibly your "set of compromises" may be flawed and that you may need to reconsider your plans, having better one or another feature redesigned for less RAM usage. I'd think you'll probably always need another 10 or more bytes for taking a conceptual prototype to an actual game.

 

Greetings,

Manuel

A feeling I have, is when seeing all your required stunts like minimalizing stack usage and tradeoffs like the one above, all of this before you can even post a demo of your work, is that possibly your "set of compromises" may be flawed and that you may need to reconsider your plans, having better one or another feature redesigned for less RAM usage. I'd think you'll probably always need another 10 or more bytes for taking a conceptual prototype to an actual game.

 

If I use 8 bytes for the kernel and do everything as planned, I could use a 16-high playfield and a 64-long snake and have seven bytes free (assuming one byte for return address, but before doing some of the other tricks I mentioned). If things become to difficult, I could shorten the snake (4 units/byte) or cut the playfield height (5 bytes/row) but I'd prefer not to do either unless I have to. If the snake limit ends up being 48 units instead of 64, I won't mind too much, but if it shrinks below 32 that wouldn't be as much fun.

Hi there!

 

Good to hear that there's a plan B

 

Greetings,

Manuel