Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!lll-lcc!lll-tis!ames!ucbcad!ucbvax!FINGATE.BITNET!MAILER-DAEMON From: MAILER-DAEMON@FINGATE.BITNET (Mail Delivery Subsystem) Newsgroups: comp.sys.atari.st Subject: Returned mail: Unable to deliver mail Message-ID: <8707161013.AA16913@ucbvax.Berkeley.EDU> Date: Thu, 16-Jul-87 06:13:45 EDT Article-I.D.: ucbvax.8707161013.AA16913 Posted: Thu Jul 16 06:13:45 1987 Date-Received: Sat, 18-Jul-87 06:32:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 423 ----- Transcript of session follows ----- 554... Unknown fudec host name : sampo ----- Unsent message follows ----- Received: by santra.UUCP (5.51/6.4.TeKoLa) id AA18188; Thu, 16 Jul 87 10:58:54 +0300 From: Message-Id: <8707160758.AA18188@santra.UUCP> Received: by fingate Thu Jul 16 10:58:49 from MAILER@FINHUTC.BITNET via rscs BSMTP. Received: by FINHUTC (Mailer X1.24) id 2009; Thu, 16 Jul 87 04:23:30 FIN Date: Wed 15 Jul 87 16:25:41 PDT Reply-To: Info-Atari16,Score.Stanford.edu Sender: "Atari ST users forum (INFO-ATARI16)" Original-From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #278 To: , Original-To: , Info-Atari16 Digest Wednesday, July 15, 1987 Volume 87 : Issue 278 This weeks Editor: Bill Westfield Today's Topics: mediachange problem - (nf) Re: IBM high dense (ity) drives Re: DLII.ARC Re: How to get ALN from Atari VAX XMODEM RE: PC-Ditto Re: IBM emulator Re: IBM emulator Re: Disk R/W times for large files ST blit Lattice C 3.04 Re: ATARI ST w/hybrid arts smptetrack; Trojan Warning !! ---------------------------------------------------------------------- Date: 10 Jul 87 12:41:00 GMT From: mcvax!unido!infbs!hafer@seismo.css.gov Subject: mediachange problem - (nf) To: info-atari16@score.stanford.edu Has anyone written a device driver for GEMDOS which simulates removable media? E.g., a ramdisk driver which allows changing of disks? We want to write a device driver for accessing a file server and do not know how to convince GEMDOS that a media-change has taken place. Any information would be greatly appreciated. Udo Hafermann uucp: hafer@infbs ------------------------------ Date: 10 Jul 87 09:28:11 GMT From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov (Smee) Subject: Re: IBM high dense (ity) drives To: info-atari16@score.stanford.edu I'll go with Moshe on this. If we took the original sender's 'leave it alone' literally, we'd all still be using 1/8th meg 8-inch disks. Historically, 'packing' media hasn't been too painful as long as the physical characteristics of the media stay the same. 800/1600/6250 bpi tape drives are quite common. Drives which will read 80-track 5.25 or 3.00 inch disks will also handle 40-track ones. And, a proper QUAD-density 3.5 drive should do the right thing to current DD disks. (And, of course, a DS drive can use SS disks.) The only real disadvantage is that you must assume the lowest common denominator when interchanging or distributing disks (SS-DD for 3.5 drives). Our experience is that most disks stay with the one machine they were created on, which means that the new QD wins big in saving local stoarge, the cost being that you've got to remember to keep some DD's around for transporting data. Far as costs go, sounds like I should come to the States to buy my disks. Going price over here (for quality Branded disks) is (in packs of 10) about 6 dollars each for DS, little under 4 dollars for SS. Sigh... (Cameras and computers, my 2 hobbies, are distributed without regard for exchange rates, is my guess. In general, any given item for either costs the same IN NUMBERS in the US and the UK, which means, at current exchange rates, the UK price is about 1.6 times the US one.) ------------------------------ Date: 11 Jul 87 11:13:03 GMT From: mcvax!unido!laura!@@seismo.css.gov (Andreas Toenne) Subject: Re: DLII.ARC To: info-atari16@score.stanford.edu In article <736@ektools.UUCP> bruce@ektools.UUCP (Bruce D. Nelson ) writes: >Simon Poole's program, DLII.ARC was recently posted on GEnie. Last night, the >GEnie sysops purged it, and left a main banner message saying, in part, that >bugs had been reported in it and that they urged users who d/l'ed it to >destroy their copies. > ... >Simon, thanks for the nice program. I hope you can work out the tangles that >made the GEnie people nervous. I wonder what the bugs are ??? I like DLII but I'm getting very nervous too if this program is really capable of munching my precious data. Andreas Toenne CS Dept. U of Dortmund, W-Germany at@unido.uucp toenne@unido.uucp at@unido.bitnet D ------------------------------ Date: 11 Jul 87 03:49:30 GMT From: cbosgd!cwruecmp!bammi@ucbvax.Berkeley.EDU (Jwahar R. Bammi) Subject: Re: How to get ALN from Atari To: info-atari16@score.stanford.edu In article <783@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >I talked with Cindy Claveran and found out that she will send the linker, >along with laser-printed documentation (same content as the .DOC file, >but nicer-looking), to registered developers who send her $1.50 and >a disk. > Kudos to Alan for a very nicely done linker. One small suggestion. Instead of having a seperate index file, why not put it in the library archive itself (like ranlib(1)). Look forward to landons Macro Assembler and the debugger. -- usenet: {decvax,cbosgd,sun}!cwruecmp!bammi jwahar r. bammi csnet: bammi@cwru.edu <---------Please note change of address arpa: bammi@cwru.edu <---------Please note change of address compuServe: 71515,155 ------------------------------ Date: Sat, 11 Jul 87 21:55:37 PDT From: johnson%msuhep.hepnet@lbl.arpa Subject: VAX XMODEM To: info-atari16@score.stanford.edu X-ST-Vmsmail-To: LBL::"info-atari16@score.stanford.edu" I realize that this is not the place for talk about VAX matters, especially if they do not directly relate to the ST, but I recieved a copy (fortran source) to VAXXMODEM.FOR and would really be appreciative if the person who sent me this program last time would send me another copy. You see I recently through a wildcard in when I was deleting some similar files and ... oops... it was gone ( and silly me, I didn't have a backup). This is a PD program and it works (worked) great in that it allowed me to do file transfers using FLASH or Uniterm or any emulator that supported XMODEM, between my ST and the Vax's at work. If anyone knows where I could get this or if anyone wishes to aquire this (it beats the heck out of Kermit for speed) please drop me a note at the below address: BITNET : JOHNSON@MSUPA HEPNET : MSUHEP::JOHNSON (you may have to go via LBL node to reach me on hepnet- I get Arpanet mail (usenet?) at: JOHNSON%MSUHEP.HEPNET@LBL.ARPA Thanks, John Johnson MSU Physics Dept. ------------------------------ Date: Sat, 11 Jul 87 22:16:22 EDT From: MCOHAN%UMASS.BITNET@wiscvm.wisc.edu Subject: RE: PC-Ditto To: info-atari16@score.stanford.edu I got PC Ditto into my store last week. We ran Lotus 1-2-3, Turbo Pascal, Sidekick, GEM :-} , Word Perfect, and a couple of other things on it. The good news is, they all worked perfectly. No problems. The bad news is, it's pretty slow, especially when doing graphics. But, it WORKS. So it's slow, for $89.95, it's a pretty decent clone in my view. Michael Cohan The Computer Bug, Inc. The Hampshire Mall Hadley, MA 01035 phone (413) 584-7722 "Authorized Atari Sales & Service" ------------------------------------------------ "Are you questioning my shredding ability?" -- Oliver North ------------------------------ Date: 9 Jul 87 21:38:00 GMT From: mnetor!utzoo!utgpu!water!ljdickey@seismo.css.gov Subject: Re: IBM emulator To: info-atari16@score.stanford.edu In article <678@hhb.UUCP> rob@hhb.UUCP (Robert R Stegmann) writes: > ... >I just read in the August issue of Compute! magazine about an IBM PC >emulator (in software) for the ST. It is called "pc-ditto" from >Avant-Garde Systems, 381 Pablo Point Dr., Jacksonville, FL 32225. > ... >I called Florida information and got a phone number for Avant-Garde, >which turned out to connect me with some company that refuels Navy jets! > ... > he gave me another >number! I tried THAT number several times, but it was always busy, >so I haven't been able to contact Avant-Garde. I also tried to find Avant-Garde Systems in Jacksonville, but there is nothing listed with this name on Pable Point Drive. Something about address "381 Pablo Point Drive" makes me think of a residential area. I suspect that the person who wrote PC-DITTO is trying to start a business out of his home, picked the name "avant-garde", thinking it was pretty far ahead :-) but has no business phone yet. If someone in the Jacksonville area has a reverse phone book (such as a City Directory), they could look it up. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UUCP ljdickey%water@waterloo.CSNET ljdickey%water%waterloo.csnet@csnet-relay.ARPA ljdickey@watdcs.BITNET UUCP: ...!watmath!water!ljdickey ------------------------------ Date: 9 Jul 87 13:35:43 GMT From: mnetor!utzoo!utgpu!water!watmath!mks!wheels@seismo.css.gov Subject: Re: IBM emulator To: info-atari16@score.stanford.edu In article <678@hhb.UUCP>, rob@hhb.UUCP (Robert R Stegmann) writes: > I just read in the August issue of Compute! magazine about an IBM PC > emulator (in software) for the ST. It is called "pc-ditto". > Can anybody out there who has any experience with this product or company > comment? Does this emulator run at speed, or is it slow? > Is it real or vapor-ware? I haven't used it, although I briefly saw it running at the local dealer. There is much discussion about it on CompuServe, with the concensus being that it does indeed run almost everything. Its speed depends on the type of program being run, but seems to range from 50% to 80% of a plain PC. Some programs suffer from slowness (interpreted BASIC, action games, etc.), but users report running the usual applications, including communications programs. There was some discussion that the author was going to halt production after only one month, due to large-scale pirating, but the latest posting says that he has decided to continue as long as sales remain good. Hey, I don't know anywhere else to get an IBM PC for under $100! Now you can buy an Atari ST and have an ST, a MAC, and an IBM! :-) -- "Network XXIII. Where two's company, and three's an audience." -- Max Headroom Gerry Wheeler {seismo,decvax,ihnp4}!watmath!mks!wheels Mortice Kern Systems Inc. ------------------------------ Date: 10 Jul 87 19:25:14 GMT From: mnetor!utzoo!utgpu!water!watmath!orchid!egisin@seismo.css.gov Subject: Re: Disk R/W times for large files To: info-atari16@score.stanford.edu In article <1643@?>, braner@batcomputer.tn.cornell.edu (braner) writes: > But my experiments (when modifying microEmacs, etc) show that, with typical > text files (<50K), a buffer of 9K (one DS track) yields a performance that > is very close to that of larger buffers. That is with standard > ("slow") formatted disks. (The performance gradually levels off as you > increase the buffer size through 4.5, 9 and 18K.) There isn't any point in making IO buffers a multiple of the track size when using gemdos IO; it is unlikely the file begins at side 0, sector 1. Making the buffer large is what matters. I've been using disks formatted with 10 sector/track, and was wondering if this is within the specs for the floppy controller, or outside IBM specs, or what. Has anyone had problems with this format? Does anyone have some C code that does floppy IO at the controller level. I want to do a "track read". (I don't want assembler, I can get that from the bios listing). ------------------------------ Date: 10 Jul 87 10:29:41 GMT From: mcvax!ukc!siesoft!crs@seismo.css.gov (crs) Subject: ST blit To: info-atari16@score.stanford.edu I have heard that there is some software out there to allow an ST to become a terminal somewhat like a blit. Anybody got any information/software ? BTW could anybody in the uk who has the ST uucico or the vix software drop me a line so that I can arrange to be sent copies. Thanks in advance Chris Smith ------------------------------ Date: 11 Jul 87 15:29:36 GMT From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov (Smee) Subject: Lattice C 3.04 To: info-atari16@score.stanford.edu a Well, I finally found a copy of Dhrystone. I've run it through Lattice 3.04. With interesting results. For those of you who've seen figures for other machines/compilers, the results were: No register variables -- 757 Dhrys/sec (66 sec run time) Register variables -- 781 Dhrys/sec (64 sec) 520ST, ROM TOS, 50000 iterations. Figures I'd seen for the previous version of Lattice would suggest that 3.04 is something like 1.5 to 1.6 times faster than the last one, for th the sorts of things dhrystone checks -- basically 'typical' integer and char stuff. (Earlier less formal measurements I've taken make it look like floating point, not tested by dhrystone, is 8 to 10 times faster with this version than with the previous -- I don't have whetstone so can't check formally. I did have trouble with the use of 'command line define' (compiler arg of -dREG=register) which might have been me but which I think is more likely a bug. I had to resort to putting a #define REG register into the source. Just as a matter of interest, I also ran a version of DHRY which I modified by changing all 'int' declarations to 'short int'. (The few things which need 'long int' are specifically so declared and I left them alone.) I thought this might give a useful check as most ST compilers default int to short, while Lattice defaults it to long. I got a wonderfully anomalous result. Figures were: NO REGISTER VARIABLES -- 833 Dhrys/sec (60 sec) (short ints, remember) Register variables -- 806 Dhrys/sec (62 sec) Looks like the compiler's got better ideas about what to do with the registers than the benchmark writers. I think I shall report this back to MetaComCo just for fun. Paul ------------------------------ Date: 12 Jul 87 16:45:07 GMT From: hen@bu-cs.bu.edu (Bill Henneman) Subject: Re: ATARI ST w/hybrid arts smptetrack; To: info-atari16@score.stanford.edu Boston University has been growing a digital music studio,+primarily designed to supply sound for animations producedin our Computer Graphics Lab. The studio has a Macintosh, an an Atari 1040ST with B/W monitor I picked up used for $300. The studio also has access to Suns, Encores, and an IBM 3090 (on each of these we have some student-generated software). I originally bought the Hybrid Arts MIDI track because it had the interface box to do SMPTE, but I immediately fell in love with their sequencing facilities. I use the Mac, (do a little Jam Factory every morning) but for day-in-day-out work, I use the Atari w/ Hybrid Arts MIDI track (along with Gen Patch & various 'droids). They have the cleanest user interface I can find on any of the packages: somebody inside Hybrid Arts knows how to put together software that is intuitive to a musician and at the same time feels right to the compunerd. Every visitor to the studio who has experience with some other hardware/software combination (particularly Dr.. T) has told us that our system is unbelievably much easier to use - they very often end up grumbling about how their software is too much like a spreadsheet. I would sooner give up one of our keyboards than give up the MIDI track. Another suggestion: I would also say that the B/W monitor is much better than a color monitor if you are going to be using the software for any length of time. Color is very useful for cramming lots of information on a screen, but your eyes get glazed over much faster. I started with an Atari 1040 w/ color monitor, but I took it home as soon as I got the b&w Atari. ------------------------------ Date: 12 Jul 87 17:10:56 GMT From: mcvax!botter!ark!kleef@seismo.css.gov (Patrick van Kleef) Subject: Trojan Warning !! To: info-atari16@score.stanford.edu Although I don't think there's a large chance the program will make it across the Dutch borders, it can never harm to warn the ST-community about the presence of a so called Trojan Horse.. On my BBS in Amsterdam, Holland, a program has been uploaded that did in fact destroy the contents of some people's harddisks. It was described as a calcalutor with a very high accuracy (something like 300 decimals). Running this calculator produced nothing but a freshly cleaned harddisk. So watch out for a program that's called CALCULAT.ARC (or CALCULAT.BAS in its uncompressed form) and consists of a GfA Basic program. In it are poorly disguised routines named 'DESTROY' and other names that should make sirens sound, turn on red lights etc... In general: always turn off the harddisk when running a downloaded program, make regular back-ups and distrust downloads in general. Boy, am I glad I run my BBS on an PC-clone, uncapable of running ST-Trojans :) ------------------------------ End of Info-Atari16 Digest ************************** -------