Info-Atari16 Digest         Sat,  1 Jun 91       Volume 91 : Issue 307
 
Today's Topics:
                            'only_ste.lzh'
                              .gif files
                ASCII text files on UNIX and Atari ST
                        assorted TT questions
                 Atari's position in the U.S. Market
                        Atari 540ST Questions
                             Atari Mortis
                               Atari TT
                        Gemini Standard Usages
                            Lynx and sega
                            PageStream 2.1
                          The Current Market
                     Weekly Posting of New Stuff
                  What's a fair comparison? (2 msgs)
               What happened to comp.sources.atari.st?
 
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: 31 May 91 15:03:18 GMT
From: news-server.csri.toronto.edu!torsqnt!lsuc!jimomura@uunet.uu.net (Jim
 Omura)
Subject: 'only_ste.lzh'
To: Info-Atari16@naucse.cse.nau.edu
 
In article <134302@unix.cis.pitt.edu> rjast1@unix.cis.pitt.edu (Robert J Anisko)
 writes:
>In article <CMM.0.90.2.675623718.larserio@kvart.ifi.uio.no> larserio@ifi.uio.no
 writes:
 
 
 
>  For any users that might have been Atari 8-bit users at one time, the
>MSA (Magic Shadow Archiving) works in the same way as DISCOMM or Scrunch -
>it simply takes data from the whole disk (including boot sectors) and
>puts it into a file, so it can be transmitted via modem.  Then when the
>file is received, you just reverse the process and unpack it to a full
>disk, boot and all.  For some programs and demos, this is the only
>way to go about it (say an author doesn't want you messing with his/her
>data (by loading a file into an editor such as Edhack) - so he/she
>wipes out the directory and makes the program autobooting - kinda
>a method of file protection...
 
     Now that's getting down right, uh, not-very-intelligent.
Anybody with enough knowledge to analyse an object code file
probably has sufficient tools to read sectors anyway.  For
the rest of us who have no intention of playing with their
object code they do us the great honour of create a situation
where virus distribution can increase.  All we need now is
somebody forging a copy of this 'only_ste' demo kit with a
virus in place of the original boot sector and dozens of
STE owners are going to find themselves doubting the wisdom
of their purchases.
 
     While we're on the topic of viruses, I was very impressed with
the "finish" of VKiller.  It got me to thinking about such programs.
VKiller identifies ST boot sectors and where possible specifically
identifies viruses.  But even the warning about boot sectors is
well done.  I was just thinking that many of us use Atari ST's in
"mixed environments" with MS-DOS machines and it would be helpful
if VKiller identified MS-DOS boot sectors as well.  I wouldn't go
so far as to try and keep up with the MS-DOS virus situation completely,
but just give a warning like this:
 
"MS-DOS Executable boot sector found.  If this disk was not supposed
to have one, you might want to discuss this with whomever supplied
the disk."
 
     That way you could alert an MS-DOS user that s/he might have
a virus.
>
>                                       Robert Anisko
>                                       rjast1@cis.unix.pitt.edu
 
 
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura
 
------------------------------
 
Date: 1 Jun 91 05:25:03 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!caen!dali.cs.montana.edu!milton!tymbrim
 i@arizona.edu (Ben Gilbert)
Subject: .gif files
To: Info-Atari16@naucse.cse.nau.edu
 
In article <1991May31.172345.19875@news.larc.nasa.gov>
 klassa@asdsun.larc.nasa.gov (John Klassa) writes:
>Is there an FTP site somewhere that maintains an archive of .gif files?
 
>Thanks,
>John Klassa
>klassa@asdsun.larc.nasa.gov
 
Here's a few anonymous FTP sites that have .gif files (I haven't
  tried all of them yet, they might be outdated...) :
 
           System name                           IP Address
        -------------------                     -------------
 
        a.cs.uiuc.edu                           128.174.5.20
        ssyx.ucsc.edu                           128.114.133.1
        surya.waterloo.edu                      129.97.129.72
        wuarchive.wustl.edu                     128.252.135.4
 
 
------------------------------
 
Date: Fri, 31 May 91 20:45:29 BST
From: TAN JUN <tan@essex.ac.uk>
Subject: ASCII text files on UNIX and Atari ST
To: Info-Atari16@naucse.cse.nau.edu
 
I am very disappointed to find that I cannot use my Atari ST 1040STE at home
to write/edit any pure ASCII text files if I want to transfer it later to my
SPARC using Mtools. The problem is that, any newline returns are marked with ~M
when I use UNIX vi (or Sun textedit) to edit. Actually, I had noticed these
strange things quite often when I downloaded stuff from network and un-pack
on SPARC and viewed text files such as README, *.doc, *.txt, etc. I could not
hit return for extra line, I had to use space for new page as I used UNIX 'more'
command. Also, if I used vi to edit, I had the same problem as I had on files
transferred from Atari. However, these files are definitely normal when I
use 1st-Word or stevie.ttp (vi clone) to edit on my Atari.
 
I have been on this wonderful newsletter list for quite a long time, although
I have been always a only silent reader. I wish that somebody could give some
advice on this matter. Is that a individual problem only happened to my Atari?
Or is that common? Any suggestions or experimences?
 
Prefer reply by E-mail (save bandwidths for good things), or on newsletters.
 
Thanks for consideration.
 
E-mail: tan@uk.ac.essex
 
 
Jun Tan
 
------------------------------
 
Date: 31 May 91 01:43:01 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!chaph.usc.edu!aludra.usc.edu!baffoni@arizona.e
 du (Juxtaposer)
Subject: assorted TT questions
To: Info-Atari16@naucse.cse.nau.edu
 
In article <meulenbr.675587949@cstw163> meulenbr@cst.prl.philips.nl (Frans
 Meulenbroeks) writes:
>Hi,
>
>I'm in the process of convincing myself to buy a TT, and I'm stuck with
>the following questions:
>
>As I'm told the TT does not have a 68882 on board, but does have
>a socket for such a beast. Right?
 
   No the 68882 is standard (however, it may be in a socket...?).
 
>What speed must this beast have, or can is the speed selectable?
>the 68881 and 68882 are supposed to be compatible. I owe a 68881.
>Can I use that one instead (assuming it is the right speed).
 
  The 68882, like the 68030, runs at 32 MHz.
 
>I'm a little puzzled by a previous posting about how memory is
>implemented. Are there two different daugtherboards??
>If I buy a 2 MB system is it then just a case to add sims if I want to
>upgrade to 4 MB? If not, I think I'll prefer to buy a 4 MB system.
>Is such a 4 MB system easily upgradable (e.g. by adding (or maybe
>replacing) simms). From a previous posting I concluded that there is
>a different daugther board if you go to 8MB. Is the ram on the
>second daughter board faster than on the first one??
 
  Ok.  The two basic memory types are ST and TT ram.  ST ram is located on
the mother board (I believe that there is 2MB soldered and 2MB socketed which
are empty if you get a 2MB TT or a 4MBTT with 2MB TTram) and doesn't need a
daughterboard.  TT ram does need a Daughter board (its more than just a bunch
of SIMM sockets - it also has a chip that allows access to the TT memory).
The TT daughterboard holds 4 SIMMS - up to 16MB max (using 4MB SIMMS).  Using
the card slot inside the machine, you can add a memory board for even more
memory.  However, in neither case is it simply a matter of slapping SIMMS into
your machine (unless you already have the TT daugterboard).
 
>
>What speed is the ram actually. Do I get wait states when accessing the
>memory? In any of the above cases??
 
   Since the machine runs at 32MHz, I assume that there are at least 1 wait
state on all memory, the TT ram having less than the ST ram.
 
>
>Then there is the monitor.  Is it possible to use an ST monitor if the
>screen is in an ST resolution??
 
   No.  Even though the TT displays ST resolutions, it does it on the same
signal that displays the TT's special resolutions.
 
>I think the price on a TT monitor is on the high side. However, I'm
>told that this is just a regular VGA monitor. Can I go out and buy a VGA
>monitor and use it?
 
Probably.  I can't see why not (except you may need to "customize" the cable
connector).
 
>I assume I need a monitor with 640x480 resolution and 60 or 70 hz
>refresh rate, and a D connector plug (forgotten the number of pins).
>Do I need a color monitor, or can I also use a monochrome monitor.
>Using a monochrome monitor would cut the price with $ 200 or $ 250, and
>I do not really need color.
 
  I forget - is  640x480 the max resolution of the TT's color screens?  If not,
you will need to get a monitor that reflects that limit.
 
>
>If someone could answer these questions that would be very appreciated.
>
>Thanks!
>--
>Frans Meulenbroeks        (meulenbr@prl.philips.nl)
>       Centre for Software Technology
 
 
   Hope that does it!
 
-Mike
 
------------------------------
 
Date: 31 May 91 20:48:30 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!apple!portal!cup.portal.com!Metalist@
 arizona.edu (Bryan Jones Woodworth)
Subject: Atari's position in the U.S. Market
To: Info-Atari16@naucse.cse.nau.edu
 
Atari's image in America has never been great, has it?  Now I hear that STart
is going bi-monthly?!  Ok.  But let me ask you out there:  Will the Atari
situation ever IMPROVE?  Or will it continue to decline?  (You can assume
this is a rhetorical question.)
 
 
Bryan_Jones_Woodworth@cup.portal.com
 
------------------------------
 
Date: 31 May 91 21:10:20 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!apple!portal!cup.portal.com!Metalist@
 arizona.edu (Bryan Jones Woodworth)
Subject: Atari 540ST Questions
To: Info-Atari16@naucse.cse.nau.edu
 
-- Salvador Pinto Abreu         spa@fct.unl.pt says:
 
>I wonder which Atari mouse you're talking about. All Atari mice I've
>used are the most dreadful rodents I've ever come across, second to
>none, not even the "original" VAXstation-100 mouse (ever seen one of
>these?) feels as bad.
>Finding a replacement mouse seems to me one of the first priorities of
>an Atari owner. I recently ordered a Naksha mouse, and await it
>eagerly.
 
I have to disagree.  You must have been supplied witha faulty mouse.  The
Atari mouse is lightweight and easy to use.  The mouse never moved too slow
for me.  Like you said, a mouse accelerator is easily obtained if the
mouse moves exceedingly slow for you.
I cannot understand what you don't like about the Atari mouse!  let me
say that I am by no means a mouse connoisseur, for I have only fondled two
mice:  Macintosh and Atari ST.  Macintosh, in my opinion, are heavy and
unresponsive.  I click, but I get no confirmation onscreen.  I despise the
recessed single button.
 
The Atari ST is easy to move, responsive, and suits my needs.  I have felt
no urge to get a replacement mouse.
 
 
Bryan_Jones_Woodworth@cup.portal.com
 
------------------------------
 
Date: 31 May 91 18:30:38 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.e
 du!pacific.mps.ohio-state.edu!linac!midway!clout!chinet!saj@arizona.edu
 (Stephen Jacobs)
Subject: Atari Mortis
To: Info-Atari16@naucse.cse.nau.edu
 
I hope Jeff won't object to my disclosing a specific issue he mentioned to me
in email; it will help people identify what might interest him.
 
One of his major applications is animated graphics, for which he is prepared to
write his own code.  To me, that sounds like a set-up in favor of the TT.  If
anyone has benchmarks or pointers to tools directly relating to animated
graphics, this might be a good time to mention them.
 
What I'll mention is that there's said to be an awesome TT demo (about an
hour's download time worth of it) recently put up on GEnie by Bob Brodie.  I
won't see it myself for a while, but perhaps someone has more to say about it?
 
                                 Steve       saj@chinet.chi.il.us
 
------------------------------
 
Date: 30 May 91 07:10:51 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!chaph.usc.edu!aludra.usc.edu!baffoni@arizona.e
 du (Juxtaposer)
Subject: Atari TT
To: Info-Atari16@naucse.cse.nau.edu
 
In article <17555@chaph.usc.edu> baffoni@aludra.usc.edu (Juxtaposer) writes:
 
>course SOME of it has to be reserved for I/O etc. but not more than 32k worth!)
                                                             ooops   ~~~
  That should be around 1MB - just to be generous with the ROMs :).
 
>-Mike
 
-Mike
 
------------------------------
 
Date: 31 May 91 18:43:17 GMT
From: news-server.csri.toronto.edu!torsqnt!lsuc!jimomura@uunet.uu.net (Jim
 Omura)
Subject: Gemini Standard Usages
To: Info-Atari16@naucse.cse.nau.edu
 
I've been working with Gemini off and on for a while now and
I hope somebody can pass these comments to the programming team.
It's all regarding the "mupfel.mup" file:
 
HOME is defined as the current "gemini" directory.  This is
a bad practice.  You should tell people to define "HOME" to
their current "working directory", whereever that is.
On a Unix system, my normal HOME directory would generally
be something like "/usr/mygroup/jimomura".  This is the directory
in which I do my usual work.  The thing to emphasize is that
it has *nothing* to do with the operating system or executables.
In fact, it's mainly just text data files of my own concern.
If you don't learn this concept early on your going to scr*w up
your system organization by writing programs that look to the
wrong places for the wrong things.
 
Also, I have no idea what they are intending to use the "CDPATH"
for.  I've never seen it on a Unix system or an OS-9 system and
I don't know what program would look for it.  Is that supposed to
be a path for CD Rom applications?
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura
 
------------------------------
 
Date: 31 May 91 23:47:05 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!caen!umich!terminato
 r!terminator.cc.umich.edu!weiner@arizona.edu (Jeff Weiner)
Subject: Lynx and sega
To: Info-Atari16@naucse.cse.nau.edu
 
Has anyone seen the commercial for sega's new portable game machine?
Color graphics that, at least on tv, look comperable to the lynx.
Could spell trouble for one of the better selling atari machines.
 
weiner
--
Jeff Weiner  --- weiner@{{sklyab,felix}.engin, atari.archive}.umich.edu
 
------------------------------
 
Date: 31 May 91 06:36:41 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!zaphod.mps.ohio-state.edu!cis.ohio-st
 ate.edu!dsac.dla.mil!dsacg3.dsac.dla.mil!desc.dla.mil!wright!desire.wright.edu!
 cse0507@arizona.edu
Subject: PageStream 2.1
To: Info-Atari16@naucse.cse.nau.edu
 
I talked to SoftLogik this week, and evidently PageStream 2.1 is done,
they're just waiting to get the manuals before they ship (the manuals were
just sent to the printer's this week).  I asked them if they had considered
sending the program out without the manual (for us bravos), and they said
they had just started considering it that day.  I then indicated :-) that
I would be one of those who is extremely brave, and would like to go mad
trying to figure out PageStream without the manual :-) :-) :-).  So, to
all those who have an interest in PageStream, would you call SoftLogik and
help me get my upgrade early?  Tell them Bob Schulze would like to have his
software now, and incidentally you'd like a copy too.  { HUGE :-) }
1-800-829-8608 is the U.S. toll-free number; I'm afraid I can't lay my
hands on numbers for any other country.  T'anks.
                               Bob The Schulze
 
------------------------------
 
Date: 31 May 91 14:41:27 GMT
From: news-server.csri.toronto.edu!torsqnt!lsuc!jimomura@uunet.uu.net (Jim
 Omura)
Subject: The Current Market
To: Info-Atari16@naucse.cse.nau.edu
 
    These are just some random observations about the current
market and definitely NOT a complete overview of what's happening
in the Toronto area:
 
     Long & McQuaide North is a music store -- NOT a computer store,
but they had a stack of 1040STEs and has sold them all.  Obviously
if a music store with no real computer people can sell 1040STEs
there's a market for STEs.
 
    Comspec, a computer store next door to L&M has discontinued
stocking Atari products completely.  That's not much of a loss to
the Atari community.  Comspec has always preferred Amigas and would
go to great lengths to sell Amigas at the expense of ST sales.
Still, I agree with a lot of the things Comspec has to say about
the current Atari Corp. and the Canadian situation.  I'm not at all
happy about the current trend in Atari to "pull out of Canada" and
leave us with a warehouse and repair department.  Though I plan to
do development on the ST for the immediate future, if things don't
turn around on this matter I'll probably move on to another platform.
 
    CompuPlace is strange.  I've always felt they were strange and
now their getting even stranger.  Not bad, mind you, but if you look
at the software they carry, I just don't know why they get in what
they do.  The best thing they have lately is a good supply of the
British magazines.  That and they have 2 of the better flight
simulators.  They have Proflight (British simulator of the Tornado
that's supposed to be really good) and the F-19 pseudo-simulator
(simulating a non- existant plane is, well, interesting).  They are
essentially out of stock of 1040STE's but will be getting more.
 
I have been hearing rumours that Atari has really been jerking
around the dealers with the recent price drops.  I hope this isn't
true.
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura
 
------------------------------
 
Date: 1 Jun 91 08:26:04 GMT
From: noao!asuvax!ukma!rex!samsung!umich!terminator!usenet@arizona.edu (Atari
 Archive Robot)
Subject: Weekly Posting of New Stuff
To: Info-Atari16@naucse.cse.nau.edu
 
  -rw-rw-rw- hyc        819302  May 25 17:38 ./gnustuff/tos/update8.zoo
  -rw-r--r-- weiner     803295  May 25 10:04 ./ste/only_ste.lzh
  -rw-r--r-- weiner     9750    May 27 10:26 ./utilities/Index
  drwxr-xr-x weiner     512     May 27 10:25 ./utilities/virus
  -rw-r--r-- weiner     65152   May 27 10:25 ./utilities/virus/vkiller.lzh
  drwxrwxr-x jon        1560    May 27 10:21 ./magazines/znet
  drwxrwxr-x weiner     512     May 27 10:19 ./ste
  drwxrwxr-x daemon     1024    May 28 22:48 .
  drwxrwxr-x jon        512     May 28 22:39 ./misc
  -rw-r--r-- weiner     4870    May 28 22:39 ./misc/2_5ram.zoo
  -rw-r--r-- weiner     962     May 28 22:40 ./misc/Index
  -rw-r--r-- weiner     9807    May 28 22:36 ./utilities/Index
  drwxr-xr-x weiner     512     May 28 22:35 ./utilities/doubclick
  -rw-r--r-- weiner     5376    May 28 22:35 ./utilities/doubclick/dcr_tmag.arc
  drwxrwxr-x weiner     512     May 28 06:49 ./tex/tex31
  drwxrwxr-x jon        536     May 28 22:29 ./gnustuff
  -rw-r--r-- weiner     91771   May 28 22:29 ./gnustuff/gnu881_s.zoo
  -rw-r--r-- weiner     34937   May 28 22:29 ./gnustuff/gnu881_x.zoo
  -rw-r--r-- weiner     261542  May 28 22:29 ./gnustuff/gnuplt_x.zoo
  -rw-r--r-- weiner     10856   May 28 22:32 ./gnustuff/Index
  -rw-rw-r-- weiner     2424    May 28 22:34 ./printing/Index
  -rw-r--r-- weiner     81389   May 28 22:45 ./Index
  -rw-r--r-- weiner     40865   May 28 22:45 ./CompInd.Z
  -rw-r--r-- weiner     63357   May 28 22:47 ./ls-lR.Z
  drwxrwxr-x daemon     1024    May 29 12:22 .
  drwxrwxr-x jon        6144    May 29 12:17 ./utilities
  -rw-r--r-- weiner     9933    May 29 12:21 ./utilities/Index
  drwxrwxr-x weiner     512     May 29 12:18 ./utilities/tosfixes
  -rw-r--r-- weiner     4096    May 29 12:18 ./utilities/tosfixes/serptch2.lzh
  drwxrwxr-x weiner     512     May 29 12:17 ./utilities/mouse
  -rw-r--r-- weiner     2071    May 29 12:17 ./utilities/mouse/rt_move2.lzh
  drwxr-xr-x weiner     512     May 29 12:21 ./utilities/filemenus
  -rw-r--r-- weiner     34541   May 29 12:20 ./utilities/filemenus/stwhiz11.lzh
  drwxrwxr-x jon        2048    May 29 12:15 ./telecomm
  -rw-r--r-- weiner     43090   May 29 12:15 ./telecomm/dterm_1k.lzh
  -rw-r--r-- weiner     2546    May 29 12:15 ./telecomm/Index
  drwxrwxr-x jon        1536    May 29 12:15 ./printing
  -rw-r--r-- weiner     37760   May 29 12:15 ./printing/pamflite.lzh
  -rw-rw-r-- weiner     2470    May 29 12:16 ./printing/Index
  -rw-r--r-- weiner     81561   May 29 12:22 ./Index
  -rw-r--r-- weiner     40961   May 29 12:22 ./CompInd.Z
  drwxrwxr-x daemon     1024    May 30 06:50 .
  drwxrwxr-x jon        4096    May 30 06:40 ./games
  -rw-r--r-- weiner     48896   May 30 06:40 ./games/col_drac.arc
  -rw-rw-r-- weiner     7798    May 30 06:41 ./games/Index
  -rw-r--r-- weiner     81618   May 30 06:41 ./Index
  -rw-r--r-- weiner     40995   May 30 06:41 ./CompInd.Z
  -rw-r--r-- weiner     63573   May 30 06:43 ./ls-lR.Z
  drwxrwxr-x daemon     1024    May 31 14:58 .
  drwxrwxr-x jon        1024    May 31 06:54 ./editors
  drwxrwxr-x jon        3072    May 31 14:42 ./graphics
  -rw-r--r-- weiner     63501   May 31 14:42 ./graphics/neochro2.lzh
  -rw-r--r-- weiner     5356    May 31 14:44 ./graphics/Index
  drwxrwxr-x jon        3072    May 31 14:57 ./diskutils
  -rw-rw-r-- weiner     5333    May 31 14:57 ./diskutils/Index
  -rw-r--r-- weiner     51432   May 31 14:56 ./diskutils/stree104.arc
  -rw-r--r-- weiner     81651   May 31 14:58 ./Index
  -rw-r--r-- weiner     40983   May 31 14:58 ./CompInd.Z
 
------------------------------
 
Date: 31 May 91 18:49:44 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!think.com!mintak
 a!bloom-beacon!eru!hagbard!sunic!kth.se!ugle.unit.no!erlingh@arizona.edu
 (Erling Henanger)
Subject: What's a fair comparison?
To: Info-Atari16@naucse.cse.nau.edu
 
--
       _______    _____          o           ____       Erling Henanger
      /___       /____/ /       /   /|  /   /           Norwegian Institute
     /          /\     /       /   / | /   |   ___      of Technology. (NTH)
    ------     /  \   /____   /   /  |/     \____| o    MS-dos should be dying!
 
------------------------------
 
Date: 31 May 91 14:41:40 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio
 -state.edu!linac!midway!clout!chinet!saj@arizona.edu (Stephen Jacobs)
Subject: What's a fair comparison?
To: Info-Atari16@naucse.cse.nau.edu
 
In article <1991May30.223629.13096@jato.jpl.nasa.gov> vsnyder@jato.Jpl.Nasa.Gov
 (Van Snyder) writes:
>In article <1991May30.145023.1684@chinet.chi.il.us> saj@chinet.chi.il.us
 (Stephen Jacobs) writes:
>>I seem to be involved in what is fast becoming a shouting match about relative
>>price and performance of Atari computers vs those based on Intel chips.  One
>>of the main problems is knowing what to compare with which.  So how about we
>>pick some fair yardsticks.  Atari isn't 'Joes Garage Computer Manufactorie',
>>fun with.  Cross-platform benchmarks are damn near impossible (Byte magazine
>>has had several articles on the subject), but I'll modestly propose as a
>>benchmark the time for GNU C to compile itself, with all temporary files on
>>hard disk.  Any other suggestions?
>>
>Some of the benchmarks people commonly use are Dhrystone (integer performance),
>Whetstone (Floating point performance), Linpack (Floating point performance),
>Livermore loops (Floating point performance), SpecMark (Overall system
>performance, but belongs to SPEC Inc).  The advantage of using these is that
>you don't have to re-do the benchmarks on the other machines, which you
>might not own.  I've seen dhrystone for the ST, maybe at atari.archive?
>
 
I know that linpack (which used to be considered the great 'real-world'
benchmark) is no longer considered a fair comparison of machines because it's
too architecture-sensitive (especially to cache and super-scalar aspects).
Whetstone never seems to have caught on for micros, perhaps someone knows
why and will say.  I guess Byte eventually picked a suite of benchmarks,
which they make available in source, but they hedged pretty heavily about
counting on them across architectures.  I'm assuming that the people who
participate in this discussion have some applications that exercise a processor
pretty thoroughly, and might be considered as successors to Linpack.
For what it's worth, I talked to a friend who rides herd on some big iron,
and he says that simply saying that beyond a certain machine speed my biggest
application (chromatographic data processing) is disk-bound sounds like a
benchmark to him.  I disagree, but I'll toss it into the discussion.
                                     Steve      saj@chinet.chi.il.us
 
------------------------------
 
Date: 31 May 91 10:39:55 GMT
From: mcsun!hp4nl!utrcu1!infnews!ramaer@uunet.uu.net (Mark Ramaer)
Subject: What happened to comp.sources.atari.st?
To: Info-Atari16@naucse.cse.nau.edu
 
A long long time ago in a place not far from here (within 10cm :-)
I offered to submit some example sources of a GEM program if people were
interested.  People were interested, so I sent it to
 atari-sources@unido.informatik.uni-dortmund.de but I have not seen
anything since then.
I can imagin that the moderator disliked it so much that he (she?) threw
it away, but I have not seen anything else in comp.sources.atari.st either.
Is it still alive?  Is it normal that it takes a long time?
Should I send it to twitterpater instead?
Have other sites received any sources?
 
#ifdef utwente.nl
Hier binnen de universiteit was er ook iemand ge\"{$\imath$}nteresseerd.
Als die me even mailt, wil ik het wel rechtstreeks sturen.
#endif
 
According to `ls -l` that long time ago is before 13 may.
 
Mark
 
------------------------------
 
End of Info-Atari16 Digest
******************************
