| A NOTE FROM THE EDITOR |
| ARTICLE -- HOW TO PROGRAM EVERYTHING -- A STEP BY STEP GUIDE |
|
Right now I'm sitting in a Greyhound bus station in Thunder Bay,
Ontario to hide from my past. That thought only grazes my consciousness
for a minute though, because I have a secret I need to share. A big
secret. A lot of professional programmers have been keeping a secret
from you. They don't want you to know the truth. To be honest, I wasn't
sure if I should tell you, but it must be said. I'm here to tell you
what every programmer needs to know; I'm here to tell you how to
program everything and anything. I'm sure you can understand that I'm
putting myself into mortal danger by telling the world like this, but
without this information, an entire generation of programmers may keep
living with the wool pulled over their eyes, and I cannot allow that,
especially in QB, where the programmers are so bright, but many of them
still don't understand the one fundamental truth.
There has only ever been one program ever written, and every other has been a clone of that. In these paragraphs, I'm going to explain The One Program in detail, I'm going to point how that original program works, and how you can use the innate knowledge of The One Program to code anything you've ever wanted. The One Program The one program ever written is deceptively simple, mostly because programming languages make it simple. In reality, the operating system, the BIOS, and the programming language dummy it down so much most people can't see it, but I'll tell you what it is. 10 PRINT "HELLO WORLD!" 20 INPUT "Try again"; Answer 30 IF answer = "yes" THEN GOTO 10Deceptive, isn't it? Let's look at what the program is really doing though. There's where things get interesting. 10 PRINT "HELLO WORLD!" The first line of the program is probably the most abstracted, so read carefully. After that things get a lot simpler, so just bear with me. The PRINT statement represents several stages of memory reading and writing, array indexing, pointers, and many other aspects of most output engines, whether it's a 2d tile engine in VGA, or a fullscreen bitmap renderer using SVGA, or an RS232 teletype terminal. In many ways, it's even more difficult. The first major part of the PRINT statement is a huge memory location at &HB800. In this segment, all text data is stored. To let the video card know that a character is at a certain location, two bytes are written to the screen: The first is a character code, which is just a pointer to a certain element in an array of font sprites in the video cards memory, the second is a type code, which determines the foreground colour, background colour, and status as a special text type (bold, underlined, flashing, etc...), which tells a special routine on the video card how to render it. In turn, that rendering program on the video card will try to draw to the video segment at &HA000, placing the fonts by placing the bitmaps found at the array I mentioned earlier onto the screen in a prescribed format, which is determined by the video mode, which is stored elsewhere. Knowing how that process works from &HB800 onwards, the largest hassle for the moment, several steps before the text appears to the screen, is knowing what kind of text you're rendering and where. Internal variables keep track of both of these, whose movement is likely controlled by other routines which are designed to scroll the screen down when text reaches the bottom of the page. From here, we finally have enough information to send the text to the screen. This is done by starting at the sprite pointer, whose first couple bytes are descriptor bytes in QB which describe the length of the string (C and C++ use a null character at the end, which is easier for low-level programming by humans, but opens the door for things like buffer overruns, the cause of many internet vulnerabilities in software today). Reading the relevant information and skipping over the rest of the header, the print routine reads the character from the string, puts it at the correct memory location, and goes on until the end of the string is reached. Then the OS is sent a "carriage return" character, which increments the row variable mentioned earlier. Finally, the text is on the screen. 20 INPUT "Try again"; Answer Since we have already defined the print routine, this command becomes much, much simpler. In fact, the first step is to just print "Try Again", then without sending any "Carriage Return" characters, a "?" is printed, again without a "carriage return", and finally the input function itself starts. The first step of the input routine is simple; input. BIOS routines handle reading the keyboard, and change a stream of pure keydata into a manageable single character ASCII code. This is added to the string being captured, and drawn onto the screen using something like PRINT. After an enter key keypress is detected, the string is converted into a floating point number (because we didn't do a defint earlier), which is entered saved into the memory location provided, Answer. 30 IF answer = "yes" THEN GOTO 10 The final step of this program is deceptively simple in terms of actual work done, but for most people, the work done isn't immediately apparent. The important thing to realize is that a PC cannot simply check if two strings are the same. The machine goes through the letters, one at a time, and if any differences show up, only then does the program know that they are not the same. At this point, the processor itself sets a variable right on the processor, and another instruction tells the instruction counter on the CPU that it must go to instruction 10. In terms of machine language, it's slightly more difficult because there is no instruction 10 as we know it, but the compiler counts that for us, thank god. How is this relevant? By now, You're probably asking yourself "What happened to teaching us how to write any program?". Well, I'm sure most of you recognised parts of that description. From start to finish, no major part of programming wasn't covered. More importantly, all major algorithm types required to handle Input, Output, and data manipulation. For example, if one was going to write a particle system, a data structure not unlike the &B800 array would be perfect. If one were to write a tile engine, a routine not much different from the PRINT routine would work just fine as a starting point. If someone wanted to write a 3d game engine, the same pointer structures and the same multiple rendering modes used for different video modes' text routines would be added, with only a few small changes. In essence, once you understand exactly HOW any program works, on an intimate level, you can create any other program using the framework of knowledge you get from the first. It sounds like a cop-out, but I invite you to take the next program you want to write, and try to break it down into known elements, like pointers, arrays, strings, data structures, et. cetera. You should find, as most people do, that once you start thinking in that way, all programs break down, and you will indeed, as I promised, be able to write any program. In other words, I hope you were paying attention. Article by SJ Zero |