Relocating Loader (RLC) Format: Difference between revisions

From Bitchin100 DocGarden
Jump to navigationJump to search
(New page: == What is RLC == The Model 100 use an 8085 CPU. This CPU does not support position independent machine code, at least in any traditional sense. Also, the Model 100 has no built-in suppo...)
 
No edit summary
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== What is RLC ==
== What is RLC ==


The Model 100 use an 8085 CPU. This CPU does not support position independent
The Model 100 uses an 8085 CPU. This CPU does not support position independent
machine code, at least in any traditional sense.
machine code, at least in any traditional sense.


Line 7: Line 7:
language files over the serial port.
language files over the serial port.


Presumably for these reasons, the authors of programs residing in the M100SIG on
Presumably for these reasons, someone created the RLC format. RLC is a representation of an 8085 machine
Compuserve created the RLC format. RLC is a representation of an 8085 machine
language program that is relocatable and 7-bit clean.
language program that is relocatable and 7-bit clean.
There are many programs in the Compuserve Model 100 SIG archive, for example, that are formatted
as RLC files.


== Format ==
== Format ==
Line 15: Line 17:
=== Overview ===
=== Overview ===


RLC is basically a ASCII base-16 representation of an 8085 machine language
RLC is an ASCII base-16 representation of an 8085 machine language
program. Unlike traditional hexadecimal, however, it uses the ASCII characters
program. Unlike traditional hexadecimal, however, it uses the ASCII characters
<pre>0123456789:;<=>?</pre>
<pre>0123456789:;<=>?</pre>
It starts with a header, followed by the body, and ending with a
It starts with a header, followed by the body, and ends with a
checksum. Whitespace is permitted, and most RLC files seem to keep the data
checksum. Whitespace is permitted, and most RLC files seem to keep the data
less than 128 bytes per line.
less than 128 bytes per line.
=== START ===
One value must be supplied at load time which does not appear
in the RLC file: the START address. START is
where the user wants to locate the relocatable image. The first field in the body
will be poked into RAM starting at START. Note that there must be sufficient space
CLEAR'ed at START to load the program.


=== Header ===
=== Header ===
Line 40: Line 50:
=== Body ===
=== Body ===


=== Trailer ===
The body of the RLC file is a sequence of fields and whitespace.
Whitespace is generally needed just to separate lines.
 
The two types of fields are octets and relocation offsets.
 
==== Octet ====
 
An octet is a two-ASCII-character, base-16 representation of a byte. The high nibble appears first.
 
No separator between octets is required.
 
==== Relocation Offset ====
 
A relocation offset is represented by an '@' sign and followed by a
big-endian, base-16 representation of an address to be relocated.
 
<pre>
@035>
</pre>
 
In hexadecimal, this would represent the offset 0x035E, or 862 in decimal.
 
In order to format as 8085 binary, this is added to the user-requested START
address for the image and formatted in little-endian byte order (least
significant byte first).
 
=== Checksum ===
 
The RLC file ends with the checksum in decimal format.
 
The checksum is the arithmetic sum of all offsets and octets in
the image. It is at least a 32-bit integer.
 
In the examples I have seen, it occurs on its own
line and is preceded by a space.
 
[[Category:Model T Developer Reference]]

Latest revision as of 23:02, 30 January 2009

What is RLC

The Model 100 uses an 8085 CPU. This CPU does not support position independent machine code, at least in any traditional sense.

Also, the Model 100 has no built-in support for transferring binary machine language files over the serial port.

Presumably for these reasons, someone created the RLC format. RLC is a representation of an 8085 machine language program that is relocatable and 7-bit clean.

There are many programs in the Compuserve Model 100 SIG archive, for example, that are formatted as RLC files.

Format

Overview

RLC is an ASCII base-16 representation of an 8085 machine language program. Unlike traditional hexadecimal, however, it uses the ASCII characters

0123456789:;<=>?

It starts with a header, followed by the body, and ends with a checksum. Whitespace is permitted, and most RLC files seem to keep the data less than 128 bytes per line.

START

One value must be supplied at load time which does not appear in the RLC file: the START address. START is where the user wants to locate the relocatable image. The first field in the body will be poked into RAM starting at START. Note that there must be sufficient space CLEAR'ed at START to load the program.

Header

The first line starts with (in ASCII format) the number of bytes in the RLC file, followed by the offset within the image to the entry point.

The numeric values are space separated. For example, here is the first line of an RLC file coding for a 7387 byte image, whose entry point is the first byte of the image.

7387  0

It is not clear whether the header needs to be on its own line. It is also unclear whether the first line needs to start with a space.

Body

The body of the RLC file is a sequence of fields and whitespace. Whitespace is generally needed just to separate lines.

The two types of fields are octets and relocation offsets.

Octet

An octet is a two-ASCII-character, base-16 representation of a byte. The high nibble appears first.

No separator between octets is required.

Relocation Offset

A relocation offset is represented by an '@' sign and followed by a big-endian, base-16 representation of an address to be relocated.

@035>

In hexadecimal, this would represent the offset 0x035E, or 862 in decimal.

In order to format as 8085 binary, this is added to the user-requested START address for the image and formatted in little-endian byte order (least significant byte first).

Checksum

The RLC file ends with the checksum in decimal format.

The checksum is the arithmetic sum of all offsets and octets in the image. It is at least a 32-bit integer.

In the examples I have seen, it occurs on its own line and is preceded by a space.