I was learning to program with C++ after using turing in 98 and quit moving to assembly which I thought I could talk with the code structure experience that I already had. I didn't have any trouble understanding registers and the such so I feel good about my ability to master enough of the basics of assembly to learn the language.
The reason I'm posting here is the reason that I quite trying to master C++, it was simply impossible to learn and build progressive software from the base up. What I conceived of as a program model and learning to program was to build in a progressive single program all of the functions of the computer from the basic functions up, and to master the language and programming skills while building a complete base up model.
What I mean by this is that the first thing I learn is to write the blank program and struggle to master all of the components and theory in that single program. Then progressively move to the next logical component in a program system covering the required new theory for each component.
By the time you master all the basic program components an appendix of source examples for any crazy function ever created is easy enough to use to be nothing but cream on top.
I am trying to learn MASM by completing this type of circuit now and the model that I am using for component progression is so burning bright in my mind that I thought for sure it must be of interest to you. I work with pseudo code and unifying theory a little so hopefully it will be usefull as well, or at least an intruiging paradigm.
One final comment is the reason I chose to learn MASM as opposed to non-windows integrated assembly languages. Since I am trying to build a base up system at the top you always run into windows and MASM was simply a better choice for talking windows operating system masterment in my own build codes.
Blank program
Write a binary bit to a file
Read a binary bit from a file
Input from keyboard
Output pixel to screen
Input from mouse
Text editor
Draw program
File manager
Graphic display – translation theory
I/O and device drivers (cd rom/writers, music output, gamecontroller input)
Music player
Video player
Internet log on and explorer/spyder program
Writing building programs – like a final project (IDE, Animation, Music or Video stuios,
and my personal favorite The self-actual management program or the Scheduler and
task support software.)
I hope that you understand this as I would simply hate it if the information did not get across to you.
<-!Thanx for listening-> proc Friendly
flag "tran"
Aaron G. Skoreyko
aaronskoreyko@hotmail.com
I'm only online on the weekends sorry
return flag 'tron'
END Friendly
Aaron,
It sounds like you are an interesting person to know. You certainly are not afraid to set goals for yourself and IMO this is very important otherwise you will not maintain a directed learning curve. We certainly are here to render any assistance that you may need along the way. All of those things have been done by various persons. Very few people have done them all but this is because they did not need to. While it is good to gather a broad knowledge of the discipline, you must be careful not to overwhelm yourself. If you take a look at Iczelion's Tutorial set, you will see that he is using a directed approach to learning the discipline and his documentation is at the top of the line IMO. Most of us are too busy coding to write good docs so we become lousy tutors. Try not to fall into that bad habit. Although it is never necessary to comment EVERY line of code in a source file, it is important to put in as many comments as are necessary for a person to understand what you are doing. Also, with Assembly, whenever you look at your sources after a long break from them; if they are not commented, it usually requires some thought for you to remember what and why.
Remember to have fun with it. If it is not fun, try Solitaire. :bg
Paul