Re: [stella] compiler?

Subject: Re: [stella] compiler?
From: "nj bloodline" <njbl00dline@xxxxxxxxxxx>
Date: Fri, 27 Jul 2001 15:07:08 -0400
My idea was to make a Game Maker that you draw stuff, tell it where to go on
the screen and what it does and hit a button and it makes the whole Atari
2600 game for you.

There are plenty of other game design softwares out there.. some have
standard routines in them... like for instance, you draw something and
define it as player, enemy, etc. If it's enemy you can pick it's movement
path - random movement, follow a path, bounce off wall, etc.

You tell the program what happens when item a and item b collide.

Etc, etc.. you get the idea. Basically it's kinda like WYSIWYG (what you see
is what you get).

----- Original Message -----
From: "Ben Larson" <wazzapfool@xxxxxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Thursday, September 06, 2001 1:33 PM
Subject: [stella] compiler?

> Has anyone ever considered making a compiler that
> generates Atari 2600 code?  I know it sounds like a
> pretty farfetched idea, but I was thinking maybe
> something scaled down at first.  Obviously creating a
> compiler that would be able to abstract all the nasty
> details of making a really graphically-intense game
> (like Pitfall for instance) would be near-impossible.
> That's not what I had in mind.  What I had in mind was
> something that would just let you do console
> text-based stuff a la old DOS text-based programs, or
> that 2600 game 'Dark Mage'.
> I already have a simple C-esque scripting language I
> wrote with some other guy for a class in college,
> which I was thinking might be a starting point.  The
> implementation was done in C++ and is completely
> object-oriented (the implementation, not the language
> we wrote).  Right now it's interpreted, but it would
> be easy (knock on wood) to convert it into a compiler
> because of the object oriented structure.  All that
> would need to be done would be to write a new 'virtual
> machine' class (one of the 3 C++ classes that
> comprises it) which would take the pseudo-instructions
> given to it from the parser and generate 6502 assembly
> language code instead.
> Anyway the language itself is kinda cool - supports
> integer variables and arrays, string constants, as
> well as 'for' and 'while' loops, procedures, (pseduo)
> local variables, arbitrarily complex conditional
> statements, order-of-operations, etc.  I (or someone
> else) would just need to come up with a 'console
> kernel' to retrive text information from RAM and
> display the characters on-screen, and I think the
> whole thing might be pretty feasable.  Obviously the
> limited processing power of the 2600 might be a
> problem, but I suppose if all of a given program's
> calculations couldn't be done in one screen blank,
> then it could just be spread over multiple screen
> blanks...maybe.  The compiler would likely have to
> count cycles when generating the code, and always
> assume worst-case scenario in order to determine
> whether code would fit into 1 screen blank.  If not,
> it could generate the appropriate subroutine calls to
> draw the screen, and then go on generating code.
> Anyway just a thought, I don't know if anyone would be
> interested in such a thing, since its usefulness, like
> I said, would probably be limited to fairly static
> (text-based) stuff.
> Ben
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo!
> -
> Archives (includes files) at
> Unsub & more at

Archives (includes files) at
Unsub & more at

Current Thread