Article View: comp.sys.atari.st
Article #25953Returned mail: User unknown
From: MAILER-DAEMON
Date: Sun, 29 Mar 1987 03:06
Date: Sun, 29 Mar 1987 03:06
471 lines
20394 bytes
20394 bytes
----- Transcript of session follows -----
550 ALEN@WISDOM.BITNET... User unknown
----- Unsent message follows -----
Received: from finhutc.bitnet by wisdom.bitnet; Sun, 29 Mar 87 21:48:39 -0200
Received: by FINHUTC (Mailer X1.23b) id 2549; Sun, 29 Mar 87 08:35:55 FIN
Date: Sat 28 Mar 87 19:06:54 PST
Reply-To: Info-Atari16@Score.Stanford.edu
Sender: "Atari ST users forum (INFO-ATARI16)" <INFO-A16@FINHUTC>
Comments: To: "Distribution List: ;" <INFO-ATARI16>
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.edu>
Subject: Info-Atari16 Digest V87 #147
To: Alen Goldberg <ALEN@WISDOM.bitnet>
Info-Atari16 Digest Saturday, March 28, 1987 Volume 87 : Issue 147
This weeks Editor: Bill Westfield
Today's Topics:
Re: UW status report
Cambridge Lisp Performance
So. California Atari users group, midi...
Scientific WP, keyboard-handling, MS-DOS emulator
Notice
Re: Extension boards for the Mega-STs?
Re: DSDD Floppy disk drives
AUTODISK, FLEXCOPY and fast disk formats
Re: Floating Point Benchmarks
Fix for SpaceWar 3.1 posting
----------------------------------------------------------------------
Date: 23 Mar 87 23:12:47 GMT
From: mcvax!ukc!icdoc!mjd@seismo.css.gov (Martin J Davies)
Subject: Re: UW status report
To: info-atari16@score.stanford.edu
In the UK the University of Kent have a fully operational
UW. I dont know what staus it is (PD or otherwise) but
hopefully someone at ukc can comment !
I suppose you could try mailing to postmaster!ukc!mcvax....
I have used it and its very very nice
------------------------------
Date: Wed, 25 Mar 87 01:28:27 est
From: bill@ipsa.ARPA (Bill Pase)
To: info-atari16@su-score
Subject: Cambridge Lisp Performance
There was recently some questions about the performance of Cambridge Lisp
on the ST. It's interpreted code was said to be 20X slower than lisps
running on the MAC. To which someone else pointed out that compiled lisp
can be 10 to 100 times faster than interpreted. Anyhow I took the time to
run a couple of benchmarks on Campridge Lisp to see how much faster the
compiled code really is.
The following are a couple of the standard lisp benchmarks. All times shown
are in seconds. The GC time is the same for both compiled and interpreted code.
Interpreted Compiled GC Time
----------- -------- -------
TAK 726 4 0
DIV-ITER 2576 10 10
DIV-REC 1662 12 10
BOYER 10250 64 180
Anyhow, this seems to indicate that the compiler brings about a rather
dramatic seed increase. The times above show increases from 160 to 260
times! I suspect this would make it considerably faster than the lisps
available for other micros. Comparing these to the values shown in the
current issue of Byte for a 8MHZ 286 runing Gold Hill Common Lisp shows
Cambridge Lisp to be about 20% faster.
If we look at the value for BOYER in particular, as it is indicative of lisp
functionality, the numbers for some other lisps are: Gold Hill 77,
Sun 3 Common Lisp 52, Symbolics 10, VAX 750 PSL 43+41. All of these, except
the last, had sufficient memory to avoid garbage collection. All in all,
Cambridge Lisp is fast, its only real lost is that it is limited by the
current 1MB Atari machines. (Something which could well be changed very soon.)
/bill
------------------------------
Date: 25 Mar 87 05:38:57 GMT
From: rgoodman@csvax.caltech.edu (Ron Carl Goodman)
Subject: So. California Atari users group, midi...
To: info-atari16@score.stanford.edu
Sorry everyone has to read this. If you're not in the Southern California
area, you probably want to skip this.
I just discovered that (other than USENET) I am not alone in So. Cal. with
respect to my Atari ST. As it turns out there is a users group in So Cal
that has 4 meetings a month (1 general, 1 8bit, 1 16bit, 1 MIDI). If you are
interested, more info can be had by either calling the club at a computer
store called "Logical Choice For Computing" which by the way is an all
Atari store in North Hollywood at 818-760-0738 or by writing to me via email.
I hope to save some other soul out there who feels alone as I did until today.
Ron Goodman
--
rgoodman@cit-vax.caltech.edu _______ _________ _________ |
rgoodman@cit-vax.bitnet / \#/ \#/ | Pasadena
rgoodman@cit-vax.uucp |alifornia |nstitute |echnology | California
\_______ ___/#\___ of | | U. S. A.
------------------------------
Date: 22 Mar 87 04:57:02 GMT
From: regan@gvax.cs.cornell.edu (Ken Regan)
Subject: Scientific WP, keyboard-handling, MS-DOS emulator
To: info-atari16@score.stanford.edu
This message is prompted by recent postings on both scientific
word-processors for the ST series and on the way ST keyboard
information is handled. I use the T^3 ("T-cubed" or "T-three")
scientific text-processor on MS-DOS systems, and have
corresponded with its designers (TCI Software Research, 1190-B
Foster Road, Las Cruces, NM, 88001) for several years.
PLUG ON
T^3 is great; two major advantages are the ability to see
mathematics and alternate font styles on-screen as you type, and
to create new symbols for both printer and screen via an
uncomplicated font editor. Multiple-layer lines are treated as
single units, and any number of keystrokes may be saved as a macro.
I've written a 400-page doctoral dissertation and several papers on it.
Even for just ASCII text entry it has the best system
for getting around a document that I've seen. There are no 'modes';
one puts down a visual mark to insert text. To jump forward [backward]
to the next occurrence of a given character, be it a letter, space,
period, or carriage-return, simply hold the right [left] arrow key
down and type the character. This leads right into my main point,
so
PLUG OFF
Two years ago I contacted TCI about the not-yet-out ST and its
CGA-slaying mono graphics screen. The obstacle they mentioned wasn't
any difficulty in porting the code (p-system & IBM Pascal) or working
with GEM/TOS, but the keyboard: then (as now?) it would only store
two (2) key-presses simultaneously. The program uses three-key
combinations copiously (and some fours), so this was no-go.
I called Atari technical staff about this last December, since I'd
like to buy the 1040ST + planned MS-DOS box come June and my tax refund,
and their response was, in two words, "Good point!". Let me add
some tips on what one can do with "n-key rollover" and separate
recording of press and release (the latter I understand the ST's have):
(1) Making sensitive commands difficult to type by mistake:
T^3 uses /DEL/Shift/End (held down in that order) for "delete to end
of document". If you don't release the keys right away,
it will show you what it's about to do in inverse-video,
and if it's a mistake you can cancel the command by hitting <ESC>
(so a fourth key down) before releasing. Such conventions are
universal in the system, applying also to...
(2) Avoiding the display of pop-up menus:
Menus only pop up when the "Menu" key <F9> is released (GEM mouse programmers
take note), but are "there" when it is pressed. E.g. to mark the whole
paragraph the cursor is in and move it to the end of a document, one
can type the "chord sequence" /Left-Arrow/Shift/CR/, /F1/CR/,
/Shift/End/, /F9/+\/m\/+\. No menus appear, saving one screen-write
time, and the "mark from previous shift-CR (paragraph start) to next CR",
"jump to document-end", and "move block to cursor position" commands
are executed quickly and "silently". I won't explain the keys' meanings
(except the numeric-keypad <+> means "Accept")--the point is
that one gets all the virtues of both menu-based and command-based WP
systems combined. (Record the whole thing as a macro, calling it "pmove"
if you wish, and invoke it by typing /Ctrl/pmove to save more time later.)
(3) "Chording" has lots of other applications: music from QWERTY input,
combining key-commands with the mouse buttons in arcade-style games,
you name it.
So, aside from saying "Atari--please take note", let me ask some specific
questions:
I. Do currently-made ST's have the n-key feature (under TOS)?
II. If not, can the keyboard hardware be addressed in a fashion
that will still make programs portable within the ST line?
Will the Megas have the feature?
III. Will the planned 8088 box emulate the full IBM BIOS means of
handling the keyboard?
Neither I nor the TCI people have been able to try T^3 with Paradox's
MS.EM to see whether the key-combos work.
I, and also the T^3 people, will appreciate and consider all replies.
Mail me at 'regan@gvax.cs.cornell.edu' (Arpanet) or for Bitnet,
'regan%amvax.tn.cornell.edu@CRNLCS.BITNET' whatever you may
not wish to post. Thanks,
Dr. Kenneth W. Regan,
Center for Applied Math.,
211 Sage Hall, Cornell Univ.
Ithaca, NY 14853-6202.
------------------------------
Date: 24 Mar 87 19:00:36 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU (Neil Harris)
Subject: Notice
To: info-atari16@score.stanford.edu
It is with some regret that I inform the net that Alex Leavens is no longer
with Atari. We are actively looking for someone to take his place on the
net and otherwise. In the meantime, mail sent to Alex makes its way to my
mailbox.
--
--->Neil Harris, Director of Marketing Communications, Atari Corporation
UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil
BIX: neilharris / CIS: 70007,1135 / Delphi: NEILHARRIS / GENIE: NHARRIS
WELL: neil / Atari Corp. BBS 408-745-5308 / Usually the OFFICIAL Atari opinion
------------------------------
Date: 24 Mar 87 18:46:53 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU (Neil Harris)
Subject: Re: Extension boards for the Mega-STs?
To: info-atari16@score.stanford.edu
In article <8703231057.AA11904@ucbvax.Berkeley.EDU>, ZRFA1@DS0RUS51.BITNET
writes:
> In an interview with a german magazine Shiraz Shivij said
> that Atari has finished the development of a board with the
> 68881 on it. Does somebody (Neil) know when this board will
> be available, and which languages are going to support it.
From what I hear, the 68881 board was simply built to show what could be
done for the Mega ST using the expansion bus. If we plan to use it as a
product, it's news to me. Sounds like the sort of product that would be a
perfect opportunity for a third party vendor to sell.
--
--->Neil Harris, Director of Marketing Communications, Atari Corporation
UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil
BIX: neilharris / CIS: 70007,1135 / Delphi: NEILHARRIS / GENIE: NHARRIS
WELL: neil / Atari Corp. BBS 408-745-5308 / Usually the OFFICIAL Atari opinion
------------------------------
Date: 20 Mar 87 04:02:49 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: Re: DSDD Floppy disk drives
To: info-atari16@score.stanford.edu
[]
Apparently, the DSDD 3.5" drive is the upcoming standard (now starting to
take over the IBM-PC world).
Plea to Atari: Please discontinue the bundling of the 520ST with the
single-sided drive. That device is obsolete, and the existence of two
disk formats in the ST world is a pain. (Not to mention that all SW
that is to be distributed has to be broken up into those puny 360K pieces...)
Current owners of SS drives should be given a reasonably-priced upgrade path.
Waiting for an ST-microBernoulli connection (20Meg on a 5" removable disk)...
(and/or a SCSI jack in the back of the MegaST...)
- Moshe Braner
PS: If my most cynical guess is right (Atari happens to be stuck with a huge
inventory of SS drives...) then I hope this plea will be heeded some time in
the future.
------------------------------
Date: 23 Mar 87 22:37:22 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: AUTODISK, FLEXCOPY and fast disk formats
To: info-atari16@score.stanford.edu
[]
I didn't think AUTOCOPY and FLEXCOPY would work with floppy disks formatted
with the 'fast' format (the one with a bad tenth sector). But turns out
they do. The speed improvement is about two-fold for reading - great for
autoloading of a lot of stuff into RAMdisk on boot.
To copy a disk to a 'fast' disk with FLEXCOPY, you have to format the
destination disk with FORMATER.PRG _before_ you run FLEXCOPY. And BTW,
FLEXCOPY will let you back up such a disk relatively easily. (STCOPY won't.)
Note that FLEXCOPY and AUTOCOPY use the Rwabs() call
to read and write the disk, so any disk format that looks normal as far
as Rwabs() calls are concerned (i.e. has the normal _logical_ sectors)
should work with those programs. STCOPY reads whole tracks at a time, I
believe (for that awesome speed reading _standard_ disks), and therefore
has problems with 'fast' disks. Rwabs(), on the other hand, reads sector
by sector (roughly - anybody knows _exactly_ what it does?), even when
reading a _lot_ of consecutive sectors in one call. Half the speed
(on standard disks) but more flexible.
I do not have a copy of 'twister', so I don't know if that is also
compatible with AUTOCOPY and FLEXCOPY. If _you_ can, please try it out
and tell us all.
- Moshe Braner
Anybody knows the status of MINIX/ST?
------------------------------
Date: 21 Mar 87 04:55:34 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: Re: Floating Point Benchmarks
To: info-atari16@score.stanford.edu
[]
Thanks to Sandra Loosemore for posting the interesting benchmarks.
Here are results of the Savage benchmark for Megamax C on the Atari ST
(8 MHz 68000):
time error
Single precision: 146 4.3E+01
Double precision: 496 8.5E-07
Double precision, with 32081: 119 2.2E-08
The Megamax math library (written in C, using sloppy algorithms) is even
slower than the (in)SANE numeric package on the Apple Macintosh, as
exemplified by Aztec C (353 seconds). In comparision, Absoft FORTRAN
on the Amiga did it in 77 seconds (could someone post the Absoft time
on the ST?), Alcyon C v4.14 (libm) clocked in at 73 seconds, and HP BASIC
(also on an 8 MHz 68000) managed 45 seconds. (Any data for Mark Williams C?)
The 32081 case needs explanation: This is _still_ using the Megamax library,
but doing the +-*/ primitives on a 32081 FPU mounted as a peripheral and
running at 4 MHz. This speeded it up by a factor of 4. (Why the error is
smaller I don't know.) That is _not_ the best the 32081 can do. I have
tested, on my ST, an optimized log() function written in assembler language
for the 68000/32081 pair by Hal Hardenbergh of Digital Acoustics. It took
520 microseconds. Extrapolating from there, assuming the other functions
will be as fast, predicts that the Savage benchmark time would be 7 seconds,
or as fast as an IBM AT! Alas, Hal will not disclose his code for the other
functions, and I do not have the time right now to write my own, nor to
replace the 32081 with a 68881 (anybody done that?).
What can be done to improve the performance of your ST in number-crunching?
- Use Absoft FORTRAN
- Use the recent version of Atari/DRI/Alcyon C
- Pressure your favorite C compiler vendor to get it together
- Hack a 32081 onto your ST and
write your own (optimized in AL) math library
- Hack a 68881 onto your ST
- Get a MegaST and a 68881 card (Fall 1987?)
- Wait for the Atari TT (_Supposedly_ Winter 1988)
- Get the MSDOS add-on box for the ST (when?) and add an 8087
- Give up and get a Mac II or a "Turbo Amiga" (big $$$)
- Get an Atari PC (8 MHz 8086) and add an 8087
(Turbo C is here 8-) - Atari PC not yet...)
The 68881 is now about $140, similar in price to the 8087. (Finally!)
It has the transcendental functions built-in (the 32081 does not).
It is designed as a coprocessor for the 68020, although it _can_ be
connected to the 68000 as a peripheral (a lot slower). Is the 68881 card
for the MegaST (rumored) going to have a 68020 too? Is Atari _ever_ going
to build a machine suitable for number-crunching? Keep tuned for the
responses from Atari...
- Moshe Braner
Quiz: what computer comes standard with a mouse but no keyboard?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PS: here is the C code I used:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <math.h>
#include <osbind.h>
long sysclk;
gettime() {
sysclk = *((long *)0x4BA); /* System variable: 200 Hz counter */
}
main() {
int i, iloop;
double a;
long start, end;
Supexec(&gettime); start = sysclk;
a = 1.0; iloop = 2499;
for (i=0; i<iloop; i++)
a = tan(atan(exp(log(sqrt(a*a))))) + 1.0;
Supexec(&gettime); end = sysclk;
printf("\007time = %f\n", (double)(end-start)/200.0);
printf("error = %e\n", a-2500.0);
------------------------------
Date: 24 Mar 87 06:49:18 GMT
From: ubc-vision!alberta!sask!long@BEAVER.CS.WASHINGTON.EDU (Warren Long)
Subject: Fix for SpaceWar 3.1 posting
To: info-atari16@score.stanford.edu
Ah well, such is life. The very first posting in
comp.binaries.atari.st is glitched. Anyways, since I have the
original, I just ran a diff and ...
How to fix it up:
Take the uuencoded file and delete all lines in front
of the begin.
line 976 should begin with: M'++.+V this is correct
line 979 should begin with: M$Y #= this is correct
delete lines 977,978
insert the following lines after line 976:
M% O8.F-,$C4D?4,2.&@[O;#1]004P -V0Q#OO TG:\&#/,;@=T;V,U!W"X'
M'D '=J-@=WXWKYSPW':K8'<.=F,7^=!.X]TOOP/SVX3=&V_N-P 2*/Z$W1[S
M:W+D 9P^\N<!9&&W9?SZ9?K5 $R@^%G\UF&W'8@#D#7M@_);B-V&%.^ XH?8
M78K=IJC<-^\>*#XVO\?8C8SUIX.@>#)VBV/W..#SGH'BY-A]C]WXI)^P[[3G
the resultant file should have lines 976 to 981
looking just like this:
M'++.+V<\P!XDL1R(T#FW++'1@I"4"$F*,,URO@? O A)DY!$B=4BPWP*2;"0
M% O8.F-,$C4D?4,2.&@[O;#1]004P -V0Q#OO TG:\&#/,;@=T;V,U!W"X'
M'D '=J-@=WXWKYSPW':K8'<.=F,7^=!.X]TOOP/SVX3=&V_N-P 2*/Z$W1[S
M:W+D 9P^\N<!9&&W9?SZ9?K5 $R@^%G\UF&W'8@#D#7M@_);B-V&%.^ XH?8
M78K=IJC<-^\>*#XVO\?8C8SUIX.@>#)VBV/W..#SGH'BY-A]C]WXI)^P[[3G
M$Y #=S_?.37)TQ!X +XP/W^12\8%$]OGQ. 1>CE,'KUH'B4HY</[C>$^Q&A
I wanted to get this out in a hurry and haven't had time to test
it yet. (I mean download it to the ST). But, these changes do
result in a file that is identical with the one I originally sent
in.
Of course, nothing is complete without a bug report:
If null-gravity is selected the speed of the asteroids
seems a little random. It is not. It is set to the
speed of a stable orbit of the most recently player
game where the gravity was not zero. (is this a bug
or a feature?? :^)
Warren
--
=-=-=-=-=-Warren Long at University of Saskatchewan, Canada-=-=-=-=-
Home: 78 Carleton Dr.,Saskatoon, Sasakatchewan, S7H 3N6
Phone: (306)-955-1237
=-=-=-=-=-U-Email: ...!ihnp4!alberta!sask!long -=-=-=-=-=-=-=-=-
------------------------------
End of Info-Atari16 Digest
**************************
-------
Technical Details
Message-ID:
<8703300553.AA20157@ucbvax.Berkeley.EDU>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!WISDOM.BITNET!MAILER-DAEMONShow Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!WISDOM.BITNET!MAILER-DAEMON From: MAILER-DAEMON@WISDOM.BITNET.UUCP Newsgroups: comp.sys.atari.st Subject: Returned mail: User unknown Message-ID: <8703300553.AA20157@ucbvax.Berkeley.EDU> Date: Sat, 28-Mar-87 22:06:54 EST Article-I.D.: ucbvax.8703300553.AA20157 Posted: Sat Mar 28 22:06:54 1987 Date-Received: Tue, 31-Mar-87 01:14:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 471