The Space Shuttle Reloaded
After renaming the volume label successfully, I set myself the next goal: I wanted to create my assembly program to write a text file on the hard disk. I was struggling with the growing complexity of the new program for this task and I felt that I needed a new step in the tools I was using to write code so I started looking at MASM.
The biggest limit with DEBUG.EXE is that I couldn't give a label to an address so that every time I needed to make even a small modification to the program, it took a huge amount of time to check and fix all jumps, calls and address of data.
To show how bad this problem was, let me talk about the jump instructions in assembly. There exist jumps in three forms: short, near and far. Far-jumps use an absolute reference for the target address, short- and near-jumps use a relative one1. "Short" means a jump in the range from +127 to -128 bytes from the address of the Instruction Pointer (IP) of the next instruction and "near" means a jump in the range from +32767 to -32768 bytes. As a consequence, there exists a short-form of the OPCODE like 0xEB ?? (where ?? is the two complements single byte used to code the jump) and a near-form of OPCODE like 0xE9 ?? ?? (where 0x???? is the two complements word used to code the jump). Given this peculiarity, I had to triple check what DEBUG.EXE produced because very often I was in the following situation: I had a code with a backward jump at -125; then I had to fix a bug and maybe I changed one instruction in between the jump making it now a jump at -129 which cannot be coded in the short-form (2 bytes); DEBUG.EXE coded it in the long-form (3 bytes). The consequence was that the complete code in downstream was then one byte off and I had to fix all jumps again. By fixing the jumps, it happened sometimes to cross again the boundary among short- and near-jumps somewhere else in the code, which created a new shift. Sometimes it took me four iterations to fix all jumps. This was a very slow and painful way of proceeding: the point when I stopped and I said to myself "I have to find a new way for it!".
MASM can help me a lot and it seemed to me that I could manage to learn it, so before opening a new "chapter in my mind" with the learning of MASM, I wanted to close the old "chapter DEBUG.EXE" and consolidate what I have learned so far. Talking about learning I feel that I need to make it clear for the reader what I want to learn. I want to learn how the PC works. I don't care about learning how to write programs. Learning assembly and learning how to write programs is a tool that serves the main purpose which is learning how the computer works. Academics learn how computers work by reading a lot of books (I do it too by the way), hobbyists like me need to make things and make experiments in order to learn how the computer works: pretty much the same as a kid needs to make experiment with the toy to learn how to use it. For me, learning how to develop software is not the purpose (even if I realize that I am getting better and better the longer I practice). Learn how to use DEBUG.EXE, MASM or even VISUAL STUDIO is a "secondary" achievement (so to say) that serves the "main" purpose of learning how the computer works.
I thought that the best way to close the learning experience with DEBUG.EXE
was to create my toy boot loader the
Space Shuttle
again.
Space Shuttle
had a lot of embedded bytes that made it tight to the specific partition. It
couldn't be just copied and pasted on a different PC or even on a different
partition of the same PC, so I wanted to create a more generic version of it.
I had a second test rig in parallel to the IBM-T41 (I kept using it): an HP
Elitebook 8540w. I wanted to repeat the same experience as in the post
"Set up the test rig"
and as in Chapter III
, but this time I wanted SHUTTLE2 to be more generic.
Those were my steps:
- I prepared the HP Elitebook in the post "Initial setup".
- I wrote SHUTTEMP, which was a fixed 512 Bytes, halfway completed program, in the post "The template for SHUTTLE2".
- I wrote MAKESHUT which adapted the template, based on the information in the BIOS Parameter Block, to produce the final program SHUTTLE2 (as you will read in the post "The builder for SHUTTLE2").
- Finally, I tested SHUTTLE2 on my two different computers as you will read in the post "First launch of SHUTTLE2".
This was the exercise that I gave to myself in order to conclude the use of DEBUG.EXE as a tool to write programs. I thought that this made sense and would give me back a SHUTTLE2 which I could use on every PC. I thought also that this would have been a low hanging fruit to take, and I was wrong. This was complicated and very long indeed, so much so that what in my original intention had to be just one post, had become a new chapter by itself.
Comments
Post a Comment