Re: [stella] BAStella Language Reference V0.000000001

Subject: Re: [stella] BAStella Language Reference V0.000000001
From: Erik Mooney <erik@xxxxxxxxxx>
Date: Wed, 21 Nov 2001 10:46:57 -0500
>Among the things I'd like to hear from my comrades here...
>
>1. Is this a good idea, or would it just ruin the mystique?

If successful, I think it would in fact dilute the homebrew scene a bit,
same as the C compiler dev kit did for the Gameboy homebrew scene.
But that's not necessarily a bad thing, just as long as Braves4515
doesn't get wind of this. :)  (Although I'm wondering if he inspired you?)

>2. Is it workable as presented?

Looks sound theoretically.

>3. Is anybody interested in using it?

That's the question.  You can do, what, Combat and Adventure with it?
(Actually, maybe even Gunfight with static reflected PF :) )

>The default BAStella kernal draws all five screen objects over
>a non-asymmetrical playfield, but other kernal options are
>available including scores, and the kernal types can be mixed
>on a single screen.

If you could work it so that BAStella code could run during the
kernel, you could do some pretty sophisticated stuff along the lines
of Air-Sea Battle or River Raid.  As in, call the five-object kernel and
tell it to run for, say, 10 lines, then reposition some objects and
call it again.  This would also be a great intermediate step between
basic functionality and full assembly - introducing the concepts of
rewriting objects during the screen without yet getting bogged down
in cycle counting.

>BAStella doesn't create a re-assemblable .asm file, since
>it would greatly complicate BAStella and DiStella can do that.
>(I may change my mind on this, as it depends on some nuts and
>bolts I haven't fully worked out.)

If I were doing the project, I'd probably go this route.  It might be easier
to have BAStella generate that instead of essentially writing your own
assembler as part of the project.  This effectively makes BAStella
a high-level abstraction of the 6502 and TIA rather than a language in
its own right.

> ON exp GOTO label0, label1, label2, label3...
>
>(ON...GOTO is an oldie but goodie which can be implemented even
>more efficiently than SELECT CASE, since the CASEs are both fixed
>and consecutive so DEC can be used to successively check them.)

This can be implemented directly in 6502 assembler with Indirect JMP.
Just gotta be careful on a bounds check for exp.

>Functions cannot have arguments because of no math
>stack.

I think you could allow one argument in the accumulator.

>I normally don't like requiring variables to be DIMensioned,
>but it's kind of a duh thing here.

Every variable should always be declared, in every language. Sometimes
the structured-programming guys do have it right. :)

>* Wonk question: Where's the math stack?

*Wonk question 1A: How in the world are you going to multiply and divide?




----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/


Current Thread