Jump to content

Photo

Intellivision Programmer's Questionnaire


32 replies to this topic

Poll: Intellivision Programmer's Questionnaire (17 member(s) have cast votes)

What's your language of choice?

  1. IntyBASIC (12 votes [70.59%])

    Percentage of vote: 70.59%

  2. Assembly Language (5 votes [29.41%])

    Percentage of vote: 29.41%

If you chose IntyBASIC, is it because...

  1. I love BASIC (0 votes [0.00%])

    Percentage of vote: 0.00%

  2. Assembly Language is too hard (6 votes [21.43%])

    Percentage of vote: 21.43%

  3. I am not a programmer, so BASIC seems easier to learn (0 votes [0.00%])

    Percentage of vote: 0.00%

  4. I hate Assembly Language (1 votes [3.57%])

    Percentage of vote: 3.57%

  5. IntyBASIC offers the features I need (8 votes [28.57%])

    Percentage of vote: 28.57%

  6. The IntyBASIC SDK makes programming games simpler (3 votes [10.71%])

    Percentage of vote: 10.71%

  7. There isn't a comparable Assembly SDK to make programming more accessible (2 votes [7.14%])

    Percentage of vote: 7.14%

  8. I already knew BASIC, so I'm comfortable with it (3 votes [10.71%])

    Percentage of vote: 10.71%

  9. Not applicable, I chose the other one (5 votes [17.86%])

    Percentage of vote: 17.86%

If you chose Assembly Language, is it because...

  1. I love Assembly, it gives me full power of the machine (5 votes [21.74%])

    Percentage of vote: 21.74%

  2. I hate BASIC (2 votes [8.70%])

    Percentage of vote: 8.70%

  3. That's what I know, and I can't be bothered to learn anything new (1 votes [4.35%])

    Percentage of vote: 4.35%

  4. IntyBASIC doesn't do everything I want (2 votes [8.70%])

    Percentage of vote: 8.70%

  5. The IntyBASIC programming model is different from mine (2 votes [8.70%])

    Percentage of vote: 8.70%

  6. I have my own Assembly Language library already that works for me (2 votes [8.70%])

    Percentage of vote: 8.70%

  7. I don't like "SDK" and frameworks that try to do stuff for me (0 votes [0.00%])

    Percentage of vote: 0.00%

  8. Not applicable, I chose the other one (9 votes [39.13%])

    Percentage of vote: 39.13%

What "platform" do you ultimately target with your games?

  1. Emulation (ROM) - Any emulator (2 votes [11.76%])

    Percentage of vote: 11.76%

  2. Emulation (ROM) - jzIntv (5 votes [29.41%])

    Percentage of vote: 29.41%

  3. Hardware (PCB) - 16K classic "Mattel" cartridge (2 votes [11.76%])

    Percentage of vote: 11.76%

  4. Hardware (PCB) - JLP (2 votes [11.76%])

    Percentage of vote: 11.76%

  5. Hardware (PCB) - Any (4 votes [23.53%])

    Percentage of vote: 23.53%

  6. Hardware (PCB) - Other (1 votes [5.88%])

    Percentage of vote: 5.88%

  7. Hardware (Flash) - LTO Flash! (1 votes [5.88%])

    Percentage of vote: 5.88%

If your target platform supports "special features," which ones do you actually use?

  1. On-board non-volatile memory (Flash RAM) for save-states, etc. (5 votes [20.83%])

    Percentage of vote: 20.83%

  2. On-board extended memory (Cartridge RAM) (5 votes [20.83%])

    Percentage of vote: 20.83%

  3. ROM Bank-switching (3 votes [12.50%])

    Percentage of vote: 12.50%

  4. None, I try to keep it "old-school" (11 votes [45.83%])

    Percentage of vote: 45.83%

If you use jzIntv as part of your development environment, which features do you actually use?

  1. Just the emulator to test my game (9 votes [52.94%])

    Percentage of vote: 52.94%

  2. Regular debugger (breakpoints, watches, register view, memory peek/poke, etc.) (3 votes [17.65%])

    Percentage of vote: 17.65%

  3. Source-level debugging (all debugging features, plus source file and symbol mapping) (5 votes [29.41%])

    Percentage of vote: 29.41%

  4. I don't use jzIntv (0 votes [0.00%])

    Percentage of vote: 0.00%

Which of the following do you consider "standard" in modern Intellivision home-brew development?

  1. 42K memory map (12 votes [21.05%])

    Percentage of vote: 21.05%

  2. Cartridge RAM (for game variables) (11 votes [19.30%])

    Percentage of vote: 19.30%

  3. Flash RAM (for save-states) (8 votes [14.04%])

    Percentage of vote: 14.04%

  4. Bank-switching for extra-large games (9 votes [15.79%])

    Percentage of vote: 15.79%

  5. 60hz game loops (5 votes [8.77%])

    Percentage of vote: 8.77%

  6. Voice synthesis (i.e. Intellivoice on-board) (6 votes [10.53%])

    Percentage of vote: 10.53%

  7. Two PSGs (i.e. ECS on-board) (2 votes [3.51%])

    Percentage of vote: 3.51%

  8. Cartridge acceleration features (4 votes [7.02%])

    Percentage of vote: 7.02%

Which of the following programming libraries/features do you use or would use if they were available in your language of choice?

  1. Pseudo-random number generator (9 votes [13.04%])

    Percentage of vote: 13.04%

  2. Event-driven hand-controller decoder (without having to poll periodically yourself) (5 votes [7.25%])

    Percentage of vote: 7.25%

  3. Music Player/Tracker (10 votes [14.49%])

    Percentage of vote: 14.49%

  4. Timers for triggering periodic or timed events (5 votes [7.25%])

    Percentage of vote: 7.25%

  5. Autonomous MOB displacement (i.e., set velocities and their positions are updated automatically) (3 votes [4.35%])

    Percentage of vote: 4.35%

  6. Smooth scrolling (6 votes [8.70%])

    Percentage of vote: 8.70%

  7. Text-to-speech (3 votes [4.35%])

    Percentage of vote: 4.35%

  8. Sprite animation (i.e., give an array of picture cards and a frame-rate and MOB is updated automatically) (5 votes [7.25%])

    Percentage of vote: 7.25%

  9. Optimized physics functions (projectile trajectory, convergence, acceleration, friction, gravity, etc.) (4 votes [5.80%])

    Percentage of vote: 5.80%

  10. Optimized trigonometry functions (sine, cosine, tangent, etc.) (2 votes [2.90%])

    Percentage of vote: 2.90%

  11. Event-driven collisions (based on regions or bounding-boxes) (6 votes [8.70%])

    Percentage of vote: 8.70%

  12. An Integrated Development Environment (IDE) (6 votes [8.70%])

    Percentage of vote: 8.70%

  13. Nothing, I just need access to the hardware and I can do everything myself (5 votes [7.25%])

    Percentage of vote: 7.25%

The primary reason you program Intellivision games is...

  1. for fun! fun! fun! (8 votes [47.06%])

    Percentage of vote: 47.06%

  2. for the chicks and the parties (1 votes [5.88%])

    Percentage of vote: 5.88%

  3. to get rich and famous (3 votes [17.65%])

    Percentage of vote: 17.65%

  4. to help others with their own projects (1 votes [5.88%])

    Percentage of vote: 5.88%

  5. for the challenge (2 votes [11.76%])

    Percentage of vote: 11.76%

  6. to keep busy during summer vacation or train commute (0 votes [0.00%])

    Percentage of vote: 0.00%

  7. Other (2 votes [11.76%])

    Percentage of vote: 11.76%

  8. as a side job for spare cash (beer money, pay rent, medical bills, vices, etc.) (0 votes [0.00%])

    Percentage of vote: 0.00%

Are you actively programming for the Intellivision?

  1. Yes (8 votes [47.06%])

    Percentage of vote: 47.06%

  2. No (1 votes [5.88%])

    Percentage of vote: 5.88%

  3. On and off, when I get the chance (8 votes [47.06%])

    Percentage of vote: 47.06%

Vote Guests cannot vote

#26 artrag ONLINE  

artrag

    Stargunner

  • 1,122 posts

Posted Fri Jun 29, 2018 1:46 AM

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 by artrag, Fri Jun 29, 2018 1:49 AM.


#27 DZ-Jay ONLINE  

DZ-Jay

    Quadrunner

  • Topic Starter
  • 11,273 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sat Jun 30, 2018 4:35 AM

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... :lol:)

 

    -dZ.



#28 artrag ONLINE  

artrag

    Stargunner

  • 1,122 posts

Posted Sat Jun 30, 2018 4:53 AM

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 by artrag, Sat Jun 30, 2018 4:59 AM.


#29 DZ-Jay ONLINE  

DZ-Jay

    Quadrunner

  • Topic Starter
  • 11,273 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sat Jun 30, 2018 5:17 AM

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.



#30 Darkhog OFFLINE  

Darkhog

    Chopper Commander

  • 167 posts

Posted Sun Jul 1, 2018 3:38 PM

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.



#31 nanochess OFFLINE  

nanochess

    Processorus Polyglotus

  • 5,573 posts
  • Coding something good
  • Location:Mexico City

Posted Sun Jul 1, 2018 6:30 PM

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.

#32 DZ-Jay ONLINE  

DZ-Jay

    Quadrunner

  • Topic Starter
  • 11,273 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Mon Jul 2, 2018 3:19 AM

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.



#33 Darkhog OFFLINE  

Darkhog

    Chopper Commander

  • 167 posts

Posted Mon Jul 2, 2018 2:13 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users