I started my investment in software development with a TRS-80 model I, level 2 computer system. It wasn't my machine, but belonged to a friend on the same floor as me, in the dorms at the college. We wrote action response software to time how fast you could push a key after the screen flashed up a big "GO".

Some of you might remember these types of games from college bars. They were meant to pass time, but also gave you a hint into how much alchohol you had been absorbing! In basic, the program was a poor performer. It was rediculously slow, and had unpredictable responses. We had made a poor investment in API choices by choosing basic.

Assembly for Christmas

I had no practical computer training at that time, and my friend, who was an EE major, said to me, you need to learn assembly language, that would make it much faster. So, I bought Bill Barten's TRS-80 assembly language programming book, and absorbed it over christmas break.

I came back all gung-ho to make a much better application. I had learned how to poll the keyboard matrix, draw from buffers, with the graphics characters using the LDIR (load increment and repeat until zero) Z-80 instruction and call assembly language from basic.

I did have to work out all the details in actuality, but within a week or so, I had it working. I had to hand assemble the instructions, and bury them into basic data statements. I used loops and the poke command, in basic, to put them into memory. It was a true learning experience about how computers worked!

What a difference assembly made. I had invested 3 weeks of reading and 1.5 weeks of programming to fix problems with software that had taken 1 day to write in basic.

RET NZ?

And, some of you might consider this a pretty worthless investment. I mean, that application had little real value right? Well, that was what led me away from the field of Architecture, into the world of Computer Science. It was an investment that I have come to appreciate in many ways.

Later, I was able to use an assembler development environment, and I wrote many other assembly language programs. When I wrote those assembly language programs, I used labels, and variable names made up out of the blue. I did not use things like 'loop', or 'top' or 'buf_G' and 'buf_O'. Instead, I use labels and variable names like 'fred', 'dave', 'joe', 'what' etc.

You see, I had no idea what I should use for labels. I just wanted line numbers like I had in basic, and I was a little miffed when I had to make up something that the programming environment should have been providing me! Some of the labels include some pretty good explitives because I was tiring of labels.

JR NZ,where

Well, as I moved on to more complex programs, I soon discovered that there was a need for very real labels and variable names. Functional coherency became very obvious to me. I also came to recognize many other things that I learned from those initial assembly language days.

For me, those days were the ultimate investment. They gave me a very real education that I could not have gotten from a classroom. In the classroom, you don't get to make so many mistakes, and waste so much time because you don't know what you need to know, or where to find out what you need to know.

Now days, I continue to look for those ultimate investments. I am very weary of spending (if not wasting) my time writing useless or poor performing software.

I will use this forum to expand on areas where I think the good investments are.