Leor Zolman 362 Memorial Dr Cambridge MA 02139

Many microcomputer hobbyists pass through an early stage in the development of their systems where machine language is the only mode available for programming. My system configuration at that point included an IMSAI mainframe and 4 K memory, a VDM-1 video driver and monitor, and a Tarbell cassette interface. The big problem when programming something like LIFE for the VDM in machine language occurs when it becomes necessary to insert a routine (call it routine y) between locations x and x+1 in memory. I found myself with two miserable options open:

About the Author Leor Zolman has been programming for years, including such applications as medical graphics for Cedars of Lebanon Hospital in his hometown of Los Angeles. He is currently working on a 2 K resident monitor for the 8080, and characterizes himself as a BASIC games enthusiast. Mr Zolman is 17 years old and a freshman at MIT.

My solution to this dilemma was to write a machine language program which performs the second type of relocation above quickly and painlessly when given just 11 bytes of relocation data as shown in table 1.

The program, which I call the "relocator," performs its duty in two phases. Phase 1 simply takes the block whose first address is a, and whose last address is b, then transfers it as is to the area beginning with address c. That's it for phase 1. If the function select byte is equal to 02, then the relocator quits here and goes into an infinite loop which shows up as a known pattern in the lights of an Altair or IMSAI front panel. This is an indicator of the end of execution.

Phase 2 is the tricky part. All addresses (meaning all 2 byte operands of 3 byte instructions) which fall between items a and b above (inclusive) must have added to them the distance (number of bytes) which the block was moved. This value is easily computed by the expression c-a. For example, if a ten byte block was moved from starting location 10 to decimal starting location 75, then the value 65 must be added to any 2 byte operand in the program having a value from 10 to 20 inclusive.

The purpose of items d and e in the relocation data is to tell the relocator where it must look for such operands (references), so that they may be altered or "fixed" accordingly. Since the references may lie anywhere within the program (not necessarily just within the relocated block) d should be set equal to the very first location of the program, and e should be set to the last. The exception to this, which occurs when a data block lies in the way, will be covered later. [To avoid the exception, the "good" programming practice of keeping data separate from executable code is highly recommended ...CH] Phase 2 may be executed without phase 1 if the function select is set to 0.

The beauty of this program becomes apparent when a friend having 32 K in his machine hands you a tape of a program he wrote residing somewhere up in the sky (or so it seems to you, with only 4 K) and you would like to run it. All you have to do in this case is:

1. Load in the relocator
2. Load in your friend's program in any free memory space
3. Feed the relocator this relocation data:
   1. the original first address of the program
   2. the original last address of the program
   3. the location where you loaded it (first location)
   4. same as c
   5. c + length of the program (this equals c + b - a + 1)
   6. 00 (function select to fix references only)
4. Examine the start of the relocator and hit run. When the LEDs stop flickering (about 1 second for each 1 K between d and e) hit stop. You should see C3 in the data LEDs of an Altair or IMSAI.

That's it! Now the program should run right where you loaded it, unless one of the following problems occurs.

The block move (phase 1) is done tail first. For a block of length n, then, byte n of the source would be transferrcd to byte n of the destination, then byte n-1 would be moved, then n-2, etc. up to byte 1. Therefore, relocating forward into higher memory always works, but relocating backward into lower memory fails if the difference between the source and destination addresses is not greater than the block length. In such a case, say moving a block at b to location a, an intermediate relocation must be done from b to c (where |c-a| > length of block), and then a second relocation must be performed from c to a. Note: I could have had the relocator check the direction of the move and proceed either tail or head first accordingly, but the program is long enough to cause toggling headaches as it is.

LXI instructions in which the operand happens to equal an address in the block between a and b but doesn't actually refer to an address (LXI H, 0000 is a good example) present a problem. If you are in the process of writing the program try to use LHLD instead (or, if worse comes to worse, LHLD with MOV B, H and MOV C, L for LXI B, xxxx) and set aside two bytes of storage at the end of the program for the data.

If the program was not written by you, or if you really want to use LXI, then the only alternative is to go through your listing (if you have one!) and change the locations in question. But this problem never caused me much trouble.

Avoid relocating data whenever possible. If relocation is necessary do not try passing through it with phase 2. Here is an example of how to handle data areas: In a program residing from location d to location e, a block starting at a and eriding at b is to be moved to location c. As a complication, a data block resides from location f to location g. See figure 1 for a memory map of this situation. The relocation should be performed in two runs of the relocator as follows:

In the listing provided the relocator resides at locations 0D00 to 0DFF, but it is self-relocatable. of course. The six key items of relocation data must be set up at locations 0DDD to 0DE7 as shown in table 1, with the low byte coming first numerically in each case.

I sincerely hope that this program repays your understanding und toggling efforts with a vast reduction in relocation frustration.

The value of this program becomes apparent when a friend having 32 K in his machine hands you a tape of a program he wrote residing somewhere up in the sky (or so it seems to you, with only 4 K) and you would like to run it.