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 array. > 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 console > 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 overhead. > 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 likely > 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 well. 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 may have to relent on this though, I've only done the most cursory exploration of how it will work (and the only expression evaluators I've written so far have 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 http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] BAStella Language Refe, Glenn Saunders | Thread | Re: [stella] BAStella Language Refe, Chris Wilkson |
Re: [stella] Gunfight Label Contest, Clay Halliwell | Date | Re: [stella] BAStella Language Refe, Roger Williams |
Month |