Re: [stella] BAStella Language Reference V0.000000001

Subject: Re: [stella] BAStella Language Reference V0.000000001
From: "Roger Williams" <mer02@xxxxxxxxxxxxx>
Date: Wed, 21 Nov 2001 18:02:25 -0800
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>

> My first suggestion here is to provide a mechanism for variable reuse.

It's in there -- see NAME.  You can assign the same RAM to act as variables
of totally different type, and any variable can also be the base of an

> Also, for the graphics datatype, you should allow for 0 with the period,
> not just the space.  It's hard to visualize a bit with a space, especially
> when you are using a nonproportional font.

Good idea, consider it added to the spec.  I will probably also allow for a
terminating and break character.

> I would also try to allow for:
> ADR() (to retrieve the address of a variable or register)

Well, it WAS in the spec, though it seems to have slipped through
a crack in the editing.

> USR() (machine language subroutines)

This creates a problem with the VBLANK timing, which must count
cycles.  BAStella can use blocks of code of known length but it has
no way of knowing the timing of code you've written.  (Also, unlike
the situation with an interpreter, you don't get *that* much of a
performance increase by writing your own ML, since you're already
pretty close to the CPU.)

> PEEK()
> POKE()

The "vector" takes care of this.  RAM from $80 to $FF is addressed
as !(0) to !(127).  While technically you're not supposed to access
above VECTOP no bounds checking is done.

> I would also try to provide an abstraction layer for controller and
> routines, so you can set up automatic debouncing.

Hmmmmm, might be an idea.  Could also provide for reading the paddles
and controller keypads.  Of course the library routines could fill up a 4K
cart pretty quick.  Might be a V2.0 thing after I get it to compile at all.

> You may also want to implement simple automatic boundary
> checking/wraparound for the sprites.

Actually, I was thinking it might be better to leave this to the player.
Sometimes you don't need those checks and you could save the

> I also think that in the long run it might be better to enforce strict
> timings on VBLANK processing.  I don't think anybody is going to want to
> play a 2600 game that stutters because the processing is constantly
> spanning frames.  At least it needs to inform the user when there is
> to be too much calculation going on during VBLANK.

There's no reason for the game to stutter _visibly_.  That's what FRAME
is for.  You do your timing, increment your own frame counter, repeat
until your counter matches FRAME.  If you slip on one overlong frame
you catch up on the next, and it's all over in 1/30 second.  I've done the
same trick on a high-speed in-motion checkweigher, and it works quite

In any case, I could probably do this as a different mode.  The idea was
to have something that wouldn't constantly be erroring out with "code too
long" but would instead give you a visceral indication if this was the case
by just running slow.

> I also see no reason not to support passing arguments to functions.  These
> would wind up becoming temp variables that survive only during the calling
> and called functions.

The problem is that the code within a user function may do full math, using
both the accumulator and operand registers.  (BAStella's own functions can
get around this using temp vars, but BAStella has no way of knowing in
advance what resources arbitrary code will want.)  The only way around
this is a math stack, and I'd really like to avoid using the extra RAM.  I
have to relent on this though, I've only done the most cursory exploration
how it will work (and the only expression evaluators I've written so far
been interpreted, using a stack.)  BAStella's expression evaluator will of
course be extremely stacky and recursive in the compiler itself.

In fact, now that I think about it, I have to stack items in order to do
this perfectly legal thing:

LET V1 = NOT(A+B) + NOT(C+D)

Drat.  Oh well, it will be possible to pass arguments to functions.
Hopefully I can at least use the code stack to do this so I don't need a
whole 'nother memory area.

Thanks for the suggestions!

--Roger Williams

Archives (includes files) at
Unsub & more at

Current Thread