Z*Magazine: 29-Oct-90 #186From: Atari SIG (xx004@cleveland.Freenet.Edu)
Date: 10/02/93-03:37:08 PM Z
- Next message by date: Atari SIG: "Z*Magazine: 3-Dec-90 #187"
- Previous message by date: Atari SIG: "Z*Magazine: 15-Oct-90 #185"
- Return to Index: Sort by: [ date ] [ author ] [ thread ] [ subject ]
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.. =======================================================================
- Next message by date: Atari SIG: "Z*Magazine: 3-Dec-90 #187"
- Previous message by date: Atari SIG: "Z*Magazine: 15-Oct-90 #185"
----------------------------------------- Return to message index