Re: [stella] compiler?

Subject: Re: [stella] compiler?
From: Ben Larson <wazzapfool@xxxxxxxxx>
Date: Thu, 6 Sep 2001 13:00:01 -0700 (PDT)
OK I did some more thinking about this at work. :)  I
started thinking that the whole text-based console
kernel might not be as easy as I thought.  For one,
I'm pretty sure it would have to involve some trickery
with the player graphics to get any decent text
resolution...inputting numbers would be kinda
difficult to do too with a joystick. :)

Maybe something more useful would be a compiler that
would support 'real' graphics, but just support a
fairly simple display kernel (at first anyway) - i.e.
two player sprites that can be positioned anywhere
on-screen, a ball that can be positioned anywhere, and
a symmetrical playfield.  Then everyone could make
their own Combat clone in a high(er) level language!


P.S. Sorry if I'm offending any assembly-language
purists with all this talk of high-level languages :)

--- Ben Larson <wazzapfool@xxxxxxxxx> wrote:
> 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! Messenger
> -
> Archives (includes files) at
> Unsub & more at

Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger

Archives (includes files) at
Unsub & more at

Current Thread