Published More-or-Less 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. Editors: Jesse Kaysen & Phyllis Herrington.
Entire contents copyright 1988 by Raised Dot Computing, Inc., All Rights Reserved. Nothing may be reprinted in any medium--print, braille, audio, or electronic--without prior written permission from RDC Inc.
Table of Contents: the all-uppercase words name the disk chapters; the words after the equals sign are the actual article titles.
READ ME FIRST = How to Read the RDC Newsletter on Disk
CONTENTS = This Chapter (print page 1).
LASER LINES = Laser Lines from the Editor (print page 2).
FIVE LEARNING TRAPS = Five Traps in Learning About Computers (print pages 2-3).
BEX BEGINNER = BEX Beginner's Corner, includes: Quickly Estimating Chapter Size; Reading ProDOS Textfiles into BEX Chapters; Make Copies When You Translate (print pages 3-6).
IW LQ INTERFACE = Interfacing the ImageWriter LQ with BEX -- David Holladay (print pages 6-7).
VAPOR & GOSSIP = New Product Previews: What An Elegant Solution--Now What Was the Problem? -- Jesse Kaysen (print pages 7-9).
HD & WP = Using Hot Dots with Your Favorite Word Processor -- Phyllis Herrington (print pages 9-13).
OUTLINES & BEX = Making Inkprint Outlines with BEX -- Jesse Kaysen (print pages 13-17).
FRIEND OR FOE = Computers: Friend or Foe? Phyllis Herrington (print pages 18-19).
TROUBLESHOOTING = Troubleshooting Your Computer Problems -- Nevin Olson (print pages 19-23).
STUFF FOR SALE = Attention Schools & Agencies: Talking Potpourri for Sale (print page 23).
FAX ON FILE = Products Mentioned in this Issue; Notes on the Contributors; Who's Who at RDC; Trademarks (print pages 23-24).
MAKE OUT = Transformation chapter mentioned in "OUTLINES & BEX" article.
OUT DRAFT = Complete shorthand version of outline sample in discussed in "OUTLINES & BEX" article.
OUT FINAL = format command version of outline sample discussed in "OUTLINES & BEX" article. [End of contents.]
Much to my surprise, this Newsletter has developed a theme: how computers affect their users. For those readers who find this topic of interest, I recommend Sherry Turkle's fascinating research and meditation on the interaction between silicon and living minds, The Second Self.
Even the Dots in our air-conditioned offices were not immune from the Midwestern drought. We had unhappily grown accustomed to the brittle lawns and the forlorn rattle of perennials. Was there a time when stepping outside did not scorch the throat? Hadn't the city always felt like a closed box? And then it rained. The singular blessing of the drought was to reawaken our senses to the magic of water. Even the runoff in the sewers made a music: life itself dancing and chuckling. Every growing thing softened and swelled. No longer did survival demand that bush and tree and blade of grass hold their breath. A walk in the park has again become a journey through a thousand small weathers.
Over the past month I've been attempting to learn a new piece of software. It's a humbling experience. Accustomed to the computer as my willing servant, I rediscovered it as my adversary. This struggle has reacquainted me with the ordeals common to new computer users. Figuring out what was driving me bananas enabled me to persevere. I hope sharing my experience will help others to minimize the pain.
My first bite was too big. The task at hand was computerizing all of RDC's records, an exceptionally complex job. Naturally, this requires complex software. If the task had been translating Shakespeare into Mandarin Chinese, I would of course have begun by translating "Dick and Jane." But since I think of myself as a "power user," I falsely thought I could skip that step. After paddling around in the smooth waters of the tutorial, I waded right into the RDC database, and promptly drowned. Lesson 1: Complex tasks require complex skills--take time to develop these skills or risk failure.
I blamed myself for program deficiencies. Like BEX, the database program comes with ample documentation. I fervently hope that new BEX users find my documentation more useful than the lifeless pages I read and reread. After the fourth time through the manual, I began to doubt my own powers of reasoning. These doubts are deadly, since they undermine my ability to formulate questions. By the time I called for technical support, I'd convinced myself I did not even know what I did and did not know. I was no longer able to state the problem clearly, and so the technical support staff could not help me. Lesson 2: The moment you're confused and fuddled, stop and figure out what your question is. Write it down, and then reach out for help. Don't let frustration dig you into a hole.
I turned the means into the end. As I became more and more fascinated by the software, I forgot that its only function was to accomplish a specific task. When it seemed that I could not make the software perform the task, I panicked--how could we run Raised Dot without this program? Lesson 3: Just about anything one can do on a computer can also be done manually or with other technology.
I succumbed to computer voodoo. No longer operating in a completely rational manner, I began to experiment with different program functions more or less at random. These kinds of explorations can often lead to remarkable insights--however, I did not keep notes of my experiments. When something finally worked, I was stranded in computer voodoo--I had no way of retracing my steps to recognize what elements were effective. When faced with a similar task, I would whip out my voodoo code--and if it didn't produce the desired result, I was stuck. Lesson 4: As you guess and intuit your way through software, leave some breadcrumbs so you can find your way back. If you don't know why you're using a particular command or approach, then you're probably not making the most effective use of the software.
I forgot that computers are stupid. By this point, I had worked myself into a ridiculous lather. I allowed my inability to use the program to become a commentary on my own wit and worth as a human being. The shock cure for this condition is a strong dose of anti-technology: I removed myself to a North Woods cabin with no electricity. The call of the loons brought me back to my senses. Lesson 5: Computers are truly stupid. Software attempts to bridge the communications gap between sophisticated humans, (who can recognize patterns at a glance) and idiotic microchips, (who only know the difference between "on" and "off"). Great software allows humans to be the wonderful communicators we are. So-so software forces us to think in reductive terms. Lousy software requires us to think only in "on" and "off," and humans are too subtle for that.
As you work your way through the maze of technology, remember the magic of your own intelligence. Before any RDC product sends you over the edge, please give us a call! [End of article.]
This regular feature is designed to help new BEX users make the most of the software. We welcome your questions--you can submit them annonymously--as well as your insights!
Before you create a copy of a BEX chapter, you should be sure that there's enough room for it on your data disk. In addition to making identical copies for back-up purposes, you generally make modified copies of data when you use Grade 2 translation or Replace characters. DOS 3.3 measures space on disk in sectors: When you use option I - Initialize disks to prepare a BEX data disk, a 5.25-inch floppy disk has 528 sectors available to store your data. Press the number sign # at any BEX menu to find out how many sectors are available on a data disk. User Level Section 4 goes into great detail on how many sectors a given BEX chapter will occupy--too much detail for those who don't like reading manuals.
Here's a quicker rule of thumb: To get the approximate number of disk sectors a chapter requires, divide the number of characters by 200 and round up to the next whole number. To discover how many characters are in your chapter, use the Page Menu option F - File list. Suppose File list tells you a chapter contain 12,549 characters: 12,549 divided by 200 is 62.745. Always round the result up to the next whole number, in this case, 63 sectors.
Now you know how much room is required: before copying this chapter, press # to check the sectors free on the disk. In this case, if BEX reports less than 64 sectors free, I'd have to find another data disk with more room. If none is handy, then you can create a new data disk with option I - Initialize disks on the Starting Menu. Get to BEX's Main Menu, insert the Boot side of BEX in drive 1, and press the spacebar. Now press I to totally erase the contents of a disk and prepare it for storing data.
While many people are good at dividing numbers in their heads, I'm not one of them. And my desk is such a mess that I usually can't find my calculator when I need it. Fortunately, Apple IIs have BASIC built in, and BASIC includes a simple calculator. To estimate the number of sectors required, I press Q at the Main Menu. Q quits BEX while retaining speech and large print output. Once I've quit, I'm at the BASIC ] "Ready" prompt, where I can type:
]? 12549/200 <CR>
BASIC obligingly responds:
To return to BEX, I simply type RUN<CR> at this point.
The question mark is a shorthand for the BASIC command "PRINT"; you're asking BASIC to immediately evaluate the arithmetic that follows and print the result. As you can see, division is shown with the slash; use the asterisk (star) for multiplication, the plus sign for addition, and the hyphen for subtraction. You can use parentheses to evaluate more complicated expressions: to solve 95 times the quantity 18 divided by seven-eighths, you would type:
]? 95*(18/(7/8)) <CR>
As my math professors used to say, "the answer is left as an exercise to the reader."
Beginning with version 2.1, BEX has had the capability to read ProDOS textfiles directly from a ProDOS formatted disk into a BEX chapter. However, there is a very important thing to keep in mind: you cannot save the resulting BEX chapter on the ProDOS formatted disk; you must save it to a DOS 3.3 formatted disk. DOS 3.3 and ProDOS save files in different ways: ProDOS does not accept DOS 3.3 files and DOS 3.3 does not accept ProDOS files.
When your Apple has two disk drives, you must put the ProDOS disk in one drive and the DOS 3.3 disk in the other. Here's a step-by-step sample. You begin with your BEX program disk in drive 1, and the ProDOS disk containing the textfiles in drive 2. Get to BEX's Second Menu by pressing S, then proceed as follows:
Enter Option: R
Read textfile to chapter: 2 <CR>
There are 3 textfiles
Use entire list? N Y <CR>
(enter question mark for choices)
Target chapter naming method:
As you can see, BEX can supply on-line help on what naming methods are. In this case, you can't use the S naming method, which tells BEX to name the target chapters the same as the source textfiles. That's because the ProDOS textfiles have periods in their names: if you used the same naming method, BEX wouldn't be able to recognize the chapters.
You have to provide BEX with target chapter names individually. You also must tell BEX to write the target chapters on the DOS 3.3 disk in drive 1. At the moment, the disk in drive 1 is your BEX program disk, which won't have room to store all the textfiles. Replace your BEX disk with an initialized DOS 3.3 disk with some room, and respond like this:
Target chapter naming method: 1I <CR>
The digit one tells BEX to write the chapters on drive 1. The letter I tells BEX you are going to supply a name for each target chapter.
For textfile PART.1
Target chapter name: PART 1<CR>
For textfile PART.2
Target chapter name: PART 2<CR>
For textfile PART.3
Target chapter name: PART 3<CR>
Once you tell BEX how to name all the chapters, it gets to work. You hear the disk drives whirring for a while until all the ProDOS textfiles have been copied to DOS 3.3 BEX chapters.
For BEX 2.1 and 2.2, your ProDOS textfiles must be on 5.25-inch floppy disks. As David detailed in the April/May 1988 Newsletter, BEX 3.0 lets you read and write data on 3.5-inch disks as well. Since a ProDOS 3.5-inch disk can store around 750,000 characters, many people take advantage of ProDOS subdirectories to partition all that storage into smaller units. While subdirectories make it easier for ProDOS users to find files, they pose a problem for BEX.
When reading textfiles from a ProDOS disk, BEX can only find those files that reside outside of a subdirectory, at the root or highest level. Suppose you have a 3.5-inch disk named /AW which contains both the AppleWorks programs and some AppleWorks data. The program is stored in a subdirectory named /AW/APPLWRKS while the data is saved to an /AW/DATA subdirectory.
When you create a ProDOS textfile in AppleWorks, the software requires you to type in the full pathname for the file: /VOLUME.NAME/SUB.DIRECTORY/FILE.NAME is the general pattern. To write your textfile at the root level, where BEX can find it, don't specify a subdirectory: enter /AW/TEXTFILENAME
Option G - Grade 2 translator on BEX's Main Menu modifies inkprint data to make properly contracted braille. Once you have created an inkprint chapter, BEX needs to know two things before it can translate: where to find the inkprint data, and where to save the braille data. In BEX lingo, the original inkprint chapter is your source chapter, while the modified braille chapter BEX creates is your target chapter.
It's always a good idea to keep the source and target chapter separate in braille translation. That way, if you need to correct the inkprint or add to it, you can easily do so and then translate it again. You control, by the name you assign to the target chapter, whether BEX makes a modified copy or overwrites the inkprint source with the braille target. When the source and target chapter names are identical, then the source chapter data is gone forever after braille translation is complete. We urge you to use different source and target chapter names to maintain both inkprint and braille versions of a document.
Here's how you do that. When you translate one chapter at a time, you type in the complete target chapter name. To distinguish between braille and inkprint chapters, we always add the digit 2 to the source chapter name. For example:
Enter Option: G
Grade 2 translator
Drive number or chapter name: QUIZ<CR>
Target chapter name: QUIZ2<CR>
Starting to translate ...
If you typed QUIZ for the target chapter name, then the inkprint original would no longer exist once translation was finished.
When you translate more than one chapter, BEX asks you for a target chapter naming method. These code letters instruct BEX how to construct the target chapter names by modifying the source chapter names. To tell BEX to add the digit 2, you use the A2 naming method, like this:
Enter Option: G
Grade 2 translator
Drive number or chapter name: 2<CR>
There are 3 chapters
3 UNIT 1 TEST
Use entire list? N Y
Target chapter naming method: A2<CR>
Starting to translate ...
Once BEX is finished translating, this data disk contains three more braille chapters: HANDOUT2, QUIZ2, and UNIT 1 TEST2. Only if you entered the S naming method would BEX overwrite your source chapters with the target chapters.
When you want to revise a braille document, always edit the inkprint source chapter and then translate the whole thing again. For example, when the teacher hands you just one more question for the quiz, type it in to the QUIZ chapter, then use the translator to make a revised QUIZ2 chapter. BEX writes the now-complete QUIZ2 braille chapter on top of the old QUIZ2 braille chapter: you still have separate inkprint and braille versions.
Some folks are tempted to take a shortcut by typing the new inkprint in the braille chapter and then translating the braille chapter a second time. This doesn't work--all you get is a mess. When the inkprint original is:
Chapter 4 Quiz: Places You Know
the correct braille translation is:
,*apt] #d ,quiz3 ,places ,y ,"k
If you translated this braille again, the resulting double speak would be:
1 99 apt7' #;d 1quiz#c 1places 1;y 18;k
However, if you have by misadventure lost the inkprint original chapter, you can probably recreate it. At BEX's User and Master Levels, the Main Menu includes option B - Back translate from grade 2. If you want to recreate an inkprint original, you must first configure at the User (or Master) level to get access to back-translation. Boot BEX and enter this User Level configuration name, get to the Main Menu, and press B. When BEX prompts for a chapter, enter the name of your grade 2 braille chapter. The target chapter will be inkprint--make sure you give it a different name! [End of article.]
Apple Computer has come out with a new dot matrix printer. As the name implies, the ImageWriter LQ is an ImageWriter with a letter quality mode. Its 27-wire print head gives superb print quality. In its draft mode, it can produce 250 characters per second. In this age of laser printers, we sometimes forget that you need an impact printer to produce carbons and ditto masters. But it is not cheap: the ImageWriter LQ lists for $1429, (street price around $1150 at a local computer store).
The DIP switches on the ImageWriter LQ are underneath a panel held down by a single screw on the top of printer. There are three banks of DIP switches. Never change the third bank of switches yourself. The default baud rate is 19,200 baud, while BEX's "Standard Parameters" use 9600 baud. To establish communications, the baud rates must match: you can change the ImageWriter dip switches or change the baud rate on the interface card. If you want to slow things down on the ImageWriter end, reverse the positions on switches 2-1 and 2-2. If you want to speed things up with an Apple Super Serial card, reverse the position of Switch 1-4. Alternatively, you can send a command sequence to an Apple port or SSC to change the baud rate: 15 B sets the baud rate to 19,200, while <command> 14 B sets the interface back to 9600.
When using the ImageWriter LQ with BEX, you can generally pretend that you have an ImageWriter II. The ImageWriter LQ obeys the same escape sequences as the ImageWriter II, and it also connects to your Apple with the same cable. However, the default output is initially disappointing. When I made a sample of BEX's 18 point large print, I noticed that the dots that form the letters do not overlap. The white space between the dots gives the large print a lighter look than you get from an ImageWriter or an ImageWriter II. I'm sure that photocopying the output would produce better results. It's also possible that some DIP-switch setting or escape sequence can squeeze the dots together--I welcome reports from the field on this one!
The near-letter-quality mode is very attractive. To turn on this mode, use three characters: <Esc>a2 the Escape character, lowercase a, digit 2. The result is pretty tiny. To get larger characters, use <Esc>n to turn on expanded, or 9 characters per inch. Once you make the letters larger, it looks nice to add some vertical space: The sequence <Esc>T32 sets the line spacing to 32/144 of an inch between each line. (Default line spacing is 24/144 of an inch, so you should cut back the form length to 75% of the BEX Dox recommendations.) A left margin would be good, as well: use <Esc>Lnnn to establish a left margin "nnn" characters wide. A complete sequence would look like:
See the April/May 1988 RDC Newsletter article about BEX Large Print for full details how to send escape sequences to your printer with BEX. The ImageWriter LQ manual discusses a host of other escape sequences as well.
I have only had a brief chance to work with an ImageWriter LQ at a computer store. It seems like a solid piece of equipment that is quite versatile. If you have access to one, you should have no difficulty using it with BEX. [End of article.]
Early July found RDC in Montreal at the convention of the Association for Education and Rehabilitation of the Blind and Visually Impaired (AER). Nevin and I had the opportunity to meet many of our Canadian and U.S. customers, as well as the chance to bask in the French atmosphere of that lovely city on the St. Lawrence. While the convention-goers were attending hundreds of useful workshops and presentations, I had a few free moments to browse the latest in sensory aids technology. For those unable to attend this or any of the other summer conventions, here's a highly biased selection of interesting products that may be available to you in the near future. Names and addresses for all these products appear in Facts on File.
The most bizarre name-change award certainly goes to Sensory Aids Corporation: they're now known as HumanWare. Their new president, Jim Halliday, readily acknowledges some may think this name comes straight from the Sensory Overload catalog, but asserts that the new name demonstrates HumanWare's commitment to making products that are sophisticated and easy to use. HumanWare was demonstrating a very exciting, if very buggy, prototype of the Keynote PC+. Around the size of a three-ring binder, this portable computer has two personalities: it's a Keynote and it's a talking MS-DOS compatible. As described in the March 88 Newsletter, the Keynote is a self-contained easy-to-use notetaker, word processor, calculator, and terminal; MS-DOS is MS-DOS. This combination seems to make a lot of sense, and best of all, HumanWare prices it at $2995. Jim said they hope to ship "sometime in the Fall."
Australia's Quantum Technology shared the booth with HumanWare, and their prototype of the Mountbatten Brailler wins the Salvador Dali award for Art Deco hardware design. As wide as an IBM Selectric, around 4 inches high and 9 inches deep, the Mountbatten's sleek gray body and zippy yellow keypad are simply gorgeous. The keypad is not only beautiful but durable as well: it's a solid rubber rectangle, with well-placed keys rising up from its surface. I'd summarize their blueprint for the Mountbatten as "start with a Cranmer Brailler redesigned for the 90s and then build from there." It will be an electric braillewriter with built-in eraser as well as a 10 cps computer-driven braille embosser accepting single sheets and tractor-feed paper; Quantum also promises ROM-resident braille translation. Quantum currently plans to ship sometime in mid-1989.
Kurzweil Corporation was demonstrating an absolutely astounding piece of technology: the Kurzweil Personal Reader. This next-generation reading machine offers you a choice of scanners for typeset or typewritten print: an automatic flatbed or a handheld manual (or both). A separate 12 x 7 x 17 inch box holds the very smart computer that interprets the scanned material, as well as the DECtalk synthesizer that speaks the interpreted text. An 18-key detached keypad controls all scanner operations. You can use the built-in DECtalk independently as a speech synthesizer with a computer; the Personal Reader has a completely configurable RS-232 interface.
I was awed by the Personal Reader's brains: it took around 90 seconds to scan and recognize page 4 from the November, 1987 RDC Newsletter, and then it started reading it back almost perfectly. The large print edition of the Newsletter is a nasty, real-world test: blobby laser-printed type, in a two column format complete with decorative and irrelevant lines, four different typestyles, and a three-column chart. However, this test did raise some interesting questions about the Personal Reader. For some reason, one occurrence of the phrase "computer braille" was recognized as "computer file." On the plus side, the Personal Reader's software lets you review all the data in its memory--I could find that word and spell it out letter by letter. The problem is that even this impressively-high IQ artificial intelligence makes mistakes.
While human readers require more initial training, they are truly capable of reading everything correctly. Users must weigh the considerable convenience of automatically scanning inkprint and getting a file that can be sent to a computer with the definite drawback that the file can contain errors. In my old-fashioned and cynical opinion, hiring high-school students as readers has some advantages over even this remarkable device. Kurzweil plans to ship the Personal Reader in August of this year; a system with both automatic and manual scanners would set you back around $12,000.
Finally we come to the product that inspired the title of this article. At their open hospitality suite on Monday night, Telesensory Systems, Inc. demonstrated a very early beta test version of inTOUCH, a screen access product for the Macintosh. Since Berkeley System Design has extensive Mac experience with inLARGE, TSI hired them to program this Mac utility. inTOUCH captures the screen display immediately surrounding the Mac's cursor and sends the data to an Optacon II's tactile array.
As a confirmed Mac addict, and as a sighted user familiar with many of the issues surrounding computer use by blind people, inTOUCH made me absolutely furious. The Macintosh has a well-deserved reputation as an easy-to-use yet powerful computer. The reason is its whole-screen user interface, which provides sighted people with a feeling of being in control. Apple's interface guidelines have ensured that conversations between the user and computer entail minimum mystery.
After only a few week's experience with the Mac, I knew how to operate just about any Mac program. Every program presents a menu bar across the top of the screen: I can randomly explore and compare all a program's functions by browsing the choices on the menus. At any juncture, all the choices and their effects are graphically presented for my comparison. To take just one example, mutually exclusive choices--like the baud rate for a serial port--are subtly signalled by the shape of the round "radio button" that selects them. Because of this graphic cueing, many Mac programs won't have a prompt like "Choose one of the following."
Providing blind computer users with meaningful access to the Mac's whole-screen interface is a tall order. A tactile representation of a tiny portion of the screen ain't it. It's like asking a fully sighted person to read a topographic map through a soda straw. TSI can afford to fund research and development as they see fit, but I wish they'd put their money somewhere else. Berkeley System Design has a paying client in the development of inTOUCH, while their long-announced (October 1987) voice utility for the Mac, outSPOKEN, is on the back burner. If inTOUCH is only a research project, why is TSI demonstrating it at a hospitality suite at the AER Convention? Working with braille and speech access to text-based applications on the Apple and IBM, blind people have become vocationally competitive computer users. Does TSI expect blind computer users to welcome an inherently slow and frustrating access tool like inTOUCH? [End of article.]
Over the past two and a half years, I have handled various questions pertaining to the Hot Dots program for the IBM-PC and PC compatibles. Frequently people ask how to use Hot Dots in conjunction with their word processor in order to output properly translated and formatted braille. Hot Dots creates format by interpreting the $$ commands in your braille data. There are two basic approaches you can take: type Hot Dots' $$ commands into your text as you are entering data in your word processor, or use the global search and replace routines of your word processor and Hot Dots to replace word processor-specific codes with the $$ commands needed by Hot Dots formatter for correct formatting. I will attempt to answer many of the questions you may have. If there are some difficulties you experience which are not addressed here, please contact us at RDC before your frustration level gets to the dangerous point.
Before we get to specifics on how to use your word processor and Hot Dots, understanding some background concepts will save you time and frustration.
First, the file you send to Hot Dots for grade 2 translation and formatting must be in the form of an ASCII textfile. Some word processors store information in a form that is specific to it. We cannot predict how Hot Dots will react to a different file structure than ASCII.
Secondly, you need to think about line endings. To mark the end of a printed line, IBM-PC's use a pair of control characters: carriage return/linefeed (we'll abbreviate this as CR/LF). There are two types of CR/LF line ends: soft and hard. You create a hard CR/LF when you press Return or Enter in your word processor--this generally defines a new paragraph. The word processor itself places soft CR/LFs in your text to break lines on the screen. When you use your word processor to create an ASCII file bound for Hot Dots, the soft and hard CR/LFs are stored identically on disk. Hot Dots' formatter can't tell the difference between a new paragraph and just another inkprint line, but this distinction is crucial for correct braille translation and format. The ideal input for Hot Dots' formatter contains no CR/LFs at all. Instead, a new paragraph is signalled by ($p), and a new line by ($l). I'll get down to details on how you make the meaning of CR/LFs clear later on.
Another issue of concern in generating braille is multiple spaces. Common practice in the world of writing print, by hand or otherwise, is to place two spaces between the ending punctuation of a sentence and the beginning letter of the next sentence. Proper braille format allows only one space between the ending punctuation of one sentence and the beginning of the next sentence. Two spaces in a row can cause problems when translating some words. Only when exactly one space follows words like "to," "by," "with," "of," or "for," can Hot Dots correctly jam the word up to the next one.
Both your word processor and Hot Dots contain a feature that enables you to manipulate data, generally called "global search and replace." Search and replace lets you change one thing into another. It's important to recognize which search-and-replace tasks are best handled by which software. Only the search-and-replace in your word processor can recognize some format information. Most word processors let you search for a new paragraph--it can tell the difference between a soft CR/LF and a hard one. (Hot Dots' GLOBAL can make some educated guesses about the difference, but your word processor will be more accurate.) On the other hand, the search-and-replace in most word processors can only do one thing at a time. Hot Dots' GLOBAL uses a rules file, which can contain a long list of replacements. We supply a number of rules files on the Hot Dots disk that accomplish specific tasks. Once you've experimented a little with the information from this article, you'll be able to write rules files to do all the data massage required with your software.
Finally, the creation of braille with Hot Dots must follow a definite order:
Step 1: Prepare the inkprint file. This means data entry with a word processor or editor, plus search and replace with the word processor and/or Hot Dots.
Step 2: Translate inkprint to braille with DOTS.
Step 3: Create a formatted textfile with FTEXT, which interprets the $$ commands.
Step 4: Printing the formatted file to your braille embosser.
It is imperative that grade 2 translation or back-translation takes place before you run the file through the formatter. Grade 2 translation changes the number of characters in your text. If you format first, then some of your lines would be too short after translation.
In order for Hot Dots to format your braille correctly, it needs to interpret $$ commands in your braille text. The decision faced by the Hot Dots user is when and how to insert these commands. One factor is the purpose of the file: Some files will be prepared for generating braille documents only while other files will be intended for both print and braille hard copy. Another factor is how your word processor controls format. If it also uses embedded, printing commands, then it's easy for Hot Dots' GLOBAL to find and change them. But if your text is formatted through invisible function keys, and the format attributes appear on your word processor screen, then you will have more success placing Hot Dots' $$ commands while still in your word processor.
Because Hot Dots' $$ commands are meaningless to your word processor, you can enter them directly into your text. Doing this reduces the amount of global replacement required to prepare the document for braille translation and formatting. You can set margins, tabs, line spacing, center text, establish running heads, instruct certain lines be left blank, etc. The most important commands to enter are the paragraph and line indicators. ($p) is what Hot Dots' formatter needs to see to make a correct braille paragraph, while ($l) makes a correct braille line.
Once you create an ASCII version of this file, you still need to use Hot Dots' GLOBAL to remove all the CR/LFs. If these remain in the text, the length of the braille lines will be very strange. You may get a forty character line followed by one with only ten characters.
Most often your files have two purposes: you want nicely formatted print and braille copies. The print version is the responsibility of your word processor; you've used its own format commands to make your document look the way you want. The challenge is getting a braille version. Just as the $$ commands of Hot Dots are not interpreted by the print program of your word processor, the formatting codes of your word processor are not interpreted by the formatter of Hot Dots. In order to get well-formatted braille hard copy, the file must contain the $$ commands native to Hot Dots.
Basic formatting such as indicating new paragraphs and forcing new lines are two areas in which Hot Dots must know what you are doing. For example, in some word processors, a new paragraph is signaled by either one return or two. In order for Hot Dots to properly handle indent and linespacing of paragraphs, the formatter must see ($p), the paragraph indicator. When the formatter is interpreting a file with the .BRL extension, it advances one line and indents two spaces when it encounters the ($p). If your file doesn't end with .BRL then the formatter uses print values.
While your word processor thinks of CR/LF as a paragraph, Hot Dots thinks of it as a new line. If Hot Dots were to encounter a CR/LF, it reads it literally and advances to the next line and starts text at the left margin. Since we recommend you remove all CR/LFs as the first step in Hot Dots processing, you must use the new-line ($l) indicator when you want to force a new braille line. There may be a special code within your word processor to force a new line, but Hot Dots doesn't know how to interpret it. Now that I have gone around the world to give simple examples of clashes, it's time to introduce how Global Search and Replace can make your task a lot easier.
My advice to users is to do as much replacing as you possibly can within the environs of your word processor. Before you begin replacing, be sure that you save your final inkprint version! Once your replacing is complete, the file will be ready for input to Hot Dots for some clean-up with GLOBAL.
Search for a new paragraph, and replace it with ($p); then search for a forced new line (if possible) and replace it with ($l). Search for the tab command and replace it with ( $$); look for the commands you used for headings and stick in Hot Dots' centering command $$c. You may have to do some research in the manual to discover how to find a format code. Some word processors like WordPerfect have the capability to let you view the formatting codes, which makes it easier to discover where they are.
You've laid the groundwork for good braille by placing the $$ commands in your word processor, either manually or with the help of search and replace. You use the word processor to create an ASCII file, and you have data ready for Hot Dots processing. Hot Dots' GLOBAL lets you write rules files to exchange certain characters with something else, save these to disk for use at another time, and even use rules files supplied on your disk by RDC. Just to make things a little more confusing, the names of the supplied rules files changed from version 1.5 to version 2.0--I'll give both names to help you get the right file.
There are some general housekeeping tasks you must take care of to get nicely formatted braille. A common feature of word processors which will send Hot Dots into a tailspin is high bit characters. Many word processors use ASCII characters higher than 127 to represent accented letters, issue instructions to the printer, and for certain formatting information. Before Hot Dots can properly handle the file, these high bit characters must be turned off. By using strip.rul in Hot Dots 2.0 (it's called wordstar in version 1.5), these high bit characters are turned off and other control characters are removed from your file except for CR/LFs, tabs, and form feeds.
Earlier on I mentioned how GLOBAL can make an "educated guess" about the difference between soft and hard CR/LFs. This trick is accomplished with the rules file named fixtxt.rul in Hot Dots 2.0 (or strip in 1.5). This handy rules file changes two carriage return/line feed pairs to the paragraph ($p) indicator, while changing single CR/LF pair to a space. This rules file finishes up by changing two spaces to one. If you haven't entered ($p) in your word processor, then you must run GLOBAL with this rules file before you translate into braille.
Those of you who have Hot Dots 2.0 will also notice the crlf.rul rules file, which simply changes CR/LFs into spaces without inserting ($p) as the paragraph indicator. If you have already placed your ($p) in the text, then you should use crlf.rul before you translate to ensure accuracy. We didn't supply a rules file like this with version 1.0 or 1.5. Here are the nasty hexadecimal codes you use:
From: ~0D~0A [Enter]
To: <Space> [Enter]
Writing rules files containing control characters is a lot easier with Hot Dots version 2.0 and its "verbatim" control-V command. Each time you want to enter a control character in a from string or to string in your rules file, enter control-V then the control character. Owners of earlier versions can still upgrade to 2.0 for just $75!
As mentioned at the start, you don't want two spaces between words in braille, so you must remove double spaces in your inkprint. Some word processors end each line in an ASCII file with <Space><CR>; once you strip out the CR/LF pairs, you may have extra spaces in your file. Hot Dots 2.0 includes a rules file, named space.rul that takes care of this. Unfortunately, if you are using earlier versions of Hot Dots, you must write your own. You want your rule to instruct Hot Dots to change every incidence of two spaces into one space; once you've written it, you can save it to disk for later use. The dialog would go like this:
From: <Space><Space> [Enter]
To: <Space> [Enter]
Save rules file? (y/n) y [Enter]
Rule file name: myspace [Enter]
Especially if you are a new user, this discussion about search and replace in two different programs may seem overwhelming. However, take heart! Those of us who work with Hot Dots at RDC did not come into this world knowing how to use the program. We had to make mistakes and figure out where we went wrong. Read everything carefully and take things one step at a time. Remember, Rome was not built in a day. Learning software is not done during the first session at the computer, but hopefully these helpful hints will make learning an easier task. If you encounter difficulties, please do not hesitate to call the tech line for further assistance. If any of you experienced Hot Dots users have helpful hints, please pass them our way and we will share them with others. [End of article.]
In school, many BEX users face the assignment of generating outlines for their themes and papers. You can make precisely nested outlines with just two BEX format commands: $$p# and $$ml*. To see why those commands do the job, let's analyze how outlines are formatted in inkprint.
An outline consists of a series of ideas or points, usually referred to as topics, ranked in a hierarchy. Two features show the reader where each topic fits in the ranking: nested indents and labels. In this article, I follow the format guidelines presented in the Modern Language Association Handbook. Your instructor may require a slightly different format, but the same general method will apply.
Outlines look like flights of stairs. The main topic begins at the inkprint left margin, with an uppercase Roman numeral label followed by a period. The text of the main topic is indented five characters. The second level, or subtopic, label is indented five characters: it's immediately below the text of the main topic. The label for the subtopic is an uppercase letter plus a period, and then its text is indented 10 characters from the left margin. The label for a third-level topic is an Arabic digit followed by a period: again, this lines up with the text of the subtopic above it. The sub-subtopic text is indented 15 characters. Further subdivisions use labels of lowercase letter plus period; then Arabic digits enclosed in parentheses; and finally lowercase letters enclosed in parentheses.
The labels always align with the text of the topic above, and the text itself is indented five more characters. This combination of changing left margin and distinctive labels helps readers find their way around the outline hierarchy.
For each topic, you need BEX format commands that say: "put this label at the appropriate spot horizontally on the line. Then move over five and line up all the rest of the text at this point." Since BEX has so many format commands, there are a variety of ways to accomplish the task. The method that follows uses a minimum number of commands.
Begin each topic with BEX's paragraph ($p) indicator, making a blank line between each point in inkprint. (If you want two blank lines between each point, increase the paragraph line spacing with the $$s3 command.)
To place the label at the correct indent, use the $$p# command. The number in this command forces BEX to print the text that follows at the # position on the line, overriding any indent or margin currently in effect. The main topic uses Roman numerals for labels, and these vary in length. Instead of fussing with typing the exact number of spaces, use another $$p# command to place the text of the topic exactly where you want it.
This second $$p# gets you to the start of the topic text. You want all this text to line up at the current point, so you need to establish a left margin. If you tried to set an absolute left margin with the $$ml# command in the middle of a line, you would get unpredictable results. Instead, use the "floating" left margin command: $$ml* sets the left margin at BEX's current position on the output line.
The following commands create the format specified by the MLA Handbook:
$p $$p0I. $$p5$$ml* First level text (main topic)
$p $$p5A. $$p10$$ml* Second level text (subtopic)
$p $$p10 1. $$p15$$ml* Third level text (sub-subtopic)
$p $$p15 a. $$p20$$ml* Fourth level text (sub-sub-subtopic)
$p $$p20 (1) $$p25$$ml* Fifth level text
$p $$p25 (a) $$p30$$ml* Sixth level text
The formatter interprets the $$ commands in your text to build up one output line at a time, then ships the composed line to the printer.
Let's break down how the formatter interprets the commands for the first level text above. When BEX sees the paragraph ($p) indicator, it starts out putting two <CR>s and five spaces in the current line. The five spaces are the default paragraph indent for inkprint. But BEX immediately gets the $$p0, so it zips the current position back to the initial position on the output line. BEX throws away the space following this command, placing the Roman numeral I at position 0. The period is at position 1, and position 2 is blank.
Now BEX encounters the $$p5 command and stuffs three spaces in the current line, moving the current position to 5. Next comes the $$ml* command, which tells BEX "set the margin here." "Here" is position 5, so any text that's longer than the current line will begin at this left margin. You don't have to worry about cancelling these left margins. The start of each paragraph is precisely defined with the $$p# command, and every time you set a new margin you cancel the old one.
To prove that these command do indeed work, here's the outline I used to write this article, as it would appear on a 50-character carriage width: [Disk readers: kindly print the "OUT FINAL" chapter on this disk to a Review class printer or the screen to see the final result.]
The sample above left-aligns all the labels and the text. Some instructors require you to align the labels on the period. This requirement only affects the Roman numeral labels for the main topic, since only these characters vary in length. BEX's "sticky spaces" were designed for just this kind of situation.
Two BEX commands work together to create sticky spaces in inkprint: $$ss tells the formatter that you want to use sticky spaces, and the single <Control-S> character tells the formatter to print one space, no matter what. (Unlike a regular space, the formatter won't replace a sticky space with a soft <CR>. Another use for a sticky space is to keep two words together on an output line.)
Using sticky spaces requires a little arithmetic. Once you've completed your outline, identify the longest Roman numeral label. In my sample, it's three characters long: "III". Go back to any label that's shorter than three characters, and place enough sticky spaces to even it out immediately before the label. In this case, the first line would look like:
$p $$p0<Space><Control-S><Control-S>I. $$p5$$ml* Outline Format Generalities
To type a <Control-S> in the Editor, press control-C S. Just typing the <Control-S>s in the Editor is not enough! You have to remember to add the $$ss format command at the start of your outline chapter, or BEX just sends the <Control-S> characters on to your printer.
When you're writing an outline, you want to focus on the content, not on the format. Instead of typing in the format commands as you write, you can develop a shorthand of unique characters to enclose each topic's label. These shorthand characters will be easier to type and easier to listen to as you're in the throes of the creative process.
Once you're all done composing, you use Replace characters to expand your shorthand to the appropriate format commands. You must choose shorthand characters that won't show up as data in your outline. Few outlines include vertical bars; here's a shorthand system that worked well for me.
I enclose each topic label within vertical bars. I start each topic with one <CR>, followed by a number showing the outline level for that topic, followed by one vertical bar. Then I type the entry's label, followed by one vertical bar, the level number, and one space. Just to make my life easier, I don't bother typing the punctuation for each topic label--I include the periods and parentheses in the transformation chapter that expands the shortcuts. Using this shorthand, you'd enter the MLA's formats like this:
<CR>1|I|1 First level text (main topic)
<CR>2|A|2 Second level text (subtopic)
<CR>3|1|3 Third level text (sub-subtopic)
<CR>4|a|4 Fourth level text (sub-sub-subtopic)
<CR>5|1|5 Fifth level text
<CR>6|a|6 Sixth level text
When I listen to this in Some punctuation, the Echo doesn't pronounce the vertical bars, but there is a slight pause between the initial number that shows the level and the letter or number labelling the outline entry. It's easy for me to move between topics with control-A control-L or control-Z control-L. To see how this system works in practice, here's the shorthand version of a portion of the outline printed above: [Disk readers: the shorthand version of the entire outline appears in the "OUT DRAFT" chapter on this disk.]
<CR>1|III|1 Shortcut Format Commands
<CR>3|1|3 Concentrate on composition instead of format
<CR>3|2|3 Greater accuracy through fewer characters
<CR>3|1|3 Settle on unique character
<CR>3|2|3 Write transformation chapter
<CR>3|3|3 Test transformation chapter before extensive data entry
To expand these shorthand vertical bars and numbers to the appropriate format commands, I used the following transformation chapter. To make it easier to understand, I show the rules as I entered them by following the prompts; after each rule, I explain what I'm doing. [Disk readers: the transformation chapter itself is on this disk, under the name "MAKE OUT".]
Main Menu: R
Drive or chapter: OUT DRAFT<CR>
Drive or chapter: <CR>
Target chapter name: OUT FINAL<CR>
Use transformation chapter: <CR>
Enter terminator: #
Change to: <Space>$p<Space><Space>#
Find the three shorthand characters preceding the first level topic label, change to new paragraph, force to left edge
Change to: .<Space>$$p5$$ml*<Space>#
Find three shorthand characters following first level label, replace adds the period plus commands to force to position 5, set left margin here
Change to: <Space>$p<Space>$$p5<Space>#
Find three shorthand characters preceding subtopic label, change to new paragraph, force to position 5
Change to: .<Space>$$p10$$ml*<Space>#
Find three shorthand characters following subtopic label, change to adds the period, force to position 10, set left margin here
Change to: <Space>$p<Space>$$p10<Space>#
Same strategy as second level, but change to increases position number by five
Change to: .<Space>$$p15$$ml*<Space>#
Same strategy as second level, but change to increases position number by five
Change to: <Space>$p<Space>$$p15<Space>#
Same strategy as third level, but change to increases position number by five
Change to: .<Space>$$p20$$ml*<Space>#
Same strategy as third level, but change to increases position number by five
Change to: <Space>$p<Space>$$p20<Space>(#
Find three shorthand characters preceding fifth level label, change to new paragraph, force to position 20, then add opening parenthesis
Change to: )<Space>$$p25$$ml*<Space>#
Find three shorthand characters following fifth level label; change to adds closing parenthesis, force to position 25, set left margin here
Change to: <Space>$p<Space>$$p25<Space>(#
Same strategy as fifth level but change to increases position number by five
Change to: )<Space>$$p30$$ml*<Space>#
Same strategy as fifth level but change to increases position number by five
The end of the transformation chapter
Continue? Y <CR>
Replaced 34 times
Save transformation chapter: MAKE OUT<CR>
Notice that the transformed chapter has a different name--it's much easier to make revisions in the shorthand version and then use the MAKE OUT transformation chapter again.
Whenever you use Replace characters to expand shorthand, you should test it before you do a lot of data entry. As I was writing this article, testing helped me avoid a total disaster. On my first attempt, I really blew it. Where my shorthand version had:
<CR>3|2|3 Greater accuracy through fewer characters
the replaced version looked like:
<CR>3. $$p10$$ml*. $$p15$$ml*Greater accuracy through fewer characters
The problem lay in how I had defined the find string. To place the period, $$p#, and $$ml* commands, I looked for "vertical bar, level number" instead of "vertical bar, level number, space." Notice that the transformation rule for "vertical bar, digit 2" appears before the rule for "vertical bar, digit 3." Replace characters is totally literal-minded: it saw the label "2" as "vertical bar, digit 2" and changed it to the format commands for a second level topic. The final transformation that appears above avoids this problem by adding a space. [End of article.]
The story goes like this: A man received his electric bill (hydro for our friends in Canada) which stated he owed the company $5000. This was at the time when computers read key punch cards which not only boldly proclaimed the amount owed but also had explicit warnings not to bend or otherwise mutilate the card. After trying several times to straighten out the mess, this poor soul got so frustrated that he stapled the card together, put it on the floor and stomped on it, punched some more holes in it, ran it through the washing machine, and then sent it back to the power company to see what would happen. Imagine this guy's surprise when he received a notice informing him he did not owe the company $5000, rather the utility company owed him one million dollars due to overpayment! "Friend or foe?" you ask.
This incident causes us to chuckle and whisper a prayer of thanksgiving we weren't on the receiving end of such an astronomical bill. But have you ever stopped to consider how much our lives have been affected and are being affected by computers? Jobs are being created each day, while others are being phased out. A couple weeks ago I began such a musing, and I want to share some of my thoughts with you.
Before I go any further, I must assure you I do not wish to see computers banned from the planet. If I did, I would be shooting myself in the foot, since computers provide the means for me to put food on my table and in my dog's dish, as well as clothes on my back and a roof over my head. Even if I didn't work for a computer company, I would still need computers to let me independently prepare written material and run my personal affairs. Wild horses could not separate me from my computer--maybe I'll take my computer with me when I see them charging at me. But is the computer our friend, foe, or both?
Recently I found myself wishing I had one of those laptop PC-compatible computers. It would facilitate exchanging files with my friends who have PC's instead of Apple computers. Although I have access to PC's at work, I wanted to be able to make the transfers at 2 A.M. if I so desired. After dreaming about how wonderful it would be to have a new computer to add to my collection, the realization hit me that I wanted, rather than needed, the new machine. Okay, so I can't manipulate data between an Apple computer and PC at 2 A.M.; I still have that option at work.
Immediately the thought occurred to me that the more we have the more we want. I then remembered the Tenth Commandment, which admonishes us against coveting what our neighbor has. A twentieth century reading would be: "Don't think you have to have something just because everyone else has the newest, best, and fastest." After confessing my sin of covetousness, I felt purged and relieved. For you see, I discovered I'm not alone. Others fall into the entrapment of wanting more, even if they do not need it.
Computers influence our lives in day-to-day communication. Important reports, contracts, and love/hate letters no longer require days (maybe weeks) to reach their destinations. With the introduction of electronic mail, a traditional pastime bites the dust: cursing the postal service for mutilating an important document or making delivery of a letter fifty years later. We can now vent our anger for scrambled messages on the communications hardware and software. "Sorry! Your contract was routed via the lines to London. It will take two extra minutes to send your mail." Or maybe we can blame a misunderstanding in communication on a poor squirrel who happened to walk across the cross-arms of the telephone pole at the split second your message was being sent!
Due to the popularity of computers, a whole new language has developed which has widened the communication gap between the older and younger generation. When you get computer hounds in the same room with those less conversant on the subject, notice which group looks uncomfortable and feels left out. About a month ago, several friends and I went out to dinner to bid farewell to a friend. We four females got into a discussion of computers and how one could accomplish certain tasks. This friend's father, a long-time teacher of linguistics, sat in the background getting bored because we were speaking a language he couldn't understand, much less relate to.
The communication gap can be taken one step further. In any language parents beam with pride and lose all composure when Baby says "Mama" or "Daddy." Imagine their great surprise when the first words are "goto," "run," and "A>". Grandma and Grandpa will have to take a computer class in order to figure out what the grandchildren are talking about. Haven't times changed!
Sadly we must acknowledge that individuals are no longer judged only by the car they drive or the dog guide school they attended or whether they have a Southern or Yankee accent. It seems we have added the type of computer one uses to these limiting criteria. Brand X is labeled as a toy and Brand Q is hyped as the best thing to happen to mankind since someone discovered sliced cheese. We categorize people as being recreational or serious users not only by their computer brand, but by the type programs these users run. Woe be unto you if your computer software can't scrub the floors, feed and walk the dog, take out the trash, and bring in the mail. And if your computer requires two, not one, milliseconds to get all this done, why you're "stuck somewhere in the stone age of technology"!
We must remember that computers are machines and we are the ones who push the buttons. We must carefully evaluate our requirements and the task at hand before we blow a wad of money on something we'll regret later. I hope that we can re-evaluate the forces of computer peer pressure. It's getting to the point that poor souls who have no desire and no need for a computer still feel themselves in the vast vacuum of not fitting in. If any of you are tired of your current job and are searching for something more exciting and interesting, have you ever considered establishing clinics for us computer junkies who are so addicted to computers that we are no longer able to converse in a lucid manner when we blow the circuit cards inside our wonderful machines? [End of article.]
Computers generally break down when you need them most. We'd just finished several days of data entry and formatting, and we were ready to print out the final version of a report. We'd been printing portions to the screen, voice, and printer as we went along, and all was well. But when it came time for the final printout, the computer stopped, beeped, emitted a random series of letters and numbers, and finally the message, "SYNTAX ERROR".
Now what? Obviously, something was screwy with the Apple, BEX, the printer, the data, or the connections between all these things. But how do you choose where to start isolating the problem? David and I were in this predicament several weeks ago. The fact that we struggled for a long time and then came to the wrong conclusion was the impetus for this article.
I want to present some basic strategies for troubleshooting computer problems. Of course, we'd rather leave these sticky issues to "the experts"--but experts are in short supply! If you're a geographically isolated computer user, resource room teacher, or agency guru, then it's worthwhile to become an expert yourself. Even if you can't precisely isolate the problem, the techniques presented here will help you get better service from others. While my examples refer to the Apple and BEX, the techniques work equally well with other software and computers.
Troubleshooting is a see-saw process. You develop a theory of what your problem is, then design a real-world test of the theory's accuracy. The results of your test may confirm the theory, or they may send you back to refine your definition, which then needs testing again. The more precisely you can define the problem, the better you can test it.
When trouble erupts, you must fully identify what's going wrong. Write down all the players in the process that's not working. Writing things down is mandatory--it's too easy to forget one variable in the heat of testing. If it is a complex problem that you later take to someone else for diagnosis, a written description will be very helpful at that time.
Once you have your cast of characters, it's important to pinpoint their behavior. It's easy to say "My printer doesn't work," but that definition is too general to test. A more useful statement is "When I send this document to the printer, it doesn't respond--the printhead doesn't move, the printer doesn't beep, the paper doesn't advance."
This list in hand, you can decide how to test the elements to isolate the problem. Unlike the SATs, the goal of this testing is repeatable failure. A successfully operating computer is a remarkable cooperative act. As much as possible, you want to see how each player behaves in isolation. When multiple tests produce the same bad result, it's a good indication that you've found one culprit. If you have access to multiple computers, printers, interface cards, and cables you can substitute in devices you know are working to help pinpoint the guilty party. But a carefully planned series of tests can eliminate some devices through logic alone.
Let's start with a simple problem: your BEX disk won't boot. One element in the process is clearly "the BEX disk." Another element is "the disk drive." Depending on how comfortable you are playing around with the insides of your Apple, you may wish to further break down "the disk drive" into three smaller components: the disk drive box, the disk controller circuitry in your Apple, and the cable that connects the two.
Now let's focus on the behavior of the elements. First, refresh your memory about what's supposed to happen when the system is working correctly. The BEX Manuals say that a correctly booting BEX disk should whir for around 20 to 30 seconds and then prompt "Enter configuration:". Boot your BEX disk and record what is actually going on. When you turn on the Apple, does the disk drive do anything? Does it sound like the disk is being read, or is it just whirring smoothly with no disk access sound? Do you hear the dramatic gronking sound that means the drive is having difficulty reading the disk? Now turn off your computer and boot BEX two more times, noting what happens.
Having defined the players and their behavior, you're ready to determine whether the problem is the disk or the drive with a controlled test. Obtain two other bootable programs (you can use the Echo/Cricket Lessons Disk and Diversi-COPY from your BEX binder), and attempt to boot each three times, recording the results.
By comparing the bootability of three programs, you're isolating the BEX disk, but remember you need to test the drives as well. To do this, turn off your computer and open the top. Switch the disk drive cables around on the controller card so that the computer now boots from drive 2. Now retest all three programs on drive 2 and record your results.
Now you have a long list of results, and it's time to analyze them. If the Lessons Disk and Diversi-COPY boot correctly in both drives 1 and 2, then you've successfully isolated your BEX disk as the culprit. (Write a note describing what happened, pop it in a mailer with the disk, and send it to us for replacement.) If no programs boot in either drive, then there's clearly something wrong with your disk drives. If none of the programs boot in drive 1, but do boot in drive 2, then chances are good there's something wrong with drive 1. Contact your Apple service center and describe your results--they may want you to bring in your entire system for testing.
It can be a challenge to isolate what's going on with a printing problem, since so many of the parts of your system are involved in the process. Here are all the players when you print with BEX: You use the keyboard to tell BEX to print. BEX may respond by reading some special software from disk, depending on what kind of printer you have. Then BEX locates the chapter on disk and reads a portion into memory. BEX's formatter interprets the format commands in memory and composes a line of text. BEX sends the text to a printer interface card. The interface card processes the text, and then sends it over a cable to the printer. The printer receives the data and accumulates it in its short-term memory buffer. When the printer is ready to print data, it gathers it from the buffer, processes it, and moves the printhead. The printhead pushes characters or little wires through a ribbon to make ink on paper.
Before you even suspect that some equipment is malfunctioning, check all the "easy" stuff: Are all players present? Do you have your BEX disk in drive 1 and your data disk in drive 2? Does the printer number you gave BEX correspond to the printer you have in mind? (Press question mark at the Which printer: prompt.) Has some light-fingered soul made off with your printer interface card? (Use option W - What is in your computer on BEX's Starting Menu for a slot report.) Is the cable firmly connected to both the interface card or port and the printer? Is the printer turned on? Is the printer ready for data--press the "on-line" or "select" button. Many printers won't print if there's no paper or the ribbon is stuck.
Having ruled out the obvious, it's time to start isolating. Here are some BEX factors to consider: Has the printer worked correctly with BEX at some time in the past? If so, what's different now? Are you using the same BEX configuration? If so, print the old chapter that worked before and see if it still works. When the old data works, then chances are good that something is amiss with your current data. If you're using a different configuration, review it carefully with option V on the Starting Menu. Perhaps you mistyped some values in the printer setup.
Print the current chapter(s) to the screen--is the same problem showing up? If yes, then you may have some combination of commands that make BEX do unexpected things. (I once typed $$f1 where I wanted $$s1 for single spaced paragraphs. BEX obediently made a form length of 1: each page contained just one line!) Copy the (unmodified) QUANDARY chapter from your master BEXtras disk and try printing that.
Most printers have a self-test mode that outputs all its characters without any help from a computer. On the ImageWriter I and II, hold down the Form Feed button, turn the printer off and on, then let go of the button. If all the characters print correctly, then you know the printer itself is OK, leaving you to investigate the cable, interface card, Apple, and software.
It's possible to take BEX out of the loop entirely to test whether the combination of Apple, interface card, and cable is working. One approach is to use another program to print--if AppleWorks can print but BEX can't, then something is probably missing in BEX. However, you don't need to own another program.
The PR#n function built in to the Apple can send information directly from the Apple out to slot n. When your printer is connected to slot 1, then typing PR#1 <CR> at the BASIC prompt sends all subsequent output to your printer. Supposing your printer is connected through slot 2, here's how you can test the connection. Boot BEX and proceed as follows:
Enter configuration: NONE<CR>
You have booted DOS (and if you have an Echo, loaded TEXTALKER), and then told BEX to not bother anymore. The Apple indicates readiness for further instruction with the BASIC prompt.
This turns on the 80-column screen. If you want to turn off the Echo at this point, type control-E O. The Apple prompts again:
This tells the Apple to send output to slot 2. Now you need to output something. Since you have booted BEX, a portion of the software is in the Apple's memory. Type:
and the Apple starts listing the contents of memory on the screen and sends it to the printer. This printout should take up around two and one-half pages. If there are problems with this printout, you have narrowed down the area of investigation to the interface card, cable, and printer combination.
While I could literally fill the entire Newsletter with more techniques for printer troubleshooting, I think I'll stop right here. In November 1985, Open-Apple magazine published an outstanding special issue devoted to the topic of untangling printer interfaces. You can obtain just Volume 1, Number 10 for $2, or annual bound back issues for $14.95.
Recalling our pickle recounted at the start of the article, we went through all the tests above and then some and still couldn't find the problem. Since we have a lot of equipment here at RDC, we were able to substitute a known working printer, a known working BEX disk, a known working interface card, and a known working cable--and still the darn chapter wouldn't print. We reviewed the players in the process: When printing, BEX is processing data in the Apple's memory. On a wild guess, we replaced the chips on the Apple's 80-column card, which seemed to solve the problem. It has since reappeared--perhaps the card itself or the slot it plugs in to is the real culprit.
If you are able to approach your computer problems in a calm and thoughtful manner you are probably more likely to get them solved. I know that many of our readers are capable of solving problems of this nature themselves. Whether or not you are able to fix these problems at the chip level, it is certainly satisfying to be able identify and isolate those elements which are so often frustrating. Being able to take your memory board into your repair shop and asking them to check things out is a lot less frustrating than lugging your entire system in and saying "Something's wrong." It is a lot more helpful for the repair person as well.
But being able to identify how your system works and what isn't working right is most rewarding to you. Learning to work comfortably with your computer and have confidence in your knowledge and abilities is what it's all about. [End of article.]
Daveed Mandell of Berkeley, CA is cleaning out his Apple closet, at bargain prices. All items are in mint condition; all prices include UPS ground shipping to your door.
Speech synthesizers (with speakers and disks): Echo II: $90 (two available); Echo Plus: $110; Echo GP: $170; APH Echo Commander (brand new): $190; Cricket: $110.
APH Talking Apple Literacy Teacher's Kit (software, manuals, & computer models): $90.
Apple Peripherals: Apple Super Serial Card: $130 (two available); Null modem cable adapter: $30; Hayes SmartModem 1200 (with serial cable): $200; Thunderclock; $90; monochrome amber monitor: $100; Comrex Comwriter C1 18 cps daisy-wheel printer (with parallel cable): $300.
APH Model 3-5194 tape recorder (need repair): $100 (two available).
Contact Daveed Mandell at 415-644-3180 or write 1815 Derby St., Berkeley CA 94703. [End of article.]
6140 Horseshoe Bar Rd.
Loomis, CA 95650
5 South St.
Rydalmere 2216, Sydney, Australia
U.S. Phone c/o HumanWare: 800-722-3393
Kurzweil Personal Reader
Kurzweil Computer Products
185 Albany St.
Cambridge, MA 02139
Telesensory Systems, Inc.
PO Box 7455
Mountain View CA 94039
PO Box 11250
Overland Park KS 66207
Nevin Olson, RDC's Business Manager, makes oak furniture in his spare time.
Jesse Kaysen, RDC's Publications Manager, is umbilically attached to her Mac's mouse.
When Phyllis Herrington is not doing Technical Support and writing for RDC, she helps foreign students make sense of Madison.
Claire Whiskel is a back-up consultant for sticky technical support questions at RDC: she worries and wrestles thorny problems like a dog with a bone.
David Holladay founded RDC in his spare time in 1981. He no longer has any spare time.
Phyllis Herrington, Technical Support; David Holladay, Programming & Janitor; Jesse Kaysen, Publications; Caryn Navy, Programming; Nevin Olson, Business Manager; Becky Rundall, Sales Manager.
The RDC Newsletter is written & edited with BEX on an Apple IIgs; file transfer with BEX, ASLtalk DA, QTC & Apple File Exchange to Mac Plus; spellchecking with Spellswell; page layout with JustText, offset master output on an Apple LaserWriter & duplicated at The Print Shop. Two-track audio edition mastered on APH Recorder & copied on high-speed Recordex 3-to-1 duplicators.
Apple Computer, Apple IIc, Apple IIe, Apple IIgs, Apple II+, DOS 3.3, ImageWriter, Macintosh, ProDOS, and Super Serial Card - Apple Computer Inc.; IBM-PC - International Business Machines, Inc.; MS-DOS & PC-DOS - Microsoft Corp.; BEX & Hot Dots - Raised Dot Computing, Inc.; Cricket, Echo Plus, Echo II, Echo GP, & TEXTALKER - Street Electronics Corp.; Optacon II - Telesensory Systems, Inc.; WordPerfect - WordPerfect Corp.; Kurzweil Personal Reader - Xerox Corp. [End of article.]