It's time I made my own 2600 game

[chadtower]

Okay, when I was a kid, I used to spend countless hours in front of my 2600, dreaming of how cool a person must be considered who could write video games. I mean, come on, these guys must get ALL the chicks, right? Well, at least I was right about being cool. Fast forward about 20 years and I'm finally working on my first 2600 code. If I can pull this off, and create a respectable 2600 game, I'll have accomplished a lifelong dream! I'm excited to say the least. I've just compiled my first 2600 bin (sample kernel by Andrew Davie) and was wondering... it's nice and all that to play them in an emulator, but what is the best way to test these things out on an actual 2600?

[CPUWIZ]

1.) Cuttle Cart

2.) Supercharger

3.) EPROM board

4.) Modified 7800 system + RAM cart

5.) Real 2600/7800 development system + Atari ST

 

I am sure there is another way that I can't think of right now.

 

[chadtower]

Hrm... I've heard of the cuttle cart and supercharger, never seen either one. I remember the supercharger was a cart interface for a cassette drive? What is the cuttle cart?

 

What are the ways one would use an eeprom? A cart with an atmel style socket that you could plug eeproms into, paired with perhaps an atmel programmer?

 

I have never heard of a 7800 RAM cart... what is that, and why would it cause you to have to modify the console?

[CPUWIZ]

The CuttleCart is out of production but Chad is making a new one for the 7800, I'll dig up the link and you can read about the 7800 mod in the meantime.

 

http://home.arcor.de/estolberg/tools/

[CPUWIZ]

http://www.schells.com/cc2.shtml

[chadtower]

Wow... that cuttle cart is pretty cool. Costly, too. I really need to learn how to solder, I think.

[+Cafeman]

I did the same thing but on the 5200, started in 2001. I didn't have a cuttle cart so I bought the pocket programmer and Old Guru made me a test PCB with an Eprom Socket on it. You could go that route too, but it will cost you over $200 for the PP and an Eprom eraser.

 

I also had to learn to solder. I'm still not sure I really learned! But I did manage to make carts.

 

Congrats on taking steps into the bigger and stranger world of 2600 programming! Got any ideas for games yet?

[chadtower]

I've got some vague ideas, nothing specific. For some reason all of my ideas end up being envisioned as overhead gameplay, kind of like Ikari Warriors or River Raid, so I guess that's where I'm going.

[EricBall]

Superchargers can be had at a reasonable cost on eBay, and can handle standard 4K carts and do 6K bankswitched. There are utilities to download the ROM image from a PC too.

 

But it is very possible to develop using only a good emulator (Z26 is my favorite) as a guide. Skeleton was developed using only an emulator, with some final testing by others on real hardware.

[kisrael]

Superchargers can be had at a reasonable cost on eBay, and can handle standard 4K carts and do 6K bankswitched.  There are utilities to download the ROM image from a PC too.

 

But it is very possible to develop using only a good emulator (Z26 is my favorite) as a guide.  Skeleton was developed using only an emulator, with some final testing by others on real hardware.

I just wanted to second these two thoughts, and add a few notes.

 

Superchargers are pretty cheap--back in the day, people provided their own casette tape, and plugged the cartridge's wire into the audio out of the tapedeck...so what you do now is plug the cartridge's wire in to the audio out of your PC. the only caveat is it seems to be (at least for me) that the supercharger plug was just a tiny bit bigger than average for a headphone jack, and so now when I use my regular stereo, i have to wrap the wire around another plug so it stays pulled up a bit.

 

emulators do a pretty damn respectable job... with joust pong ( http://alienbill.com/joustpong/ , still in progress but already a complete game) my biggest problems is I'd forget the "#" before numeric constants, and get all sorts of weird results sometimes, that would vary from emulator to emulator....but nothing beats seeing your stuff on a real atari, on a real tv, so look into the supercharger. (If you get really finished--and I won't kid you, it is a reasonable sized "if"--there are lots of resources on this site to help you make carts and get publicity and sell)

 

Do you know any programming already? I'm a pretty experienced high-level programmer (Java/Perl/C etc) but the atari has been a harsh mistress. I think there are somewhat better resources now than a year ago... Andrew Davie's "Programming for Newbies" forum, and my own humbler tutorial 2600 101 (now hosted, but not linked, on this very site)

[chadtower]

Yep, 5 years of cmpsci at Northeastern and UMass, I'm a software developer at Kodak now. Lots of programming experience, have studied assembly before. I'm not having any trouble following Andrew's tutorials, read about half of them yesterday and poked around in his sample kernel. I just have to master the oddities specific to the 2600 mentioned in the Stella guide like the background mirroring and especially ntsc frame management.

[kisrael]

Yep, 5 years of cmpsci at Northeastern and UMass, I'm a software developer at Kodak now.  Lots of programming experience, have studied assembly before.  I'm not having any trouble following Andrew's tutorials, read about half of them yesterday and poked around in his sample kernel.  I just have to master the oddities specific to the 2600 mentioned in the Stella guide like the background mirroring and especially ntsc frame management.

Ah, you might be around where I was...though if the "studied assembly" history is like mine (one class of SPARC back at college) it might not be too too useful.

 

Do read through my 2600 101, it's pretty compact, and I use a different style of starting with a basic program and adding to it, I think it's a decent complement to Davie's ultimately superior work.

[chadtower]

Oh, don't worry, I'll end up reading everything I can manage to find, and likely ordering one or two 6502 books as well. My assembly background was in a class - architecture and assembly language - at umass amherst. So far, though, i've found it to have been tremendously helpful in giving me what I need to understand this stuff. Of course, I took it in 1997, so some of it is taking a bit of time to come back to me.

[Chadivision]

Just a couple of thoughts.

 

The Cuttle Cart is great. I used it to develop my first (and so far only) homebrew, Backfire.

 

I have also looked throught the homebrewing tutorials and they are really well written. When I started messing around with this stuff about 3 years ago, I wasn't able to find anything nearly as complete as these. There was a lot of information, but no step by step tutorials. I wish these had been around when I started.

 

I haven't posted on the Stella list very much, but I have read a lot of the posts. There is some really good information there. Just about any question that you can think of has already been answered there.

 

I also used to think how cool it would be to make Atari games and I have to tell you that it feels really good to have completed one. I think that Atari homebrew programming is a really cool art form. Everyone knows someone that can paint or play the piano (not to diminish this), but how many people do you know that can write Atari games? How many people do you know that even know that you CAN make your own Atari games? I have had a great time with my first game and I hope to create several more.

[chadtower]

Yeah. It could take me a long time since I don't have much free time these days (work, kids, the usual). But I think I have the start of a concept that could be a decent game, something that I haven't seen yet, and would be a candidate for some really funny artwork too (think This Planet Sucks). I'm going to spend some time going through the info, getting better with the code... and then will come with the specific questions that demonstrate I've done enough work on my own to deserve an answer.

[kisrael]

I'm going to spend some time going through the info, getting better with the code... and then will come with the specific questions that demonstrate I've done enough work on my own to deserve an answer.  

 

My advice, besides reading tutorials (including my own "2600 101") involves being really careful with some things in your source...specifically, if you're use to higher level stuff, DASM sometimes lets you make strange-seeming shooting yourself in the foot type mistakes. To whit: make SURE your constants start with #, otherwise you start doing random memory things. And focus on memory addressing modes.

[chadtower]

Cool, thanks for the advice. I'm used to that, though, being a professional PERL programmer. PERL has a lot of those same typing issues, though it may be a bit easier to debug.

 

Who am I kidding, it's a LOT easier to debug.

[Chadivision]

One other thing that I have found helpful is to focus on enjoying the process of writing a game (and not just finishing the game). That way you don't get discouraged even if you don't have a lot of time to program. I think it's kind of like guys who like to tinker with old cars. The finished product will be cool, but the tinkering is the fun part.

[kisrael]

I've done Perl professionally as well...and, for my money, this is nothing like the fast-and-loose typing of Perl. Perl has an uncanny knack for figuring out what you're getting at, with just a smidge of trickery for hashes and arrays. For fundamental non-coincedental reasons, 6507 ASM is a lot more like pointer and dereferencing madness in C, where specifying the wrong mode is likely to get you something completely unexpected. (Or worse, something more-or-less-expected, until you try it on a different emulator or real atari, and suddenly the fact that you're reading using a number as a memory location rather than a hardcoded constant value can put you in a world of weirdness.) As long as your very careful, make sure you put a "#" before the name of constants you're referencing, and know what address modes are possible, you should be ok.

 

RE: tinkering vs. goal oriented development...I dunno, without the goal of getting a game out and into the hands of hobbyists, and that greek street cred, I never would have gotten as far as I have. It was seeing Joe Grand seeling carts at Philly Classic 3-- not the money, but the recognition-- that got me started and realizing that 2600 is tough but not a superhuman endeavor (though later I found out Grand had a good of ASM under his belt already). Actually, I'm not positive what got me picking the project up after letting it lapse for a year, but it's definately not just the urge to tinker.

 

Though now that I've passed some of the basic hurdles, I might be more willing to experiment with some basic game ideas in the future. But first thing first, I want to add a ton of polish to JoustPong.

[Chadivision]

I agree that there is something to be said for using a goal oriented development schedule. I used a schedule for developing Backfire.

 

My point is that if you really want to write a game, don't talk yourself out of it because you don't have a lot of time on your hands. If it takes you several months or a year, that's fine. It's better to spend a year writing a game than to spend a year not writing a game. If you have more free time, great. Maybe you can get it done in a month or two.

 

I wrote Backfire while I was in the process of starting a new career as a real estate agent, which is very time consuming. I think that having a goal oriented hobby can keep you from getting burned out on other things in your life (like a new career).