Software Development

That's when I learned about hardware sprites. Something that has only returned with 3D hardware around the turn of the millennium. The 3D hardware before then wasn't especially noteworthy considering that software was often just as fast. One aspect that I liked about I/O was that it too could be swapped out. In its place, you could find either ROM or RAM where the ROM, if available, could also be swapped out. The Commodore 64 actually had 64K of RAM. But it had a lot of ROM as well. Playing with I/O was fun because it was a matter of making the machine do what you wanted. There was no middle layer. There was nothing between your software and the hardware. It was direct. It was fast. And it was a heck of a lot of fun.

But BASIC could only get you so far. Sure, you could change the screen, play some sounds, and move sprites around, but BASIC has always been slow. I heard that the machine actually executed these things called opcodes. I didn't know what they did or how they worked, but I wanted to find out more. In the school library, I found a really thin reference book that contained all the opcodes with a one line description. TXA would say "Transfer X register into Accumulator." What did that mean? I had no clue. What's an accumulator? What's a register? What's X? It made no sense.

I read and reread the book until it clicked that X, Y and the Accumulator were three 8bit special pieces of storage outside of RAM. It's where everything happened. Once I understood that, everything else fell into place and that's how I learned Assembly on the 6502 (or rather the 6510 in the C64). I then got an Assembler from a friend and I started coding up software. I was amazed at how FAST and easy it was to program in assembler. As far as I was concerned, I did not understand why BASIC even existed because assembly was SO much easier to deal with. By this time, I had a disk drive and could save my work. The disk drive was also a computer with its own processor. I eventually wrote my own software for the disk drive as well and created my own hardware that would allow for much quicker data transfers between the C64 and the disk drive. I was doing multiprocessing before I even knew there was a word for it.

After that, I got an Amiga 500 and an Amiga 1200. I even had a couple of little programs published on the cover disks of the August 1995 edition of Amiga Shopper and the October 1995 edition of Amiga Format. Today, there are no more magazines with programs that you can type in or where you find cover disks with clever tools on them. For a developer, I can assure you there is no feeling like having your name and software published. And I'm not talking about shipping a product. I'm talking about having your work recognised in print. It's simply not the same as having your name mentioned on a blog or in a review where your software had a budget. I suppose it also goes to the scarcity of a resource. There were so many great and clever programmers that it was very difficult to get a mention. Oddly enough, what did the difference wasn't the software, but the packaging. For one of my tools that got published, the editor said he was going to go with another product, but decided to go with mine because it had better packaging and incredible docs (made by a friend of mine). Just goes to show where and how you get lessons in programming. Sometimes, it's not about the code at all.

All during this time, we were using what I used to call "THE BEAST". The PC CLONE. Bet you haven't heard that term in a while. Oh, why pay several thousands of dollars for something that a C64 was better at. The PC had EGA graphics with 4 colors (different modes had a different set of 4 colors). Yet the C64 had 16 colors. VGA ended up with 16 colours, but had one HUGE advantage, even on the Amiga. It had a 256 color mode. This is what I attribute the success of the PC. But the Amiga was doomed from the beginning even though I admired everything about it. While the PC's 256 color mode allowed for games like Wolfenstein and DOOM, the Amiga could only boast 32 colours (with an additional 32 half shades). Or it could do thousands of colors, but this mode could only be used to display pictures. Look up HAM mode. It's fucked up. The amount of colors wasn't the only thing holding back the Amiga. On the PC, the memory for the screen could be accessed with one byte for each pixel on the screen. That made things real easy, except for the quirks of X-mode, but that's another story. The Amiga dealt with bit planes. One plane allowed each bit to display one of two colors. Add another plane and you doubled the amount of colors. You could have up to 6 bit planes, but only 32 colors. The last plane only did half-shade. For animations, dealing with bit planes was horrendous. Even with hardware such as the blitter chip, it was too slow. And converting back and forth was even worse. This meant that games that could compete with the PC were lacking. Sure, there were plenty of great games and good attempts at replicating DOOM, but nothing that was on the same level.

Then two things happened. While the PC was about a decade late in catching up with the C64 or the Amiga, it had one thing going for it. PC manufacturers could completely change the hardware just as long as it could still execute old software. So faster processors started coming out. Today, it's common practice to replace your processor if you want to. And you can change your video card. These two things are what changed the computing world in the 90's. In the early 90's, game programmers were pushing the limits of what the processor could do. The game DOOM is in large part responsible for the popularity of the DX2-66. Even the faster 50Mhz processor was a dog in comparison. The reason was that the DX-50 has a full 50Mhz bandwidth with RAM, but the DX2-66 only had 33Mhz of bandwidth. For most applications, the DX-50 was quicker. But computations is where the DX2-66 excelled and this is why it ran DOOM faster than the common 3 to 8 frames per second of other machines.

In the late 90's and at the turn of the millennium, graphics hardware started to become available. It meant that game programmers had a piece of hardware where they could push the limit just as they did back in the C64 days. This provided a nice transition from pushing the limits of the processor to pushing the limits of the GPU. Programmers are drawn to puzzles. More importantly, they are drawn to new and difficult problems that have the possibility of becoming reality.

Today, we know what the next boundary is. It's multiprocessing. It's already begun. However, this time it's different. It's not about pushing the boundary of a single processor (whether CPU or GPU). It's now about being able to create software that doesn't care how many processors there are. Also, how can you push the boundary of anything when you don't even know what kind of setup you'll end up with?

This is where I know how this will turn out. Unfortunately, such a shift has never happened before. So the trends we are seeing today are not real trends. They are remnants that have surfaced from the emptiness left behind. In order to understand how things will turn out, we must first understand that innovation is almost never done because of business applications. Games drive hardware. This is and always has been a constant. You don't need 3D hardware for your spreadsheets and you're certainly not going to need holographic technology for your pie charts and reports. In business sense, these costs don't produce profits. However, with games, new hardware does mean profits (for hardware manufacturers at least).

What games will use multiprocessing? Before getting into that, let's look at how multiprocessing was used in the past.

1. Commodore 64

Machine connected to disk drive. Both machine and disk drive had processors. The disk drive wasn't often used with custom software, but it was used for copy protection and fast loaders.

2. Amiga

MC68000 series processor.
Sound chip Paula.
Graphics chip Agnus. (Contains blitter hardware and also something known as the copper. The copper is like a pixel shader, but for raster lines).
Video chip Denise. (Handle video resolutions and display).

This allowed for a LOT of multiprocessing and freed up the CPU. However, things were still done in a very much sequential manner. You set up the hardware and then used the processor to handle game logic.

3. PC

x86 processor (MMX, SSE, FPU can all be executed in parallel with certain conditions)
GPU
Other hardware devices like sound, hard drives, etc.

Again, although you can do a certain amount of multiprocessing, it's basically a matter of setting up the hardware and using the CPU for game logic. Future games could take advantage of multiprocessors with things such as parallel raytracing or even real time rendering.

In all the above scenarios, we have the CPU as the center of the universe. We send commands out to the hardware and wait for a response. This technique is so ubiquitous in the computing world, the thought never even occurs to question it. And why should we? It's brought us the command line, SQL, the web, etc. Heck, it's how most applications work. You have buttons that do something and give feedback. Menus are like that too. Most programming languages work this way. So much so that functional programming is becoming more popular. What could possibly be wrong? Everything is on the right track, right? Not exactly.

To answer this question, I have to return to when I didn't understand why ANYONE would program in BASIC. The question isn't about BASIC. It's about why anyone would use a high level language instead of a low level language that is easier, faster and gives the programmer more control. There is a plethora of literature on this and we'll dispense with it here. Suffice it to say that productivity trumps speed and control.

Here's the problem though. Productivity does not enter the picture when you are pushing the limit. These higher level tools are useless in such a case. Here's why. Apologies for the anime style back story, but it's an important lesson. Back when I learned assembly and was proficient at it, a friend asked me to teach him. I explained what registers are and what each instruction did. Yet he kept asking one thing: "How do you DO anything?" At first, I didn't get it. He said he could put together a million instructions together and there would be no results. How do you make the machine DO anything? That's where I/O comes into play. I hadn't explained that part. I took it for granted. I/O memory is what makes a computer work. On the PC, it even has its own addressing space. Once he understood that part, everything clicked. You use instructions to modify I/O memory which tells the computer what to do.

What's the moral of the story? It's that high level languages are dead end languages if they cannot access I/O memory. Java can't do it. Functional languages can't do it. VM's can't do it. But languages that have pointers can. This little tool that I learned from a friend of mine after exhausting all conventional explanations finally said, "Wait a minute! You know assembly, right? Well, a pointer is the same thing as indirect addressing." And that's how I understood pointers. I laughed out loud at how simple a concept it was, yet no one could explain it properly.

Access to hardware is the key. I'm not saying that high level languages are a dead end as it comes to writing software though. Let's be clear. What I'm saying is that functional languages and other higher level languages that use VM's are incapable of creating a revolution or of driving innovation. It's simply impossible. History is not on its side. Now that programmers are trying to grasp the complexity of multiprocessing, a void was created. In the status quo, higher level languages have taken prominence.

What will happen is that the way we think about building software will change. Unfortunately, it may take several generations in order to rid ourselves of misconceptions about how software should be created. Once there is a way to handle multiple processors as easily as handling a single processor, you will see innovation take place again. We know innovation is dying out because video cards are showing up with multiple GPU's instead of having more functionality. People don't want to commit money and resources unless they know it will work and will take hold. In short, they are waiting on game programmers to take the next step. If the games exist, they can tailor their hardware to it. The roadblock is that game programmers have to change the way they think about software. Not gonna happen anytime soon.

When that change does happen, it will be vastly larger than anything that preceded it. Techniques that could have been used in the past will be the first thing that programmers will explore. Then the more advanced techniques will start being discovered again for the first time. People will think that they discovered something new when it's been there all along. And the kicker is that access to hardware will always be there. The layers in between will start becoming unnecessary. It'll be portable and native at the same time. The abstract will merge with the concrete.

These aren't lofty goals or mystical notions. They are real. And it will happen. Don't let the current vacancy in innovation lure you into a sense of entitlement when it comes to higher level languages. In the past, all programmers needed was the hardware. Today, the opposite is true. Programmers are waiting for the tools to use the hardware. What they don't realise is that even if the tools existed, they'd still be waiting. We need to change the way we think about computing. Oddly enough, the future of computing has nothing to do with computing, but with ourselves.