Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 92 Issue 072
Info-Atari16 Digest Fri, 7 Feb 92 Volume 92 : Issue 72
Today's Topics:
.SPS picture viewer?
All three rez on SM124!!!
A non-representitive benchmark...
Anti-flamewar proposal. (2 msgs)
Atari ST items for sale
Circuit drawing programs?
FOR SALE TOADFILE 44 REMOVEABLE HARDDRIVE!!
HVDI?
Notator printer support
PD Fortran compiler?
Postscript on Atari's in general
Problems when trying to exit MiNT
Re: Please Educate (soon to be) new Atari user
Slowing down my TT ... seriously
TT speed comparison..
WANTED: Protracker d'Esion XLI
who sells the Reflex card?
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: 6 Feb 92 22:10:38 GMT
From: agate!darkstar!cats.ucsc.edu!monsoon@ames.arpa (Len A. DeJesus)
Subject: .SPS picture viewer?
To: Info-Atari16@naucse.cse.nau.edu
In article <60323@aurs01.UUCP> you write:
>I've come across some Spectrum files that use the extention *.SPS...
>
>Does anyone know of a viewer that can display these?
There should be a file in the atari archive called "SPSLIDEX.PRG" that
should be used to view these files. Actually, this program will compress
spectrum .SPC or .SPU pics, hence the .SPS (smaller? scrunched?)
extension so that .SPS are usually smaller (about the size when you arc
.SPC files.) NOTE: you might come across some .SPS files which are
actually animation done in Spectrum 512 format with the program Unispec
so don't try any use the slide show on them.
--
Len A. DeJesus (monsoon@cats.ucsc.edu)
(tsunami@ucscb.ucsc.edu)
--
Len A. DeJesus (monsoon@cats.ucsc.edu) "Hey Mon"
(tsunami@ucscb.ucsc.edu) "Blame it on the Rain"
------------------------------
Date: 6 Feb 92 13:50:50 GMT
From: mcsun!sun4nl!fwi.uva.nl!gene!schaper@uunet.uu.net (Lancelot Schaper)
Subject: All three rez on SM124!!!
To: Info-Atari16@naucse.cse.nau.edu
I have a PD program with which it is possible to run MED and LOW rez.
on a SM124.
The only problem is that the screen is split in half.
Because LOW rez. uses 320 x 400.
I found this program on ftp terminator.umich.cc.edu
--
*****************************************************************************
Lancelot Schaper schaper@fwi.uva.nl
Faculteit Wiskunde en Informatica 020 - 683.17.78
Universiteit van Amsterdam Nederland
------------------------------
Date: 6 Feb 92 13:41:41 GMT
From: mcsun!uknet!bcc.ac.uk!ucacmsu@uunet.uu.net (Mr Stephen R Usher)
Subject: A non-representitive benchmark...
To: Info-Atari16@naucse.cse.nau.edu
I thought some of you might want to know how fast the TT was as compared
with other "workstations" using a real application.
This is the result of running Rayshade Version 3.0 (no Utah raster toolkit)
on a Sun SPARCstation IPX (16Mb RAM) and on an Atari TT030/8.
The Sun took approximatly 300 seconds to perform the raytrace of two
mirrored balls in front of two mirrors at 45 degrees with a textured floor.
The TT took approx 1700 seconds to render the same image.
On the Sun, rayshade was compiled using dynamic libraries, the standard Sun
C compiler with the -O switch.
On the TT rayshade was compiled with GCC 1.40 and mintlib16. The following
switches were used:-
-O -fstrength-reduce -finline-functions -fforce-mem -fforce-addr -m68020
-m68881 -D_M68881
The define -D_M68881 was used so that the inline assembly functions to use
the maths co-processor in the PML math.h header file were used.
The executable was set so that it would run in TT RAM and could also
Malloc() from it.
The code was run under MiNT 0.92.
As you can see, the TT performance was about 1/6th that of the Sun IPX
(SPARC 2 chip running at 40MHz(?)). As raytracing is VERY floating-point
intensive, this suggests that the TT's floating-point performance is about
0.5 Mflops (The IPX is rated at about 3 Mflops).
I don't know what this proves, if anything, but there you are!
Steve
--
Addresses:-
JANET:- ucacmsu@uk.ac.ucl or susher@uk.ac.csm
Internet:- ucacmsu@ucl.ac.uk or susher@csm.ac.uk
------------------------------
Date: 6 Feb 92 16:57:06 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu
!yale.edu!ira.uka.de!math.fu-berlin.de!fub!heaven7.in-berlin.de!cloud9.in-berli
n.de!martini@arizona.edu (Martin P. Ibert)
Subject: Anti-flamewar proposal.
To: Info-Atari16@naucse.cse.nau.edu
( ) In <1992Jan25.215455.14648@ux1.cso.uiuc.edu>, William Magro writes:
( ) > E) Non standard connectors. ACSI, monitor and drive ports, a male
rs232
( ) > port?!?!?! Come on! If you are going to introduce new
connectors, at
( ) > least give them advantages over the standard connectors.
You must be joking. Since the indroduction of IBM PCs, DTE-type serial
ports have always been male. Look on your modem (if you have one). Most
likely, it has a female DCE-type connector. Perfect fit, eh?
--
__ | Martin P. Ibert, Westendallee 100 d, D-1000 Berlin 19, Germany
( )__ | martini@cloud9.in-berlin.de, also martini@heaven7.in-berlin.de
( 9 )_ |---------------------------------------------------------------
(_________) | All that we see or seem/is but a dream within a dream. --E.A.P
------------------------------
Date: 7 Feb 92 11:24:38 GMT
From: mcsun!corton!laas!ralph@uunet.uu.net (Ralph P. Sobek)
Subject: Anti-flamewar proposal.
To: Info-Atari16@naucse.cse.nau.edu
>>>>> On 25 Jan 92 21:54:55 GMT, wmagro@roma.physics.uiuc.edu (William Magro)
said:
Bill> If you hate posts that respond to flamers, read on. This one is
Bill> different.
Thanx Bill!
Bill> "Why my Atari 1040STf Sucks," by Bill Magro
Bill> I) GEM/Desktop has a lot of problems
Bill> A) Mouse events are not registered quickly, so if I click on a button
Bill> and quickly move the mouse, the button doesn't see the click. Very
Bill> annoying, and it slows me down.
I have the *exact* same problem on my sparcstation at work running
X11R4 and OpenWindows 3. I can quite easily click and move too fast
for the X11 events and the machine does the wrong thing. Sometimes I
even get it to freeze up completely and have to reboot (or kill X11).
Seems just like when some interaction of GEM programs misbehaves,
isn't it.
Bill> B) I have to bring a window to the front before I can launch a
program
Bill> from it. In the mac's finder, if I double click on an icon in an
Bill> obscured window, the window comes forward and the program runs.
In
Bill> GEM the window just comes forward. Arghh! This slows me down.
A correction seems appropriate! Holding the right key while double
clicking *will* run the program in the other window with the current
top window serving as current directory. This has been true since TOS
1.0 but seems to be undocumented.
Bill> C) I can't arrange my desktop in any efficient way. Not being able
to
Bill> put programs on the desktop or to arrange them freely in a window
Bill> makes launching programs a nightmare. This slows me
Bill> down.
TOS 2.05 already solves this one!
Bill> II) Hardware bitches
Bill> B) Our graphics modes suck. 640x400 mono is great for work. But
everyone
Bill> else has at least 640x400 256 colors available now. The new TT
Bill> resolutions should be in _all_ of the machines by now. Come on
Atari!
How true!
Bill> D) The power supply/keyboard/mouse all suck. ... The mice
Bill> don't feel very nice and are prone to quickly
Bill> wearing out. (Again Mega/TT seem to deal with this.)
Do you prefer Mac or Sun mice more? The Suns have at least optical
ones but they are large and clumsy. Whatever happend to the
*beautiful* small optical Xerox mice that came with their lisp
machines? I've heard that they are even compatible with the, shh,
Atari ST.
Bill> E) Non standard connectors. ACSI, monitor and drive ports, a male
rs232
Bill> port?!?!?! Come on! If you are going to introduce new
connectors, at
Bill> least give them advantages over the standard connectors.
Come on now! Things are becoming more and more standardized but still
many ANSI terminals come with either male or female RS232 connectors.
Likewise for any machine that's more than 3 years old.
Bill> By the way, if you decide to followup on this article, please don't
include
Bill> the whole thing and respond line-by-line. Can you imagine anything more
Bill> agonizing than having to read this again in its entirety?
Hope I didn't cite too much to offend the net sensibilities.
--
Ralph P. Sobek Disclaimer: The above ruminations are my own.
ralph@laas.fr Addresses are ordered by importance.
ralph@laas.uucp, or ...!uunet!laas!ralph
If all else fails, try: sobek@eclair.Berkeley.EDU
Phone: (+33-)61-33-62-66 FAX-1: (+33-)61-33-64-55 FAX-2: (+33-)61-55-35-77
===============================================================================
Got a Mega 4 ST. Wish it was a Mega STe? :-| Do I *really* want a TT/Next? ;%#
------------------------------
Date: 6 Feb 92 16:56:10 GMT
From: sgi!silvlis!patf@ames.arpa (Pat Fitzgibbons)
Subject: Atari ST items for sale
To: Info-Atari16@naucse.cse.nau.edu
I am cleaning out my shelf of unused items.
I have the following items for sale.
Spectre GCR w/ Mac ROMS - $300
Word Perfect - $65
--
O O O Patrick Fitzgibbons /\ | These are my opinions.
\ / patf@silvlis.com /--\ Sunnyvale ) -- Any agreement with my
X /\/ \ CA | company is purely
/ \ in / \ \ coincidental.
------------------------------
Date: 6 Feb 92 19:36:12 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!convex!constellation!a.cs.ok
state.edu!cummins@arizona.edu (CUMMINS JOHN WILLI)
Subject: Circuit drawing programs?
To: Info-Atari16@naucse.cse.nau.edu
In article <n2asjtj@rpi.edu> dinsmm@aix02.ecs.rpi.edu (Michael John Dinsmore)
writes:
>
>I am looking for a program that can draw circuits. It doesn't
>have to be specifically designed just for electronic cicuits,
>but it should be easy to use and not labor intensive just to make
>the diagram.
> / |\/ |\
> / |/ || Michael Dinsmore
> / /| /| || dinsmm@rpi.edu
I've had EASYDRAW highly reccomended to me for this use. A set of
circuit elements is available (I hear) for cutting and pasting!
EASYDRAY is as the name implies "easy to use" but it's not
simplistic. It is a capable program.
I do not use it for this purpose as I've been too busy to get it and
set it up....
jc
------------------------------
Date: 6 Feb 92 22:09:36 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.
uiuc.edu!uxa.cso.uiuc.edu!mpl44572@arizona.edu (Ender)
Subject: FOR SALE TOADFILE 44 REMOVEABLE HARDDRIVE!!
To: Info-Atari16@naucse.cse.nau.edu
I have a 44 Meg Toadfile for sale. This has an ICD adapter, so you can
plug it in and go. Comes with all manuals, and a 44meg disk. This is a
syquest removable hard drive. $500 (shipping negotiable)
Mark
------------------------------
Date: 5 Feb 92 17:07:54 GMT
From: mcsun!unido!urmel!tornado!icemark!teppic@uunet.uu.net (B.E.Heinen)
Subject: HVDI?
To: Info-Atari16@naucse.cse.nau.edu
In <1992Feb4.145633.16665@usenet.ins.cwru.edu>, Jason Baker writes:
>
>What is HVDI? Is it just a screen accelarator like quick/turbo st? Why does
>it have its own font? And, most importantly, is it freeware?
NVDI (NewVDI) is a commercial screen accelerator like quick st, but in NVDI the
main part of accelerating is GEM (not TOS outputs like in QuickST). This
doesn't mean, that it is slow in TOS text...
NVDI is *REALLY* fast, especially if you have a blitter chip in your ST; NVDI
is the first program that fully uses the capabilities of the blitter chip!
It has an internal GDOS, too! I can quite recommend it...
Ask your local ST dealer for it, for any closer information.
yours
Benedikt
--
=============================================================================
Benedikt Eric Heinen, Matthiashofstr. 3, W5100 Aachen, Germany
Voice: +49-241-408592 icemark!sigrorn@tornado.gun.de
"When in doubt, print 'em out."
-- Karl's Programming Proverb 0x7
------------------------------
Date: 7 Feb 92 09:44:30 GMT
From: timbuk.cray.com!hemlock.cray.com!marc@uunet.uu.net (Marc Bouron)
Subject: Notator printer support
To: Info-Atari16@naucse.cse.nau.edu
Hi People,
I'm posting this for a friend `sans network access', so please email any replies
to me. Thanks. My buddy would like to know what the printer support is like
for C-labs Notator package. He's looking at Epson-compatible printers and has
also been somewhat taken by one of the Canon Baby-Jets. He would particularly
like to know of anyone's experience of printing scores in landscape format.
Many thanks in advance from Rob (and myself).
Cheers,
[M][a][r][c] ===== Cray Research (UK) Ltd. =====
INTERNET: marc@hemlock.cray.com
"If all the girls in Essex were laid JANET: M.Bouron@uk.co.cray
end-to-end, no-one would be in the UUCP: ...!uknet!crayuk!M.Bouron
slightest bit surprised..." VOICE: +44 344 485971 x2208
------------------------------
Date: 5 Feb 92 17:11:18 GMT
From: mcsun!unido!urmel!tornado!icemark!teppic@uunet.uu.net (B.E.Heinen)
Subject: PD Fortran compiler?
To: Info-Atari16@naucse.cse.nau.edu
In <1992Feb3.205550.52312@cc.usu.edu>, Hoyt J. Heaton writes:
>Does anyone out there know of a PD fortran compiler, or have a commercial
>version they'd be willing to part with?
Here in Germany you can get a program called BCFortran. This is an public
domain Fortran, but I don't know if it is quite good, since I don't work
in Fortran. If I'll find it somewhere on my PD-disk "collection", I'll
send it to atari.archive and tupac-amaru.informatik.rwth-aachen.de .
Benedikt
--
=============================================================================
Benedikt Eric Heinen, Matthiashofstr. 3, W5100 Aachen, Germany
Voice: +49-241-408592 icemark!sigrorn@tornado.gun.de
"When in doubt, print 'em out."
-- Karl's Programming Proverb 0x7
------------------------------
Date: 6 Feb 92 18:46:16 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!wupost!zazen!doug.cae.wisc.edu!umn.edu!
cs.umn.edu!thelake!steve@arizona.edu (Steve Yelvington)
Subject: Postscript on Atari's in general
To: Info-Atari16@naucse.cse.nau.edu
[In article <697322022.24866@minster.york.ac.uk>,
mjl-b@minster.york.ac.uk writes ... ]
> What I objected to was the "Calamus is so great I don't see why
> you should even consider using anything else" argument. I stated why we
> might want to have Postscript output.
I think anyone who advances the argument that Calamus is the be-all,
end-all of page layout software is ignoring the fact that users' needs
come in many shapes and sizes. There is no one perfect tool, and there
never will be.
> If the Calamus Page Description Language becomes as popular as Postscript,
> I'll be happy -- by all accounts it's a better PDL. But although Calamus
could
> output _both_ Calamus PDL and Postscript, you _still_ have to buy some other
> program to do the conversion.
Point of clarification: PostScript should not be regarded as a page
description language. It's a programming language designed for building
graphic images. There's a very big difference. You can't create a page
with PageFoo software, write out a .PS file, then edit that page with
PageBar on a different platform. You can use the .PS file to build a
bitmap on a system (usually a smart laser printer) that has a PostScript
interpreter, but that's about it.
Calamus doesn't output a programming language. It outputs a bitmap in a
format appropriate to the imaging device that is being driven. This allows
it to skip several layers of interpretation, resulting in faster
throughput. It also allows Calamus to have very precise control over the
output image, something that is not possible with PostScript.
> I'm not saying that we should stop using the Calamus way of things, just that
> the great thing about standards is that they are just that : _standard_.
As Henry Spencer says, the great thing about standards is that there are
so many of them.
> This is not to say that we should never innovate (I hope to god someone
> innovates us out of the IBM-PC standard soon).
That was accomplished years ago.
> When you could support a very
> popular standard at little extra cost,
Whoa! Who says it would entail ``little'' extra cost? Have you priced
Calamus recently? Those modules don't write themselves.
Of course it would be possible for the authors of Calamus to create a
module that could write PostScript code based on Calamus' document file
format or internal data structures. That doesn't mean it would be simple,
easy, or cheap, or that the performance would be acceptable to the market
at which Calamus is aimed.
> but refuse to do it because you
> consider it beneath you, that's arrogance. What other serious DTP program
> takes this stance?
I know of no instance in which Ditek has said it considered PostScript
support ``beneath'' it.
At any rate, businesses make decisions on the basis of projections of
short-term and long-term profitability, not on emotional grounds or
``arrogance.'' If it becomes clear that there's profit in PostScript
support, even at the expense of siphoning off scarce resources from other
projects, then no doubt you'll see PostScript support.
I don't think it's all that clear. There are some serious competitors to
Calamus on the way from other developers who are taking a similar approach
-- i.e., focusing on high-performance page output by rasterizing the image
directly and avoiding PostScript entirely.
If I ran the company, I'd be very careful not to get blindsided in my
upscale core market while working on a product that would be of interest
primarily to people who can't afford a printer.
One other comment: The performance issue may be small to you, but to
others it is very, very important.
The company I work for -- a major daily newspaper -- must typeset
thousands of 18-by-22-inch pages per week. Most of those pages are dumped
to the typesetter in a very small time window, close to the press
deadline.
PostScript simply cannot handle the job quickly enough, so we continue to
use Autologic APS-5 typesetters whose design is a couple of decades old.
We can RIP, record and process (photochemical, resin-coated paper) a
broadsheet newspaper page at about 2000dpi resolution in a few minutes.
Even the fastest new RISC-based PostScript RIPs can't approach that sort
of performance.
We're stuck with PostScript on the Macintosh systems used by our
infographics specialists. Whenever we must output an infographic on
deadline, there's a great round of nail-biting, and often we miss the
start of the press run with the color separations. For businesses with our
sort of time constraints, the internal-RIP model used by Calamus makes a
lot of sense. For the casual user who doesn't own a printer, it's probably
not the best solution. Pick another tool.
But don't expect it to be perfect. As Voltaire observed, we live not in
the most perfect world, but rather the most probable world.
---
Steve Yelvington, Marine on St. Croix, Minnesota USA
steve@thelake.mn.org umn-cs!thelake!steve
------------------------------
Date: 7 Feb 92 10:01:57 GMT
From: mcsun!unido!news.uni-bielefeld.de!uchef153@uunet.uu.net, Menke
Subject: Problems when trying to exit MiNT
To: Info-Atari16@naucse.cse.nau.edu
I have got a problem when I try to leave MiNT.
If there is a program running in the background (like lpd), when one
trys to leave MiNT the system prints this message:
pid 0 (MiNT): assert(`f->links == 0') failed at line 590 of filesys.c.
Fatal MiNT error: adjust dedug level and hit a key ...
Hitting a key leads to:
System halted Press 'x' to exit, or else reboot
After pressing x the first messages once again will be printed.
Pressing any other key or combination of other keys causes the 2nd
message (System ...).
Raising the debug level seems to be no help because there is only difference
between the regular leaving of mint and the crash:
Crash:
pid 1 (sh): Fcntl(-1,cmd=0x5407)
pid 1 (sh): Fcntl: calling ioctl
pid 1 (sh): Pterm(0)
pid 0 (MiNT): leaving Pexec with child return code
pid 2 (lpd): disposing of closed fifo <---- difference for the crash
exit code: 0
pid 0 (MiNT): assert(`f->links == 0') failed at line 590 of filesys.c.
Fatal MiNT error: adjust dedug level and hit a key ...
Reagular leaving:
pid 1 (sh): Fcntl(-1,cmd=0x5407)
pid 1 (sh): Fcntl: calling ioctl
pid 1 (sh): Pterm(0)
pid 0 (MiNT): leaving Pexec with child return code
exit code: 0
leaving MiNT
Is there a posibility to solve this problem ?
Not 'rm u:\proc\*' or manual killing of background jobs.
The system I am working on is an ATARI MEGA/STE 4MB.
Unfortunatelly I do not know the TOS version I have,
because up to know everything works fine.
I have not mounted any other filesystem.
Carsten Menke
carsten@chec02.uni-bielefeld.de
or uchef153@unibi.hrz.uni-bielefeld.de
------------------------------
Date: 7 Feb 92 11:29:30 GMT
From:
noao!asuvax!ukma!wupost!think.com!yale.edu!ira.uka.de!fauern!LRZnews!NewsServ!s
eibert@arizona.edu (Ewald Seibert)
Subject: Re: Please Educate (soon to be) new Atari user
To: Info-Atari16@naucse.cse.nau.edu
In article <1992Feb07.070946.45861@yuma.acns.colostate.edu>,
sytang@lamar.ColoState.EDU (Shoou-yu tang) writes:
|> In article <1992Feb06.232348.6350@cdsmn.mn.org> plate@cdsmn.UUCP (Doug Plate)
writes:
|> ...
|>
|> f : means internal floppy drive in the CPU box.
|> m : modulator installed (i.e. can hook up to the TV etc.)
|> STe and Mega STe are newer ST and Mega with enhancement in it also use SIMMs
|> instead of DIPs on older machine.
|> TT is 030 machine with different design for more expansion.
|> STs has no expansion slot, Mega has one Mega bus for expansion, Mega STe has
|> more and TT has VME bus.
I think you confused something:
Both, MegaSTE and TT have ONE normal length 16-bit VME
|> The STs requires hardware hacks to add-in (piggy back, remove etc.) or use
|> DMA (hard drive, supercharger) or cartridge port (Spectre).
|> STe is about the same except the memory upgrade is easier (change the
SIMMs).
|> Other probably can provide more information on top this and correct any
|> mistake presented.
Furtheron, the MegaSTE has a 16MHz 68000-CPU with 16kB cache a LAN port.
==============================================================================
seibert@hphalle9.informatik.tu-muenchen.de ist
Ewald Seibert, Rheinbergerstr.1 8070 Ingolstadt, 0841-86480
Dont't blame ATARI for things, the GURU told you from the ARABIAN NIGHTS (*
==============================================================================
(* = Maerchen aus 1001 Nacht
------------------------------
Date: 6 Feb 92 11:29:18 GMT
From: mcsun!uknet!yorkohm!minster!mjl-b@uunet.uu.net
Subject: Slowing down my TT ... seriously
To: Info-Atari16@naucse.cse.nau.edu
In article <w6ZNFB3w164w@ersys.edmonton.ab.ca> mforget@ersys.edmonton.ab.ca
(Michel Forget) writes:
>sms@sys.uea.ac.uk (S.M.Sowerby) writes:
>
>> This may seem a little silly but I want to make my TT run at ST
>> speeds. Not all the time of course, only when running certain
>
>> Steve Sowerby, Postgraduate layabout, (sms@sys.uea.ac.uk)
>
>Well, you could try writing an accessory that tells GEM to wait for 10
>ticks, then return. Then do some useless thing like increment some
>variables a few thousand times, and tell GEM to wait again. This will
>SLOW DOWN the machine like you wouldn't believe. Of course, there are a
>few problems. Mainly, it won't work in TOS programs and it will take up
>an accessory slot.
> [etc.]
><< mforget@ersys.edmonton.ab.ca >>
><< ersys!mforget@nro.cs.athabascau.ca >>
><< Michel Forget >>
You could also hook a routine into the VBL queue which wastes time. This
will work with all programs, assuming that you can install it before you run
the target program (may not be easy for games).
Mat
| Mathew Lodge | "What do they call you, boy?" "Kate." "Isn't |
| mjl-b@minster.york.ac.uk | that a bit of a girl's name?" "... it's |
| Summer: lodge%alsys@uknet | short for 'Bob'" -- Blackadder II |
------------------------------
Date: 6 Feb 92 16:36:02 GMT
From: mcsun!uknet!bcc.ac.uk!ucacmsu@uunet.uu.net (Mr Stephen R Usher)
Subject: TT speed comparison..
To: Info-Atari16@naucse.cse.nau.edu
I thought some of you might want to know how fast the TT was as compared
with other "workstations" using a real application.
This is the result of running Rayshade Version 3.0 (no Utah raster toolkit)
on a Sun SPARCstation IPX (16Mb RAM) and on an Atari TT030/8.
The Sun took approximatly 300 seconds to perform the raytrace of two
mirrored balls in front of two mirrors at 45 degrees with a textured floor.
The TT took approx 1700 seconds to render the same image.
On the Sun, rayshade was compiled using dynamic libraries, the standard Sun
C compiler with the -O switch.
On the TT rayshade was compiled with GCC 1.40 and mintlib16. The following
switches were used:-
-O -fstrength-reduce -finline-functions -fforce-mem -fforce-addr -m68020
-m68881 -D_M68881
The define -D_M68881 was used so that the inline assembly functions to use
the maths co-processor in the PML math.h header file were used.
The executable was set so that it would run in TT RAM and could also
Malloc() from it.
The code was run under MiNT 0.92.
As you can see, the TT performance was about 1/6th that of the Sun IPX
(SPARC 2 chip running at 40MHz(?)). As raytracing is VERY floating-point
intensive, this suggests that the TT's floating-point performance is about
0.5 Mflops (The IPX is rated at about 3 Mflops).
I don't know what this proves, if anything, but there you are!
Steve
--
Addresses:-
JANET:- ucacmsu@uk.ac.ucl or susher@uk.ac.csm
Internet:- ucacmsu@ucl.ac.uk or susher@csm.ac.uk
------------------------------
Date: 6 Feb 92 13:26:19 GMT
From: aahs.no!karloey@ucbvax.berkeley.edu (Karl Anders Oygard)
Subject: WANTED: Protracker d'Esion XLI
To: Info-Atari16@naucse.cse.nau.edu
>The following appeared on ST MAGAZINE No 57, JANVIER 92:
>
>" Le Protracker est un soundtracker tres complet pour un freeware..."
This is _not_ correct. I've spent far too much time on ProTracker
to release it as freeware. The copy of ProTracker that's floating
about was stolen, and should never have gotten out.
>Has anybody seen this protracker ? The screen shots look really nice
>and can load PACKed files (save disk space). Is it available on any site?
There is (should be) a demo copy of ProTracker ST v1.3 on a-a. Take a
look at it - v1.3 is a lot better than the illegal copy (v1.2) that's
gotten out. ProTracker itself is going to be released commercially
under Daatasoft pretty soon.
/Email: Karl A Oygard <karloey@aahs.no> ================================
/Karl Anders Oygard - regd. developer for Atari =======================
------------------------------
Date: Fri, 7 Feb 1992 08:35 EST
From: CSULLOGG@crl.aecl.ca
Subject: who sells the Reflex card?
To: Info-Atari16@naucse.cse.nau.edu
Who sells the Reflex graphics card in North America? Is there a MegaSTE/TT
version (i.e. VME)? Thanks in advance!
------------------------------
End of Info-Atari16 Digest
******************************
