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
**************************
-------