Intellivision Programmer's Questionnaire

[artrag]

I would love to have variables with scope and reuse of the ram for variables that do not need to hold a state across different function calls.

But it is matter of tastes.

Probably an external pre-processor of .bas files could add this feature.

Edited June 29, 2018 by artrag

[+DZ-Jay]

I would love to have variables with scope and reuse of the ram for variables that do not need to hold a state across different function calls.

But it is matter of tastes.

Probably an external pre-processor of .bas files could add this feature.

 

You mean lexical variables with local scope within a subroutine? That may not be a bad idea. I have considered implementing something like this in my framework using stack frames. Perhaps IntyBASIC could do something similar: create local variables in the stack, and pop them out of scope on return.

 

It could follow Microsoft's evolution of BASIC (VB) and require a "Dim" to allocate variables so that their scope is unambiguous. It could also support the same loose semantics: variables encountered without pre-definition with "Dim" are assumed to be in the global scope. (Then it's just a small step from there to implement the "Option Explicit" directive to require strict allocation and typing... )

 

-dZ.

[artrag]

You can also use static linking instead of the stack. The generated asm code is faster but it needs to study the three of the calls and does not allow recursion.

Basically, two local variables in functions that do not call each other directly or indirectly can share the same ram location.

 

The riddle is to allocate different ram locations for local variables along all branches and sub-branches of execution.

Only independent branches can overlap variables in ram.

Edited June 30, 2018 by artrag

[+DZ-Jay]

You can also use static linking instead of the stack. The generated asm code is faster but it needs to study the three of the calls and does not allow recursion.

Basically, two local variables in functions that do not call each other directly or indirectly can share the same ram location.

 

The riddle is to allocate different ram locations for local variables along all branches and sub-branches of execution.

Only independent branches can overlap variables in ram.

 

That's what I do in my framework, but that's because in P-Machinery, there is a concept of "Game States" (or phases) baked into the programming model, so there is a very natural division of scope: each state is mutually exclusive. By (ab)using the assembler's symbol table, I allow overlapping blocks of RAM to be re-used in each game state. The only drawback is that, being just assembler symbols, the namespace cannot be scoped, so the names must always be unique across the global space. It's still an enhancement built upon a foundation of static allocation provided by the CART.MAC library.

 

I can get away with that because of the loose semantics of "variables" in the Assembly model, which does not guarantee much.

 

I thought for IntyBASIC it may not be that simple, since it doesn't just use the symbol table, but needs to track variable usage dynamically across the program. This is, I think, the reason why they are typically just all global in many implementations of BASIC. But then again, I haven't seen IntyBASIC source code, so I don't know.

 

Either way, lexically scoped variables would not be a bad addition to IntyBASIC.

 

-dZ.

[Darkhog]

IntyBASIC v1.4.0 allows support for playing music in 2 PSG, also MUSIC GOSUB and MUSIC RETURN to save space creating subsongs.

 

Also allows MUSIC VOLUME and MUSIC SPEED to change volume and speed in the fly, very useful when a song includes fast parts but not all song

 

It will be released once the IntyBASIC 2018 Programming Contest is finished because the v1.2.9 of the compiler is required to build, in the meanwhile people can give a look to the Github https://github.com/nanochess/IntyBASIC

Cool. Any plans of adding a way to specify instrument envelopes in code without having to go to prologue/epilogue? From what I've read the syntax is similar for both so it could be done. This way you could have different instruments at play and music in all games won't sound the same. Yeah, I know you can change them in epilogue/prologue but the process to do so isn't straight-forward not to mention that you're basically editing a default template and will have to revert back if it's just for a specific cart.

[+nanochess]

Cool. Any plans of adding a way to specify instrument envelopes in code without having to go to prologue/epilogue? From what I've read the syntax is similar for both so it could be done. This way you could have different instruments at play and music in all games won't sound the same. Yeah, I know you can change them in epilogue/prologue but the process to do so isn't straight-forward not to mention that you're basically editing a default template and will have to revert back if it's just for a specific cart.

I've plans for it.

 

I need to optimize first the player to release some 16 bits variables in order to put the wave pointers.

[+DZ-Jay]

I've plans for it.

 

I need to optimize first the player to release some 16 bits variables in order to put the wave pointers.

 

How about making the envelope instruments statically defined? Similar to what you have today, but exposing the mechanism to the programmer. You wouldn't need extra variables for that.

 

-dZ.

[Darkhog]

I'd rather have it dynamic since it would give much more flexibility to the coder - many more instruments could play, just only 4 at the same time.