Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 524
Info-Atari16 Digest Thu, 3 Oct 91 Volume 91 : Issue 524
Today's Topics:
Atari 1040STf with hard drives for sale
C on the ST
GhostScript and all that
Good places to anon-ftp atari-pd-software from
lharc 2.01e vs zoo 2.1: some tests
lharc source...
lharc vs. zoo (my correction)
lharc vs zoo (my correction)
Mega2 questions
Questions on PC-Speed
SIM CITY - STe Compatible????
SST for 1040STe's ??
STE simms
Using gcc/g++ to cross compile for the ST
ZOOSHELL 0.6
Welcome to the Info-Atari16 Digest. The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out. Please send notifications about broken digests or bogus messages
to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list
instead of the moderators are likely to be lost or ignored.
If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------
Date: 2 Oct 91 23:04:11 GMT
From: noao!asuvax!cs.utexas.edu!milano!cactus.org!covert@arizona.edu (Richard
Covert)
Subject: Atari 1040STf with hard drives for sale
To: Info-Atari16@naucse.cse.nau.edu
FOR SALE:
1040STf with 2.5 megs RAM, dual TOS 1.0/1.4
Atari SM124 monochrome monitor
Tweety board (not installed)
IMG SCAN scanner
Asking $550 for the computer system.
Also two hard drive systems:
Atari MegaFile 30 $300.00 30 megabyte hard drive
TOADFILE 85 $600.00 85 megabyte hard drive. Room for a
second 85 meg drive in cabinet.
130 megabyte home built hard drive. This is kinda upgly as the original
power supply burned out and I replaced it with a larger power supply
that wouldn't fit in the cabinet. So, I have the two Seagate 65 meg
drives with the ICD host adapter and the power supply sitting in an
open cabinet. Asking $500 for this one.
Also, Panasonic KXP4450 laser printer with 1.5 megs RAM, dual paper trays,
11 pages per minute printout (heavy duty office quality laser printer)
$1000.00 (you pay shipping). The KXP4450 is cheap to use as the toner
kit only costs about $45 from any office supply store. I use Hurrican
Office here in Austin.
I have some software I might be talked into including as well, just
ask.
--
Richard E. Covert covert@cactus.org
CACTUS ..!cs.utexas.edu!cactus.org!covert
------------------------------
Date: 2 Oct 91 23:27:35 GMT
From:
noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc
.edu!unmvax!uokmax!kllove@arizona.edu (Kenneth L Love)
Subject: C on the ST
To: Info-Atari16@naucse.cse.nau.edu
Okay, I've posted this question before, but I lost my reply file.
I'm looking to get C for my Mega 2, but I need something that can
be used from a floppy based system (I have to DS/DD drives).
Is Sozobon any good? Will it work with the above condition?
I bought called 'A Book on C' by ??? and Ira Pohl. It seems to have
quite a good discussion on C (for IBM/Unix systems :( ), but I couldn't
find anything about how to check the mouse or anything about graphics.
Is there an Atari specific book that talks about this?
Oh yeah, I want to convert a BASIC program to C, but I need to know how
to do PEEKs and POKEs in C.
I'm not sure what the ST Basic command "vdisys(1)" does, but I gather
it has something to do with the mouse (based on the context of the
program). What the "chain" command is and how it works would also be
nice to know.
Please respond by e-mail as I don't keep up with this newsgroup on a
regular basis (messages are gone in 2 days around here and I read
r.g.frp, r.a.startrek, and r.a.drwho before this one).
Thanks in advance,
Kenneth Love
------------------------------
Date: Thu, 3 Oct 91 15:51:35 WET DST
From: "Ian McCall (Scorpion)" <csd015@central1.lancaster.ac.uk>
Subject: GhostScript and all that
To: Info-Atari16@naucse.cse.nau.edu
I've been hearing quite a bit about GhostScript recently, and it sounds
very interesting. But it's part of GNU or something, isn't it? Could
somebody post up exactly what I'd need to do, from scratch, to get a
working version of GhostScript?
Also, I now own a Mac LC as my main machine, but I've heard you can get
GNU for the Mac too. Is GhostScript around for that, and if so, would I
just follow the same procedure with Macintosh versions of the files as I
would for setting up the ST version?
Thanks in advance,
Ian McCall (csd015@uk.ac.lancs.cent1)
------------------------------
Date: 2 Oct 91 15:27:27 GMT
------------------------------
Date: 2 Oct 91 18:36:52 GMT
From: garfield!odie.cs.mun.ca!david10@uunet.uu.net (David Churchill)
Subject: lharc 2.01e vs zoo 2.1: some tests
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Oct02.023218.28662@infoserver.th-darmstadt.de>
DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes:
>Following the discussion I tried three archiver programs
>to backup 151 files worth 700KB of data. The data consisted
>almost entirely of documentation (ASCII) and C source.
>
>Machinery: ST-1MB w/40MB ST-251-1
>I did NOT clean my partition for this test, why should I? I
>never evacuate any partition just for arcing things up. So
>I think this is more true to life, than any more 'scientific'
>setup. I did the test twice, which didn't change any of
>the timing values significantly and gave every program
>a 'fair' chance on a equally fragmented harddisk. Fragmentation
>is more of an issue when unpacking anyway.
Fair enough.
>
>Results:
>
>ARC 6.02
> Size: 304048 bytes Time: 3:48
>
>ZOO 2.1
> Size: 307207 bytes Time: 4:45
>after issueing a pack command for an additional 2:20
> Size: 307151 bytes
~~~~~~
Hmmm, something fishy here . . . zoo 2.1, using the high compression scheme,
should be closer to LHARC than this.
>
>LHARC 2.01d
> Size: 218964 bytes Time: 6:13
>
>(my) conclusions:
> So guess what, good old ARC is by far the fastest,
> LHARC is the tightest,
> And ZOO well the -um- most compatible...
>
>
>And they way I called them (thru make)
>
>#ARC=arc
># update
>#UPDATE=u
># update with subdirectories
>#DIRUP=uz
>
>#ARC=zoo
># update
>#UPDATE=aun:
~~~
Yup, this is a zoo 2.01 compatible archive, not a 2.1 archive. To use the
high compression method, the command line should be 'ahun', not 'aun'.
># update with subdirectories
>#DIRUP=aun//
Ditto for here.
>
>ARC=lharc
># update
>UPDATE=u -s -wf:\tmp
># update with subdirectories
>DIRUP=u -r2 -p -s -wf:\tmp
>
>GSOURCES=*.h *.c *.tlk *.s *.y make*.* memo
>
>backup:
> $(ARC) $(DIRUP) arc\backup support doc lib header demo
> $(ARC) $(UPDATE) arc\backup $(GSOURCES)
It's a good test (in a real-world sense), but to be fair to Zoo 2.1, it can
compress files MUCH better than what this test has shown, along with being
more compatible across platforms.
> Nat!
Later,
Dave C
--
Dave Churchill DoD #266 * * * CS Undergrad (Class of '92)
david10@garfield.cs.mun.ca * * * Memorial University of
ar473@freenet.cleveland.edu * * * Newfoundland.
My opinion is just that - mine! * * * St. John's, NFLD Canada
------------------------------
Date: 2 Oct 91 22:53:13 GMT
From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
Subject: lharc source...
To: Info-Atari16@naucse.cse.nau.edu
since i have received numerous requests for lharc 2.01e source in
anticipation of actually getting it, let me try and put an end to
these requests.
i have just received the source from thomas (infinite thanx, that
wasn't so hard now was it?). however, i also agreed that i would NOT
distribute this source, or any derivative source and i will abide
by that agreement. please don't bother asking me. i cannot and will
not post it or mail it or in any other way distribute it. i will ignore
all requests for same. i gave my word.
with that in mind, however, when/if i have time, i do intend to
return this particular version BACK to 100% C, in fact 100% portable
ANSI/POSIX (32-bit int) C. i will focus on the portions of the code
in assembler, returning them to C. i will profile the code (even
vectorize it!) and optimize the C performance as much as i care to
so that i will be satisfied with its performance. i will also fix
the bugs in it. this will not happen for several months. after that,
i will return this portable version to thomas for his own use. if he
chooses to release it, he can. if he chooses to continue that work,
i will applaud him. if he moves it to /dev/null, that is fine, too.
oh, and i'll go further: i will not post/mail/etc a BINARY ST version
either which would be as bad (actually worse). i might be persuaded,
however to distribute a convex executable image, if anyone out there
has a convex :-).
so, i guess i am happier now about the lharc situation. TQ's version
does seem to be the best version on the ST. and i will eventually
(finally) have a unix version to boot. henceforth, i shall retire
from most all public discussions on portability of archive formats.
i still don't think i can recommend lharc as a universal archiver,
but at least i have done something for myself to remedy some of the
problems i have with it. i still think at this point in time, zoo
is about the best overall archiving system available across the board
(i.e. independent of platform). a close second would be compressed
tar files, i think. then arc, and then possibly lharc. lharc _could_
rise to the top of my short list by having all lharc developers get
together and decide on a standard. i just don't ever see that happening.
i think someone mentioned that the amiga version also uses the lh4
format, which i am not sure 2.01e supports. so some amiga .lzh files
would not be extractable on an st. of course, at some future time, there
will probably be an new lh* format. then i am again back to bitching...
thank you all for your support during this effort. now we can proceed
with other issues :-)
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 3 Oct 91 14:59:11 GMT
From:
europa.asd.contel.com!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!mailgzrz!
opal!unido!mcsun!news.funet.fi!sunic!chalmers.se!dtek.chalmers.se!dxper@uunet.u
u.net (Per Anders Olausson)
Subject: lharc vs. zoo (my correction)
To: Info-Atari16@naucse.cse.nau.edu
DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes:
>As two people have pointed out I lost 'cause I oversaw the 'h' option
>on Zoo 2.1. I ran the tests again and sure enough the results of ZOO
>came very close to Lharc. Which makes conclusion wise ZOO as good
>as Lharc really.
I found when using ZOO V2.1 from my backup program (which can use any
compression utility) that ZOO V2.1 still wasn't completely error free.
Unfourtunately I don't remember what the implications were, but since then
I use LHarc. Both ZOO and LHarc are the only, known to me, which accepts
hidden and system files so for me that's the only choice.
Also note that the earlier LHarc V2.01? versions quite a lot of bugs which
could trash compressed data.
pao
--
.............................Andrew Olausson................................
............................Systems Architect...............................
..........................dxper@dtek.chalmers.se............................
..............................pao@proxxi.se.................................
------------------------------
Date: 3 Oct 91 22:53:34 GMT
From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
Subject: lharc vs zoo (my correction)
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Oct03.183321.13105@infoserver.th-darmstadt.de>
DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes:
>I/O. The cleverer the buffering strategies and the less i/o done (in
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>most cases) the better. If you just do I/O on ideal devices (clean RAMdisk),
>you are punishing programs who use more clever i/o in order to circumvent
>the ususal everyday pitfalls.
yes. agreed. and i did eliminate this from the test as well, tho not for
the reasons that people thought ("he hates lharc so he wants to make sure
zoo wins"). you are correct that a comprehensive test would have sought out
these strategies as a desirable trait. i did mention this in the original
post as well. my hypothesis going into the test was that both were going
to be pretty equal on all fronts. my evidence was that zoo was compiled
with GNU C by someone whose previous (excellent) work i was familiar and
that lharc was well tuned by conversion to assembler.
to be fair to me, however, and those with similar situations, i generally
either extract a new archive into a ramdisk to "check it out" or when
creating an archive of something on hard disk i write to an archive file
in ramdisk. in both cases, which constitues maybe 75% of my archiving,
maybe more, the only cleaverness is how the original files are read and
the disposition of any temporary files (i.e. is the program smart enuf
to recognize i am ususally smart enuf to make $TEMP a ramdisk?). i think
the fact that your equally limited tests, tho perhaps more realistic for
your particular use, shows little difference implies that as far as IO
is concerned, both are about as smart (or dumb). i suspect smart because
i know of at least one tiny modification (which bill shroka did in fact
do) which improves zoo's performance. i have not had a chance to examine
lharc, tho i suspect it handles things pretty much the same.
>As devices get faster, I/O importance lessens.
another important point which can be broadened futher: as cpu's get faster,
archiver tuning lessens in importance. as disks and communications get cheaper
and faster, compression ratio lessens in importance.
>BTW: A better test would be to setup partitions of various sizes and fragmen-
>tation on several different devices and then do the tests again
>(just in theory, who's got the time..) - and - Just because a result is repro-
>ducable, doesn't make it automatically the most meaningful result.
yes, but it DOES make it reproducable, in itself desirable over something
both non-meaningful and non-reproducable. one is subjective, the other
objective. your definition of meaningful may not be meaningful to someone
else. and even if it were, if it could not be reproduced, it would resort
to hearsay.
there are ALWAYS better tests. i think mine was fair for what i did. i tried
to point out some of the weaknesses in the test that i saw. and i think that
there can be no question that it is valid if all your archiving is done in
ramdisk. except that i did not necessarily use "calibrated" files. i did,
however, give a source for the files at least in one of the tests (portions
of the MiNT distribution) so it could be reproduced.
> Nat! (using ZOO [with 'h'] more often nowadays)
EXCELLENT!!!!
ciao
-bill
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 3 Oct 91 21:40:06 GMT
From:
europa.asd.contel.com!darwin.sura.net!haven.umd.edu!uflorida!mailer.cc.fsu.edu!
open!boyd@uunet.uu.net (Mickey Boyd)
Subject: Mega2 questions
To: Info-Atari16@naucse.cse.nau.edu
In article <kemionINN4ub@matt.ksu.ksu.edu>, kenneth@matt.ksu.ksu.edu (Kenneth W
Samson) writes:
>I have three questions for those outthere that have Mega2s...
>
>2) I know that Mega2 will go to 4 meg of memory, but will it
> go all the way to 16 with standard simms on the motherboard?
>
This is not true. Some Mega2's have the traces and sockets for more memory
(none of them use SIMMS, by the way). Some have the traces, but no
sockets. The newer ones not only have no traces or sockets, but they have
an MMU that only allows for 2mb. You can upgrade any Mega2 with a third-
party board, but you may need a new MMU also (they are not all that expensive).
Four megabytes is all the Mega's can handle unless you do strange things
(which would undoubtedly cause a lot of software to bomb). Dave small reports
that he has a 16meg 1040 for Spectre testing purposes.
Also, I read once that there are a select few Mega2's out there that have
4 megs in them, but are jumpered (or trace-cut) to only access 2megs. The
reason for this (reputedly) is that if a Mega4 fails quality control, they
jump/cut it and test it as a Mega2. If it works, it gets packed up and
sold. One poster to this group (about two years ago, I seem to remember)
was shocked to find this out. After tracing down the bad chip, he replaced it
and un-jump/cut the motherboard to get a Mega4. Ahh, the stuff dreams are
made of . . .
--
---------------------------------+-------------------------------------
Mickey R. Boyd | "Come to your senses professor
FSU Computer Science | Fernberg. You did not transcend
Technical Support Group | the time-space continuum. You
email: boyd@nu.cs.fsu.edu | got drunk in a topless bar."
---------------------------------+-------------------------------------
------------------------------
Date: 3 Oct 91 21:09:31 GMT
From:
arizona.edu!cerritos.edu!orion.oac.uci.edu!usc!zaphod.mps.ohio-state.edu!unix.c
is.pitt.edu!dsinc!netnews.upenn.edu!eniac.seas.upenn.edu!efaskha@arizona.edu
(Eli Faskha)
Subject: Questions on PC-Speed
To: Info-Atari16@naucse.cse.nau.edu
Help. I've had a PC-Speed for some time, but haven't really taken full
advantage of it. I know it can recognize the Atari ST mouse as a Microsoft
Mouse, but I can't get it to do it...
Also, what's the latest revision of the software? I have revision 1.3, and
I think there might be a new one out.
Where can I get in touch with Talon Technologies? Anyone know a net address
or phone number?
Thanks,
Eli
------------------------------
Date: 3 Oct 91 02:05:23 GMT
From:
noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-st
ate.edu!linac!unixhub!ditka!slacvm!reeves@arizona.edu (Terry Reeves)
Subject: SIM CITY - STe Compatible????
To: Info-Atari16@naucse.cse.nau.edu
Sim City runs just fine on my STE, a 4meg 520 STE. The TOS version is 1.62.
Terry
Disclaimer: The above opinions are my own, and mine alone.
------------------------------
Date: 3 Oct 91 03:29:46 GMT
From:
noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!
udecc.engr.udayton.edu!blackbird.afit.af.mil!lonex.rl.af.mil!longj@arizona.edu
(Jeffrey K. Long)
Subject: SST for 1040STe's ??
To: Info-Atari16@naucse.cse.nau.edu
Can anyone tell me if Dave Small will make a version of the
SST that will work with 1040STe's?? I remember reading something about
it several months ago, something to the effect that if STe sales
warranted, then an adaptor to connect to the square 68000 in STe's.
I sure hope the answer is yes! I am about ready to upgrade somehow, and
the thought of being able to get an '030 box that might be able to run
UNIX and still have my beloved atari stuff close at hand is
intoxicating!!
If yes, when and about how much will such a beast set me back?
Jeff
--
----------------------------------------------------------------------------
Capt Jeff Long Rome Laboratories, Griffiss AFB, NY
longj@lonex.rl.af.mil (preferred) Network Design Laboratory
jlong@cassiopeia.rl.af.mil (315)330-7751 or (DSN)587-7751
------------------------------
Date: 2 Oct 91 12:39:08 GMT
From: aahs.no!data3d@ucbvax.berkeley.edu (Karl Anders 0ygard)
Subject: STE simms
To: Info-Atari16@naucse.cse.nau.edu
[Wayne Martinez writes]
>Can I just go out and purchase some simms, crack the case,
>and plug them in?
Obviously. At present I've got 4 9-bits 70ns 1Mb simms installed in my STe,
giving me a total of 4megs. I got the simms 9-bits (8-bits will pass, I think)
and 70ns (100ns should be enuf?) so that I'd be able to use them on a PC or a
Mac, should I decide to do so.
Mind you, all of this may be wrong. Correct me if it is. ;)
Karl Anders Oygard - Karl A Oygard <data3d@aahs.no>
------------------------------
Date: 2 Oct 91 23:25:45 GMT
From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
Subject: Using gcc/g++ to cross compile for the ST
To: Info-Atari16@naucse.cse.nau.edu
>I'd like Unix zoo 2.1 source too, been too lazy to go looking myself.
atari.archive.umich.edu:atari/archivers/zoo21src.* (forgot if zoo or
arc).
>I'm a little hazy on the MiNT support in the current version of gcc.
>It causes the mint libraries to be loaded before the regular libraries,
>but the mint library docs say "use this instead of the regular gnu
>libraries." Some agreement/clarification would be nice.
sure, howard:
it took me a couple of tries myself. however, is is not too bad.
i think the makefile in the t100 terminal emulator i recently posted
has this. let's see if i can remember (for GCC 1.40, gmake 3.60, mint
lib PL 10, i think - gmake contains some of my own hacks to get it to
work for me):
# makefile from t100 (compiled for mint)
CC = gcc
OPT = -O
# -v=verbose, -Wall=all warnings, -z=errs to compile.err, -I->mint *.h
CFLAGS = -v -Wall -z -Ig:/mint/include $(OPT)
# -nostdlib is the key. also explicit crt0.o
LDSPECIAL = -nostdlib g:/mint/lib/crt0.o
# -L->mint *.olb
LDFLAGS = -v -Wall -z -Lg:/mint/lib $(LDSPECIAL)
# both gnu.olb and iio.olb must be specified as a byproduct of -nostdlib
LIBS32 = -lgnu -liio
LIBS16 = -lgnu16 -liio16
# if -mshort, use LIBS16...
LIBS = $(LIBS32)
TARGET = (your .ttp file here...)
OBJS = (your program .o files here...)
$(TARGET): $(OBJS)
$(CC) $(LDFLAGS) -o $(TARGET) $(OBJS) $(LIBS)
there is probably a better way, but something along this lines should work.
i keep "normal" gnu libraries and includes in g:/gcc/{lib,include}.
-bill
rosenkra@convex.com
long live GCC...
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 3 Oct 91 20:06:40 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!caen!spool
.mu.edu!cs.umn.edu!thelake!steve@arizona.edu (Steve Yelvington)
Subject: ZOOSHELL 0.6
To: Info-Atari16@naucse.cse.nau.edu
I recently shipped ZOOSHELL 0.6 off to atari.archive.umich.edu, and
(naturally) a bug surfaced quite quickly. The bug is fairly obvious in the
code, which also is available at a.a., so if you have Sozobon C and want
to fix it, change the following in main():
strcpy(zoottp,p);
to
if (p != NULL)
strcpy(zoottp,p);
This bug surfaces only if ZOOSHELL can't find ZOO.TTP in the current
directory or with a PATH search. If you use an environment-setting utility
(which I wholeheartedly recommend for Desktop users) you'll never
encounter this one.
I intend to release a newer version of ZOOSHELL, but at the moment I'm
bogged down in the process of writing ARGV-compatible startup and
process-control code so that ZOOSHELL can pass very long arguments to ZOO.
(I also am doomed to work for a living, which interferes with recreational
pursuits.)
--
Steve Yelvington, Marine on St. Croix, Minnesota
steve@thelake.mn.org (In winter we walk on water)
------------------------------
End of Info-Atari16 Digest
******************************
