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. Guest Editor: Becky Rundall
Entire contents copyright 1987 by Raised Dot Computing, Inc., All Rights Reserved. Nothing may be reprinted in any mdeium--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 = Table of Contents (print page 1)
CORRECTION = LaserLines from the Editor; Correction: Centering Long Lines on Title Pages (print page 2)
OHTSUKI BUG FIX = Why Ohtsuki Doesn't Back-translate Correctly with BEX and How to Fix It -- Caryn Navy (print pages 2-3)
(The next four chapters comprise the "Joy of TranscriBEX" Column:)
TBEX BRL K-B = Braille Keyboard & the Apple IIgs (print page 3)
TBEX INDEXES = Improving TranscriBEX's Indexing Commands -- Conchita Gilbertson (print pages 3-4)
TBEX BOLDFACE = Semi-automatic Braillle Boldface Indicators -- Caryn Navy (print pages 3-4)
TBEX SIM BRL DOTS = Simulated Braille with Dipner Dots -- Ken and Diann Smith (print pages 5-6)
USING RAMDRIVES = Speeding Up BEX with RAM Drives -- Richard Wright (print pages 6-8)
BEX TO KEYNOTE = Transmitting Files Bewteen BEX and the Keynote -- Caryn Navy (print pages 8-10)
TROUBLESHOOTING = Your Ticket to Better Technical Support -- Phyllis Herrington (print pages 10-11)
NJ TECH AIDS PROFILE = New Jersey Commission Responds to Technical Explosion -- Becky Rundall (print pages 11-13)
HINES VA PROFILE = Access to Technology for the Blind -- Joanne Barsanti (print pages 13-16)
DATA RECOVERY TRICKS = BEX Data Recovery Techniques -- Jesse Kaysen (print pages 16-23)
PUBLICATIONS = Publications on Interest (print pages 23-24)
BLIND PROOFREADERS = Braille Proofreading with BEX -- Fareed Haj (print pages 24-26)
MISC ANNOUNCE = Announcements (print pages 26-27)
FACTS ON FILE = Names & Addresses Mentioned in this Issue (print page 27)
MASTHEAD & TMS = Who's Who at RDC, Inc.; Trademarks and Copyrights (print page 28)
The bad news about this issue is that it's a little late. The good news is that it's twice as thick. We have a pleasant variety of articles, and we're sure there's something for everyone in this double issue. The reason it's late is that I've been buried deep in the bowels of a Top Secret Project. Thank heavens for Becky Rundall! Our shipping manager is also a long-time wordsmith, and she graciously agreed to take on the task of editing this double issue.
I do want to take this opportunity to encourage you to submit an article for the Newsletter. We're eager to publish your thoughts, be they technical, philosophical, or humorous. If you can submit your masterpiece on MS-DOS, DOS 3.3, or ProDOS disk, so much the better.
When I edited this article, I introduced a misstatement of fact. In the ninth paragraph, at the bottom of print page 5, it asserts that the Code of Braille Textbook Formats and Techniques "requires that the bottom line of the title page should contain just the page number, in this case, p#a." This is wrong!
Rule II, section 6 of the Code clearly states that the last item on a title page should be the print pages included in that braille volume. It's clear from Models 1, 2a, 2b, and 3 that the bottom line of a title page must contain both the included print pages and the preliminary braille page number.
Your editor offers her sincere apologies. I hope I haven't confused anyone too much, and my thanks to Gloria for her eagle eye.
The Ohtsuki brailler has a built-in back-translator that changes grade 2 braille to inkprint. So the Ohtsuki has the unique ability to simultaneous produce braille and print copies when it's sent a grade 2 file.
However, there is an idiosyncrasy in the Ohtsuki's back translator--it ignores all lowercase letters. For example, when the Ohtsuki receives <eo> FIX$ </eo> it brailles the four characters <eo> fix$ </eo> and prints the word fixed. But if the Ohtsuki receives <eo> fix$ </eo> it brailles <eo> fix$ </eo> but only prints ed.
To compensate for this problem, we make BEX send out only uppercase letters when brailling to the Ohtsuki. Unfortunately, the latest edition of BEX fails to send uppercase characters to the Ohtsuki. Fortunately there is a reasonable way to cope with this glitch.
To get proper grade 2 braille and print output on the Ohtsuki, you must include the BEX command $$su in your data. This commands sets uppercase output; all letters are uppercase, but the letters in your format commands are still lowercase, so they still work.
It's important to place $$su in the right position. You must place the four character command $$su before the beginning of your text.
However, we're not out of the woods yet. There are five commands which cancel the effect of the $$su, so you must repeat the $$su after any use of these commands. They are $$d (reset all parameters to their default values) and the major format commands of TranscriBEX: \\bookformat and \\textbookformat.
A simple remedy is to create a chapter called FIX on your Main program disk. This chapter should consist of only the five characters $$su and a space. When you are sending braille chapter(s) to the Ohtsuki, specify 1FIX as the first chapter, then specify the rest of your grade 2 files. (Because you precede the name FIX with the digit 1, BEX finds it on drive 1.) Avoid using the $$d command (or if you do, follow it with a $$su command).
If you use TranscriBEX with the Ohtsuki to get braille and print, remember to type $$su after every major format command: \\bookformat and \\textbookformat. It is also possible to build the $$su into your MAKE$ and ALL$ transformation chapters. Call Caryn Navy at the tech line for details.
As we mentioned in the June issue, BEX's braille keyboard mode won't work on the new Apple IIgs keyboard. We've contacted Apple about this problem, and we know now that the IIgs keyboard won't ever be able to support BEX's software-only braille keyboard mode. (Bob Stepp's ED-IT program is similarly affected, since we both use the same routines to allow six-key data entry.)
So the bad news is: Transcribers wanting braille data entry need a separate braille input device to work with the Apple IIgs. However, there's some good news as well. Your Apple dealer can do a performance upgrade or board-lift that changes your Apple IIe to a IIgs. Almost every chip inside the Apple IIe is replaced in this process; this born-again IIgs has all the same power as the newest member of the Apple family. However, the performance upgrade does not change your Apple IIe keyboard. Therefore, you still have braille keyboard mode. A performance upgrade to the IIgs is the best of both worlds: more power, same old keyboard.
Everyone everywhere must know by now what a strong proponent I am of RDC's software. However, even RDC can't anticipate occasional problems which we transcribers encounter.
Recently, I experienced some difficulties with the indexing commands. The material I was transcribing may have been a bit out-of-routine, but I don't believe so. The index contained two kinds of entries: many entries had various levels of sub-entries, while other entries where only at the main level. Several instances required a new paragraph within a third sub-entry level entry. To complicate matters a bit more, blank lines were needed within some of the main and sub-level entries.
The problem was, when I used ($p) and ($s) within an entry, the indent was wrong. I wanted cell 5; I got cell 1. Now that we have reached mind-set, let's see how to solve these dilemmas.
And as long as I'm on the topic of indexes: Page 11-2 of the TranscriBEX Manual describes simple index data entry as follows:
BEX's Grade 2 translator recognizes BEX's own underlining commands. So both begins underlining in print, and marks the beginning of braille italics. Likewise, finishes underlining and ends braille italics. When the translator encounters , it begins placing braille italics signs (dots 4-6, the period in screen braille) before every word. When the translator encounters, it stops placing italics signs. When the underlined passage is greater than three words, then the first word gets a double italics sign (two dots 4-6s or two periods in screen braille) and the last underlined word has a single italics sign.
With TranscriBEX, you use and to take advantage of the translator's ability to place italics signs. (MAKE$ changes to and to.)
Braille italics are used to represent various typeface changes in inkprint. But with some books, the braille reader must be able to distinguish between three typefaces: plain, italic, and bold. For this situation, TranscriBEX includes a boldface indicator that you enter manually. Placement of boldface indicators follows the same rule as italics indicators. Three or less bold words each begin with the single boldface indicator () greater-than, underbar, period. The first word in a passage longer than three begins with the double boldface indicator () greater-than, underbar, two periods, and then the single boldface indicator precedes the last bold word.
When you make extensive use of boldface in transcribing a particular book, it's time-consuming to place all those boldface indicators by hand. I've found a way to enlist the translator's aid in placing these indicators. First I'll just give you the bare step-by-step instructions; after that, I'll explain what's really going on.
You create two new \\ commands for boldface braille. \\bb begins boldface; \\bf finishes boldface. To activate these commands, you must add to the list of transformation rules in MAKE$ and ALL$.
Once text containing these commands is transformed with MAKE$ and then translated, you use a contextual transformation chapter that places the boldface commands where appropriate.
Step 1: Modifying MAKE$.
Create a new chapter in the Editor. With your cursor at position 0, erase any text on the Clipboard by entering $$eb control-B S $$ec immediately followed by $$eb control-B C. $$ec Type the following characters exactly: <eo>
</eo> Now enter $$eb control-B X $$ec to exchange the current page with the Clipboard. Quit the Editor.
Copy MAKE$ to a chapter named MAKE$ BOLD. Edit MAKE$
BOLD. With your cursor at position 0, enter $$eb control-L
Step 2: Create contextual transformation chapter
Edit a new chapter named PLACE BOLD. Type the following characters exactly: <eo>
</eo> In this sample, <CR> stands for the single carriage return character; <space> stands for the single space character. Quit the Editor.
Step 3: Enter the \\bb and \\bf commands in your data
Precede the first boldface word with \\bb wherever you want boldface indicators in braille. Finish up boldface by entering \\bf after the last boldface word.
Step 4: Add one step to TranscriBEX process
After you have created the grade 2 braille chapters, you must use Replace characters with PLACE BOLD as your transformation chapter. You may use PLACE BOLD and then FINETUNE, or you can use FINETUNE and then PLACE BOLD. (If you've dipped into the Master Level, you can write an auto chapter that does both transformations.)
The \\bb command is transformed to two BEX format commands: begins underlines; $$eb begins boldface. Similarly, \\bf is transformed to finish underlines plus $$ec finish boldface. The translator ignores the $$eb and $$ec commands; but because the and commands are there, it places italics signs as always.
The PLACE BOLD transformation chapter changes italics signs to boldface signs. Because PLACE BOLD is contextual, it can use on and off strings. The on and off strings prevent every italic sign from changing to boldface. The on string is $$eb and the off string is$$ec. This means that the only time italics signs are changed to boldface signs is when the italics signs appear between $$eb and$$ec.
The $$eb and $$ec commands are designed to turn boldface on and off when BEX is printing to a class S - Specific printer. BEX's formatter knows that braillers can neither underline nor do boldface. When you print your final grade 2 chapters to the braille previewer or an actual brailler, BEX suppresses the action of all ,, $$eb, and $$ec format commands.
A textbook which has been translated into braille should be reviewed for accuracy following textbook format. For example, tables should be on separate pages, columns in tables must be properly aligned, runovers should be in their correct location relative to the previous line. This means you must proofread your braille text.
For sighted proofreading, simulated braille printed on draft-quality paper is an inexpensive way to see the entire layout of a braille volume exactly as it will appear when it is embossed on more expensive braille paper. The simulated braille copy can be marked up by the proofreader for use in correcting the original BEX chapter files.
Section 12 of the Interface Guide discusses Dipner Dots, a method of creating draft quality braille on a daisywheel printer. Page 12-3 mentions printed Dipner Dots in passing, but only in reference to daisy wheel printers. BEX can easily produce simulated braille on dot matrix printers with graphics capability.
The BEX configuration dialogue for an Epson (FX-85, MX-100, etc.) printer is as follows: <eo>
Enter printer class code: B
Enter brailler code: 13
That means Dipner Dots printed.
Is that what you want? Y
What character are you using? o
</eo> That's a lowercase letter o. You must release your Caps Lock, press o, then click down your Caps Lock again! <eo>
Enter carriage width: 40
Enter form length: 25
Do you want a pause after form feed? N
Do you want auto line feed? N
Do you want to give an automatic set-up sequence for Printer? Y
Set-up sequence: <Esc> A Control-E Control-O <Del> </eo>
That's just five characters; the spaces are there for readability only. Remember that the keys do not echo during the set-up, so you just have to have faith.
Let's decipher these codes. <eo> <Esc> A </eo> means set printer ready to receive line space value. Control-E sets the line space equal to 5/72 inches. Control-O turns on condensed printing. And finally, <Del> tells BEX you're done entering the set-up sequence.
The same thing can be done on the original Apple ImageWriter printer with the following set-up sequence: <eo>
<Esc> T 12 <Esc> Q <Del>
<eo> <Esc> T </eo> means set printer ready to receive line space value. <eo> 12 </eo> sets line space equal to 12/144 inches. <eo> <Esc> Q </eo> means set ultra-condensed printing, and again <eo> <Del> </eo> signals the end of the sequence.
For other printers, check the index for controlling vertical line spacing and invoking condensed print.
When you use option V - View a configuration to look at this configuration, you may be surprised when BEX displays the automatic set-up sequence. The characters you enter appear at the end; the earlier characters are what BEX sends to the printer to do Dipner Dots.
As a faster alternative to simulated dots, you can use the braille previewer, introduced on pg. 7-2 of the TranscriBEX manual. Admittedly, the braille contractions in screen braille can be disconcerting, but it doesn't take long to become proficient in reading screen braille. Although only 24 lines appear on the screen at a time, you can access line 25 by just pressing the down arrow key.
However, it's difficult to keep track or make notes of when to make changes since you cannot mark on the screen as you can on paper, and you may not always have your computer nearby.
[Editor's note: You can get a hard-copy of the braille previewer output by configuring your inkprint printer as a Thiel with a character width of 41 and a form-feed of 25 (or whatever format you need). Each braille page only occupies the upper lefthand corner of the paper, so you have plenty of room to make notes.]
As I read the April issue of the RDC Newsletter, I became quite excited over the article describing the use of RAM drives for temporary storage. As a BEX user who also uses a number of MS-DOS memory resident programs, I have often found myself wishing that all of the files used by BEX could be kept in memory. Some operations, especially those involving a lot of disk access, can seem interminable.
When I read the article on RAM drives, I couldn't wait to utilize what seemed to me to be equivalent to a free update to BEX.
I have had a RamWorks card with one megabyte of memory from Applied Engineering for approximately eighteen months. While using this memory to process large AppleWorks database files, I have often wished for additional applications. Now I found myself with an opportunity to get more use out of my RamWorks card and to significantly speed up BEX.
As soon as I finished reading the article, I began the process of installing the Ram drive software. In spite of my eagerness to use the software, I did take one important precaution. I used one of my three opportunities to copy BEX to make a copy to be used with the Ram drive software. I reasoned that although the instructions were very straightforward, and although I am an experienced computer user, Murphy (as in Murphy's Law) is alive and well and hanging out around my office.
Once the copy of BEX was made, I proceeded with the instructions exactly as given in the article. Once line 15 of the program had been written and the hello program had been saved, I rebooted BEX. To my horror, there was no familiar synthesized voice telling me to enter a configuration. The computer had stopped with a copyright message for the Echo software on the screen. I rebooted the computer with exactly the same result. Several thoughts went through my mind at this point. I had a crippled copy of BEX. On the brighter side, I still had a working copy since I had the presence of mind to make another copy prior to beginning the installation.
In only a mild state of panic, I called the RDC support line. Although Phyllis could offer no immediate help, she promised that someone would get back to me. Shortly, I received a call from David Holladay. He asked me what version of the RAMDRIVE program I had installed. I was able to tell him that it was version 3.3 rather than version 5.3.1, which had been specified in the article. Between the time that the program had crashed and David had returned my call, I had reread a portion of the article and had begun to wonder if the version number could make all that much difference. It does. David suggested that I load the HELLO program from a working copy of BEX and save it on the non-working copy. Alternatively, I could have used DOS 3.3 to load the HELLO program from the non-working disk and delete line 15 (which runs the RAMDRIVE program) prior to saving HELLO. In any case, it was necessary to get access to version 5.3.1 of the DOS 3.3 side of the RamWorks software disc and repeat the installation procedure.
Are RAM disks worth all the trouble? You bet! One of my primary uses for BEX is in reformatting and doing Braille translations of documentation downloaded from our mainframe. Since installing the RAM drive software, I have processed five fairly large files. I would estimate that my applications have been accelerated somewhere between 700 and 1000 percent depending on the particular operation.
While my experience with RAM disks is limited, I have already learned one precaution which RAM disk users should pay attention to. I am using five 737 sector RAM disks. When running a series of files through a sequence of operations, it is easy, and probably wise, to start with the highest numbered disk and route the output to successively lower numbered disks. If, for example, a contextual replace chapter behaves in an unexpected way, you can always go back to the copy you had before that chapter was used. The precaution I have about this type of operation is that it is very important to keep track of the drive number you used for each operation. So far, I have been writing these down, though if someone has a better suggestion, I am eager to hear it. The problem occurs if you are working on files and get interrupted. Two versions of the same file or of a set of files can look a lot alike.
Of course, if you are using virtual drives in descending order and have not used all of them, you can always use the directory command to find out where you left off. The problem occurs when you start to cycle through the virtual drives a second time.
Finally, as the article says, it is a good idea to periodically save files to a floppy disk. All the time you saved with the greater speed of RAM disks can be lost, literally, in a blink of the powerlines.
Having recently transferred files between BEX and the Keynote, Sensory Aids Corporation's portable talking computer, I thought I'd pass on the process. First, make sure you have the following items:
BEX Version 2.2
Modem Cable for Keynote
Apple Super Serial Card or
Keynote to Apple IIc cable
You must have BEX Version 2.2. because earlier versions lose characters when receiving files from the Keynote--they cannot perform "hardware handshaking" while inputting text. If you do not have BEX 2.2, contact RDC about getting an update.
You'll need a "706" cable (also know as the modem cable for the Keynote) from Sensory Aids Corporation. It has an 8-pin circular DIN plug for the Keynote and a 25-pin (DB25) male end for the Apple. Raised Dot Computing does not stock this cable. If you're using an Apple IIc, you'll also need a 2F cable from RDC. Plug the circular end of the 2F cable into port one of the Apple IIc, and plug the other end into the Apple end of the 706 cable.
You must create a BEX configuration to allow communication with the Keynote. To enable BEX to receive material from the Keynote with Input through slot, you must answer the "download device" questions appropriately.
Although the Raised Dot Computing standard setting for the Super Serial Card and the Apple IIc is 9600 baud, you must tell BEX to set the appropriate baud rates to 4800--that's the highest at which the Keynote can send or receive. Answer Y when BEX prompts: Do you have a device to download text? Answer Y to the Kurzweil question. Because BEX thinks the Keynote is a KRM, it automatically sets the baud rate to 4800 just before receiving input.
To send material from BEX to the Keynote, you establish a printer in your configuration which is really the Keynote. Give the slot number for the Keynote and ask for class G (generic) printing. Give a carriage width to your liking and a form length of zero. Answer N to the questions about pause on form feed and auto linefeed. Answer Y to the question about an automatic set-up sequence. If you have a Super Serial Card, give a five-character sequence of: <eo>
Control-I 12 B <CR> <Delete>
</eo> If you have an Apple IIc, give a four-character sequence of: <eo>
Control-A 12 B <Delete>
</eo> Now BEX automatically sets the Super Serial Card or the Apple IIc port to 4800 baud just before sending the material to the Keynote.
If you have other devices sharing the same Super Serial Card or IIc port as the Keynote, and you want to use such a device at 9600 baud, you must tell BEX to go back to 9600 baud. In telling your BEX configuration about such a device, answer Y to the question about an automatic set-up sequence. If you have a Super Serial Card, give a five-character sequence of: <eo>
Control-I 14B <CR> <Delete>
</eo> If you have an Apple IIc, give a four-character sequence of: <eo>
Control-A 14B <Delete>
Use the Input through slot option on BEX's Second Menu. BEX prompts for the name of the chapter you are creating on the Apple. When you supply the name, BEX says "Start device".
On the Keynote, copy into memory the file you want to transfer. Press C to get into the Communications Menu. Then, choose S for Set Up Options. Set the first parameter, "communications code", to "68N2B". To make this change from the default of "68N2F", you must type "68N2B". For "transmit delay", choose "0", the default. For "transmit end of file character", choose F for off. For "paragraph or line format", choose P for paragraph. For "transmit linefeeds", press F for off. For "communications type", press return for "standard". When the parameters are set right, press the quit button to return to the Communications Menu.
At the Communications Menu, press T to select the transmit file option. The Keynote prompts for the name of the memory-based file to transmit. It then prompts "Host command to receive file:". Just press return. The Keynote then prompts "Press return when host is ready". Assuming you already got the "Start device" message from BEX, press return on the Keynote. BEX makes a continuous tone when it receives text at 4800 baud. There will be pauses when BEX saves pages to disk. When the Keynote has finished sending data, it prompts "Communications Menu". Press Q on the Apple to tell BEX the transmission is over.
There are several ways to send a file from the Keynote to another device. We have selected the Keynote's "transfer file" option with "paragraph format" because it does not send "line breaks" to BEX. These are the "soft carriage returns" that the Keynote places automatically throughout your text in accordance with your chosen Keynote margins. With this type of transfer, only the carriage returns you have typed are sent to BEX. This includes "new line" (single carriage return) and "new paragraph" (double carriage return). On the Apple you may use Replace characters to change double carriage return to the BEX paragraph symbol (space, dollar, lowercase p, space). If your familiarity with both systems and your circumstances allow, you may use a different method for sending files to BEX.
Formatting is different on BEX and on the Keynote in all cases. There is no universal way to automatically get a perfectly formatted Keynote file from a perfectly formatted BEX chapter. One option is to use Replace characters to change the BEX paragraph symbol to two carriage returns, and place $$z at the beginning of your BEX text. On the Keynote change BEX $$ commands to their Keynote replacements. There is also a simpler option when the only formatting is paragraphs and centering. Just place $$l0 (dollar, dollar, lowercase L, 0) at the beginning of your BEX text, and do not include $$z. Then BEX will send the Keynote two carriage returns for every paragraph symbol, but no other carriage returns. It will also send out multiple spaces for centering.
Prepare the chapter(s) to send to the Keynote. Use the Print option and select the appropriate chapter(s). Before selecting the appropriate printer, you must get the Keynote ready to receive text.
Press C on the Keynote to enter the Communications Menu. Press S for Set Up Options. For "communications code", choose "68N2F". Note that this is different from sending to the Apple, as the last character is F instead of B. Press the quit button to get back to the Communications Menu. Press R to select the Receive file option. The Keynote prompts for the file name and lets you replace or append to an existing file. It then prompts "Host command to receive file:". Just press return on the Keynote. The Keynote then prompts "Ready to receive". Enter your printer number and return on the Apple. The Keynote clicks to tell you it is receiving data. When BEX returns to its Main Menu and the Keynote stops clicking, press the Keynote's Main Menu button.
When you purchase RDC programs and mail in the registration card, you receive your "ticket" to technical support. This ticket enables you to receive the answers to the questions you may have concerning your program. However, there is some troubleshooting you can do before you call us which might save you a call and money. Even if you are apprehensive about troubleshooting on your own, there is information we would like from you which will expedite technical support.
When you call, please have on hand the name of the individual to whom the program was serialized, your zip code, and the serial number of the program. We will ask for this information. Also, check the switch settings of your printer, and Super Serial Card (SSC). This is especially important when you call because of a printer problem. But before you pick up the phone or pen and contact us, try a little troubleshooting on your own. You will surprise yourself with your ability to figure out the problem.
Problem: I'm trying to print a document using Hot Dots and I don't get any output.
Solution: Check to make sure the interface is correct. Don't set up your brailler for serial printing when the device is parallel. If the embosser is serial, make sure the COM port and LPT have been set correctly.
Problem: My printing device and the computer aren't communicating. The printer is serial and I cannot get any output.
Solution: Check the switch settings on the SSC to ensure they are set at RDC's standard switch settings. You can find these in the Interface Guide. When you are using BEX or TranscriBEX, you can easily determine whether these settings are correct by using option W - What is in my computer on the Starting Menu. You will be told what is in each slot, as well as whether or not the SSC is set at the standard switch settings.
If the switch settings are correct, check the dip switch settings for the printer. They need to be set for 9600 baud, 2 stop bits, 8 data bits and no parity. For the VersaPoint, Thiel and Romeo, the set-up configuration must also match the SSC.
If the switches for the SSC and the printer match, but you still aren't getting any output, see if the cable is secure between the printing devices and the computer. Make sure the cable you are using is the proper one. This last suggestion may insult your intelligence, but here goes: make sure the printer is plugged in and ready to go!
Problem: When prompted for a printer number, I give a number but nothing goes to the printer.
Solution: When you are prompted for a printer number after you've chosen chapters for printing, the printer number corresponds to the order you defined the printer in your configuration. It's a common mistake to enter the slot number instead of the printer number. When BEX prompts "Which printer:" you can enter question mark, <CR> to get a reminder of how you configured your printers.
Problem: I'm getting double-spacing between lines, and I didn't issue formatting commands for double-spacing.
Solution: The probable culprit is you answered yes to auto linefeed when you were setting up your configuration. Ninety-nine percent of the time you want to answer no to the auto linefeed question. The exception to this hard rule is large print. If you answered no to auto linefeed in BEX, there are two other places to check. Most printers and printer interface cards can also generate auto linefeed. You only want one device adding linefeeds, so check the settings on the printer and the interface card.
Problem: I configured for large print, but I am not getting linefeeds. The printer is writing on top of the line when for each swipe.
Solution: For proper execution of large print, answer yes to <eo> Do you want auto linefeed? </eo> This situation is the single exception to "no auto linefeed" rule above.
Problem: VersaBraille transfers are not working.
Solution: Check the overlays: they must match the direction of transfer. Do you have the TO VB loaded for option T - Transfer to VersaBraille? Or do you have the FROM VB overlay for option F - Transfer from VersaBraille? Look at Section 8 of the BEX Interface Guide for more information about overlays.
If the overlays prove correct, check the cabling. Do you have the proper cable for your particular VersaBraille model? If so, is the right end connected to the right device?
Please use your ticket to technical support. We are here to help make your use of computers and software enjoyable and productive. I would like to remind you that you must first register your BEX, TranscriBEX or Hot Dots programs before we can offer either telephonic or written assistance.
We are receiving more and more disks for analysis, which is good. Sometimes it's hard to describe a problem over the phone, but it makes perfect sense once we look at the disk. However, when you send a disk, please enclose a note informing us of the nature of the problem. Chances are we have spoken with you over the phone, but as time elapses between phone calls and the receipt of the disk, our minds go blank.
Have fun with your computer and trust your instincts. Don't be afraid to do a little troubleshooting. You could save yourself a few bucks.
I recently managed to catch an extremely busy Pete Rossi on the phone long enough (during his lunch hour) to query him about the Technical Aids Center at the NJ Commission for the Blind and Visually Impaired. Pete is supervisor of the Center, and because we've been working with him since the Center's inception 2-1/2 years ago, we were curious about how it got started and just what he does there.
The Commission was faced with an ever-increasing barrage of software and high-tech devices for the blind and visually impaired. The resulting confusion over what to recommend to clients led the Commission to established the Technical Aids Center. Its mission is to serve as a resource for both staff members and clients, as well as for potential employers of blind and visually impaired people. As a result of training at the Center, the Commission staff, consisting of vocational career counselors and regional office staffers, has become more "literate" in the adaptive equipment field. However, the early trend of a 50/50 counselor-to-client training ratio is shifting--these days, the Center is training more clients than counselors. And, as if training all of those people weren't enough, the Center's staff also makes appropriate equipment recommendations for clients and screens equipment requests prior to state fiscal approval.
The Center, which opened in early 1985, handled 31 cases involving the recommendation of specific equipment to clients during their first year. Their second year saw a whopping increase to 94 cases and around $300,000 of recommended equipment. They've trained 121 vocational and 10 non-vocational staff members and have hosted 120 visitors, including employers, teachers, and just plain interested folks. All of this in an area which has been expanded from 300 to 800 square feet since the Center's beginning, by a staff which has grown from one person one day a week to three full time people--Pete, Kathy Mercado and Lori Converso. All three work hard evaluating what Pete calls his "zoo" of adaptive equipment, consisting of "one of everything."
The Technical Aids Center offers numerous one-half to one-day courses, ranging from general informational classes about computers to workshops on specific devices. "Introduction to Computers 101" is a small-group, hands-on training course in which participants learn about everything from disks to the internal workings of Apple and IBM personal computers. Moving on to "Introduction to Computers 201," they receive individualized training, employing FlipTrack cassettes, disks and even videotaped "tours" of the PC and the Mac.
We were pleased to learn that courses in BRAILLE-EDIT and BEX (as well as around ten other special purpose Apple and PC-compatible software programs) are offered, both in small group format and individually as training becomes more intensive. Further classes involve training on VersaBrailles, large print monitors, braille embossers and various speech devices.
In addition, the Technical Aids Center has worked closely with the Commission's Textbook and Materials Center in the production of braille textbooks. The State of New Jersey supplies equipment to Red Cross-trained volunteer transcribers. Out of around 55 Library of Congress-certified volunteers, 21 have purchased their own Apple computers. Using Bob Stepp's ED-IT program, they and the volunteers transcribing by hand have produced the Center's 360 permanent titles and 600 titles sold through both the Red Cross and the American Printing House for the Blind.
So kudos to Pete Rossi and staff at the Technical Aids Center for dispelling the smoke surrounding the recent explosion in adaptive equipment technology. And best wishes to Pete in his new position at the American Foundation for the Blind in NYC. You'll find him there, hard at work, beginning in September.
[Editor's note: Ms. Barsanti does free-lance writing primarily for computer people, focusing on Chicago-area companies and what they're doing with technology. A slightly different version of this article appeared in a Chicago-area magazine. RQR]
In an excerpt from their article "Computer Access by the Visually Impaired, Is It Still a Dream?" Harvey Lauer and Leonard Mowinski summarize the raison d'etre of the Technology Transfer Division of the Veterans Administration Blind Center in Hines, IL: "When sighted people used only books, typewriters and filing cabinets, well-trained blind people could compete with the tools at hand, namely, the use of braille and tapes. Now that people study, write and file with computers, we can no longer compete with only our braille and tape equipment."
As Mowinski describes it, the idea of blind people having access to computers became a kind of a "hot potato" with the VA about five years ago. Mowinski's colleague, Lauer, who is blind, relates the "birth" of the Technology Transfer Department: "I was teaching braille, and was doing research to evaluate braille machines. The other researchers had computers and I couldn't keep up with them." When he bought an off-the-shelf Apple computer, added a speech synthesizer card and some word processing software designed for the visually impaired, he found that he could now keep up with his colleagues and crank out the research. The serendipitous result was that Lauer's superiors became more interested in the computer devices than in his research, and the outcome was the Technology Transfer Department.
Although Mowinski avers, "We are not computer people," the two Technology Transfer Specialists demonstrate an impressive proficiency with a variety of computer hardware, software packages, specialized devices for the blind and visually impaired, and a complex set of interfaces among all of the above. And like most "computer people," they have acquired a sense of humor and a healthy dose of cynicism which comes from working with developers of hardware and software in an industry he aptly describes as "a moving target."
If the department's beginning was simple, the challenge faced by it today is not, for it must marry a complex and constantly changing technology with an end user group whose only common denominator is its wide variance in computer sophistication, access to technical advice and assistance, and degree of physical and environmental limitations.
The Technology Transfer Department and the two men who run it illustrate this challenge on a number of different levels: they use the technology themselves; they research, test, and evaluate new technology both in its developmental stages and as it becomes available to the public; and they provide advice, assistance, and training for vision-impaired veterans. Let us take a brief look at each of these areas.
The software roughly divides into two categories: special purpose software which is designed specifically for the visually impaired; and interface programs which work with off-the-shelf software normally used by sighted people. A typical example of the former is BEX, a word processor developed by Raised Dot Computing, Inc. of Madison, WI for Apple computer users. This product is used by Lauer in both his research and teaching work at the Blind Center. With it, he can select large print in several sizes, translate back and forth between braille and print files, and generate output in either braille or print. He uses a standard Apple keyboard, although it can also be set up to use a braille input device.
This first type of software, through its translation capabilities and duel output mode, facilitates work-sharing between the blind and their sighted co-workers. Since Mowinski and Lauer coauthor a variety of articles and papers, and since the former does not read braille and the latter cannot see the printed text, it provides an invaluable tool for their research efforts.
The second type of software, often referred to as "screen access software," works with the application (e.g., the word processor) and a voice output device to provide audio feedback on the information displayed on the screen.
The Blind Center uses this type of software on both the Apple and the IBM. Lauer demonstrates them both. He puts them through their paces, showing how he edits his work--paragraph by paragraph and then sentence by sentence, "skimming" through the text. When he reaches a crucial area, he slows it down and switches to a word by word review mode, and finally he spells out a word which doesn't sound quite right.
A slight raise in pitch for words that begin with a capital letter provides an interesting cadence that avoids a monotone effect. Even with an occasional odd pronunciation, it is fairly easy to listen to. Mowinski and Lauer concur, stating that on the average, it takes about six hours to get used to this type of product.
While both the Apple and the IBM are used in the Blind Center, the former seems to have the edge. Mowinski explains, "Because the Apple architecture is more easily adaptable, it is easier for people to develop software and peripheral devices for that machine . . . You find a lot more specialized software written for the Apple." Another advantage of the specialized software is that its documentation is usually available in some combination of braille, large print, or audio cassette.
On the other hand, most of the software written for the IBM is designed to give the user access to widely used software products. The advantages are obvious: it opens up a whole new world of computing power via the abundance of data base, word processing, and spreadsheet programs that exist for the PC and its compatibles. Keyboard macros increase efficiency and compensate for the inherent visual orientation of general use software. But that efficiency comes at a steep price. "You have to write a lot of macros to make it transparent to the user," Lauer explains, and then adds, "the mountain to climb is three times higher with the IBM than it is with the Apple."
The added learning time is one factor; another is the level of expertise required to install and configure multiple layers of software, a process which is exacerbated by the highly dynamic nature of the microcomputer industry.
Typically, Mowinski and Lauer recommend only minor modifications to the Apple keyboard--braille markings on the home row keys "F" and "J" and on numeric keys "0" and "6". The recommended modifications to the IBM keyboard are a little more elaborate, with key caps at the top of the list, followed closely by a keyboard indicator with auditory feedback on CAPS and NUM status.
There is a risk at this point of oversimplifying the situation: take your basic off-the-shelf computer, add a voice output device, perhaps an extra card, throw in some software, and you are ready to go.
But not so fast. There is another component to the technology: the sensory aids themselves. The Blind Center uses a number of them, and evaluates many more. Two of them deserve mention here.
The first is the VersaBraille system, by Telesensory Systems, Inc. of Mountain View, CA. This system captures input from a braille keyboard onto a cassette tape. An external microphone can be used to capture audio information on the same tape. Slightly smaller than a briefcase and weighing about ten pounds, it runs on batteries, and even has an attached handle. It provides a line-at-a-time tactile feedback. The basic model is a stand-alone unit with its own microcomputer to allow proofreading, editing, and revising.
The enhanced model includes an RS-232C input/output connector. As a result, a variety of interfaces can be achieved. For example, it can be interfaced to another VersaBraille unit to produce additional copies of the tapes, it can be interfaced to a computer to upload and/or download information, or it can be interfaced to a braille hardcopy or inkprint output device. The cassettes also provide a compact storage medium for braille text: one tape can hold the equivalent of 400 pages of braille hardcopy. [Ed. note: Lauer and Mowinski add that they did not make clear to Ms. Barsanti that the VB, the VersaBraille II, is now a disk-based instrument.]
The second sensory aid is the Kurzweil Reading Machine (KRM). This machine bears a striking resemblance to a copy machine, but is, in fact, a sophisticated piece of equipment which scans printed material and outputs the result to a voice synthesizer. At the Blind Center, it is interfaced to the Apple computer via an RS-232 connection.
The KRM is quite expensive, currently in the $20-30,000 range. Its hefty price tag and the fact that it requires high quality text puts it out of the realm of everyday home use. However, like much of the technology, it is new, it is evolutionary, and the cost is declining.
With the proliferation of devices, the variety of features and upgrades available on each, and the continuing breakthroughs, making suitable choices has become a complex matter. In fact, in their article, "Recommending Computers for the Visually Impaired, A Moving Target or a Losing War?", Lauer and Mowinski state, "Making the appropriate choice and applying it is probably the toughest job in rehabilitation."
As a first step, they rely on research which involves evaluating new devices and product enhancements; publishing papers related to the selection and utilization of computer aids; and attending meetings, conferences, and workshops.
This often involves working with developers, manufacturers, and other researchers and rehabilitation specialists. Their experiences with the KRM illustrate the rewards of this collaboration: the current generation KRM incorporates many of the suggestions and recommendations made by Mowinski and Lauer as a result of their evaluation of the first model.
However, every rewarding experience is counterbalanced by a number of frustrating ones. In their "Computer Access by the Visually Impaired" article, Lauer and Mowinski discuss how the dream can easily become a nightmare. They lament the fact that some developers "seem to be so fascinated with their computers that they have apparently forgotten about us." They compare the computer business to "a bucking bronco," with change occurring "at a frantic, galloping pace." The technology changes so rapidly that a given product does not even make it through a full cycle of evaluation, installation, and training before becoming obsolete.
As if this pace isn't enough, they cite the growing problem of "vaporware," whereby software is announced and marketed but never materializes. They charge that "Many manufacturers of aids for the disabled are among the worst offenders . . ." To aggravate the situation, a shortage of qualified personnel in the rehabilitation field fosters the development of "systems designed to keep people unnecessarily dependent upon experts."
Once the computer devices and sensory aids have been evaluated for themselves and their suitability to a veteran candidate has been assessed, then the actual training can take place. The entire process is extremely labor intensive, and illustrates an underlying theme in much of Mowinski and Lauer's work: that "it costs more to apply computer aids than it does to buy them."
In addition to providing individualized training and developing related training aids for the veterans they serve, much of Mowinski and Lauer's work is geared towards the education of others involved in the rehabilitation field: counselors and trainers, as well as researchers and developers.
As a result of their research work and related experiences, as well as the many questions they receive on topics ranging from specific devices to general strategies for selecting computer devices, they have written a number of articles and maintain resource lists of devices, their manufacturers, and where the products can be obtained.
Like most of us who work with rapidly changing technology, Mowinski and Lauer have had their share of rewards and frustrations. If recommending computers for the visually impaired is indeed a war, they are fighting a great battle. And if computer access for the visually impaired is still only a dream, they are keeping the dream alive.
Learner Level Section 13 of the BEX Dox discusses how to cope when things go wrong. This article provides you with some additional tools to help you solve most of the problems you could encounter using BEX. One important tool is an understanding of the DOS commands that BEX itself issues. I also provide the full details of how Fix chapters works. Finally, I present several hints for coping with problem chapters.
Most of the time BEX handles routine housekeeping tasks, like making sure a chapter's directory file accurately describes its page files, perfectly well. However, there are times when BEX becomes befuddled. Fortunately, your human problem-solving skills are a thousand times superior to any computer, so with the right tools, you can almost always put things right.
Every BEX menu has option Q - Quit. When you press $$eb Q, $$ec the Apple responds with the BASIC prompt, the single right bracket character. The Echo pronounces this as "Ready." You also get the BASIC prompt when you press control-Reset to stop a BEX option in progress. In the many of the samples in this article, I show the exact keystrokes you type at the BASIC prompt. To make things clearer, I don't show the right-bracket BASIC prompt itself.
A complete discussion of DOS commands is outside the
scope of this article. Here are some fundamental facts: Always depress the
Caps Lock key when you type DOS commands. DOS commands
always end with <CR In a DOS filename, every character,
including punctuation and spaces, is very important; DOS won't be able to
find a file on disk unless you type its name exactly. If you
make a typing mistake in a DOS command, DOS lets you know with the words
SYNTAX ERROR and a high beep. If you mistype a filename,
DOS responds with
FILE NOT FOUND and a high beep. In the
following samples, I enclose a filename in brackets to show where you type
the filename of your choosing.
When you have more than one disk drive, you must tell
DOS which drive you want to operate on. When you press control-Reset or
Quit from any BEX Menu, DOS's default drive is the BEX program drive,
usually slot 6, drive 1. To direct DOS's attention to a different drive,
you add the slot and drive number to the end of any DOS command. The
syntax for this is typing
S6,D1 for slot 6, drive
S6,D2 for slot 6, drive 2. Once
you supply a slot and drive, DOS assumes all subsequent commands are
directed to that drive until you give a new instruction. Providing the
complete address is crucial when you've modified BEX to work with RAM
drives. When BEX is running from an auxiliary slot RAM drive, then it's
usually in slot 3, drive 1.
Quitting allows you to use Apple DOS 3.3 while
maintaining BEX's control of input and output--speech and large print
display. When you press control-Reset, you temporarily lose BEX's input
and output control. To restore large print display, type PR#0 <CR>
<CR> and then Quit again. To relink speech at this point,
you can type either
PR#3 at the BASIC prompt, you reset
the speech software to "speech only" mode. If you want output to the
synthesizer plus the screen, issue the appropriate command.
When you are at the BASIC prompt, you return to BEX by
typing RUN <CR>
and then create your own Applesoft BASIC program. When you do
this, you erase the BEX Menu program from the Apple's memory. To return to
a BEX Menu, you need to type RUN followed by the filename of the BASIC
Menu program, followed by the slot and drive numbers for the BEX program
disk. For the Starting Menu, you type:
RUN MAIN,S6,D1 <CR>
The Main Menu is also named MAIN; the Second
Menu is named SECOND, and the Page Menu is names PAGEMENU. When you press
control-Reset or Quit, you can move directly to a different menu from the
one you left by typing RUN [menuname],S6,D1 <CR>
RUN [menuname],S6,D1 <CR>
The BEX Menu programs issue a number of DOS commands
as they copy, merge, delete, rearrange chapters and pages within chapters.
When you understand the commands that BEX uses, you are better able to
issue these commands yourself when BEX is befuddled. The Apple has a
built-in feature that lets you eavesdrop on a program as it's running. You
can use this feature to see how BEX accomplishes these housekeeping tasks.
At the BASIC prompt, type: MON C <CR>
NOMON C <CR>
MON C and then
RUN you eavesdrop on BEX
telling DOS to CLOSE any open textfile, then allocate a lot of memory for
the program with MAXFILES 2. To stop eavesdropping on BEX get to the BASIC
prompt and type:
MON C <CR>
NOMON C <CR>
WARNING! Before using
make sure that you've made lasting copies of anything you want to
keep. This is crucial when you're using RAM drives for data. Monitoring
the computer while it's running BEX can easily overwhelm the Apple,
resulting in a "deep" crash. In a "deep" crash, the DOS in the Apple's
memory is incorrect, and even simple DOS commands like CATALOG yield
?SYNTAX ERROR. In particular, using MON C in the Editor or during Fix
chapters is guaranteed to create havoc. You probably will have to
turn off the Apple and reboot. But a "deep" crash doesn't
really harm anything. As long as all essential data is saved
to disk, sit back and enjoy the show!
CATALOG shows the contents of a DOS 3.3
disk. BEX issues this command when you press <space> after the list
of chapters with a BEX D - Disk catalog. When you are having problems with
a chapter, it's a good idea to perform a DOS catalog. It shows you every
file on the disk. The catalog information is shown in four columns. The
first column is one character wide: when a file is locked, position 1
contains an asterisk. The second column is also one character wide: it
contains a single letter that corresponds to the type of file. For binary
files, the letter is B, for Applesoft BASIC files the letter
is A, for textfiles the letter is T, and for
Integer BASIC files the letter is I. The third column
occupies positions four through six; it always contains a three-digit
number. This number is the sector count for the file. From position eight
on to the end of the line is the fourth column; it contains the filename.
INIT HELLO and
initialize a disk, preparing it to save files. (You can't use these
command when you are working with a RAM drive.) This sequence of
two commands does the same thing as option I - Initialize
disks on the Starting Menu. Be cautious when using this command: any
information on the disk is wiped out when it's initialized. While
Initialize disks on the Starting Menu prevents you from initializing your
BEX program disk by mistake, no such protection exists when you type
INIT HELLO at the BASIC prompt. Assuming the disk to
initialize is in drive 2, do three things in this order: Get to the BASIC
prompt and type
CATALOG,S6,D2 <CR> DOS gives you a
listing of all files on the disk, allowing you to be sure you don't need
them. Then type
INIT HELLO <CR> which starts the
initialization process. If DOS reports
I/O ERROR then you
should throw the disk straight in the trash. Finally, type
<CR> to prepare the Apple's memory to run another program.
DELETE [filename] permanently erases a
file from the disk. When you Kill a chapter, BEX issues one more DELETE
command than the number of pages in the chapter. One DELETE command is
required for each page file, and then one more for the chapter directory
file. BEX uses DELETE whenever you Kill chapters, textfiles, configuration
files, or pages.
RENAME [old filename],[new filename]
changes a file's name on disk. Second Menu $$eb option N - Name change for
chapters $$ec uses the RENAME command to change the names of the page
files. As it does this, it reletters the page files to follow their
numerical order. This requires a fresh directory file, which BEX creates.
BEX's final step in Name change is to DELETE the original, outdated
directory file. Later on in this article, I demonstrate when you might
wish to DELETE and RENAME files instead of letting BEX do it for you.
DOS 3.3 unfortunately has a bug regarding file names: This operating system allows you to have more than one file with the same name on a given disk. This is why you should never rename a chapter to a name that already is on a disk. I demonstrate a way to cope with this problem later on.
LOAD, SAVE, BLOAD, and
Caution! The following information is here to whet
your curiosity. When you use these commands, it's quite possible that you
could damage some of the programs on your BEX disk. It's also possible
that you can learn a lot about Applesoft BASIC, by exploring the Apple's
power in great detail. Only you can guarantee the safety of your BEX disk
by always using a back-up copy.
The LOAD command copies information from disk into the
Apple's memory. The SAVE command is its opposite; it copies information
from the Apple's memory to a file on disk. You can only LOAD and SAVE
Applesoft programs, a type of file identified by the letter
A in the second column of a DOS catalog. All of BEX's menu
programs are Applesoft BASIC. Once it's loaded into memory, you can look
at an Applesoft program by typing
LIST at the BASIC prompt.
Binary files use a variation on the LOAD and SAVE commands. BLOAD copies information from disk into the Apple's memory, and BSAVE copies from memory to disk. Many of BEX's smaller programs are binary files, and all BEX chapters are composed of binary files. Whenever BEX is reading and writing chapters between memory and disk, it's issuing BLOAD and BSAVE commands. BLOAD and BSAVE commands are frequently accompanied by a specific address in memory. For example, when BEX copies a 2795-character page file from disk to the page buffer, it copies it beginning at the address A$9500, with a length of L$2795.
When BEX gets overwhelmed, it usually crashes with an
error message, which has two parts. The second line is
LINE followed by a four-digit number. Although the Apple says
break, your BEX disk is not broken. Whenever a
BASIC program stops unexpectedly, the Apple says break plus
the program line number where things went wrong. The first
line of an error message can help you pinpoint what's going wrong.
OUT OF MEMORY error
Whenever BEX presents a list of chapters, it's doing a
lot of analytical work behind the scenes. So when you press $$eb D $$ec
for a BEX catalog, or enter a drive number to scan the disk, BEX uses
blocks of the Apple's memory to build up the chapter list for your
perusal. When you ask BEX to create chapter lists several times in a row,
BEX can run out of room in the Apple's memory. The result is that you
crash with an
OUT OF MEMORY error message. Usually, typing
RUN <CR> solves this problem. If you crash again, try
moving to a different menu. When you crash at the Page Menu, for example,
RUN MAIN,S6,D1 <CR> and then press $$eb Z $$ec
once you arrive at the Main Menu.
SYNTAX ERROR IN 65239
When BEX crashes with this error message, it's a
symptom of major disorganization in the Apple's memory. (The actual number
can vary; it's always 5 digits long and begins with 65.) There's a chance
that you can recover, so type RUN MAIN,S6,D1 <CR> at the BASIC
prompt. When you try this two times in a row and just get the same
SYNTAX ERROR IN 65239 message, give up and reboot.
* Crashing into the Monitor
When you get the asterisk prompt, which the Echo pronounces as "star," it means you've crashed into the monitor. The monitor is a unique feature deep inside the Apple. It allows programmers to directly examine the contents of the Apple's memory. When BEX encounters problems, it usually crashes to the right-bracket BASIC prompt. When BEX gets really confused, you could crash directly into the monitor. When you crash into the monitor, you get a star and then at least one line of what looks like totally incomprehensible garbage. (It's actually useful information about the contents of the Apple's memory, expressed as base 16 numbers.)
To leave the monitor and get back to the BASIC prompt, press $$eb control-C <CR $$ec Try this twice; if this doesn't give you the right-bracket prompt, it's time to reboot.
In Learner Level Section 13, there's an example of using option F - Fix chapters on the Second Menu. You use Fix chapters when one or more pages of data seem to have disappeared from a BEX chapter, and you know you haven't killed those page files. A thorough understanding of how Fix chapters works can help you cope when Fix chapters doesn't solve the problem.
BEX adds a two-character extension to the chapter name to make a unique identifier for each page file. The first character of this extension is always period, the second character is usually a letter. (More details in Learner Level Section 12, part 4.)
Suppose you've created a 20-page chapter named TERM PAPER. When you print it, some of the data is missing, yet you know you did not kill any pages. Time to try Fix chapters. After you press $$eb F $$ec at the Second Menu, you must type in the exact name of the chapter you want to fix. BEX then attempts to find any page file that could exist for a chapter with that name.
First, BEX tries to BLOAD a file named TERM PAPER.A into the page buffer. When TERM PAPER.A exists on disk, then this load is successful, and BEX counts the characters in the page buffer and creates an entry in the new directory file for that page. When a file named TERM PAPER.A does not exist, then BEX tries again with the next possible page extension, TERM PAPER.B. When TERM PAPER.B exists, then BEX creates an entry in the new directory file. BEX repeats this process for every possible page.
Normally, the directory file for a chapter keeps track of which file on disk corresponds with which BEX page number. When you cut pages in the Editor, or change the order of pages with the Page Menu, it's quite possible that page 5 corresponds to TERM PAPER.A and page 1 corresponds to TERM PAPER.G. Because Fix chapters searches for page files in alphabetical order, the directory file it creates always makes TERM PAPER.A page 1, TERM PAPER.B page 2, and so forth. After you use Fix chapters, you may have to rearrange the pages with the Page Menu or the Clipboard.
The directory file is always the last file of a chapter written to disk. When some event interrupts the saving of a BEX chapter to disk, then it's likely that the disk contains some of the page files, but no directory file. This can easily happen when the disk you copy to is close to full. Before you create a target chapter by translating, replacing, copying, adjusting, or whatever, you should check that there's enough room on the target disk. (You can obtain a free sector count by pressing $$eb # $$ec at any menu prompt.)
When a disk fills up before the directory file is created, Fix chapters alone won't help you. BEX can find all the page files without problem, but there won't be room to write the new directory file to disk. Before you can use Fix chapters, you must make room for the directory file.
First, Copy any other chapters from the problem disk to another disk. Then use Kill chapters on the problem disk to delete the chapters you just copied. Now there's enough room for Fix chapters to write a new directory file.
If you already have copies of every chapter on the
disk except the problem chapter, you can use a shortcut. Quit BEX, CATALOG
the disk, and then erase just one page file from the target disk by typing
DELETE [filename] at the BASIC prompt. This makes enough
room to save a directory file, so you can use Fix chapters. After Fix
chapters is successful, you copy the just-fixed chapter to another data
disk, and initialize the problem disk.
The BEX Dox contain numerous warnings against typing a
space at the end of a chapter name. If you did, you would not be able to
do anything with that chapter. When you obtain a chapter list
by pressing $$eb D $$ec at a BEX menu, the chapter does show up. When you
scan a disk drive for chapter names, that name is on the
list. Yet when you try to print, edit, translate, or even rename it, BEX
crashes with a
FILE NOT FOUND error message. This can be
pretty mystifying; fortunately, you can solve the problem.
Suppose you created a two-page chapter in the Editor.
When you started, you named it ACT1 and typed two spaces at
the end. When you do a DOS catalog, you see: B 011 ACT1.A
B 090 ACT1.B
B 003 ACT1
B 011 ACT1.A
B 090 ACT1.B
B 003 ACT1
In this case, .A and .B are added after the two spaces. But there's no way for you or BEX to tell how many spaces are in the name from just looking at the directory file. When you scan a drive or press $$eb D $$ec at any BEX menu, BEX presents you with a list of chapters. BEX creates this list by checking for directory files on the disk. BEX assumes that any 3-sector, binary, file whose second-to-last-character is not a period qualifies as the directory file for a BEX chapter. In this sample, BEX grabs the filename ACT1, but it has no way of knowing there are two spaces at the end.
Suppose you wanted to copy this ACT1 chapter. If you
scan this disk, BEX finds the directory file and thinks the chapter's name
is just four characters long. When it's time for BEX to BLOAD the page
file into the page buffer and then BSAVE it to the target chapter page,
BEX asks DOS 3.3 to please load the file named "ACT1.A". But that file
does not exist! The result is that BEX crashes with a
The solution is to type in the full name, spaces and all. Use option N - Name change for chapters to get rid of the spaces. You may have to do some trial and error. Type the name with one space; if that doesn't work, try two spaces, and so on. In this sample, the only meaningful spaces are shown by <space You type:
Second Menu: N
Name change for chapters
Drive or Chapter: ACT1<space><space> <CR>
Drive or Chapter: <CR>
Target chapter: ACT1 <CR>
Chapter ACT1 done
Because you have supplied BEX with the full
six-character name ACT1, BEX knows to ask for the page file
named ACT1.A and you can successfully change the name.
As mentioned earlier, DOS 3.3 does not prevent you from renaming one file to a name that's already taken. I'm not talking here about overwriting an old chapter with a new chapter. When your target disk already contains a chapter named INVOICES, and you copy a chapter to the name INVOICES on this disk, the new INVOICES information replaces the old. And usually, that's exactly what you want to happen.
You only encounter the duplicate filename problem when
you are renaming chapters. Suppose your target disk contains
two chapters: a two-page chapter named INVOICES and a three-page chapter
named BILLS. A DOS catalog of this disk shows: B 010 INVOICES.A
B 015 INVOICES.B
B 003 INVOICES
B 016 BILLS.A
B 008 BILLS.B
B 008 BILLS.C
B 003 BILLS
B 010 INVOICES.A
B 015 INVOICES.B
B 003 INVOICES
B 016 INVOICES.A
B 008 INVOICES.B
B 008 INVOICES.C
B 010 INVOICES.A
B 015 INVOICES.B
B 003 INVOICES
B 016 BILLS.A
B 008 BILLS.B
B 008 BILLS.C
B 003 BILLS
B 010 INVOICES.A
B 015 INVOICES.B
B 003 INVOICES
B 016 INVOICES.A
B 008 INVOICES.B
B 008 INVOICES.C
I hope this problem remains completely hypothetical for you. But if you should encounter it, you can use Fix chapters to recover. In our sample, copy INVOICES to BILLS. Then, Kill INVOICES. Now, you have the two page files left from the original INVOICES chapter. Create a new directory file by using Fix chapters, with target chapter INVOICES.
Textfiles are type T files and BEX
chapters are type B binary files. There are some DOS commands
that only work for textfiles, and some others that only apply to binary
files. If you try to do a binary file operation on a textfile, or vice
versa, DOS 3.3 reports a
FILE TYPE MISMATCH error.
When a disk contains a BEX chapter named APPENDIX,
then there's one binary file named APPENDIX for its directory. If you told
BEX to Write a textfile named APPENDIX on that same disk, DOS 3.3 would
complain with the
FILE TYPE MISMATCH error. That's because
BEX has asked DOS to OPEN a type T file named APPENDIX, but DOS has found
a type B file named APPENDIX that can't be OPENed.
You would encounter the same error message if a
textfile named APPENDIX existed on disk and you tried to copy a chapter to
the name APPENDIX. BEX asks DOS to BSAVE the directory file named
APPENDIX, and DOS is upset because you can't BSAVE a textfile. If you
tried to edit a new chapter named APPENDIX, you would get a
read error message from BEX.
Doing the research for this article was quite enjoyable. I found out more about DOS 3.3 than I ever thought I could understand. I hope it encourages you to experiment with your Apple--the more you know, the more fun you can have!
This resource book is for all those who struggle with the question of how to pay for computer access technology.
In clear and practical language, Mendelsohn, an attorney and rehabilitation practitioner, explains all the sources of technology funding, including the vocational rehabilitation system, veteran's benefits, Social Security, the tax system, and governmental and nonprofit loan programs. He provides would-be technology users with the information on how to develop a comprehensive--and successful--acquisition strategy.
Readers will learn which sources are most relevant to their situations and needs, how and in what order each is best approached, and what each source should be asked and told. Readers will also learn how sources can be combined--even how failure with one can be turned to advantage with another.
Financing Adaptive Technology is available in large print, in braille, on four-track audio cassette, or on Apple IIe disk for $20. Mail your check, money order, or purchase order to: Smiling Interface. See Facts on File for address and phone number.
The American Association for the Advancement of Science (AAAS) announces publication of the 2nd edition of the Resource Directory of Scientists and Engineers With Disabilities. The spiral-bound volume, containing 950 listings, is cross-referenced by scientific specialty, disability, geographical location, and gender. A braille edition is also available.
The Directory is an excellent source of consultants, speakers, role models and peer reviewers. Potential users of the Directory range from university administrators and human resource departments to parents, educators, and disabled students.
Price is $10 plus $3 for postage and handling. Multiple-copy discounts are available. To order, send a check or money order payable to AAAS (details in Facts on File).
The Braille Authority of North America is happy to announce the publication of two braille codes soon to be available from the American Printing House for the Blind.
The Computer Braille Code will be available in both print and braille, and is officially approved for implementation by BANA as of April 30, 1987.
The English Braille American Edition - 1959 (Revision), now available in print and braille from APH, has been approved by BANA for implementation in August, 1987. The official title is: The English Braille American Edition--1959; Changes to the 1972 Revision; Adopted by the Braille Authority of North America; August 1987.
Check Facts on Files for contact information.
Go-WordPerfect is the second product in Talking Computers, Inc.'s line of Talk-To-Me Tutorial series. The first product, An Introduction to MS/DOS, has been on the market for six months and is being used by individuals and training centers alike with excellent results. The one-of-a-kind course is recorded on audio cassette and is the only training available that doesn't ask the user to continually refer to a printed manual.
Go-WordPerfect takes the listener from the most elementary steps of entering text through more advanced features, ending with sophisticated text handling such as running merge files, writing in columns, creating lists, developing tables of contents and more. The four-hour training course concludes with an audio reference card that can also be brailled.
Go-WordPerfect sells for $75, the MS/DOS tutorial for $69. [For ordering address, please see Facts on File.]
Dig-Sig is a disabled interest group, one of whose goals is to disseminate information about how computers can enrich the lives of the disabled. To this end, we publish a monthly newsletter--the "Hot Dig-Sig News"--with a circulation of approximately 300. We are seeking relevant articles of around one page length. Suggested topics are products available and work being done which may help the disabled community. We can't guarantee a specific printing date or that we'll use all articles, but we will try to get the information out to our readers as expeditiously as possible. See Facts on File for contact information.
When computers were first used to create braille, some blind proofreaders were concerned that the computer would put them out of business. I'm happy to report this has not happened. First off, computers have made producing braille easier than ever. Those who felt that it wasn't worthwhile to learn braille because of a scarcity of material have realized that nothing could be further from the truth. Second, computing has generated a tremendous new demand for braille. The blind need braille manuals for all sorts of software programs and peripheral devices. And third, brailled material still needs to be proofread to eliminate mistakes. Braille has so many applications that blind proofreaders will never be obsolete.
Several years ago, realizing how much braille material I need personally, and how much our blind students at public and vocational schools and colleges need, I started our own volunteer transcriber group. In the early days, we relied on the Perkins brailler. When I proofread a volunteer's work and found even one mistake on a page, she had to re-braille the entire page. When we needed to add or omit a line, several pages had to be transcribed again to make sure the page numbering was correct. Volunteers who could have been producing new material lost precious days revising. Today, for those who have refused to give up the Perkins, we still use the same old technique. But for the adventurous ones who've taken up computing, it's an entirely different story.
With the computer, braillists can produce more work faster and with less physical effort. A couple of years ago, one of my volunteers, a braillist for some thirty years, decided she was getting too old to continue pounding the Perkins. So she gave up transcribing and regretfully sent back her brailler. Then she discovered computers, learned a transcription program, bought her own computer, and is back in the fold. She's now producing more braille than ever. She doesn't tire as easily as she did when she was pounding the Perkins, and since she never has to go over old work, she's far more productive than she was previously. The reason she's free to keep brailling new material is that I use BEX to make corrections for her.
She actually uses Dr. Stepp's ED-IT program to enter text--using that program is similar to using the old Perkins, so she had few transition problems. I can and do use ED-IT, but I prefer using my old reliable talking BEX. When I get a disk prepared with ED-IT, I simply use the Read textfile option on BEX's Second Menu. I select the first textfile, specify the Zippy chapter as my Target chapter, and print it out as a draft copy for proofing. I get back into page one of the Zippy chapter, and while proofing the braille draft copy, use Control-L to locate and correct the errors I find. Once I've corrected the errors on each page, I get out of the Editor and copy the Zippy chapter onto a formatted blank disk. The name I give the chapter reflects the name of the entire volume I'm working on. For instance, if I'm proofing the DOS User's Manual, braille volume I, I name the chapter DOS MANUAL1.
Now I use option K on the Second Menu to kill the Zippy chapter. I use option R to read the next textfile I wish to review, and go through the process all over again, using the Zippy chapter for my Target chapter as before. Once I've corrected the errors in that chapter, I use option G - Grab pages on the Page Menu to copy the information in my Zippy chapter to the end of my first chapter. My chapter DOS MANUAL1 now includes the first two textfiles from the volunteer's ED-IT disk.
I repeat this entire process until I've combined four or five ED-IT textfiles to produce one braille volume. Once I have some ninety braille pages on my data disk, I print the entire disk to my brailler. When BEX prompts for chapter name, I enter 2 <CR> to do the entire list. If I have access to a continuous-feed braille embosser, I can go to lunch, secure in the knowledge that I'll find a perfectly brailled volume waiting for me upon my return.
If I've created any major changes in my text, such as deleting or inserting a line, my biggest problem is the braille page numbering. Transcribers using ED-IT enter the page numbers manually. When lines are deleted on a page, then the page numbers can appear any old place on the page.
I use Replace character to delete all the page numbers. Then I go into the Editor and insert a few commands at the beginning of the volume: $$w40 $$f25 $$np for line width, page length, and page numbering. When working on anything past volume one, I add $$n# and set # equal to the beginning page of the next volume. The wonderful thing about this procedure is that it enables me to print any single page or group of pages I choose. If I catch a mistake on page 77, I can correct it, and then, using option M - Multi function print, ask to have just that particular page re-brailled. BEX makes sure that I get the identical words on that page each and every time. I've never know it to miss by a single letter.
But asking BEX to do the page numbering can introduce another problem. As the braillist originally entered the text with ED-IT, she allowed at least three spaces between the text on line 1 and the page number. But once I remove the manual page numbers, the second line on a braille page may be cut short if the first line was fully brailled. Since the computer has to allow room for the page number preceded by at least three spaces, the rest of line one may be finished on line two. What was originally one braille line becomes two, with the second line being mostly wasted.
When I'm doing straight literary braille, I sometimes use Replace characters to strip out <CR>s. All the <CR>s manually entered in the ED-IT textfile disappear and the braille lines are filled up as much as possible. One problem can result with this method: if you haven't really filled your braille lines before using hyphens to divide words, the new format will put your hyphens where you may not want them. In many cases, it may be more trouble to remove the carriage returns than to keep them, especially if you're transcribing poetry, computer work, or other text that doesn't call for full lines all the time.
[Editor's Note: I know of several TranscriBEX users who are grappling with the differences in format when transferring information from ED-IT to BEX. I'd be deliriously happy to print a Newsletter article about good techniques to use! JK]
I've found another simpler and faster way to proofread--using voice. I use the same method described above, but instead of printing the individual files or the entire disk, I back-translate the entire data disk into print. I press B at the Main menu; when I'm prompted for a chapter, I take BEX from drive one and replace it with my data disk. I put a newly formatted disk into drive two. For Source chapter, I enter 1 <CR> (for the whole disk in drive one). Since I now have to rely solely on voice, I begin by typing Control-E 4 D. This command inserts a delay between words, so that I can really catch those mistakes. And, as before, I use Control-L to locate them.
Whether proofreading braille draft copies or by using voice, your ability as a blind person to make all the corrections not only relieves your volunteers from a burdensome task; it also allows them to produce more work. It's clear that there's no shortage of work for blind proofreaders.
I am interested in purchasing a used but perfectly functioning Echo II voice synthesizer, card and speaker with volume knob. I do not need the original software or documentation. To discuss price, please call me at 212-581-8291.
John Fritz of Wisconsin wants to make someone quite happy by selling them his original SlotBuster card. This fully-equipped card has manuals on disk and in print, speech synthesizer, 24K of memory, circuit card to enable the solid and open-Apple keys to clear buffer, cable to connect the Apple speaker to the card, and parallel/serial ports with both cables. Price is negotiable. Bargain hunters should contact:
12212 County Hwy K
Lancaster, WI 53813
Screenless Games has moved! The new address is:
1407 Cedar Avenue
Boulder, CO 80302
Braille Access Service offers you an opportunity to have all your braille and large print needs met at a reasonable price and in a timely fashion. We will transcribe a variety of information for employees, customers, students, friends or yourself. Please call or write for more information. BAS hopes to be of service to you.
Braille Access Service
P.O. Box 10998-396
Austin, TX 78766
BEX, TranscriBEX & Hot Dots
Raised Dot Computing, Inc.
408 S. Baldwin St.
Madison WI 53703
Ohtsuki Communications Products, Inc.
1399 Ygnacio Valley Rd
Walnut Creek, CA 94598
Station A, Box 5002
Champaign, IL 61820
RamWorks & RAMDRIVE
Applied Engineering, Inc.
P.O. Box 798
Carrollton, TX 75006
Sensory Aids Corporation
205 W. Grand Avenue - Suite 110
Bensenville, IL 60106-3389
NJ Commission for the Blind
Technical Aids Center
Newark NJ 07114
Harvey Lauer & Leonard Mowinski
Blind Center 117A
Hines IL 60141
Financing Adaptive Technology
P.O. Box 2792
Church Street Station
New York, NY 10008-2792
Resource Directory of Scientists and Engineers With Disabilities
Project on Science, Technology and Disability
AAAS 1333 H Street, NW
Washington, DC 20005
Phone: 202-326-6667 (voice/TDD)
New Braille Code Books
Susan Jay Spungin, Ed.D.
American Foundation for the Blind
15 West 16th St
New York, NY 10011
Talking Computers, Inc.
6931 N. 27th Rd.
Arlington, VA 22213
Hot Dig-Sig News
Peter D. Mirche, Editor
Dig-Sig (Disabled Interest Group)
5982 Bernadette Lane
San Diego, CA 92120