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
-----------------------------------------------------------------------
EDITORS DESK
------------
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
have???
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!
RUMBLES...RAMBLES...RUMORS...
=============================
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
on-line!
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
know!
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!!
PRINTER BASICS - PART ONE
=========================
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
joystick".
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
characters.
"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
understands.
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
------
"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
completed.
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.
NORTH CENTRAL REGION EDUCATIONAL
LABORATORY'S TECH EXPO 1990 REPORT
===================================
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
schools.
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-
7677.
Z*NET NEWSWIRE
--------------
SECOND "SIMPSONS" GAME
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.
ATARI 8-BIT SURVEY
------------------
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
it?
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
editor?
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.
USING 'USR'
-----------
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.
HOW DO THINGS STACK DOWN?
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.
A CRITICAL ADDRESS
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.
EXIT BASIC
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:
ADDRESS CONTENT COMMENT
$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).
PROGRAMMING TECHNIQUES
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
TXA
PHA STX XSAVE
TYA
PHA STY YSAVE
... ...
... ...
PLA
TAY LDY YSAVE
PLA
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
instruction).
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.
ADDR ACTUAL LINE LABEL MNEMONICS
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.
THE IDYLLIC LIFE OF A REVIEWER
==============================
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
OTHER PUBLICATION OR NEWSLETTER WITHOUT EXPRESS PERMISSION FROM ST-
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
extent.)
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
