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. There are tips for getting help from the 6502.org forum in the last half of
this page.
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.
A common request is to have others look over their "schematic." I put "schematic" in quotes because so often what they present is not really a schematic so much as a netlist written around boxes, with tags everywhere, and it is very difficult to follow, requiring us to search the whole thing, sometimes several pages, for a matching tag. I give an example of tagless schematic of an entire simple computer near the top of the circuit potpourri page. This one is done by hand, but the same principles apply when doing it with CAD. (There are certain things I dislike about all the schematic-capture CADs I've tried, so I still do my schematics by hand, sometimes on velum up to 18x24" with 400+ components.) Note the way to draw address and data buses, so you don't need a ton of parallel lines.
Please draw the gates. For example, if you have a 74xx00 quand NAND gate, do not draw a rectangle with the A1, B1, Y1, A2, B2, Y2, etc. down the sides of the rectangle. At the appropriate places, draw out the individual NAND gates with the NAND symbol as shown in the diagram in the middle of the address-decoding page. This will also reduce the connecting lines' lengths since they don't all have to come to one rectangle, and it will make things easier to follow. (This applies to ICs having multiple individual gates each. It would not apply to ICs where the whole thing works as a unit, like the 74xx138 3-to-8-line decoder, the '245 octal tri-state transceiver which is intended to be used on a bus and has a single direction pin and a single enable pin for all eight buffer bits, the '595 8-bit shift register which has a single pin for each of five input functions and serial out, applying to all 8 bits of the one shift register, etc.; but please do separate the two sections of a '139 dual 2-4-line decoder, a '74 dual flip-flop, etc., even though each section will be drawn as a rectangle.)
A few potentially helpful forum members have color blindness. One of them cannot see green lines against a yellow background, and has other color difficulties too; but people post their schematics in these troublesome colors. I have told Cadsoft/Autodesk about this problem and asked them repeatedly to change the default colors; but they apparently don't care. If you post your diagrams in black and white, everyone can read them. I personally am not colorblind, but it still slows me down if some (or all) of the text is in a light gray font. The light gray pin numbers and labels on the ICs are awfully hard to read sometimes, so it would be good to darken them up. As I was writing this, someone posted a schematic with a black background and pin labels in dark blue. I could barely see there was something there, and I couldn't read them without getting off my chair and getting up really close to the monitor.
If you can, it's good to also scale images so the post fits on standard monitors (of, say, no more than 1600x900) without having to scroll side to side. I use Gimp software which is free and for my uses has no disadvantages compared to Photoshop and in fact it had certain abilities before Photoshop did. (I used gimp to massage every image on this site, for size, contrast, sharpening, and cropping; and for pencil diagrams, using the threshold function to make them black and white with no gray scale. I'm no power user; but this stuff is easy and quick.)
Please note that you can attach your images or other files to your post on the 6502.org forum. Third-party hosts like photobucket, Imageshack, and Imgur used to be allowed; but there was a big problem in that the pictures disappeared after a while. I don't know if it's because the sites dump your oldest pictures to make room for newer ones, or just dump them based on age regardless of new ones, or if members think they're not needed anymore so they delete them, or maybe even the whole site goes down; but then someone comes along and wants to read the topic a few years later, and the images are gone. The problem was too common. In the fall of 2022, Mike (the forum owner) made it so you can no longer use external hosts for images. Please just attach your images to the forum post. There's an option to inline them if you need to, so they don't have to all be at the end.
If your problem is "I built this thing and it doesn't work," photos of your build may be very helpful for a reader
to spot a source of trouble.
If you post source code:
CLC ; Clear carry flagwhich is just unnecessary clutter.
A couple of other tips: Give the topic a relevant title. Titles like "Question?" or "Help!" or
"What happened?" or "and the winner is..." don't get potential readers' interest, nor do they remind them of what an ongoing project
is about. Also, do not start a new topic for every question if they're all questions about the same thing, for example clock
circuits. That just clutters the forum and fails to tie the various ones together. If you have to put the project on
hold for a few months (or even years) and then come back to it, don't just start a new topic about the same thing just because the
first one is old. Continuing on the same one helps keep related things together, and also has the advantage that anyone who
has replied before now gets an email notification that there's a new post in that topic (when the notifications are
working—which seems to depend on the the email provider, not anything about the forum software).
getting 65xx parts <--Previous | Next--> program-writing
last updated Dec 25, 2022