bB used in computer science course

[Gregory DG]

I'm an advocate for the Cuttle Cart 2 too however, it can't be used on a real 2600. You'd have to drag in a 7800 into class and that might confuse the young skulls full of mush.

 

The Kroco Cart will work on a 2600 though.

[ibogost]

The Krokodile Cartridge is probably exactly what you want, and it is supposed to be available for purchase in the AA store very soon...

 

Thanks for all the replies. The Kroko cart sounds really promising. I was familiar with the Supercharger but I was hoping to find something more like the original carts in form and function, and it sounds like the Kroko is just that. And I do want something that I can run on the 2600 hardware. I'll get on the list for the next batch; hopefully we can use it next term.

 

And thanks for dropping in! I did mention that the games were unfinished, but I understand completely why that is so (I took CS courses in college myself ) and it is no knock on your students; it's impressive to me that most/all of them wrote playable games within just a few weeks of first learning to code the VCS - it isn't an easy machine to code for!

 

Thanks! I think sound gets left out most often, which is too bad because I think programming VCS sound is among the more fun aspects of the process. I've learned a bit about how to best help them I'm planning, at some point, to do a graduate course on the 2600... whole semester on the one platform, both playing and critiquing games from the perspective of deep knowledge of the hardware architecture, and really digging into programming, first in bB and then in assembly. I'm hopeful I'll be able to put that together in the next year or two.

 

A question: Did you introduce the concept of "flicker," and show how it can be used in bB? That's a pretty essential tradeoff in 2600 coding: no flicker vs. more sprites.

 

I showed them how the TIA timing works and showed them some pure-asm code that I then modified to use too many cycles and roll the screen. Then we talked about what bB does when it writes PF graphics, for example. I should probably build a few more examples that show the timing issues in bB specifically, since it's a bit harder to understand why you get flicker sometimes (since you're not doing the cycle timing directly, which is a huge blessing)

[vdub_bobby]

A question: Did you introduce the concept of "flicker," and show how it can be used in bB? That's a pretty essential tradeoff in 2600 coding: no flicker vs. more sprites.

 

I showed them how the TIA timing works and showed them some pure-asm code that I then modified to use too many cycles and roll the screen. Then we talked about what bB does when it writes PF graphics, for example. I should probably build a few more examples that show the timing issues in bB specifically, since it's a bit harder to understand why you get flicker sometimes (since you're not doing the cycle timing directly, which is a huge blessing)

I think you misunderstand what I mean. By "flicker" I mean what 2600 Pac-Man does to get more than 1 ghost on the screen at once.

[+batari]

Thanks for all the replies. The Kroko cart sounds really promising. I was familiar with the Supercharger but I was hoping to find something more like the original carts in form and function, and it sounds like the Kroko is just that. And I do want something that I can run on the 2600 hardware. I'll get on the list for the next batch;

hopefully we can use it next term.

I think that having a few of the Pixels Past boards, some EPROMS and a device programmer would give a better impression of how things were done back in the day, if that's important. (Not that The Kroko cart isn't a cool piece of hardware...)

I showed them how the TIA timing works and showed them some pure-asm code that I then modified to use too many cycles and roll the screen. Then we talked about what bB does when it writes PF graphics, for example. I should probably build a few more examples that show the timing issues in bB specifically, since it's a bit harder to understand why you get flicker sometimes (since you're not doing the cycle timing directly, which is a huge blessing)

Yeah, it's really easy to exceed the allotted cycles, and in some ways I think that abstracting out the timing is kind of a mixed blessing, since it's not too clear (and not well-documented) as to which kinds of operations hog cycles and which do not. Plus, the emulators are much more forgiving than the actual hardware in this regard.

 

So I put in two special debug modes in the latest version. When enabled, the first just flashes the background color when you exceed the number of cycles in the frame.

 

The second is more informative, in that it hijacks the score and shows an estimate of the number of cycles available in the current frame, in white. Or if the number of cycles is exceeded, the score will turn red and show how many cycles you have exceeded the count, up to around 2000.

 

IIRC, they are enabled by each of the following:

set debug cycles

set debug cyclescore

[MausBoy]

Yeah, it's really easy to exceed the allotted cycles, and in some ways I think that abstracting out the timing is kind of a mixed blessing, since it's not too clear (and not well-documented) as to which kinds of operations hog cycles and which do not. Plus, the emulators are much more forgiving than the actual hardware in this regard.

 

So I put in two special debug modes in the latest version. When enabled, the first just flashes the background color when you exceed the number of cycles in the frame.

 

The second is more informative, in that it hijacks the score and shows an estimate of the number of cycles available in the current frame, in white. Or if the number of cycles is exceeded, the score will turn red and show how many cycles you have exceeded the count, up to around 2000.

 

IIRC, they are enabled by each of the following:

set debug cycles

set debug cyclescore

 

When I use these in every program I've made so far, I get tons of flashing and over 2000. I guess I have a lot to learn about timing and well organized programming.

[potatohead]

A single index is definitely needed. That's on my todo list for the summer.

 

Back to the spacebar/joystick thing, I think it's a valid point you raise, even if I do explain and show them the hardware. I've tried to get a number of the students to change their control systems to better reflect the physical joystick, but that doesn't always happen. I think getting a cart writer of some kind will solve this problem, but I haven't had a chance to figure that out. Any recommendations?

 

I would get a USB adapter and some gaming hardware for them to use. There are a number of joystick / button thingys built for playstation, etc... that should do the trick.

[supercat]

Thanks for all the replies. The Kroko cart sounds really promising. I was familiar with the Supercharger but I was hoping to find something more like the original carts in form and function, and it sounds like the Kroko is just that. And I do want something that I can run on the 2600 hardware. I'll get on the list for the next batch; hopefully we can use it next term.

 

Although I would recommend having students use something like the KK for development, I would also suggest getting a stock of cartridge shells, boards, and EPROMs so that students who want them can keep real cartridges of their games once the course is over.

[ibogost]

Hey folks --

 

The new games for this semester are now done. I haven't even had a chance to go through them yet in detail but I wanted to share them with the community here. Some really, really nice stuff. Here's the link:

 

http://www.lcc.gatech.edu/~bogost/courses/...700/project.php

 

Scroll down to Atari 2600 at the bottom and click on the names to open the project pages. A lot of students made box art this term as well. Be sure to check out eorear and jswisshelm, which lead to particularly complete games including sound and splash screens and the like. And don't miss the sound design in caubuchon.

 

I promise to aggregate these better after the term ends. But I wanted to share then now.

[Shawn]

Hey folks --

 

The new games for this semester are now done. I haven't even had a chance to go through them yet in detail but I wanted to share them with the community here. Some really, really nice stuff. Here's the link:

 

http://www.lcc.gatech.edu/~bogost/courses/...700/project.php

 

Scroll down to Atari 2600 at the bottom and click on the names to open the project pages. A lot of students made box art this term as well. Be sure to check out eorear and jswisshelm, which lead to particularly complete games including sound and splash screens and the like. And don't miss the sound design in caubuchon.

 

I promise to aggregate these better after the term ends. But I wanted to share then now.

 

 

Dorthy X really reminds me of a gauntlet sort of game. Very nice & IMO the best of the bunch. I also really liked Quakman VS Growl. Both of those blow the rest of the projects right out of the water from play value perspective.

[vdub_bobby]

I thought Go B! was best, though a 1-player mode would be really nice.