Starting from zero: how to learn to program for Inty?

[ghsqb]

Hello everyone,

I've wanted to learn to program for the Inty for a long time, and I've actually kicked the tires a few times but got frustrated and went nowhere.

 

FWIW I've checked the Programming section of the forum, and I've tried to read the white papers, but even those assume some familiarity with programming as some of the terminology is way over my head with my present knowledge (or lack thereof).

 

With that said, is anyone able to suggest a jumping off point for a complete newb?

 

I don't mind reading and practising and learning, I'd just like to build up a bit of a foundation so that when I read the white paper and the SDK and STIC and other documentation, it is in a language I can understand.

 

I actually have two project ideas I would like to attempt but I don't even know if they are feasible owing to my lack of understanding of the technical aspects of the system.

 

Thanks in advance for any and all assistance.

[Rev]

You have seen IntyBasic Im sure....supposedly BASIC is an easier language to learn than Assemler?

 

http://intellivisionrevolution.com/intybasic

 

 

OK, Ive started an Intellivision Programming section, inspired by you!

 

http://intellivisionrevolution.com/programming

Edited May 26, 2014 by revolutionika

[Troy_Whelan]

You have seen IntyBasic Im sure....supposedly BASIC is an easier language to learn than Assemler?

 

http://intellivisionrevolution.com/intybasic

BASIC is much easier to learn than Assembler / Assembly, but it is also more limiting is some capabilities.

 

Troy

[ghsqb]

You have seen IntyBasic Im sure....supposedly BASIC is an easier language to learn than Assemler?

 

http://intellivisionrevolution.com/intybasic

 

 

Right, I did see that. Again the issue is kind of getting an understanding of the hardware, it's limitations, the working environment.

Just by being a longtime member here I've learned about tiles and MOBs and Backtabs and GRAm and all that stuff, but until I learn how that all comes together and use the systems resources, I don't really see the point of starting to practice coding.

 

Or maybe I'm approaching it wrong?

[LidLikesIntellivision]

I'm curious to know if it's best to learn the basics of assembly for another machine before learning assembly for Intellivision.

 

There should be many resources for other processors.

Maybe a good book to introduce the basics of assembly in a more popular and accessible machine would help...

 

^wrote by a non programmer...

[ghsqb]

That's an interesting point Lid, and you may be right.

But am I wrong in thinking that before you ever write a line of code, whether in assembly or Basic, that you need to learn how the hardware works etc?

From the little I know about the system, I know that there are limits on the number of tiles (cards?) and MOBs etc.

 

So I could learn to write a beautiful little program to execute instruction x, y z, but if that instruction falls outside the limitations of the system, it's worthless.

 

Again, I may be approaching this all wrong this is kind of my intuitive way of looking at it.

[Games For Your Intellivision]

It is true that you have to learn how the different modes work on the Intellivision, how you only have 64 cards that you can modify, and what GROM images are available etc., before you can start to program the system. However, it isn't really necessary to learn how machine language works on other systems before you start programming the Intellivision. The Intellivision has a pretty good 16 bit CPU. Its only real limitation in my opinion are the graphics.

 

I know dZ has come up with his own programming framework, 'P-Machinery', but we are doing our own Elektronite 'in house' game engine that is pretty generic and will take a lot of the set up work out of the equation.

 

Our Boulder Dash programmer is pretty organized, and documents everything. The game engine is being developed at the same time as Boulder Dash.

 

Our goal is for experienced assembler programmers to be able to write a game for the system with as little typing and set up as possible.

[Kiwi]

I would highly highly recommend starting with IntyBASIC. I posted source codes for the example programs I made in this thread, http://atariage.com/forums/topic/221362-intybasic-compiler/ . There are source codes in that thread to get you started with programming in BASIC. It comes with a manual explaining how the functions work. You should be able to get good results IntyBASIC.

http://atariage.com/forums/topic/223886-intybasic-compiler-v07-now-with-intycolor/

This thread has the latest version of IntyBASIC.

[GroovyBee]

As others have said, I'd say start with IntyBASIC. If you've never programmed before then set yourself achievable goals. If you want to code Quake 12 on Inty you're probably going to get disheartened pretty quickly . With BASIC you don't have to know much about the machine. First, get your build and emulator environments set up and working e.g. builds examples fine and you can run ROMs on an emulator/CC3. Then the real fun begins . I'd suggest starting your game's development with something like the following steps :-

• Clear the Inty screen.
• Get a sprite (MOB) of your design on screen.
• Get the sprite under player control.
• Animate the sprite.
• Stop the sprite going off the edges of the screen.
• Get a few more sprites on screen at random positions.
• Get those other sprites moving around too (not under your control).
• Get some background tiles (BACKTAB cards) on screen.
• Detect if the player has run over a background tile and do something e.g make a sound, change colour etc.
• Detect if the non player sprites have run over a background tile and do something.

At this point you have a simple zombie style game and probably a good start on plenty of other game styles too. As long as you are having fun and learning new stuff, thats all that matters at the end of the day.

 

You might want to post specific programming related questions in the AA Inty programmers section, it doesn't get spammed in there much .

[+DZ-Jay]

I'm currently working on the next generation of P-Machinery, which will be a fully-featured, open source, game construction framework. More than a game engine, it aims to abstract most of that complexity that you've talked about, allowing the programmer to concentrate on game logic. P-Machinery introduces many high-level and structured constructs on top of Assembly language, offering an intuitive event-driven and object-oriented model to Intellivision game programming.

 

However, although a work in progress, it is some way off from being released. I don't expect to have anything ready for the public until at least the end of the year.

 

In the meantime, like others, I recommend you check out IntyBASIC, and play around with it for a bit. Like you, I started pretty much from scratch, and tried to devour every technical document and tutorial I could find. However, it wasn't until I actually got my hands dirty and started my own project that things took off and everything came together.

 

So, I second GroovyBee's suggestion to start implementing your project either in IntyBASIC or directly in Assembly Language. It's hard to pick a starting point when staring at a blank canvas, but dipping your brush in paint and running it across the board is the only way to go.

 

Now, post some questions in the Programming Forum, subscribe to the INTVProg mailing list, and let's get cracking!

 

-dZ.

Edited May 26, 2014 by DZ-Jay

[HunterZero]

I would say the trickiest part of programming is identifying all the steps you need your program to execute breaking things down into steps that can be executed programmatically. These skills are portable from language to language. I would say intybasic is as good a place to start as any, as you can learn the limitations of the hardware as you go, and basic ways to work around them. Plus you can learn how to design a main game loop, how to add functions and using variables to keep track of the game state without worrying about crashes because you had a bit set incorrectly, or worrying about unexpected behaviour of exec routines. Assembler is a very unforgiving way to program.

[catsfolly]

Yeah, what they said...

 

You can't learn to ride a bicycle by reading all about the physics of bicycles - you have to get on the bicycle, try to ride it, and fall down a lot.

 

Falling down is part of the process.

 

Every time you fall down, you can learn something - eventually you fall down less and less.

 

Learning programming works the same way - you have to jump in and get your feet wet.

 

I think that starting with a blank sheet is very difficult and intimidating.

 

I recommend finding an example program that does something related to what you want to do, and modify it until it becomes your program.

 

Similar to what Groovy said - Try to find the smallest step that you could do that would give you a sense of accomplishment and motivate you to keep going, and try to do that.

 

For example, if you wanted to do a "Galaga" type game on the Intellivision - first you might put a ship sprite on the screen, then try to move it left and right on the screen, then try to fire a shot etc.

 

You might at some point decide that "Galaga" doesn't fit the Intellivision, but at that point you could use what you had learned to make a different kind of game... But you won't learn anything until jump in and try to make something happen.

 

 

Catsfolly

Edited May 26, 2014 by catsfolly

[+DZ-Jay]

For example, if you wanted to do a "Galaga" type game on the Intellivision - first you might put a ship sprite on the screen, then try to move it left and right on the screen, then try to fire a shot etc.

 

You might at some point decide that "Galaga" doesn't fit the Intellivision, but at that point you could use what you had learned to make a different kind of game... But you won't learn anything until jump in and try to make something happen.

 

 

Catsfolly

 

Fun fact: Christmas Carol vs. The Ghost Of Chirstmas Presents started out as a port of Pac-Man. I spent a couple of years just thinking about how it could be implemented, trying to get acquainted with the hardware by reading the SDK-1600 documentation, just like you, and dreaming of what and how I could do with it. Then my wife one day dared me to actually make the game (well, she actually said something more akin to "yeah, making games, whatever, sure... I'll believe it when I see it.")

 

The first thing I did was to draw the maze. I've created a script to read ASCII drawings and convert them to tiles, but actually taking the data and drawing the maze on the screen forced me to figure out at least how the BACKTAB and GRAM works. It also forced me to get acquainted with the assembler, the debugger, and emulator, and some really basic things that are required to get to at least display a title screen.

 

The next thing I did was, of course, draw and animate Pac-Man. No motion yet, just an animated sprite in the center of the maze. A few weeks later, with the assistance of many helping hands from the Intellivision programming community, I was reading input from the controller and moving Pac-Man within the maze.

 

On and on it went, little by little, step by step: Dots and blinking energizers, Pac-Man eating the dots, counting dots to end the level, keeping score, adjusting sprite speed based on level and game state, etc. By the time Christmas Time came around, I had enough of a game core and useful features implemented that I decided to dress it up for the season and release it as an electronic greeting card to the community. That eventually became Christmas Carol vs. The Ghost Of Christmas Presents, and here I am, ready to make more.

 

I've always said that making games--especially retro-games on vintage hardware--is hard. However, to this day, the hardest part of all was switching from two years of "theory" and "blue-skying" about making a game, to actually making one.

 

Cheers!

-dZ.

[ghsqb]

Just wanted to say thanks to everyone for the great suggestions.

 

This statement from catsfolly is particularly relevant:

 

You can't learn to ride a bicycle by reading all about the physics of bicycles - you have to get on the bicycle, try to ride it, and fall down a lot.

 

So I will take the advice offered and begin with IntyBasic.

 

Thanks Groovybee for some great ideas on some milestones to benchmark my early progress.

 

Looking forward to getting into this, and hopefully one day bringing a game to market (got a killer idea for an original homebrew, let's hope I can make it a reality).

[LidLikesIntellivision]

Just wanted to say thanks to everyone for the great suggestions.

 

This statement from catsfolly is particularly relevant:

 

You can't learn to ride a bicycle by reading all about the physics of bicycles - you have to get on the bicycle, try to ride it, and fall down a lot.

 

So I will take the advice offered and begin with IntyBasic.

 

Thanks Groovybee for some great ideas on some milestones to benchmark my early progress.

 

Looking forward to getting into this, and hopefully one day bringing a game to market (got a killer idea for an original homebrew, let's hope I can make it a reality).

In some sense, I'm in the same boat.

I hope I can make some games soon.

 

And I really must start coding something and get hands dirty.

[+Lathe26]

Learning to program with BASIC on any system is a good choice. It was originally designed at a learning language for folks new to programming. I can't speak to IntyBASIC, but I suspect that is still the case. Here you should learn about storing data in variables, use 'if' statements to make decisions, doing simple math, and other concepts of programming.

 

Once you feel you have mastered BASIC, I strongly recommend learning assembly language next. There is more effort needed to program in assembly, but this is mostly busywork and details. The advantage is you will learn what it is like to program "close to the metal" and how to write tight and highly optimized code.

[GroovyBee]

Once you feel you have mastered BASIC, I strongly recommend learning assembly language next. There is more effort needed to program in assembly, but this is mostly busywork and details.

I'd say keep pushing IntyBASIC until you get to something in your game that needs to be converted to assembly language. Then you can directly code that routine in assembler. It'd also be quite interesting if you threw the BASIC routine out to the floor then more experienced programmers can probably suggest other ways to improve it and probably optimise your assembly language replacement too .

 

The advantage is you will learn what it is like to program "close to the metal" and how to write tight and highly optimized code.

As an embedded programmer I've seen some dog slow and well wacky assembler over the years . Its entirely possible to write ugly, bloated and slow code in assembler. It just tends to execute quicker .

[+Lathe26]

As an embedded programmer I've seen some dog slow and well wacky assembler over the years . Its entirely possible to write ugly, bloated and slow code in assembler. It just tends to execute quicker .

 

As they say in New Orleans: Tru dat!

 

I'm curious GroovyBee, what sorts of assembly languages have you worked in? I've worked in 68000, ARM, ABRISC, a little bit of SPARC and MIPS, and a tiny amount of x86 (only learned the minimum x86 of what was needed, yuck). Unfortunately, I've probably forgotten most of these given how long it has been since I've done anything with them.

[GroovyBee]

As they say in New Orleans: Tru dat!

 

I'm curious GroovyBee, what sorts of assembly languages have you worked in?

Its probably easier to list processor families I haven't used than the ones I have .

 

I've worked in 68000, ARM, ABRISC, a little bit of SPARC and MIPS, and a tiny amount of x86 (only learned the minimum x86 of what was needed, yuck). Unfortunately, I've probably forgotten most of these given how long it has been since I've done anything with them.

Sounds like you'd be a good candidate to make an Inty game with that kind of assembly language experience. Don't worry, as as you get going, it'll all come flooding back .