Info-Atari16 Digest Mon, 4 Nov 91 Volume 91 : Issue 571 Today's Topics: 8mhz ST = 16mhz 386 (4 msgs) desperatly looking for a GOOD UUCP p HD backup Indus GTS-100 floppy drive PD or shareware Fortran Compiler out there SIMPLE NETWORK!? TT sound broken! Wants (What's!) happening? Where is Happy Computer /Discovery ? 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: 4 Nov 91 01:57:07 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: 8mhz ST = 16mhz 386 To: Info-Atari16@naucse.cse.nau.edu In article <1991Nov3.204636.3057@murdoch.acc.Virginia.EDU> lch3e@holmes.acc.Virginia.EDU (Lauren C. Howard) writes: >An article in the October Current Notes magazine reviews up-to-date >benchmarks comparing the ST and TT vs. 286/386sx/386/486 is this online somewhere? >Our little ol' 8mhz ST's come out equal to or slightly better than >the 386sx in ALL benchmarks, including running identical programs. > >The 386 is only slightly better (20mhz), and conjecture is that the >Mega STE would blow any 386 away. > >The TT was mucho better than the 486, though unclear by how much. can u be a wee bit more specific? when u say "identical programs", are these source code (that u compiled) or common applications? if the former, are you sure u are not really benchmarking compilers? on the ST itself, any 2 different compilers may differ by 2x or more in dhrystones, for example. i measured dhrystones (2.0 or 2.1) with alcyon at about 800 and gcc, turbo C, etc all do over 2000, i think. has nothing to do with the hardware, only compiler. i find it REAL hard to believe an 8Mhz system outperforms a 16 Mhz system, and is close to a 20 Mhz system, especially with this very simple architecture which pc's (generic) represent. also, is there _detailed_ configuration info on these benchmarks, eg disk, memory size, compiler, etc? are we really comparing the same thing, either by power or price, or is this an ultra-biased attempt to make the ST look good (for some unknown reason)? and do these benchmarks represent some real workload or are they things the ST may do particularly well at? a comprehesive test would include display (text and graphics), calculation (integer and floating point), i/o, telecom, etc. it would also be fair to have a 386/486 "expert" do their tests and an atari "expert" do ours. such an expert would choose the proper configuration, compilers, etc. i could see the TT doing well against a 486, however, given comparable clock (and disk) speeds. since i don't have access to a TT (or a 486) this is pure conjecture on my part. >Chew on that awhile. munch, munch, munch...all done. give me (us) more :-)... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 4 Nov 91 03:35:00 GMT From: noao!ncar!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!spool.mu.edu !munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick@arizona.edu (Warwick Allison) Subject: 8mhz ST = 16mhz 386 To: Info-Atari16@naucse.cse.nau.edu In <1991Nov04.015707.11599@convex.com> rosenkra@convex.com (William Rosenkranz) writes: >In article <1991Nov3.204636.3057@murdoch.acc.Virginia.EDU> lch3e@holmes.acc.Virginia.EDU (Lauren C. Howard) writes: >>Our little ol' 8mhz ST's come out equal to or slightly better than >>the 386sx in ALL benchmarks, including running identical programs. >> >>The 386 is only slightly better (20mhz), and conjecture is that the >>Mega STE would blow any 386 away. >can u be a wee bit more specific? when u say "identical programs", are >these source code (that u compiled) or common applications? if the former, >are you sure u are not really benchmarking compilers? on the ST itself, >any 2 different compilers may differ by 2x or more in dhrystones, for >example. i measured dhrystones (2.0 or 2.1) with alcyon at about 800 and >gcc, turbo C, etc all do over 2000, i think. has nothing to do with the >hardware, only compiler. i find it REAL hard to believe an 8Mhz system >outperforms a 16 Mhz system, and is close to a 20 Mhz system, especially >with this very simple architecture which pc's (generic) represent. The Intel architecture is NOT a simple architecture. That's what makes it so slow. Where a 680x0 has one continuous expanse of memory, the 386 system would be using 64K chunks, adding base registers and all that stuff. (The 386 is CAPABLE of running with continuous memory, but the OS generally isn't). These figures do not suprise me at all. 16MHz 386 is probably around the power of a 8MHz 68000. Although I agree, the methods for finding the results are very inexplicit. Warwick. Did you know that the screen memory on a 386 runs about 1/5 the speed of normal memory? And I thought the TT was slow with video memory!!!! -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA. ------------------------------ Date: 4 Nov 91 08:52:34 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: 8mhz ST = 16mhz 386 To: Info-Atari16@naucse.cse.nau.edu In article <4924@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes: >The Intel architecture is NOT a simple architecture. That's what makes it >so slow. Where a 680x0 has one continuous expanse of memory, the 386 >system would be using 64K chunks, adding base registers and all that stuff. >(The 386 is CAPABLE of running with continuous memory, but the OS generally >isn't). These figures do not suprise me at all. 16MHz 386 is probably >around the power of a 8MHz 68000. nobody hates segmented memory more than me. well, there may be someone :-). just look what it did to minix/PC :-(. long ago i made a conscious decision to avoid intel 80x86 chips just because of the horrid memory architecture. (my favorite quip re: the '86 is "segments are for worms". i wish i had said that :-). well, we could argue about what "simple" means. to me unitasking uniCPU non-vector/parallel unibank/non-interleaved non-cached CISC systems are "simple". this pretty much sums up the ST (and many 386 implementations). i have not used a 386 in quite a while so i don't claim to be expert in what it can do. in fact, i don't even think i have much technical info on the 386 on my shelves. i do know of some 386 _implementations_ which are used in very demanding applications (like embedded system data processors). as much as i hate the 386, i would think a good 16Mhz implementation will beat a good 8Mhz 68000 implementation handily. now we can argue about what "good" means (and what good costs). and the 486 does have an on-chip instruction/data cache and FPU. also many instructions execute in 1 clock (the 68000 takes 8 clocks to do a register/register longword add), tho i think memory bandwidth is usually the critical issue. on a somewhat related note, since the ST has multiple memory banks, are they interleaved? will stride 1 memory access on the ST run faster than (say) stride n where n is the number of banks (4 as i recall)? i was under the impression that each bank holds a contiguous address range. if it _is_ interleaved, is it byte-wise or word-wise interleaved? and what is a "word" in this context? or is the bank cycle time included in the move cycle count? consulting my 68000 move table, for example, a "move.l d0,(a0)" takes 16 cycles. it seems to be independent of memory architecture. is this similar to the 386? does zero wait state make sense on a 68000? is the ST memory bandwidth limited? > Although I agree, the methods for >finding the results are very inexplicit. exactly. we need more info than "8Mhz = 16Mhz" or "TT >= 486"... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 4 Nov 91 10:37:27 GMT From: mcsun!hp4nl!alchemy!piet@uunet.uu.net (Piet van Oostrum) Subject: 8mhz ST = 16mhz 386 To: Info-Atari16@naucse.cse.nau.edu >>>>> rosenkra@convex.com (William Rosenkranz) (BR) writes: BR> hardware, only compiler. i find it REAL hard to believe an 8Mhz system BR> outperforms a 16 Mhz system, and is close to a 20 Mhz system, especially BR> with this very simple architecture which pc's (generic) represent. The MHz don't mean anything if you compare different CPU architectures. It is just the frequency of the clock. It is a well known fact that a 8 MHz 68000 is roughly equivalent to a 16MHz 80*86. The 68000 just does about twice as much in one clock pulse than the 80*86. It also uses less overhead because of the more regular instruction set, addressing modes and the better register structure. With the "improvement" in architecture on the [34]86 machines this is expected to become less significant, but then the 680[34]0 also improve. -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------ Date: 3 Nov 91 19:36:44 GMT From: noao!ncar!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!spool.mu.edu !cs.umn.edu!msi.umn.edu!math.fu-berlin.de!unido!mcshh!malihh!pfunk.hanse.de!bla ckbox@arizona.edu (Michael Kistenmacher) Subject: desperatly looking for a GOOD UUCP p To: Info-Atari16@naucse.cse.nau.edu In <1991Oct31.094337.14377@frmug.fr.mugnet.org>, Mathias Herberts writes: > >Well there I am again , looking for a UUCP package ... >does anybody have a UUCP package in which both uucp and uucico allow the user >to retrieve files from a remote system ?? HERMES does this very well. You can use the 'uucp' command to write a workfile-line for the uucico, which is already able to send the request- command to the other side of the line. I use this weekly to get some index- files from my host. >Few days ago someone talked about a Hermes package , could some one give me >his address so I can send him a disk ? I already sent the package to someone in the U.S. to publish them on c.b.a.s. You hopefully won't need to send the disk. Perhaps you might send the shareware fee to the author (No, it isn't me and I haven't seen him ever :-)). >I'm kinda frustrated , I have the GNU-UUCP sources but cannot compile them ! >I'll send them in when sending the disk for Hermes You should not try to compile the gnuucp sources, because they are even badder than our GFA-cico. The gnuuio doesn't support windowed transactions, so you would get very slow connections. Our 'cico' doesn't run under mint or other environments, but all other things are done perfectly. Bye.....Michael -- /------------------------------------\ | Michael Kistenmacher / blackbox | | 2000 Hamburg 61 / Schippelsweg 64 | | West Germany / ++ 49 40 552 37 66 | \------------------------------------/ ------------------------------ Date: Mon, 4 Nov 91 13:54 MET From: "Chris Evelo: MFAGKCHR@HMARL5 (BITNET)" Subject: HD backup To: Info-Atari16@naucse.cse.nau.edu Todd Drga asks: >Are there any backup programs out there that can backup a HD directly to >a Syqest 44 meg cart? I have an 89 meg HD that I'd like to back up with >my Syuest drive. I have an ICD Advantage + Host adapter, if that makes >a difference. May be my partback program would be of use to you. Below is the readme file. Note that partback does not use any tricks like Cheetah and the like. But this might also be an advantage. ---------------------------------------------------------------------- PartBack v0.05 Partback is available from: Chris Evelo Op de Vey 54 NL-6165 CD Geleen The Netherlands Send $ 20,- or equivalent and you will receive the program on disk. PartBack is a backup program. It makes full backups from one partition on to another. This is especially useful if you can make the backup from a fixed disk to a removable unit, like a Syquest unit. Backups can be made directly from one root directory to another, or from one partition to a folder on the other. In both cases the full directory structure of the source partition is copied. If the backup is directed to a folder, the folder will have the name of the source partition. If the target folder does not exist it will be created. You can choose to backup more than one partition to the same target partition. In this case it is highly advisable to select "To Directory". You can select that only newer files are copied. PartBack will use the GEMDOS creation date and time to check what file is newer. With TOS 1.4 or higher you can also choose to use the archive bit. If you select "Use Bit" PartBack will check whether a file was backuped before. If you select "Set Bit" PartBack will tell GEMDOS when a file was backuped. This way the file will not be copied again during a subsequent run with "Use Bit" selected. PartBack uses standard GEMDOS calls to find files and directories. This means that it is very likely that you will run in to the so called 40 folder bug, when you use TOS versions older than 1.4 without additional tools to enlarge the buffer for directories. If you use FOLDERxxx it is advisable to use a rather high value for xxx. Two times the amount of folders to be copied should be the minimum. After initiation PartBack searches the default path for a file called partback.inf. This file can contain files, folders and filetypes that partback should not copy. A sample configuration file is shown below. The first line "#partback" is obligatory. Possible entries are #skipdir, #skipfile and #skiptype. They may be given in any order. If you use skipdir the whole path below a directory with the given name will not be copied. #partback #skipdir=clipbrd #skipdir=trashdir #skipfile=rubbish.txt #skiptype=bak #skiptype=log Limitations: currently the maximum number of directories per partition is 400. The maximum number of skipdirs is 20 and the maximum number of skipfiles and skiptypes is 100. This limitation will be removed in a future version (as soon as I or some registered user need it). There is no limit to the amount of files to be copied. Error handling is minimal. PartBack will notice write protected target files, and will notice a full target disk. That is about all there is. Other errors will be taken care of when they are encountered. ------------------------------------------------------------------------------ Bug reports and comments to: Chris Evelo. MFAGKCHR@HMARL5.BITNET PartBack was developed with GFA-Basic 3.50E D. Disclaimer. PartBack was tested in normal daily use. Errors may however occur. I will not be responsible for any losses that may result from the use of the program. ------------------------------ Date: 4 Nov 91 02:34:16 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rphroy!caen!u florida!mailer.cc.fsu.edu!boyd@arizona.edu (Mickey Boyd) Subject: Indus GTS-100 floppy drive To: Info-Atari16@naucse.cse.nau.edu Howdy, I have a been offered a GTS-100 for a song. However, it (like its brethren) does not seem to work quite right. When I connect it to my Mega2, it not only refuses to format in twisted mode, it also somehow prevents my internal from doing it! My questions are: What exactly is wrong with this drive (ie what does it do wrong). Is there any way I can disable or fix the "wrongness"? I remember this thread from years past, but time has clouded my memory. I want the drive to work with my system (obviously), be able to format out to at least 82 tracks 10 sector/track, and be able to twist format. I assume there is something non-standard with the Indus board in the drive, and not the drive mech itself. Could it be an internal cabling problem? I would not hesitate to rip it apart and fix it if I knew what needed tweeking, nor would I care too much if the little digital track display was lost in the process. The drive mech inside is a Shugart SA310-16. Can anyone tell me if this one will work ok with the ST (ie no media change problem)? Related to this, is there any document which outlines the method of hooking a generic 3.5" drive to the ST? I seem to remember that this only requires a special cable. Could I hack the drive cable and connect it directly to the mechanism, thus ignoring any Indus specific hardware? Any information would be appreciated. Please email, and I will post a summary if there is interest. -- Mickey R. Boyd | "God is a comedian playing to an FSU Computer Science | audience too afraid to laugh." Technical Support Group | email: boyd@nu.cs.fsu.edu | - Voltaire ------------------------------ Date: 4 Nov 91 11:40:36 GMT From: mcsun!unido!sbsvax!lupus@uunet.uu.net (Markus Wolf) Subject: PD or shareware Fortran Compiler out there To: Info-Atari16@naucse.cse.nau.edu Hi Folks, is there a PD or shareware version of a FORTRAN77 Compiler out there in netland. Please, post me a server. Lupus ------------------------------ Date: 4 Nov 91 08:30:43 GMT From: cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!mig@rutgers.rutgers.edu (Meir I Green) Subject: SIMPLE NETWORK!? To: Info-Atari16@naucse.cse.nau.edu Would it be possible to network a few PCs and Macs by connecting their TX/Data and Rx/Data lines together and simply sending some simple header information before each transmission? Would this essentially be any different from any single-channel network? Would it simply be a problem of impedance matching? In that case, I suppose that about 3 PCs should work with no special matching circuits. Is this what the $25 network is? How about a simple TSR which would allow transparent file operations using the serial port, or, perhaps, remote logins--OS/2 should allow this already, I suppose! Thanks. Meir * * * * * * ================== Internet mig@cunixb.cc.columbia.edu * * * * * * * = Meir I. Green == or Internet mig@asteroids.cs.columbia.edu * * * * * * ================== UUCP Bang! ...rutgers!columbia!cunixb!mig * * * * * * * ================== Amateur Radio N2JPG@W2XO.PA.USA.NOAM ------------------------------ Date: 4 Nov 91 03:35:22 GMT From: vax5.cit.cornell.edu!wwhy@cu-arpa.cs.cornell.edu Subject: TT sound broken! To: Info-Atari16@naucse.cse.nau.edu I just recently bought a TT and I've had it for a couple weeks. For some reason the sound no longer works. Nothing I do will make the sound come back on. I've tried the control panel, I've tried every program that has sound effects or music. Nothing works. I'm very upset. I've only had the thing for a couple weeks and already it is broken! If anyone has had similar problems and knows how to fix this please let me know, and if anyone from Atari is listening, I'm beginning to lose my faith after spending tons of money on a computer that isnt realiable. Bill ------------------------------ Date: 4 Nov 91 00:55:35 GMT From: noao!asuvax!cs.utexas.edu!milano!cactus.org!covert@arizona.edu (Richard Covert) Subject: Wants (What's!) happening? To: Info-Atari16@naucse.cse.nau.edu In article <3NOV199115015563@zeus.tamu.edu> jmm2948@zeus.tamu.edu (Jeffrey M. Mayzurk) writes: >(original text deleted) > >> >>The Atari market is soo starved for good professional development tools >>that they will buy products that no one others would even consider. >>HyperLink with its poor design and lack of features, TC2 with its >>German only docs, Lattice C 5 with its lack of source code debugger and >>MAKE utility are just a few of the lousy tools that I have bought >>for my ST. >> >>for me, the Mac is the only machine that makes sense. Heck, even the >>great new Atari UNIX System V package is worthless to me. It doesn't >>support a link to the TOS environment. Mac has too UNIX versions >>available. an old AT&T System V Release 2 (which is admittedly an >>old UNIX), and A new BSD 4.3 UNIX called MachTen. Both of these support >>seemlessly the Mac apps, so you can run your Mac apps while inside >>UNIX and X Windows. That is years beyond what Atari is capable of. >> >>So, that is why I am so flamed at Atari Corporation!! >>-- >I am afraid that I have to agree with you. I have owned and used Atari >computers since 1982, way back to the 400 days with 16k ram. Things have >changed a lot. I have owned an ST since 1986, and I really do like the >machines. Unfortunately, I just can't use a machine that isn't supported. >I NEED software -- it's that simple. I hate to leave Atari, but I really >have no choice. I'm not going to sell my machine -- it's still useful -- >but I am currently in the market for a Mac II. (blasphemy, I know...) > >However, I'm not flamed at Atari Corp. They did it to themselves, and >noone else is to blame. Back in '86, they really had a good position in >the market -- a fresh product with lots of potential, but they never >developed it to it's full extent. If they had only advertised! > >Oh well.. I hope (by some miracle) things turn around, but I'm not holding >my breath. The STe and TT have a lot of potential, but it's too late now >for Atari to get any real support. > >Jeff Mayzurk Lack of professional tools is a big reason why I think that the ST/TT is a doomed marklet. Just to give another example, why did Atari Corp fail so dismally with the CD ROM? Heck they announced a product back in 1987. I remember going to my local Atari dealer in Phoenix AZ and placing an order for one! I would have bought it sight unseen in those days. But to this day you can't buy an Atari CD ROM drive. As for the CD ROM software, I saw a notuce here on USENET for 50 CD ROMs from NASA with hundreds of mewgabytes of digitized photos from various space programs. None of these CD ROMs are configured for the ST/TT. All come with software for the PC and for the Mac platforms. Say what you want about the ST/TT but it is rapidly becoming an obsolete non-supported platform that is too expensive for me to justify further support of!! Want more examples of peripherals too advanced for the ST/TT? well, have the newest Digital Audio Tape backup systems? There are several different makers of them for the Mac. None for the ST/TT. Now that must be because no one would spend $1500.00 for a peripheral for the ST/TT huh? Or what about those new 3.5" optical read/write drisk drives. Available for the Mac, not for the ST. What about that new Hyperlink product being hawked as a HyperCard clone. Well, the ads in ST INFORMER make it said really great, but then you find out that HL is basically just a shell over dBMAn. The released version 1.52 doesn't support sounds or even printing. So whil;e it makes a nice platform to demo some limited ideas you can't use it in a production environment. And yet HL is listed at $150. Heck, the full Hypercard Deverloper's package sells for only $99. So, the Atari HL product is 50% more expensive than HyperCard but with much less capability!! What about the fabled much praised German Turbo C? Well, it is now renamed "Pure C", but it still is available only with German docs. the Gribnif folks on GEnie admit that their "Pure C" will come with German docs only. They site "legal reasons" (which are unspecified on GEnie) for that. but the ST/TT market is starving for decent tools that it will support even such products as German documented only compilers!! And even then the ST version of Turbo C is double or triple the cost of the PC version of Turbo C. And the PC TC comes with English docs, and with USA support. there are literally tens of hardware and software peripherals available for the Mac that aren't for the ST/TT. As for the fantastic DTP packs for the ST/TT, some maybe be as good as those for the Mac, but when you add in all of the other Mac programs which aren't available for the ST/TT then how can you justify the cost of a fully decked out TT? Or even for a new Mega STe4? For all of the above reasons, I class Atari Owners in the same group as other Religous Fanatics!! You can not justify buying an Atari product in rational terms, as it doesn't other the same level of support as other platforms. But if you criticize the ST/TT then the Atari Fanatics attack you!! So don't buy an Atari on rational reasons, just buy it and enjoy whatever software you can find for it!! And enjoy being one of the few and brave Atari owners!! Join the Religion!! -- Richard E. Covert covert@cactus.org CACTUS ..!cs.utexas.edu!cactus.org!covert ------------------------------ Date: 4 Nov 91 08:06:37 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!snorkelwacker.mit .edu!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!nuug!ifi.uio.no!jkr@arizona.ed u (Johan Kristian Rosenvold) Subject: Where is Happy Computer /Discovery ? To: Info-Atari16@naucse.cse.nau.edu Does anybody have happy computer's phone number or BBS number ? (The producers of the discovery cartridge. European magazines have stopped taking their ads. (For reasons I can understand)). -- K. Rosenvold, jkr@ifi.uio.no Short signatures R QT. ------------------------------ End of Info-Atari16 Digest ******************************