Open Apple Vol 3 No 11 DEC 1987

Open-Apple Releasing the power to everyone. December 1987 Vol. 3, No, 11 ISSN 0885-4017 newstand price: $2.00 photocopy charge per page: $0.15 Living Languages PROMAL Reviewed by Dennis Doms if there is one factor affecting the development of software for the Apple II, it's the search for a true high-level (that is, higher than assembly language) development language for the computer. Applesoft Basic, the high-level language supplied in ROM with the Apple, lacks certain features that make writing programs of any appreciable size easy. Programmers complain about the “sloth” of Applesoft and its lack of “programming structures;’ such as IF/THEN/ELSE and DO/WHILE. Most programming structures can be simulated by crealive programming, though, and speed is often not as much an issue as being able to write a readable, bug-free program while minimizing high blood pressure, To my mind, one of the most serious failings of Applesoft is thatitrelies on indexing its program logic by line numbers to transfer control, Therefore, you have to remember what a subroutine at line 1000 does while typing in “GOSUB 1000” to execute the code, lest you invoke a set of lines defining a printout routine when you meant to open a disk file. There’s nothing mnemonic about a line number, In small programs, this is an irritation; in large programs with 20-30 or more subroutines, you have to" use your memory as an extension to Basic to remember where you put things in the program, The use of line-numbers for indexing also makes SAVEing a general purpose subroutine so that it can be used in other programs an exercise in patience, requiring a “hold and merge’ utility that lets you “hide” the main program in memory, load the subroutine into memory, renumber the subroutine so that its line numbers don't clash with those in the main program, then “unhide” the main program and merge the renumbered subroutine into it If you did happen to know what the line number of the original subroutine was, it was almost certainly changed during this process. Also, unless you have total recall, there’s a possibility that some variables in the original (main) program may clash with the newly added subroutine. Which means you not only have to remember what all the (changing) line numbers stand for, you also have to remember which variable names are in use and (when changed) what they stand for. The larger the: program, the: more ofa problem this becomes. One solution is to allow the naming of a subroutine so that it can be accessed within the program by stating its name. Therefore, "GOTO 1000” might become “PRINT.STRING’. Second, we'd like to be able to name variables used in the subroutine separately from the main program, so thata variable “ASTRING” used in the subroutine would not change the value of a variable of the same name in the main program, unless we wanted it to. ‘There are. a few programming languages on the Apple that allow this, but they may use different methods to achieve the effect. PROMAL \s such a language. Maybe the easiest way to look at the philosophy of the language is to analyze a small program, where it's easy to see we're not in Basic anymore (the text following a ;" on a program line is a comment, similar to a REM in Applesoft): PROGRAM CALC 3 Floating point calculation benchmark for PROMAL 3 (based on June 1984 Gyce, p. 336) INCLUDE LIBRARY 4 for some extra PROMAL Func! INCLUDE DUD/PRTINE 3 for “print current tine DATA DATR REAL C WORD COUNT DATA WERD NREPS = S00 71828 214159 3 define a fau variables aL } tneluding our boop counter nd nunber of repeci ons BEGIN 3 CALE OUTPUT “Starting celculacicns a: y pent starting tine PRT! PUT CR C=1.0 FOR COUNT = 1 TO NREFS 3 cecKe cece, cec/a Cecse bUTPUT PRTINE PAT oR ourest ENO follow with carriage return thos Le teat tart uth hen manipu awhile Caleulasians done at i print completion tine Error = ME",C-1.0,C8 § and amount of error created 3 CALC First, unlike Basic, we have to describe (“DiMension,” in Applesoft terminology) all variables before they are used. We can define variables as being REAL (floating-point), WORD (a two-byte positive integer from 0 to 65555), INT (a two-byte integer from -32768 to 32767), BYTE (a one-byte value from 0 to 255) or BOOLEAN, (a two-state value such as TRUE and FALSE). Second, and very easy to spot, we have no tine numbers. The flow of control in PROMAL is determined by certain keywords (some disarmingly familiar) in conjunction with the indentation of the lines. For example, there are four : — “TUUST HOPE TWS WILL PUT TO AX END ALL THE MOPING AND WHINING ABOUT NEEDING A MONITOR FOR HIS COMPUTER.” 3.82 -Open-Apple indented lines containing simple mathematical expressions following the line “FOR COUNT = 1 to NREPS”. The FOR loop in this case executes in a manner similar toa loop in Basic, but PROMAL determines which statements are inside the loop by their indentation. The four indented expressions are executed over and over while COUNT increments (by 1) from 1 to NREPS, then the FOR “falls through’ to the following OUTPUT statement. Notice there's nothing in this program similar to Applesoft’s NEXT statement — indentation takes its place. Using indentation as part of the control structure takes some adjustment if you're a die-hard Basic programmer, but it has a good side affect: it strongly encourages you to write structured code that you (or another programmer) can read later. In this matter, PROMAL is more adamant about structure than some other languages; as an example, indentation is normally used in writing Pascal or C programs but is not forcibly required as in PROMAL Even other languages | have used on the Apple that are stringent about structure, such as Forth and LISP, do not do as much to force you to write readable code. The third difference from Basic is that the command words are different; BEGIN, OUTPUT, and PUT are not part of the standard set of Appiesoft statements. BEGIN proclaims the beginning of a grouped set of instructions that can define a PROGRAM, PROC (procedure; a subroutine that does not retum a value), or FUNC (function; a subroutine that retums a value or values). END in PROMAL is (unlike END in Applesoft) required to define the end of a PROGRAM or segment (PROC or FUNC). Pairing the use of BEGIN and END to define program segments aliows us a luxuryin PROMAL thats not allowed in Basic; the easy definition ofa series of general purpose routines for inclusion in other programs. What makes PROMAL better than Basic in this regard is that the routines are accessed painlessly by name rather than called by a line number. And another problem solved: unless you explicitly make them otherwise, variables declared and used within in PROCedures or FUNCtions are manipulated separately from those in the main program or other procedures, even if the variables have the same name. That is, we can have a variable named COUNT within a PROCedure and do all sorts of things to it without affecting the contents of another variable named COUNT in a separate PROCedure, FUNCtion, or our main PROGRAM. Incidentally, variable names can be up to 31 characters long with all characters significant (not just the first two as with Applesoft). This modularity feature is a reason for going through the pain oflearninga new programming language; you can speed up Applesoft, and you can simulate DO/WHILE and other structured loops, but you can’t get rid of the line numbers. Only by going to a new version of Basic or a whole new Janguage can you escape the dreaded “hold/merge” required to make Applesoft somewhat modular. ‘An example of the power of modularity: while the FOR loop and BEGIN/ END are part of PROMAL, some commands such as OUTPUT and PUT are not part of the basic core of the language. OUTPUT and PUT are, in fact, subroutines defined in the PROMAL source file “LIBRARY,” which is added to the source file for the program CALC by the program line “INCLUDE LIBRARY.” This line causes the PROMAL compiler to effectively insert the text of the source file “LIBRARY” and compile it as if the text were included in the file for PROGRAM CALC at that point. LIBRARY includes many routines needed for normal programming tasks and is provided as part of the language package, The PRTIME statement refers to a routine J wrote to print the time at the beginning and end of the benchmark code: PROC PRTIME +: prints time from ProDOS-compatibie clock to nesrest second. * expects Thunderclock-compatible format! * EXT BYTE TARRAY[] AT $229 EXT ASM PROC JSR AT SOFE4 3 start of tise string for HO or TC 3 PROMAL M/L interface OAM HORD TROINTER DATA BYTE OOGETTINE{) = ¢ used for indexing 3 ML for get_tine call 520,300, 55F . 7 JSR MLL S82, } OFB BETTIME 500,00, 3 OW PARMLIST 360 3 RTS BEGIN 3 PRTINE JSR OOGETTIME get tine string Into buffer FOR TPOINTER = $02 TD 308 jar high bits TARRAY[TPOINTER] = TARRAY[TPOINTER] AND $7F TARRAY(2] = “= 3 change coamas to colons TRRRAYIS} = “= TARPRY|S) = $00 ¢ terminate string with 390 Vol. 3, No. 11 PUT TARRAY END i eeeand print It This code is more obscure than the CALC program, but it shows an . important feature of PROMAL—the ability to access the Apple through definition of PROCedures incorporating machine language routines. The byte array DOGETTIME is defined to contain a series of hexadecimal values (yes, you can enter hex numbers into PROMAL) that provide the machine code to execute a ProDOS GET_TIME cali, We also declare an EXT ASM PROC (external assembly procedure) named JSK at memory address location $0FB4; this routine is actually part of the PROMAL runtime support that allows us to pass control to an assembly ge subroutine. We use the procedure JSR to call our GET_TIME code, then dig the (Thunderclock format) time string data out of the Apple’s input buffer. This allows us to print the time to the current second instead of limiting it to minutes as “peeking” at the ProDOS TIME and DATE registers would. This specific PROC also shows a limitation of PROMAL—it isn't set up to deal with strings as easily as Applesoft. Since there is no “string’ data type, we access a string as a set of contiguous bytes, ending with a terminating value of 0, This limits us to using defined string fields of known maximum size; writing programs that would use dynamic string-handling in PROMAL would require defining our. own data structures and garbage collection routines for astringarea” of memory, Still, this is not an unheard-of limitation; I've had to do this type of programming in FORTRAN on minicomputers, and the current version of Kyan Pascat also does not have a string data type. PROMAL, though C-like in most of its features, also lacks (as far as I can determine) a data structure to incorporate several variables into a “record” similar to C’s STRUCT, though programmers can write routines to build their own associated data structures. PROMAL'S library does include several functions that allow common manipulations of string data (concatenation, substring search) so that you don’t have to start off writing a string support package. Basic real-number calculations (add, subtract, divide, multiply) are directly supported in PROMAL, but get more difficult with trigonometric and transcendental functions such as LOG and SIN. These functions are provided byaset of real number library routines that are slower than Applesoft's binary floating point routines, but much faster than Kyan Pascal's BCD (binary coded decimal) routines. | came up with the following results on a few simple benchmarks from Byte (see the December 1986 issue of Open-Apple page 2.88, for information on sources for the benchmarks). All times are in seconds: calc sieve urite read PROMAL 2.1 142 Applesaft 2 131 138 64 205 7 36 Benchmarks are only one factor among many in evaluating a language, so take the following comments in that light PROMALS calculations were to 11 digits of precision; error for the iterative calculations was about 0.0000000036 percent. This was for simple “four function” math (addition/subtraction/multiplication/division). For the more rigorous. Savage benchmark, which uses trigonometric and exponential functions, PROMAL took 706 seconds and retumed a relatively high error of about 0.002 percent over 10,000 iterations (versus 472 seconds with an error of 0.0000050 percent for Applesoft). Bruce Carbrey at Systems Management Associates, developers of PROMAL, says he is still looking into improvements for the math library (they are looking into support using the SANE math package provided in the IIgs). PROMAL's function library also uses iterative methods that can overflow the stack on heavy calculations; | had to split the test formula used in the Savage benchmark into two expressions to avoida stack problem. PROMAL's manual wamed about this possibility. In simple looping operations (a good portion of any program), PROMAL blows Applesoft away; Applesoft takes 143 seconds to execute 100,000 iterations of an empty FOR/NEXT loop; PROMAL takes 9 seconds for the same operation. We can also go to the Gilbreath Sieve of Eratosthenes benchmark reported in Byte ("Eratosthenes Revisited”, January 1983) to see some differences— Applesoft takes 3,764 seconds versus 163 seconds for Kyan Pascal and 154 seconds for PROMAL What the benchmarks don’t show is the flexibility of PROMAL in data manipulation. In addition to the math operations and some of the string support we've come to expect from Applesoft, PROMAL can do bitwise operations on data. Also, any routine or function we can write can be added December 1987 to any program with a simple INCLUDE statement; all we have to do is save the debugged subroutine in a text file for use the next time. The manual describes a large number of such routines, which are included with the PROMAL package. The substantial PROMAL manual was a bit hard to wade through at first; partly due to my lack of familiarity with the language, and partly due to the fact that the manual interleaves descriptions of both the Apple and Commodore 64 versions of the PROMAL system, which occasionally breaks the flow of reading about certain features. The manual contains a tutorial but the reference sections are definitely intended to be read by someone with programming experience. Still, there is an index and | found all the information to be there for solving some complicated probiems in porting the Byte benchmarks to PROMAL. The reference sections and appendices of the manual are superb in the fact that they give concise, technically accurate descriptions of the PROMAL language and do not assume the reader is simple-minded. Some of the information is hard to read the first time, butitis the completeness of the explanations of some features of the language (such as program chaining and overlays) that makes it so. If you decide to leam about such advanced features, all the information is there waiting for you tather than simple words pointing you to another manual. Ifthe manual is serviceable, the amount of source cade that comes with the PROMAL system is amazing. Included is source code for 2 simple terminal driver (for the Apple Super Serial card and compatibles), the floating point routines, access to the ProDOS MLI, and a Ict of samples. The $100 developer's system allows you to distribute compiled programs written Open-Apple 3.83 in PROMAL, including the use of the source code routines and a provided stand-alone runtime package for self-starting disks. A $50 end-user system is also available. Both PROMAL packages include a very usable full-screen editor, a linker for combining compiled routines, a command-ine executive with “memory management” and 1/0 redirection, and an extensive library of additional functions. A high-res graphics support package is available at extra cost. Phone support during several conversations with SMA was excellent. In addition, there is a disk library of PROMAL support routines and programs available to PROMAL users. For languages other than Basic, it looks to me like today's front runners under ProDOS 8 are Kyan Pascal and PROMAL. Both have speed advantages and disadvantages compared to Applesoft that depend on the operations being performed, Pascal has the advantage of wider portability; PROMAL versions exist for the Apple Ile and {fc (igs also, with exception of the terminal driver routines, which need to be updated for the IIgs ports), Commodore 64, and MS-DOS 100 per cent IBM-compatibles. That covers a large portion of the micro market, but Pascal also runs on most computer systems with some minor changes. The Apple version of PROMAL also expects a Ile or Ile (Ayan Pascal supports any 64K Apple Il). The primary limitation for both languages is that neither has support of strings that approaches the simplicity of Applesoft string variables. PROMAL 2.1, by Syslem Management Associates (3325 Executive Drive, Raleigh, NC 27609; 919- 878-3600) development system $96 95; end-user system §49 85; graphics toolbox $29.95. On the other hand Hey! Every time | write to Open-Apple with a suggestion, the next issue always contains a letter from someone saying, “you can’t do that.” Come on guys, if Steve Wozniak had that attitude, you'd all be ‘writing Cobol programs for IBM. I'm particularly disappointed that Peter Baum called my “frigid” reboot idea “extremely dangerous” ("Frigid flaw’ page 3.80). Baum’s objection, like earlier objections, is that it might not work with future hardware revisions. He's concemed that the power-up byte location may change. First of all, Apple's documentation states that this byte is reserved, and won't change. Of course, that doesn’t mean much. Ifit does change, so what? We'll just change a byte in the frigid reboot routine. Finally, the frigid reboot routine is designed to keep you from having to tum off your power switch. God forbid this routine might crash! You might have to tum off the power switch. Unfortunately, the “you can’t do that” attitude seems to be taking over at Apple. The most exciting hardware product at AppleFest was the Zip Chip, a plug-in replacement for the 65C02 that triples the CPU speed of the Apple IIc, lle, and H-Plus, The company says they'll have a [Igs version out next year to replace the 65816, but two of the top Apple IIgs engineers I talked to said, “you can’t do that” My money is on the Zipchippers. I talked to a number of ProDOS 16 developers at AppleFest, who complained of performance problems caused by strictly following Apple's tool calling protocol, particularly for keyboard input and screen output. I say that ifyou sacrifice current program performance for compatibility with future hardware, you'll be out of business before that future hardware appears. For the people who disagree with me and want to write a rebuttal letter to Open-Apple, you can’t do that! Bill Basham Diversified Software Research Farmington, Mich. Ah, come on Bill, sure they can, One of the best Parts of AppleFest for some of us was eavesdropping ‘on the parleys you were having with people who designed various parts of the IIgs. Compatibility is very important to the long-term mental health of the Apple I! user communlty. But yowand |, as authors of Diversi-DOS and ProntoDOS, know quite well thal users will pay for speed. We got our start making Apples faster. It can be done. If Appie had done tt our way to begin with, where would we be now? PS, | was impressed by the Zip Chip too, but we've decided ta reserve judgment until we actually get our hands on one. They're still not shipping. Some feedback on reality While [ am an avid reader of Open-Apple, | an seldom as galvanized by an article as | was by your lead piece for the November 1987 issue, “Reality and Apple's Vision:’ You have articulated and made explicit In this essay the uneasy feeling that has been slowly and quietly creeping up on inany of us in the Apple Il world. Thank you for sounding the alarm, As one who bought a Ilgs early on, [ am most distressed by the absence of any indication that a 16- bit AppleWorks will emerge from Apple or from anyone else. I'm not talking about a ported-over version of Microsoft Works. I'm talking about an extension ofthe current AppleWorks, filecard interface and all, to the 16-bit IIgs. The potential for building on this solid foundation of success is enormous. If Apple absolutely, positively must have a Mac-like appearance then let's use the mouse with MouseText inconjunction with cursor controlas many of Pinpoint Publishing’s products do, We'll see what gets the best reviews, The use of MouseText is infinitely faster than the Macclone stuff I've seen so far. When it takes an etemity for a 16-bit pragram launcher to load and position itself for duty in comparison to &-bit desktop managers like Pinpoints Run-Runor Glen Bredon’s ProSEL, then someone has really goofed. Consumers are not that stupid. If you don't helieve that, just try selling full-size cars with lawn mower engines in them. Thave a IIgs. [ have several of the latest and most popular 16-bit software packages. When I want to get something done, | use my 8-bit software, most notably AppleWorks. Why? Because | don't want to wait longer to use a computer than it takes to assemble pencil and paper. Because | don’tlike tobe patronized bya weak and slowversion of the Macintosh user interface. If | had wanted or needed a Mac. 'd have boughta Mac. You suggest that Apple execs are pursuing a rational, though misguided, course ofaction in order to mollify disaffected third-party software developers. Specifically, you suggest that Apple is trying not to compete with software developers. If that's their aim then how in the world did HyperCard get out? HyperCard on the Mac will, [ predict, devastate the Mac software indusiry, especially the big-boys. With HyperCard, anyone can be a sophisticated software developer. My belief is that they don’t know what they're doing, We probably can't cure Apple of its death-wish, that's too deeply ingrained. What we can do is make the choice so plain that even a deinented fool would recognize the hand that feeds him; so plain that basic susvival instincts override the afore-mentioned death- wish. Here's what I propose. We begin a realistic public discussion of what a 16-bit AppleWorks could and should do. This will accomplish at least two things, First, itwill provide Apple with a free market-analysis, one they wouldn't commission on their own because of the fear that they might find out that their “Apple IT as mini-Mac” theory is bankrupt. Second, it will place the initiative for what such a software item might be in the hands of those who will ultimately use it Power to the people, 3.84 — OpenApple Let's hear what the Apple Ill folks out there in keyboard-land really think. Frank Lowney Milledgeville, Ga. Your editorial "Reality and Apple's Vision” was right on the money. | believe your statement that we are “on the edge ofa disaster” was not hyperbole. [tis an accurate statement when applied to the Apple I's true situation, and Apple should notice. It probably won't notice, however. Why worry, when Iis are still selling strong? Why find-tune marketing and software evangelism, when you've made a massive investmentin pigeonholing the Apple II as an “enter- tainment and education” computer rather than recognizing how IIs are actually used by many people? ‘The roaring success of AppleWorks provides excellent feedback on how IIs are applied by adults in the real world, but as you correctly noted, Apple itself has almost gone out of its way to ignore this feedback, other than to deposit the proceeds, 1 am 31 years old, an account executive with an advanced degree. | do not use a Macintosh; | use an Apple Ilc because | like it and the publications and the people. | am frustrated, however, by what I perceive to be an undersupply of good productivity software for my computer. The advent of the IIgs had me excited until | read from Jean-Louis Gassee that “in no way, shape or form will we be in the office with this computer.” (Editor's note: | am not familiar with this quote, and it doesn't ring true with what f have heard Gassee say. | will attempt to find out more for a future issue—sorry for the interruption.) What Kind of message does that send developers? John Sculley was on TV last night, singing the praises ofthe Macintosh in the office, the Apple Il in education” What about the Apple I in the office, Mr. Sculley, or in the home office? luse Apple Writer, Point-to-Point, and software from Glen Bredon and Bit! Basham. These are better than almost every MS-DOS application | have used, and I have used a lot Problem is, software for adults as useful as these programs is rare. Apple perpetuates this condition through its “positioning” which discounts the possibility of non-school markets for the II. And through its training of computer store salesmen, who. can't help you if it doesn't go on or in a Macintosh. (Hint Bypass the suits and talk to the technicians.) At the same time, Apple will not develop any more good, crash-proof applications for the Il because itis, afraid of criticism from developers. I really do feel that developers have had their chance. Most of them are too busy with MS-DOS to create new II stuff that doesn’t draw a greeting card or animate a bear. Nobody criticized GRID when it came out with inte- grated packages for its computers. Borland and Ashton-Tate don’t bellyache when Atari releases software, or rake IBM over the coals for manufacturing software. Why should Apple be so concemed about static from outside developers when those developers have had years to make more procluctivity software for the I, but didn’t do much, except for AppleWorks add- ons and programs in specific vertical markets. When, with a good product, it's easier to be a big fish in the II pool than in the MS-DOS ocean? Clone prices are, of course, plummeting and MS- DOS software is getting better and easier to use— witness Microsoft Works for the PC. I'm thrilled that Apple is using supercomputers and geniuses to develop better system software. But what difference doesit make when they promote the Il essentiallyas a gadget to display flash cards? Through too-narrowly- focused advertising, ambivalent developer programs, anda lack of desire to support the wider world of Woz’ invention, Apple will widen the gap between what people need the computer to do and what Apple wants them to do with the computer. That puts Apple IIs in closets. Italso puts clone makers, who haven'ta fraction of the genius and resources Apple has at its disposal, in the winners circle. Benn Kobb Washington, D.C. I like the concept of AppleWorks as an operating system. Although I'm a true Macintosh zealot today, my roots are in the Apple I]. Whenever | use an Apple Il today, my work generally involves AppleWorks’ power and flexibility, In fact, we are about to release an interface to AppleWorks for our library circulation system, Circulation Plus. It will provide a path for our users to import and export data in both directions, giving them the power of AppleWorks to massage their data. Don Rose Follett Software Company ‘ystal Lake, Ill. | just finished reading your opening article in the November issue and feel that it requires a response. If not for myself then in defense of Apple. | have been using Apple computers since early 1982 and consider myself an intermediate to expert user. | do not own, nor have | used AppleWorks (except once when I got 0 confused that I gave up). ‘The program uses.commands that, though many people are familiar with them and add-on programs use them, are completely different from any other program | know of. Also the program (and it is a program and not an operating system) uses a file ‘structure that is different from all other programs, | know you can use text and DIF files but you yourself have said that it's a pain. No DOS 3.5 program and very few ProDOS (note: these are operating systems) programs use the same file structure. All BBSs and information services use standard text files, as do many good ProDOS programs. Before you think that I'm completely against Apple- Works let me say that the program is of good quality and very easy to learn if you don’t have to unlearn another program in the mean time, It's provenitselfin sales and testing. That's an excellent track record for such a complex program. As for Apple not having ads for AppleWorks, | don’t think they need them. Think about it, If you had a product that sold as well as AppleWorks and also had some other products that weren't selling, which ones would you use your advertising budget for? Martin Wallgren Prophetstown, Ill. | would like to disagree with you on a couple of points regarding “Reality and Apple's Vision” Your ‘Suggestion of acknowledging Robert Lissner’s contri- bution to the Apple II is a good one. However, including AppleWorks as system software has some serious flaws. First some background. | was an avid Apple II user for several years until just this last summer when | acquired a Mac and sold my Apple I!. Until about 18 months ago, Apple bundled MacHtite and MacPaint with every new Mac sold. For the first three years of the Mac's life, there was only one word processor the Mac, MacWrite, Because everyone received Macltite free, there was little room in the market for other word Vol. 3, No. 11 processors. The market stagnated for three long years in word processors and paint programs. Apple finally decided to unbundle MacWrite and MacPaint for the Mac, and the market is now booming with word processor and paint programs. And during the three years that MacWrite and MacPaint came in the box with the computer, did Apple grow and improve the programs? No! They merely updated each program enough to keep it up-to-date with the evolving Macin- tosh Operating System. So you see, Apple really is a computer hardware company. Not only do they ignore AppleWorks, the program that has sold so many Apple Ils, but also MacWrite and MacPaint. Including AppleWorks as system software for the Apple II will not solve the stagnation of AppleWorks, It will only stagnate the competition also, I also have problems with AppleWorks being the standard platform for ProDOS. Before | continue, 1 must admit | like the idea ofan improved AppleWorks that has many hooks developers could use to attach their software. This would alleviate the problem of one add-on patch to AppleWorks not getting along with other add-ons. But ProDOS should be kept separate from AppleWorks, One shouldn't have to run AppleWorks just to delete or copy a file. The beauty of ProDOS is that it is just an operating system. The SYSTEM file defines the actual user interface. This is ‘one of the most common misunderstandings of ProDOS, | have seen many articles where a command like “BSAVE LOADERSYSTEM, TSYS, L16284, 48192" is attributed to ProDOS. This is absolutely incorrect! Thatis a Basic.system command. ProDOS only under- stands Machine Language Interface calls. The beauty of ProDOS is that it leaves the user interface to the ‘SYSTEM file, and SYSTEM files can be developed to make ProDOS look like any operating system (Kyan Pascal's KIX.SYSTEM, for example, has a Unix look). So for some constructive ideas, | agree that Apple has to create a vision with the Apple Il as they have with the Macintosh. This vision might settle on a ‘standard Interface for the Apple fl under ProDOS; I believe that Basicsystem is the de facto standard right now. Apple should decide on supporting the Apple II and stop worrying that it will undercut their Mac sales. Whether Apple sells an Apple II or a Mac, they still have a customer. Craig Miller Honolulu, Hawaii J completely agree with your point that ProDOS and AppleWorks should be separate. As you point out, significantly different user interfaces can be embedded In SYSTEM programs; that is one of the beauties of the Apple I. The point at which we disagree is that you think Basic.system Is still the de facto standard interface on the Apple II and I think Aplworks.system became the de facto standard months ago. As the de facto standard, I see no reason a 16-bit version of AppleWorks needs to change the user interface at all. For once why couldn't we have a 16- bit version of a program that actually recalculates spreadsheets and sorts databases faster than the 8- bit version, instead of wasting all the extra power on belis and whistles. Why nota 16-bit version that uses today’s larger memories for data space rather than for program space? The major enhancements | {ook forina 16-bit AppleWorks are speed, larger data files, system hooks, developer's documentation, and memory management thal would allow third-party developers (0 do the real enhancing. December 1987 The Hypercard precedent gives Apple the liberty to begin putting AppleWorks in the box with all Apple Ils. This can hardly stifle a software market that has already been choked to death by an AppleWorks that has a suggested retail price of $250. Itwould, in fact, give software developers a new base {in Apple’s words, a “platform’) to develop from. Ifwe can't convince Apple to put AppleWorks in the box with the Apple I] within the next couple of months, the program that defines our machines will fall into the hands of Claris. Perhaps that’s no worse than having it at Apple, but still, the idea makes me sweat, All ProDOS Sider update Please warm your readers that the popular all- ProDOS ROM developed by Steve Park, which has been used by many people on all models of the 10 meg Sider and the 20 meg Sider 1, is not compatible with our new 20 meg model, called the Sider D2. We are using a different drive and controller in the 20 now and we are hearing that not only does Park's ROM not work, butitwill screw up the format on the drive to the point that our own software and ROM will no longer be able to install the drive, We have been shipping the D2 for about 6 weeks. You can easily identify it because it has a black label on the front that simply says "The Sider.” The old 10s and 20s had blue labels that sald “The Sider” and “The Sider II” respectively. The 10 meg siders are no longer being built. The suggested retail price of the Sider D2 was just lowered to $595, Despite the use of a third-party product with the Sider, we have not voided anyone's warranty and have replaced all D2’s that have run into this problem. I am told that a factory format can get the drive back up and running fine. Lance Jacobs, Technical Support First Class Peripherals Those of you with older 10 and 20 meg Siders whose ears perked up at the words “all-ProDOS ROM" can coniact Steve Park at Advanced Tech Services, PO Box 920415, Norcross, GA 50092 404 441-3522. The ROM sells for $49.95, Zero-page: No Vacancy Thave seen lists of zero-page locations compiled by Beagle Bros and others, but none of them list all the locations. What about the rest? Are they simply not used by Applesoft or DOS? Nick Doulas Chicago. Ill. On page 142 of the ProDOS Technical Reference Manual is a fist of zero-page locations, who uses them, and which are free, This map lists location $D6 asunused, In writing an ampersand routine for use by an Applesoft program, | discovered, after much frustration over an intermittent and elusive bug, that $D6isused. Justa caveat for your readerswho may be using the ProDOS manual as an exclusive reference, Chuck Bilow Oregon, Wisc. In general, assembly language programmers should assume that every byte on zero-page is used, In fact. Applesoft, DOS, and the Monitor do use almost every last byte; assume that other ampersand routines use the few bytes that are left. If you need some Zero-page bytes for indirect addressing, save what's already in a couple of bytes, use them, then replace the previous contents, Don't attempt to use zero-page as a slorage area—build your own data storage area inside your program. The book What's Where in the Apple, by Wiliam Luebbert, is probably the best single source on zero- page usage. Two of the major companies that publish Apple Ii assemblers, Roger Wagner Software and $-C Software, have programs available that disassemble Applesoft and give you complete details on its zero- Page usage. AppleWorks on the Il-Plus My soccer club already had a II-Plus but wanted to use AppleWorks. After a bit of checking around to compare prices and the market for Il-Pluses without drives or monitor, ust the box, we decided to upgrade the IL-Plus instead of buying Ile. Not necessarlly the best way, but the cheapest. Before starting, we determined that the “minimum” requirement was a 64K II-Plus with the famous “one- wire” shift key modification. We had both, so we were on our way. We had to have an 80-column card to run Apple- Works. | found a “clone” card for a very reasonable price from WG Technologies. Look in the back pages of Computer Shopper magazine for their address and a current price quote. Itis possible to use an Apple-styie memory card for desktop expansion, if you have AppleWorks 13 (we. did), We bought Applied Engineering’ RamFactor. The RamFactor comes with AE's patch software that makes AppleWorks run on the Il-Plus. The version of the patch we received was 1.2.1 —1 know from another project that thisis the same software that AE sells with their ViewMaster 80-column card. After installing the 80-column card and the Ram- Factor the rest was easy. (You may need to adjust your monitor after installing the 80-column card.} Make a copy of AppleWorks. Again, it must be version 1.2 or 13, not 2.0, The AE program is menu driven and lam not going to describe howto use it. Just follow the on- screen instructions. Ifyou have AppleWorks 1.2, you will not get much. Even after patching, it will only use 64K for programs and data. This means you have just a 10K desktop and the program must go back to the disk to “overlay” program segments every time you switch operations. Get 13 ifyou can. With AppleWorks 1.3 and the RamFactor, data space is limited only by the amount of memory installed on the Ramfactor. The real plus, however, is that 1.3 will load itself into the memory card for fast operation, The only program segment that must be loaded from the disk is the one for printing. Asmall price to pay for the speed of using the memory card for all the rest of the AppleWorks’ program functions, Since the II-Plus does not have an open-apple key, the patched program has you press the ESC key once, and then the desired key. Such as ESC-P to print or ESC-S to save. You press ESC ESC to get the actual ESCape key. Due to the lack of a solid-apple key, and the MMU chip of the Ile, add-on programs such as AppleWorks or PinPoint will not work on a I-Plus system. Tom Smith Fort Vancouver, WA J was unable to find an ad from WG Technologies in the latest issue of Computer Shopper, However, we recently received a flyer from one of our subscribers who works for a company called Nexo Distribution Open-Apple 3.85 (914 E 8th St, #109, National CA92050 619-474- 3528). They seit ail the pieces needed to get Apple- Works to run on a 64K Apple Il or Il-Plus for under $100: Plusiorks I] softuare, Norwich Data 339.0 Videx-rospatible 8@-colunn board 45.00 Shift-Key Modification leit 6.95 PlusWorks has several advantages over Applied Engineering's software—it's compatible with alt Appleworks versions from Li through 2.0 and it's compatible with all memory boards—even older 128K Satum- and Legend-type boards. If you are starting with a 48K Apple II, Nexo has a 16K card for $35, but the money might be better Spent on an accelerator card for slot 0-- these all add the missing 16K as well as speed things up (see “RAM found in accelerators,” in our December 1986 issue, page 2.88). Muttiplan update In "Spreadsheet $tring variables,’ a reader asks for a spreadsheet that lets you use the IF statement with text. He says “neither AppleWorks nor Multiplan allows text as a clause or argument in formulas.” AppleWorks, true, but my version 107 of Multiplan allows more than adequate string manipulation. For example, {F{ RLC1>R1C2, "MORE THAN’, “LESS THAN"} yields the text "MORE THAN” if R2C1 is greater than RLC2and the text "LESS THAN" in all other cases. Multiplan 107 also allows the concatenation of strings using an ampersand ("“Open-” & “Apple” yields “Open-Apple’’); the separation of strings using the MID("TEXT”,star.num) formula; the translation of Strings to values using the VALUE("text’} formula; and the translation of values to strings using the FIXED- (value,num) formula. In short, there isn’t much which Muitiptan can't do with strings (or any type of data). Interestingly enough, though, I'm in the process of changing all of my Multiplan spreadsheets to Apple- works for two reasons: 1 the ease with which | can move from application to application and 2. the speed with which AppleWorks calculates. True, Multiplan overpowers AppleWorks in some areas, but since AppleWorks is probably doing less (or are there other reasons for Multiplan’s sluggishness?), I've found speed improvements of up to 40 seconds on similar 12 column by 60 row spreadsheets, Onanother spreadsheet topic: on page 3.39 of your June 1987 issue, you stated: "A simple way to get blanks instead of zeroes in calculated cells is to set up an ®IF statement that displays 'NA’ if a cell’s value is zero. Then start up your favorite disk zap program, find the NA...and change it to blanks.” Thank you. it works...but not enough. If the calculated “double-blank” cell is the last calculation in the chain, fine. But, for example, ifyou add a column of numbers that includes even one double-blank cell, the answer will also be a double- blank. The whole idea was to clean up the looks of a spreadsheet with lots of zero cells, but your solution cleans up all the result cells, too. So, does anyone out there have a patch to allow something like @IF(A1<>0, Al'B1,“")? Multiplan allows this and it’s one of the features | miss with AppleWorks. Robert Cerchio Carbondale, Ill. We thought Multiplan for the Apple Ii was dead, but a call to MicroSoft’s sales department at 800-426- 9400 (206-882-8088) revealed they still sell it, Version L07 is the latest. Updates from older versions 3.86 Open-Apple cost $25, Suggested retail on a new copy is $95. It’s still “Apple” DOS 5.3 based and still copy-protected. Microsoft hasn’t tested it on the Iigs (and doesn’t intend to), but says it's compatible with all earlier Apples, You've identified a significant limitation to the NA- method for displaying cells with zeros as blanks, Does anyone have a better idea for this one? AppleWorks ligs defeater Maybe I am too old to switch (70 years) but | still want to use AppleWorks version 1.3 on my IIgs. But even though | have a RamFactor card in slot 7 anda 5 meg GSRAM card, I can only get a 55K desktop. ‘Surely, someone can come up with a patch to make AppleWorks recognize the RamFactor, Elmer Meissner Bedford, Ind. Incredible as it may seem, AppleWorks 13, which was released months before the ligs, includes a test to see if it is nmning on a ligs. If it is, it refuses to expand into an Appie-standard memory card, such as RamFactor. AppleWorks 2.0 also refuses to use this type of memory card when run ona ligs. Dennis contacted our AppleWorks guru Alan Bird, who had a patch handy. He came up with it while debugging the Time Out manager so he could fool AppleWorks 2.0 into thinking it was running ona He when it was actually running on his ligs. Alan's one-byte patch simply changesa JSR $FELF instruction (20 1F FE) to BIT $FELF (2C IF FE). Asa JSR, this instruction jumps to the ligs identification routine, As BIT, it makes the ligs appearto be alle. To make the paich, use a disk zap utility to search through APLWORKS.SYSTEM for the byte to change, or get into Applesoft, insert an unmodified copy of your AppleWorks disk in the drive, and enter: POKE 768,44 BSAVE APLWORKS .SYSTEN, TS¥S,A76B,(1,813223 (V1.3) SAVE APLHORKS .SYSTEN, TSYS,A768,(1,813605 (V2.0) Because of the patch technique being used, there isno need to BLOAD the file first (see “Patch instruc- tions patchy,” page 3.79, for more). AppleWorks 2.0gs bugs After running AppleWorks 2.0 on your IIgs, ty Tunning a program that uses the high-resolution graphics screen, You'll just see garbage. AppleWorks 2.0 tums off IIgs “shadowing’ for everything but the text screen and neglects to tum it back on. The following short program will fix this: 10 REN fix IIgs shadow register 20 FOR 1=@ to 1@ : READ X : POKE 76641, X + NEXT 30 DATR 173, S3, 182, 41, 168, 9, B, 141, 53, 192, 95 40 CALL 768 Jim Lather Kansas City, Mo. For the full scoop on what “shadowing” is, see “Iigs altemate display mode” in our December 1986 issue, page 2.86. Asimitar bug in AppleWorks 2.0 is that it gets an ID from the ligs ID manager, but doesn't delete it before quitting. If you run AppleWorks 2.0 on a Ilgs 256 times without turing the machine off (not impossible If you teave your machine on 24 hours a day), the 1D manager will run out of IDs. We haven't had time to actually test to see what kind of disaster happens then, however. Another fix for both of these problems is to simply make AppleWorks think it's running on a Ile, as demonstrated in the previous letter. lle aux-slot advantages Potential users of the Beagle Compilershould note that compiled programs may use either aux-slot or standard-slot RAM cards to hold variables. However, it is only the aux-slottype card that can be partitioned to hold both variables and a RAMdisk. | have been able to have both AppleWorks and my own compiled programs ina RAMdisk while using the rest of the card for variable storage (my programs) or desktop (AppleWorks). Anyone developing or using programs that read AppleWorks files should find this type of arrangement very convenient. Using ProSet it is possible to jump from AppleWorks to your program and back in less than 10 seconds. This feature, in my opinion, tips the balance in favor of auxiliary cards for the time being, Paul McMullin Campinas, S.P. BRAZIL Gutenberg lives After reading September's “Reviewer's Corner” (pages 3.59-3,61), one might think that Printrixis the first text processor to deliver the type of performance you describe. {I know you didn’t say that.) However, the majority of the features you describe have been available to 48K Apple owners since 1981, when the firstversion of Gutenberg was introduced, The current ProDOS-based version 3,0 allows four fonts to be in memory at once and allows still more fonts to be used on a given job. These fonts may be downloaded fonts or special graphics fonts that allow the use of huge characters. They may be stored on a RAMdisk for quick access. Vertical spacing, letter- spacing, and minimum and maximum word-spacing can be changed in tiny increments, as with Printrix at any place in the text. Special formats, such as fractions, definite integrals, etc, can be automated so that inputting such things is a simple matter. The program supports multi- column setups, automatic formatting of simple and complex ruled and unruled tables, customizing of automatically printed headers and footers (changeable at any point in the text), footnotes and endnotes, mail merge, several types of automatic numbering for enumerated paragraphs, imbedding of graphics material, and much more, Its appeal to foreign language specialists is obvious, since it comes ready to print in Greek, Hebrew (yes, left to right), Arabic, Russian, Ukranian, Syriac, and Cree (an Indian tribe of Wester Canada). Justin case you want to change your dip switch settings to use one of the European fonts supplied with the Image- Writer, Gutenberg supplies you with the matching screen fonts. Itisn't perfect though. Not nearly enough fonts are supplied to printa newsletter such as yours, although there is a hint in the manual that more are on the way. It is not cheap, but technical support is fast and excellent. Itsupports only the Apple DMP, ImageWriter, and ImageWriter Il. It formats at the printer, not on the screen, but on the other hand offers unlimited formatting capabilities and superb precision. For any Apple owner with a special job (eg., linguist, scientist, mathematician) it may be the answer to a prayer. A few months ago a certain magazine carried @ rather thick center-fold ad for a new IBM-based technical word processor from a very well-known Vol. 3, No. 11 company. [t asked the question, “Was your word Processor designed to do this?” Asa Gutenberguser, { could answer “yes” and be about 95 per cent truthful. Olof Monson Kingston, Ontario Gutenberg Sr. 3.0 requires 128K and an 800K disk device, It selis for US$360 (C$460) from Gutenberg Software, 47 Lewiston Road, Scarborough, Ontario, CANADA M1P 1X8, 416-757-5320. The company also offers a US$91 (C$118) version called Gutenberg Jr. It comes with a manual on disk and specific defined Printing formats. The junior version is printer-specific, however, it is available for a wider selection of printers than the senior version. For more information, write or call Gutenberg Software and ask for a copy of their 16-page sample brochure (printed with Gutenberg, of course). Help wanted Is there anyone you can pay to create an AppleWorks custom printer definition for a non-Apple printer? Todd Shelton Chico, Calif. Or how about a disk full of SEGPR files for non- Apple printers? We don’t know of any, yet. Multiple custom printers In its April 1987 issue, the National AppleWorks Users Group's AppleWorks Forum published the addresses of the pre-defined printer codes held in SEG.PR. The article is by Garth Shultz, who attributes the information to an article by David Walker that can be found in the DL-4 library on CompuServe's MAUG. With this information itis a relatively simple task to replace a set pre-defined codes (for example the Imagewriter codes) with a set of custom codes you've entered using the AppleWorks Add a Printer menu. You can also change the printer names that appear in the in the Add a Printer menu by editing SEG.M1 {at $0E9 of block $0117 on the AppleWorks program disk). I've created a single SEG-PR file that includes an Okidata driver with draft mode codes, an Okidata driver with near letter quality codes, and an Okidata driver with boldface begin defined as ESCAPE. Works fine. Bruce Ristow Rochester, N.Y. Shultz’s idea ts to define a custom printer from within AppleWorks, BSAVE that section of the SEG.PR file, then overlay one of the pre-defined printer's codes with it, Then you go back to AppleWorks and add that pre-defined printer. Now, when you use that printer, youll get your custom printer's codes. This allows you to put three custom printers in SEG.PR rather than just one. The only difficulty with this technique is that the length of a set of SEG.PR printer codes varies. The length depends on exactly whal codes a printer uses. For example, a printer that uses a code such as “ESCAPE R ESCAPE 44 LF” for super-script begin needs more space than a printer that uses a code ‘suchas “ESCAPE S” for this, SEG.PR has a 500-byte space for the custom printer. If you BLOAD SEG.PR, A$2000, this space is at $2B42. You can overiay a complete 500-byte section of codes into SEG.PR at the start of the Scribe section ($24BA) and at the start of the Epson FX section ($2845) withoul ovenwriting either the Imagew- December 1987 riter/Apple Dot Matrix printer codes or the custom printer codes (you will ovenvrite most ifnotallofthe other pre-defined printer codes however, so don't attempt fo use them), Proceed like this: enter Applekiorks, define custom printer # exit AppleWorks, enter Applesoft LOAD SEG.PR, TSYS, A2000 SAVE CUSTON.1, ALLe74, L500 enter AppleWorks, define custom printer #2 exit Appleliorks, enter Applesoft BLOAO SEG.PR, TSYS, ASZA00 BSAVE CUSTON.2, ALLO74, L520 BLORO CUSTOM.2, ALES03 LORD CUSTON.1, 93402 BSAVE SE.PR, TSYS, A2000 enter AppleWorks, renovs ali printers add a Serie; this is custos.1 add an Epson F) acd a custom printer; this would be custom.3 The proportional problem Why isn’t it possible to set up a custom printer for AppleWorks and the ImageWriter II that will print proportionally? Michael Leddy Charleston, IU. Proportional fonts are hard on word processors. The concept of “characters-per-inch” simply doesn’t apply to proportional fonts—the characters, by definition, are all different widths. Consequently, to get printed lines to be approximately the same width, the word processor has to know the exact width of each character and do line calculations based on those widths. Many more “I's fit in a tine than "M's, To do fulljustification, which most people with access to a proportional font immediately want to do, the word processor also needs to calculate how much space should go between each word. Then it needs to know the commands for printing blank spaces of various widths. AppleWorks’ author correctly, in my estimation, Judged that entering all this information into custom printer definitlons would be beyond the ability of most users, and so he didn't include proportional capability for custom printer setups. He did, however, goto the trouble to support proportional fontson the Apple DMP/ImageWriter, the Apple Daisy Wheel, and the FX_. Jt sounds like what you want to do is add some custom features to the Imagewrtter without losing those proportional fonts. This can be done by manually editing the Imagewriter definition in the SEG.PR file. See “Zapping Imagewriter codes” in our February 1987 issue, page 3.4. The AppleWorks BBS (see “AppleWorks + Multiscribe” in August 1987, page 5.54-55) indudes an assembly source fite for SEG.PR that you can follow like a roadmap. Using this information, it’s possible for a knowledgeable individual with lots of spare time to create a “custom” driver for any printer, But be aware that the number of capabilities defined in SEG.PR is limited; to add a feature will mean losing existing capabilities, Ifthis sounds too difficult, Open-Apple subscriber Eugene Whitehouse has developed a program called ExtraWorks Printer Utility that rewrites AppleWorks’ Imagewriter or Epson printer setups so that you can get things like color printing, mousetext, half height sub- and superscripts, and slashed zeros without giving up proportional type ($20, 25 Kensington Ave., #505, Jersey City, NJ 07304). Database crash lead I'm pretty sure I've found a weird problem with AppleWorks that occurs to people who upgrade from version 15 to 2.0. I've seen it about a dozen times now, and have examples, All of a sudden, AppleWorks 2.0 will not load old database files created with 13 anymore. In every case, the byte in the header that shows the number of report formats defined was Incorrect. I haven't found the code that causes this yet, and it obviously doesn’t happen a lot, or we'd have heard of it already, but I've seen it enough to be convinced that somewhere there is a problem. If you hear from anyone who has this problem, have them send me a copy of the disk and I'Ilatleast try to fix it;it may help me find the cause, Eugene Whitehouse 25 Kensington Avenue, #503 Jersey City, NJ 07304 AppleWorks page nos. (cont) Tuse the AppleWorks word processor to create long documents, some over 300-400 pages. According to the manual, | should be able to get up to 511 consecutively numbered pages. But with both Apple- Works 1.3 and 2.0 I get interrupted pagination following page 256. Making corrections on the misnumbered pages is a chore, so if there's any way of getting AppleWorks to deliver its 511 consecutive numbers, I'd be delighted to know it David Alman Highland Park, Nu. We've been following this bug since Aprit 1986 (page 2.23) and once had a report the bug would be fixed in AppleWorks 2,0 (page 2,51). Apparently it is more complicated than at first thought—tests I've run using a page length of half an inch, a header with the page number, and one line of text. print page numbers correctly well into the 300s. (This kind of testing takes a long time and uses lots of paper— printing to a formatted text file (August 1985, page 2.60) helps some.) Atany rate, you might want to took at the program WriteWorks from W°A'R (Working Apples Reientlessiy) Software ($29.95 plus $2 shipping; 4974 N Fresno ‘St, #282, Fresno, CA 93726). WriteWorks is a ‘post- processor” for AppleWorks word processor files. To use it you leave AppleWorks, run WriteWorks, and tell it which file to print. It picks up intemal AppleWorks formatting codes, reacts to additional “double-dot” commands (lines that begin with two periods) that you embed in your file to send special codes to your Printer, automatically formats footnotes, and correctly prints page numbers. CHAIN bugs and overlays 1am developing a ProDOS-based Applesoft program that would benefit greatly from using binary program overlays as described in your April 1986 issue, page 2.20 and 2.21 I want to use three program segments that share lengthy menu and character input subroutines. So, following your directions, | slavishly prepared a file containing those shared subroutines and named it “OVERLAY.” After many unsuccessful attempts at doing arun and much tinkering and the fourth re-read of the article | came to the conclusion that there was a problem with LOMEM. And, lo and behold, on page 2.20 I find “Neither the DOS 3.3 nor BASIC.SYSTEM versions of CHAIN pay attention to whether you have reset LOMEM™. And this is a fact. Open-Apple 3.87 But the instructions you give fora STARTUP program at the bottom of page 2.21 say to move LOMEM beyond the end of your longest overlay and then CHAIN to your main program. Have | missed something? Theodore F. Smolen Danvers, Mass. What we're dealing with here is your bugs, my bugs; and Apple’s bugs. Your bug is the simplest to explain, so let's start with it. Your shared menu and character-input routines should be in your main program and your three program segments in three separate overlays. Instead, you have designed your program with a single, permanent “overlay” and three “programs” that you want to CHAIN in under the overlay. This won't work. The overlay technique is intended to replace CHAIN. It's based on the idea of a main program holding all Shared routines and of overlays holding independent Program segments, You have to think of CHAIN and overlays as two different techniques. The difference between them is that CHAIN changes the whole program in memory, while the overlay technique changes only part of the program in memory. My bugs come in two parts. You haven't missed anything, my comments at the bottom of page 2.21 are just stupid. Take a pencil and change the next to last paragraph so that it says, “if you attempt these tricks, your main program should begin with the following steps.” Then cross out the last fo steps, which relate to the CHAIN command. We could have aseparate STARTUP program, like the one described, that simply copies all program segments from floppy disk to RAMdisk, But it should end by RUNning the main program. And the main program itself, not ‘STARTUP. should change LOMEM and should RESTORE its own variables. The second bug | made was higher on page 2.21, where { showed how tojump from the main program to the overlay. The way I did it works only when the line numbers used are “right.” For a complete description of this bug and how to get the overlay technique to work with any line numbers, see the letter “Problems with splits,” from Paul Nix, in our September 1986 issue, page 2.64. Apple's bugs have to do with Basic.system's CHAIN, ‘STORE, and FRE commands. These three commands Share a set of routines that move Applesoft variables around in memory, Unfortunately, the routines need to work slightly differently for CHAIN and STORE than for FRE and for automatic garbage collection, bul they don't. As installed at the factory, Basic.system: works fine for FRE and garbage collection, but messes up CHAIN and STORE when the Applesoft variable tables happen to be an exact multiple of 256 bytes tong. In the same issue of Open-Apple, on page 2.20. 1 mentioned a couple of articles in Call -A.P.P.L.E. that first demonstrated, then fixed, the CHAIN/STORE bug. What ! didn’t know at the time was that the fix has the side effect of messing up FRE and garbage collection. Complete details are available in the July 1987 issue of Byte’s “Best of BIX: Apple” column, on pages 305-310. Assuming | now understand the whole problem, which is debatable, the complete fix is: Inmediately before CHAIN or STORE: IF PEEK(49143)=1 THEN POKE 41859,3 Inpediately after CHAIN or STORE: IF PEEK(45143)=1. THEN POKE 41859,7 700 8 8(YUpPrVvAppic Basic.system 11] is unusually bug free, so I'd hate to see it modified much, but I do think Apple should give us a version 1.2 to fix this particular bug. Basic choices Is there a different Basic for the Apple [le? Daniel Mason San Jose, Calif. Quickly skipping by all the CP/M Basics available to you if you have a CP/M card, and all the MS-DOS Basics available if you have a PC Transporter, and alt the upcoming Basics that are ligs-specific, the answer is yes. But first sit back and decide what exactly it is you don't like about Applesoft. Is it lack of speed? Is it limited memory space for variables? Is it tack of structured loop commands? Is it a flaccid command set? Is it difficulty with adding machine language modules? is it line numbers? Is it auo-character variable names? Is it lack of portability to other computers? Go make a list of what's important to you and meet me back here in five minutes. Now, if tack of speed and memory space are your only major complaints, what you need is the Beagle Compiler (current version ts 2.5). We don’t want to be redundant, so see our February and March 1987 issues, pages 5.13.2 and 3.9, and “Expanding Apple- soft” in last month’s issue, page 3.80, for more information. The Beagle Compiler will run on any 64K or larger Apple II, supports aux-mem and Apple- j Zz I ji © Copyright 1987 by Tom Weishaar Business Consultant ‘Richard Barger Technical Consultant Dennis Doms Circulation Manager Sally Tally ess Manager Sally Dwyer Most rights reserves. All programs published in public domain and may be coped and dist buted mrad charge. Apple usergroups and sirvican! oars ma repr nt aces am time (9 lime by specific writen request. Requests and chet dori! materia cluding ters to ince DOS svould be sentte Open-Apple P.O, Box 7651 Overland Park, Kansas 66207 U.S.A. Published monthly since January 1988. World-wide prices (in US. ‘ollars, airmail delivery inctuded at no additional charge) $24 for + year: $46 tor 2 yenrs, $60 lor 2 years. All single back issues are currently available for $2 each; bound, indexed editions of Volume 1 ang Volume 2 are $14 95 each. Volumes end with the January issue; ‘an index for the grior volume is included wilh the February issue, Please send all subscriplion-relaled correspondence to: Open-Apple P.O. Box 6331 Sracine, N.Y. 13217 U.S.A. rom Speech Enterprises, PO. 463 ‘sav 0 wt nthe ros conmetial sofa, Open Apple is sold an unprolectes toma for yout co You ae encouraged 10 mmateback-up archival copies, 9S eniarges copies or your own use without charg for Eaintutonoaie's Te copy distrbte WARRANTY AND LIMITATION OF LIABILITY. | warrant hal most of the information an ple is useful and covet, ahough sve! and mislakes are meluded Irom time to line. usualy Snuntestionaly Unastisied subseters may return issues wit 18Ocaysot celery lor afulretune Please include anotelrom yout porens of eb surg ela al cope are at Eire Thun fot of ay pu sara be Telundedon eaves! MY LIASIITY EOREAROMSAND OMS ISUMITED 10 THIS PUBLICATON'S PURCHASE PRICE In ne ase shal | or my contrbutors be lable lor any incidental oF onseauentta damages, norlor ary damages excess clthe ees paidbya syoscrte 1SSN 0885-4017 may f sbubion See is t5 cents per page per Source Mail: TCF238 Printed inthe U.S.A. CompuServe: 70120,202 standard memory cards, is ProDOS-based, and is unprotected. Distribution of self-running disks requires a royalty payment of $50 a year ($74.95, Beagle Bros, 3990 Old Town Ave, #102C, San Diego, CA 92110 619-296-6400). If lack of structure and a weak command set are your major problems, take a look at Basic (current version is 2.7). Like the Beagle Compiler, it is highly compatible with Applesoft itself—the only Applesoft command Blankenship Basic doesn't support is HGR2. On the other hand, it adds a number of new commands that allow structure, such as REPEAT/UNTIL, WHILE/ENDWHILE, WHEN/ ELSE/ENDWHEN, and LOOP/EXITWHEN/ENDLOOP. It adds commands that allow routines to be called by name rather than by line number, Itcan printtextand it can draw and fill boxes on the graphics screen; it has SORT, SEAKCH, and PRINTUSING commands; and it has facilities that allow you to save often-used subroutines in individual files and easily merge them into programs you are writing, It includes its own tine editor. For more, see our answer to “Toward a perfect Basic” in March 1986, page 2.14. Blanken- ship Basic comes in both DOS 3.3 (any 48K Apple If} and ProDOS (any 64K Apple iI) versions, is unpro- tected, and can be distributed on self-running disks as shareware with no royalty payment. ($25 DOS3.3 or ProDOS, $39.95 for both, from Blankenship and Associates, PO Box 47934, Atlanta, GA 30362 404- 491-3151). In between the Beagle Compiler and: if Basic is an ever-growing collection of ampersand packages that add various abilities to Applesoft. This collection is much too large to tick off here; if we tried we'd be sure to unintentionally insult at least one of the dozen or more subscribers who has sent us an ampersand package to review, to say nothing of overlooking stuff we haven't seen. So how about this —we'll throw out all the ampersand packages we've received and start over with two new niles. To get a plug in Open-Apple, an ampersand package must 1) be compatible with Roger Wagner Software's Toolbox Series and 2.) be compatible with the Beagle Compiler. These niles mean that all amper- sand packages we talk about from here on will be State-of-the-art and will be compatible with each other. Those of you who aren't famitiar with Roger Wagner's Toolbox Series should look al ‘The amper- sand solution” in our September 1986 issue, page 2.63. Pushing just past Applesoft and ampersands, we next come to ProBasic (current version is 10), developed by the same Alan Bird who wrote the Beagle Compiler. ProBasic is an Applesojt-based language you can extend by writing “modules,” using either assembly lanquage or ProBasic itself, that become ProBasic commands. The modules support local variables (ie, using FOR I= 1 to 10 ina module will not change the value of I in the main program), parameter passing (ie, in POKE 768,0, “768” and “O” are “parameters” that are passed to the command POKE), and recursion (a module can call itself). ProBasic includes a VIRTUAL module that allows you to pul arrays on any ProDOS-compatible disk device, including RAMdisks (array size is limited only by the size of the device), and modules can be easily switched in and out of memory. ProBasic also comes witha full-screen editor (well, ... actually, «you buy the full-screen editor, Program Writer, and you get ProBasic free on the back of the disk). ProBasic is ProDOS-based, works on any 64K or larger Apple Il, supports any memory card that can Vol. 3, No. 1 be configured as a RAMdisk, is unprotected, and can be distributed on self-running disks by leaving in the copyright notice. Por additional information see “ProBasic, " in our September 1986 issue, page 2.62. ($49.95 from Beagle Bros, address above.) While Blankenship Basic and ProBasic solve many of the problems people have with Applesoft, neither is compatible with the Beagle Compiler. To get speed and structure without throwing everything you know about Applesoft away, the best compromise is Micol Basic (current version is 2.1). It’s fast like the Beagle Compiler, it provides structure like Blan- kenship Basic, it allows multi-character variable names (the first package mentioned so far that does), has local and global variables, named proce- dures with parameter passing, and includes an editor. It is not totally Applesoft compatible, but it is Close, We carried a rather extensive review in Sep- tember 1986, page 2.61. Micol Basic is ProDOS- based, will work on any 64K Apple I, is unprotected, and can be distributed on self-running disks by leaving in the copyright notice. A 90 to 95 per cent Source-code compatible llgs version of Micol Basic és under development. (US$69.95, Micol Systems, 9 Lynch Rd, Toronto, ONT, Canada M2J 2V6 416-495- 6864). A step farther away from Applesoft is ZBasic, which is available for DOS 5.3 (current version 3.20), ProDOS (current version 4.00), CP/M, the Macintosh, and MS-DOS. The big strength of ZBasic is the Portability of its programs. In theory, you write just one program, then, using different compilers, you can make the program run on any of the supported computers. The advantage of being able to move a program from one computer to another so easily is obvious, Even graphics transfer ~ Dennis devised a program that rotates a pyramid on the screen; when rununder CP/M, which doesn't support graphics, the pyramid’s lines are drawn on the text screen with text characters. Bul the disadvantage of this univer- sality is that you have to move away from familiar Applesoft commands into a kind of Basic “Esperanto” that has a closer resemblance to the CP/Mor MS-DOS versions of MicroSoft Basic than to Applesoft. TBasic includes a full screen editor; is the only Basic mentioned here that allows you to completely do away with line numbers; provides for long, case- sensitive variables; and includes a feature called “long functions” you could use to emulate the modularity of Blankenship Basic, ProBasic, or Micol Basic. A lgs-specific version-is reportedly under development, Although capable of 2- to 54 digit precision, ZBasic's major weakness is the speed of ftoating-point calculations, which are nott- ceably slower than standard Applesoft at similar precision, The DOS 3.3 version of ZBasic runs on any 64K Apple, the ProDOS version requires 128K and won't work on a Il-Plus. ZBasic is not copy- protected and can be distributed on self-running disks by leaving in the copyright notice. ($49.95 for first package, $39.95 for others—all use the same manual—Zedcor, 4500 E Speedway, #22, Tucson. AZ 85712 602-881-8101). An Applesoft to ZBasic source-code translator program is available for $29.95 from Bringardner Data Products, 1736 E North Broadway, Columbus, OH 43224. Finally, out on the edge of the Basic universe ts Promal (see this month's front page), which is more Basic-like than most other computer languages. Beyond the edge of the Basic universe, don't forget that Apple II versions of Pascal, C, Forth, and Logo are also easily available,