|
Tip of the day, #41: Getting started
Many times recently someone new has posted a "Help!" message and say they have an assignment or want to learn the 6502 by doing a project and don't know how to begin. It has been hard to help them when they can't spell out exactly what they want to do and don't know enough to ask the right questions.
Although this is not the place for a hardware or software beginning tutorial, I can suggest a general development plan to get rid of some of that unsettling feeling of unfamiliarity. Here's the order you will normally follow on a project:
A. Decide what you want the computer to do, and what I/O, memory, etc. will be needed.
B. Build the necessary hardware.
C. Get the hardware going. (tips #35 and 36)
D. Write routines to set up the I/O.
E. With rudimentary I/O routines working, begin the actual application program.
F. As the program develops, watch for ways you can simplify.
Missing D is probably one of the beginner's biggest road blocks, as he is probably thinking that after the more obvious A and B, you just start working on your application program (E). Where do you start? How do you know if anything at all is working? Intuition itself hints that something is wrong with this idea; but without knowing what, the person is stopped before there's measurable progress. Even if hardware debugging were unnecessary, the order here is part of the building-block approach. It comes from lots of experience.
That is not to say there's no room for a top-down approach. Indeed even in A you start at the top with your dreams—the end goal; but the realization will mostly come about as you build tiny components, get them working, and put them together to make bigger components. As you move on, you no longer concern yourself with the internal details of the smaller parts. The process continues until you have the completed system with all its parts quietly doing their jobs.
Previous tips will help at various stages. Each step above does not necessarily need to be 100% finished before starting the next. For example, C and D have to be done at least partly concurrently since you will need to write a little bit of code to operate at least some part of the output, minimal as it may be, for verifying the hardware.
As you progress through E, I/O software can be expanded, and you will no doubt also be adding things to the reset routine for initializing variables or other software resources.
F should be started early, soon after E is started. The beginner may see it as time wasted for the sake of unnecessary neatness; but in the end it will prove invaluable. F may include use of subroutines, macros, or re-arranging so certain parts become unnecessary and can be eliminated. It's like factoring things out of an equation to simplify it or reduce it to lowest terms. Document everything as you go!! You'll get yourself in trouble if you leave that for last. By maximizing structure, documentation, and simplicity, you will be able to keep control of the project and maintain it. Otherwise there will be so many things you don't remember how you did that you can't unravel it to get control back, do updates later, or fix a routine with a bug that didn't show up until long after you wrote it.
I may be editing this depending on others' feedback as well as other things that come to mind.
_________________ http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Last edited by GARTHWILSON on Wed Feb 22, 2012 9:27 am, edited 1 time in total.
|
Login
Register
FAQ
Search
