|
|
Autodesk's development efforts were officially underway when the Information Letter 6 was written in late May 1982, but nobody had yet begun to work on AutoCAD. We were still hoping to port the SPL compiler and use the original source code. And besides, AutoCAD was not seen as our flagship product. But, at last, our marketing was underway.
This information letter is a random collection of news notes, technical information, and reports on progress on various fronts.
Since we started talking about forming the company, we've been looking for somebody to join the company with a strong marketing background and extensive knowledge of the computer field. At last our search has ended. Mike Ford, a former Vice President for Sales at Information Systems Design, has agreed to join the company on June 1, 1982. Mike will be buying into the company on the same basis as everybody else, using the option offering we're doing for the out of state participants.
Mike's marketing experience in the computer field goes back to
1956. He has worked for such industry giants as IBM, RCA, and
Univac, and was instrumental in rescuing ISD in its time of peril.
Since 1977, he's been running a company he formed to provide
employers with employee benefits statements for their personnel.
The package which does this was designed by Mike and is written in
CBASIC under CP/M. Mike is also becoming a dealer for the Victor
9000 machine (made by Sirius, and sold under that name outside the
US). The Victor is an extremely attractive 8088 based machine
which offers twice the memory, 5 times the disc capacity, double
the graphics resolution, and built in serial ports for the same
price as the 2 disc IBM PC. Mike's connections with Victor not
only allow us to obtain these machines for internal use at
attractive prices, they give us the contacts to sell our software
to Victor and Sirius. The Victor machine is an ideal host for
MicroCAD, as the basic package has the graphics resolution, enough
memory and disc, and the serial ports needed to do serious work
with MicroCAD.![[Footnote]](i/footnote.png){kind=small}
At the moment Mike is preparing marketing plans for our various products and trying to compile prospect lists and publicity channels. If you know reviewers for magazines, who to contact to get a computer store to try out a package, somebody who can get press releases run, or any such information which might be of use, please pass the information on to Mike either directly or via myself.
We're now the owners of a IBM Personal Computer. We bought the full-blown configuration with two discs and 64K of internal memory. We've ordered, and soon expect to receive, a “Baby Blue” which will provide 64K of additional memory plus a Z-80 processor to allow the IBM to run CP/M, and a Quadram board which will give us a serial port, time of day clock, and 64K–196K of additional memory (we're ordering 64K, and will add the chips ourself to expand it to the maximum). We've received the IBM Macro Assembler, which we will be able to run as soon as we get the requisite 96K (!) installed in the machine. We've also obtained an 8087 chip which we'll install in the machine to give it hardware floating point capability. This will both let us certify our software floating point package and let us offer the hardware floating point as an option in all the software we develop. (This will make MicroCAD immensely faster.)
At the moment the IBM is at Greg Lutz's house in the east bay, where Greg and Keith Marcelius are gaining familiarity with the machine. We have two copies of the technical manual for the machine, which we will circulate to those interested in it.
At the moment we're mostly playing with the machine and trying to figure out the assembly language. The machine's major immediate application will be to support the conversion of MicroCAD and QBASIC.
Because we're faced with so many different types of disc formats,
we've decided to implement a universal file transfer protocol which
allows us to get both text and binary files from any machine to any
other given only a serial communication port. John Walker designed
the protocol and implemented a 9900 driver for it.
Greg Lutz reviewed the protocol,
fixed some flaws in it, and is now developing an IBM PC version of the
program. Once that's done, we'll test the 9900/IBM link, at which
time we'll be able to trust the protocol. Then we'll be able to
implement it on every machine we encounter. The protocol is provably
proof against data loss, duplication, and garbling, and has sufficient
redundancy that it can be used on international phone lines. It's
simple enough to implement in BASIC on any machine that lets BASIC
drive the serial port. There are no time-critical operations that
would cause trouble in a BASIC implementation.
After the 9900/IBM test, Dan Drake will put the protocol on the
Apple, using Jack Stuppin's machine, and we'll have the
long-awaited way to get software over to the Apple to use with the
CP/M Softcard. After this is done, we'll be able to move among
the 9900, CP/M, IBM PCDOS, and Apple freely.
Obviously we don't want to get wiped out if somebody's house burns down. If you're developing some huge chunk of software, be sure to keep backups somewhere else. To aid this, I've set up the following scheme. Anybody who wants to back up something can simply write a disc with the name of the thing on it and the date, plus who sent it, and send it to me. I'll just keep the discs here in a special box for AI. When the box gets too full, I'll get in touch with you and see about scratching old backups for which I've received more recent copies. I'll recycle the old backups back as blank discs the next time somebody needs them.
There's no need to keep these backups very current. It's just good to know that we can't lose everything if a disaster happens.
We're now stocking 8 inch double density single sided discs and 5 1/4 inch double density single sided discs here. If you need discs for AI work, let me know and they'll be sent out UPS. We get 8" discs for $3.20 each and 5 1/4" discs at $2.63. If you can beat that, let me know.
John Walker has been talking with a company who's developing a 68000
CAD system about getting a loaner system from them for converting
MicroCAD to the 68000 (which they would then license from
us).
If we can work such a deal,
we'd be able to get a 68000 development machine in house immediately
without having to spend any money. Since one of the major advantages
of the 68000 is the speed and large memory that suits it for graphics,
I suspect that there's more than one software-hungry vendor who might
be interested in loaning a system to get a package like MicroCAD
converted to it. If you see announcements of 68000 based systems that
look like good prospects (e.g., have 400×400 or better
graphics and cost less than $13,000 with discs included), pass on the
information and we'll contact them.
Jack Stuppin has set up a meeting between us and a company which has been developing electronic medical instruments and wants to expand into the medical office vertical market. We'll be talking with them about developing a patient records database system to run under CP/M which would optionally interface to data collected from instruments. At this point we have no details on what they want or how attractive a deal could be struck with them to do the work, so at this point this is nothing more than a lead. I'm mentioning it here because if there's somebody who has some experience in database system development or medical applications, they should be in on the meeting or at least brief somebody who's going to be there.
It's become clear that the plague called the 8086 architecture has sufficiently entrenched itself that it's not going to go away. For the last month or more, Mike Riddle, John Walker, Keith Marcelius, and Greg Lutz have been bashing their collective heads against it. The following is collected information on this unfortunate machine.
I think we'd be wise to diffuse our 8086 knowledge among as many people as possible. The main reference for the 8086 is a book called, imaginatively enough, The 8086 Book published by Osborne. This is the architecture and instruction set reference, but does not give sufficient information to write assembly code (of which, more later). However, it is the starting point to understand the machine. AI will reimburse the cost of your buying this book, which is available at computer and electronic stores.
I have never encountered a machine so hard to understand, one where the most basic decisions in designing a program are made so unnecessarily difficult, where the memory architecture seems deliberately designed to obstruct the programmer, where the instruction set seems contrived to induce the maximum confusion, and where the assembler is so bizarre and baroque that once you've decided what bits you want in memory you can't figure out how to get the assembler to put them there. But I digress.
Mike Riddle has come up with the following programming rules for the 8086. They are presented here for comments from people with 8086 experience.
With regard to other 8086 developments, Hal Royaltey is writing a floating point package for the beast. The floating point package will be compatible with the IEEE double precision format used by the 8087. We'll set things up so that a program can be easily (maybe automatically?) configured for hardware or software floating point. This floating point package will be used for both SPL and QBASIC programs.
John Walker has a version of QBASIC that generates 8086 assembly code. The compiler still runs on the 9900, where it will stay until META is running on the 8086. Soon we'll be loading the code onto the IBM to make sure it assembles properly, and to check out the segmentation structure of the code/library interface. Assuming that works, it's full steam ahead with QBASIC on the 8086. John Walker will be completing the compiler conversion and basic library routines, Dan Drake will be converting the I/O library, and we'll be integrating Hal Royaltey's floating point package and Mike Riddle's format independent math routines.
We'll be completing the META port on the IBM here, freeing Mike Riddle's time to concentrate on the SPL compiler and runtime library.
In developing both SPL and QBASIC, we're taking the following approach to the 8086. We want to treat the thing as if it had true large memory, even though it's deliberately set up to obstruct us in doing that. We're imposing only the constraint that the static code generated by any one compilation cannot exceed 64K (which would be an unwieldy source program anyway). Dynamically allocated strings and arrays may be anywhere in the 1MB addressing space, and linked lists will use a general segment/offset 32 bit address for pointers. Any number of modules of up to 64K each may be linked together, and runtime library size will not subtract from the maximum program size. Thus, our compilers and their generated code will be limited only by the physical memory constraints of the machine and the operating system we're running under. This is a very important competitive edge: remember that most 8086 code is translated 8080 code, and such converted code cannot easily exceed 128K (or 64K if it's messy). Our programs will have no such limit.
It's planned that an “engineering test version” of QBASIC will be running in about a week on the IBM to verify the basic memory architecture ideas that go into the above (such a test is required because the IBM assembler and linker are so confusing that whether some ideas will work cannot be determined from the manuals).
We also lack documentation of the Microsoft/IBM relocatable code format used on the 8086, although Mike Riddle suspects it's an extended version of the bitstream code used by Microsoft Fortran on the 8080 and adopted by Digital Research. Even if it is, we still don't know how the additional information for the 8086 was encoded. Does anybody know this, or have any leads to find out? We need to know to make our compilers salable, as we can't expect people to buy the IBM Macro Assembler just to assemble the code from QBASIC. I can think of lots of things I'd rather do than reverse-engineer somebody's bitstream relocatable format.
As most of you know, Marinchip has been negotiating with Lifeboat for
many months about selling MSL's 9900 software to Pertec for use on a
9900-based machine they make called the PC1000. This deal has been
off and on so many times I can't even begin to recount the story. Now
Pertec has officially announced the machine, including the “SB-99 CP/M
Compatible Operating System from Lifeboat Associates”. This is
presumably Marinchip's software (unless we've been spectacularly
double crossed). Nonetheless, there's no signed agreement between
anybody to do the work, nor have we heard anything about this other
than what we read in InfoWorld.
The reason I'm
bringing this up is that if this does go through, I (John Walker) will
probably disappear for a month or so into doing this conversion
project for Pertec, and Dan Drake will probably be sucked in to some
extent. This means that we want to get as many AI things running
smoothly without our involvement as we can in case this happens. As a
result, if there's something I should be doing or which you need me to
do, please let me know as soon as possible so I can schedule it around
this potential time sponge.
Remember that the first regular monthly meeting will be on Sunday, June 6, 1982 at Jack Stuppin's house in San Francisco. We haven't decided whether to go ahead with the Subchapter S election mentioned in the last Information Letter or not, but as the form requires lots of signatures, we're going to get them so we have them if we decide to do it. We should have the form at the meeting. If you can't make it, I'll see that the form is routed to you after the meeting.
Kern Sibbald has been restructuring Autodesk from the hacked-up demo version of the program written for the Computer Faire into an honest program which will run on CP/M. In the process, he had to invert the internal structure of the program because the original program heavily used recursive function calls, which aren't supported by CB80. He also installed the new general terminal driver from the CP/M Window, which allows adaptation to new terminal types simply by making entries in a file. We expect the basic system to be running on CP/M under CB80 within 30 days. At that point we can start to add the features we need to complete the system for sale.
Kern Sibbald's CB80 version of Duff Kurland's TS program has been
turned over to Peter Goldmann, who has successfully generated it
and is now reviewing other communicator programs to choose ideas
for extending the package. We will be adding autodialing, a
database of systems with automatic configuration for various
protocols, micro to micro file transfer, and many other features
to make it the premier microcomputer communication
utility.
It
will eventually be integrated with Autodesk to add an electronic
mail facility to Autodesk.
Does anybody know about WordStar? We need to figure out how the files work so we can fix DIFF to make change bars for WordStar files. Also, we should look at the product in general to see if we should use its conventions for control keys.
We're moving along with preparing professional looking
documentation. At first, we'll be using WORD on the 9900 as our
documentation tool, because we have it, we control it, and we can
make it do the things we need done. We'll be installing an INDEX
command and writing an INDEX postprocessor so all our manuals can
be indexed. We'll install the commands we need to generate the
control sequences for font selection, point size, underlining,
etc., in the final output medium we use. We'll add Knuth's
hyphenation algorithm from
,
with an override ability when you
see that it's botched one.
Richard Handyside told us about an outfit called “TypeShare” in Los Angeles which you dial up with your modem, send text with control information, and get back camera ready type. I called them up to get information, but haven't received anything yet. I hope the typesetting is faster. Other potential leads on services like this would be appreciated.
We're checking out the option of making the manuals for our stable
products into hardbound books.
What else conveys a comparable feeling of stability
and solidity? From our initial checking, it's also cheaper than the
little looseleaf binders IBM uses for the manuals for the PC. Keith
Marcelius is running down this option.
We've found a distributor who seems to think we're a computer store and who will sell us most mass market CP/M and IBM PC software at pretty good prices. Check first if you need something, as we should be able to get a good discount on it. We haven't ordered anything yet, so this isn't a sure thing.
Dan Drake is currently reading up on the
Apple. At the moment this is pure research, but as there are so many
Apples out there, some way to get things like Autodesk on the Apple
might make sense
sooner or later.
We're having stationery printed up. I'll be distributing it to people after it arrives, so they can use it for requesting information, etc. At the moment, the official phone number for AI is 383-2997, but don't use it to call me, as I'm always on the other phone and get very mad when 2997 rings.
Immediately before COMDEX in 1982, Sun-Flex asked us to make a demo of house placement on a subdivision plan map. Roxie and I made this drawing one horrible night in November 1982. It was while making this drawing on AutoCAD-80 that I first really became aware that much more powerful geometric facilities were needed for professional drawing. If you really want to get a flavour of 1982 AutoCAD, try making this drawing without ever using object snap, arcs other than three-point, fillet, trim, or extend.
|
|