[atari7800] Re: If you had never programmed anything ...?

>> Here's a question for the people who learned how to do this by fiddling
>> ... where did you begin?

I learned to write code just slightly before exiting the birth canal (smile). I 
learned assembly language in grade 11 computer science, which I took in the 9th 
grade. That was about 1985, and next to actually learning to read (which I 
probably didn't learn in school anyway) was probably the most usefull thing I 
got out of school.

My advice if you want to learn assembly language:

- Unless you're really in love with the 7800, I'd suggest starting with another 
system that has a larger community and more mature documentation (particularly 
in the way of tutorials) - Atari 2600, Atari 8-bit, C64, Vectrex. The 7800 
doesn't have a lot of good documentation, there isn't much source code 
available, and there are only a few real experts in the system. With the other 
systems I mentioned you'll find all the help and all the texts you could ever 
possibly need. The 2600 does get a bad rap for being difficult, but I don't 
neccessarily agree. It's just a little more unforgiving and the skills and 
habits you pick up from the 2600 will be beneficial in the future - For 
example, once you master the 2600's display, doing raster interrupts on 
anything from the C64 to Gameboy will be a snap. There are only a handfull of 
"flavours" of assembly language (ie: Motorola, Intel, Z80) and if you know a 
particular flavour then that manufacturers instruction sets are very similar. 
That is, The Atari 2600 assembly language is to the Atari 8-bit assembly is to 
the Commodore 64 assembly is to Apple II assembly is to Vectrex assembly what 
British English is to Brooklyn English, is to Arkansas English is to SoCal 
English is to Texan. The differences lie mostly in dealing with I/O and 
perhipherals not so much the language (though there are some) and transitions 
are relatively easy.

- Be patient. You wouldn't learn Spanish in an afternoon and you couldn't build 
a boat in your backyard in a week-end. Learning to write code is an equally 
major undertaking. So don't expect to just whiz through and become an expert 
overnight. It's going to take time. It's going to take study. It's going to 
take work. Remember, it sometimes takes *years* for homebrews to get finished 
and that with people who *already know what they are doing*. If you find it 
difficult or frustrating, do not be too 
hard on yourself! Learning is not easy and if you've been out of school a while 
you probably have not had to learn anything in a long time. When your brain is 
no longer in learning mode it can be difficult to get back into that mindset. 
Set reasonable goals, and have reasonable expectations.

- Learn to ask questions. Don't be afraid to ask for help! Keep in mind that if 
you can learn how to find answers yourself (ie: mailing list archives, 
documentation) it's generally more efficient than waiting for someone to give 
you an answer, so is figuring it our for yourself (even just trial and error - 
You learn all kinds of things that way, often completely new things). However, 
that's just not always going to be possible. When you do ask questions, learn 
HOW to ask questions. Be as specific as possible!! Questions like "How do you 
write games" get asked all the time and never get answered. Even questions like 
"I don't understand how to display a sprite" is a tough question to answer 
because it's so broad - What don't you understand? Setting the colours? 
Horizontal positioning? Vertical positioning? Bitmap editing? Pointers? Don't 
ask questions that amount to "How do I drive a car" or "How do I service an 
engine" ask "How do I determine the optimum adjustment for the timing belt on 
my powder blue '57 Chevy?"

- Break it down. This is an absolutely key skill in programming and it goes 
hand in hand with knowing how ask the right questions. As programmers we are 
always breaking down large taks into smaller, more manageable tasks. Then 
breaking those tasks down into even smaller ones. I cannot overstate how 
important this is in assembly language! Assembly language is micromanaging to 
the Nth degree. In order to deal with this, and in order to write hundreds of 
lines of code you need to break everything down into tiny pieces. Nobody sits 
down and writs a full game in one sitting. You write the routine to draw a 
sprite. Then you write the routine to read the joystick. Then you write the 
routine to move left. Then the routine to move right. Then you write the 
jumping routine. &etc. When you have a problem and you have to find a bug, you 
narrow it down - The problem is somewhere in the player handling part of the 
code. Then the problem is in the player movement part of the code. Then the 
problem is in the left movement part of the code. Then the problem is in the 
left part of movement of the code only when a certain enemy in on screen. &etc. 
By breaking it down, you're able to take on and manage complex tasks. You're 
also able to focus your energy and learning in a very specific area. For a 
child, memorising the entire alphabet in one setting is just not going to 
happen so they learn a couple letters at a time... You're not going to learn an 
entire instruction set all at once, so you start with a couple of the more 
important ones and work your way through. As you encounter new things that's 
when you work to assimilate them, not all at once. If you don't need to know it 
yet, don't worry about it, you'll get to it later.

- Get comfortable. You need to get your hands dirty in code. You need to get 
used to editing source good. You need to loose the fear that you will break 
something. Get some source code and just mess around with it. Start with 
hacking the bitmaps. Move on to messing with simpler/more obvious things (ie: 
colours).

- Be consistant. A hour a day is better than a night a week is better than a 
day a month. However, regardless, you need too stick with it. If you work on it 
for a few days or weeks and then leave it for six months you're going to have a 
tough time making progress as you'll be contantly relearning what you've 
forgotten. Learning something as complex as programming, particularly assembly 
language, is not something you can just go at for a couple hours, every once in 
a while, when you feel like it.

- Realise the progress you have made. There will be times when it feels like 
you're getting nowhere, you haven't learned a thing, and nothing makes sense. 
That's simply not true! Take stock and consider all the stuff you didn't know a 
week, a month, a year, ago. Once we know something, it becomes commonplace and 
we tend to discount it's value. Know what you know and place value on what 
you've accomplished. E=MC^2 looks pretty damn simple when you look at it, so 
howcome nobody ever figured it out before? When it gets though, remember back 
before you understood hexadecimal. Realise there was a time you really had no 
idea how a computer stored data. Think of all the opcodes you DO understand, 
not the ones you don't and consider you understood NONE of them before you 
started.


On a practical level, you generally need a few things:

- An emulator (unless you have the hardware to test code on a real machine)
- An assembler (Keep in mind that if you use a PC the assembler probably runs 
in DOS, not Windows and if you want to run in Windows you'll likely have to 
start with batch (.bat) files. If you didn't understand the previous sentence, 
then THIS is where you need to begin, not actually programming.)
- Documentation (Tutorials would be optimum)
- Source code (particularly well documented/commented source code, and/or 
source code included with whatever tutorial(s) your using)
- A good mailing list, newsgroup, web forum or other place you can get support 
from other developers.
- Google (To find all of the above)



Good luck!

Chris...

Other related posts: