Electric Malcolm

Whenever an Autodesk old-timer wants to intimidate a Kelvin-come-lately, the conversation always seems to turn to “Electric Malcolm”. After a few veiled references to this legendary facility, the newcomer walks away slowly, shaking his head, and muttering something about “they told me this company was weird, but ‘Electric Malcolm’? …naaah.”. Well I promised to tell all, so here's the inside scoop on Electric Malcolm.

Malcolm McCullough was still studying architecture at UCLA when he took a summer job with Autodesk in 1983. Malcolm was the first person really talented in drawing to work for Autodesk, and his work with AutoCAD helped both by generating good sample drawings and by identifying the most important features needed in real professional drafting. The Golden Gate Bridge drawing that we used to feature so prominently in our advertising was drawn by Malcolm that summer.

We had hoped that Malcolm would be able to help us put together some form of scripted or video demo. When time began to run out, I implemented a transcript capture facility which would actually be able to record Malcolm creating a drawing. Then we could play it back at a trade show or in a dealer's showroom and show AutoCAD making a drawing in the hands of a master with the simple push of a button. Hence, “Electric Malcolm”. The code was implemented in the CP/M-86 version of AutoCAD, but there was a stability freeze in effect prior to the release of Version 1.4, so the code was never integrated in the product. To this day, AutoCAD lacks this capability, although both AutoSketch and AutoShade support it for development testing purposes.

The attached disc contains the additions to AutoCAD to provide a crude transcript capture and replay facility. This code is provided for internal use only, and has several glaring shortcuts and deficiencies which are excusable only by the short time remaining before it must be pressed into service to prepare demos for NSS and COMDEX, and the short time before our best AutoCAD expert departs for southern climes.

I have tried to implement this code in an extensible way, and will later suggest how existing transcripts prepared with this code may be painlessly converted into a more advanced version compatible with the 1.40 DIG changes and future plans.

First, let's look at how the mechanism works.

To make a transcript, at any time while AutoCAD is active, you may enter the command:

XSCR

You will be prompted with:

Transcript file:

and you should respond with a valid file name in the system you are running under. This file name may contain a drive letter, but must not contain a file type. A file type of “XSC” will be used for all transcripts. If a file with the given name already exists, it will be overwritten. Following the completion of the XSCR command, you will receive the “Command:” prompt, and henceforth every AutoCAD action you take will be recorded in the transcript file. That is, every keystroke on the console, every pick with the pointing device (whether in screen or tablet mode), and every menu pick, whether from the tablet menu or the screen.

To terminate the recording of the transcript, just enter the command:

XSCR

again. This will close the transcript file and turn off recording. The transcript file will also be automatically closed out when a command is entered which leaves the Drawing Editor (END or QUIT). But remember, if you use an END or QUIT in a transcript, it will be recorded and will take effect when the transcript is later used, so be sure this is what you wish.

Once a transcript file has been recorded with the XSCR command, it may be replayed at any time with the command:

RPLY

This command will prompt you:

Transcript file:

and you should respond with the file name of a previously recorded transcript. As with the XSCR command, the file type of “XSC” is assumed and should not be specified. The transcript will then be fed to AutoCAD as it was initially entered. If the transcript was terminated with an XSCR command, that command will display at the end, but will be ignored. If the transcript does not terminate the Drawing Editor, control will return to the console at the end of the transcript. Transcripts may not be aborted. (This isn't hard to fix.) Transcripts have meaning only within the Drawing Editor. Unlike SCRIPT files, they cannot be used to feed commands to the main menu, configurator, or plot modules. Note that you are free, however, to make composite demos with scripts which use the RPLY command after calling the Drawing Editor.

In using transcripts to prepare demos, it is of the utmost importance that you remember to save the precise initial environment which obtained when the transcript was captured. That includes the original drawing file (beware of making any changes, even of view, before starting the transcript), the menu file(s) in effect, all LOAD and INSERT files, and the same display hardware (since digitiser samples are converted into screen coordinates). A transcript is simply a logical baboon typing from a list of characters and moving the cursor to where it was on the screen before—if you change the environment, the baboon will just keep on typing with nary a giggle at the devastation which ensues.

Consequently, the wise transcript maker saves the entire disc set before the transcript capture, then makes the transcript, then sets up a demo script incorporating the backup disc set and makes sure the demo process isn't destructive of the initial information on the disc.

There is no way to edit or concatenate transcript files. Zip. Nor is there any reasonable way to convert a transcript from one machine to run on another, or to update it for a new version of AutoCAD. However, this is not as bad as you might think. We are making changes in the interface between DIG and the people who call it which will rationalise the way tablet mode and handling of screen pointing work. These changes will have a major impact on transcript capture, and will allow us to much more easily turn a transcript into a SCRIPT file which can be edited with a text editor. This is really what we want, so it doesn't make sense to make a large investment in a 1.30 base transcript mechanism now. But based on timing, we gotta have something now, so this is it. When we get the new interface, I can gimmick DIG to read one of these old transcripts while writing a new style one, and then everything gets automatically converted (I hope).

The transcript code itself is very obvious. COMMAND is modified to recognise the XSCR and RPLY commands (which have clunky names because we have no intention of making this facility available to users), and to add the code which closes an open transcript on an QUIT or END. All transcript code in both COMMAND and DIG can be turned off by undefining TRANSCR, which is how we will normally ship AutoCAD.

The code to process the XSCR and RPLY commands is in the procedures with the same names in DIG. Note that the transcript file is paged; we wish no more disc I/O than necessary, because we may fill a buffer during user keyboard input. Both the capture and replay code is added to the procedure DIGITZ, and is obvious. The format of the transcript file is:

    00-7F                 Console character
    F0 SX SX SY SY        Digitiser pick
    F1 SX SX              Menu pick
    F2 RX RX RY RY        Raw digitiser coordinates  (tablet mode)
    FF                    End of file

Any questions this doesn't answer are as easily answered from the code as from a document about it. The raw X and Y coordinates are written first so that RAWX and RAWY are correct when the pick item follows. It is always generated regardless of tablet mode.

Writing of the transcript file doesn't adjust the disc full counter. That's because I'm too lazy to bother with it for internal code I'm going to rewrite anyway.

Freehand sketch material doesn't get captured in the transcript. This isn't particularly hard, but I skipped it because of lack of immediate need and to prevent code integration conflicts (as changes in SKETCH would be needed, and SKETCH in currently under integration into 1.40).

The management of the cursor in the replay code is no great shakes. It should really glide the cursor over to the point smoothly to simulate user movement. This would make the replay much better. We'll also have to put in DELAYs at strategic places after we get the translator to SCRIPT format working. All menu picks are turned into screen menu picks, with cycling through the NEXT box as required. Until we get the robot arm for the digitiser (or mouse with legs), this is the best way we can represent menu usage.

Anyway, the plan is that we retrojam this thing into 1.30 for the Victor and let Malcolm loose on it for the time we have left, then massage the material we collect in the free time after he goes. I'm sure we can come up with a better mechanism in the future, but this one works and we can use it in the remaining time.

Here's the drawing of the Golden Gate Bridge that Malcolm McCullough did in the summer of 1983. His drawing shows the entire bridge and includes structural details beneath the panels. This view of part of the drawing is the one we featured most frequently in brochures. It's hard to appreciate what an achievement this drawing is without having used the primitive version of AutoCAD with which Malcolm drew it.