Many times someone new has posted a "Help!" forum 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.
Here's a general development plan to get rid of some of that unsettling feeling of unfamiliarity. This is 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. (But see the modularity note below.)
C. Get the hardware going. (tips #35 and 36)
D. Write routines to set up the I/O. (You may need to refer to the next section, "Program-Writing: Where Do I Start?")
E. With rudimentary I/O routines working, begin the actual application program.
F. As the program develops, watch for ways you can simplify.
Regarding B above: Take an approach that lets you get at least something working soon, preferably even useful, then expand toward your end goals after that. If your plan is too grandiose and requires too much complexity to be built up before anything at all works, it is more likely that you'll get discouraged, because of the time involved, the more-difficult troubleshooting, and possibly other factors. You'll be more encouraged and excited if there's something useful soon. After that, you can add more things to it, primarily (but not limited to) I/O types. Been there, done that. Obviously you do want to look ahead far enough that you don't paint yourself into a corner and find you'd have to re-do at least part of it to achieve your goals.
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. This advice 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 (initially meaning subroutines), get them working, and put them together to make bigger components. "Putting them together" means calling them from other subroutines which in turn may serve as components in other subroutines, as you go building your system. 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, there will be some overlap between C and D 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-aranging
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 don't know how to emphasize this enough! Even
after decades of experience, I still find myself on the raggedy edge of losing control of projects, because as your experience grows,
so does the size and complexity of your projects! Start early on F. Don't put it off.
getting 65xx parts <--Previous | Next--> program-writing
last updated Jul 1, 2015