informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/magazines/ZNET/0110.txt

1422 lines
66 KiB
Plaintext
Raw Permalink Blame History

_________________________________________________________________________
|///////////////////|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
_______________________________________
Reference in New Issue View Git Blame Copy Permalink