Structuring my Thinking

Originally published on: Mon, 30 Nov 2009 16:50:50 +0000

In my post Learning Z-80 Assembly Language on the TRS-80, I describe my acquisition of the assembly language programming skills that could have led to a career as a game-developer. I emphasized the phrase "could have", because I had mentioned in that post that I really knew nothing about good software design practices.

Like many of my generation, I started out coding in 8-bit BASIC dialects and later began to code in assembly language. What I often did when writing assembly was picture the program in BASIC. That's the sort of mental modeling I was doing at the time because it was the only programming environment I had known. My early coding style for writing assembly programs was just to start and interactively try to shape the program as I went along, without a clear high-level mental picture of what I wanted to accomplish.

At this time, the trade press was starting to warm up to the Pascal programming language as a means by which good programming habits could be taught. Many add-on packages for BASIC supplemented the interpreters with some Pascal-like constructs ( named procedures and functions, structured loops, block-structured if/else/endif, ...etc. ) One such extended BASIC was a language called COMAL from Denmark. A free version was available at the time for the Commodore 64 home computer, so I tinkered with it a bit. ( You can try out COMAL on modern OS's via the OpenCOMAL project: http://www.josvisser.nl/opencomal/ ).

COMAL was a powerful BASIC with extended flow-control and instant feedback on errors as you entered lines of text. I really didn't understand the value of these named FUNC's and PROC's that it would encourage the developer to use, although I had seen similar constructs in the language Simons' BASIC ... another extended BASIC available in cartridge form for the C-64.

I had purchased a couple of Commodore 64 Pascal compilers at the time. They were very cumbersome to use due to the limited amount of memory plaguing 8-bit computers of that time, and also due to the slow disk speeds of the serial protocol used to talk to the 1541 disk-drives. Often, you had to unload the editor while the compiler pored over your program. When a mistake was found, you had to re-load the editor ... which took a lot of time. Development with most of these compilers was a very slow process.

I wasn't making very much headway learning Pascal on my own, so I took a Pascal course as an elective in college. I learned much more quickly in a formal curriculum. It's not that the assignments were all that enlightening; I just needed a bit of a nudge in the right direction. I worked a little with the small Pascal compilers I had, but they were very frustrating to use.

Just after I had completed my introductory Pascal class, Commodore released the Commdore 128 home computer. I bought one as soon as the department stores started to carry them. The C-128 had a C-64 emulation mode and a CP/M mode. I had an interest in CP/M as I had a desire to work with a "real" operating system, but the Z-80 cartridge I'd bought for my C-64 and the CP/M software for the cartridge were just too slow.

CP/M on the C-128 was much better. I bought a composite Apple monitor and cobbled together a video cable that allowed me to use the 80-column text mode on the C-128. I began to frequent a local BBS with a CP/M software repository. Some local people were writing CP/M utilities in Turbo Pascal. I really enjoyed downloading the source code and looking through each program. Tech magazines of this time period were providing coverage of Turbo Pascal.

I ended up getting Turbo Pascal 3.0 for CP/M-80 for my C-128. I was amazed at how quickly TP would compie my code. It was an incredible experience after putting up with all of those slow compilers for such a long time. I spent a lot of time toying with TP and bought a book on the MS-DOS version of TP from Compute! publications.

I was beginning to model programs mentally using a more structured, top-down approach. I would start by envisioning some high-level functions / procedures and would flesh each one of those out as I thought about them in detail.

A friend of mine who was attending a reputable university advised me to buy the venerable book The C Programming Language by Kernighan and Ritchie. So, I did. I loved reading that book. Learning Pascal helped ease me into similar concepts in C. Unfortunately, I didn't have a C compiler to toy with. I went to a computer store in a neighboring city and bought the C-64 version of Abacus' ( Data Becker's ) Super-C compiler. It was really cumbersome to use like the Pascal compilers I had tried to use earlier. I had realized that I was just going to need to go with a computer that had better compilers available.

By this time, I was out of school and was working writing mainframe code. I sold all of my 8-bit Commodore gear and bought an Amiga 500. I tried to learn C using this new computer as that seemed to be the most popular development language available for it. I didn't have a hard-disk drive, so the compiler required some diskette shuffling. I would compile with one floppy to a ramdisk, then I'd link with a separate floppy. I still had a long way to go, but this process wasn't really that bad. Even with the floppy swaps, I was able to edit, compile, and test pretty quickly.

I used to read the code listings in Dr. Dobbs Journal ( I loved Allen Holub's C Chest column ) and in Byte magazine each month and would try to understand what the author was trying to accomplish, line by line. I checked out a copy of the Waite Group's Advanced C Primer Plus text, which helped de-mystify pointers and C's pointer notation.

My next planned purchase was an MS-DOS machine as the prices for the rising clone market were dropping. I bought a book on 8086 assembly language in MS-DOS to be certain that I understood the OS at a very low level.

"Chance favors the prepared mind." - Louis Pasteur

An opportunity arose to be a founding member of an MS-DOS C development team at work. Although I had no MS-DOS machine at home, the rigor that I had put forth studying C and low-level MS-DOS had paid off. Although, my team and I all started out as novice C programmers, our prowess grew in leaps and bounds as we went on to build some very respectable, long-lived software.

I continued on the C path, first using C++ and later Java as well as a myriad of diverse languages along the way. Often, these languages cater to specific programming idioms and/or philosophies. By learning a little about each of these languages I've learned more about programming in general.

While I have only used Pascal a few times professionally ( most recently Object Pascal in Delphi), I consider it to be the language that kick-started my software design skills.

Unless otherwise noted, all code and text entries are Copyright ©2009 by James K. Lawless

Save to StumbleUpon
Digg it
Save to Reddit
Share on Facebook
Share on Twitter
More bookmarks