Sorta-experienced newbie

[supercat]

I just rediscovered my interest in 2600 programming after about a decade away from trying it, and am wondering whether I should finish the game I started (a "columns" clone) or do something else. I've got a nice six-column twenty-row gradient-shaded gems display (gem colors are packed two per byte with an odd interlacing scheme) so the game should look pretty good, but I haven't figured out the best way to detect three or more adjacent gems of the same color. Further, I'm not sure how much interest there would be in such a game.

 

The other idea I had would be a 'worm' game for the SuperCharger. Doing a program for the 'straight' 2600 would be cooler than doing one for the SuperCharger, but even with the most efficient coding in the world the playfield would probably be limitted to a dimension of 32x16 and I don't know how playable the game would be at that size.

 

One technique I would use with the 'worm' game that I haven't seen used elsewhere would be to 'venetian blind flicker' the playfield between two colors so as to allow a four-color playfield display (probably black/red/green/yellow). Using this approach would allow for a green worm, red mines, and yellow munchies, with flicker that would hopefully not be too bad.

 

BTW, I know how Galaxian's seven sprites per row works, but does anyone know how Commie Mutants' score digits work? And how on earth did Warren Robinnet do his Basic Programming cartridge in 4K ROM with only 128 RAM (of which 64 are available to the programmer!?)

[Cybergoth]

Hi there!

 

Doing a program for the 'straight' 2600 would be cooler than doing one for the SuperCharger, but even with the most efficient coding in the world the playfield would probably be limitted to a dimension of 32x16 and I don't know how playable the game would be at that size.

866148[/snapback]

 

http://www.atariage.com/screenshot_page.ht...wareLabelID=537

http://www.atariage.com/screenshot_page.ht...wareLabelID=548

http://www.atariage.com/screenshot_page.ht...areLabelID=1997

 

Greetings,

Manuel

[kisrael]

Commie Mutants' score digits work?  And how on earth did Warren Robinnet do his Basic Programming cartridge in 4K ROM with only 128 RAM (of which 64 are available to the programmer!?)

Heh. No idea, I've always had a weird fascination with that game.

 

Damn, I can't find this one document I dug up once where a guy tries to make as many games as possible within that environment...I remember at one point I was trying to tap some of them but the environment was WAY too clumsy through an emulator even when I made myself a nice printout of what buttons to try and press....

[vdub_bobby]

I just rediscovered my interest in 2600 programming after about a decade away from trying it, and am wondering whether I should finish the game I started (a "columns" clone) or do something else.  I've got a nice six-column twenty-row gradient-shaded gems display (gem colors are packed two per byte with an odd interlacing scheme) so the game should look pretty good, but I haven't figured out the best way to detect three or more adjacent gems of the same color.  Further, I'm not sure how much interest there would be in such a game.

I'd be interested in a Columns-type game. Puzzle games are fun and there aren't many on the 2600.

[supercat]

I'd be interested in a Columns-type game.  Puzzle games are fun and there aren't many on the 2600.

866375[/snapback]

 

I'll have to see if I can dig out my code. What's the best development system to use these days?

 

Also, I was thinking of doing a version of Mahki/Boxxi/Bubble Ducky/etc. using a 16x16 five-color grid. Colors could be nicer in an 8x16 grid, but I don't know if that would be as much fun.

 

It is nice to see that the forum seems to be alive, though. >:*3

[vdub_bobby]

I'd be interested in a Columns-type game.  Puzzle games are fun and there aren't many on the 2600.

866375[/snapback]

 

I'll have to see if I can dig out my code. What's the best development system to use these days?

Well, just about everyone uses either a PC or a Mac with the assembler dasm and one of the emulators: z26 or Stella (or the older, but still useful, PCAE).

 

Alternately, Andrew Davie uses dasm to assemble and the Krocodile Cartridge to run his binaries, since no emulator supports the far-out bankswitching method he uses (yet).

[+batari]

Alternately, Andrew Davie uses dasm to assemble and the Krocodile Cartridge to run his binaries, since no emulator supports the far-out bankswitching method he uses (yet).

866676[/snapback]

Plus the bankswitching scheme he uses allows something like 32k of RAM, which means that you can make games using the same tricks as Supercharger games (and then some) plus you can access something like 480k of ROM. Plus, you can make these into a stand-alone cart, something you can't readily do with Supercharger games. For this reason I don't recommend making new Supercharger games.

 

I plan to experiment with this scheme as soon as the emulators support it, which should be soon, I hope.

[supercat]

http://www.atariage.com/screenshot_page.ht...wareLabelID=537

http://www.atariage.com/screenshot_page.ht...wareLabelID=548

http://www.atariage.com/screenshot_page.ht...areLabelID=1997

 

Well, Wormy is a bit different from those games:

 

-1- Unlike Surround or (as far as I can tell) Warring Worms, the Wormy worm has finite length. This requires keeping track of where the worm has been to allow for erasing the tail. With a 32x16 playfield, a worm should probably be allowed to grow to a length of at least 64. Even with optimal coding, keeping track of the worm tail would thus require a minimum of 16 bytes. I don't know how Tapeworm keeps track of the worm's tail, but I notice its grid size is about 32x16.

 

-2- Unlike Commodore's Slither (from which Tapeworm seems to be derived), which only shows one goodie at a time and has no obstacles other than the snake's tail, Wormy has a playfield laden with mines and goodies. Best-case storage would probably be about 16 bytes to keep track of 128 objects which could be goodies or mines (I would have one or more ROM-based maps showing where the 128 object-spots were; if a bit in the 128-bit bitmap was set, the corresponding spot on the playfield would be occupied by either a mine or a goodie, depending upon whether the other bitmap showed 'occupied' or not.)

 

I would expect that it might barely be possible to make everything fit, but RAM would be extremely tight since 96 bytes would be allocated to array structures before I even start counting up 'loose' variables. Coding for a SuperCharger would make things a LOT easier.

[supercat]

Alternately, Andrew Davie uses dasm to assemble and the Krocodile Cartridge to run his binaries, since no emulator supports the far-out bankswitching method he uses (yet). icon_lol.gifAlternately, Andrew Davie uses dasm to assemble and the Krocodile Cartridge to run his binaries, since no emulator supports the far-out bankswitching method he uses (yet).

866676[/snapback]

Forgive me for asking, but is there a FAQ someplace that says where to find all these goodies?

 

BTW, as I think about it, my current inclination would probably be to do a version of Mahki/Boxxi/Bubble Ducky/etc. on either an 8x16, 16x12, or 16x16 grid using a venetian-blind color trick somewhat like Boulderdash but better [but unsuitable for full-screen-width use]. Should require somewhat less tricky coding than my other ideas while still being pretty playable.

[Cybergoth]

Hi there!

 

Well, Wormy is a bit different from those games:

 

Well, with 3 million different Worm games available, it'll be a hard job guessing the one that you have in mind

 

These where just examples of all worm games already made on the 2600, so they're more or less showcasing what's possible.

 

With a 32x16 playfield, a worm should probably be allowed to grow to a length of at least 64.  Even with optimal coding, keeping track of the worm tail would thus require a minimum of 16 bytes.  I don't know how Tapeworm keeps track of the worm's tail, but I notice its grid size is about 32x16.

 

That's 80 bytes then.

 

Well, you asked "how playable the game would be at that size" so Tapeworm is exactly what you'd get at this resolution.

 

I would expect that it might barely be possible to make everything fit, but RAM would be extremely tight since 96 bytes would be allocated to array structures before I even start counting up 'loose' variables.  Coding for a SuperCharger would make things a LOT easier.

866871[/snapback]

 

Hm... that's still ~30 bytes available. Maybe...

 

BTW: Since you said you've never seen a venetian color flicker thing elsewhere, I attached one for you...

 

Greetings,

Manuel

grandiii.zip

[vdub_bobby]

Alternately, Andrew Davie uses dasm to assemble and the Krocodile Cartridge to run his binaries, since no emulator supports the far-out bankswitching method he uses (yet). icon_lol.gifAlternately, Andrew Davie uses dasm to assemble and the Krocodile Cartridge to run his binaries, since no emulator supports the far-out bankswitching method he uses (yet).

866676[/snapback]

Forgive me for asking, but is there a FAQ someplace that says where to find all these goodies?

Have a lookie here for assemblers/disassemblers/documentation/etc.: http://www.atariage.com/forums/index.php?showtopic=24015

 

For emulators, have a look here: http://www.atariage.com/2600/emulation/ind...p?SystemID=2600

 

There is also an emulation forum here at AtariAge that is worth peeking in on occasionally.

[supercat]

BTW: Since you said you've never seen a venetian color flicker thing elsewhere, I attached one for you...

 

Hmm... that's not quite what I had in mind. Check out the enclosed demo I just wrote to see what I was thinking of.

JPDEM1.ZIP

Edited June 5, 2005 by supercat