This week we continue my nostalgic look back at my college days starting with my fourth semester at IUPUI and the paid programming jobs I ever had.

Hi, this is Chris Young. Welcome to episode 60 of Contemplating Life.

We took a couple of weeks off after my office reviews and now we return to my nostalgic look back at my college days starting with my fourth semester at IUPUI and the first paid programming jobs I ever had.

My transcript for the spring semester of 1975 shows that I took “Psychology as a Biological Science PSY 105” which I discussed in a previous episode. I earned a B for that class. Next, we have “Physics 152 Mechanics” which I also discussed in my episode about my friend Mike Gregory. Another B with four credit hours. I also had “MATH 261 Multivariate Calculus“ which was my first calculus class. I never was very good at calculus or differential equations but I managed to sneak through with a C.

Finally, we get to my second-ever programming class – “Assembly Language Programming CSCI 300.” It was very frustrating that this was my fourth semester trying to earn a BS degree in Computer Science And I was just now getting to my second class in my major. I explained previously that they had me mistakenly identified as a Math major rather than a Computer Science major and that got me off sequence.

Let’s talk For a little bit about what we mean by Assembly Language Programming. We are going to get a bit technical for a minute or two but I will try to explain some programming concepts in layman’s terms.

There are a variety of ways to program a computer. Computers don’t understand English-like languages or algebraic formulas to do calculations. Most of the time we write programs in what’s called a “higher-level language.” My previous programming class CS 220 taught programming in a now obsolete language called FORTRAN IV.

Suppose you wanted to calculate the area of a Rectangle. In FORTRAN, you might have statements such as…

Width = 5

Height = 7

Area = Width * Height

(Where an * is a symbol used for multiplication).

That’s a very simple formula but you could have much longer calculations on one computer statement. For example, the volume of a sphere might be

Radius = 5

Volume = 4/3 * Pi * Radius * Radius * Radius

Because the volume of a sphere is 4/3 pi times the radius cubed.

Computers cannot directly understand any of this. You have to use a specialized program called a “Compiler” which translates a high-level language like FORTRAN into something called “Machine Language”.

Machine Language is nothing but a series of numbers that the computer interprets as commands to do various things. Computers have a section of circuitry called an Arithmetic Logic Unit. The ALU consists of some registers to store temporary numbers. Some commands load data from the computer memory into a register. There it can be added, subtracted, multiplied, or divided by a number in a different register or perhaps a number stored in memory. Once a number is in a register you can also compare it to the number in a different register. Based on how that comparison went, you can conditionally jump to a different part of the program. Or you can remember where you were, jump to something called a subroutine, and then when the subroutine is finished, you jump back to where you left off.

There is a special register called the Program Counter which points to the next instruction in memory to be executed. When it completes that command, it increments the counter to the next instruction. Your program instructions and the data it works on are all stored in the same memory. If you’re not careful, you can jump to a location that contains data rather than instructions. The computer will try to interpret that data as an instruction to do something when it really wasn’t meant to be. The program goes haywire doing God knows what.

Machine language consists solely of binary numbers (a series of ones and zeros) which is hard for humans to read. We can group the ones and zeros into groups of four and use base 16 numbers also known as hexadecimal numbers. But that still doesn’t tell you what the instruction does unless you memorize the codes. For example,3c 12 67 means that you should take the value at memory location “6712” and load it into the A register. That’s not a mistake, it stores the lower order two digits first. So you specify the address as 1267 but it means location 6712.

Assembly language, which is what I studied in CS 300, is one step above machine language. In machine language, the previous command we talked about would be…

LDA MyValue

The command LDA means you’re going to load something into the A register. That’s relatively easy to remember that LDA means “Load Register A”. But where are we going to get what we want to load? We could remember a memory address like 6712 but it’s easier if we just make up a name for that location. In this case, we called it “MyValue”. A program called an Assembler translates this command into machine language. Assembly language is just a human-readable form of machine language. Somewhere in the program prior to this, you had to tell the assembler to send side a memory location and that we would in the future refer to it as “MyValue”. The assembler sets up something called a “symbol table” so that you don’t have to deal with numbered locations. You can just refer to it by a name you made up. You don’t have to remember it was location 6712 and you don’t have to remember that the opcode for loading register a was the hexadecimal value 3c. The Assembler takes care of that for you.

So there is a one-to-one correspondence between assembly language and machine language. Every time you write an assembly language line of code, the assembler translates it into a single machine language instruction. The advantage of assembly language is that you are talking to the computer in its native language. You can make the code run very efficiently because you are telling it exactly what to do in exactly what order. When you program in a higher-level language like FORTRAN, you are counting on the compiler to translate what you wrote in FORTRAN into something efficient in machine language.

The advantage of high-level languages is, they are easy for humans to write and read. The disadvantage is, that they might produce a sequence of commands that is not fully optimized. At least in theory. Today’s compilers can probably optimize code better than most programmers can. This is especially true now that computer processors have multiple CPUs that can execute multiple threads of instructions simultaneously. Modern compilers can figure out how to do that efficiently.

Back in the early 70s, people still used assembly language when they wanted the most efficient code. Sometimes today, you might still use assembly language if you are concerned about code that ran with exact timing because of hardware constraints. But these days, people very rarely write assembly code.

Even though assembly language commands tried to use mnemonic codes that were allegedly easy for humans to remember like LDA means load into register A, there were hundreds of commands with variations and we could never keep track of them all. We had something called an IBM System 360 Reference Card. It was a fan-folded card about 8 inches tall and perhaps 3 inches wide with about four panels printed front and back on green card stock. I’ve included an image of one in the YouTube version of the podcast. I found a PDF of one online. Somewhere along the way, the campus bookstore quit selling the famous “little green card”. They replaced it with a version for the IBM System 370 that was printed on white card stock. One day, someone said, “Can I borrow your little green card?” The sarcastic reply was, “They don’t make them anymore.” So then we grabbed the little white card and wrote across the top of it “This is a little green card.” So even though they were white, we still called them “the little green card.”

These quick reference cards were very valuable tools.

Years later, I met a guy named Paul Nanos. We were both members of the Speedway RadioShack Computer Users Club. Paul created a series of quick reference cards for a variety of personal computers. I helped him create one for the Timex/Sinclair 1000 computer. I sold the quick reference cards through my business although I never made much money from them. But that’s another story for another day.

By the way, in the examples above, I’m using codes for the Intel 8080 processor used in early personal computers even though the CS 300 class I took years ago was for the IBM 360. That’s another problem. Every type of hardware has its own unique set of machine instructions. It has a different set of registers and different commands to move numbers in and out of those registers and to manipulate them. So assembly language written for the IBM 360 that we had at IUPUI would not run on the Digital Equipment DEC-System 10 that we also had. Nor would it run on the IBM 1620 that we had. And none of those assembly languages would work on the new Intel 8080 or Zilog Z80 or MOS Technology 6502 processors that were used in the early personal computers.

However, if you wrote a program in FORTRAN and you had a FORTRAN compiler on your IBM 360, DEC 10, RadioShack Model 1, or Apple ] [ computer it would compile your FORTRAN program into the machine language of your particular machine, as long as you didn’t try to use any hardware-specific or operating system-specific features, it would work.

But when using machine language, a program written for one type of computer will do nothing on a different type of computer. A program intended to run on an Intel-based processor in machine language running Windows would do absolutely nothing on your iPhone which uses a completely different kind of processor.

That’s what bothers me about sci-fi stories where we can hack into alien computers or they can hack into ours and upload viruses.

Probably the worst offender was the 1996 film “Independence Day”. Jeff Goldblum was able to hack into the alien computer and upload a virus to disable the shields.

If I gave you a memory dump of a program written for IBM 360, unless you understood the internal workings of the machine and the exact function of every operational code, there is no way you could tell what the program did and there is no way you could write a program for that machine without that basic knowledge. When looking at the memory dump, there would be no way you could tell which of the numbers were program codes and which numbers were data that the program operated upon.

Machine language programs are nothing but strings of numbers in memory. There’s nothing inherent about them that tells you it’s from an IBM 360, Intel 8080, or a modern Intel series CPU. Oh, perhaps if you understood machine language for those types of machines you could try to reverse engineer it and see if it corresponded to machine language instructions for one of those machines. But if it was alien hardware, and you had no idea how the internal workings of their computers worked, you couldn’t make heads or tails out of it let alone write a program that would run on their hardware.

Anytime you see someone in a movie look at a string of numbers and suddenly declare, “It’s an algorithm that does… Whatever” that’s nothing but BS. I have seen that in a number of movies and TV shows. The worst offender of this scenario is the Star Trek: The Next Generation Season 6 Episode 20 “The Chase”. Captain Picard reunites with an old friend who is an archaeologist. Prof.Galin is killed by pirates who are trying to steal information from him. Picard discovers the professor is collecting a series of numbers but they have difficulty deciphering the pattern. They finally realized the numbers corresponded to sequences of DNA that had been found on planets all over the galaxy. They also determine that there is a secret message in DNA. There is nothing scientifically impossible about that. We can already produce DNA strands of a particular sequence so it’s not impossible to think that you could encode a message in someone creature’s DNA. The problem comes when Lieut. LaForge suddenly declares that there is more to this DNA than appears.

LaForge: This is not part of a natural design Captain. This is part of an algorithm coded at the molecular level.

Picard: An algorithm. Are you saying that these DNA fragments are elements in some kind of computer program?

LaForge: I know how this sounds but there is no way this could be a random formation. This is definitely part of a program.

That’s just ridiculous. So we got a string of numbers and they are encoded in DNA and we link them up to get a certain pattern but there’s no way to know that that string of numbers is actually a computer program. Because the way you turn numbers into programs is totally dependent upon what kind of hardware you are using. The number 3c in hexadecimal means something in register A on an Intel 8080, but that number could mean anything on a different kind of computer. A string of numbers that represents a program on one machine would be nothing but random noise for a different type of computer processor. Whoever it was that encoded this DNA allegedly billions of years ago would have no idea what kind of hardware we would be using today.

Later in the episode when they finally connect all of the pieces of DNA, somehow their tricorder device magically starts running the program and projecting a hologram of the recorded message. First of all the idea that this program could magically reconfigure the tricorder to project a hologram which is something we’ve never seen the device do before and that somehow decode the video and audio in 3D to project the message is totally ridiculous but we will them that one. The message was two minutes and 10 seconds long. I timed it. I downloaded that episode, clipped out the two-minute 10-second scene, and it was over 68 MB long. That must’ve been some lengthy sequence of DNA. Much longer than it appeared in the episode.

There are also stories where someone creates a computer virus and the simple act of looking at the file causes your computer to get infected. That’s a load of crap as well.

Probably the worst offender in this category was Dan Brown’s 1996 novel “Digital Fortress”. There was a computer virus that was so dangerous, they couldn’t open it to see what was inside it. That’s ridiculous.

A computer file is nothing but a string of numbers. If those numbers are in the proper form and you name the file “something.txt” then you can open it using the Notepad application and theoretically, it would have plain text in it. Or it would look like garbage. But opening a file with Notepad is not going to infect your computer.

Or if it had an extension like .docx then maybe it’s a Microsoft Word Document file. And if you use Microsoft Word to open the file, there might be some macro codes or program extensions embedded in it. That could possibly be dangerous but only because Microsoft Word allows you to embed programs in what should otherwise be a text file.

The most dangerous type of file is one with the extension .exe which means “executable”. If you try to “open” that file, your operating system will execute it as if it is a program. All you have to do to examine that file safely is to rename it as “whatever.dat” which means it’s nothing but a data file. Then you open it with a safely created program that doesn’t try to execute any code but just looks at the string of numbers inside the file and displays them for you. That is 100% safe. The only way a file can infect your computer is if you load the file into memory and somehow cause the program counter to start executing it like a program.

You don’t need anything special to look at a file safely. You don’t need an antivirus program. You don’t need an air-gapped machine (which means it is not connected to the internet). Computer programs are just strings of numbers no different than data. It’s only what you do with those numbers.

Okay, time to get off my soapbox and get back to my story…

When I got my first personal computer using a Zilog Z80 processor, I did have to write some assembly language. Sometimes I had to translate that assembly language into machine language myself because I didn’t have a suitable assembler program. One time I taught a class in Z80 assembly language for members of that computer club I talked about. The concepts I learned in writing IBM 360 Assembly carried forward when I had to write assembly language for other types of hardware. However, for the most part, I never had any practical use for the IBM 360 Assembly Language Programming that I learned in CS 300.

I said “for the most part” because although I never had a legitimate use for IBM Assembly, my first paid programming job was writing IBM Assembly Language– Illegitimately.

Anyway, I think it was perhaps my third year at IUPUI that a Computer Technology student came up to me and asked me if I would write some programs for her. She had to write about 15 very simple programs in IBM 360 Assembly. It was one of those situations where she had all semester to write these programs and waited until the last minute to do it. I was sympathetic towards her because I had been through the same scenario which I will tell you about in a later episode. Anyway, she needed to write about 15 programs in 10 days. She said, “I can write all of these programs but I just don’t have the time to do it by the end of the semester. Look at the list, pick 4 or 5 of them, and I will pay you $20 per program.”

I picked out 4 of the assignments and told her I would do them. I wrote the programs in FORTRAN but I did it in a very primitive kind of way. I pretended I was writing in assembly language. So I used very simple FORTRAN commands. I made sure that the program ran and produced the proper results. I could run FORTRAN on the DEC-10 by sitting at a computer terminal. If the program didn’t run properly, I could edit and rerun it a dozen times in just a few minutes.

Running programs on the IBM 360 was more difficult. You had to type the code onto punchcards using a keypunch machine. Submit the deck of cards to the computer operator which he/she would put in the pile and run them in the order they were received. Then you had to come back in a half-hour or so, pick up your output, and if it didn’t work, retype some of the cards and resubmit them. That’s why this woman could not get all those programs finished in time.

By getting the basic logic of the program working in FORTRAN, working out all the bugs quickly, and then rewriting them in assembly language code, I’m pretty sure all four of the programs worked the first time I submitted them.

She paid me in brand-new crisp $20 bills fresh out of an ATM. I used the $80 to buy a fancy new HP 21 scientific pocket calculator. It cost $125 but it got me most of the way there.

I know I shouldn’t admit that I helped someone cheat by doing their homework for them, but I looked at the other code she wrote and I am confident she was correct when she said she could have done them all if she had time.

My first legitimate programming job was also in assembly language but it wasn’t for the IBM 360. It was for the Intel 4040. The 4040 was a slightly more advanced version of the Intel 4004 which is widely considered to be the world’s first microprocessor. It was a 4-bit computer. Compare that with computers today that are 64 bits. It wasn’t good for much of anything although the way the computer architecture was designed, it was obvious it was intended to be used for a calculator. I don’t remember the details about it.

It was very primitive in that it would only add or subtract but it could not multiply or divide. Binary multiplication is pretty easy. You just shift the bits left and then add repeatedly. There was a guy who was an electrical engineer who was a friend of a friend. I don’t remember the guy’s name. I don’t remember the friend’s name. But he needed someone to write about 30 or 40 lines of Intel 4040 code for a digital thermometer. All it had to do was read in 6 bits of data from an input port, do some addition and multiplication on it, and store the result in a particular location. He gave me some photocopies of the hardware manuals for the 4004/4040 processor. I had to teach myself 4040 Assembler Language, write the program, and then hand translate it into a hexadecimal code because we didn’t have an assembler.

Along the way, I learned a little bit about digital electronics. For example, the “input” command read data from a pair of 4-bit ports for a total of 8 bits. However, we only needed 6 of the bits. I assumed that the other two bits which we were not going to use would default to zero. But they don’t. A disconnected pin on an input port of a microprocessor in all likelihood defaults to a “one” rather than a “zero”. So you have to mask off only the bits that you want. This was a lesson that I would use regularly decades later when I began programming Arduino-based microprocessors. I never dreamed that someday I would be programming a computer smaller than a deck of cards that had similar computing power to my first PC which was the size of a microwave oven. And that the programming skills I’ve learned on that simple little digital thermometer, would be essential to the microprocessor programming I would do much later in life.

Anyway, I wrote the program out in Intel 4040 Assembly Language on a yellow legal pad. To the left of each Assembly Language instruction, I wrote the hexadecimal codes that I hand-translated into machine language. To the right of the instructions, I wrote comments that explained step-by-step what the program was doing.

The guy paid me $100 and was quite grateful. He said if he ever needed another piece of code written he would be happy to hire me but he never did. But it was my first legitimate job as a computer programmer and I have fond memories of the experience. I spent that money on the more advanced HP 25c scientific pocket calculator that was programmable. I’ve got some funny stories about that gadget for another episode.

With the exception of everything I described above, I had absolutely no use for what I learned in “CS 300 Assembly Language Programming“. I earned 3 credits and an easy A.

I’m not sure who taught the class. I think it was a guy named Dr. Rizo but I’m not sure.

There was a more significant aftereffect of that class that has had a major impact on my life ever since then. One of my classmates in CS 300 was a guy named Rich Logan. You’ve heard me talk about him previously because he and his wife Kathy have been very loyal friends ever since our college days. They frequently take me to movies and occasional sporting events and have been the best friends anyone could ever hope to have. We will talk more about them and some other friends I made at about that time at IUPUI in next week’s episode.

It may be a difficult episode to write. I’ve talked about other people I went to school with in grade school, high school, and other college friends but they are all long gone from my life. We either drifted apart like my girlfriend Ellie or my buddy Dennis who I still keep in touch with but we are not close. Some of them sadly have passed away like my girlfriend Rosie or my good buddy Mike. But, Rich and Kathy are still a very big part of my life nearly 48 years later. I’m not going to be able to tell their entire story in one or two episodes but we will hit the highlights of the early part of our friendship in the next episode.

– – – –

I’d like to dedicate this episode to my good friend and caregiver Brandon Drake who tragically passed away from an epileptic seizure on March 9. You were a good friend and a great caregiver and I will miss you always buddy. Rest in peace, my friend.

– – – –

If you find this podcast educational, entertaining, enlightening, or even inspiring, consider sponsoring me on Patreon for just $5 per month. You will get early access to the podcast and other exclusive content. Although I have some financial struggles, I’m not really in this for money. Still, every little bit helps.

As always, my deepest thanks to my financial supporters. Your support means more to me than words can express.

Even if you cannot provide financial support. Please, please, please post the links and share this podcast on social media so that I can grow my audience. I just want more people to be able to hear my stories.

All of my back episodes are available and I encourage you to check them out if you’re new to this podcast. If you have any comments, questions, or other feedback please feel free to comment on any of the platforms where you found this podcast.

I will see you next week as we continue contemplating life. Until then, fly safe.