MS, EC, and PSA are engaged in marketing a dead horse. The time for the 9900 to establish itself as a contender in the microprocessor sweepstakes has come and gone. We are faced always with a selling job that T.I. should have done for us, not us for them. Our processor cannot compete in performance, address space, instruction set, or available software. No announced product from T.I., or any direction indicated in their product development holds out a hope for elimination of these problems.
Our selling point is our software. Our software is portable between processors. We should not consider ourselves tied to one processor or manufacturer because of a decision we made in the past.
We've discovered in converting the code to the Z8000 that conversion of even assembly language code poses no horrors. OS has developed the conversion tools for the Z8000, and we have learned how to best approach the problem. In addition, OS has made a native code MDEX, saving some work that would otherwise have to be done.
The Z8000 is not a good base for our future development because of the segmented memory addressing architecture, possible register set exhaustion when in segmented mode, and because the market perception seems to be that it is not the best product.
Based on our evaluation of the products available and the market's perception of them, the Motorola 68000 seems to be the best really available, second sourced, processor. Its instruction set and register architecture promises an easy conversion of our code. Its memory architecture imposes no limits on future system growth.
There are no currently available boards, either S-100 or Multibus, which implement the 68000 in a general fashion including memory management. Without the memory management chip, the 68000 can not be used in a secure multi-user mode. The memory management chip is only available in samples now, so it will be some time until boards are available.
The best way for us to work with the 68000 is to design a ``node board'' exactly like the one contemplated for the 9995. This board (in its final PC implementation) will have a 68000 CPU, 256K RAM (depopulatable to 128K), 4 or 8K PROM, 2 SIO, 1 PIO ports, possibly a 9512 math chip, and an S-100 I/O bus interface. The 68000 will talk to the S-100 bus only as an I/O device.
Given this board, all those with 9900 systems can start working with the 68000 immediately. NOS will support the 68000 as a node processor, so all existing 9900 peripherals may be retained unchanged, and may be accessed through the 68000 as well as the 9900. The 68000 will then also be a straightforward upgrade for our existing customer base.
The software for the 68000 node board will request all I/O through the host system processor. NOS will, of course, support this protocol. We can write a CP/M program which talks this protocol and allow the 68000 to be added to a CP/M system using all our 68000 software. The only restriction is that file names on the 68000 would then have to conform to the CP/M standards (and that JSYS requests not supported by CP/M could not be performed). All the compilers should run with no difficulties. There might be a reasonably large market for such a product.
Once the software is converted to the 68000, we can shop around for an S-100 or Multibus 68000 to serve as the host processor. On finding one, NOS/MT will be converted to run on it, using memory management to support multiple users. Of course, node board users will also be supported (if Multibus, we would have to make a Multibus node board). This work would gain us an all-68000 system (easier to sell and maintain), a cheaper entry level system (no 9900 required, no processor per user, better memory utilisation=less memory), and the ability to run programs of any size, not limited to 256K.
Editor: John Walker