Z*Magazine: 11-Apr-88 #101

From: Atari SIG (xx004@cleveland.Freenet.Edu)
Date: 07/28/93-10:59:09 AM Z


From: xx004@cleveland.Freenet.Edu (Atari SIG)
Subject: Z*Magazine: 11-Apr-88 #101
Date: Wed Jul 28 10:59:09 1993


______________________________________
|////////////////////////////////////|
|////////////////////////////////////|
|//SYNDICATE ZMAGAZINE   Issue #101//|
|//================================//|
|//Publisher/Editor|April 11, 1988 //|
|//   Ron Kovacs   |Vol 3, No. 2   //|
|//================|===============//|
|//Asst Publisher  |Managing Editor//|
|// Ken Kirchner   | Keith Whitton //|
|//================================//|
|////////////////////////////////////|
|////////////////////////////////////|
|____________________________________|
|SPC                                 |
|Post Office Box 74                  |
|Middlesex, New Jersey 08846-0074    |
|____________________________________|
|BBS #1: Syndicate (201) 968-8148    |
|BBS #2: Stairway  (216) 784-0574    |
|CompuServe SIG*Atari8 DL 11         |
|____________________________________|
|Contents                            |
|____________________________________|
|*|Editors Desk                      |
|*|Compaction Programs Revisited     |
|*|SpringBoard Confrence Transcripts |
|*|XF551 Revisited                   |
|*|Different Look At ARC             |
|*|Computer Show Calender            |
|*|PC Pursuit Update                 |
|*|Shareware Review  DETERM850       |
|_|__________________________________|
______________________________________
Editors Desk
______________________________________
by Ron Kovacs

A few developments this week that will
help some of our users out.

We have been uploading past issues of
ZMag along with support files and old
articles to Data Library 11.  We now
have our own area for ZMagazine. You
will also find Chicago issues of ZMag
from 1986 and whenever we come across
more recent issues.

Files in DL 7 are supposed to be moved
into DL 11 shortly, you will find all
Zmag issues there.

Updates on will be listed here and on
CompuServe in future weeks.  You will
also start seeing some articles
available there for reprinting. So,
give us a call on CompuServe and check
out ZMagazine.  We are there everyday,
so leave us a message and get
involved.

Official registration numbers are now
required for ZMAG carriers. If you
want to know yours, leave email on
Compuserve or Syndicate BBS.

For recognition and BBS advertising,
you must have a registration number.
You will use this number at a later
date for special offers, which are
currently being developed.
______________________________________
|FEATURE ARTICLE|
|_______________|
   Compaction Programs Revisited
______________________________________
Three articles appear here, Marty
Albert re-does his compaction test a
rebuttle article by Jeff Kyle, and 
some commentary about compaction
programs from Dominick Palance.
--------------------------------------
A REVIEW OF FILE COMPACTION SYSTEMS
A SECOND LOOK

April 2, 1988

by Marty Albert

This article may be freely reprinted
so long as this notice remains intact
and the document is unchanged.

Copyright 1988 by Marty Albert.

Well, today, in GEnie Mail, I had a
note that was sent to me by Jeff Kyle
for Bob Puff, the author of Disk Comm
for the Atari 8-Bit computers. The
basic gist of Bob's letter and the
note that Jeff sent along was that the
reasons that I had trouble with Disk
Comm is that SpartaDOS "has too many
bugs for me".

Since I don't want to get into a DOS
"war", nor is that the reason for
these comparisons, I decided that I
would repeat the tests with a more
"standard" DOS, namely Atari DOS 2.5.

The system used is a 256K 800XL with a
single Atari 1050 drive with US
Doubler chips.  I used the standard
130XE RAMDisk set as D8: for a 499
sector RAM drive.

The programs tested were SHRINK XE
version 1.00, SCRUNCH 2 version 2.0,
Disk Comm 3.2, and ARC/ARCX version
1.2.

Since I used Atari DOS 2.5, bytes mean
nothing.  All the file sizes are in
terms of single density sectors.  The
files used for testing were as
follows:

Binary load file ....... 65 sectors
SAVEd BASIC file ....... 64 sectors
Daisy-Dot *.NLQ file ... 15 sectors
Atari font file ........ 09 sectors
Text file .............. 60 sectors
RLE picture file ....... 48 sectors
Koala picture file ..... 27 sectors
AMS song file .......... 52 sectors
 TOTAL SECTORS ......... 340

Note also that the % saved is in terms
of the sectors used, which will of
course be the same as the reduction in
XModem blocks needed to transmit the
file.

The following table is a summary of
the test results.

PROGRAM      TIME CRE.    TIME REC.   SIZE      % CHANGE
--------------------------------------------------------
SHRINK XE     1:25          0:50       331        -2.72%
SCRUNCH 2     4:30          5:36       325        -4.62%
DISK COMM     4:08          1:34       326        -4.29%
ARC/ARCX      5:20          6:04       249       -36.55%

So, there is the data.  Now, for a few
observations made while the test was
going on....

SHRINK XE
=========
This is a nice little program.  I like
it, as I have liked all the past
versions of Shrink.  It's fast, in
fact, MUCH faster than anything else
in the test.  It's easy to use with a
nice menu.  It allows the verification
of files without actually needing to
recover them.  All in all, SHRINK XE
is a good option to use.  The only
problem that I see is that it does
very little compaction.  I guess you
can't have everything, but I sure want
it!

SCRUNCH 2
=========
This is another good program, but it
is a bit slow. In fact, Scrunch was
not all that much faster than ARC,
especially when you look at the
compaction difference.

But, Scrunch does seem to work
flawlessly in operation.

DISK COMM
=========
Here we go again.  No matter what I
say, I'll get nailed for it.  But,
that's life!  Disk Comm *is* good.
It's faster than ARC, but slower than
Shrink.  It compacts better than
Shrink, but no where near what ARC
does.  On this test, I had none of the
problems loading Disk Comm that I did
in the last test.  First try I made,
it ran like a champ.  Bob also hinted
at the idea that my copy of Disk Com
was damaged because I had gotten it in
ARC format.

Well, the copy that I used for this
test is the same copy as for the
previous test.  Sort of rules that
out. Now, on to what I really like
about Disk Comm...  The menu and use
has to be one of the best and most
user friendly that I have ever seen,
and I've been in this field for over
25 years now.  It is, simply put,
fantastic!  Bob Puff has put a lot
thought and energy and time into the
design.  It would be very easy to use
with no documentation whatever.

ARC/ARCX
========
OK, here it is again.  ARC is the
slowest but it also is the one that
does the most compaction.  The fact
that CRC errors happen is real.  Jeff,
in his note, stated that the CRC
errors do not happen because of XModem
padding and that the file is,
"..damaged in some way.  It may not be
easily noticable, but it's there."
While that is, in strict terms, true,
it still doesn't matter.  If a text
file has 10 characters on the end that
are XModem padding, and the ARC/ARCX
process changes one of them, the file
has indeed been damaged.  But, so
what?  Does it harm the way the file
works?  No.  So long as a file is not
OPERATIONALLY changed, who cares?  Not
me.  Especially if I'm saving 35% of
the time/money needed to download the
file.

IN CONCLUSION
=============
So, it looks like the data is really
unchanged, except that we now see that
Shrink is now the fastest of the
bunch.

Bob meantioned that, "And the fact
that CIS named Diskcomm their official
boot disk standard tells me they have
no problems with it either."  I can't
speak for what CIS does or doesn't do,
nor can I really speak for what GEnie
does or doesn't do.  I have no contact
with CIS at all.  On GEnie, as I have
said all along, whatever the
RoundTable members want is what I will
do.  However, in the recent online
survey on GEnie, it was shown that the
members had the following preferences:

ARC        53%
Scrunch     2%
Shrink      2%
Diskcomm    7%
SCOPY       1%
Other       1%
None        8%
No pref.   25%

While this only reflects the attitudes
of the GEnie users that took the
survey, it's all we have.

As I said in my prior article, we do
need something better than anything
that's out there now.  I just wish
that I had the skill to write it!

...Marty...
--------------------------------------
|Part 2|
|______|

View of File Compaction Systems:
A Second Look        A Rebuttal
April 3, 1988

by Jeff Kyle

First off, I'd like to thank you,
Marty, for promptly redoing the
compactors comparison, and taking a
second look at DiskComm. However, I
couldn't believe you liked Shrink XE
so much, so I decided to load the old
sucker up and test it against
DiskComm.

First: you should note that neither
Shrink nor Scrunch can handle double
density disks. This is a serious
problem.

I went through and compacted and
uncompacted the "Awesome #1 Demo" disk
using DiskComm 3.2 and Shrink XE 1.00.
You say that SXE could compact the
disk you used in 1:25. This is quite
strange is you were using a normal
disk without UltraSpeed, which by the
way DiskComm 3.2 supports.

So here are the times I got. Note that
this included all the reading/writing
time, and the compacted disk was in a
DD RAMdisk. Therefore the "size" will
be in double density. To find the
single density size, just multiply by
two. Also, the input and output disks
were in UltraSpeed, speeding up
reading/writing by approximately 3X.

Program    Time In  Time Out  Size
---------- -------- --------- -----
Shrink XE  1:57.5   0:48      176
DiskComm   0:58     0:52      152

Obviously DiskComm is faster, and
creates smaller files. This, plus all
the extra features, support of
SD/dual/DD, plus "non-conforming"
drives, should make DiskComm the clear
winner.
--------------------------------------
|Part 3|
|______|

Why I hate Compaction all together!

by Dominick Palance

4/6/88

Now I'm no great programmer and I
don't know assembly and I'm not
totally perfect at Basic, but I'm an
Atari user non-the-less. I feel its
time for another totally different
outlook on compaction.

I started telecommunicating this past
summer with my Atari XM301 and now use
a SX212. That was the first time I saw
ARC. I didn't know what it was at
first, but now we all know that it is
a program that makes files smaller and
links them back. It saves downloading
time and takes up less disk space to
store on a BBS.

BUT, you must UnARC the file to run.
No problem, but it *does* take time.
But better to spend the time off-line
so not to run up a bill. I kind-of
liked the idea at first and a lot of
files are ARCed, so I got an unARCing
program. At 300 baud a smaller file is
great and is OK even at 1200 baud.

"But where's the part about why I hate
it?" you say. Well, hold on.

I've seen many ARCed files and they've
always run (well, 99% of the time) and
I needed therefore to have an unARC
program as I said. THEN, I started
seeing "other" compactors and some
files used them, but not nearly as
many that used ARC. Some are ShrinkXE,
DiskCOMM, and SCRunch. This kind of
put a dent in things. I didn't want to
spend my time downloading all these
compactors/uncompactors let alone go
to the trouble of seperating files
into groups by which compactor they
used.

ONE compactor was fine for me, two
tops if really needed. The second most
popular I've seen is SCRunch. To make
things worse, there seems to be more
and more compactors coming out these
days.

I happen to like ARC because there are
so many files using it and its so easy
to use. SCRunch is faster, but doesn't
seem to do as much compacting, so why
use it? Whats the point? Plus, its not
user-friendly and it totally wiped
out one of my double density Sparta
DOS disks. I've only gotten SCRunch to
work with DOS 2.x. As for the others,
I hardly see any files using them, so
why not forget them?

As for ARC, it will support my Sparta
disks and does a lot of compacting. I
don't mind the wait then. But still, I
don't like going to the trouble of
going through the process. You +have+
do download the entire file that may
contain files you already have and you
have to unARC them all. Plus, some
files are called AUTORUN.SYS as if
they are gonna be the only file on the
disk. Thats not too bad. But when ARC
ruins the file by adding a byte here
and there (or so I hear) then thats
not good.

Sometimes, compaction is totally
uncalled for and still its used and I
have to go through a long slow and
hard process. And the file is not
always compacted too much. And with
2400 baud coming, you may not notice
the time to a file not compacted. On
larger systems with more memory, ok..
maybe compaction could help, but as
for us 6502 users, not always.

I downloaded a package of AMS files
with a TV theme. I believe it was
ARCed. When I looked at all the files
seperated, I already had *1/2* of the
files included! BIG waste!

On one system I call, you can upload a
group of files related in some way and
put them all under one title in the
directory. That way, you can either
d/l the file, documentation, OR the
source code or ALL. This only leaves a
need for compaction to make the files
and time to download smaller, but it
does not always matter. Do I make
sence or are you alseep already?

I welcome ANY comments on this ect,
thank you for your attention.
______________________________________
Confrence Transcript
______________________________________
SPRINGBOARD Conference
Date: 03/31/88   Time: 22:56EST

Springboard, makers of NEWSROOM

<[Neil] NHARRIS> OK folks sorry for
the delay. We had a couple of problems
but we're all set now..

<[SysOp's-Asst] MARTY.A> Room is now
listen-only.

<Neil] NHARRIS> Our special guest
tonight is Bob Mueffleman of
Springboard. As you may have heard,
within the past week or so, Newsroom
was released for the Atari 8-bit
computers!  <yay!>  Bob, please tell
us a little about Springboard, ok?

<[SPRINGBOARD] DMAY> SPRINGBOARD
PRODUCES EDUCATION AND HOME
PRODUCTIVITY SOFTWARE.  WE RELEASED
THE NEWSROOM IN 1985 FOR APPLE
COMPUTERS.  UPON DEMAND WE DEVELOPED
IT FOR ATARI 8 BIT AND NOW IT IS
HERE!

<[Neil] NHARRIS> Just so we're clear,
Bob, what's your role at Springboard?

<[SPRINGBOARD] DMAY> SOFTWARE MANAGER

[Neil] NHARRIS> Great.  You mentioned
that it was developed "upon demand"
-- what kind of demand?

<[SPRINGBOARD] DMAY> Antic magazine
sponsored a write in letter campaign a
few months ago that resulted in
hundreds of letters from Atari users
asking for the Newsroom.

<[Neil] NHARRIS> Wow!  So the letter
campaign persuaded you to do the port?
Great! Let's take some questions from
the floor...please use the /RAI
command to raise your hand and get
in line...

<[SysOp's-Asst] MARTY.A> J.Sliker, go
ahead

<J.SLIKER> JUST HOW HARD IS IT TO
RE-WRITE A PROGRAM FORM SAY THE APPLE
TO THE ATARI?

<[SPRINGBOARD] DMAY> There was a lot
of common code... but the I/O and
graphics routines had to be re-written.

<[Neil] NHARRIS> How much time did
that take?

<[SysOp's-Asst] MARTY.A> <when you're
done, please type "GA" for the next
response>

<[SPRINGBOARD] DMAY> 3-4 months in
total... 2 to 3 programmers

<ZAP> How much will Newsroom cost?

Also,will it make any use of the 128K
130XE and will it take advantage of
the XF551's extra powers over the 810
& 1050? Cost of Newsroom is $39.95
(direct from Springboard). There are
additional saving for purchasing our
ad-on clip-art disks.  It does not use
the extra memory in the 130XE.  I have
yet to see it work on a XF551... but
will be intrested in the results.

<[Neil] NHARRIS> Is Newsroom also sold
through computer dealers?

<[SPRINGBOARD] DMAY> Yes, it is being
carried by a number of distributors.

<[chuck] AJP82F> WIll it work with the
SG-10 (star) printer

<[SPRINGBOARD] DMAY> It works with
many different printers.  I don't know
off hand if that's one of them.

<T.CHAPPELL> Since alot of A-8's have
some Print Shop icons, will Newsroom
support them?

<[SPRINGBOARD] DMAY> I know there are
some Start printers on the list.
Star not start

[Craig] C.S.THOM> OK.  three parter:

a> is Newsroom copy protected?

<[SPRINGBOARD] DMAY> We have 2600
pieces of clip-art available... we don't support the Print Shop art.

[craig] C.S. THOM> b> does it use a
custom DOS?  c. does it use the extra
RAM under the OS ROM?

<[SPRINGBOARD] DMAY> (please... slow
down for a sec...!!_) Yes it is copy
protected. It uses Atari DOS. Does not
use extra RAM.

[Craig] C.S.THOM> Darn.  I was hoping
to be able to use it from hard drive.
Have you tested it with other DOSes?

<[SysOp's-Asst] MARTY.A> Bob, with all
the clip art out for the CBM machines
and the Apples, will there be any
coversion programs available? Or do we
do those ourselves! (grin)

<[SPRINGBOARD] DMAY> Will not work on
a hard drive... No current plans for
any conversion program. sorry...

<[chuck] AJP82F> will the new chipmuck
program copy it even though it is copy
protected? and what kind of art is it,
2 or 3 examples

<[SPRINGBOARD] DMAY> Clip Art
Collection #1 is made up of 500 pieces
of all art. Collection #2 is business
art and #3 is 500 pieces of sports and
recreation art. In addition, 600
pieces come with the main program.

<[Neil] NHARRIS> Is it possible for
users to create their own art for use
with Newsroom, and if so, can they
share it with each other?  And is the
format for the art proprietary?

<[SPRINGBOARD] DMAY> The program
allows the user to create their own
clip-art or modify the exsisting
clip-art. We don't give out the format
of the clip art....

<J.SLIKER> Okay, back to the XF551 for
a sec...Will SpringBoard Consider
putting the Prog out in a revised Dos
form so I can Load at the fabled (but
so far Unseen high speed of the Xf551?

<[SPRINGBOARD] DMAY> We do have plans
to test the XF551 and see what it
would take to support

<[chuck] AJP82F> what is the quarantee
on the newsroom?

<[SPRINGBOARD] DMAY> 30 day money back
guarantee

<[chuck] AJP82F> if I did order it
which set of art colelection s would
you suggest?

<[SPRINGBOARD] DMAY> What types of
newsletter would you be writting?...
Personal, Organizational, or Business?

<[chuck] AJP82F> mabye a newsletter
for Dungeons & Dragons that would be
distrubutied throughout the reno
area

<ZAP>  Ok..does the copy protection
check for a Happy or rather in my
case, for Double density and will it
run on a Indus GT as to where the XF
will by-pass this protection. Second,
How many drives will it support?

<[SPRINGBOARD] DMAY> Clipart Volume #1
sounds good...but for the low low
price of $69.80...you can get the
Newsroom, and all three clip-art
collections.!!

<[SPRINGBOARD] DMAY> It will work on
one or two drive systems.

<ZAP> and the Indus GT? Some stuff
won't run on a DD drive..

<[SPRINGBOARD] DMAY> We have not done
testing on the Indus.

<TOWNS> I would just like to Thank
Springboard for coming and talking
with us. I would also like to ask if
they have any plans for

<[SPRINGBOARD] DMAY> send your name
and address (via regular mail) if we
need testers...we will contact you.

<TOWNS> future Atari XE or ST products..

<[Craig] C.S.THOM> You mentioned
earlier that the clip art format was
proprietary.  Will the clip art still
be stored as a standard DOS file,...

<[SPRINGBOARD] DMAY> We have no plan
that we can discuss at this time...

<[Craig] C.S.THOM> so that owners may
share custom art work, say, through
GEnie here, or local BBS's?

<[SPRINGBOARD] DMAY> No... the clipart
is not stored as a standard DOS file.

<[Neil] NHARRIS> Thanks very much,
Bob, for representing Springboard here
today

<[Craig] C.S.THOM> Thanks,
Springboard, for stopping by.  Hope to
see you around in the future.

<[chuck] AJP82F> whats the address of
springboard?

<[Neil] NHARRIS> and please make
yourself at home in the 8-bit
roundtable here!

<[SPRINGBOARD] DMAY> Thanks for
inviting us...if you have others
questions you can write us at

SPRINGBOARD
7808 Creekridge Circle
Bloomington, MN 55435

<TOWNS> Thanks for coming
Springboard...We appreciate it!

<[SPRINGBOARD] DMAY> Thanks Neil and
Towns... Bye. Bye....

______________________________________
XF551 Revisited
______________________________________
A Review of the XF-551
From a Programmer's point of view

by Robert Puff  04/88

Atari's new XF-551 certainly has been
quite a suprise to many. I have seen
many comments concerning it, and
thought I would offer some of mine as
well.

The drive is just about the same size
as the 1050, but not quite as high. It
uses a generic-type double-sided
direct drive mechanism which is nice
and quiet, compared to some 1050's
I've heard. The drive uses the
standard 9VAC power supplies used for
the other 1050 and 810 drives. The
back of the drive does get nice and
hot, just like the 1050s, but that did
not affect the drive's operation when
I left it running for a month solid.

The drive runs a little faster (300
RPM compared to the standard 288), but
Atari adjusted for it by clocking
the controller a little faster. So
there is still the same amount of data
in the same format on the disk.

Now we get into compatability. Atari
has done a fair job at making the
drive compatible with the 810 and
1050.

There is only one flaw I found. The
missing sector bit in the status bytes
does not reflect a missing sector
correctly. This should have been
simple enough to do, but they did not.
Because of this, there ARE protected
disks that will not load on a XF-551.
I do not have the titles with me at
the moment, but any program that looks
for a missing sector status will
probably not work.

The next subject is double density.
Finally, Atari has come out with a
true double density drive, which will
read other double density disks.
However, there are some problems here
also. To determine the density of a
disk, normally you read sector 1, and
then issue a status request. One of
the status bytes will then tell you
the density. This works fine for the
XF-551 when it is in single or
enhanced density, but not always for
double.

Instead, double density comes back
with a status of enhanced. Once you
use the set density commands, the
drive may be set to double, and the
status will be correct. Just don't go
back into single, or you'll have to
manually set the density again. To
summarize: If you use single and
double density disks, the drive will
have a very hard time going into
double. Since SpartaDOS has no way of
forcing densities, this can be a real
problem. The only way I've ever seen
it do it automatically is when booting
a double density disk. (Note: I did
figure out a way to make the drive
reconfigure: It is used in Diskcomm
3.2)

The drive is capable of double-sided
operation, giving you a possible 360K
storage when using double density. (Of
course, you must use MYDOS or
SpartaDOS because the DOS 2.5 it comes
with supports none of this.) I found
it strange that it will not use double
-sided operation in single or enhanced
density.

Also another thing to think about is
it uses the index hole of your disks
for timing. This means you cannot
use those cheap hard-sectored disks
anymore, and cannot write to the back
side of the disk like you did with
your 1050, 810, etc... Now this really
dosen't matter if you use its double-
sided capabilities; but if you want to
make up a disk for your club or friend
who has a 1050, and wish to use the
back side, you are out of luck.

The High-Speed disk I/O the drive
boasts is very similar to Happy's 810
warp speed. Although not as fast as
ICD's UltraSpeed, it is fast. The
set-up is similar to UltraSpeed: You
must format with a special sector skew
for optimum speed, which will be slow
when high-speed software is not used.
Strangely enough, the drive only has a
special sector skew for double
density, even though the exact same
command is used for single density. I
have been able to read single density
disks formatted with UltraSpeed sector
skew quite nicely on the XF-551. As of
now, the only programs I am aware of
that make use of the high-speed
capabilities is my Disk Communicator
program version 3.2, and THE ULTRA
SPEED + OS.

Unfortunately, Atari did not make the
drive for expansion. It uses a MCU
chip that takes the place of many
chips the 1050 used. Because of this,
and because it's not 6502 based, I
don't think you will see any products
such as the Happy or Super Archiver
available for a while.

Well, I guess that's it. I have
confirmed the bugs I found with later
models, so it appears they haven't
been fixed yet. Once Atari fixes
these, it should be a very good drive
at a nice price.
______________________________________
A Different Look At Arc
______________________________________
ARCronomicon, The Book of the Dead

(files)

by Jeff Kyle 04/03/88

OK. So you like ARC, eh? So you like
saving time downloading, eh? So you
like being able to get all the files
in one nice package, eh? Think again.
ARC is one of the programs that shall
go into legend, but shouldn't go in a
positive way.

Believe it or not, that innocent
program isn't so innocent. A program
this potentially dangerous should
never be released, much less into the
public domain. (No, I'm not saying
sell ARC.) You've probably noticed one
of ARCs big problems in that it barely
works with any DOSs. ARC will refuse
to work in most DOSs, and when it does
work, it acts differently in most. In
some, it will print out more than in
others, in some (MYDOS) it will
somehow manage to lose characters in
the directory. It's not easy to code
something to work that bad.

And once you get it working, be
prepared to be bored out of your
skull. Just enter the name, and WAIT.
You can't get a directory, it doesn't
like problems, and once you've finally
got that darn file ARCed, that's it.
You can't manipulate what's in it as
you can in ARC on other machines. If
you've closed the ARC, that's it, you
can't change it. If you do want to
change it, you have to start all over.
If you get a huge ARCed file, but only
want one file out of the middle, tough
luck. You've got to wait and wait for
it to slowly process all the other
files that you don't need. But so far
I've just mentioned "extras."

Now for the bad part:yep, it's true,
ARC does murder files. You've all seen
the messages that say "you'll get CRC
errors on this that and the other, but
don't worry, they're fine." Well,
they're NOT fine, they ARE damaged,
and some files that don't get CRC
errors are damaged also. Each time a
file fails the CRC check, it's been
damaged in some way. Pictures can have
stray bytes in them, text files may
get stray letters, binary files
malfunction slightly. Anyone who's
seen the ARCed "Digital Nosebleed/
Atari Wave" knows that ARC can easily
do major damage to files. When a local
person cleared out the bad bytes and
reARCed the clean version of the
program, it had the same problems.

ARC tries to justify this by saying
that it is removing "Xmodem block
padding." Bull. The only time it ought
to have this is at the end of files,
but ARC happily changes bytes right in
the middle of files. And why is it
I've seen much more of the "xmodem
padding" at the ends of text files
that have been ARCed than haven't
been?

And of course this can cause many
problems. Occasionally a machine
language program may refuse to
function. Demo programs may be almost
unuseable, as in Digital Nosebleed.
And what if you have an important text
file, full of specific data? It would
be easy for ARC to change one of those
and very much mess up the file.

So what are the alternatives? If you
need to compact one file, use Squish.
It is faster, and has about equal file
compaction, and is easily modifiable
to turn the screen off while working
by anyone with a rudimentary knowledge
of Action!. If you have to put many
files together, Library will
accomplish that quite nicely. If you
have to do many things and want them
all together along with a DOS, etc,
DiskComm will do compaction and put
the whole disk together as a nice neat
file that tells you if you have bad
bytes in a file.

So think about this next time you
decide to use ARC. There are
alternatives. Nothing is as good as it
could be, but yes, that is being
worked on. (Hint, hint!) So, go on. Go
for it. Stop using ARC. Your programs
will thank you for it.

If you'd like to further discuss this
matter, feel free to leave me E-Mail
on GEnie for JEFF-KYLE.
______________________________________
Computer Show Calender
______________________________________
Courtesy of Gary Gorski
Jersey Atari Computer Group (JACG)

April 9
=======
Philadelphia Computer Swap Meet
Saturday 10 to 5
Philadelphia Park - Philadelphia, PA

April 21
========
Business & Home Computer Fair
Tri State Fairs   Thursday 5-10PM
Rt. 46 Eastbound  Wayne, NJ
Holiday Inn, Info call (201) 533-1991.

Box 76 Livingston, NJ 07039

APRIL 23-24
===========
TRENTON COMPUTER FESTIVAL
850 VENDORS !!!!      SAT/SUN

For more info call (609) 771-2667

May 5-6
=======
The Nineteenth Annual Pittsburgh
Conference on Modeling and Simulation
- Sponsered by The School of
Engineering, University of Pittsburgh

May 7
=====
Philadelphia Computer Swap Meet
Saturday 10 to 5
Philadelphia Park - Philadelphia, PA

May (To be announced)
===
Long Island (NY) Micro Show & Sale -
225 Tables

Grand Royal Hotel - Clinton Ave. -
Hempstead, NY

June 4
======
North Jersey Micro Show & Sale -
500+ Vendors
Saturday 10 to 4 
Fairleigh Dickinson University -
Athletic Center Hackensack Ave. - off
rte. 4 - Hackensack, NJ

June 25
=======
Philadelphia Micro Show & Sale -
190 Tables
Saturday 10 to 3
George Washington Conference Center -
Willow Grove, PA  Exit #27 of PA
Turnpike - Left after Toll Booth

August 20
=========
Cherry Hill Computer Swap Meet
Saturday 10 to 5
Garden State Park - Cherry Hill, NJ

September 10
============
Cherry Hill Computer Swap Meet
Saturday 10 to 5
Garden State Park - Cherry Hill, NJ

October 22
==========
Cherry Hill Computer Swap Meet
Saturday 10 to 5
Garden State Park - Cherry Hill, NJ

November 12
===========
Cherry Hill Computer Swap Meet
Saturday 10 to 5
Garden State Park - Cherry Hill, NJ

For more information or current
updated list call the JACG BBS (201)
298-0161. If you have a show that you
would like added to this list, send to
JACG BBS, c/o  313 Sheridan Ave.
Roselle NJ  07203.. Thanks for your
help, and enjoy.
              -Gary...
______________________________________
PC Pursuit Update
______________________________________
by Keith Whitton (Mr. Goodprobe)

In case you might be wondering
whatever happened to Pc Pursuit and
its proposed upgrade to 2400 baud, you
may have noticed..it STILL isn't
working! Here's the low-down from PC
Pursuit itself, and after that is a
series of notices we have been
receiving that serve to show you the
roller-coaster ordeal they have been
going through with their new modems.
Good news is that there will be an
additional 15 cities added to the
prior list of new cities. Reach out
and touch someone...oops...isn't that
somebody elses line?

"Dear PC Enthusiast:

Since its introduction in 1985,
Telenet's PC Pursuit Service has
offered you a cost-effective
alternative to long distance telephone
service for PC communications
nationwide.  While the performance of
PC Pursuit has traditionally been very
good, we have recently encountered
problems that have degraded the
quality of the service and
inconvenienced many of our users.  We
apologize for any difficulties you may
have recently experienced using the
service.

We are currently taking the following
steps to provide you the type of
service that you expect and deserve.

Outdial Modem Deployment:  A large
number of outdial modems were
installed at the end of 1987 to expand
the capacity of the service.
Unfortunately, unexpected problems
were encountered during the deployment
of the modems, which caused the
expansion To be delayed. These
problems have recently been corrected
by the modem manufacturer, and we are
currently testing the modems to ensure
their operation in the network.

Additional Expansion:  Plans for
additional expansion continue in order
to meet the growing demand for the
service.  In addition to the new
outdial modems to be installed in the
network after testing, we will expand
the network to include even more
outdial ports than originally planned.

Enhanced Net Exchange:  A new system
is being designed for the Net Exchange
Bulletin Board System. The system will
allow the Net Exchange to handle four
times the traffic it can currently
accommodate.

We thank you for your patience and
understanding during this period of
change for PC Pursuit Service.  Over
the next few months we will be
contacting you again as the specific
details and timetables regarding these
expanded capabilities become
finalized. As the new product manager,
I look forward to working for you in
the future to provide you the best
possible service and support.

Sincerely,
Peter Naleszkiewicz
PC Pursuit-Product Manager

03-29-88

Daytime usage bills have definitely
started going out in the mail.

Remember that problems should be
addressed to BILLING DEPT in the
BILLING conference area.

The new PROMS are still scheduled for
install tonight in DC.  Give them a
good workout!

More expansion!  We have tentative
approval for 15 more cities (bringing
the total to 48).  I can't say yet
which ones but I'll let you know as
soon as possible.  These too will be
held up until the new modems are
working - but watch out after that!
We'll be expanding the size of the
exisiting rotories too!!!

Take a look at the file LETTER.TXT in
the PURSUIT file area.  It's a copy of
a letter which is being sent to
customers soon.

03-25-88

New version failed as well.  All new
modems to be removed from DC Saturday
morning [that means that the 2400 bps
service will not be operational
through this weekend]. Another version
is to be installed during the day on
3/29 so the 2400 bps service should be
operational again Tuesday evening (in
DC).

If all goes well on that test, the
modems will be released to Denver and
Boston on 4/14.  Further deployment to
be announced as the modem status firms
up.

03-25-88

New PROM version being tested in DC
modems...results pending.

Daytime usage bills for September to
December should be mailed this week or
next.

03-21-88

Even though the new modems passed
their lab tests, they have been
failing in the DC field tests.  The
vendor is aware of the problem and is
working with us to resolve it.  The
problem includes the modem locking up
(no response to ATZ) and failure to
pass certain characters.

03-15-88

The new modems have finally passed all
their lab tests!!! They're being field
tested start today for 2 weeks in DC
to make sure nothing was missed.  That
means that the 2400 baud rotory in DC
should be available for use starting
tonight.

As long as the DC test goes well, the
modems will be deployed to the rest of
DC, Denver, and Boston for final
testing which will also last 2 weeks.
As soon as I have a schedule for the
rest of the expansion work I will post
it here.
______________________________________
Sharware Review
        ...DeTerm 850...
______________________________________
by John M. Urbansky III

When Keith Ledbetter released the
Express! series of public domain
terminal programs for the Atari 8-bit
computers, many said they were the
best terminal programs available for
any computer.  Users of the Express!
programs loved all the many fine
features of them -- the scrolling
menu, the Ascii/Atascii/Vidtex
support, the automatic dialing,etc.
The general ease-of-use of the whole
series impressed -- and inspired -- a
lot of people.

Now there is a program in the public
domain entitled De-Term 850 -- and it
is every bit as good as Express! --
plus it's packed full of things that
Express! doesn't offer -- such as the
windowing system much like that used
on the Atari ST computers, the LD and
City codes and Identification, and the
included mini version of Breakout that
you can play while uploading,
downloading or waiting for a
connection AT THE SAME TIME!  Whether
this can be called true multitasking
or not is beyond the scope of this
review -- i'll let the experts figure
that one out -- but it is equally
impressive!

But first let's look at some of the
many fine aspects of DeTerm. Presently
it is available only for the Avatex,
Practical Peripherals, Atari SX212, or
any other Hayes-Compatible modem
connected via a suitable interface
(Atari 850, ICD P:R:Connection), but
i'm quite sure as this program gains
popularity, like the original 850
Express! did, versions will be made
for many different modems.  I hope
this is done soon -- DeTerm is far too
good a program to be enjoyed by only
those who have the required interface
and modem(s), or the money to buy
them.

Setup:
======
DeTerm is very intelligent.  After
booting up your DOS and loading the
correct RS232 handler (I had to use
the SpartaDOS RS232.COM handler, since
the handler included with DeTerm
didn't seem to work with my
P:R:Connection), load it in using
whatever DOS you use.  DeTerm works
fine with Atari DOS 2.5 as well as
SpartaDOS Version 3.2 -- which is the
recommended DOS for this program. 
While loading it in the upper part of
the screen shows the name, the author
(James Dillow) and the copyright
notice.  DeTerm is copyrighted, but is
a Share-Ware program -- like Express! 
That is, the program is free and in
the public domain, but user-modified
versions are not to be given away or
sold without permission.  You can make
a donation if you like -- whatever the
program is worth to you.

After the program is loaded in, it
will search for the files List.Bat and
Modem.Bat.  These are batch files that
either load your phone list from disk
or send commands to your modem.  If
DeTerm cannot find them it will let
you know -- but still function
correctly. These files are not
required, they just make things easier
for you.  After that, the screen will
be blank except for the top line,
which will display several options you
can select by moving the cursor keys. 
When your option is highlited, press
[RETURN] and a window will appear
below that option, with several
choices of it's own.  Again, move the
cursor keys to the option you want and
press [RETURN].  There are many
options De-Term can handle -- and all
are easily selectable by this method. 
I believe it is far simpler than
memorizing cryptic command codes or
having to refer to a manual.

Features:
=========
De-Term offers uploading and
downloading using XModem protocol, as
well as text capture.  It doesn't
support YModem yet, but future
versions might include this.  The
versin number for the De-Term that is
presently in the public domain is
1.00b -- the lowercase "b" meaning
this is an experimental version.  It
also lets you force terminal mode with
your modem, as in Express!, so that
you can enter commands directly to
your Hayes-Compatible.

Some of the other features are less
essential but show a thoughtful touch.
The View option creates a text frame
on the screen and lets you view a text
file a page at a time (one page being
about 18 lines or so).  When you are
finished reading this page, hit any
key and the screen will scoll up
another page and wait for you to hit
another key.  I found this very handy,
and frequently boot De-Term just to
read text files!

Then there's the included mini-
Breakout game -- something i've never
seen in any terminal program for the
8-bit Atari's before.  After dialing a
number, you can press Control-G for
the Breakout game (Control-F to resume
a previous game) and play it until the
modem connects with the other
computer, information service, etc,
and the screen will go to terminal
mode and let you communicate.  Now
let's say there's a file you'd like --
but it's pretty large and would take
more than a few minutes to download. 
Simply start the transfer, then press
either Control-F or Control-G again --
and you can play Breakout while the
transfer is taking place!  (If you
don't believe me -- try it and look at
your modem's RD and SD indicators --
they will be flashing indicating data
transfer!)  When the transfer is
complete De-Term returns you to
terminal mode, and you can resume
communicating.  This also works for
uploads.

Overview:
=========
All in all I like De-Term very much,
and use it regularly instead of
Express!  I still use Express!,
especially if i'm communicating with
someone who is rather impatient
(De-Term's transfer is a little slower
checking blocks than Express!) but i'm
not often in that situation.  I love
the windowing system -- better than
the Express! scolling menu, and the
screen buffer and City codes are nice,
but let's face it -- I LOVE the game! 
No longer do I have to stare at a
screenful of cryptic control
characters while uploading or
downloading!

(C) John M. Urbansky III
SysOp Discovery BBS    216-626-5187
______________________________________
Syndicate ZMagazine     April 11, 1988
Issue #101 (c)1988 SPC/Ron Kovacs
______________________________________


-----------------------------------------
Return to message index