Re: [stella] BAStella Language Reference V0.000000001

Subject: Re: [stella] BAStella Language Reference V0.000000001
From: "Roger Williams" <mer02@xxxxxxxxxxxxx>
Date: Sat, 24 Nov 2001 16:20:13 -0800
From: Clay Halliwell
> Remind me again how you're planning on pulling this off? Game logic is
> rarely deterministic... there's no practical way for the compiler to
> calculate in advance exactly how long a given chunk of code will take to
> execute.  How would your compiler deal with something as simple as...
> FOR I = 1 TO N
>     yadda yadda
> ...where N could be *anything*?

The timer check is really simple, if the accumulator is clear (which
it is much of the time, and compilers have to know this stuff
 LDA #$FC ;[0]+2
 AND INTIM ;[2]+3
 BNE .+5  ;[5]+3
 JSR Kernal
[BNE dot-plus-5 lands here]

This takes takes 8 cycles and clears the way for the next 256, 
less overhead.  It's messier if you have to stash ACC but not
much worse.  Probably the default which stashes the ACC
will be invoked whenever the byte expression evaluator is
active, and the 8-cycle version at the earliest suitable time
anyplace else.

You place this snippet at < 200 cycle (it can be approximate)
intervals, plus at the junction of every branch.  Since the FOR
statement has a branch, the check will get refreshed.  I figure
this will add ~10% overhead to the code, plus the 300%
overhead of the kernal.  OTOH it's an integer compiler with
few functions, so it has inherent speediness to draw against.

Of course you get the worst performance in a tight loop,
but loops will by their nature clear the way for using the 8-cycle
version of the check so it's hard to imagine the overhead getting
bigger than 15% to 30%, even if you're copying a vector into
RAM  or something like that.

Lib routines, like the notoriously inefficient multiplication,
can be preceeded by automatic checks as appropriate to
their worst-case runtimes, so they don't have to do this
unless they are *really* hogs, and then they can be more
carefully optimized.

End result, the object code keeps the kernal refreshed and
as a programmer all you notice about it is that you seem to
be programming for a 200 kHz processor.  The first
computer I ever saw had iron core RAM and ran at 175
kHz, so that doesn't bother me.  It's useable.

--Roger Williams

Archives (includes files) at
Unsub & more at

Current Thread