Intellivision Programmer's Questionnaire

[+DZ-Jay]

Hello everyone!

I thought I'd put together a short questionnaire for Intellivision programmers. The purpose is mostly to bring to light what others are doing and how they work. Although I know that there are a lot more IntyBASIC programmers than Assembly Language ones out there, in the poll I try to gauge the reasons for picking one over the other.

The poll is just for fun, so there's no special motivation behind it and the results are not intended to drive anything afterwards. I do hope it serves to show where the programmers see the community going.

I invite all Intellivision programmers -- experts, newbies, dabblers, lurkers, etc. If you have ever touched Intellivision programming tools at some point, your participation is welcomed.

So have at it, and please be honest with your answers. If anybody has any additional comments regarding the poll questions, or feedback on programming tools and approaches, please feel free to post in the thread

Cheers!
-dZ.

[carlsson]

A few comments/suggestions about missing options:

 

If you chose IntyBASIC, is it because...

* I know assembly language on a different platform, but is too lazy to learn another one

* Not applicable, but the forum won't let me submit the form without a choice

 

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

* Not applicable, but the forum won't let me submit the form without a choice

[+DZ-Jay]

Fixed! Thanks for that!

[+nanochess]

At last a poll that my little programmer's mind can understand

[Kiwi]

I don't know how assembly works for the Intellivision and attempted to add a debugger that write the content on to the screen upon stack overflow. It wrote some of it and then crashes. I know how to write assembly for Atari 2600 and I studied the Atari 2600 for many years. I wrote 2 games, one is on this forums, and one tool for sound data to hear what sound Atari 2600 can make with it complicated sound chip. I don't know how the Intellivision works using assembly and what's needed to keep the game to work. Z80 assembly is still new to me but have succeeded using the Colecovision call function to load tiles on screen. IntyBASIC makes it really easy and generate good result. And the game can run at 60 fps. If it couldn't then I have to split it to 30 fps, which game don't show slowdown. Writing Colecovision in C is just as easy as writing in IntyBASIC. Unlike C, Intybasic don't nag about the semicolon thankfully. I still want my variable++ to cut down on typing to increase variable by 1 . Atari 2600 assembly you can just use, INC variable. 5 cpu cycles ^_^. Um anyway, I really like IntyBASIC and IntyCOLOR, which both help me with developing games.

 

The primary goal is to make a game. So Intybasic meet those goals.

Edited June 13, 2018 by Kiwi

[+DZ-Jay]

I don't know how assembly works for the Intellivision and attempted to add a debugger that write the content on to the screen upon stack overflow. It wrote some of it and then crashes. I know how to write assembly for Atari 2600 and I studied the Atari 2600 for many years. I wrote 2 games, one is on this forums, and one tool for sound data to hear what sound Atari 2600 can make with it complicated sound chip. I don't know how the Intellivision works using assembly and what's needed to keep the game to work. Z80 assembly is still new to me but have succeeded using the Colecovision call function to load tiles on screen. IntyBASIC makes it really easy and generate good result. And the game can run at 60 fps. If it couldn't then I have to split it to 30 fps, which game don't show slowdown. Writing Colecovision in C is just as easy as writing in IntyBASIC. Unlike C, Intybasic don't nag about the semicolon thankfully. I still want my variable++ to cut down on typing to increase variable by 1 . Atari 2600 assembly you can just use, INC variable. 5 cpu cycles ^_^. Um anyway, I really like IntyBASIC and IntyCOLOR, which both help me with developing games.

 

The primary goal is to make a game. So Intybasic meet those goals.

So, just to be sure I understand your position, you don't dislike Assembly, but don't use it because you do not know how it works on the Intellivision. On top of that, you like IntyBASIC because it makes it easy to make games. Is this correct.

 

That's all cool. . Make sure to make your choices count on the poll.

 

One question I want to ask is, if there was an easier or more sophisticated way to make make Intellivision games in Assembly, would you try it? (It could be an IDE, a framework or library, a bunch of tutorial or sample code, a complete SDK or "game development kit" with a bunch of pre-made routine that do the hard work for you, etc.).

 

In other words, is it the actual Assembly Language that keeps you away, or is it the limited or primitive tools and libraries?

 

Just curious.

 

dZ.

[Kiwi]

I did run into an issue when writing PONG for the Colecovision. I couldn't get the sounds to work. I reviewed the source code that been provided with the newcoleco kit. Didn't know what's going on, this ROM have music, but the source code looks right. Then I was like, ok I'm going to just learn assembly and try to get sounds working that way. I was already half way finished PONG that point. I was slightly upset. Evidently, I compiled the example source code and.... no music. Hmm that's odd? Eventually found a source code that had working sound. Turns out the line that provide the pointer address to the sound table was missing from the source code. So I added the sound table pointer to that source code, and now it plays music. So no need to force myself to work in z80 assembly no more.

 

Intybasic is more easier to program in. If needed, I can look at the epilogue or prologue to see what it is doing under the hood. I can do that with Colecovision C. I have modify Pletter and bitbuster source code to work right, when it failed on the real hardware for not waiting for the vdp to be ready to retrieve data. I could add assembly library if needed. I did ask to see source code out of curiosity how box collision work in z80 to see the structure of the code and how the register get modified from the opcodes. I had z80 wikipedia to see what the opcode do. I also have 6502 opcode wikipedia and vcs.h open while programming atari 2600 games.

All I really need, array, loops, variables, and branches to build my game frame work. Intybasic provides that. I wrote my own sound effect function that works. I have set up Tilestudio colors to port tileset I made to intycolor to intybasic. MOBs are a bit harder to make and sandwich, but I use paint shop pro to draw the MOBs and then make bitmap statement in intybasic for each color. Right now, I'm learning the music player of IntyBASIC. So that save me the headache of programming music player for Intybasic.

 

With Atari 2600, I went with assembly. I read a lot about the hardware, and experimented with the source provided by the lesson post in the Newbie programming section. 8bitworkshop.com provide realtime change when typing in your code. So that accelerated my learning on assembly. Also learn that both Stella and Jatari emulator behave different. So it making the ROM version of the game makes it easier to try in Stella since it's closer to the real machine. So having 8bitworkshop showing you the changes in real time, providing visual aid, really helps a lot. I have compiled source code multiple of times in a hour just to place sprites in specific place.

 

Intybasic does provide a lot of control of the hardware. It does have a lot of support if people have question. I do try answer those question. Don't really need to be forced to learn CP1600 assembly to make games for Intybasic. Intybasic and Colecovision C makes it very easy for me to produce games. However, I will use assembly if needed like making page flipping games to make game bigger than 42KB, which I will attempt to learn some day.

[artrag]

Adding name space common between the asm integrated in intybasic and the code generated by intybasic could promote a wider use of assembly in current projects.

You could code in intybasic the framework of the game and in assembly time critical code that has to manipulate intybasic data and variables

[GroovyBee]

The following options are missing :-

 

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

Hardware (PCB) - Other

 

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

Cartridge acceleration features

[+DZ-Jay]

The following options are missing :-

 

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

Hardware (PCB) - Other

 

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

Cartridge acceleration features

That is very true, GroovyBee! I'll add those as soon as I get home in a few minutes.

 

Done! Thanks again!

Edited June 13, 2018 by DZ-Jay

[+DZ-Jay]

The one thing for which I was hoping from this poll has already started to reveal itself: programmers consider on-board Cartridge RAM and capacious 42K ROM map as standard features.

 

[+DZ-Jay]

Hmm... On the question "the primary reason you program Intellivision games is...", I see two votes for "Other."

 

Can anybody suggest any choice I could add to the question? I thought that fun, challenge, profit, boredom, and to help others would have covered it (although they were presented with a bit of tongue-in-cheek mirth).

 

-dZ.

[carlsson]

Perhaps there is a correctional institution somewhere where programming Intellivision games is part of the punishment/treatment to make honest citizens out of rogue people? Those "Other" votes might reflect that.

[+DZ-Jay]

Perhaps there is a correctional institution somewhere where programming Intellivision games is part of the punishment/treatment to make honest citizens out of rogue people? Those "Other" votes might reflect that.

 

So, what you're saying is that I should add "because I am legally compelled to" as an option..

[carlsson]

Heh, yes. Under a contract perhaps, one that doesn't make you rich and famous but just pays off enough to cover your rent.

[+DZ-Jay]

Heh, yes. Under a contract perhaps, one that doesn't make you rich and famous but just pays off enough to cover your rent.

 

OK, it's a good point. I added "rich and famous" as an in-joke for those who do it to make money since it is such a pittance; but I can see how those who actually do it as a side-job to pay some bills would object to that characterization.

 

I added an option for "side job or spare cash."

 

-dZ.

[intvnut]

I feel like some of the radio boxes should have been check-boxes.

 

As for using jzIntv... You might say I have a special relationship with it.

 

On IntyBASIC, I find it's fine for control logic, but quickly becomes too slow when you need to loop over a bunch of items, such as looping over BACKTAB. That, and its lack of scoping both push me back to assembly. If I can bang out an assembly loop faster than I can figure out how to get acceptable performance from IntyBASIC, then I'll just write the assembly loop.

 

As for which hardware I target, "anything." I write code that's specific to LTO Flash, code that targets JLP, code that only runs in the emulator, code that works in the Mattel 16K map, code that loads into ECS RAM through the tape port via WAV file playback...

[+DZ-Jay]

I feel like some of the radio boxes should have been check-boxes.

 

As for using jzIntv... You might say I have a special relationship with it.

 

On IntyBASIC, I find it's fine for control logic, but quickly becomes too slow when you need to loop over a bunch of items, such as looping over BACKTAB. That, and its lack of scoping both push me back to assembly. If I can bang out an assembly loop faster than I can figure out how to get acceptable performance from IntyBASIC, then I'll just write the assembly loop.

 

As for which hardware I target, "anything." I write code that's specific to LTO Flash, code that targets JLP, code that only runs in the emulator, code that works in the Mattel 16K map, code that loads into ECS RAM through the tape port via WAV file playback...

 

Thanks for sharing. The idea of the single choice questions was to gauge the individual preferences, not to pit one option against another. You may be an outlier due to your extensive experience, versatility, and your deep connection with the tools involved. Most programmers just pick one platform and stick to it.

 

As for the target platform, I guess I could add a choice for "anything"; but the idea was to get an understanding of what's the actual interest in targeting hardware (an expensive and more involved option) vs. just making ROMs to run on the emulator (the more accessible option).

 

Based on your previous experience, I would imagine you on the "PCB (JLP)" camp just because if you were to release a new game, I suppose that would be your primary target. That's not intended to express any limitation on your capabilities or attitudes, really.

 

All that said, if you feel strongly about any of the questions, I can easily change them to include more options or allow multiple-choice.

 

-dZ.

[carlsson]

So 61% (8 of 13) are using or would want to use a music tracker, but only 15% (2 of 13) would desire support for dual PSGs. We're musically inclined, but most think the built-in sound hardware is enough for our intents.

 

54% (7 of 13) like to have a ready-made PRNG to use, while the other 46% either don't need random numbers or are rolling their own from scratch. I'm not sure if 54% using a PRNG supplied with the programming language/environment is a bigger or smaller number than expected, as not all games or other applications really would rely on random events.

[+DZ-Jay]

An interesting thing I see emerging from the poll is the lack of interest on these two features:

• Event-driven hand-controller decoder (without having to poll periodically yourself)
• Sprite animation (i.e., give an array of picture cards and a frame-rate and MOB is updated automatically)

It may be that those two choices are discarded in favour of the option:

• Nothing, I just need access to the hardware and I can do everything myself

However, what I find interesting is that these are two aspects which (at least in my opinion) most games underutilize or areas in which they underperform. I would imagine that if the functionality to do the hard part came for free via a built-in framework -- i.e., automatic polling and decoding, in the case of former; and automatic GRAM cycling at various frame-rates, in the case of the latter -- that programmers would use them. I know I would.

 

I'm curious to know what others think.

[+DZ-Jay]

So 61% (8 of 13) are using or would want to use a music tracker, but only 15% (2 of 13) would desire support for dual PSGs. We're musically inclined, but most think the built-in sound hardware is enough for our intents.

 

I don't think that's what it means. At least the way I phrased the question was, do you think a second PSG is a "standard feature"? It could be that 60% wish to use a music tracker, but half of them would not count on a second PSG being available (i.e., they don't expect too many people to have or want to use an ECS).

 

54% (7 of 13) like to have a ready-made PRNG to use, while the other 46% either don't need random numbers or are rolling their own from scratch. I'm not sure if 54% using a PRNG supplied with the programming language/environment is a bigger or smaller number than expected, as not all games or other applications really would rely on random events.

 

I suppose it is likely that of the remaining half, some roll their own and some don't need it.

 

Since these percentages translate to about a handful of individuals in this poll, I can see that, say, invnut and GroovyBee, roll their own; and a couple of others do not use it.

 

-dZ.

[+nanochess]

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

[carlsson]

Did IntyBASIC v1.3 suffer the same fate as Windows 9?

[Kiwi]

Did IntyBASIC v1.3 suffer the same fate as Windows 9?

Some say that the number 13 is unlucky. So it's wise to skip 1.3 and go to 1.4. Just my guess.

[carlsson]

Hm, ok. I probably should rethink my plans for making games about black cats and walking behind ladders.