Re: [stella] VCS C programming

Subject: Re: [stella] VCS C programming
From: Kevin Lipe <kevin.lipe@xxxxxxxxx>
Date: Wed, 18 May 2005 01:09:53 -0400
What about a higher-level language that abstracted away all the
bit-level comparing that is done on each scanline, and allows
if/then/else, do/while, etc. high level things to be determined by the
compiler and then converted to optimized 6502 code? This way every
kernel is still customized, but some of the boolean operations and
branch instructions are handled by the language and compiler instead
of the programmer... I don't think you could ever create a high level
language that would create game kernels efficient enough for a
"production" homebrew, but such a language would help with rapid
prototyping of ideas. The kernel generated by the higher-level
language could then be analyzed and optimized as an assembly-language
program once the basics are in place...

Does that make sense? A language that abstracts away some of the more
time-consuming portions of 2600 programming in order to enable rapid
prototyping of an idea, and then once the prototype is "sort-of"
functional (as in, a simple demonstration of a gameplay idea) the
compiler outputs to a DASM-ready .s file for the programmer to
continue work on. I think that'd be good.

~ kevin
On 5/17/05, Kirk Israel <kirkjerk@xxxxxxxxx> wrote:
> Wow, interesting philisophical point.
> I've done about as much as anyone in terms of trying to tamp down the
> initial learning curve for 2600 coding, but I absolutely see Fred's
> point.
> The article of faith is almost less "it can't be done" and more "it
> could probably be done but the resulting games wouldn't be worthwhile"
> I guess there are two questions: how flexible will the available
> kernals be, and will it stir people's creativity to make lots of neat
> stuff, or will it just lead to a flood of crap...does the dedication
> learning 6502 and all the TIA stuff provide a useful trial by fire, or
> does it mostly get in the way? (ok, that's 3 or 4 questions, but
> whatever..)
> I guess the risk is it would make the homebrew scene look like the
> hacks scene...hmm.
> On 5/18/05, Fred Quimby <c9r@xxxxxxxxxxx> wrote:
> > >Now I know that the resulting games would not be as groundbreaking
> > >and distinctive as all-from-scratch 2600 games. But as you say, it would
> > >broaden the hobby. And the actual creating of the tool itself
> > >would be *very* groundbreaking and distinctive, since everyone has
> > >taken it as an article of faith that it Can't Be Done. (:
> >
> > I'd be surprised if anyone said it can't be done.  I have seen discussions
> > in the past that indeed said it would be difficult but certainly not
> > impossible, as long as you used prepackaged kernels.
> >
> > Now, I hate to be the only dissenter here, but I think this is all a bad
> > idea, given the requirement for prepackaged kernels!  Perpackaged kernels
> > lead to games that are all essentially the same.  I think that "less than
> > groundbreaking" is an understatement.  I think that this would not broaden
> > the hobby at all, but instead diminish it with a flood of games that are
> > mostly bad or at best mediocre, or perhaps even discourage programmers like
> > me who have spent countless hours trying to do real 2600 programming,
> > essentially killing the hobby with a mini-crash reminiscent of the original
> > crash of '82-'83.
> \
> Archives (includes files) at
> Unsub & more at
Archives (includes files) at
Unsub & more at

Current Thread