|
|
Because Autodesk has been successful, there's a tendency to forget what a high-risk undertaking it was to start the company. Most of the founders of Autodesk were involved in preexisting ventures of their own, some while also holding down full-time jobs. Embarking on Autodesk meant abandoning these ventures, some of which looked quite promising at the time, for a new business in an untested market.
Starting Autodesk wasn't the only opportunity that beckoned at the time. I wrote this paper in late 1981 to plot the strategy of Marinchip and the people around it, who encompassed a large percentage of the Autodesk founders. This strategy represented the “safe evolutionary path” for Marinchip and would, had it been pursued, have led to utter failure.
It's worth keeping this in mind when evaluating new business opportunities that seem to diverge from Autodesk's traditional areas of success. Special thanks are in order to David Ciari, who typed in this entire document from the only existing paper copy.
Revision 0—September 29, 1981
by John Walker
This paper describes the background, plans, and goals for Marinchip Systems' hardware and software development projects. This paper is being prepared as a working document for Marinchip (MS), Evolution Computing (EC), Optimistic Systems (OS), and Pacific Software Associates (PSA), to identify how the plans will impact work in progress by each group, how work will be distributed among the organisations, and how the work must come together before goals can be met.
This is a working document. Nothing in here is final, decided, or immutable. It exists only to serve as a starting point for discussion and as a base for the development of a formal plan.
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.
The 68000 Node Board will be designed and prototyped by EC. MS will take over manufacturing, testing, and service after the final testing of prototypes. The anticipated specifications of the 68000 node board will be:
68000 CPU
256K Dynamic RAM with Parity (40 x 4164)
4K/8K/16K PROM (2 x [2716, 2732, 2764])
2 Async RS-232 ports (header pin connectors)
1 Parallel I/O port (header pin connector)
9512 Math processor (if it fits)
S-100 bus I/O interface
The node board will look like two I/O ports to the S-100 bus master. The base port address will be settable with a DIP switch. There will be a data port and a control port. Data written to the data port by port by the 68000 may be read by the S-100 bus master. The data port is bidirectional without restriction. The control port may be used by the S-100 bus master to:
Hardware reset the 68000
Interrupt the 68000
Set a status bit the 68000 can read
Clear interrupt
Clear status bit
The control port may be used by the 68000 to:
Interrupt the S-100 master
Set a status bit the S-100 master can read
Clear interrupt
Clear status bit
In addition the control port may be read to determine the value of the status bit. This allows either interrupt or non-interrupt synchronisation of data transfer between the host and the node board.
MS will write a 68000 assembler and linker in SPL. This will initially run on the 9900.
MS will develop an NOS support module for the 68000 which will allow programs to run as under NOS. It will make requests to the master CPU for I/O. This program will probably be put in PROM once stable. Marinchip will develop support code in NOS to handle these requests. This will probably initially be a user program (which will fit in space below the system). If demand seems to justify it, MS will develop a host support program for CP/M.
Somebody will convert META and its runtime system to the 68000.
Somebody will use 68000 META to convert QBASIC 2.x to the 68000.
Somebody will convert WINDOW and SPELL using the new QBASIC (not trivial because of assembly routines).
Somebody will convert Osborne packages, Selector, etc., to 68000 QBASIC.
Somebody will convert EDIT, WORD, and other 9900 assembly programs to the 68000, carefully considering whether they should be redone in QBASIC or SPL.
EC will convert SPL to the 68000. Using SPL, Interact may be converted.
We will be abandoning the 9995 node board project and the plans to redesign the M9900 CPU with the 9995. There are two major reasons for this:
First, the major problem we are having with all 9900 work is exhaustion of the 64K address space of the 9900. Neither the 9995 nor the 99000 solve this problem. The 99000 allows larger memory, and could be used with a segmentation scheme, but this is not a general solution and could not be used by unsophisticated users. We have to have a system where we can simply let the user buy more memory when his program won't fit. Thus, the major advantages of both the 9995 and the 99000 are higher performance, but neither of them delivers enough extra performance to compete effectively with the newer processors from Zilog and Motorola.
Second, The 9900 family is a largely unknown product since T.I. has failed to effectively promote it. The 99/4, considered T.I.'s last chance to establish recognition for the processor, is widely considered a flop. There is nothing in the 9900 family and nothing expected to be added which would cause a designer today to design in the 9900. Thus, the future for the 9900 is not bright. T.I. has been dropping product lines (bubble memories, watches) in response to poor market response, and the 9900 may go that way. It seems clear that if T.I. is to become a contender in the high-end micro market, it will not be with the 9900, so we would have to convert anyway. Remember, this isn't the first time this happened. The TI-ASC, for years the fastest computer in the world, only sold 7 units, 5 to T.I. divisions. Most people were unaware it existed. They dropped the product.
Since OS has converted most of our software to the Z8002, it would be
far less painful to go to the Z8001 CPU. In addition, off the shelf
Multibus systems exist with Z8001 CPU, memory management, and all the
large memory and support boards at excellent prices. The basic
problem with the Z8000 is that it is not a general large address space
processor. The Z8000 addressing is split up into “segments” from 0 to
127, and “displacements” from 0 to 64K.![[Footnote]](i/footnote.png){kind=small}
You can address 8 megabytes
by concatenating the segment and displacement into one address.
Segmented mode programs can do this in both direct address pointers
and in index register pairs. The problem comes in how indexing and
autoincrementation is handled. When addresses are added in the
processor, only the displacements are added, and the carry is
discarded. Thus, if you are indexing through an array and cross a
segment boundary, you wind up back at the start of the segment you
were in, not at the next one.
As a result, you can simulate large addressing only by manually computing addresses in software, bypassing the index hardware. This is grossly inefficient. You can ignore the problem if the linker never places a module across a segment boundary and dynamic allocation never splits a buffer across segment boundaries. This doesn't help you if the user simply declares an array larger than 64K.
Further, it seems that most vendors who have looked at the Z8000 for our type of general purpose application have shied away from it and are now working with the 68000. We've had it with trying to push unpopular products.
OS has put a large amount of work into the Z8000 software project, and MS has supported this with hardware purchases and loans. We continue to feel that this is a valuable product, and that if properly marketed it can return not only its development costs, but also make a reasonable sum of money for both OS and MS. With the general slant of the industry being away from the Z8000, we have to target our marketing carefully, since we can't afford big splash advertising.
MS has contacted Central Data about putting QBASIC on their system. This would involve a Z8002 to Z8001 conversion as well, so we would have to work on their system to do this. They expect their operating system to be ready early next year so we should contact them then regarding that. Since we don't expect to buy one of their systems now, this may be a sticky matter to arrange.
I think we should send out new product announcements about the Z8000 QBASIC, emphasising that this is an OEM-tailorable product we want to put under customer's operating systems, and announce the development software the same way. Also, we should put together a catalogue, manual package, and OEM schedule for this and pass it on to Lifeboat so they can pitch it to OEM prospects.
There's nothing wrong with what we've done with the Z8000. It just doesn't look worth putting a lot more money and effort into unless we can generate some interest in it. If the Z8000 is going to bomb, we'd better be somewhere other than the target zone. If, say, Lifeboat uncovers a vast market for Z8000 software, we'd be happy to change our mind.
This redirection will have remarkably little effect on the work in progress.
All work underway by PSA is conversion of QBASIC programs. These will be portable to the compatible QBASIC on the 68000. Obviously, assembly language routines should be avoided wherever possible. PSA's NOSMODEM will remain applicable as long as a 9900 host is retained, which will probably be for quite some time. Then they can convert it. Any development in SPL or QBASIC should be safe. The work on WORD will have to be carefully coordinated with the conversion. Maybe this is the time to rewrite WORD in QBASIC or SPL, or maybe PSA should convert WORD to the 68000 while adding the enhancements. Discussion is needed. PSA should avoid 9900 assembly programming like the plague.
EC will drop the 9995 node board project. The 9918A board will continue and Marinchip will market it as agreed. Marinchip's QBASIC drivers for the 9918A will not be converted to the 68000. This board will be offered primarily to existing customers who have expressed an interest in it. We won't advertise it heavily. EC will do the prototyping research on the 68000, hand wire a prototype node board, layout, tapeup, and prototype the actual node board. We anticipate a yield from the prototype run to supply MS, EC, PSA, and OS with all the 68000 node boards needed for development. EC will produce final separations, solder mask, etc., for MS to begin actual manufacture. MS will pay EC a per-board royalty on the 68000 node board, and will defray development and prototyping costs. The actual manufacturing of the node boards will be done with MS existing vendors and contractors and will not consume any EC resources, except for possible revisions and corrections as needed. EC may undertake the META conversion, and will convert SPL. FORTRAN should be developed with the large address space of the 68000 in mind. EC and MS should consult over features needed in the new linker to support FORTRAN.
OS can use a node board in the Z8002 system and work on 68000 code. Depending on the market we can stir up for the Z8000 code, OS will continue to develop and support that code. The Z8000 C should be evaluated for portability to the 68000, as that would be a very desirable product to have. Optimally, we could consider converting the OS machine to a native 68000 processor (when we can get one), and letting OS do the 68000 host support (NOS/MT conversion). This would not affect work with or use of the node board. We can lend OS a 9900 to bridge the conversion gap, if needed.
MS has no development work in progress, to speak of. We'll be busy enough converting code, we reckon, without taking on anything else.
With the emphasis on the 68000, Marinchip will cease to actively market the 9900 system to new customers. We will continue to support existing customers and OEM's, and we will continue to sell and service all our existing 9900 products. OEM's using our system will not be impacted by this change in direction, except if they anticipate future 9900 based products, which will not be forthcoming.
We will continue to market the 9900 software through Lifeboat, and if a new 9900 OEM walks in the door, we will not turn him away. However, we will be up-front about where we are going and what this means.
Our large-system OEM's will be encouraged to configure and expand systems by adding 68000 node boards. Our converted software should make this relatively painless and advantageous. We hope to keep these OEM's with Marinchip by offering them the same software, much better performance, less big system slowdown effects, better reliability, and a migration path which doesn't make them throw away either hardware or software.
We want to make it clear, though, that if an OEM is happy with the 9900, he can continue to get them for the foreseeable future.
We will announce all of this in the Shifting Bit in
a message for end users. We will basically say that support
continues, sales continue, but most new products will be 68000 based.
We'll explain the reasons and show how a user can upgrade at minimal
hardware cost.
As soon as we have the software on the node board, we will begin a multi-pronged marketing strategy.
We will market the 68000 utilities (QBASIC, SPL, WINDOW, WORD, etc.) under other operating systems by directly contacting other 68000 vendors and through Lifeboat. This would be sales on an OEM buyout or on a royalty basis.
We will announce a 68000 “system” and advertise it. This system will have a 9900 running NOS in 64K as the support processor.
We will announce the 68000 node board as an add-on to our existing customers and OEM's. We will emphasise its use in expanding or building large NOS configurations.
We will advertise the 68000 node board as a CP/M addition. We will supply CP/M program and disc so our software can be used on the 68000.
What we want to do is to sell the 68000 software to OEM's, and possibly (say under XENIX) to end users. We'll try lots of alternatives to get the visibility we need to find them.
The current structure of the MS-OS-EC-PSA community is a complete
mess. Before we all get into this stuff we should figure out exactly
how everybody's going to be compensated for what they do.
MS intends to continue being the “shock troops” of the
community. We'll do the manufacturing, testing, advertising, mailing,
phone answering,
shipping, and receiving.
OS, EC, and PSA will thus be freed to get development work done
(although they are certainly welcome to do scuzz work if they
wish!!). The cleanest arrangement for MS is to simply handle all work
by OS-EC-PSA on a royalty basis, paid per item sold, credited upon
sale. We would define the royalty as a percentage of the payment
received by MS for the item sold, so discounted OEM sales would be
attractive to MS to negotiate for.
MS will pay for the hardware and other out of pocket expenses involved in getting into the 68000. We will provide node boards to OS and PSA at cost, with payment deferred until offset by royalties. (EC, of course, will just keep a prototype of the node board).
MS would like to renegotiate the agreements for MIDAS software from PSA to the standard percentage royalty. This isn't to grab more money, it's to remove the ambiguity in OEM sales (e.g., if the royalty is a fixed price and we discount the package to 50% off to sell 20,000 of them, we'd end up losing money on the deal, so we can't pursue it). Also, we could promote those packages more aggressively.
Further, we must normalise the status of those packages initially developed and nominally owned by MS, which others have or are planning to enhance. We need to somehow make work on those packages pay off via a royalty or upgrade charge from sales of the package. We can't afford to let sidelines build up for these packages, especially if we're going to be moving them between processors.
We can help all these goals by unbundling the 68000 software as much
as possible. If we eliminate the “free software” concept, we can at
least handle royalty on a reasonable basis.
None of this implies that there's anything wrong with developing products and selling them directly. It's just that if we're going to go after large volume OEM sales, it's to the advantage of the developers of software to have it visible to all potential customers who may examine our software. We need to make something on the software we sell that way to defray the costs of learning it enough to answer questions and intelligently market it, to do the front line support, and to handle updates, etc.
The following are things we need to pin down.
How much will it cost us to build the node board? How much should it sell for? What will be the problems making and testing it?
Who will do what in converting the software? What items are on the critical path? What other priorities are contending for the time of these people? What interest in the revenue from a piece of software will converting it earn?
How should the completed plans be best presented to dealers and OEM's? What is the best way to announce and advertise the products? What do we do about one-off user inquiries?
What exactly will be MS's role in selling Interact and PSA-developed software? Are EC and PSA prepared to provide full end user support? If not, how much will it cost MS to do so?
How can we use the conversion to the 68000 to make the next conversion easier? What should be rewritten in a higher level language now? What language?
Should we put OS's C on the 68000? Whitesmiths is supposed to have a C for the 68000 soon. Should we use it?
What about the INS16000? How about the IAPX432? Should we make node boards for them also? How real are they? Is software for them in demand? What pieces can we sell?
What is the maximum capital drawdown we can expect before we find out if this was a good idea or not? How long should it be until we know? If MS is putting up all the development money (and hence taking all the risk), what is reasonable compensation for that? What do we do if it doesn't work?
|
|