Jump to content
IGNORED

It's contest time!


Jess Ragan
 Share

Recommended Posts

The Stella Mailing List is hosting a Batari BASIC contest, to find the best game designed with Fred Quimby's excellent game design utility. The grand prize winner receives $500 in cash, with other prizes to be determined later. You can find more information about it here... just scroll to the bottom of the page.

 

http://thedig.dyndns.org/?action=contest.details

 

The only problem (for me, at least) is that I can't seem to subscribe to this mailing list... I keep getting Internal Service Errors! Anyone have any suggestions as to how I can fix this problem?

 

JR

Link to comment
Share on other sites

I'm not quite sure what this means:

Entries into this category must author games using the Batari BASIC framework.

People who use special kernels and a ton of inline assembly will kick the asses of those who stick with the normal batari Basic commands.

 

 

 

Entry deadline: July 1, 2006

I should be able to create something by then and you know I'm going to win so they can put my name on the check right now. :lol:

Link to comment
Share on other sites

Whos gone payout the $500 ?!? and why..

910544[/snapback]

 

Glenn Saunders will pay.

 

As to why, he wants to see more development in two areas:

 

1. Supercharger. We've lots of great homebrew games, but few supercharger efforts. With 6K of ram, lots of interesting programming techniques become available. Untapped potential. Games can be loaded as audio files to boot, making play on an ordinary machine + supercharger possible w/o having to have cuttle cart, etc...

 

2. Batari Basic. Chance to grow some new 2600 blood. BB used as a framework instead of a platform for game development. A bb program with custom kernel might rival pure assembly home brew projects while saving some time as well.

 

 

Both of the cash prizes are about pushing the limits, doing new things and learning stuff.

Link to comment
Share on other sites

BB used as a framework instead of a platform for game development.

911364[/snapback]

What does that mean exactly? I know what each word means, but not in that order.

911366[/snapback]

 

Sorry, that's way past any reasonable buzzword limit :)

 

Right now ooze is a great example of a bb game as if bb was a platform. I'm not touching the kernel, am using inline assembly for speed / space reasons. I think it's gonna end up being a great game, but it won't do anything some other bb program can't do. For me, this is great. I can get a good solid game done and learn how the 2600 works without having to spend tons of time on assembly issues.

 

What Glenn wants is things taken to the next level. Rough out the game with bb, maybe resulting in something like the games we have seen so far. Then, get into the kernel and carve out a custom environment that works for *that* game only. That's what a framework is. The result of that effort will likely be on par with pure assembly homebrew games visually.

 

Bb can match homebrew games in terms of overall gameplay, but falls short in the visuals department. Some games are gonna work great anyway, others are just not. (Platform limits) Games that break this barrier will be treating bb as a framework, much like taking an existing assembly language game and building from there.

Link to comment
Share on other sites

BB used as a framework instead of a platform for game development.

911364[/snapback]

What does that mean exactly? I know what each word means, but not in that order.

911366[/snapback]

Sorry, that's way past any reasonable buzzword limit :)

 

Right now ooze is a great example of a bb game as if bb was a platform. I'm not touching the kernel, am using inline assembly for speed / space reasons. I think it's gonna end up being a great game, but it won't do anything some other bb program can't do. For me, this is great. I can get a good solid game done and learn how the 2600 works without having to spend tons of time on assembly issues.

 

What Glenn wants is things taken to the next level. Rough out the game with bb, maybe resulting in something like the games we have seen so far. Then, get into the kernel and carve out a custom environment that works for *that* game only. That's what a framework is. The result of that effort will likely be on par with pure assembly homebrew games visually.

 

Bb can match homebrew games in terms of overall gameplay, but falls short in the visuals department. Some games are gonna work great anyway, others are just not. (Platform limits) Games that break this barrier will be treating bb as a framework, much like taking an existing assembly language game and building from there.

911794[/snapback]

Thanks. Now I understand.

 

On a semi-related subject, it's cool that a programmer who knows all about programming the Atari 2600 the hard way could use bB and the IDE to speed up the game making process and make the whole experience more pleasant.

 

I probably won't do much beyond the Basic commands except for using inline asm from a code repository, so there's no way I'm going to win anything. Trying to win some money might spoil the fun for me, so I'm not going to worry about it. I always wanted to make games for the Atari 2600 and bB will make that possible after the next version comes out so we can use more gosubs in if-then statements. I love programming games in a BASIC that doesn't have 3 billion commands. My games might end up sucking, but at least I will have fun creating them, plus, they will work on an Atari 2600.

Link to comment
Share on other sites

The Stella Mailing List is hosting a Batari BASIC contest, to find the best game designed with Fred Quimby's excellent game design utility.  The grand prize winner receives $500 in cash, with other prizes to be determined later.  You can find more information about it here... just scroll to the bottom of the page.

 

http://thedig.dyndns.org/?action=contest.details

 

The only problem (for me, at least) is that I can't seem to subscribe to this mailing list... I keep getting Internal Service Errors!  Anyone have any suggestions as to how I can fix this problem?

 

JR

909908[/snapback]

 

Jess, I get the same thing. I even emailed the administrator asking for instructions on how to go about subscribing to the Stella list, but have received no response. (Perhaps they killfile all emails coming from AOL addresses?) I tried to subscribe about a year ago, and got nowhere at that time, either-- but the list seemed to be in limbo at that time (I think it may have been undergoing a reorganization, or was being moved to a new server, or something?), so I attributed the lack of response to that fact. But the list appears to be active again now, so I would hope that there is someone available to give instructions for subscribing, especially since the web page that's supposed to be used for subscribing isn't working.

 

Not that I really need to be able to *post* to the list; I can still *read* it. And there probably isn't much in the way of programming that I'd need to ask anyone there for help with that I couldn't work out myself-- not that I'm a programming guru or anything (far from it, especially on the Atari 2600!), but I enjoy working things out for myself. Still, I'd like to join in some of the discussions if I could.

 

I'm currently working on (or perhaps I should say, *not* working on) a huge adventure game that uses the M-Network bankswitching method, so I can have 16K of ROM, but most importantly, 2K of extra RAM to work with. The questions I have aren't in the area of programming, but deal with manufacturing cartridges for the finished game, so I really need to talk with some old M-Network engineers for that... or maybe anyone who's *created* a bankswitching method of their own, as I'm interested in the possibility of extending the M-Network bankswitching design to allow for even more ROM and (especially) RAM. I had thought about attending the CGE2K5 in California this coming weekend-- I was invited, anyway-- and I would have loved to talk with any of the old M-Network gurus about bankswitching, but I don't expect to make it there after all. :-(

 

As for the Batari BASIC contest, I'm currently working on a far simpler adventure game in Batari BASIC, and it's a lot of fun to see what I can do with it! But I don't know if I'd enter it into the contest, as it probably isn't "good enough" or "original enough" to warrant that. (It's basically one of those "You're in a dungeon maze and need to find your way out" game, which has been done to death; but the maze is based on an idea I had many, many years ago, so I really want to do it.) Right now I'm programming it in pure Batari BASIC, with no in-line assembly code, because I want to see what I can do that way. But before it's done, I may end up taking the compiled Batari BASIC game and doing some surgery on it to squeeze the code together and pack more levels into the finished game.

 

Michael Rideout

Link to comment
Share on other sites

I'm currently working on (or perhaps I should say, *not* working on) a huge adventure game that uses the M-Network bankswitching method, so I can have 16K of ROM, but most importantly, 2K of extra RAM to work with. The questions I have aren't in the area of programming, but deal with manufacturing cartridges for the finished game, so I really need to talk with some old M-Network engineers for that... or maybe anyone who's *created* a bankswitching method of their own, as I'm interested in the possibility of extending the M-Network bankswitching design to allow for even more ROM and (especially) RAM.

912072[/snapback]

 

With luck, in a few weeks I should have a working cartridge with a wonderful new bankswitching design. 64K ROM + 32K RAM; three areas of bankswitched addressed space:

$1000-$10FF : One of 128 banks of RAM

$1100-$17FF : One of 16 banks of RAM or one of 32 banks of ROM, aligned to start 256 bytes after a 2K boundary

$1800-$1FFF : One of 32 banks of ROM

 

The RAM areas will have a switchable write-protect function. When write-protected, all forms of read access will be allowed. When not write-protected, all forms of read access will be allowed EXCEPT that (1) indexed operations across page boundaries will be forbidden; (2) code execution from non-write-protected RAM will be forbidden. Write access will be allowed via indexed and indirect indexed modes only; read-modify-write instructions will be allowed via non-indexed-addressing modes only (indexed read-modify-write instructions may work, but would rely upon a floating bus to hold its value and should thus not be considered trustworthy).

 

I don't think I've seen any other cartridge use timing to distinguish reads from writes, but it seems like it should be a good method to allow a generous amount of RAM to be accessed without wasting address space.

Link to comment
Share on other sites

I'm currently working on (or perhaps I should say, *not* working on) a huge adventure game that uses the M-Network bankswitching method, so I can have 16K of ROM, but most importantly, 2K of extra RAM to work with. The questions I have aren't in the area of programming, but deal with manufacturing cartridges for the finished game, so I really need to talk with some old M-Network engineers for that... or maybe anyone who's *created* a bankswitching method of their own, as I'm interested in the possibility of extending the M-Network bankswitching design to allow for even more ROM and (especially) RAM.

912072[/snapback]

 

With luck, in a few weeks I should have a working cartridge with a wonderful new bankswitching design. 64K ROM + 32K RAM; three areas of bankswitched addressed space:

$1000-$10FF : One of 128 banks of RAM

$1100-$17FF : One of 16 banks of RAM or one of 32 banks of ROM, aligned to start 256 bytes after a 2K boundary

$1800-$1FFF : One of 32 banks of ROM

 

The RAM areas will have a switchable write-protect function. When write-protected, all forms of read access will be allowed. When not write-protected, all forms of read access will be allowed EXCEPT that (1) indexed operations across page boundaries will be forbidden; (2) code execution from non-write-protected RAM will be forbidden. Write access will be allowed via indexed and indirect indexed modes only; read-modify-write instructions will be allowed via non-indexed-addressing modes only (indexed read-modify-write instructions may work, but would rely upon a floating bus to hold its value and should thus not be considered trustworthy).

 

I don't think I've seen any other cartridge use timing to distinguish reads from writes, but it seems like it should be a good method to allow a generous amount of RAM to be accessed without wasting address space.

912117[/snapback]

 

Supercat, that sounds super cool! I'm not sure if I've really understood what you wrote yet, but I'll read it over and percolate on it.

 

How does one go about creating a new bankswitching scheme? I'm no engineer, so your answer will probably be lost on me, but others might like to know.

 

As for myself, I had thought about simply adding more addresses to M-Network's scheme, to swap in additional banks of ROM or RAM. But I'm developing my game on an emulator, so for now I'm restricted to using the basic M-Network scheme, since the emulator won't recognize anything new (unless I modify the emulator, which is beyond me right now).

 

Anyway, best of luck with getting your cart up and running!

 

Michael Rideout

Link to comment
Share on other sites

A historical note:

Glenn was one of the "founding fathers" of [stella].

(I think there's some tie-in with the "stella gets a new brain" project too.

 

But I think it veered from where he originally saw it going: he became fascinated with the idea of the supercharger becoming the de facto way of distributing exciting new atari games. But Packrat/Hozer showed up (as much as I like AA I think they were first) with burning carts, and for nostalgia reasons (hey I'm making what I played in my childhood!) and practical ones (there are only so many superchargers to go around) making carts has been the primary expression of homebrew activity.

 

But Glenn is willing to put his money (some kind of bonus from his job) where his heart is, and try to entice people to *finally* do a 2600 game that can *only* be done on supercharger.

 

As for bB...I think he just likes that as well. Honestly I wish the contest was after bB was more stable and mature, but still. Also, if it were my world/contest, I would be more interested in something that used bB *without* a lot of assembly, not just as "glue logic"...and/or maybe a seperate prize for someone who did the most work in kernals that *anyone* could take advantage of in their bB program.

Link to comment
Share on other sites

A historical note:

Glenn was one of the "founding fathers" of [stella].

(I think there's some tie-in with the "stella gets a new brain" project too.

 

Exactly right. I'm one of the ones that bought the original CD. Very cool project. Have got a super charger too. (Isn't there some way we could make more of these?)

 

But I think it veered from where he originally saw it going: he became fascinated with the idea of the supercharger becoming the de facto way of distributing exciting new atari games. But Packrat/Hozer showed up (as much as I like AA I think they were first) with burning carts, and for nostalgia reasons (hey I'm making what I played in my childhood!) and practical ones (there are only so many superchargers to go around) making carts has been the primary expression of homebrew activity.

 

I was excited about that too. --never happened. One biggie today is the development tools are much better than they were when Stella was launched.

 

But Glenn is willing to put his money (some kind of bonus from his job) where his heart is, and try to entice people to *finally* do a 2600 game that can *only* be done on supercharger.

 

As for bB...I think he just likes that as well. Honestly I wish the contest was after bB was more stable and mature, but still.  Also, if it were my world/contest, I would be more interested in something that used bB *without* a lot of assembly, not just as "glue logic"...and/or maybe a seperate prize for someone who did the most work in kernals that *anyone* could take advantage of in their bB program.

 

I dunno. My gut says the 2600 is just a bit too limited to allow this to reach a good potential. Of course we have been proven wrong before. I'm open minded on this topic.

Link to comment
Share on other sites

I was excited about that too.  --never happened.  One biggie today is the development tools are much better than they were when Stella was launched. 

Well, that's true, but I still think it's a combination of emulators (for people to quickly distribute and try out stuff) and burnt carts, rather than say development tools pushing the what's possible envelope, that set the non-supercharger course of this history.

 

As for bB...I think he just likes that as well. Honestly I wish the contest was after bB was more stable and mature, but still.  Also, if it were my world/contest, I would be more interested in something that used bB *without* a lot of assembly, not just as "glue logic"...and/or maybe a seperate prize for someone who did the most work in kernals that *anyone* could take advantage of in their bB program.

I dunno. My gut says the 2600 is just a bit too limited to allow this to reach a good potential. Of course we have been proven wrong before. I'm open minded on this topic.

What, the 2600 is too limited to not require custom kernals and whatnot?

bB development will probably largely fork into "using the standard kernal library" and a smaller group of "heavy use of custom kernals". There's an even smaller group that need to have ASM in the gamelogic as well, like to squeeze maximum use out of memory or what not, but I think overall bB "straight" can handle most gamelogic stuff.

 

And in some ways I find the group that does everything without ASM more interesting...if you do everything tough in ASM, bB is basically just a big macro to save you from writing conditionals and the other easy stuff in ASM.

Link to comment
Share on other sites

I was excited about that too.  --never happened.  One biggie today is the development tools are much better than they were when Stella was launched. 

Well, that's true, but I still think it's a combination of emulators (for people to quickly distribute and try out stuff) and burnt carts, rather than say development tools pushing the what's possible envelope, that set the non-supercharger course of this history.

 

And in some ways I find the group that does everything without ASM more interesting...if you do everything tough in ASM, bB is basically just a big macro to save you from writing conditionals and the other easy stuff in ASM.

912436[/snapback]

 

 

Agreed. That was all inclusive in my view. (carts, etc...)

 

I think I'll end up being a mix of the three. Doubt I'll touch the kernel this time around. (Could happen though.) Having inline bits in the language is very cool. --and powerful. The language will grow to eliminate many of my current uses at least.

 

Having said that, there is a real charm to how it works right now. It's close to the CPU --and I like that. It's very easy to think in terms of a simple language that runs really fast. As long as language development does not get in the way of that, I'm happy.

Edited by potatohead
Link to comment
Share on other sites

If I can see evidence that the game started off as mostly bBasic, and the basic stuff eventually gets removed by the time the judging starts, I'm not going to disqualify it. I would like to reward people for taking off the training wheels. If they never needed the training wheels to begin with, then they shouldn't be in this contest category. After all, the Supercharger contest has twice the purse! You have to trust I'll be able to know the difference between these two types and not let the contest be abused.

 

And remember that if you write a simplistic game that sticks pretty closely to bBasic limitations, but it's a whole new game, not a port, I will rank it higher than a technically dazzling port of a "done to death" game.

 

Creativity can mean more than sheer programming ability.

 

I take nothing away from stuff like Marble Craze or Thrust+, but I still think Oystron is the best of them all and it's only 4K.

 

The technical aspect is more of a factor in the Supercharger contest, although even there I still want the games to hold up and not just be a tech demo for the sake of being a tech demo.

 

Link to comment
Share on other sites

The only problem (for me, at least) is that I can't seem to subscribe to this mailing list... I keep getting Internal Service Errors!  Anyone have any suggestions as to how I can fix this problem?

 

JR

909908[/snapback]

 

Jess, did you ever get subscribed to Stellalist? It turns out you have to click on the link that says *unsubscribe*, then when it takes you to the next page, you can say that you want to subscribe, and it will work. (Thanks to Russ, who set me straight!)

 

Michael Rideout

Link to comment
Share on other sites

I take nothing away from stuff like Marble Craze or Thrust+, but I still think Oystron is the best of them all and it's only 4K.

Yeah, Oystron really blew me away.

 

NickB has the history of it on his Oystrong webpage...it has a great feel, and seeing the old ROMs were interesting.

 

Heehee...I see Glenn has been trying to get people to take advantage of the Supercharger for a long time

Link to comment
Share on other sites

Nope, still getting the Internal Server Error.  Thanks for the advice, though.

 

JR

913175[/snapback]

 

Go to http://stella.biglist.com and click "Easy Unsubscribe," then type in your email address, select "Subscribe," follow any instructions or fill in any additional fields, and it should work.

 

Michael Rideout

Link to comment
Share on other sites

Supercat, that sounds super cool! I'm not sure if I've really understood what you wrote yet, but I'll read it over and percolate on it.

912179[/snapback]

 

Well, to implement a new bank-switching scheme in hardware, you need to figure out what signals need to control the bank-switching, and what signals need to be controlled by the bank-switching, and wire them into a programmable logic device. If you want RAM, you also have to wire in the appropriate control wires for that. Then you need to describe how the bank switching device is supposed to work either using a schematic package or using one of several 'languages' including VHDL, ABEL, etc. Then you need to build a cart, program the CPLD using appropriate software, plug it all in, and see what happens.

 

If the hardware works, you then ask the emulator people real nicely if they can add your scheme to the emulator. :)

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

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...