Z*Magazine: 27-Jun-88 #112From: Atari SIG (xx004@cleveland.Freenet.Edu)
Date: 07/29/93-09:53:25 AM Z
- Next message by date: Atari SIG: "Z*Magazine: 4-Jul-88 #113"
- Previous message by date: Atari SIG: "Z*Magazine: 19-Jun-88 #111"
- Return to Index: Sort by: [ date ] [ author ] [ thread ] [ subject ]
From: xx004@cleveland.Freenet.Edu (Atari SIG) Subject: Z*Magazine: 27-Jun-88 #112 Date: Thu Jul 29 09:53:25 1993 _________________________________________________________________________ |///////////////////|ZMagazine June 27, 1988 Issue #112| |///////////////////|___________________________________________________| |///////////////////|___________________________________________________| |///////////////////| American Publishing Enterprises, Inc | |////////////////// | Post Office Box 74 | | //////// | Middlesex, New Jersey 08846-0074 | | //////// |___________________________________________________| | //////// | Publisher/Editor: Ron Kovacs | | //////// | Sales Manager : Gary Gorski | | //////// | Assistant Publisher: Stan Lowell | | //////// |___________________________________________________| | //////// |**Syndicate BBS down for vacation. | | //////// |___________________________________________________| | //////// | Where to communicate with ZMag/ST-Report/AMy-Rpt | |///////////////////| CompuServe: 71777,2140 | |///////////////////| GEnie : R.KOVACS or ST-REPORT | |///////////////////| Delphi : RONKOVACS or REXREADE | |///////////////////| The Source: BDG793 | |___________________|___________________________________________________| |June 27, 1988 #112|Table of Contents| |___________________|_________________| <*> Editors Desk.......Ron Kovacs <*> ZMAG Confidential.....Ron Kovacs <*> Reader Commentary....Jack Lee <*> Basic Programming..Jackson Beebe <*> Action Prgm'g.....D Arlington <*> Up/Coming..............Bill Pike <*> Celebrity Cookbook..Bill Pike <*> ST Modification.......Jeff Rigby _______________________________________ EDITORS DESK by Ron Kovacs _______________________________________ This week I am writing commentary about BBS Software and Hard Disk systems. You can call it a bitch session if you choose. I really do not comment in these pages that frequently. I am on my soapbox this week because I have been battling more BBS problems. As some of you know, I have been running different BBS software over the last few years. Many comment that I am changing software too many times and should at least stay with something for at least a year. I totally agree and have made some mistakes, however, what I have gained in knowledge about them all is well worth telling. I really haven't seen many articles written about problems with BBS software. They are all either running well, or I am making some big mistakes. We all make errors, but I refuse to believe that I am the only person in the world with BBS problems. If you are a BBS sysop and have expirenced problems, please take a few minutes out and drop me a note. I am very interested in knowing what the heck the real story is. I wrote the following over the last few days, It might even be taken as a direct blow to some, but it is honest and written with facts I have expirienced over the last three years. Feedback about this editorial is welcome and appreciated. Now, Let me hop on my soapbox and begin. Having been a BBS SysOp for close to 3 years and telecommunicating for more than 5 years, I have seen BBS systems come and go. New BBS software is released about every 6 months and rise and fall just as fast as it is released. BBS users are just as fast in disappearing. Running a BBS requires many hours of preparation and dedication. You have to select a program that you feel will best service your needs and the needs of your users. When selecting software, you know right away if it something you want. I guess the best choices are made by calling other systems and finding the software pleasing. The choice is then made to purchase it and off you go. This article will discuss a short history of my problems with a few BBS programs and take you to the present problems encountered with another recently released program. Back in 1985, I thought about putting up a BBS of my own, ZMagazine wasn't even a thought at the time and my particular area didnt really have an Atari BBS locally. We had the JACG and Scott Brause, but nothing else really worthwhile, locally. After a few months of pondering on what I wanted, I researched and decided to try out FoReM MPP. I had only an MPP modem at the time. The 1030 couldn't answer a phone and cost for a better modem wasnt attractive at the time. The rest of my configuration was an 800XL, Indus GT and a 1050 Disk Drive. I decided to go with FoReM 26M and on July 21, 1985, the Hudson BBS was born, later in September the name was changed to the Syndicate BBS. We ran this software at 300 baud until May 1986. The best thing we were able to do is modify and add code, spruce up commands etc... We encountered few and far between problems. This was the ONLY time in Syndicate BBS history we ran 9+ months without serious problems. Then it all began in May 1986. We discussed the idea of moving to 1200 baud. Having just purchased an Avatex 1200 modem, we wanted software that could handle the task. I had also recently ordered the New Supra Atari Hard Disk System. The 10 Meg Hard disk with it's own interface. Being one of the first owners of the system, I was pretty excited about upgrading, However, Forem would run with MyDos, and SpartaDos wouldn't run with it either at the time. Upgrading hardware and modem to 1200 baud and no BBS software to run. Wait!!! Antic is selling the same software the JACG BBS uses! Lets look into it! BBCS! A very well written software package. It did have it's problems as most everyone knows, however, I am sure with the proper marketing and better beta testing, alot of the problems of that time would have been rectified. Not only did it take 2 weeks to set-up, but I don't think it lasted more than 2-3 months. I am sure you all know the story behind BBCS! There are still a few systems around running it and they are happy with it. (I hope) We are considering at this time to take another look at BBCS for some testing to see where the bugs still exist if any. After a Hard Disk crashed, software problems, fixes to the software, calls to Supra and other minor problems, we killed this sucker off and went to another problem software, Carina I, this ran well for about 3 days also, but was soon discovered to be locking up at the drop of a pin and again was pulled from usage. Then in December 1986, Express BBS. Christmas and the modem, after a day or so set-up, we were off and running for a clear 6+ months of trouble free service until another Hard disk crash and the debut of Oasis. Oasis I and II were a good addition to the BBS software area. Well written, decent price and excellant support. A commendable job to Leo Newman and Ralph Walden. Leo is missed from the 8 bit community. He is still working hard I hope. Until Glenda Stocks bought the software, or took over thr rights to it. I am really not sure on the details, but many of you know who I am talking about. The lady who comments in numerous BBS discussions around the country and lands punches on the other software writers. We should get Bill Brown and Glenda Stocks in a ring somewhere so they can battle it out!.. I wonder who will win.. Well, Glenda made some improvements to the program and continues today with Oasis IV and Oasis Jr. the public domain version of Oasis. Well, sorry to say this software lasted 6 months. Great at the start with Leo helping me with minor misunderstandings (which were my fault for not reading the documentation properly.) But the problem with Oasis would not surface until later. Instead of a preset message base size, Oasis appends messages( read on later about Hard Disk problems). Oasis was doomed sooner or later, well, sooner came quicker than expected, 6 months after running Oasis II and III, it again was another notch on my BBS belt as a failure. At this time I had decided to retire from BBS sysoping. I really wasnt pleased about going through it all again. Carina II, Express Pro, Oasis IV, Nightlite, BBCS 2.4 etc.... I stayed away from the SysOp role for two months and came back with FoReM XEP. FoReM XE Professional, this public domain release contains features from 3-4 different BBS programs. Running with Basic XE and Spartados, it is definately one of the better systems available. The support was great and the system ran very well. Again, another success here. All this brings us to the final days of trouble. After FoReM XEP, we went with Carina II. I did so because of the impression left by the demo and the extensive time I spent working on the special Carina ZMag issue a few months ago. The entire revamping of Carina I is not without its problems and holes. I have tried standing by the software for the last two months, and honestly have to say that it was a mistake. Here is a list of some problems encountered with this software in just the last 4-6 weeks: <*> Lock-ups This software locked up when a caller hung up, when a caller changed sigs, or did any type of moving around the system. After a caller would logoff the system, the waitcall section would then be loaded to reset the system for the next caller. Of the 60 days I ran this software, a total of 87 lock-ups. This would be a frustrating feature if I were to continue usage of the software. <*> Disconnects A user was hung up on just traveling around the system. <*> Uploads and Downloads Uploads to the BBS are placed in a holding area for sysop validation at a later time. When the files are validated, the SysOp has the option of: A). Validating the file. B). Erasing the file. C). Editing the description. A few notes here about this. If the user uploaded the file with a mistake in the filename or without an extender, there is no way to correct it, unless you use a sector editor. Re-editing a users file description is a great feature. If you do so, the user uploading the file is lost and your name is placed as the uploader. When a user uploads a file and the file is aborted, 9 times out of ten, you will see everything there except a no byte count and a sometimes (File Not Found) message next to the filename. When a file is validated, you then transfer the file to the main download directory in that particular SIG. In other words, you are deleting the original file and re-writing it to another place on your hard disk(more on hard disk problems later). When a user uploads a file, there are no flags to tell the system operator that a file has been uploaded. If you are running a multi SIG (section) system and have file transfer ability in each, you have to manually check each base for new uploads. <*> Passwords Name and passwords checking does not exist within this software. I had a user with the same name and password and two different user numbers. This user was then able to circumvent BBS rules by calling and downloading twice as much as other users. There really should be password checking here. More than one user can have the same password. If a user calls and has line noise at login, and that noise is part of his name, you cannot edit it out in the password file. You have to wait for that user to call, if he can logon, and have him call again and re-apply for access. No name editing at all! <*> Speed After a hard days work, Carina crawls like a turtle. I never before in my life did I ever see a BBS reset in 5 minutes. Sheesh!! Give me a break here.... Sometimes the system would take the phone off the hook during this reset, or just let the phone ring while it was sleeping trying to get it's act together! Below is my rating of BBS Software. FoReM 26M is now public domain and really not popular anymore. It is the only software on the list that is restricted to 300 Baud only. Maybe 450 as a max. Here is a rating of the BBS software we have ran. Ratings: -------- 1- Poor 2- Fair 3- Good 4- Excellent 5- Outstanding Software |P/W| File Xfer | Msg Base | Locks-up | Hard Disk | Rating |SPD| ---------|---|-----------|----------|----------|-----------|--------|---| Carina I | 2 | Fair | Poor | Yes | Fair |1- Poor | 1 | BBS Exprs| 3 | Fair | Fair | Not bad | Fair |3- good | 4 | FoReM 26M| 4 | Excellent | Excellent| None | None |5- Oustd| 2 | BBCS | 3 | Fair | Fair | Yes | Poor |1- Poor | 3 | Oasis II | 4 | Excellent | Excellent| Not bad | Excellent |4- Excln| 3 | Oasis III| 5 | Fair | Excellent| Yes | Fair |3- Good | 3 | FoReM XEP| 5 | Excellent |Outstand'g| None | Excellent |5- Oustd| 3 | Carina II| 1 | Good | Fair | Yes | Poor |2- Fair | 3 | Exprs Pro| - | Not tested| - | - | - |- | - | The clear winner so far is FoReM XEP, Although BBS Express was a fairly crash free system, modification was almost non-existant. Basic BBS programs are about the only choice one has for modifying to one's personal preference. The machine language programs have the speed. In three years of running BBS systems, I have found that they all are lacking Spartados support. Which brings us to the subject of Hard Disks on the 8 bit. I will let you all know now that I am not a machine language or basic programmer. But I think I have enough expirience with Spartados and hard disks to write the following. As all 8 bit hard disk owners know, we do not have the honors of using an optimizer with our systems. Optimizers assist the Hard Disk by filling blanks sectors that have become available after file has been deleted. There is probably a better explanation than that. More on optimizers in a future issue. When we run BBS software on a hard disk, there are many disk access routines which sooner or later are going to cause grief. Let me try to explain further. When running a large BBS, you are more than likely allowing file transfers and storing many files in your library. Not including database areas and BBS text files. When you allow users to access your hard disk it also has the potential of playing havoc with your sector maps, files, or directories. When a file is uploaded, you are filling empty sectors with data. Pretty simple to understand right? Now take a look at the example below: FILE.1 ********************** FILE.2 ************************** FILE.3 ******** FILE.4 ********************************* FILE.5 ************* As noted above, we have five files in order on a typical hard disk. Let the (*)'s show as a sector. Now let's erase file one and write file 6 to the hard disk. FILE.6 ********************** FILE.2 ************************** FILE.3 ********* FILE.4 ********************************* FILE.5 ************** FILE.6 *************** You will notice that FILE.6 took the place of FILE.1, and continued after FILE.5 This was because FILE.6 had filled the area of FILE.1, FILE.6 was larger and had to be written at another place on the disk. Now with this in mind imagine a BBS system with a larger number of file deletions and message base input etc... You will end up with a file being scattered over many places. This in my judgement is the cause of many if not all 8 bit hard disk crashes. For awhile in my BBS problems, I either blamed the BBS software or my Supra Hard Disk system. With the setting up of Carina II, I used an MIO and a 16 MEG hard drive. Having increased storage by 6 MEG, I really thought I had the problem solved. But it has happened again. The worst offender of this type of disk storage is the Carina II BBS software. I recommend that if you are planning on changing software, stay away from Carina until these problems have been resolved. The multi-subdirectories and massive amount of disk accessing has the potential to cause problems down the road. THE FINAL WORD Many readers may feel that this is a personal attack upon Jerry Horanoff and feel compelled to write back in anger. Please save your opposing points of view and think about it all. Any BBS software can have it's own problems. I just happens that I did try almost everything there is and the results were included here. I did NOT contact any software author for assistance during the past weeks crash, Repairing an apparent problem would be of no use to me right now. If you are a Carina II SysOp running without any problems, then you are a very lucky person. I would greatly appreciate hearing the details of your system set-up and how long you have ran without a problem. Mr. Horanoff and a few other programmers should get spend more time beta testing and searching for potential problems. Even if it takes purchasing other Atari hardware. Leaving beta testing to the untrained public is a dangerous alternative. Perhaps a survey of the BBS sysops is in order here. I am sure each BBS configuration is different and and will perform different from the programmers did. Better luck with future releases. NEWSLETTER COMMENTARY Michigan Atari Magazine gets a BOO from ZMagazine for the content of the most recent issue. Your Reader's Viewpoint piece was in very poor taste. The original reader who sent in the article was stating his opinion, jokingly or not your response was totally off base. _______________________________________ ZMAG CONFIDENTIAL by Ron Kovacs _______________________________________ News around the 8bit community... Jerry Horanoff is said to be working or going to be working for ICD. Carina II will not become part of the ICD inventory. Should be interesting what plans they have for Jerry there... As reported last week, Micron Tele and Atari have settled the law suit out of court. We are still on the pursuit of the details that either will not release to the public. What ever happened to Keith Ledbetter?? Sources tell us that he was fired from ICD! True or false? We have been told that Keith says it was a difference of opinion and others say he was canned. Check out the most recent issue of Atari Explorer Magazine and you will find Atari selling it's hardware and software via mail order. Not too bad, but when you consider the price of a 130XE for $149.00, the acceptance just doesn't seem to be there. You can call other mail-order houses and find a better deal! _______________________________________ READER COMMENTARY by Jack Lee _______________________________________ The number of software companies that support the Atari 8-bit line are practically nil, if indeed there are any. What is the reason? Piracy, among other things. Most companies when asked why they dropped the support of the 8-bit line will reply that the market was very unlucrative, or that sales were very poor, and so forth. It's a bit amazing to see how the attitudes of these companies changes throughout the years. In my five years of using Atari computers, I've heard these responses from the companies: "There are very little Atari computers out there, so we don't see that we should market software for it yet."; "The Atari computer is a game machine, and that wouldn't help our sales"; "Not too many Atari owners have disk drives, and since all our software is disk based, that wouldn't do us much good..." The list goes on and on. If the Atari computer was a game machine, then why was it rebuffed? The Commodore 64 was taken more seriously, and yet what did software companies make for it? A lot of games. And now I hear the 64 referred to as the "classic game machine". HAH! In any case, the 8-bits are a dying breed, with diehards scattered about, including this one. Atari Corp. seems to be heavily promoting the virtues of the ST line, and ignoring the 8-bits altogether. Even with the release of the XE Game System, they are doing little, except advertising it now and again on TV commercials. The XE-GS is the last hope- no, make that the NEW HOPE to get software publishers to produce Atari software once again. And it's about time, too. In one of the XE-GS commercials, it had a presidents from a few software companies to say how great the machine was. But you never can tell what the outcome will be in this everchanging market. As was the case in the past, by the time companies finally released software for the Atari computer, the product was already obsolete, having been available for other computers for years. So perhaps one of the major reasons why sales were poor for the Atari 8-bit is that the owners grew up and evolved into using the ST. Hmmmmm, could this mean something? Well, yes and no. Sales for 8-bits are poor due to less 8-bit owners, and piracy. Combine the two and what do you have? Zilch profits for the software companies! You always hear Atarians complain that there are no software for their machines. Some realize why, some play dumb, and others, like Antic Magazine, take this attitude: "Hey! Such and such won't release software for Atari! Duh, I wonder why? Let's all write to the company and demand that we want that product for our computer! Let's show them that there is a big user base in Atari!!!" And of course, the companies fall for it, thinking: "Gee, maybe we were wrong in abandoning the Atari market. We sure have been receiving a ton of mail! There's probably a big number of people wanting to buy our products afterall!" And of course, what happens? No sooner does the product reach the market do pirated copies come out. That implies something- some people don't give a damn! They write to a company saying that they want software, then gleefully grab an illegal copy once it's out! The survival of the Atari 8-bit line is now in the hands of Atarians. Action must be taken, and not just talk! If the 8-bit line was to finally go kaput, then it will be a Catch-22 situation, since that seems to be the case now. The software companies will continue their merry way, and the 8-bit diehards will have to salvage the remains and make the most of it. And that's the bottom line. _______________________________________ BASIC PROGRAMMING by Jackson Beebe _______________________________________ (Continued from last week Issue #111) PUT # Statement: ================ In the same way that the GET # statement gets or reads a byte from a device, the PUT # statement puts or writes a byte to an open device. For example, let's open one IOCB to the keyboard, and another IOCB to the printer, and send data from the keyboard to the printer. The PUT # statement puts just one byte (character), each time it is called (used), to a valid device as specified in an OPEN # statement. Got that? It's commonly used with a FOR-NEXT loop around it, to write strings, sentences, entire files, etc one byte at a time from beginning to end. BASIC knows enough to start you at the beginning of a file when the file is opened, and we can GET and PUT, one byte at a time. BASIC gives an EOF (End Of File) message, sending error 136 -End of File. We can set a TRAP statement for a line that tests for error 136 in an IF-THEN. If its TRUE, we're at the end of the file. 10 REM ** PUT Demo ** 20 OPEN #1,4,0,"K:":REM Open kybd 30 OPEN #2,8,0,"P:":REM Open prtr 40 ? :? :? "Begin typing" 50 REM 60 GET #1,A:REM Get keypress 70 PUT #2,A:? CHR$(A);:REM Put to printer and screen 80 GOTO 60:REM Loop This prints a prompt "Begin typing" on the screen, then gets a character from the keyboard, prints it to the screen (not done automatically for you) and sends it to the printer. The PUT # statement writes data to disks, to create disk files; sends data to a printer; to the screen; cassette; etc. INPUT # Statement ================= In the way that the GET # statement brings in bytes, the INPUT # statement brings in strings from a device. Each time the command is issued, it brings in a string of the length specified in the DIM statement associated with the variable. The syntax is; 10 DIM STRING$(15) 20 CLOSE #1:OPEN #1,4,0,"K:" 30 ? "Type some - then <RETURN> " 40 INPUT #1,STRING$ 50 ? STRING$ 60 GOTO 30 Note it doesn't write to the screen as we type, as BASIC or DOS. It's handy to bring strings in from data files on disk. We will use it to bring in entries in a disk directory, in RWP.BAS. CLOSE # Statement: ================== The CLOSE # statement, closes and releases the IOCB referenced. Closing an IOCB, 'turns it loose' meaning it is free to be called for a different purpose, or device. It's syntax is simply: 95 CLOSE #1 100 CLOSE #2:CLOSE #3 etc. Once an IOCB has been opened, it cannot be reopened again. It needs to be closed before reopening. Type in this code and RUN it: 10 OPEN #1,4,0,"K:" 20 OPEN #1,8,0,"P:" It generates: ERROR- 129 AT LINE 20 This means the IOCB is already open. We can sometimes solve this problem by using different IOCB's for different purposes. Still, there will be times when program logic dictates looping back into an OPEN statement in a wild hack. No problem. We simply issue a CLOSE # statement, THEN issue the new OPEN # statement. Actually, it is common practice to use an OPEN # statement preceded by a CLOSE # statement. This is routinely done. Check the listings in published BASIC programs. It insures you don't issue an OPEN # statement to an open device. You should always close IOCB's at the end of a program. This avoids potential problems. I usually precede my END statement with a CLOSE. A strange and terrible phenomenon of some BASIC's, involves Opening a data file (financial, mailing list, etc.) for appending, or updating for instance, and crashing out of the program without closing it. The file can hang out there, inaccessible, not able to be opened again, as it's already open. Bad News. It's sensible to be conscious of this, and add all needed CLOSE statements to our programs, covering all the different ways we can exit without closing. Okay, let's try a revision of the previous code: 10 CLOSE #1:OPEN #1,4,0,"K:" 20 CLOSE #1:OPEN #1,8,0,"P:" Type in and RUN this code. Note it runs correctly, without error 129, as it was closed before opening. Writing RWP.BAS: ================ Well, that's the building blocks for data transfer. Now let's add a few touches, and a little flash, and write a program that moves data between devices, in Atari BASIC. Let's say it should...oh....Read a file - Write a file - Print a file - and give a disk Directory. This will give us understandable examples of how to do input/output in BASIC that we can refer back to when programming. Here's the way I would go about writing such a program. I think it's important for beginners to see that programs are written from the middle out, or started at just any old place, and written until everything is finally finished. We don't have to start at the beginning. Okay, I think, hmmm...let's use a menu for Read /Write /Print /Directory choice, and one section for each part, that's four parts plus menu is five. Maybe subroutines? Yes, definitely subroutines. We'll leave the initial lines from 10 and up for initialization, description and housekeeping. Maybe put the menu at 1000, (R)ead at 2000, (W)rite at 3000, (P)rint at 4000, and (D)irectory at 5000. This way,we're sure to have room to number new lines by 10's as we go along, and we will always intuitively know where we are in the program by what number lines begin with. We will number the first line in the subroutines 1000, 2000, 3000, 4000 etc for clarity, and ease of remembering where the first line is, when looping back to it, or going-sub to it. We'll hack this program out, then maybe renumber the sections for neatness in increments of 10 when we're finished. How do we renumber separate sections of a program without affecting the whole numbering system? Stick around and I'll show you (with LIST and ENTER). Okay, let's think over some of the things we have to do. Let's put a menu up at the "top" of the program, that reads input and sends control down to one of four subroutines below it. Think of the program's operation in terms of "falling down through" the program from the top, until diverted, then falling once again. Kind of like "gravity." Let's have control revert to this main menu prompt, on return from any subroutine. The menu will choose which subroutine to send control to by letting the program fall through a stack if IF-THEN statements. Down at the bottom, we will use a GOTO to send control back up to the top of the menu if the user DOESN'T choose one of our options. We will print our prompt, then bring in a character from the keyboard. We could use an INPUT statement, but...the user would have to push <RETURN>, and that seems inelegant in a one letter menu. If we OPEN an IOCB, and GET a character from the keyboard, we won't have to push <RETURN>. We forgot to add a way to end the program, so let's exit the program with a (Q)uit option at the menu. We'll CLOSE IOCB's before quitting. Now the Read subroutine. Hmmm...Open an IOCB to the disk, by filename. We need to allow for different disk drives other than the default D: and we might want to get a little fancy, and write a hack to recognize a legitimate filename in any of the three formats: FILENAME D:FILENAME D1:FILENAME Okay, after we OPEN an IOCB, we will GET a byte and PUT that byte to the screen. Let's include error trapping to catch errors that would crash the program (also very inelegant), by using a TRAP statement, and letting control return to a subroutine's beginning prompt in case of trouble. Generally, if programs don't bomb on mistakes, but keep prompting us until we get the input correct, most of us will learn a program fairly quickly. It will be "user friendly". The TRAP function keeps a program running, when an error occurs, and gives us many recovery options by sensing the type of error that has occurred. Okay, now for the WRITE subroutine...we will need to open one IOCB to the keyboard, and another to the disk drive, to write the file to. We'll need a way to quit writing, and cause the file to be written to the disk. (CLOSE the IOCB) I think we'll have control stay at the WRITE prompt when finished, to allow us to write multiple files if we wish. If we DON'T want to write another file, or if we got into the WRITE subroutine by accident, we'll use an empty <RETURN> at the WRITE (or any other) prompt, to go back to the main MENU. Again, that's real "user friendly", not asking us to hunt for any one key, but to push <RETURN> just to go back to the MENU. I think we'll use CONTROL+Z to finish writing a file. My reasoning is that we won't need that key combination for anything else in a file, and IBM-PC's (MS-DOS) use that sequence to end files. We'll print a prompt each time so a user won't have to memorize this! And while we're at it, we may add our "smart filename" option to the Write function too. For the PRINT subroutine...we can use the READ subroutine nearly "as is", sending output to the printer in addition to the screen. No sweat, that one requires almost no new code. We will write the READ subroutine, and when ready, put our cursor on top of the first 2 in line 2000 of the READ subroutine, type a 4, and hit <RETURN>. This will "clone" line 2000 exactly, with the new number, 4000. We can edit the new line and the old line will remain unaffected. We can clone lines from the READ subroutine into the PRINT subroutine and edit them, saving some typing. One touch that's always nice in a program that accesses a printer, is checking to see if the printer is off, then printing a message and prompting for a <RETURN> without crashing the program or locking up if the printer is off. We will do this with a TRAP statement that PEEKS location 195 that holds the number of the error encountered (because the printer is off.) Isn't that handy? Our handy dandy error guide says the code for "Device did not respond" is # 138. We will use an IF-THEN to look for that in case of error, then tell the user that the printer's off, POKE a zero in 195, and wait for a <RETURN>. (You should look up location 195 that holds the number of the last error encountered, in your Memory Map, and follow this. You DO HAVE your Memory Map, don't you ? For a DIRECTORY, we will open an IOCB, and bring in a string, using an INPUT # statement dimensioned to be 17 bytes long. Let's use a FOR-NEXT loop around it. We will allow for 128 files. That should do it. When it has read the last file, it "errors" and returns to the prompt. Let's not use any "clear-the-screen" commands in this program, so we can always see the previous commands and files on the screen. It can help to see what we typed previously, especially when it doesn't work the way we thought it would. ENTER-IN FEATURE: ================= As a new service to readers, I am importing actual BASIC program code listings into these lessons, that may be ENTERed into your computer from this file, without typing, if you downloaded this from a BBS. These longer programs are identified as ENTER-IN programs, and are intended for BBS users with modems. The lines may break oddly in a word processor with narrow margins, but...edit them if you like. To use: ======= ** NOTE ** If you D/L'ed this file from CompuServe, it will be modified to contain CR/LF at the end of each line, rather than the Atari EOL character. (Copy the file to the screen using DOS, and see if it breaks correctly by line, or if it has inverse rectangles and triangles at the end of each line.) Before using a word processor as described below, convert the CR/LF back to Atari EOL characters using FILEFIX.COM by Glenn K. Smith, or a similar program.) Load this lesson in your word processor (AtariWriter Plus in a 130XE, or upgraded 800XL, etc.) t Place the cursor directly over the first character in the BASIC listing, and press OPTION+B to mark the beginning of text to be saved in the buffer. Move the cursor over the last character in the BASIC listing, and press OPTION+DELETE. This saves the text (source code) in the buffer. Now erase the lesson in main memory, retaining the BASIC listing in the buffer. With AtariWriter Plus, once you've blocked the BASIC listing in the buffer, you can use ESCAPE to move to main menu, and select Option (C)reate. Answer Y to "ERASE FILE IN MEMORY ?". The main memory is now empty. Now copy the contents of the buffer into RAM, in AtariWriter Plus by pressing OPTION+X to write buffer. This should be a perfect copy of the BASIC source code listing by itself, in memory as a document. Examine it in the word processor for accuracy. Edit as required. Now do an ASCII SAVE, (in AtariWriter Plus use CONTROL+S from the main menu) under the filename RWP.BAS. This will save only the source code, without word processor commands. This is exactly the same kind of file the ENTER command produces using: LIST "Dn:RWP.BAS" To summarize, you load the entire lesson in the word processor, and either 'clip out' and save the BASIC listing, or delete out everything but the BASIC listing, depending on your word processor, and do an ASCII save of the listing. Now boot up BASIC, and load the file back into BASIC using the command: ENTER "Dn:RWP.BAS" LIST your code to see if it contains any errors. You should have the complete BASIC listing. Many errors may be fixed with the editing feature. Lines that begin with ERROR - are usually fixed by deleting the ERROR - message, and fixing the problem. Hitting <RETURN> while in the line will save it. Now SAVE your program in BASIC, using: SAVE "D:RWP.BAS". then RUN your program. It should work fine. I've tried it, and it's worked well for me. For BBS users, it seems like a time-saving idea. (I have also uploaded RWP.BAS to CompuServe ATARI8 Forum for CompuServe users.) RWP.BAS ** AN ENTER-IN PROGRAM ** =================================== 10 REM +++++++ RWP.BAS +++++++ 20 REM + + 30 REM + A Demo for LESSON 9 of + 40 REM + LEARNING TO PROGRAM + 50 REM + IN ATARI BASIC + 60 REM + by Jackson Beebe + 70 REM + Ver. 1.07 4/88 + 80 REM +------------------------+ 90 REM 100 REM ***** Initialize ***** 110 REM 120 DIM DN$(15),FILENAME$(15),DIRSTR$(17) 130 OFF=40000:REM Turn off TRAP 140 REM 150 REM ***** MENU ***** 160 REM 170 REM ** Print menu, get choice ** 1000 ? :? :? "R/W/P/D/Q a file >"; 1010 CLOSE #1:OPEN #1,4,0,"K:" 1020 GET #1,CHOICE:CLOSE #1 1030 REM 1040 IF CHOICE=82 OR CHOICE=114 THEN GOSUB 2000:REM Read 1050 IF CHOICE=87 OR CHOICE=119 THEN GOSUB 3000:REM Write 1060 IF CHOICE=80 OR CHOICE=112 THEN GOSUB 4000:REM Print 1070 IF CHOICE=68 OR CHOICE=100 THEN GOSUB 5000:REM Directory 1080 IF CHOICE=81 OR CHOICE=113 THEN ? :? :CLOSE #1:CLOSE #2:CLOSE #3:TRAP OFF:END :REM Quit 1090 REM 1100 REM ** Must be input error ** 1110 ? :? :? "(R)ead-(W)rite-(P)rint-(D)ir-(Q)uit" 1120 GOTO 1000:REM Loop Back to MENU 1130 REM 1140 REM ***** READ Subroutine ***** 1150 REM 2000 ? :? :? "READ FILENAME.EXT >"; 2010 TRAP 2000:REM Crash proofing 2020 GOSUB 6000:REM Input and check 2030 ? :? 2040 CLOSE #2:OPEN #2,4,0,FILENAME$ 2050 GET #2,BYTE 2060 PRINT CHR$(BYTE); 2070 GOTO 2050:REM Loop until error 2080 REM 2090 REM ***** WRITE Subroutine ***** 2100 REM 3000 ? :? :? "WRITE FILENAME.EXT >"; 3010 TRAP 3000:REM Crash proofing 3020 GOSUB 6000:REM Input and check 3030 ? " (CONTROL+Z to end write)":? 3040 CLOSE #2:OPEN #2,4,0,"K:" 3050 CLOSE #3:OPEN #3,8,0,FILENAME$ 3060 GET #2,BYTE 3070 IF BYTE=26 THEN CLOSE #2:CLOSE #3:GOTO 3000 3080 PUT #3,BYTE:PRINT CHR$(BYTE); 3090 GOTO 3060:REM Loop until error 3100 REM 3110 REM ***** PRINT Subroutine ***** 3120 REM 4000 ? :? :? "PRINT FILENAME.EXT >"; 4010 TRAP 4060:REM Crash proofing 4020 GOSUB 6000:REM Input and check 4030 ? :? 4040 CLOSE #2:OPEN #2,4,0,FILENAME$ 4050 CLOSE #3:OPEN #3,8,0,"P:" 4060 IF PEEK(195)=138 THEN ? :? "* Turn on Printer - push <RETURN> ";:INPUT DN$:POKE 195,0:GOTO 4000 4070 TRAP 4000 4080 GET #2,BYTE 4090 PUT #3,BYTE:? CHR$(BYTE); 4100 GOTO 4080:REM Loop until error 4110 REM 4120 REM ***** DIR Subroutine ***** 4130 REM 5000 ? :? :? "Directory of Drive # >";:CLOSE #1:OPEN #1,4,0,"K:" 5010 TRAP 5000:REM Crash proofing 5020 GET #1,DRIVE 5030 IF DRIVE=155 THEN CLOSE #1:TRAP OFF:RETURN 5040 IF DRIVE<49 OR DRIVE>57 THEN GOTO 5000:REM Wrong Dn 5050 DN$=CHR$(DRIVE) 5060 FILENAME$="D" 5070 FILENAME$(LEN(FILENAME$)+1)=DN$ 5080 FILENAME$(LEN(FILENAME$)+1)=":*.*" 5090 ? FILENAME$:? 5100 CLOSE #1:OPEN #1,6,0,FILENAME$ 5110 FOR FILE=1 TO 128 5120 INPUT #1,DIRSTR$:? DIRSTR$ 5130 NEXT FILE:REM Loop until error 5140 REM 5150 REM *** NORMALIZE Subroutine *** 5160 REM 6000 INPUT FILENAME$ 6010 IF FILENAME$="" THEN CLOSE #1:CLOSE #2:CLOSE #3:TRAP OFF:POP :RETURN 6020 IF LEN(FILENAME$)>2 THEN IF FILENAME$(2,2)=":" OR FILENAME$(3,3)=":" THEN RETURN 6030 DN$="D:" 6040 DN$(LEN(DN$)+1)=FILENAME$ 6050 FILENAME$=DN$ 6060 RETURN ===== RWP.BAS Description ==== Okay, let's look at the program. Line 120 dimensions string variables for disk number, filename, and directory listing. Line 130 sets a variable named OFF equal to 40000, used to turn TRAP off by setting it to a line number higher than 32767. See line 1080. In Lines 1040-1080 note testing for the ASC value of a character. That's how you test a GET. Note lines 1110-1120 prompt then shoot control back to 1000 for wrong input. This also takes care of returns from subroutines, which fall down into 1120. It's a handy "catch-all" at the bottom of a menu. As mentioned earlier, I like the idea of the program being 'smart' about filenames. I want the program to operate correctly if I enter the complete drive number and filename, or D: and filename, or just the plain filename. Realizing this would be used in each subroutine, the way to go is to code this routine once, and put it in a subroutine, hence the NORMALIZE filename subroutine at line 6000. Note that we set a TRAP statement at the beginning of each function, then GOSUB 6000 to normalize and input filename. Line 2040 opens an IOCB, 2050 GETs a byte and 2060 prints it to the screen. Line 2070 causes looping until the end of file, when TRAP returns control to the (R)ead prompt. The (W)rite subroutine works the same way. Lines 3040 and 3050 open two IOCB's, used to read from the keyboard and write to the disk drive. Note line 3070 looks for a CONTROL+Z to quit writing. How did I know that CONTROL+Z was a 26? I didn't. I wrote the following little dittie and ran it. 10 CLOSE #1:OPEN #1,4,0,"K:" 20 GET #1,A 30 PRINT A 40 GOTO 20 I ran this for various inputs. It printed a 65 for uppercase A which I know is correct, and a 26 for CONTROL+Z. (Actually I have an ATASCII chart that said 26 too.) The (P)rint subroutine is similar, but note line 4010 sets TRAP to 4060 to prompt if the printer is off. When we don't use 4060 (printer is on), TRAP is set to 4000 in 4070. This allows automatic return to the (W)rite prompt at the end of printing. In the (D)irectory subroutine, line 5030 checks for null input, and 5040 checks for drive # 1-9. In lines 5060-5080 I "built-up" the filename to include the drive number, by bringing the drive number in as a character with a GET, testing it, then converting it to a string, so I could concatenate it with a "D" and ":*.*" for a Dn:*.* filename. Got that? Look again. You just start from the left, and add things to the right with the concatenation format, until you've got the string you want. There are other ways, but this is the one that came up this time. The NORMALIZE subroutine checks for null input, then checks to see if the filename contains a drive portion. ==== Interesting Quirk ==== I encountered an interesting wrinkle in writing the normalize subroutine. I initially thought that any filename less than 3 characters must not have a drive specified, as D:A for example, would be the shortest possible name that includes a drive number. I thought that I'd test for a filename length under three, and if TRUE, would concatenate the filename to D: to make it legal. I thought I'd test names over 2 characters in length for a colon. My first code was: 6010 IF LEN(FILENAME$)<3 OR FILENAME$(2,2)<>":" OR FILENAME$(3,3)<>":" THEN GOTO 6030 6020 RETURN 6030 DN$="D:" 6040 DN$(LEN(DN$)+1)=FILENAME$ 6050 FILENAME$=DN$ 6060 RETURN This would graft on a default drive number to any plain filename. Looking this over, it seemed awkward to have to jump over line 6020. If you have this situation, you can fix it by switching your logic around, from greater than to less than etc. as: 6010 IF LEN(FILENAME$)>2 ...etc. This looked good, so I coded: 6010 IF LEN(FILENAME$)>2 AND (FILENAME$(2,2)=":" OR FILENAME#(3,3)=":") THEN RETURN 6020 DN$="D:" 6030 DN$(LEN(DN$)+1)=FILENAME$ 6040 FILENAME$=DN$ 6050 RETURN This looked good. Parenthesis and all. I reasoned that if the filename was longer than 2, then it would check both places for the colon, and RETURN if it found one, and fall down into the concatenate section if not. Note lines 6020-6040 concatenate FILENAME$ to D:, then assign the completed name back to FILENAME$. Looks good doesn't it? It didn't work! It bombed with error 5 - "a string exceeded it's dimensioned length." If FILENAME$ was only one character long, the test at line 6010 bombed trying to check the 2nd and 3rd character of a one letter string. Having put the AND in there, made it always check the 2nd and 3rd places! What's the solution? Simple. FIRST test for a length greater than 2, and then test the 2nd and 3rd places like this: 6020 IF LEN(FILENAME$)>2 THEN IF FILENAME$(2,2)=":" OR FILENAME$(3,3)=":" THEN RETURN Got that? If has two IF-THEN tests in the same line. This is legal, and often needed. Study on this example if it doesn't make sense. Try typing in these code lines, and experimenting. (Dimension first.) Try this. It's a fun program, and instructive. When you are floundering in the future, coding I/O, just pull out this program listing and refer to it for examples of syntax, or hacks. Modify it, and play with it to see what you can do. Note that you need quotes around device:filename in an OPEN # statement, except when you use the name of a string variable in the statement. (Lines 1010 and 2040 for example.) _______________________________________ ACTION! FOR BASIC PROGRAMMERS A New Series by Dave Arlington _______________________________________ So what is the idea of starting this column? Well, one thing I have always heard a lot of is that "I would love to learn ACTION! since I have heard so much about it, but it is so different from BASIC, and the manual is no help. Where can I learn it?" I tried to get WNYAUG's resident ACTION! expert, Brandon Brooks to write a column on ACTION! but for one reason or another we only got one from him. So you're stuck with me. Not that I'm any great ACTION! expert like Brandon. In fact, I'll be learning it along with the rest of you since I recently started getting into it. I DO have some qualification in that I've programmed in a lot of different languages and can seem to pick them up pretty fast. Hopefully I'll be able to stay ahead of you folks! Why ACTION!? Let's talk a little bit first on the shortcomings of BASIC. It seems lately I have read a few articles from BASIC die-hards defending the language. There was an column in PC magazine a few months ago, and two very recent ones in COMPUTE! In the editorial column in this month's COMPUTE! (Sept. '87) Richard Mansfield talks about "... good old reliable, understandable, BASIC..." He writes that BASIC still gets used by most programmers because "BASIC is the most natural language." I'm sorry, but that's a lot of hogwash. Anyone who thinks that BASIC is understandable and natural, please turn to any BASIC listing at least a page long and tell me exactly what the programmer is doing at each step. I don't think too many people could take me up on that. At least in TURBO BASIC, we have the beginnings of a BASIC that is more natural and understandable. Let's face it, the real reason that BASIC is so prevalent today is that when personal computers first came out, BASIC was the only langauge that could fit in the amount of memory available. Since everyone grew up on BASIC, they felt most comfortable with it. It's like the number of Apple computers sold each year simply because the children have used them in school so much. It has very little to do with BASIC's inherent plusses. It's just force of habit. Look at the newer large memory machines like the ST. Very few people are programming in BASIC or if they are, it is something like GFA BASIC that looks almost like PASCAL. I never did like ATARI BASIC. I have long searched for an alternative. I have tried LOGO, PASCAL, Assembly, TURBO BASIC and am now looking at C (and of course, ACTION!). LOGO is a really underrated language that is more than turtle graphics. However it is too slow and does not give you great detail about adding machine language routines to speed it up. KYAN PASCAL is a great PASCAL version for the 8-bits and is almost as fast as ACTION! (look for an upcoming review), but really needs a RAMdisk to develop software and does not directly take advantage of the ATARI's special capabilities since it is designed to be a standard language. (One that will run virtually unchanged on any machine.) Assembly language is like wanting to write your name and having to contruct the pen and paper yourself from raw materials. If you have to program in BASIC, TURBO BASIC is the way to go and will be used for most comparisons with ACTION! in this column. It is still tied down to line numbers and wasteful varaibles though. ACTION! is like the best of all worlds for anyone considering programming on the ATARI. It is almost as fast as machine language, but CAN be as easy to learn (or easier!) than BASIC. It is modular like C and PASCAL so you can build little pieces at a time and test them. However, the compiler and editor reside in a cartridge so you do not have to load those things seperately like you would with PASCAL or C. It is written specifically for the ATARI so it takes advantage of all the ATARI's special features (with a few exceptions). It has many other beautiful things that make a programmer's life easy that we will be getting into as the series goes on. This month, we'll talk a little about the negative things in ACTION!, show a little demo routine, and explain it just a little. First, the negative things. One of the reasons more people don't program in ACTION! is the horrendous manual. Unusual for an OSS product, the manual abounds with typographical errors and important features that are glossed over in some appendix. Want some examples? On page 61, an example of order of operations shows that 43 MOD 7*2+19 equals 21 when it should be 31. On page 167, they show the OPEN library procedure taking four arguments. A little later on page 188, they have an example where it only uses three. (Technically, this is correct. You CAN pass a PROCedure less than the correct number of arguments, but it only confused me.) Tucked away in a paragraph on page 167 is the notice that "Remember, the maximum length of a string is 255 characters." Funny, how could I remember, when there is no other reference in the manual? As a last example, on the second last page of the manual we are finally told in a note in an example that we can use a colon ":" to separate statements as well as a space. The manual fails in other ways as well. One minute it is very detailed, assuming a novice user. The next minute we are breezing by bit-wise operators like everyone knows what they are. The manual does say that it is not intended as a tutorial on the language, however considering it is the only book to date written on the language, it could have been a little more introductory. Anyways.... I guess that's why this column was born. Out of my frustration with the manual, I felt there had to be others who wanted to learn ACTION! but needed someone to explain it better. Having said all that. Let's look at the first sample program in ACTION!. It is essentially the same routine I put in the TURBO BASIC column two months back that will load in any alternative character set (like those on this month's disks of the month. PLUG PLUG). THIS IS NOT meant to be an introduction to ACTION!. That will come next month. I just wanted to show how similar ACTION! can be to BASIC in some instances. Please ignore the first two procedures in the example for now, the ones call PROC Burst() and PROC BGet(). I borrowed these from the ACTION! ToolKit disk so the main routine would look more like our BASIC example (TURBO BASIC, that is) from two months ago. OK, here goes: ; ******************************* ; Character Set Loader in Action! ; ******************************* ; For the purposes of this first ; article, ignore these first two ; procedures. I borrowed them from ; the Action! ToolKit for the purposes ; of this article. PROC CIO=$E456(BYTE areg,xreg) CARD FUNC Burst(BYTE chan,mode, CARD addr,buflen) TYPE IOCB=[BYTE id,num,cmd,stat CARD badr,padr,blen BYTE a1,a2,a3,a4,a5,a6] IOCB POINTER iptr chan==&$07 iptr=$340+(chan LSH 4) iptr.cmd=mode iptr.blen=buflen iptr.badr=addr CIO(0,chan LSH 4) RETURN(iptr.blen) CARD FUNC BGet(BYTE chan CARD addr,len) CARD temp temp=Burst(chan,7,addr,len) RETURN (temp) ; ************************************* ; This is the procedure we're concerned ; with this month. It is the main ; program. Notice how close it is to ; the TurboBasic code. PROC main() CARD HiMem=741, ChsetStart BYTE ChsetBase=756 ChsetStart=(HiMem-1024)&$FC00 HiMem=ChsetStart Open(1,"D:FANCY3.FNT",4,0) BGet(1,ChsetStart,1024) Close(1) ChsetBase=ChsetStart/256 RETURN OK, Let's get started. Boot your ACTION! cartridge and type in the example exactly as you see it. You can leave off the semi-colons and anything after them on a line. They are ACTION!'s version of BASICs REMark statement. You may also substitute the name of any character font you have in place of FANCY3.FNT. When you're all done typing, hit Shift-Control-W to write your file to disk. Then hit Shift-Control-M to go to the monitor. (Just a white bar across the top of the screen.) Hit "C" to compile your program. The compiler will complain if you have made any errors and will put you in the approximate area of the mistake when you go back to the editor. Assuming it compiled OK, make sure your disk with the font you named is in the drive and hit "R" to run your compiled program. Now go back to the editor and look at your program in its new font. We'll just take a brief look at the main program this month and explain more next time. The main program starts where it says PROC main() and ends where it says, RETURN. Sort of like a GOSUB or PROCEDURE in TURBO BASIC. The first two lines in the main program that start with the words CARD and BYTE will be explained in great detail next month. Right now we'll just say that those are variables we will be using in our main program. The first actual line in the program says that we are going to start our new character set at HiMem (which stands for the top of RAM memory, or Himemory) minus 1024 bytes. Remember from two months ago, that is the size of a character set. That funny stuff at the end with the dollar sign and the FC00 we'll deal with some other time. It just makes sure our character set starts in the right place. The next line resets where the computer thinks High Memory is to where the character set starts. That way the computer won't go high enough to write stuff into our new character set. By the way, do you notice that in BASIC, we use memory location 106, called RAMTOP and we also have to call Graphics 0 to set things right because the computer puts the screen display stuff under RAMTOP? Well, ACTION! stuffs some other stuff up there besides the screen display and HiMem (location 741 and 742) has the screen display and the other stuff OVER it not under it. That's why we don't have to do a Graphics 0 call. Next we Open a channel to the disk file we want to use. This is just like BASIC. Next we use the BGet command to load in 1024 bytes of our new character set and stick them at ChsetStart. The BGet command is not built into the ACTION! cartridge. It is part of an extra disk, called the ACTION! ToolKit. Here is one nice thing about ACTION! that BASIC can't do. Someone else can write a routine to do a BGet command for instance and you can load it in and use it without having to understand how it works. For instance, now YOU have a routine that loads in an alternate character set that you can use in your own ACTION! programs! The BGet command here works exactly the same as in TURBO BASIC so I won't bother explaining that whole thing again. The next line simply closes the disk file and points the computer to our new character set. The RETURN ends the program. _______________________________________ UP/COMING FOR THE 8-BIT by Bill Pike _______________________________________ Reprinted from the PAC Newsletter We have recently been given a demo copy of STjr published by Merrill Ward & Associates. This is a new Graphics Operating System (GOS) is designed for the 8-bit computers. This system supports an ST MOUSE, that's right an ST MOUSE in a 8-BIT ATARI. The MOUSE is connected directly to joystick port #1. A joystick in port #2 is also supported as well as the cursor control keys & spacebar. A demo disk can be obtained from Merrill Ward at 255 North El Clelo Rd., Suite 222, Palm Springs Calf. 92262. The price for this disk is $5.00 and the price is applied to the purchase of the final version of the program at a projected cost of $59.99. The demo disk received has a screen much like that of the ST GEM system, the icons are very similar. The DOS on the disk is a Version of SpartaDos, however all the commands have been superseded by the graphics environment. In other words all commands are given graphically rather than typing in a command. The mouse action is fast and accurate. The pull-down windows are implemented and are quite fast, much faster than expected using some other graphic systems as a guide. This shows what can be done. The same publisher has a program called THE CELEBRITY COOKBOOK VOL.1 ($39.95) for the ST & 8-bit where the mouse interface and pull-down windows are fully implemented, for this program. (See the next column for a review). However most of the expected functions like diskcopy, file copy, etc. are not on the demonstration disk. These functions are in the menus but do not operate. The publisher hopes that this will become the operating system of the future for the Atari 8-bit systems. However it is unclear if the purchase of the final version will license the purchaser to use this system for his/hers own programs or if a additional license fee would be charged for commercial use of this operating environment. The final program is supposed to be on a cartridge and use ADOS as its base. It will have bank switched ROM and let the operator use the RAM under the cartridge so it will take up no operating room, similar to the DOSXL system. Here is something really new for the Atari 8-bit machines that shows a lot of promise. The action is as fast as the ST, on the screen. I can see real promise for this type of program. It will be interesting what happens. If you have $5 bucks to spend, and want to see just what can be done and want to be first in line for the final version, this would probably be a good way to spend it. Did I say that you should also beg/borrow/steal a mouse from your friendly neighborhood ST user? I guess I didn't but you do. _______________________________________ CELEBRITY COOKBOOK REVIEW by Bill Pike _______________________________________ Reprinted from the PAC Newsletter I realize that the diet of a computer person consists mostly of pizza, hamburgers, twinkies, and soda pop, etc. I also realize that it is nice to be able to include other values of a gustatorial nature. A program has arrived for those who enjoy eating and entertaining, such as the better half. The program is published by Merrill Ward & Associates. The cost of this program is $39.95 and is available for the 8-bit as well as the ST machines. The 8-bit version uses the GOS system developed by the publisher. In other words you can use a ST mouse in joystick port #1 or a joystick in port #2 or the keyboard. This makes for a very user friendly program. My wife, who finds just everything about a computer unfriendly, sat down with this program for a full hour non-stop. This is a new record for her. In-fact the only reason she left the keyboard is that she had to go to a baby shower that she was late for as it was. I feel that this is the highest recommendation for the program available, even if I didn't say anything else. Getting to the meat or fish or fowl of the program. You are given the choice of the cookbook or filer on the first screen. The cookbook gives you access to the recipes as well as a bartenders guide, beverages, soups & sauces, etc. You also have access to a wine directory and guide. There are also main courses & desserts available. All in all there are about 45 recipes as well as party tips and beverage recommendations. Most of the recipes have a short story about the dish from the celebrity who wrote the recipe. You can also save your own favorite recipes on the filer disk. The filer program can be configured to use two drives so that the main program can be in drive one and the data disk in drive 2. You can use as many data disks as you wish. There are also sort functions available to make selection easier. The instructions are straight forward and easily used. The entire program is menu driven. This makes for a very user friendly program. There is also a resize feature. This allows changing the amounts of ingredients to the number of servings. The resize works very rapidly and will just as easily change a 12 portion recipe to 2 portions or 30 portions, up to 999 portions. You can request a printout of the full recipe, the ingredients with quantities, or just a shopping list of ingredients. If you resize the recipe before requesting the printout the quantities will be increased or decreased depending on the number of portions you request. There are 5 additional volumes planned for a total of more than 300 recipes. The cost of the additional disks are not given but I assume the price will be less than the main program. The program is copy protected by a 10X10 3 number matrix on a separate card. In fact you are told to make backup disks when you first read the instructions. These are the sheets of paper you generally put up on a shelf or lose immediately upon opening the program. The code requested is a random combination of a row and a column on the card, which changes every time you use the program. This is a very good program and should be in the library of all computer users, even those without a spouse. _______________________________________ ST MODIFICATION by Jeff Rigby _______________________________________ Modification to the ST power-on reset delay timer The following modification will cause the ST to be in a Halt condition for apx 14 sec following turn-on. This allows a Hard Drive time to go through its initialization. The modification will not affect reset timing (.3 sec). It's relatively simple in that it requires the replacement of only one resistor (in the 520 & 1040 series). If you have a Hard Drive for your ST you presently have to turn on the HD, wait until it stops making noise (initialization...about 14 sec) and then turn on your computer. With the circuit modification below you can now turn both on at the same time (idiot proof). 520ST and 1040ST All computers have reset circuts and a circuit to perform a reset after the computer has been turned on (allowing the power supply to stabilize). In the ST these two reset circuits are in one chip, a 556 timer IC (a 556 is two 555 timers in one package). Both circuits use the same timing components for a delay of .3 seconds. One circuit holds the reset low for .3 sec after the reset button has been pushed and the other holds the reset low for .3 seconds after power turn-on. This second circuit (power on reset) is the one we are going to change. Basically we are looking at a 22Uf cap charging from B+ through a resistor (12k). When the voltage on the cap reaches trigger level the 555 timer turns off allowing the reset line to go high. The formula for Time T with Cap C and Resistor R is as follows: Resistor = R Cap = C T= (1.1)*R*C Time (hold down) = T For a stock ST R = 12k C = 22Uf Thus: T=(1.1)*(12000)*(0.000022) T=.29 sec Ok now for your computer.... Turn on your Hard drive and count the seconds until the activity light goes out. Mine is about 14 seconds. This time is what you need to determine the value of the resistor you are going to add to your ST. For a time of 14 sec we use the following formula to determine the resistor we need. R= (14 sec)/(1.1)*(0.000022) R= 578k Look in your ST for a Chip that has the number 556 on it (NEAR THE RESET BUTTON). Off pin 8 you will find a resistor with the color bands; brown, red, orange (12k). 520ST R83 1040ST R9 Cut this resistor loose and install a 560K resistor; green, blue, yellow. Now reassemble and check. Extremes of temperature can affect the timing of this RC circuit. I have found that a very cold computer (40F) can knock almost two seconds off the circuits reset time. Also, the 22Uf cap is manufactured with a tolerance of 20%. A 20% difference can make a 4 second difference in your calculations. You may want to install a variable resistor in place of a fixed resistor. If you are like me, you can't wait for your computer to come on and you will want the min wait time that still allows the HD to initialize properly. The variable resistor will allow you to set the time to the nearest second. Use a 360K resistor in series with a 500 K pot. MEGA ST Atari changed the design of the Reset circuit in the Mega ST. There are no longer two seperate circuits for reset. I had to kluge my Mega to get the same functionality. See below: --| |--* c3 | | 1000Uf 1000Uf @ 16v ($1.50) *---|>|-*--| |----* Gnd diode | | 1 amp diode (.50) *-----* | 33k ohm 33k ohm @ 1/4 watt (.50) | *--|>|-----* 5v diode 1 amp diode (.50) C3 is a 10Uf cap under the switching power supply. This cap is charged by a resistor network similar to the 555 circuit in the 520ST. When the voltage reaches 1.2v the reset line goes high. The circuit has the same .3 sec delay for reset and 13 seconds for turn-on. The above circuit connects to the Mega at three places: 5v, Ground and the positive terminal of C3. Increasing the value of the 1000Uf cap increases the turn-on reset delay. The 33K resistor is used to fine tune the reset delay for power turn-on. Increasing the value of the resistor decreases reset delay and decreasing the value increases power on reset delay. Typical resistor values are from 18k (19 sec) to 50k (11 sec). The bottom diode discharges the 1000Uf cap to the 5v supply (when you turn off the computer the 5v supply goes to 0) when you turn the Mega off. You should count to 5 before turning a Mega back on to insure a complete cold boot. Waiting 1 sec will not allow the 1000Uf to discharge enough (the 5v supply in the Mega discharges slowly after dropping to .6v) and your power-on reset delay may drop to 9 sec from 13 sec. The top diode provides isolation so that pressing the reset button after the 1000Uf cap has charged (power on) will cause only a .3 sec reset. The above modifications require some technical skill and should be done by a service center or a qualified person. Intersect Software makes no guarantees reguarding the reliablity of the above modifications. You, as always, perform the modifications at your own risk. This technical note may be freely copied as long as the credits remain intact. _______________________________________ ZMAGAZINE Issue #112 June 27, 1988 Copyright (c)1988 APEInc, Ron Kovacs All Rights Reserved _______________________________________
- Next message by date: Atari SIG: "Z*Magazine: 4-Jul-88 #113"
- Previous message by date: Atari SIG: "Z*Magazine: 19-Jun-88 #111"
----------------------------------------- Return to message index