Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 008
=========================================================================
INFO-ATARI16 Digest Wed, 3 Jan 90 Volume 90 : Issue 8
Today's Topics:
Changing Rez: What we _really_ want to know
LHARC takes over? Sure hope not! (3 msgs)
Making the SH205 silent
media change problem with Toshiba drive
----------------------------------------------------------------------
Date: 4 Jan 90 00:47:19 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: Changing Rez: What we _really_ want to know
Message-ID: <1921@atari.UUCP>
dmb@TIS.COM (David M. Baggett) writes:
>Although Allan says you can call the Bios from within a routine installed
>as process termination handler (at 0x102), I sure couldn't. Adding the
>single line
> Setscreen(-1L, -1L, 1);
>causes my program to crash horribly.
Well, this ought to work. I don't know why it wouldn't. Are you sure
it was just that line? I use it all the time. I have modified a ray
tracer so it shows its progress; it switches rez all over the place,
and switches back (successfully!) if terminated with ~C or something.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 3 Jan 90 18:29:55 GMT
From: hp-pcd!hplsla!andyc@hplabs.hp.com (Andy Cassino)
Subject: LHARC takes over? Sure hope not!
Message-ID: <5440094@hplsla.HP.COM>
grieggs@jpl-devvax.JPL.NASA.GOV (John T. Grieggs) writes:
| Gee, I certainly hope that LHARC doesn't take over. Why? Three reasons.
|
| 1: It doesn't exist on many machines.
| 2: It isn't that good.
| 3: It's as slow as molasses.
|
| I did a benchmark on my AT clone at work, using a variety of filesets and
| all the compression programs I had around.
.
. (text omitted)
.
| LHARC was abysmally slow. Compression was better than ARC or ZOO, but no
| better than PKZIP. It takes sooooo looooong to do simple operations that it
| is simply not usable (IMHO). Does trees, tho.
Gee, I'd venture the opinion that LHARC runs lots better on the ST than
it does on an AT clone!
I ran some tests on my ST this weekend. LHARC .51 was slower than ARC
5.21 but it was neither abysmal nor unusable. It took maybe 30% longer
to compress; un-LHARCing seemed comparable to un-ARCing. LHARC did a much
better job of compression - up to 25% better in my tests! I concluded
that any extra execution time was compensated many times over by the decrease
in download times (and costs) due to the superior compression. Therefore,
I don't mind using LHARC for GEnie uploads/downloads or other BBS downloads
at low baud rates.
As for Usenet binaries, Steven Grimm has stated that LHARC source must
be available before LHARC'd binaries are acceptable. When/if that happens,
I would think that conservation of net bandwidth should make LHARC the
preferred program.
(Then again, I hear ARC 6.0 is out and it is supposed to be better than
LHARC....)
Disclaimer: The opinions expressed herein are those solely of the author,
who has no pecuniary interest in the companies, products,
or publications mentioned above.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Andy Cassino %
% uucp: hplabs!hplsla!andyc domain: andyc%hplsla@hplabs.hp.com %
% Hewlett-Packard Lake Stevens Instrument Division %
% 8600 Soper Hill Road Everett, WA 98205-1298 %
% (206) 335-2211 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
------------------------------
Date: 4 Jan 90 01:25:12 GMT
From:
cs.utexas.edu!samsung!rex!uflorida!beach.cis.ufl.edu!cr1@tut.cis.ohio-state.edu
(Christopher Roth)
Subject: LHARC takes over? Sure hope not!
Message-ID: <21611@uflorida.cis.ufl.EDU>
Just thought I'd say a few things:
First of all, can anybody please mail me arcgsh version 2.1? All
attempts to get this program from wuarchive.wustl.edu have been a
complete and total failure. I'd appreciate it.
As for the ZOO -VS- LHARC discussion, I use ZOO quite a bit.
Currently, I am converting the Atari ST files on an 8 line BBS in
Florida over to ZOO. The things I like about ZOO are:
1) It compresses, ussually, better then ARC does. We've saved
quite a bit of disk space.
2) There are some nice features. It is USEFUL to have the
ability to add a comment into that archive, many has been the
time I have downloaded a file and forgot what it was. I also
like the fact it saves the complete pathname of the file. None
of this archives-within-archives stuff to preserve pathnames.
LHARC might compress a bit better, but it it not as widely used as
LHARC and as available on other machines.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Christoper Roth * "Machines have no
* InterNet : cr1@beach.cis.ufl.edu * Conscience..."
=-=-=-=-=-=-=-=-=-=-=-=-=-Post No Bills-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------
Date: 4 Jan 90 02:41:21 GMT
From:
cs.utexas.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jpl-devvax!grieggs@tut.
cis.ohio-state.edu (John T. Grieggs)
Subject: LHARC takes over? Sure hope not!
Message-ID: <6724@jpl-devvax.JPL.NASA.GOV>
In article <5440094@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) writes:
>Gee, I'd venture the opinion that LHARC runs lots better on the ST than
>it does on an AT clone!
I thought about this after I posted - the speed of LHARC will depend in
part on the port and the machine it is running on. It runs quite a bit
faster on the AT, incidentally. When I get something in LHARC form, I
normally undo it on the AT and tranfer it over via 3.5 inch floppy (if
it fits) or 19,200 baud cable (if larger than 720K). It seems faster to
un-LHARC on the AT and transfer serially, than to un-LHARC on the ST,
but I have not benchmarked that one...
_john
--
John T. Grieggs (Telos @ Jet Propulsion Laboratory)
4800 Oak Grove Drive, Pasadena, Ca. 91109 M/S 301-260A (818) 354-1453
Uucp: ?cit-vax,elroy,chas2?!jpl-devvax!grieggs
Arpa: ...jpl-devvax!grieggs@cit-vax.ARPA
------------------------------
Date: 4 Jan 90 00:30:13 GMT
From: uvm-gen!pegram@uunet.uu.net (pegram r)
Subject: Making the SH205 silent
Message-ID: <1371@uvm-gen.UUCP>
From article <891219125847.519899@DMZRZU71-UNI-MAINZ--GERMANY>, by
Ritzert@DMZRZU71.BITNET:
edited greatly...
> I just succeeded getting our (previously extraordinary loud) sh205 silent.
good advice deleted...
> - I replaced the fan by a silent one.
>
> mjr@dmzrzu71.bitnet
Any advice on type of fan? Size, AC or DC, Db rating, manufacturer
and model? I'd like to quiet my third party Hard drive box from it's
current "loud PC AT" 8-) rating.
Bob Pegram@griffin.uvm.edu
------------------------------
Date: 4 Jan 90 04:35:17 GMT
From: shlump.nac.dec.com!enginr.dec.com!landry@decwrl.dec.com
Subject: media change problem with Toshiba drive
Message-ID: <7193@shlump.nac.dec.com>
I read most of the messages on using generic drives with the ST and
didn't expect any problems but . . .
I'm adding a Toshiba ND-352TH-A also known as FDD4216G0D as a
second floppy. If I leave the media change diode
(pin 34 ---|<|--- pin 28) out, everything works fine, except of
course media change is not detected. With the diode, once the disk
is removed once it always appears write protected.
So I looked at the signals (only have a logic probe at home - but
it's a good one :-) ). The "no media change" condition is
indicated by a "high" on pin 34 (jumper selected for this function)
all the time. "Media change" is indicated by that pin toggling
with no drive select or constant low when the drive is selected.
It seems that the only way I can get "no media change" is to
power up the new drive with a disk inserted AND then reboot the ST.
Once the disk is removed once, "media change" is always indicated.
So, my questions are:
1) What is the media change signal really supposed to do?
I guess that really is, what does Atari expect it to do?
2) What is supposed to reset it from the "media change"
condition?
3) Is it possible to use this drive with the ST?
thanks
chris
------------------------------
End of INFO-ATARI16 Digest V90 Issue #8
***************************************
