Document the design first and keep it up to date to stay sane! Defining unit tests prior to or concurrent with unit coding can help clarify issues. Use version control! I would typically do top down design: program, package (files), data structures, procedures/functions/routines, data etc. Quite often, uncertainty dictated a bottom up approach for code and debug/unit test. Assuming your development tools support: Start each file and code unit with Header Comments: name, purpose, calling sequence, parameters, caveats/limitations etc. Intermix High level language (or pseudo code) comments with resulting assembly code. Keep code size of procedures/functions etc. reasonable for "your own" head. Use a naming convention which works for you. Three letter abbreviations with dashes or underscores work for me, but I document abreviations in file comments. I prefer jump destination lables that begin same as the routine name with numeric suffixes (get_chr, get_chr10,get_chr20). Keep unit test documentation and code either in same file as unit code (using conditional assembly control) or in a file with a related filename (example: comm.asm and comm.tst). Be ready to refine, redesign and recode. That just proves you are making progress. Check your public library and used book stores for books on assembly language programming. Study any available relevant code. You can get good ideas, even from bad code.

Jack Unger