Jump to content
  • entries
    14
  • comments
    81
  • views
    38,182

of mountaineers and retro coders

Sign in to follow this  
RevEng

1,413 views

the ascent

 

Mountain climbing is an activity that can be done many ways.

 

Mountaineers may employ sherpas to assist, or they can choose to climb only with other mountaineers. They may set up base camps at which they have large amounts of supplies, or they may simply climb steadily, carrying a meager stock of supplies that must last the whole trip.

 

The list of optional equipment a mountaineer may employ is also pretty long - supplemental oxygen, crampons, ice axes, tents, high-tech thermal body suits, etc.

 

Sometimes mountaineers and enthusiasts complain that other mountaineers are cheating due to the techniques they employ or the equipment choices they make. They feel the climb should be equally hard for all, and those who employ special gear to lighten the task are cheaters, not worthy of sharing the title of mountaineer.

 

In this respect Atari 2600 programming is like Mountain Climbing.

 

mount fuji

 

The modern 2600 game coder has a lot of choices to make. There are well over a dozen different cartridge configurations to choose from, most with additional ROM via bankswitching, some with additional RAM, and yet others with additional processing like the Activision DPC boards or Melody boards with DPC+.

 

Coders even have a choice of coding in pure assembly language, or batari Basic.

 

And it doesn't end there.

 

Both bB and assembly coders must choose between using Other People's Code, or writing their own. OPC for bB coders means using built-in libraries and kernels. OPC for assembly coders means using key routines that have been passed from hand to hand, posted on mailing lists and forums.

 

And for those that choose to write their own code, rather than using OPC, can use undocumented 6507 instructions that weren't widely used historically, or work only with the official instructions. Similarly, they can use techniques that have been learned and documented in the era of the 2600 homebrew, or keep their techniques strictly to those documented in the Stella programming documentation.

 

With all these choices, it's not a surprise that someone, somewhere, regularly declares that using one technique or another is a cheat. And, to use the analogy, often the person making the complaint isn't even climbing up the mountain with just his own two hands.

 

 

where's the top of your mountain?

 

If you're a 2600 game coder and your primary goal isn't "make a great game", then I'm respectfully going to suggest you should consider coding demos instead. Coding demos can prove your technical chops just as well as coding a game, without foisting yet another poor-to-average game on the 2600 library.

 

If you want to have a secondary goal of constraining your choices, then by all means go for it! Just don't cry foul when someone else doesn't share your secondary goal. Why should they?

 

Some of us just want to get to the top and enjoy the view.

Sign in to follow this  


5 Comments


Recommended Comments

Yep, as long as the game is fun, user friendly, and as polished as possible, that's all I care about. If a programmer wants to cut himself with razorblades and roll around in salt, that's his problem.

 

For me, the simplest things can be as hard as a 'normal' person trying to do advanced calculus while juggling chainsaws, so I'll use every tool, trick, and shortcut I can get my hands on.

  • Like 1

Share this comment


Link to comment

I understand the desire to add constraints... the added challenge makes the task more interesting, and I wouldn't be programming for the 2600 if I wanted to take the easiest route to creating games.

 

But any self-imposed challenges need to take a backseat to the game being fun, and when a coder decides his own constraints need to apply to others then he's lost touch with reality.

  • Like 2

Share this comment


Link to comment
I understand the desire to add constraints... the added challenge makes the task more interesting, and I wouldn't be programming for the 2600 if I wanted to take the easiest route to creating games.

There seems to be three main reasons why people make Atari 2600 games:

 

  1. They want to do something hard to challenge themselves, so they use assembly language.
    _
  2. They're doing it for school.
    _
  3. They had an Atari 2600 as a kid and always wanted to make their own Atari 2600 games because there's something special and magical about the graphics and sound effects that other consoles don't have.

 

The third type of person will usually want and need every tool, trick, and shortcut they can get. That's why they use batari Basic, Visual batari Basic, and various kernels, minikernels, modules and enhancements.

  • Like 1

Share this comment


Link to comment

When I programmed Skeleton, bB didn't exist - so the only way was handcoded 6502 assembly. Stellalist was fairly active, although the amount of reusable code available was a lot less than exists now. But the main constraint was 4K ROM size. Although bankswitching was understood and handled by emulators, physical cart manufacture was done by salvaging a 4K game PCB and adding an inverter to A12 for the EPROM. So if you wanted to sell games, you had to stick to 4K ROM (and 128 bytes of RIOT RAM).

 

Nowdays I think the main split is ASM versus bB, although I suspect Harmony/ARM might become another division in the future.

  • Like 1

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...