Learning to program

I suspect that Ed’s suggestions are very good. I started back in the early 1980s so my experience of any detail is irrelevant though the basics are vital and those two suggestions did appear to lay them out very clearly. Think clearly, plan logically and break the task into small manageable parts. The first thing I ever did was reprogram a multi position training simulator at work, we only had it set up for 6 trainees plus and instructor but it had the capability of dealing with 32 trainees. I guess it was a bit similar to a game in some ways. It was written in assembler and we only had a 6byte window through which to access the programming code, so write it out long hand, enter 6 up to bytes, save and if you though that was the right point, then test the steps. Boy did I learn to save little and very often! Along the way I had to write some test routines to map out previously unused functions – we had changed the main machine’s method of use during contract negotiations. The simulator was delivered RFS to start training staff in advance of the new system going live and that was before the changes were made. We did not have the budget to pay for new training programs…

Do chose an achievable target for your first steps and something that will give you good payback, or ‘early gratification’. I still get a buzz from my early efforts, I am sure ED does from memories of his successes and overcoming the failures through bugs. One routine was called 39 times but on the 40th it fell over, it took a while to find the error – a variable was longer than the space allocated. Easily corrected but initially the devil to find. For me that was the ‘game’ element. Remember, my tools were very crude with no programmer’s access just a 6 contiguous byte window to poke data into – though I even taught the manufacturer’s staff some short cuts when finally synchronising the programs to the audio visuals.

Do you have any programming experience Tippon ? Anything will do but if you don’t you should get to grips with Variables, Loops and conditional branches like the If then do stuff. You can’t write an app without them.

I think i will post the Atari BASIC code for Snake if I can find it. It has comments so see if you can pick the logic out of it ?

Old style BASIC but I know it like the back of my hand so I still use it to prototype my ideas.

Goto = spaghetti code, never stopped me though ?

I did all my stuff in Atari Basic with some assembly code that ran in Page 6 – W-o-F will know what I mean. You could do stuff with Atari Basic, especially with strings, that you couldn’t with others. IIRC it was written by Microsoft.

Oh yes page 6 ! 256 Bytes of memory you could  put your USR code in. Neither BASIC or the OS would touch it. I put my display list interupts there too.

Two place’s because it holds the x and y position of the snakes tail ?

At machine code level you are pretty much forced to use a pseudo-goto for a lot of your code as branch instructions need somewhere to go. The purist approach to removing goto in higher level languages can be done but subroutines etc are a lot harder to program and require stack manipulation. Assembler just conceals all these compilation level nasties!

When you are using peeks/pokes/push/pop etc in Basic you are actually very close to machine code level.