Jump to content
IGNORED

bB used in computer science course


batari

Recommended Posts

I've known about this for months but didn't bother posting anything until I discovered that all of the students' programs were online:

 

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

 

Look under the "Atari 2600" section. I haven't downloaded them all yet, but I do know that the programs will compile under bB 0.35 if the binaries are not available. But anyway, there are at least a dozen new games, all with source code for others to learn from.

 

Enjoy!

Link to comment
Share on other sites

Atari 2600

agardner aheaden atrusty awallace cbryant

cgillens cgoodson cocchipinti

hkayama hpritchard jcrowder jdonnelly

jjo jmccree jstrully jwalker jyi

krosier manderson mboyce mdrake mgorbsky

nlance pjarrett tmarshall

 

When I first read this, I thought what the hell kind of language is this?

 

Then I realized it was the students names.

  • Like 1
Link to comment
Share on other sites

So very cool! Way to go Batari.

 

Any news on the latest bB? I'll be in a spot to work with it soon. (1.5 months or so) Looking forward to the whole experience again.

 

Edit: I shot the prof's a quick note about this thread and the blog post above. Who knows, we might hook a student or two! No matter how that goes, I think they should see others have enjoyed their work.

 

Another Edit: Al, the new forum UI is sweet! Thanks.

Edited by potatohead
Link to comment
Share on other sites

IMO the games all seem unfinished. Not surprising, since they are group efforts and on a deadline. Only a few have sounds, only a few allow you to restart a game (or begin another once your game is over)!

 

Guillermo's House Of Crack has the makings of a good game, as does the 2-player breakout, and the death flag game. I also liked the catch the ball game and the eliminator game.

Link to comment
Share on other sites

IMO the games all seem unfinished. Not surprising, since they are group efforts and on a deadline. Only a few have sounds, only a few allow you to restart a game (or begin another once your game is over)!

 

Guillermo's House Of Crack has the makings of a good game, as does the 2-player breakout, and the death flag game. I also liked the catch the ball game and the eliminator game.

Deathflag is a good game concept, I think. The 2-player breakout looks fun too. But like others here, there's usually not another player available.

 

The chopper game looks good too. Has terrain like Super Cobra, but control like Cave1k (albeit without inertia) and the terrain gets harder and harder to navigate. The K9 game deserves a look too.

 

All in all, it's nifty to see what students can come up with given just a couple of weeks to work on the projects!

 

I've been informed that bB will be used again this semester, so there should be more games coming soon.

Link to comment
Share on other sites

We should start some kind of archive, before too much gets lost.

Yeah...I was an early big advocate of BB but kind of let myself fall by the wayside, I think waiting for Batari to have time to plump up the language a bit more.

 

Actually once upon a time I was talking to Al about a bBdb, with snippets and small programs...I'll see what he thinks about that now.

Link to comment
Share on other sites

We should start some kind of archive, before too much gets lost.

Yeah...I was an early big advocate of BB but kind of let myself fall by the wayside, I think waiting for Batari to have time to plump up the language a bit more.

 

Actually once upon a time I was talking to Al about a bBdb, with snippets and small programs...I'll see what he thinks about that now.

 

I'm still pretty pumped about it. I like the environment --just need to work through some personal issues before continuing on. Thanks for following up on this.

Link to comment
Share on other sites

We should start some kind of archive, before too much gets lost.

Yeah...I was an early big advocate of BB but kind of let myself fall by the wayside, I think waiting for Batari to have time to plump up the language a bit more.

 

Actually once upon a time I was talking to Al about a bBdb, with snippets and small programs...I'll see what he thinks about that now.

 

I'm still pretty pumped about it. I like the environment --just need to work through some personal issues before continuing on. Thanks for following up on this.

I remember kind of what happened now...between some rough spots in an earlier build of bB and my own ASM chops being super rusty, I couldn't get "16 bit math" to work, and so I kind of let my project drop for a while, and with it my active bB participation.

 

Also, there were a few directions the board was going in that I wasn't crazy about...which is a pisspoor reason to drop out, but it dampened my enthusiasm (some minor technical differenes of opinion with batari, which is of course silly because he is Da MAN here and I am not, and just not crazy about some of the all in one IDE effort and difficulties)

Link to comment
Share on other sites

I remember kind of what happened now...between some rough spots in an earlier build of bB and my own ASM chops being super rusty, I couldn't get "16 bit math" to work, and so I kind of let my project drop for a while, and with it my active bB participation.

You are correct in that there were countless bugs in the fixed point math.

 

The asm routines written by djmips were essentially bug-free (only there was a stx in place of an ldx somewhere, but that was probably my mistake.) The real problem was with the compiler's detection of fixed point types, which basically didn't work at all. I did not discover these bugs until I tried to use fixed point math myself in a real game (Superbug) which led me to finally track down the bugs and fix them. They should be working now (as of the latest build released earlier this month.)

Also, there were a few directions the board was going in that I wasn't crazy about...which is a pisspoor reason to drop out, but it dampened my enthusiasm (some minor technical differenes of opinion with batari, which is of course silly because he is Da MAN here and I am not, and just not crazy about some of the all in one IDE effort and difficulties)

I don't recall what the technical differences were (or why I didn't want to implement them) but if you do remember, I'd be happy to hear them again.

 

I am not sure that the all-in-one IDE will be developed further, as attendo seems to have dropped off the map. But I think the latest version of his IDE should still work with newer versions of bB.

Link to comment
Share on other sites

The asm routines written by djmips were essentially bug-free (only there was a stx in place of an ldx somewhere, but that was probably my mistake.) The real problem was with the compiler's detection of fixed point types, which basically didn't work at all. I did not discover these bugs until I tried to use fixed point math myself in a real game (Superbug) which led me to finally track down the bugs and fix them. They should be working now (as of the latest build released earlier this month.)

Heh...that's what I've found building APIs at my company...you don't find the issues 'til you start using it yourself...

 

Also, there were a few directions the board was going in that I wasn't crazy about...which is a pisspoor reason to drop out, but it dampened my enthusiasm (some minor technical differenes of opinion with batari, which is of course silly because he is Da MAN here and I am not, and just not crazy about some of the all in one IDE effort and difficulties)

I don't recall what the technical differences were (or why I didn't want to implement them) but if you do remember, I'd be happy to hear them again.

Well, first off, I just want to say these weren't huge issues, and I feel I have barely any right to kvetch about what I still think of as one of the coolest 2600 developments in the last 5 years.

 

If memory serves, we had some different thoughts about how to define and then use 16 bit #s, for example. I think you were leaning towards making the 16 bitness fairly transparent to the user, and using something what programmers call "polymorphism", like, so that "+" might do something different depending on the type of the variable. I thought it would be more helpful to the user to have explicit, different functions for stuff like that...to make it easier to just use, say, 8 bits of the 16 for something else, and so that as a bB programmer might start to dabble in ASM, it will be more clear that those are different operations.

 

It's kind of a philosophy difference...I lean towards seeing bB as a fantabulous macro language plus kernal, but I think your vision is for something closer to the 8bit BASICs of old. Both are totally reasonable ways of thinking of bB, and seeing as how you're the guy putting in the blood sweat and tears, you win, though I appreciate your patience with other people's opinions.

 

I must be really trying to practice avoidance at work, because suddenly there are like 20 projects I want to work on :-)

 

Here's an idea...shoud we consider a sepcialty blog for posting bB projects once they are considered "realease ready"? I was thinking of some kind of catalog, but Al doesn't have time right now to set up a "proper" system like they have for atari carts. What do you think?

Link to comment
Share on other sites

Wow, I'd say far and away that Tank Wars Game http://www.lcc.gatech.edu/~bogost/courses/...projects/8.html

was the most impressive... decent control, decent collision detection with the walls, and even basic AI! Included sound and had smart use of color...very polished relative to some of the other works, and reminds me of some projects I'd like to try...

 

actually it handled one problem I'm still not sure I have a handle on, rotating an enemy so that it faces the opponent...if I could work out the math for 16 direction rotation, I'd try coding a "heat seeker" game I have in mind...

 

One funny thing is, these young punks...they think of their game as being played by spacebar, keyboard etc, and skip that its emulation of rather different hardware entirely-- to them it's all just a primitive programming language.

Link to comment
Share on other sites

One funny thing is, these young punks...they think of their game as being played by spacebar, keyboard etc, and skip that its emulation of rather different hardware entirely-- to them it's all just a primitive programming language.

 

Agreed on this game.

 

Maybe this class needs a cuttle cart / supercharger / thingy to play their games on!

Link to comment
Share on other sites

  • 3 weeks later...

Hey folks. I'm the professor who designed this class and this assignment, and I'm happy to see the discussion here. I thought I'd throw in a couple comments/responses to the thread so far.

 

(1) vdub_bobby noted that many of the games aren't finished. This is true. This is a 2-3 week project in the course, and as many of us know that last 10-20% of a game can take a lot longer than the other 80-90%. But more importantly, the assignment isn't really intended to produce polished games. Rather, it's intended to help the students understand how hardware design constrains the expressive possibility space for software. I use the 2600 not only because I love the platform and am a hobbyist VCS homebrewer myself, but also because it's a perfect platform for learning this important lesson. That said, a dozen almost completed games isn't a bad thing either.

 

(2) potatohead worried about archival. I've been intending to build a more public-facing view onto these games, but I haven't done it yet. I also have some sample code and related materials that might be useful to the community. Some updated stuff is on this term's course page, http://www.lcc.gatech.edu/~bogost/courses/spring06/lcc2700/

 

(3) kisrael wondered if the students realize that they're using emulation of different hardware rather than just an arcane language. I can assure you that I spend a great deal of time in the class showing them how the hardware works, walking them through a bunch of my assembly code and walking through the Stella programmers manual, and then showing how the higher-level bB relates to the assembly code it compiles to. This is a sophomore-level course, and it's true that some students have no memory of the system, but we have the hardware itself in our lab.

 

The next class in sequence covers C++ and Assembly on the GameBoy Advance. I don't expect the students to know either of them yet, but they get a reasonable introduction.

 

(4) potatohead added that maybe we need a cart/supercharger to write the games to, and I agree... I've been thinking about this

 

(5) batari noted that we're doing this again this term. That's true, should generate another 7 games and source code. Stay tuned in about 2-3 weeks here: http://www.lcc.gatech.edu/~bogost/courses/...700/project.php. I'll post again when they're up.

 

Thanks everyone for your kind comments. I'll pass them on to the students.

Link to comment
Share on other sites

Hey Prof!

 

Nice idea for a class.

 

Glad to hear that my comment was misfounded, guess I read too much into some of the comments about a spacebar vs. a joystick button etc.

 

For interested outsiders like us, it would be neat if there was a single index, with one entry per game...I clicked through pretty much every students' log, and of course there was a lot of overlap since you had teams of multiple students.

 

Some very nice work all in all!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

When I coded up my own game in ASM, I relied chiefly on a supercharger when I needed to move beyond the emulator. Seeing things run on a real screen, using real joysticks, is a huge boon.

 

I think at one point i even had it reading off of a cheap MP3/WAV player, but when i gave it another shot wasn't able to duplicate it cleanly.

 

Are you looking for specific details about makewav, etc, needed for dumping a game in a temporary kind of way? Or you mean an EPROM burner? Unforutantely I was never much of a hardware guy...

Link to comment
Share on other sites

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?

 

An Atari 7800 and the soon-to-be-out-of-production Cuttle Cart 2 would fit the needs of your class perfectly. Hopefully both are well within your departmental budget! Keep up the good work...

Link to comment
Share on other sites

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?

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

Here's the description from the AtariAge Store:

 

The Krokodile Cartridge is a programmable game cartridge for the 2600 game console. The cartridge contains 512K of Flash ROM that can be programmed by connecting the cartridge to a Windows PC with a serial cable. Once connected to a PC, the Windows-based Krokodile Commander software (screenshots below) is then used to download software into the Krokodile Cartridge. The cartridge also includes 32K of built-in RAM to support games that require additional onboard cartridge memory (such as Atari's SARA-chip games).

 

Using the provided Windows software, you can directly download Atari 2600 ROM images to the cartridge. In addition to downloading a single ROM binary, the cartridge can be used as a multicart. It can store up to 127 games (4K) which can be selected with a built-in menu system. Bankswitched multicarts are also supported, allowing you to create F8 (8K), F6 (16K) and F4 (32K) bankswitched multicarts. The multicarts can be created with the Krokodile Commander software. You can easily select which games you want to have on the cartridge and once you've made your selections you can download the created multicart image to the Krokodile Cartridge.

 

If you're thinking about developing games for the Atari 2600, or if you're already an established homebrew author, the Krokodile Cartridge is a great tool to add to your arsenal. You can quickly download binaries to the Krokodile Cartridge to test on a real system--especially useful as you near the end of your development cycle and want to make sure your game runs correctly on the real thing!

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 :lol:) 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!

 

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.

Link to comment
Share on other sites

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?

 

You could use a Krokodile Cartridge. It connects to the computer via serial port and stores the games in FLASH ROM. I'm using one with my Mac and it's a great development tool(I'm currently writing Medieval Mayhem, an updated Warlords). They are currently on back order, but should be available soon. You can buy it here at Atari Age - contact Al to be added to the waiting list.

 

Another option is to trackdown a Starpath Supercharger. It was a RAM cartridge for the Atari that used cassettes to store the software. You'd need to conver the student's resulting BIN files to an audio file using makewav and then play the sound file into the Supercharger. The Supercharger has some additional functionality that can conflict with non-Supercharger games - you can do a hardware modification that lets you select "Supercharger mode" or "Normal ROM emulation mode".

 

The Supercharger would limit your students projects to 4K ROMs. The Krokodile Cartridge supports multiple bankswitching formats and can handle from 4K up to 512K ROMs.

Link to comment
Share on other sites

By now you may understand your options for downloading games to 'real' hardware.

 

The cheapest path is usually the Starpath Supercharger, the coolest would be the Cuttle Cart II.

 

You can find Superchargers on eBay fairly frequently (as I have noticed from my automatic searches) They seem to sell for $20 to $40 depending on condition.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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...