Published Monthly by Raised Dot Computing, Inc., 408 South Baldwin Street, Madison WI 53703. General phone: 608-257-9595. Technical Hotline: 608-257-8833.
Subscriptions: $18/year Print, $20/year Audio Tape, $30/year Disk. (Kindly add $20/year for postage outside N. America.)
Submissions are always welcome, especially on diskette. All are subject to editing for style and clarity. All opinions expressed are those of the author. Editor: Jesse Kaysen
Copyright 1986 by Raised Dot Computing, Inc., All Rights Reserved
Table of Contents: the all-uppercase words name the disk chapters; the words after the equals sign are the actual article titles.
December 1986 was a very hectic month--by the time we shut down the office on Christmas Eve, all of us needed a vacation. Perhaps it was the high sugar intake that inevitably accompanies the holiday season. Or maybe it was because, in trying to beat a printer's deadline, I didn't record the audio version until after the print edition was out of my hands. At any rate, there were a record number of errors in the December Newsletter. This gives me a wonderful opportunity to start my New Year right.
In the "VersaPoint Enhancements" article, the second sentence under "Other Features" did not make a whole lot of sense. The point I hoped to make was: being able to clear a 30,000 character buffer at the press of a button provides you with more flexibility.
A more serious error occurs in the TEXTALKER article, where it states that the American Printing House for the Blind's documentation for TEXTALKER 3.1.2 is supplied on the BEX 2.2 Update Disk. That was true when it was printed, but it is no longer the case. We misunderstood the distribution policies for APH-copyrighted material. At their request, we have removed the APH documentation from the Update Disk. The BEX 2.2. Update Disk now contains the new TEXTALKER 3.1.2 software, and RDC-produced documentation focusing on the improvements found in the new version of TEXTALKER. You may obtain the complete TEXTALKER 3.1.2 documentation and both DOS 3.3 and ProDOS versions of the TEXTALKER program, directly from APH. Its catalog number is D-89570; and it only costs $15.50.
American Printing House for the Blind
1829 Frankfort Avenue
Louisville KY 40206
502-895-2405
In the Slot-Buster II article, I misidentified that useful device's creator. His name was and is Randy Carlstrom.
Under "Announcements" I published a notice about the Three-Track Conference sponsored by the Greater Detroit Society for the Blind. A missing hyphen from the date caused massive confusion: that conference will be held on April 2nd through April 4th. For more information, contact:
Bernard J Pumo
Greater Detroit Society for the Blind
16625 Grand River
Detroit MI 48227
313-272-3900
Finally, the Announcement urging you to pay for your Diversi-COPY used an outdated address. To obtain peace of mind, technical support, and the latest version of Diversi-COPY, send your $30 to:
DSR, Inc.
34880 Bunker Hill
Farmington, MI 48018-2728
You're all familiar with the "Quick" and "Thick" BEX Reference Cards. The following four items could be the start of a monthly column: the "Trick Reference Card." Contributions are always welcome! All comments reflect the capabilities of BEX Version 2.2.
I frequently use BEX to produce forms. In this context, I often need to know the length of a particular group of characters. I use the Clipboard as a counting tool. I position the cursor at the beginning of my text, set the marker with control-B S, then advance to the end of my text and copy it to the Clipboard with control-B C. When I enter control-W B BEX tells me exactly how many characters there are! When I press spacebar, I'm back in the Editor.
When you have left BEX with control-Reset and used PR#0 to restore Echo speech, nothing goes to the screen. To restore screen output, for seeing and for line review, give the Echo command control-E B (both voice and screen). Here's why: BEX handles output to the screen itself. To avoid double display, it puts the Echo in "talk only" mode. When you use control-Reset, BEX is no longer sending output to the screen. You don't have to put the Echo back into "talk only" mode before returning to BEX; BEX does that automatically.
After you control-Reset out of the Editor, your Echo may seem to have had a nervous breakdown. For example, the menu choices may scroll endlessly, and you can't use line review. This is because BEX disables control-X and control-L when you're in the Editor. BEX restores these important Echo commands when you Quit the Editor with control-Q. But when you crash out of the Editor, they're still disabled. The solution is to Edit any chapter and then Quit with control-Q.
Sighted users can feel disoriented when entering data in BEX's Editor. That's because BEX fills each screen line, so words are sometimes broken between lines. At the User or Master Level, you can preview your text inside the Editor with control-V, the "View Mode" Editor command. When you press control-V, BEX prints the text of the current page to the 80-column screen. All format indicators and commands in the current page are executed, but beware when you've set up some long-term format commands at the very beginning of your chapter. For example, you enter $$ss on BEX page 1, and use control-V on BEX page 4. Your sticky spaces and touching tokens won't show up unless you enter $$ss again on that page. (Of course, you can just clipboard the commands into page 4 temporarily.)
The default page format for control-V is a print device 80 characters wide by 24 lines deep; you can easily override this with $$w# and $$f# commands entered on the same BEX page. Page breaks are shown by a line of slashes. When your text is printed to the 80-column screen, it scrolls pretty fast; use control-S to pause and restart the display. Once the text is completely printed, pressing any key (including control-S) returns you to the "normal" Editor. Your cursor position is not affected by control-V, but the block marker is cleared.
We occasionally hear the complaint, "When I want to use a different chapter in the Page Menu, I have to leave the Page Menu and re-enter it." Well actually, Option C - Change Chapters is designed for just this purpose. When you supply a chapter name, it becomes the current chapter. When you respond with just a <CR>, you clear the current chapter. It's as if you had just entered the Page Menu. This lets you create a new chapter with Grab pages without having to leave the Page Menu and come back again.
When you have an IBM-PC and an Apple in the same office, it's relatively simple to transfer files from Big Blue to Little Beige. Once the two machines are cabled together, you print from the IBM and use BEX's Input through Slot to save the information on disk. (This procedure only works with BEX version 2.2, which supports hardware handshaking for Input through Slot.) This article discusses two ways to print on the IBM: directly from the DOS command line, and using Hot Dots, the two-way braille translator and file manipulation utility.
Before any transfers can begin you must have the right cable. To connect the IBM serial port to an Apple Super Serial Card, I use a straight-through female cable with wires 4 and 20 shorted together (that's RDC's 9F cable). When you are using an Apple 2c, you need a straight-through cable female on one end with wires 4 and 20 shorted together (RDC sells this as a 10F cable). Cable the two computers together before you set the communication parameters.
Let's get the PC ready first. I boot DOS 3.1 on the IBM. After the Disk Operating System has been loaded, I need to instruct the PC concerning the baud rate, data bits, stop bits and parity of my printing device (which is actually my Apple 2e.) This is what I type at the A> prompt to set these parameters:
If you're using COM1 for your voice device, you can substitute COM2 in the commands above. Now the IBM is ready to transfer data.
On the Apple end, I assume that you have a Super Serial Card set to the "standard settings"--9600 baud, no parity, 8 data bits, 1 stop bit. Establish a User or Master Level BEX configuration that includes a "device to download text." Answer No to the question: "Is this a KRM?" If your Super Serial Card does not use the standard settings, you should include an automatic set-up sequence to your download device SSC to create these parameters. (Section 6 of the BEX Interface Guide lists the command sequences for the Apple 2c port. When the Super Serial Card's switches 1-5 and 1-6 are on, you control it with the Apple 2c port commands. When switch 1-5 or switch 1-6 is off, substitute control-I for control-A.) Boot BEX, provide a configuration name that includes a download device, and move to the Second Menu. Press I to choose Input through Slot. BEX prompts for a target chapter name; once you supply one and press <CR>, BEX prompts "Start device." BEX patiently waits for around two minutes for data to start coming.
DOS's built-in print command allows you to set up a list or "queue" of files to be printed. You can send as few as one, or as many as the number of files you have on your disk. The general formula is:
print <space> /p <space> disk drive:filename(s) <CR>
The "slash p" turns on printing. Here's how it would look with one file named "RECIPES.KG".
print /p b:recipes.kg <CR>
When you wish to print more than one file, you would type the following:
print /p b:recipes.kg b:hello.txt a:letter.fr
<CR>
To get an entire printout of all the files on the disk, type:
print /p b:*.* <CR>
After your files have been queued, you are ready to begin printing. The first time you print from DOS after turning on the computer, you must define the printing device. Therefore, the following message is displayed:
NAME OF LIST DEVICE PRN =:
If you press <CR> at this point, PRN becomes the printing device. However, at this point you can designate any of the following as the printing device: COM1, COM2, COM3, LPT1, LPT2, LPT3, AUX, etc. For our purpose of transferring files from the PC to the Apple, you need to type in the number of the communication port you have established parameters for. On my system I type:
com1: <CR>
After pressing <CR>, you are told which file is being printed, and (since you've entered all the filenames correctly) you are told that they are queued for printing. Now the data is actually being transferred. You should hear a steady buzzing noise from the Apple as the characters are received. When the IBM is finished sending, press Q on the Apple keyboard to close the chapter.
Once you've loaded Hot Dots into the IBM, sending text to the Apple is a snap. Get the Apple ready by choosing Input through Slot and providing a target chapter name. At the Main Menu of Hot Dots press number 5 to go to the Printer Menu. The Printer Menu contains drivers for 7 different printers. The Thiel, number 5, is a "vanilla" driver: it doesn't do anything special to the text. Once the driver has been loaded, the program asks me for an input file name. I have my data disk in drive B, Therefore, I type:
B:RECIPES.KG <CR>
The program looks for this file on drive B. When it finds the file, I'm told to hit any key to start printout. I press any key on the IBM, and what should my anxious ears hear but a humming sound that indicates data is being transferred. When all is quiet, press Q on the Apple keyboard.
Although I now have the text in a BEX chapter, my work is not quite finished. The text from the IBM contains control characters I don't need. When the IBM prints, it usually puts a <CR> and a linefeed (control-J) at the end of each line. The transformation chapter TXP on the BEXtras disk strips out linefeeds and changes <CR>s to paragraph ($p) indicators. So the first step is to use TXP as my transformation chapter with the newly received data.
There still may be other control characters in my file. One common character which needs removing is the break character. There may also be control characters created when Input through Slot strips off the high bit. (See "The High-Bit Mystery" in the article on Macintosh file transfers in this issue for more details about high bit set characters.) Fortunately, Contextual Replace lets me write one rule to get rid of any control characters in the text.
Here's how I wrote that transformation chapter the first time I needed it. The BEX chapter I'd created was named "RECIPES". At the Main menu, I chose Replace characters, with RECIPES as both the source and target chapter. When BEX prompted: "Enter terminator", I entered a comma. When BEX prompted "Find:", I entered comma again, and I was in Contextual replace. I didn't want to use an "on string" or an "off string", so I responded with comma to the next two prompts.
The next prompt was "Find:". I entered a control-N by holding down the control key, then pressing the letter N. Then I pressed comma to finish the Find string. When BEX prompted "Pattern:" I entered lowercase c followed by comma. This pattern code means: "Look for any control character; when you find it, replace it with the Change to string." When BEX prompted for the Change to string, I entered comma alone. Since there's nothing in the Change to string, Replace characters just deletes any control characters in the text.
That's the only rule I wanted to write, so I entered my terminator to the next three prompts, then pressed <CR> at the Continue? Y prompt. Once BEX had Replaced all the control characters with nothing, I saved this transformation chapter as CTRLKILL.
Transferring data from the PC to the Apple is easy and a lot of fun. No longer will you be denied access to material entered via a word-processing program for the IBM. It's a matter of setting up the two computers, getting the right cables, and having BEX version 2.2.
My first computer was a Radio Shack Model 100 (Laptop). With it, I learned many of the basics of the BASIC program language. I soon learned that a quick way to correct errors in program lines was to use its built-in "EDIT" command. Like a flash, the lines I wanted to correct were on the screen, and the cursor was waiting in the top left corner. It was as easy to correct program lines as it was to fix spelling mistakes in the word processor.
What a shock when I started programing with the Apple. "What! No EDIT command? How could the Apple be so antiquated?" I spent many hours retyping program lines. I had heard that there was a built-in editor, but that it didn't work very well.
I finally found a good explanation of the Apple's editor in an Apple programmer's manual. Even then, it still didn't look very promising for my Echo Plus and me. Then, I remembered "Exit at X,Y", that little feature of Echo line review that I hadn't yet found much use for. Suddenly, the lines on the screen were no longer just lifeless reminders of what had already happened. During the programming process, a screen full of data could even be more valuable than hard-copy.
Although the built-in editor is not nearly as nice as your favorite (or maybe even your least favorite) word processor, it is still a giant step beyond retyping many lines or filenames over and over. The Applesoft editor lets you insert and copy characters that are already on the screen. It's very handy for writing programs, of course; it's also useful when running, renaming, and deleting files. In some ways, using the Apple editor with TEXTALKER and its line review function is easier than using the Applesoft editor alone.
The Apple must know whether you are typing characters it should pay attention to or just trying to move the cursor. The sighted person uses the Escape key to enter "Escape mode": this tells the Apple that the following keystrokes are purely cursor moves and not part of a command. Another press of the Escape key exits Escape mode, and tells the Apple they're finished moving the cursor. After leaving Escape mode, when the right arrow key is pressed, the Apple "picks up" or copies the character under the cursor as part of the command.
The Echo does not speak in Escape mode, but that's not a problem. Sighted people use the Escape mode to position the cursor back at the line they wish to edit. You can use the Echo's line review for the same purpose; when you find the line you wish to edit, simply press X to exit line review and move the real cursor to the audio cursor.
Now you can use the right and left arrow keys to modify the text on the screen. When the punctuation mode of the Echo is set correctly, you hear a character pronounced each time you press the right arrow. The right arrow becomes the "retype key"; when the Echo speaks a character, it is just as if you had typed that character yourself. If you copy wrong characters, or copy more than you intend, use the left arrow key to back up and erase characters. Where on the line you press <CR> determines how many characters the Apple gets. You can change characters in a line by using the right arrow to copy the line up to the character you wish to change, then type the character you want instead of pressing the right arrow, then use the right arrow again to copy the rest of the line, then press <CR>.
Here's a quick sample of using the Applesoft editor. You want to delete some files from a disk. Do a CATALOG, then enter line review. Press Z followed by R to read the line where the real cursor is positioned; you'll hear "Ready." Up arrow until you hear the filename you wish to delete, on for example, line M. On that line, left arrow until you hear the boop signalling the left boundary of the line. Press X, and you hear, "Exit at M, 00." Your cursor is in the perfect position: type "DELETE", then right arrow over all the letters in the filename and press <CR>. (It's no coincidence that all DOS commands are 6 letters or less--there's always room to sneak in a DOS command in positions 0 through 7 on the line.)
When you enter changes from the keyboard, remember that each time you press the right arrow or type a character, the cursor moves one character to the right. This means that every additional character you enter makes you lose characters to the right of the cursor.
You must combine "pure" cursor moves with right arrow tracing when you want to insert text. Use the procedure just outlined to get your cursor at the point where inserted text begins. Press Escape to enter Escape mode, which signals the Apple that you're beginning "pure" cursor movement. Move the cursor up or down one line from the line you are copying, and press Escape again to exit Escape mode. Now, type the characters you want to insert--but don't press <CR>! Use Echo line review to put your cursor back where it was when you entered Escape mode. Now you can right arrow over the text you want to copy, and press <CR>.
If you are half way through a line and decide to start over, do not press <CR>. Instead, press Control-X to cancel the line without making changes in memory. When you review this line, you hear a backslash at the point in the line where you pressed Control-X. You may need to list the old line again to get a fresh copy on the screen.
Especially when working in 40-column screen, a single program line may occupy several lines on the screen. When you reach the end of the first screen line, you can use line review to reposition yourself at the beginning of the next screen line. Alternately, you can continue pressing the right arrow key until the cursor reaches the beginning of the next line. When you do this, you are copying the spaces at the end of one line and the beginning of the next. The Apple is not too picky about spaces in program lines, except when they occur between quotation marks. When there are quotation marks in the line you are editing, make sure that you do not copy extra spaces inside them.
You can copy portions of several program lines to form a completely new line. First, list all the lines you want to use. Make sure that they will all fit on the screen. When you want to start a new line, type the line number. Then, without pressing <CR>, use Echo line review to find the first characters you want to include. Press "X" to exit line review just ahead of these characters, then use the right arrow key to copy them. Make sure the Echo speaks all the characters you want to copy--if the Echo doesn't say it, then it hasn't been copied!
When you have copied all the characters from one line, don't press <CR>. Instead, use line review to find and move to the next line of characters you wish to use. Copy the characters in the new line as just described. You can change characters by typing them as you go. Continue this until you have either typed or copied all the characters you need for a complete line, then press <CR>. The Echo should say "READY". You can now list the line to make sure you have typed and copied the right characters.
The Apple's built-in editor, although not as nice as a word processor, is still a good and reliable tool for issuing DOS commands and modifying program lines. It will save you some typing, reading, and wondering just how something was spelled.
It should come as no surprise to regular readers of the Newsletter that I enjoy playing with my Macintosh. This article is based on my daily experience of transferring files between the two machines.
On the Apple, you use two BEX options: P - Print to send data to the Mac, and I - Input through slot to receive data from the Mac. On the Macintosh, you need to have a terminal or communications program. A variety are available, but many limit the rate of data transfer to 2400 baud. I've had great success with Red Ryder transferring info at 9600 baud. Red Ryder is a "shareware" program that you're encouraged to distribute for evaluation. If you like it, you send $40 to its author. Red Ryder is readily available--if you can't find it at your local users group or bulletin board, send me a Macintosh disk and I'll send you a copy.
Tool list:
Step 1: Power off the Apple, grab your Super Serial Card, and set the switches like this:
Step 2: Carefully remove the "jumper block" and reverse it so that the white triangle points to the word "MODEM". This allows you to use the ImageWriter cable. The positions of the jumper block and switches 2-1 and 2-5 are opposite from RDC's "Standard Settings."
More Details for Tech-heads: You've set the SSC for 9600 Baud, 8 data bits, 1 stop bit, No parity; don't delay after <CR>; don't add a line feed after <CR>. Even though you've flipped the jumper block to "Modem", the SSC is still addressed in "Printer Mode"--the command character is still control-I. (The command character only changes to control-A when you set switches 1-5 and 1-6 to ON.) You switch the jumper block to swap signal and ground on wires 2 and 3--and this makes the ImageWriter cable work.
Step 3: Establish a new configuration at the User or Master level. Answer Y to the question: Do you have a device to download text? Give the slot of this "non-standard" Super Serial Card. Answer N to the KRM question. Answer Y to the question: Do you want an automatic set-up sequence? Enter 5 keystrokes:
control-I X <spacebar> E <Delete key>.
"Control-I X <spacebar> E" enables X-on/X-off (software) handshaking in the Super Serial Card.
Configure one printer to send data to the Mac. The slot number is the same as the download device slot; the printer type is a Thiel brailler, class B, number 5. (This automatically filters out underlining.) Set the carriage width to 80 and the form length to zero; you want neither Pause on form feed nor Auto line feed. For this printer enter the same automatic set-up sequence as with the download device: control-I X <spacebar> E <Delete key>.
Step 4: On the Mac, set your terminal program for: 9600 baud, 8 data bits, 1 stop bit; No parity; Full echo. Plug the ImageWriter to Mac cable into either the "printer" or "modem" port on the Mac, and tell your terminal program which port you're using.
Now you're ready to transfer data. Before you do, however, there are some format issues to consider.
When the serial card, cable, and software on both machines match, actually transferring data is a snap. The tricky part is formatting the text appropriately.
I don't claim to know the ins and outs of every Mac word processor. It seems that all Mac word processors use <CR> to mark the end of paragraphs. No Mac software I've worked with is as flexible at manipulating data as BEX's Replace characters, so it's best to put my <CR>s (and tabs ... more on this later) exactly where I want them using BEX. Like BEX, MacWrite and Microsoft Word store text in unique binary file formats, and let you convert between the binary file format and the generic textfile. In the Mac world, this is called a "text-only file" or a "text document." When you send information from the Apple to the Mac, it arrives as a text document.
When you open a text document with MacWrite, it asks you: "Should a Carriage Return signify a new paragraph or a line break? You want to answer this question by clicking on "new paragraph." If you click on "line break," MacWrite turns every <CR> into a space. Your converted MacWrite document becomes one long paragraph, which you must manually reformat.
Microsoft Word Version 1.00 doesn't ask this type of question: it assumes that every <CR> marks the end of a paragraph. EDIT, MockWrite, miniWriter (and other desk accessory text editors) also treat the <CR> as the paragraph symbol.
With these facts in mind, I use various BEX format commands to make the chapter I print to the Mac easy to reformat once it arrives. One format command does most of the work: $$l0. This turns both soft <CR>s and new line ($l) indicators into spaces as BEX prints. (Hard <CR>s just transfer over the line as data.) When there's a section of text where you do want soft <CR>s and new line ($l) indicators to print, you have two choices. Either enter $$l1 at the beginning of that section and $$l0 at the end, or more simply, use Replace characters to change all <CR>s and new line ($l) indicators to paragraph indicators. Since the Mac printer is defined as a brailler, the paragraph indicators default to $$i2 $$s1. Enter $$i0 at the start of your BEX chapter, so you needn't delete the two extra spaces at the start of each paragraph once you're working in the Mac.
The way BEX underlines only creates a mess when it arrives in the Mac: the underlined word "today" becomes t, box, underbar, o, box, underbar, etc. That's why you configure your Mac printer as a brailler: All three underlining commands, (, $$h, and $$eu), are automatically suppressed.
Many BEX format commands--centering, top and left margins, and the horizontal positioning commands--create spaces as they're executed. That's fine when BEX talks directly to a printer, because most are "monospaced." The space character is just as a wide as any letter, so material formatted with spaces lines up nicely. Almost all Macintosh fonts, however, are proportionally spaced: the letter i is much narrower than the letter m, and the space character is a different width from many letters. All Mac word processors do a good job of formatting margins, tabs, etc., so you format the BEX chapter so as to give those responsibilities to the Mac.
It's easy to control tabs, once you know the trick. For the Mac (and almost all other computers) control-I means "do a tab." Since BEX lets you embed control characters in your text, you can place control-I where you wish the Mac to move to a tab. So what's the trick? The command character for the Super Serial Card is also control-I. If a single control-I appears in your text as it's moving through the SSC, the card tries to interpret the next character as a command. The SSC designers recognized that people might wish to transmit control-Is, though, so when the SSC gets two control-Is in a row, it sends out one. When you want to provide the Mac with tab information, use Replace characters to change every BEX tab indicator, (space, dollar, dollar, space), to two control-Is.
BEX's centering commands also generate spaces at the start of the line. You can delete all $$h and $$c commands so these spaces don't end up in the Mac. However, I've found that it's easier to leave them in. That way the headings stand out on the Mac's screen. I can scroll through the file and select the lines that start with a lot of spaces, tell the Mac to center the line, then simply delete the spaces.
To summarize, before printing a BEX chapter to the Mac, I do the following things: enter $$l0 $$i0 at the start of the chapter; change <CR> or ($l) to ($p); change ( $$) to two control-Is, and delete all margin and $$p commands. There's one last thing I do that I can't explain. I place two <CR>s at the absolute start of my BEX chapter--before the $$l0 command. If I omit this, Red Ryder doesn't receive any text until after the first paragraph indicator. I think these voodoo <CR>s get around a bug in Red Ryder: it doesn't "wake up" and start receiving until it gets one <CR>.
Your files must be text files when using the methods I've described here. Macintosh word processors divide into two categories: those that save information in unique binary files, and those that work directly with text files. All Mac word processors in the first group allow you to save your document as a text-only file. When you do this in MacWrite, you're asked: "Should a <CR> be placed at the end of each line or only between paragraphs?" You should click on "Paragraphs" to make your life easier. When you save a document as a text file, most format information is lost. You get no indication of font changes or underlining; running headers and footers disappear; there's no space at the start of indented paragraphs or centered headings.
About the only format information that does transfer are tabs. Each Mac tab becomes one control-I in your BEX chapter. Once the file arrives in BEX, you want to change every <CR> to a paragraph indicator and each control-I to a BEX tab command.
When you examine a BEX chapter you've received from the Mac, you may encounter some seemingly garbage control characters, as well as random punctuation or unexpected capital letters. (If all your text seems like garbage, then you have a baud rate problem in your transfer. I'm talking here about occasional strange characters.) These characters are the BEX result of Macintosh special characters--the ones you use the Mac's option key to create. Examples are accented letters and copyright or registered trademark symbols. In the Apple 2 environment, there are 128 possible characters (96 printable ones plus 32 control characters). In the Macintosh, there are 256 possible characters. These extra 128 characters are known as "high bit set" characters. The accented letters, bullets and symbols in the Mac are "high bit set" characters. BEX's Input through Slot strips off the high bit, so the characters seem like random garbage. When your Mac source file contains a lot of accented letters, you should globally change them before you send the file to the Apple.
Cable the two machines together: the smaller end of the ImageWriter to Mac cable goes in either the Mac's modem or printer port, and the larger end goes to the Apple 2e's Super Serial Card "tail." Get BEX running on the 2e and your terminal program running on the Mac. When you're sending information from the Apple to the Mac, get the Mac ready first. Tell the Mac terminal program to receive a file, using "Text Capture" or "ASCII capture" protocol. (On some terminal programs, this is accomplished by simply turning on the screen save function.) When the Mac's waiting for data, slide over to the Apple 2e and tell BEX to print. Specify the chapters you wish to transmit, choose the "brailler" that you've defined in your configuration, and sit back and relax. When the Apple is finished printing, tell your Macintosh terminal program to close the received file.
The Mac to BEX transfer is a mirror image of this process. Get the Apple ready first: choose option I - Input through slot, specify a chapter name, and BEX prompts, "start device." Slide over to the Mac, select a file to send using "Text send" or "ASCII send," and the Apple 2 starts clicking wildly. When the Apple stops clicking, enter a Q on its keyboard, and you're done.
[Aside to Microsoft Word Owners: This program comes with printer drivers for non-ImageWriter printers, including a "Typewriter" driver. You can print directly from Word to the Apple. Choose "Printer Setup" under the File menu. Choose the "Typewriter" printer; set the baud rate to 9600 and the port as appropriate. Changing to the Typewriter printer driver reformats your text on screen, which can be time-consuming. Once it's reformatted, get Input through Slot ready on the Apple, choose Print in Word, and you're on your way. Once the data's in the Apple, use TXP (on the BEXtras disk) to reformat the text.]
It was July of 1984; we had arrived in Madison, Wisconsin. The initial staff was myself, Caryn Navy, (whose husband I happen to be), and our friend, Jesse Kaysen. After unloading the U-Haul, the possessions of Raised Dot Computing comfortably filled half a room. There was an Apple 2 plus and a 2e, a well-worn letter quality printer, and a Thiel Braille embosser. An old kitchen table in an otherwise empty room served as our conference center. Oh, but we had great plans! Raised Dot Computing was incorporated under Wisconsin law; we retained an attorney and an accountant.
The building we purchased had been used as a union hall for decades. It seemed that not a single bingo card, "dues-paid" button, annual picnic photo, nor grievance had been thrown out: our first job was to cart all this stuff out to the curb. A few weeks later, a frantic union leader called to ask us if we had found his gun somewhere in the building--we hadn't.
Between then and now, Raised Dot Computing has grown from "David Holladay's pet project" to a real business. The building on Baldwin Street had 5 offices upstairs, a completely open ground floor, and a wet bar (complete with euchre tables) in the basement. We started out using only a small part of the upstairs. Now we're beginning to feel the building's limits: we recently carved out a 6th office downstairs.
By 1984, BRAILLE-EDIT had developed a good reputation. It was known as a good braille translator that was relatively easy to use. Many people thought it was a good way to introduce blind people to computer use. From 1981 to the move, I had sold a total of 450 BRAILLE-EDITs. In the next 12 months, we sold 450 more. The increasing volume of business demanded a more formal business structure.
All along, I had cadged business advice from my friend, Nevin Olson, a small-business-development consultant and industrial engineer. Jesse had always wanted to work in the same business as her husband, so Nevin bowed to the inevitable and joined the RDC team in December.
It was a wonderful team, but none of us were particularly good at typing invoices. We placed an ad for a "mail order fulfillment coordinator." Kristi Seifert, who'd spent many years as a systems analyst at a large hospital, wanted to meet the strange people who'd invented that job title. Whiskey (Caryn's guide dog) played an important part in the first round of job interviews, wandering in to check out each applicant. All four of us knew that Kristi was the one when Whiskey ambled in and curled up at her side. So Kristi became the first employee not related to another employee.
Up to this point, RDC's administrative functions had clearly been designed by a programmer. Cindy or I had coped as well as we could, but neither of us really had the time to develop a coherent system. Both Nevin and Kristi brought valuable experience gained working in large corporations: they stabilized the volatile RDC without killing its spirit. For the first time, every transaction--even Newsletter subscriptions--was invoiced. Kristi, Nevin, and Jesse attempted to organize the chaotic customer files. The "S"s were particularly unruly--there are almost 50 "State Commissions for the Blind." During my father's visit that fall, he helped out with many mundane tasks. His suggestion that we file material by ZIP code marked the turning point in our customer records.
When convention time loomed in June of 1985, we realized that we needed more help. Becky Rundall heard through a mutual friend that we had an opening, but no details about what the job involved. Fortunately for us, she braved our five-on-one interview. She impressed us with her positive attitude, her unwillingness to accept "imperious" supervision, and her ability to cope with stressful situations. One thing she could not cope with was our phone system, so we got a new phone system with real hold buttons.
Kristi and Becky insisted (and still insist) on keeping good records. These records allow us to understand and reconstruct each customer transaction. Since our customers are widely distributed over the country, ZIP codes are an ideal identifier. We have retrieved files fast enough that callers have praised the speed of our "computer system." The hardware for the system? Three four-drawer filing cabinets.
One way RDC copes with the large number of transactions is to handle them quickly and correctly the first time. (In the first seven days of 1987, for example, we processed 100 invoices.) Becky ships most orders within 24 hours of receipt. Even in unusual backlog situations (updates are the prime offender), orders never take more than a week to process.
Caryn started work at Raised Dot answering tech calls so I could spend more time programming. When she started, she had a $15 garage-sale desk, her own VersaBraille, and no computer. Caryn always insisted on completely tracing the bug or "feature" that caused problems. In the fall of 1984, she got many calls about braille page numbering problems. Thanks to her perseverance, she isolated a nasty bug in the Cranmer brailler. To get around this problem, we issued BRAILLE-EDIT version 2.50.
As Caryn gained more experience and became more involved in program design and coding, she needed freedom from constant phone duty. After a national search, we hired Phyllis Herrington in the Winter of 1985. Her teaching background helped our technical support become even more accessible. She also instituted the tech support log, which helps us develop a better understanding of what causes problems. Phyllis is also becoming involved in product design and evaluation, particularly for the IBM-PC. Phyllis, Caryn, and I now rotate answering the technical line. We've recently begun weekly technical meetings to evaluate new devices and to work out better procedures for dealing with technical questions.
We're always happy to answer questions, but we try to anticipate the most common ones in our manuals. I wrote the first RDC manuals--the BRAILLE-EDIT version 2.45 manual was written in one weekend. In the fall of 1984, Jesse revised the BRAILLE-EDIT manual. Jesse and Caryn also rewrote my early draft of the BETTE manual. In 1985, Jesse wrote from scratch the BRAILLE-EDIT User's Guide and most of the BEX Dox (Caryn and I wrote the Master Level and the Interface Guide).
While Jesse has great talents as a technical writer, it became clear that she couldn't write manuals and edit the Newsletter and produce RDC promotional materials and do all the other things that Jesse does at RDC. In 1986, we hired Andrea Botts as a full time technical writer. Her first project was the TranscriBEX manual, which is far and away the best manual we've ever produced. (It's getting rave reviews from transcribers around the country.) She insisted on getting each feature working for herself before she would write it up. She is currently working on software for the IBM-PC and other product testing.
Raised Dot Computing has been entirely self-capitalized. An Apple 2 plus computer and a VersaBraille bought by Caryn and I became the basis for Raised Dot Computing. The sale of software and hardware has financed the purchase of our equipment and our salaries. This funding method has meant that we must provide our own direction: no outside funding agency supplies us with a business plan. So how do we make decisions about the future?
Most days the RDC staff has lunch together, where we discuss the general approaches to the sticky situations we've encountered that day. The details are thrashed out later by those who are directly affected. For example, when someone wants a quote on a large quantity of software, it's an issue for Nevin (business manager), Kristi (office manager), and Becky (production manager). No one else needs to be involved. After all, it is Nevin who makes the deals, Kristi who types up the paperwork, and Becky who does the shipping. We have weekly staff meetings to develop long term policies. There are many good reasons for having the entire staff figure out its own rules. It's easier to remember and work with policies that you have helped to establish.
I'm proud of how well our system works, and I think that an understanding of it can assist those who have contact with RDC. When you call or write someone at RDC, she or he speaks for the company. The question, "Gee, does David approve of what you're saying?" is not really appropriate. Whether the person you're speaking with approves of what I'm doing is more to the point. As RDC has grown as a company, I've realized that software itself is a tiny part of a software enterprise. The technical changes I may make in software greatly affects documentation, product testing, production, customer service, and scheduling.
If you called me to try to develop a package price on software, I'd just have to put you on hold and consult with the front office staff. Besides, if I were calling all the shots at RDC, I would have to take myself more seriously. My door would not proudly display the "Mickey Mouse Executive Set" (complete with Mickey Mouse credit card, play money and phony keys).
Since RDC has been self-capitalized, we haven't been rolling in money. We've always been very cautious about purchases. We're unlikely to jump right in and buy new devices when they're announced. RDC did go out on a limb for a Thiel and for an Apple LaserWriter. Jesse, with her typesetting background, wanted a LaserWriter the moment she saw it. She had a hard sell convincing the rest of us. In September 1985 we started to phase in the Macintosh/LaserWriter system, and now we use it for just about everything--the Newsletter, manuals, promotional materials, etc.
As mentioned before, our customer record system is basically manual. For mailing lists and product data bases, we use the simple AppleWorks software. Kristi feels that our most significant purchase has been "Mr. Option" (her fancy memory typewriter).
To the dismay of many, Jesse has not yet explored naval architecture software for the Macintosh. If she did, it might help us do better in the annual "Dairy Carton Regatta." Our first boat made entirely of milk cartons did manage to cross the finish line without disintegrating. Our second craft, "Dairy Goes" displayed a pronounced tendency to pitch Kristi and Becky into the lagoon.
All in all, it's been an exciting six years. My hobby has grown into a real business. In 1984, callers on the tech line always asked to speak to "Dave Holloway." Recently I answered the tech line and the caller said, "David? Are you new around there?" To me, that's proof that we've developed as a team. We enjoy working hard and we enjoy our jobs. We definitely plan to be around long enough to add more chapters to this story.