Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: 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 ----- 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)" Comments: To: "Distribution List: ;" From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #147 To: Alen Goldberg 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 (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 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 #include #include 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*#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*#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$^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 ************************** -------