COMPUTE II ISSUE 3 / AUGUST/SEPTEMBER 1980 / PAGE 40

T. R Berger

There seems to be some curiosity about OSI's non-BASIC ROMs, i.e. ones above address $F800. The schematic for the C1, 2, 4, and 8 shows a 2K ROM (type 2316B). Disassembly shows that the C1 has the full 8 pages of this ROM addressed in memory locations $F800 to $FF00, but the C2, 4, and 8 have only 3 pages of this 8 page ROM appearing in memory. Actually, there is only one 2K ROM used in all these machines! (The old C2's without polled keyboard and the C3 with serial monitor or hard disk are exceptions which we will ignore.)

The C2, 4, and 8 have special address selecting circuitry which allows the computer to choose and address any 3 of the 8 pages in this 2K ROM. The C1 does not contain this special circuitry (presumably to cut costs) so that all 8 pages of the ROM appear in memory whether or not they are needed. The C1 uses 4 of the 8 pages and the remaining 4 pages fall where they will, misaddressed and unrunable. Since the C1 is the only machine with all 8 pages, let us use C1 addresses to describe the various pages of this ROM.

The page in which a segment of code appears in the C1 is not necessarily the page in which the code is written to run. For example, Cold Start for ROM BASIC C2, 4, and 8 computers was written to run in page $FF but appears in page $FB in the C1. In particular, in the C1 at $FB43 we see JSR $FFB8.The requested subroutine now appears at address $FBB8 in the C1 and $FFB8 is actually the third byte of a jump instruction. If the computer is asked to run this code, this subroutine jump will send the computer to limbo. Thus the code (with minor exceptions of no importance) in page $FB of the C1 will not run.

Table 1 gives a summary of the various functions of this ROM. The first column gives the C1 page number, the second column gives the model numbers of Challengers which use the given page of code (e.g. 4 means C4); the third column gives the type of machine (i.e. ROM BASIC or Disk); the fourth column gives the function of the page; and finally, the fifth column tells in which page the code was written to run.

C1 owners with a disassembler may read the code which all of us run. The rest of us will have to make do with the pages we actually use. However, not much is missed since the code is highly redundant. Commercial computer users know that the most costly facet of computing is software development. OSI can sell its computers at low cost because of a policy minimizing software development costs. That is, if a program is written for one machine, and by patching existing code it will run on another (even though at less than peak efficiency) then, by all means, patch. Thus the C1 code in these ROMs is just patched versions of the code written for the C2, 4, and 8. If this ROM were rewritten carefully, it would easily fit into 1K and run on all machines. But the larger ROMs come much more cheaply than rewriting the code. MORAL: Hardware is cheap, software is expensive. Businessmen know this; we do too when we yell ‘software ripoff!’

Since C1 run pages differ only in patches and relocation (with precious little relocation) from C2, 4, and 8 run pages, it is necessary to only understand about half of this ROM in order to understand it all. The fundamental pages are listed in Table 2. When the code was patched to run on the C1, every effort was made not to move addresses. For example, where the machine monitor for the C2, 4, and 8 resets a P1A not available on the C1, (C1 addresses $FA04 to $ FA0B), the corresponding code for the C1 is filled with NOP instructions (C1 addresses $FE04 to $FE0B).

I am writing a series of articles on the OS65D operating system. The first article, on the Kernel, should appear in the next issue. At least one later article in this series will be devoted to this ROM. In particular, much more detail on these ROMs will appear in the near future. If you have urgent questions, you may send a stamped self-addressed envelope to me at:

Tom Berger
10670 Hollywood Blvd.
Coon Rapids, MN. 55433