Z*Magazine: 29-Oct-90 #186

From: Atari SIG (xx004@cleveland.Freenet.Edu)
Date: 10/02/93-03:37:08 PM Z

From: xx004@cleveland.Freenet.Edu (Atari SIG)
Subject: Z*Magazine: 29-Oct-90 #186
Date: Sat Oct  2 15:37:08 1993

           ==(((((((((( ==    Z*MAG/A\ZINE ATARI ONLINE MAGAZINE
           =========(( ===             October 29, 1990
           =======(( =====                Issue #186
           =====(( =======    ----------------------------------
           ==(((((((((( ==    Copyright (c)1990, Rovac Ind Inc..
                      Publisher/Editor : Ron Kovacs
                     Contributing Editor: Stan Lowell
   CompuServe: 71777,2140    GEnie: Z-NET     Z*NET BBS: (908) 968-8148
 by Ron Kovacs
 Happy Halloween..... Hope you are ready for another winter, cold
 temperatures, snow, ice and all those fun things we get ready for at
 this time of year.  I am looking at a yard full of leaves and get
 sick thinking about all the work that has to be done.  Just think, there
 are only 7 weeks till Christmas....
 News??? There isn't any worth reporting on.  In our regular Z*Net
 release two weeks ago, we reported on regular Atari happenings which
 were not the most popular.  As a matter of fact, that issue was the most
 negative Atari issue I have ever published.  Story after story left a
 very bad taste.....like...Atari Taiwan Indicted for piracy, Atari's
 Elie Kenan resigns and returns to Atari France, Apple takes in
 revenues of 5.5 billion, and other news that would make you wonder why
 Atari is still in business.
 So, I searched through the ZMag Archives and found news items which
 date back only to 1988.  One of which was Neil Harris' resignation and
 Sam Tramiels' very unpopular online conference.  A year later, 1989, we
 read again about promises not followed through and now in 1990, some of
 us await more promises of glory.  The 8-bit arena is dead, those that
 choose to stay do so because of loyalty to ur machines.  We run our
 BBS's on them, use them for projects and play the games with them.  I
 occasionally sit down with my 8-bit and play and miss the day to day
 applications I used to use.
 I wonder where the 8-bit would be today if Atari were to have supported
 it??  I know there are a handful of developers out there trying to
 produce products for the machine, but it is really a sad affair that
 the Atari ST/TT owners should take some time to review.  It is slowly
 happening all over again.  The only question is how long does the ST
 I do not want to drag you through the depression of Atari.  The machines
 are decent and worthwhile owning.  That alone is something to be happy
 about.  Notice I didn't use the word "proud".  I am not proud of Atari.
 I am disgusted that I am made to feel that I made a mistake purchasing
 all of the Atari products, from the Atari 800 through the MEGA series.
 I will continue this commentary in the weeks ahead or when I have the
 time to sit and out my thoughts down.  I welcome others comments on the
 past or future and would like to see some continuing dialog take place
 here.  If you have something to add, please pass it along.
 I want to also thank the few who have sent me letters.  It is 
 encouraging to read some mail that is positive about Z*Mag.  I have
 taken some of the comments seriously and re-focused the contents and
 will continue to do so.  So please keep the comments coming.
 This week we welcome Stan Lowell to the staff as Contributing Editor.
 I have more comments on this at the start of Stan's column.  Welcome
 and thanks for the support!!!!
 So, on we go with Issue #186.  Imagine... 186 issues of ZMagazine out
 there....  Sheesh!!!  This publication is older then my children!
 by Stan Lowell
 Ever hear "There's nothing new for eight bits?"  Maybe not mountains,
 but new hardware and software are still kicking!  Refinements are being
 made to what is out already too!  Not on as grandiose a scale as in the
 heydays of course, but they are out there!
 The biggest problem as I see it: communications.  Spreading the word
 around.  I have seen messages from people who know NOTHING of ICD,
 SpartaDos, the Black Box, and on and on.  These were not posted by new
 comers to the Atari arena, these were from people who have been using
 their machines for a few years!  We still have the Antic "insert" in
 STart Magazine, but that is the last commercial stateside resource left.
 This on-line magazine, ZM/A\gazine, is a good source.  Where does ZMag
 get its material?  From user groups and readers who submit articles,
 reviews, letters, or just information to it.  In short, YOU the readers,
 help to support it.
 There are other resources around.  User Groups are a VERY GOOD resource
 for both problems you may be having and for information about new things
 which may be "out and around" someplace.
 Bulletin Board Systems(BBS) are another good resource for information
 and help.  Many ST Bulletin Boards feature message networking to some
 degree.  Even 8-bit Bulletin Boards have message networking.  My BBS,
 FoReM-XE Professional, has had it for well over a year.  Express Pro!,
 Carina ][, and I believe Puff BBS have message networking.
 Networked messages are a fantastic way to find out about new things, get
 help with problems, answers to questions, or just have a good
 conversation.  Most of you probably know about a BBS.  Otherwise, you
 wouldn't be reading this! <Grin>  If you don't, then you are missing one
 heck of a good time!  Get a modem, get a terminal program, and jump
 Most new commercial software for the eight bit Ataris comes from
 overseas.  I have heard of a place or two in the UK which will mail
 order to the U.S.  Don't know of any stateside places which carry any
 kind of inventory for us 'old timers.'  If you know of some, let me
 Public Domain and Shareware programs are still alive and well.  New
 revisions are out for TextPro and DaisyDot3.  John McGowan in Saint
 Louis, Mo. has written several programs which will let you print icons
 in your text using DD3.  New Versions of Snapshot are out.  Snapshot
 allows you to have 2 different programs in an expanded XL or XE and
 switch between them.  There is a version for hard disk owners which
 allows for up to ten programs on your hard disk.  SUPPORT SHAREWARE!
 On the hardware side, TransKey has been out for some time.  TransKey
 allows you to hook up a standard PC type keyboard to your XL/XE, and
 includes keyboard macros!  From all reports I have seen, it is an
 excellent product.  The prolific support given by CSS' Bob Puff
 continues.  Rumored to be in the works is a chip for an XF551 which will
 allow both the 5-1/4 and 3-1/2 drives to be on-line at the same time!
 Also coming is a controller for the Black Box which will allow reading,
 writing, and formating of PC, ST, and 8-bit formats!
 WEll, that's about it for now.  As I find out about, or remember new
 "things," I will pass them on in a future article.  If you know of, or
 use a product or program, let me know about it.  I can be reached on the
 Z*Net BBS, GEnie(S.Lowell), or on my BBS(Blank Page BBS - 908-805-3967,
 3/12/2400).  'Til next time...
 Editors Note:  Stan Lowell is a long time friend and supporter of 
 Z*Magazine.  His guidance in the early days helped Z*Mag stay on course
 during rough times.  Stan has also been a support sysop for Z*Magazine
 BBS systems during the past 5 years and his assistance with the new
 Z*Mag is greatly appreciated.  Please leave Stan a message and encourage
 him to continue writing!!
            by John Picken
 Everything You Wanted To Know About Using Your Printer!
 (Reprinted from the Puget Sound Atari News, October 1990)
 Many computer owners claim the "raison d'etre" for their system is
 productivity software - data base, word processor, etc. At least, that's
 how they justify the time and money spent to a disbelieving spouse;
 after all, Rule 1 of personal computing is: "Never admit to owning a
 Assuming the owner is actually going to use the system for more than
 PacMan, the most important component becomes the printer.  Application
 software is nearly worthless without a means of presenting permanent
 results.  Unfortunately, the printer is often the most underutilized
 component in a system because it is the least understood.
 Using a printer is not terribly complex though it sometimes seems so
 because of the instruction manual.  Usually, all the information you
 need to learn to control any printer can be found in its manual, albeit
 with some errors.  You often get better results by regarding the manual
 as a collection of hints to provide a basis for experimentation.  Why
 this is so is anyone's guess, but you can add this to the collected
 wisdom of Murphy: "Quality of documentation varies inversely with
 printer sophistication."
 Printers come in all shapes, sizes, and prices.  They may be broadly
 categorized by the way they mark the paper.  Laser machines produce
 superb results at a superb price.  It is my understanding that they
 print using techniques similar to Xerography but I haven't really looked
 into them because of lack of opportunity (read "lack of dollars") to
 play with one.
 "Letter Quality" printers produce characters by the single impact of a
 complete form, whether it be on a wheel, drum, ball or typewriter key.
 This category runs from top of the line "Daisy Wheel" machines down to
 the old Atari 1027.  Prices range from high to low and, correspondingly,
 speeds from fast to dead slow.  All however, have two common
 characteristics:  First, if character size and style is changeable, it
 can only be accomplished by replacing the printing element.  Second,
 they are mechanically complex and usually noisy.
 "Dot Matrix", the most commonly used printers, produce images by
 patterns of dots similar to the way an image is drawn on a television.
 Dots may be formed by ink jets or thermal paper but most commonly, are
 produced by "pins" striking a ribbon over the paper.  "Nine-Pin" dot
 matrix machines are the subject of this discussion.
 While it is possible to find older models with fewer, the standard is
 nine pins, though only eight are normally used at any one time.  The
 pins, also called "wires", are arranged in a vertical column.  Images
 are produced by moving this column across the page while "firing" or
 "striking" the pins in various combinations.  The difference from a
 television is that the printer does up to nine rows of pins at a time.
 Why use only eight of nine, and why these numbers in the first place?
 Well, eight is the closest thing you will find to a "magic number" in
 the world of computing because a "byte", which is normally the smallest
 usable amount of data, is always made up of eight bits.  The printer is
 able to interpret the bits separately, so the bits of a single byte can
 be used to control firing of eight pins.
 The ninth pin is there for things like underlining or descenders on
 lower case letters.  The printer normally only uses eight pins but it
 may switch between the top or bottom eight.  Try underlining on most
 printers and you'll notice that the underline runs into lower case
 descenders.  There are nine-pin graphics modes but they are rarely used
 as a complete second data byte is required for the addition of only one
 more pin.  Essentially, you can ignore the existence of the ninth pin
 unless you want to get into more advanced subjects like download
 "27-Pin", also called "24-Pin", printers are nearly identical, but have
 three such pin columns mounted closely side by side with a slight
 vertical offset between each.  This arrangement produces much higher
 quality characters than is possible with nine pins.  Once you get beyond
 simple text printing, these become more complex as you obviously need at
 least one byte to control eight of the pins in each of the three columns
 and the equivalent of the nine-pin mode would require a total of six
 data bytes.
 The key to understanding how dot matrix printers work, and therefore,
 what is and is not possible, lies in the name.  They cannot produce any
 image other than a "Dot" - everything they print is formed from dots.
 The "Matrix" part of the name describes something which, physically,
 does not exist.  It is a human concept represented by a collection of
 bytes in the printer's memory.  The printer's "Firmware" (program in
 ROM) interprets these as a pattern of pins to fire to form a particular
 character.  Mechanically, that's it: the printer can produce only dots.
 Firmware and software control pin firing, paper feed, and carriage
 motion to arrange these on the paper.
 While printer response to any particular byte is governed by firmware,
 this response can be modified.  Sometimes this can be done by switches
 but many features are not controllable except by software.  In other
 words, the computer must command the printer remotely.
 Like any other kind of remote control, communication is required.  A
 small part of this consists of actual electronic signals.  Most,
 however, is exercised by the computer talking to the printer in a
 language it understands: patterns or sequences of data bytes.  This is
 where the user enters the picture via a word processor or other program.
 Getting what you want out of your system requires you to give both the
 printer and the word processor the proper commands.  The word processor
 contains a block of data holding the information it needs to control
 your particular printer.  This is changeable, normally by load from
 disk.  There are numerous names used to describe these: "Printer
 Driver", "Printer Description", and "Configuration" files being some of
 the more common.  No matter what they're called, they are functionally
 bilingual dictionaries which the word processor uses to translate
 something like "underline from here to there" into language the printer
 If your system is not producing up to its capabilities, the source of
 the problem may very well be this file.  Most word processors come with
 a utility program to allow you to change or customize the printer
 driver.  The catch is you've got to read and understand the
 documentation, both for the word processor and the printer, and you have
 to know what is and is not possible.  Understanding of a few terms and
 measurements aids in this task.
 "Buffer" is commonly used but not always understood.  A buffer is just a
 reserved area of memory for temporary storage of bytes.  When dealing
 with printers, there are at least two buffers involved, one in the
 computer and one in the printer.  Eight-bitters have a buffer in the
 interface as well which serves the same purposes as printer buffers.
 Buffers allow transmission of multiple byte blocks of data.  This
 decreases time lost on "Handshaking" signals and calculation of
 checksums.  Also, since the printer can't print anywhere near as fast as
 the computer can send, it accepts and stores as many bytes as it can so
 that the computer is free to move on to other business sooner.
 Obviously the bigger the printer buffer, the sooner the transmission is
 The second purpose of the printer (and interface) buffer is to allow it
 to examine and modify the data before it is printed.  It has to sort out
 printable data from commands, make any required conversions such as
 ATASCII to ASCII or addition of auto linefeeds, and possibly, calculate
 right justification, etc.  Once this is done, it determines how, and at
 what point in the printout, to apply the commands.
 Most printers actually have two buffers - everything that comes in goes
 to the "Receive Buffer".  Printable stuff is then moved and held in the
 "Print Buffer".  The importance of this distinction is that some
 commands affect only the print buffer - you have to read and decipher
 the book.
 Part Two of the article will appear in Issue #187.
 by Mike Brown
 One of the things that we, as Atari owners, are told should be done to
 assure the survival of Atari computers in the US, is to get Atari
 computers into the schools.  Recently, I was invited to attend and
 participate in a very large educational "Tech Expo" sponsored by the
 North Central Regional Educational Laboratory, The Urban Education
 Network, The Office of Educational Research and Improvement (US
 Department of Education), Chicago Public Schools, and Illinois Institute
 of Technology.
 This show and conference was attended by representatives of the 13
 largest urban school districts in the Midwest along with the State
 Departments of Education for the states of Illinois, Indiana, Iowa,
 Michigan, Minnesota, Ohio and Wisconsin.  Doesn't this sound like a
 crowd that should be exposed to "Power without the price"?
 My ticket into this exclusive gathering of educators and school system
 policy makers was my volunteer work with a Chicago Public Schools funded
 project to develop a "...conference conduit for users of all ages and
 background with any type of computer to share ideas. (the system) will
 erase the boundaries between schools and the greater community and
 provide support for classroom teachers...".  If you guessed that this
 sounds like a multi-line BBS system, you win the star prize!  Our BBS
 system currently has eight concurrent lines (with multichannel CHAT
 capability) on a UNIX minicomputer provided by Unisys.  The system
 (which has just celebrated it's first birthday) is called the EIES 
 (Electronic Information Exchange System) of the Chicago Public Schools.
 Give us a try at (312) 890-8512 1200/2400 and (312) 890-7828 9600.
 Visitors welcome!
 NCREL asked me if I'd be available the opening day of the show to staff
 a booth with other technical volunteers, I offered (sneakily) to work
 Saturday if I could use equipment and software that I was already
 familiar with.  The organizers said "no problem, you can bring in what
 you want to demo the system on".  A neighbor, good friend, and LCACE
 guiding light, Dwight (J.J.) Johnson volunteered his new STacy for use
 at the show, this would be the hot show setup in a world of dull MS-DOS
 and Apple systems.
 The gleaming new STacy was the star of the EIES booth- I drew a large
 number of comments from attendees about the STacy, and made some
 contacts with educators who use 8-bit Atari systems (most notably with
 LOGO) in classroom situations.  A group of students (helping in the huge
 5000 sq ft Apple "School of the Future" exhibit) stopped by to play with
 the STacy and had very favorable comments.  Near the end of the day, the
 EIES sysop regretted the fact that I had chosen to set up so near the
 aisle, as the STacy could have drawn people "into" the booth (yes, but
 it was more visible at the end!).
 At the show, I was surprised by the large outlay that IBM and Apple 
 Computer made in equipment, staff, hospitality and outside exhibitors.
 Their presentations were easily as elaborate as what you might see at a
 COMDEX show.  Zenith, Tandy and Pioneer America had more modest (but 
 interesting) booths.  While developers such as Advanced Voice
 Technologies, Inc., Computer Curriculum Corporation, The ERIC
 Clearinghouse on Urban Education, Ed Tech, Encyclopedia Britannica, and
 TI-IN Network each had "one table" booths swarming with interested
 educators.  Over 60 different sessions were presented during the 3-day
 conference.  These sessions were held by exhibitors, software vendors,
 as well as educators themselves.  There were ongoing sessions in the
 Faculty Club room sponsored by Apple, and IBM had constructed a
 "Decision Support Center" to privately hawk their multimedia products.
 It was a very revealing experience shmoozing with educators and
 administrators, soft pedaling the Atari Advantage.  One of the more
 frightening revelations of the conference, was the stranglehold that
 Apple Computer has on the US educational market, and the mind set of the
 educators.  I constantly heard educators referring to computer labs as
 "Apple Labs".  This seemed to make as much sense as calling Driver's Ed,
 "Chevrolet Training" or Home Economics, "Kraft Class".  Before I was
 even in the show proper, an educator asked me "Is this the place where
 the Apple Expo is?"; my reply is not suited for a publication read by
 young persons, so it will remain unreported.
 Anyway, thank you to Carole S. Fine, Dennis Tokoph, NCREL, and all of
 the others that made it possible for STacy and Myself to play a small
 part in the shaping of solutions to educational problems in urban
 For more information on future Tech Expos, or general information on
 High-Tech, High-Touch and High-Teach resources for your local schools,
 please contact NCREL at 295 Emroy Avenue, Elmhurst, IL 60126 (708) 941-
 Acclaim announced this week that it will release its "Bartman: Avenger
 of Evil" hand-held in November.  Under an exclusive licensing agreement
 with 20th Century Fox Licensing & Merchandising Corporation, Acclaim is
 publishing Nintendo Entertainment System and Game Boy video games as
 well as SuperPlay hand-helds based on the "Simpsons".  "Bartman: Avenger
 of Evil" is expected to retail for approximately $19.95.
 Courtesy GEnie Atari 8-Bit Roundtable
 DataQue Software is currently developing a C programming language for
 Atari 8-bit computer systems.  Your input on the following questions
 will allow us to shape the product to your needs.  You may also ask any
 specific questions you may have in the Atari 8-bit BB area on GEnie,
 Category-3, Topic-15.  Of course email to DataQue.1 is also accepted.
 There are 25 total questions in this survey.  Some questions require
 one answer, others allow multiple answers.  You will have a chance to
 send comments following the survey.
 1. What is the main programming language you use (if any) ?
    A. Atari BASIC         B. Turbo-BASIC XL      C. BASIC XE, or XL
    D. Pascal              E. C                   F. Forth
    G. Action!             H. Assembly/Machine Language
    I. Another language not listed above
    J. I do not program at all currently
 2. If there is another programming language you also use often, what is
    A. Atari BASIC         B. Turbo-BASIC XL      C. BASIC XE, or XL
    D. Pascal              E. C                   F. Forth
    G. Action!             H. Assembly/Machine Language
    I. Another language not listed above
    J. I program only in one language
    K. I do not program at all
 3. Of the C languages you have used (if any) for the Atari 8-bit, which
    do you consider to be the most usable?
    A. Deep Blue C         B. Lightspeed C        C. CC8
    D. CC65                E. One not listed above
    F. I have not programmed in C on the 8-bit Atari
 4. What is the primary feature you would look for in a compiled
    language system?
    A. Fast compile/link time         B. Fast resulting code
    C. Small resulting code           D. A rich function library
    E. Ease of use                    F. Unsure
 5. What is the second most important feature you would look for in a
    compiled language system?
    A. Fast compile/link time         B. Fast resulting code
    C. Small resulting code           D. A rich function library
    E. Ease of use                    F. Unsure
 6. In your opinion, what has been the major fault in compiled languages
    on the Atari 8-bit computer system?
    A. Total compile/link time        B. Resulting code execution speed
    C. Size of resulting code         D. Function library not complete
    E. Functions not fully developed  F. Too complicated to use
    G. Unsure
 7. Because of the limitations of the standard 6502 stack, some limits
    or options have to be taken concerning stack use.  Which of these
    options do you feel is the most acceptable?
    A. Limit the number of bytes passed as parameters to 16 or so
    B. Pass parameters on a pseudo-stack
    C. Pass parameters in a fixed memory block
    D. Unsure
 8. Many people have requested larger variable types be offered, what do
    you feel is the most apropriate (non-floating point) type?
    A. INTeger (16-bits)              B. EXTended integer (24-bits)
    C. LONG integer (32-bits)         D. BOTH 2 and 3
    E. Unsure
 9. What do you feel about floating point support?
    A. Support Atari 48-bit BCD format
    B. Support ANSI 32-bit format (FLOAT)
    C. Support ANSI 64-bit format (DOUBLE)
    D. No floating point needed
    E. Unsure
 10. An overlay linker allows you to section off large programs into
     smaller blocks, which only one block is visable to the processor at
     a time.  This requires disk caching, bank switching or other means
     to select an 'overlay' to use at any given moment.  Which of the
     following do you feel is most apropriate?
   A. Support XE type banked memory for overlays
   B. Support disk caching for overlays
   C. Allow the user to select either one
   D. Overlays are not necessary
   E. Unsure
 11. What is the largest amount of memory on any single Atari 8-bit
     computer you currently own?
   A. 16k      B. 32-48k      C. 64k      D. 128k
   E. 400/800 with over 48k   F. XL/XE with over 128k
 12. Do you normally use a RAMDisk when developing code?
   A. Yes      B. Not available on my machine
   C. No       D. Unsure
 13. Do you own a Turbo-816 upgraded machine?
   A. Yes, no expanded/explicit memory
   B. Yes, with 32k-64k of expanded/explicit SRAM
   C. Yes, with over 64k of expanded/explicit SRAM
   D. No
 14. If you own, or are considering owning a Turbo-816 upgrade, would
     you be interested in a native mode development package?
   A. Yes, I would be interested
   B. Would consider a T816 if there was such a package
   C. No, not interested
   D. Unsure
 15. Do you own another type of computer system?  If you own more than
     one, the system you use most often.
   A. Atari ST         B. Commodore 8-bit        C. Amiga
   D. Macintosh        E. Apple //               F. MS-DOS Compatible
   G. No other system
 16. What disk operating system would you normally expect to use with a
     C development system?
   A. Atari DOS 2.x and Clones        B. MYDOS
   C. Disk Based SpartaDOS            D. SpartaDOS-X
   E. OSS DOS+                        F. Other DOS
   G. Unsure
 17. What is the largest capacity drive (not counting any RAMdisks) on
     your system?
   A. Floppy, under 175k              B. Floppy, 175k to 199k 
   C. Floppy, 200k to 399k            D. Floppy, 400k or more
   E. Hard Drive                      F. Unsure
 18. Do you use an 80 column screen device on your Atari 8-bit for
     editing text files?
   A. Atari XEP-80                    B. DataQue MV80
   C. Other Hardware 80 column adapter
   D. Software 80 column emulator     E. No, only 40 column
   F. Unsure
 19. A source level debugger allows you to debug your executable program
     like other debuggers, but allows references to your original source
     code to be maintained.  How should such a product be sold?
  A. As a seperate product
  B. As an integral part of the system
  C. Both
  D. Not needed at all
  E. Unsure
 20. A profiler allows you to optimize your code by providing
     information on how long various portions of your code take to
     execute, as well as how often they are executed.  How should a
     product like this be sold?
  A. As a seperate product        B. As an integral part of the system
  C. Both                         D. Not needed at all
  E. Unsure
 21. Many C compilers generate an intermediate assembly file which is
     assembled, rather than generating object code directly.  What would
     your preference be?
  A. Compiler generates assembly source
  B. Compiler generates object code
  C. User selectable at compile time
  D. Offer two compilers, one for each type
  E. Unsure
 22. Would you prefer the C language system to contain an integrated
  A. Yes, include an editor        B. No, it is not needed
  C. Unsure
 23. For a complete C language system containing a compiler, assembler,
     linker, debugger, profiler, and editor, what do feel would be a
     reasonable asking price for that product?
  A. Free        B. Shareware, under $20        C. $20-$30
  D. $30-$50     E. over $50                    F. unsure
 24. What would be the media you would prefer a such a C language system
     to be offered on?
  A. Cartridge        B. Disk        C. Either one
  D. Unsure           E. I would not be interested
 25. Would you like to send written feedback at this time?
  A. Yes
  B. No
 This concludes the survey.  Thank you for taking time to reply.
 8-Bit Programming Tutorial - Part 1
 by John Picken
 (Reprinted from the Puget Sound Atari News, August 1990)
 When computer owners speak of "Machine Language" they usually mean
 "Assembly Language" (which is considerably simpler to learn).  Though
 incorrect, I'll refer to Assembler as "ML" since it's common and
 convenient.  Many people start learning it by reading a book on the
 subject, but all too often that's as far as they get.  There are various
 reasons for this, one of the major ones being the perception that you
 have to start from scratch and write a complete and detailed ML program.
 ---- You don't.
 ML is easier to learn than any other computer language because you can
 start by writing short routines for call from BASIC.  The beauty of this
 approach is that your routines do not have to be long or complex to be
 useful.  I hate learning a language by typing 10 PRINT "THIS IS A LINE"
 Atari's USR function is one of the best ML interfaces among popular 8-
 bit BASICs.  This article first covers the passing of data to and from
 a USR routine and how the routine can "find itself".  Then it discusses
 and demonstrates programming and assembler techniques which can help you
 write USR routines that pack more power per byte.
 One important pre-condition: a USR routine is not a stand-alone program
 but rather an extension to BASIC.  This means that when writing one, you
 must keep BASIC's limitations and requirements in mind.  For example, if
 your routine is to be placed in a string, which is preferable, it must
 be relocatable and should not contain characters that require special
 treatment ([RETURN] and the quotation mark) -- remember the aim is to
 make life easier for the BASIC program.
 Many BASIC's require a series of POKE's to pass values to a ML routine.
 Atari BASIC is much friendlier; you simply specify the variables, up to
 26 of them, and BASIC pushes them onto the stack for you before entering
 the routine.  The most important thing about these is that parameters
 are always numbers -- never strings.  Since BASIC regards all numbers as
 floating point (FP) values, they get passed to the routines in ROM for
 conversion to two-byte integer.  So no matter what value you pass, even
 0, a parameter is always two bytes.
 All these parameters must be cleared from the stack before the routine's
 exit to BASIC via RTS.  Of course you don't pass variables just to clear
 them.  To use them, you need to know that BASIC pushes the last one
 first.  This means that parameters come off the stack in the order you
 put them in the USR statement.  Equally important: BASIC pushes the
 least signifigant byte (LSB) first.  This means parameters come off the
 stack MSB first.  Note that this is the reverse of the order in which
 the 6502 pushes return addresses.
 Finally, BASIC tells the ML routine how many arguments were passed.
 This value is the last item pushed onto the stack, is always a single
 byte, and is always there -- even if you passed no parameters.  This
 accounts for the one disadvantage in the Atari BASIC USR implememtation:
 You can't call a ROM routine from BASIC, you always need at least one
 PLA which can only be done in ML.
 The single, important address with USR is Floating Point Register Zero
 or FR0.  It consists of six bytes starting at $D4 on Page Zero though
 we normally only need be concerned with the first two of them.  FR0 is
 the primary address for passing data to and from the ROM FP package.
 It's always used when converting between ATASCII and integer.  This
 means that if a value is to be passed back to BASIC, it would make sense
 to leave it at FR0 for ready conversion to floating point.
 Not only does it make sense, it's what BASIC expects.  BASIC always
 returns the floating point representation of whatever two-byte integer
 it finds at FR0 when you exit a USR routine.  If you called the routine
 using X=USR(... then X will be assigned the value in FR0.  If you
 programmed PRINT USR(... then the value in FR0 will be printed.
 Remember this is a two-byte value, so if you want the routine to return
 a meaningful value, you must store both bytes: FR0 and FR0+1.  If you
 store neither, the address of the ML routine will be returned.
 The other important aspect to FR0 is that to enter your USR routine,
 BASIC has to use FR0 to convert the address from FP to integer that can
 be placed in the Program Counter.  As it happens, the last value that
 BASIC converts, prior to entering a USR routine, is the routine's
 address.  This neat little fact means that your routine can always know
 where it is -- the starting address is left in FR0.
 When BASIC encounters a USR statement within a program, it does a JSR to
 routines within the interpreter to handle it.  This code, first,
 converts and pushes the variables and their count as outlined above.
 (Remember, the count is the number of two-byte values, so twice that
 many single bytes will have to be pulled.)  After that, the routine's
 address is converted and left at FR0.
 Finally, to enter the routine, BASIC executes a simple JMP (FR0).  Since
 the routine is entered via JMP, the only return address on the stack is
 the original one buried under (above actually) the parameters.  Once
 these are removed, RTS will take control back to the BASIC program.
 As an example consider a routine held in ML$.  Let RTB indicate the
 return address, and < and > indicate LSB and MSB.  Assume also, the
 Stack Pointer is at $F2 when BASIC encounters
 X=USR(ADR(ML$),345,65500,7).  Upon entry to the routine, the Stack
 Pointer will be at $E9 and low RAM will look like the following:
  $01FF      ...      Bottom of stack
  $01FE      ...      Previous data on stack
   ...       ...                 "
   ...       ...                 "
  $01F2    >RTB-1 <== Stack Pointer was here
  $01F1    <RTB-1
  $01F0      $07      <7      Param 3 LSB
  $01EF      $00      >7          "   MSB
  $01EE      $DC      <65500  Param 2 LSB
  $01ED      $FF      >65500      "   MSB
  $01EC      $59      <345    Param 1 LSB
  $01EB      $01      >345        "   MSB
  $01EA      $03      3 parameters total
  $01E9      ...  <== Stack Pointer now here
   ...       ...
  $0100      ...      Top of stack
  $00FF      ...      Top of Page Zero
   ...       ...
  $00D5   >ADR(ML$)   This is FR0+1
  $00D4   <ADR(ML$)     "   " FR0
 The routine has to pull seven bytes off the stack before getting to the
 return address.  Keep in mind that the stack grows down from $01FF to
 $0100 and that the stack pointer indicates the next free spot in the
 stack. (This is different from some other microprocessors).
 Registers: Since you only have three internal registers, it shouldn't be
 hard to make use of all of them.  If your routine is neglecting X or Y,
 it's probably wasting bytes.  If you don't specifically need one, then
 keep it in a known state, such as one, zero, $FF, etc.  Then you can use
 register transfers, increments and decrements to save bytes.
 Direct Operations: Another important technique is operation directly on
 addresses (even hardware ones) using INC, DEC, ROL, etc.  Direct address
 operations save time and space.  For example, consider addition of one
 byte to a two byte total.  Most programs use the method shown below
 left, but the code on the right uses fewer bytes and is faster, even if
 you need to add a CLC at the exit point.
     CLC                    CLC
     LDA TOTAL              LDA TOTAL
     ADC #VALUE             ADC #VALUE
     STA TOTAL              STA TOTAL
     LDA >TOTAL             BCC EXIT
     ADC #0                 INC TOTAL+1
     STA TOTAL+1      EXIT  ...
 EXIT ...
 Page Zero: The 6502's treatment of Page Zero gives you, in effect, an
 additional 256 semi-internal registers.  Consider the code below,
 assuming the labels define Page Zero addresses.  The listing on the left
 uses ten bytes and 29 machine cycles while the code on the right
 achieves the same thing using two more bytes.  The code on the right,
 however, uses only 18 machine cycles and has a major advantage -- you
 can access the saved values in any order, at any time.
 PHA                 STA ASAVE
 PHA                 STX XSAVE
 PHA                 STY YSAVE
 ...                 ...      
 ...                 ...      
 TAY                 LDY YSAVE
 TAX                 LDX XSAVE
 PLA                 LDA ASAVE
 So to shorten and/or speed up your routines: use all internal registers,
 operate directly on addresses, and use Page Zero.  And with Page Zero,
 don't limit yourself to the few bytes that BASIC doesn't need.  You can
 usually appropriate all the FP Page Zero RAM and often, depending on the
 routine, the i/o RAM at $15-$4B.  Both sample routines use large amounts
 of the FP area without any problems.  These techniques allow packing a
 lot of features into very little space -- the second example (disk)
 routine fits into only 280 bytes.
 Maximize your use of loops to minimize RAM use.  Available RAM is
 usually not a problem especially if the routine is held in a string --
 the object here is to shorten and simplify the BASIC program.  If the
 routine can be fitted into a single BASIC statement, you save, not only
 space, but also use of a variable, so you can program
 X=USR(ADR("h etc."))
 When using loops, don't be afraid to stuff garbage into addresses that
 don't matter.  For example, to set up an IOCB, you normally store data
 in seven spots between ICCOM and ICAX2.  Each address requires five
 bytes of code (a LDA #data followed by a STA $addr), so that's 35 bytes.
 Using a loop and a data table, you can accomplish the whole effort in 20
 bytes.  Simply put zero (or anything) into ICSTA and ICPTL/H -- no
 matter what you put there, the OS will put what it wants in them later!
 Two BIT Tricks: In my opinion, the only valid use for macro's in USR
 routines is to enhance readability; any other use results in wasted
 bytes and duplication of code.  In the sample routines, readability is
 the reason for definition of the SKIPWord macro (really a BIT
 To understand the BIT tricks, consider an example where you want to
 change the X or Y register depending on your entry point to a common
 routine.  If your code looks like the following, you achieve the desired
 result in very few bytes.
 6000         0100         *=  $6000
 6000 E8      0110 XUP.2   INX
 6001 E8      0120 XUP.1   INX
 6002 2C      0130         .BYTE $2C
 6003 C8      0140 YUP.2   INY
 6004 C8      0150 YUP.1   INY
 6005 24      0160         .BYTE $24
 6006 88      0170 YDOWN.1 DEY
 6007 2C      0180         .BYTE $2C
 6008 CA      0190 XDOWN.2 DEX
 6009 CA      0200 XDOWN.1 DEX
 600A 60      0210 EXIT    RTS
 If you enter at YUP.1 the following occurs: Y is incremented, a BIT test
 is performed on location $88 ($88 = DEY), another BIT test is done on
 $CACA ($CA = DEX), you exit having affected only the Y register and
 having saved several bytes for branches albeit at the cost of a little
 extra time.  Remember always though, that BIT affects these flags:
 N Z V.
 Beginning Stages: You will often find it easiest to program your routine
 in Turbo BASIC (using line labels) before putting it into ML.  This way
 you can develop and test the algorithm before getting into the
 assembler.  Remember you can include hex and bitwise logic with Turbo.
 When using this method, I suggest you restrict your code to one
 statement per line, use line labels and avoid the use of IF.  Since ML
 has no direct IF-THEN or IF-ENDIF equivalents, you should use ON-GOTO
 which translates more easily.  Note that there is an advantage to
 ON-GOTO even in BASIC -- it can be used in multi-statement lines.
 Comments: Comments don't cost anything in the assembled code, so don't
 be afraid to make ample use of them.  The sample routines are
 extensively commented.  This was not done for the sake of this article
 -- the comments were necessary to allow me to alter and add to the
 routines (in the case of the second one, over a couple of years).
 Remember that what seems obvious and clever today, can be incredibly
 obscure a month, or even a day, from now when you want to modify what
 you've done.
 I suggest you keep your comments in lower case so they don't interfere
 when you want to use FIND or REPlace.  If you keep the lines short (1
 screen line), you can fit two columns of code on each page for printouts
 (use Elite print and a word processor to operate on an ASCII file).
 This makes debugging easier since you can examine twice as much code at
 a time.
 Next Month:  Part 2 will conclude with 'assembler techniques and
 tricks', and two example programs.
               by David Plotkin
 This feature is a reprint from the OCTOBER/NOVEMBER ST-JOURNAL MAGAZINE,
 presented here by permission.  THIS ARTICLE MAY NOT BE REPRINTED IN ANY
 JOURNAL, 113 West College Street, Covina, CA 91723, 818-332-0372.
 I've been involved with Atari computers for a long time - longer than
 most.  I got into them strictly by accident when I attended the SF
 Computer Faire in 1980 and was fascinated by the many Apple II's.  What
 really caught my eye were the games - I'd never seen anything like them
 except in the arcades, but I couldn't afford the humongous number of
 quarters that arcade machines were designed to gobble.  Also, I couldn't
 afford to pay over $2,000 for an Apple II and a disk drive.  A local
 computer dealer sold Ataris (yes, they really did in those days), and
 so, in May 1980, I plunked down $800 for an Atari 400 with 32K of memory
 and a tape drive.  The dealer later admitted that he really made me a
 better deal than he should have!
 I also bought Star Raiders which, to this day, remains one of the
 premier computer games of all times.  About a month later, when I came
 up for air, I started looking around for something else to play.  There
 was very little.  I had violated the prime rule for computer purchase -
 buy the machine that will run the software you want to use.  I decided
 to attack this problem in two ways.  The first was to learn to program.
 The results of that effort were not very satisfactory because I was
 using the Atari Basic graphics, etc.  The results ran but were so slow
 as to be useless.
 Magazine connection
 The second line of attack was to start buying magazines.  In those days,
 there were two magazines that covered the Atari: Compute! and Softside.
 These were similar - each had a section devoted to the multiple machines
 they covered.  Type-in listings were featured, along with tutorials, and
 I read these avidly, painfully, learning the tricks of programming, as I
 went along, and playing the games that I had laboriously typed in.
 There were also advertisements for quite an assortment of software on
 tape-cassettes.  I was in heaven - I quickly ordered a large selection
 of the more interesting looking stuff and soon discovered two things.
 The first was that most of this software was abysmal - slow, not much
 fun, and, after only a very short time, boring.  It needed to be
 reviewed so that people didn't buy "blind" based on frequently
 misleading ads.  The second thing I learned was that software (whether
 good, bad, or indifferent) is expensive.  I couldn't possibly afford
 everything I wanted.  So how was I to get all I wanted without having to
 pay for it?
 Writers wanted
 Being a relatively honest sort, stealing it didn't appeal to me.  What I
 did was set myself up in the reviewing business.  I phoned the editors
 of the magazines and explained that I could review software.  All they
 had to do was send it to me - or I would be willing to phone the
 software company and ask for it to be sent to me directly on the
 strength of the assignment.  Believe it or not, the editors were
 delighted.  Finding someone who was at all familiar with computers and
 also who could write was a rarity.  (I'm told that it still is to some
 In all the years I've been writing, I'm proud to say that I've never
 missed a deadline - and there have been some pretty tough ones.  Editors
 love that.  Running a magazine is tough, and knowing that they have
 people they can count on is priceless.  I have had calls asking for some
 major piece of software to be reviewed - with a deadline only a week
 away - and have pulled it off.  This policy of being dependable has
 served me well down through the years with Analog, ST Log, Antic, START,
 Video Games, and now ST Journal.
 A lot of people have seen me getting all this wondrous software free and
 have become convinced that I have it made.  Well, it is pretty nice -
 especially since I get paid for the reviews, as well.  But it's also a
 lot of work and carries a fair burden of responsibility.  You see, along
 with all the good stuff like WordUp and Touch-Up, LDW Power and Dungeon
 Master, there is some really awful stuff - the kind you wouldn't waste
 your time with; you'd either reject it, after a short trial in the
 store, return it to get your money back, or just reformat the disk and
 kiss your investment goodbye.  I can't do that.  I've been assigned to
 review it and that's my job, as unpleasant as it sometimes can be.  A
 good example is my currently working review of STEVE, the ST Event
 Editor.  This is integrated software; word processor, database, desktop
 publishing, and a few other things all put together into one huge
 package with a 600 page manual.  The software isn't bad, just huge and
 not particularly interesting.  But I can't just put it aside for some
 other time - I've got to get a review out on deadline.  If I don't, my
 credibility suffers.
 Responsibility enters the picture because I am relatively well known.
 It has been a long time since I have called a software or hardware
 manufacturer to request a review copy and they haven't known who I am.
 When I write a review, people listen and make buying decisions based on
 what they read.  Since ST Log folded, my review may be the only one they
 see.  What this means is that a lot of care must be put into evaluating
 the product.  If, at first glance, it appears really awful, I must keep
 digging and evaluating to make sure I don't say it's awful without
 giving the software every chance to prove itself.  One product (an
 alternate desktop) completely defeated me.  I couldn't even get it
 installed.  The files that I was supposed to work with weren't on the
 disk, and others that were not mentioned in the manual were present.
 After struggling with it interminably, I finally gave up.  But I really
 tried far harder than if the software had been for my own use.  Had I
 purchased it for myself, I would have simply mailed it back and gotten a
 refund.  (Always buy software with your credit card because you can get
 your money back if it turns out to be unsuitable.)
 But I must remember that people are going to read what I say and factor
 this into their decisions.  It's sort of daunting to realize that my
 single article may influence a substantial part of the income of a
 software or hardware vendor.  So I have to be fair and impartial and do
 a thorough job with each review, and, on top of that, write well and
 provide interesting material for my readers.
 So much for the idyllic life of a reviewer!  As you can see, it's hard
 work and carries a lot of responsibility.  See you next month. - DP
 Z*MAGAZINE Atari 8-Bit Online Magazine is a bi-weekly magazine covering
 the Atari and related computer community.   Material  contained in this
 edition may be reprinted without permission,  except where otherwise
 noted,  unedited,  with  the  issue number, name and author included at
 the  top  of each reprinted article.  Commentary and opinions presented
 are those of the individual author and  does  not  necessarily  reflect
 the opinions of Z*MAGAZINE or the staff.  Z*Magazine Atari 8-Bit Online
 Magazine, Z*Net Atari Online Magazine, Z*Net  are  copyright (c)1990 by
 Rovac Industries  Inc, a registered corporation.  Post  Office  Box 59,
 Middlesex, New Jersey 08846.  (908) 968-2024.  Z*Net  Online  BBS  24
 Hours, 1200/2400 Baud, (908) 968-8148.  We can be reached on CompuServe
 at 71777,2140 and on GEnie at Z-NET.
                  Z*Magazine Atari 8-Bit Online Magazine
                Copyright (c)1990, Rovac Industries, Inc..

Return to message index