Info-Atari16 Digest         Sat,  8 Jun 91       Volume 91 : Issue 323

Today's Topics:
                    And yet more 520ST info wanted
                    Appending Files with GEMDOS...
                                lharc
                            Music software
                      Problems with Demos on a.a
                      Publishers (III) (2 msgs)
                     ST/TT: two scsi bus masters
                    TC array bug... (was: Re: Reli
                             TT HD floppy
                      TT ram revisited (2 msgs)
                     Weekly Posting of New Stuff

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: 8 Jun 91 04:47:55 GMT
From: fernwood!portal!cup.portal.com!Azog-Thoth@uunet.uu.net (William Thomas
 Daugustine)
Subject: And yet more 520ST info wanted
To: Info-Atari16@naucse.cse.nau.edu

A coupla weeks ago, I got a 520 STfm, and after using it, Ive more questions
to ask about it...

I know the memory can be upgraded, people have told me so, and I also
opened up the case, and saw an unpopulated bank of memory. What I need
to know is the value of the caps that I also need to add, so I can
populate this bank with the 256k chips.

On that same note, Ive heard that you can get 4mb of RAM, but I dont
quite see how. There are no SIMMs or SIPP sockets to hold the larger
memory modules.

Anyways. I found out that the version of TOS I have is 1.0. I guess
that this is stored in the ROM. Anyway of upgrading to 1.4? Also,
what is the difference between 1.0 and 1.4? Any benifit of upgrading?
And since its on my mind :-) Just what does TOS stand for anyways?

Thanx, even tho Im sure that Ive repeated questions thats been asked
many times

 Billy D'Augustine
Azog-Thoth@cup.portal.com

------------------------------

Date: 8 Jun 91 04:32:23 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!atha!aunro!ersys!mforget@arizona.edu
 (Michel Forget)
Subject: Appending Files with GEMDOS...
To: Info-Atari16@naucse.cse.nau.edu

Does anyone know how to use the GEMDOS File commands to open a file for a
ppending.  I have been trying using Personal Pascal, but that is a weak
spot for the language, so I have decided to try to use the GEMDOS
commands (F_Open, F_Close, F_Seek, etc.) to do the job.

Can anyone help?


<<  ----------------------------------  >>
<<  ersys!mforget@nro.cs.athabascau.ca  >>
<<     mforget@ersys.edmonton.ab.ca     >>
<<            Michel Forget             >>
<<  ----------------------------------  >>

------------------------------

Date: 5 Jun 91 08:49:00 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu
 !ira.uka.de!smurf!artcom0!hb.maus.de!hh.maus.de!Thomas_Quester@arizona.edu
 (Thomas Quester)
Subject: lharc
To: Info-Atari16@naucse.cse.nau.edu

TJ>I find that the newer versions of lharc don't seem to be compatable with the
TJ>unix lharc...   the version I use is very slow, its like v1.1 or something l
TJ>that (i think it says its based on v1.13c or something) anyways, try an old
TJ>it will probablly work for you (and be horribly slow, but thats another stor
TJ>Tad

With LHarc you have to specify the version-number, because we have many
different versions and some authors working on their own versions.
"The newer version" means nothing but "any version".

MauTau V 2.2c - Tanz ist der senkrechte Ausdruck eines horizontalen Verlangens.
(Net)

------------------------------

Date: 7 Jun 91 21:44:07 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-
 state.edu!usenet.ins.cwru.edu!ysub!psuvm!cunyvm!ndsuvm1!ud005565@arizona.edu
Subject: Music software
To: Info-Atari16@naucse.cse.nau.edu

Does anyone know of any music software that I can get via ftp. I'm mostly
interested in editing and printing special arrangements, but would like to
look at anything that is available.          Bill Martin

------------------------------

Date: Sat, 8 Jun 91 17:40:04 BST
From: "D.Richards" <ug8737@computing.bradford.ac.uk>
Subject: Problems with Demos on a.a
To: Info-Atari16@naucse.cse.nau.edu (Info-Atari16)

I am having trouble with some of the demos that are on atari.archive.
The MSA's crash my machine when trying to create the disk, and a lot of
the lzh's on there contain a lot of bad files and invalid headers.

Please email me directly since i finish in three weeks time.

Dave Richards
(ug8737@uk.ac.brad.comp)

------------------------------

Date: 7 Jun 91 23:31:33 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!news-server.
 csri.toronto.edu!utgpu!watserv1!watmath!lsuc!jimomura@arizona.edu (Jim Omura)
Subject: Publishers (III)
To: Info-Atari16@naucse.cse.nau.edu

     A long while back when the Atari ST was strong I wrote a
magazine article.  As is typical for me, it was an unusual article.
I started with a datafile which came from MS-DOS (dBASE III) which
wasn't being accepted by the programs I had available.  To do so
I moved the file to my Color Computer 3 and used a hexdump utility
to analyze the data and do what I had to do to make it usable.

     It worked.  In retrospect, I think I turned it into a
"comma separated value" file and read it into MasterPlan.  Or I
might have done something else with it.  I can't remember.  Whatever
I did, I remember it wasn't a particularly difficult problem.  But
I laid out the procedure and theory behind what I did so that people
could see that it was the approach that counted and that there were
a number of tools available for the Atari ST or any other computer
that could do the job.

     There were a number of very valuable lessons to be learned.
One valuable lesson was that there is NOT an isolated "Atari ST
world" which either survived or died and held us captive.  No, not
any more than there is a Color Computer 3 world, the "death" of
which would make my Color Computer 3 "obsolete".  Nor were there
specific tools necessary without which I could not get the job done.
Oh, in certainty, I had to have certain classes of capabilities,
such as an ability to look into a file in a Hex dump presentation
or some other way of seeing the ASCII values and binary values,
and possibly some computer language or other tool to modify or
extract data from the file.  Also I had to have the ability to
move the data "cleanly" between the two computers.  But any number
of tools could do the job, selectable froy those bro`d `f!qsdpA2 0^ 90q!@	I΄
.,-΄
.
$M̬AN.N,m̮L-%N$-Ό
LM.
.m-Nd.--,MD..M$
jnm,,l-%
$,-΁N

m.L.M,mD.d
l%
m
.M
$.dm
-
N-΄.dm.lNL-̄
mAO-Ml
.e쭍N
mNDDnfo-Atari16@naucse.cse.nau.edu

In article <CMM.0.90.2.676202856.larserio@kvart.ifi.uio.no> larserio@ifi.uio.no
 writes:
> Anyone who know how I can make my Spectrum 512 work on my MEGA STE
> It dooesn't work on standard STE's either...
>
> Who distributes Spectrum 512 these days ?
> The old adress and fax-number to Electric distribution doesn't work :-(
>
>  Lars-Erik  /  ABK-BBS +47 2132659  /   ____ ______ ________________________
>   Osterud  /  larserio@ifi.uio.no  /   /___    /            The norwegian ST
> __________/ ______________________/   ____/   /   Klubben,  user association

Well you could try the firm that makes it, Trio Engineering,,
But I think that Spectrum was replaced with Unispec, now Unispec II,
if I remember,
It has the option to copy other sceens to Unispec (Sectrum), can run as
a ACC.
I would like to find out my self if they are still supporting the
Atari computers, ?.
--
***  Roger W. Sheppard        *    Roger.Sheppard@bbs.actrix.gen.nz  ***
***  85 Donovan Rd          *  *   At least I don't Flicker, not     ***
***  Kapiti New Zealand..    *     like a dying light globe. !       ***

------------------------------

Date: 5 Jun 91 20:06:21 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!dimacs.rutgers.edu!aramis.rutgers.edu
 !paul.rutgers.edu!njin!njitgw.njit.edu!tesla.njit.edu!fer9483@arizona.edu
Subject: System for Sale
To: Info-Atari16@naucse.cse.nau.edu

My friend has the following for sale:

520 St computer
External DS Drive
Color Monitor
Atari 20 Meg Hard Drive

-He does not read the newsgroup, and my account expires in a few days.  If
interested CALL HIM at 908-276-5447 - His name is Mike.

------------------------------

Date: 6 Jun 91 17:50:30 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!zaphod.mps.ohio-state.edu!magnus.acs.
 ohio-state.edu!usenet.ins.cwru.edu!ysub!psuvm!dearn!dmswwu1c!zvd007@arizona.edu
 (Ulrich Kuehn)
Subject: Umich atari
To: Info-Atari16@naucse.cse.nau.edu

In article <1991Jun5.1y
to analyze the data and do what I had to do to make it usable.

     It worked.  In retrospect, I think I turned it into a
"comma separated value" file and read it into MasterPlan.  Or I
might have done something else with it.  I can't remember.  Whatever
I did, I remember it wasn't a particularly difficult problem.  But
I laid out the procedure and theory behind what I did so that people
could see that it was the approach that counted and that there were
a number of tools available for the Atari ST or any other computer
that could do the job.

     There were a number of very valuable lessons to be learned.
One valuable lesson was that there is NOT an isolated "Atari ST
world" which either survived or died and held us captive.  No, not
any more than there is a Color Computer 3 world, the "death" of
which would make my Color Computer 3 "obsolete".  Nor were there
specific tools necessary without which I could not get the job done.
Oh, in certainty, I had to have certain classes of capabilities,
such as an ability to look into a file in a Hex dump presentation
or some other way of seeing the ASCII values and binary values,
and possibly some computer language or other tool to modify or
extract data from the file.  Also I had to have the ability to
move the data "cleanly" between the two computers.  But any number
of tools could do the job, selectable from those broad classes
of tools.

     But the magazine I sent it to didn't want it.  They *loved*
the article generally, but they wanted me to rewrite it using the
tools available for the Atari ST specifically.  They didn't want
people to know that the *approach* was the key.  To show that
methodology was so important as to eclipse the brand of computer
you worked on was, well, "too much truth" for their readers.
I agreed to re-write the story.  But time being what it was, I
never got it done.  It's a pity.  They should have printed my
original story.  Maybe later people would not have been running
around with their heads cut off moaning the death of the Atari ST.
It's not dead really, but that's another matter.  Anyway, I won't
say which of the magazines it was.  But they made a choice a long
time ago.  They decided to shovel the brown stuff which was
their version of the "truth" about the Atari ST and computers
and software in general.  And for the most part, other "fan magazines"
in the computer industry and even in other industries, are about
as bad.  And now they, and many others like them are gone.  So what
I think I've seen over the years is that people pretty much get what
they deserve.

     It's not likely that I'll ever be a publisher in the
professional sense.  I've put out "newsletter" in the past, but
I'd really rather be writing or drawing, or even researching,
than doing the paste-ups and all the other details of publishing.
So I'm writing this with the hope that maybe someday someone
will make it into the publishing side, and keep it in mind.
Maybe you don't have to squeeze the truth through some strained
filter after all.  Maybe doing so isn't going to help you as
much as you think.  Maybe in the long run, your magazine
might even last longer if you aim for higher standards.  And maybe
it won't.  But then when it's over, at the very least, you will
be able to say, "I told the truth."
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura

------------------------------

Date: 7 Jun 91 06:22:51 GMT
From: mcsun!hp4nl!phigate!prle!prles2!cstw163!meulenbr@uunet.uu.net (Frans
 Meulenbroeks)
Subject: ST/TT: two scsi bus masters
To: Info-Atari16@naucse.cse.nau.edu

Hi,

I was wondering whether is would be possible to share a hard disk
between two computers.
The disk in question is a disk with a separate host adaptor and an
Adaptec 4000 scsi<->st506 board.
I was wondering if it is possible to share this disk between two
computers. Could this sharing be done on the acsi level, or only
at the scsi level.
If this is hardware-wise possible, could then both computers use
the same disk at the same time, or would that require software
or hardware support which is not present.
If the adaptec has two disks connected, would it then be possible
for each of the computers to use one of the disks.

I know, I can plug the disk to the other system, but I foresee
that I'll have to use both systems for a while, while moving from
the one to the other. Both systems need the same data, so the only
other solution seems to be to do cable juggling each time a
transition between systems is made. I'd rather not do so.

Anyone any experience/knowledge/information??

Thanks,
--
Frans Meulenbroeks        (meulenbr@prl.philips.nl)
        Centre for Software Technology

------------------------------

Date: 5 Jun 91 22:31:00 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu
 !ira.uka.de!smurf!artcom0!hb.maus.de!do.maus.de!Martin_Koehling@arizona.edu
 (Martin Koehling)
Subject: TC array bug... (was: Re: Reli
To: Info-Atari16@naucse.cse.nau.edu

Juergen Lock nox @ jelal.north.de wrote:
<a1465268@jelal.north.de>

JL>From article <2330@do.maus.de>, by Martin_Koehling@do.maus.de (Martin
JL>Koehling):
JL>>
JL>> Juergen Lock nox @ jelal.north.de:
JL>> <a5434559@jelal.north.de>
JL>>>[description of zoo/TC array index bug deleted]
JL>> The bug was fixed in Turbo C version 2.00.
JL>
JL> hmm, sure? i know someone who i'm sure has some version >= 2.00
JL>and he had to do this same [(long) foo] thing to get `compress'
JL>running. i know that 'cause i was it who told him the `trick'... :-)

I'm rather sure; I tested several cases which were compiled into
16-Bit-Code by the 1.x compiler: the 2.0 compiler generated the correct
code for 32 bit indexing.
But of course there could still be some bug lurking...

JL>> It wasn't really a bug but a "design restriction" - it made programs both
JL>> smaller and faster (it's even mentioned somewhere in the manual!).
JL>
JL> not in my manual (TC 1.1 that is). and besides, what does ANSI
JL>say about this?

I got it mixed up - it's not in the 1.0/1.1 manual but in the accompanying
README file!

And since it is documented, it can't be a bug - it must be a feature! ;-))
(But of course you're right: from an ANSI point of view the compiler is
"broken" since it violates the "model" of the C language.)

The funny thing is: in version 2.0, they moved this info from the README
file into the printed manual; at the same time, they fixed the problem!

JL>> The new compiler uses only 16 bits for array addressing if and only if it
JL>is
JL>> sure that the array addressed is smaller than 32 KBytes.
JL>
JL> ummm... how can it be sure when i, for example calloc()ed the thing?

It's simple: it can't be sure - and so of course it will not use 16 bit
("short") addressing! :-)
As far as I know, the compiler uses "short" addressing only on arrays<=32KB
if they are declared in the same module, and _never_ on poiners...

Martin

------------------------------

Date: 7 Jun 91 06:45:55 GMT
From: mcsun!hp4nl!phigate!prle!prles2!cstw163!meulenbr@uunet.uu.net (Frans
 Meulenbroeks)
Subject: TT HD floppy
To: Info-Atari16@naucse.cse.nau.edu

I've heard rumours in the past that future TT versions will be equipped
with a HD floppy drive. This leads to the following questions:
- Is this rumour true?

and if so:
- Has there been mentioned anything about the time frame in which this
  should occur?
- will it be possible to upgrade current TT's?

Thanks for the info!
--
Frans Meulenbroeks        (meulenbr@prl.philips.nl)
        Centre for Software Technology

------------------------------

Date: 7 Jun 91 06:31:07 GMT
From: mcsun!hp4nl!phigate!prle!prles2!cstw163!meulenbr@uunet.uu.net (Frans
 Meulenbroeks)
Subject: TT ram revisited
To: Info-Atari16@naucse.cse.nau.edu

Hi,

Thanks to all who responded on my TT ram question.
I won't summarize here. Allen Pratt dealt with the question in great
detail. I don't think I should just duplicate that.

I'm left with a few small questions.

Allen says that in the future you can buy 16 MB of TT RAM
from atari. Could I do such an upgrade by myself by just
replacing the 1 MB simms by 4 MB ones, or are there other caveats?

Also I found out that the TT ram is 100ns ram. I do not have any 68030
doc handy, but with a 32 Mhz clock, I think at least one (and very maybe 2)
wait states will be required to access this memory.
Would it be technically feasible to replace this memory with faster
memory, and get rid of this wait state? Will 80 ns be enough to get rid
of the wait state, or should 60 ns be used??

Since, if I'm not mistaken, the 68030 requires at least 3 clock cycles to
do a memory access. So removing a wait cycle would speed up the memory
access from 4 to 3 cycles. which would (in theory)  lead to a speed
gain of something like 25 %. Now of course not all cpu activity is
memory access, so perhaps this figure is on the high side, but it seems
to me that a substantial gain could be obtained here.

--
Frans Meulenbroeks        (meulenbr@prl.philips.nl)
        Centre for Software Technology

------------------------------

Date: 8 Jun 91 08:23:23 GMT
From:
 noao!ncar!asuvax!ukma!wuarchive!zaphod.mps.ohio-state.edu!think.com!spool.mu.ed
 u!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!mbaker@arizona.ed
 u (Matthew Baker)
Subject: TT ram revisited
To: Info-Atari16@naucse.cse.nau.edu

From article <meulenbr.676276267@cstw163>, by meulenbr@cst.prl.philips.nl (Frans
 Meulenbroeks):
> Hi,

Hi... :)

> Also I found out that the TT ram is 100ns ram. I do not have any 68030
> doc handy, but with a 32 Mhz clock, I think at least one (and very maybe 2)
> wait states will be required to access this memory.
> Would it be technically feasible to replace this memory with faster
> memory, and get rid of this wait state? Will 80 ns be enough to get rid
> of the wait state, or should 60 ns be used??

At the risk of making a fool of myself, I should call to notice the fact
that most larger Intel-powered systems use 70 or 80ns DRAMs, with
similar clock speeds. Even these chips aren't fast enough to keep up
with the CPU. Various techniques are used to ensure that, most of the time,
the same DRAM is not read twice in two machine cycles... on the rare
occurence that it is, a wait state is inserted... - thus, you get quotes
of 0.01 wait states, etc.

> Since, if I'm not mistaken, the 68030 requires at least 3 clock cycles to
> do a memory access. So removing a wait cycle would speed up the memory
> access from 4 to 3HT)=;D4#&wSdx$cSBFs7VF@#!1 D   !> !??!>B > #>0  !> >8>0>80	>>    	>800 >> 8>>"  !>> >!> >&!>2 >>   >> !>8>9> 288> 8>0  '>2!> 28 '> !?B >2 !> !> #>!>
80>& 8>" >!?!>2 > >!?>8'? !>8!?>0 0>00 >2    ? x>8'>!>">08>" ? fxpAx>I>8n%+256)                 ! Reserve image space + spare room.
      pici%=0
      tmp|=INP(#1)
      uselocal!=BTST(tmp|,7)                ! Look for Local Color Map
      interlace!=BTST(tmp|,6)               ! See if image is interlaced.
      lpixel&=(tmp| AND 7)+1                ! Local bits per pixel.
      pass|=0
      hline&=0
      vcol&=0
      lstep&=8
      IF uselocal!                           ! We have a Local Color Map
        crange&=SHL(1,lpixel&)               ! Color range
    .edu (Atari Archive Robot)
Subject: Weekly Posting of New Stuff
To: Info-Atari16@naucse.cse.nau.edu

  drwxrwxr-x daemon     1024    Jun 1 08:55 .
  drwxrwxr-x jon        3072    Jun 1 08:51 ./graphics
  -rw-r--r-- weiner     5323    Jun 1 08:51 ./graphics/Index
  -rw-r--r-- weiner     81618   Jun 1 08:55 ./Index
  -rw-r--r-- weiner     40965   Jun 1 08:55 ./CompInd.Z
  drwxrwxr-x daemon     1024    Jun 2 13:45 .
  drwxrwxr-x jon        2048    Jun 2 13:44 ./applications
  -rw-r--r-- weiner     181     Jun 2 13:44 ./applications/Index
  drwxr-xr-x weiner     24      Jun 2 13:43 ./applications/math
  -rw-rw-r-- weiner     3857    Jun 2 13:42 ./applications/.index
  drwxr-xr-x weiner     24      Jun 2 13:43 ./applications/databases
  drwxr-xr-x weiner     24      Jun 2 13:43 ./applications/spreadsheets
  drwxr-xr-x weiner     24      Jun 2 13:43 ./applications/persutls
  drwxr-xr-x weiner     24      Jun 2 13:43 ./applications/dtp
  drwxr-xr-x weiner     24      Jun 2 13:43 ./applications/wordproc
  drwxr-xr-x weiner     24      Jun 2 13:43 ./applications/astronomy
  drwxr-xr-x weiner     24      Jun 2 13:43 ./applications/other
  drwxrwxr-x jon        536     Jun 2 21:46 ./gnustuff
  -rw-r--r-- weiner     77912   Jun 2 13:45 ./Index
  -rw-r--r-- weiner     39257   Jun 2 13:45 ./CompInd.Z
  drwxrwxr-x daemon     1024    Jun 4 22:40 .
  drwxrwxr-x weiner     524     Jun 4 06:49 ./utilities/desktop
  drwxrwxr-x jon        3072    Jun 4 12:18 ./graphics
  -rw-r--r-- weiner     5322    Jun 4 12:19 ./graphics/Index
  -rw-r--r-- weiner     72674   Jun 4 12:17 ./graphics/gemview105.lzh
  drwxrwxr-x weiner     512     Jun 4 12:20 ./applications/dtp
  drwxrwxr-x weiner     512     Jun 4 12:20 ./applications/dtp/fonts
  drwxrwxr-x weiner     512     Jun 4 12:27 ./applications/dtp/fonts/calamus
  -rw-rw-r-- weiner     82944   Jun 4 12:27
 ./applications/dtp/fonts/calamus/chanceri.arc
  -rw-rw-r-- weiner     92160   Jun 4 12:27
 ./applications/dtp/fonts/calamus/lucifer2.arc
  -rw-rw-r-- weiner     68608   Jun 4 12:27
 ./applications/dtp/fonts/calamus/tiempo12.arc
  drwxrwxr-x weiner     24      Jun 4 12:20 ./applications/dtp/fonts/pagestream
  drwxrwxr-x jon        536     Jun 4 12:07 ./gnustuff
  drwxr-xr-x swood      512     Jun 4 22:39 ./portfolio/support
  drwxrwxr-x jon        1024    Jun 6 03:12 ./gnustuff
  -rw-r--r-- gray       425580  Jun 6 03:12 ./gnustuff/g++-139.lzh
  -rw-r--r-- gray       116352  Jun 6 03:12 ./gnustuff/inc++.lzh
  -rw-r--r-- weiner     5410    Jun 6 07:05 ./graphics/Index
  -rw-r--r-- weiner     1111    Jun 6 07:02 ./music/Index
  drwxrwxr-x daemon     1024    Jun 7 23:06 .
  drwxrwxr-x jon        4096    Jun 7 22:44 ./games
  -rw-r--r-- weiner     22086   Jun 7 22:44 ./games/mst.lzh
  -rw-rw-r-- weiner     7827    Jun 7 22:45 ./games/Index
  lrwxrwxrwx gray       37      Jun 7 11:22 ./games/gnuchess.arc ->
 ../gnustuff/tos/othergnu/gnuchess.arc
  lrwxrwxrwx gray       34      Jun 7 11:23 ./games/gnugo.arc ->
 ../gnustuff/tos/othergnu/gnugo.arc
  lrwxrwxrwx gray       37      Jun 7 11:24 ./games/gnu-m522.zoo ->
 ../gnustuff/tos/othergnu/gnu-m522.zoo
  drwxrwxr-x jon        1536    Jun 7 22:38 ./archivers
  -rw-r--r-- weiner     48094   Jun 7 22:32 ./archivers/lha130.lzh
  -rw-r--r-- weiner     17536   Jun 7 22:38 ./archivers/uucode10.arc
  -rw-r--r-- weiner     45056   Jun 7 22:38 ./archivers/xlharc12.arc
  -rw-r--r-- weiner     2963    Jun 7 22:40 ./archivers/Index
  -rw-r--r-- weiner     530081  Jun 7 22:43 ./tex/texdr179.lzh
  drwxrwxr-x jon        2048    Jun 7 22:37 ./telecomm
  -rw-r--r-- weiner     22656   Jun 7 22:34 ./telecomm/gem_xyz.lzh
  -rw-r--r-- weiner     41183   Jun 7 22:34 ./telecomm/xyz201.lzh
  -rw-r--r-- weiner     61176   Jun 7 22:34 ./telecomm/zcterm20.arc
  -rw-r--r-- weiner     2663    Jun 7 22:38 ./telecomm/Index
  drwxrwxr-x weiner     512     Jun 7 22:41 ./applications/dtp/fonts/calamus
  -rw-r--r-- weiner     13312   Jun 7 22:41
 ./applications/dtp/fonts/calamus/mini_6.arc
  -rw-r--r-- weiner     207872  Jun 7 22:32 ./applications/dtp/fonts/calamus/blip.arc
  drwxrwxr-x jon        1024    Jun 7 11:12 ./gnustuff
  drwxrwxr-x jon        2560    Jun 7 11:12 ./gnustuff/tos
  drwxr-xr-x gray       512     Jun 7 07:05 ./gnustuff/tos/updates
  drwxr-xr-x gray       512     Jun 7 09:29 ./gnustuff/tos/unikoeln
  drwxr-xr-x gray       512     Jun 7 05:57 ./gnustuff/tos/unikoeln/g++
  -rw-r--r-- gray       1271    Jun 7 05:34 ./gnustuff/tos/unikoeln/g++/gnu++.g
  -rw-r--r-- gray       291236  Jun 7 05:35 ./gnustuff/tos/unikoeln/g++/lib++.lzh
  -rw-r--r-- gray       1645    Jun 7 05:34 ./gnustuff/tos/unikoeln/g++/README.G++
  -rw-r--r-- gray       7696    Jun 7 06:02 ./gnustuff/tos/unikoeln/g++/FList
  drwxr-xr-x gray       512     Jun 7 09:29 ./gnustuff/tos/unikoeln/shell
  -rw-r--r-- gray       205006  Jun 7 09:20
 ./gnustuff/tos/unikoeln/shell/unikoelnsh.lzh
  drwxr-xr-x gray       512     Jun 7 09:29 ./gnustuff/tos/unikoeln/gcc
  -rw-r--r-- gray       405835  Jun 7 09:20 ./gnustuff/tos/unikoeln/gcc/unikoelngcc.lzh
  -rw-r--r-- gray       405281  Jun 7 09:20 ./gnustuff/tos/unikoeln/gcc/unikoelnbin.lzh
  drwxr-xr-x gray       512     Jun 7 07:09 ./gnustuff/tos/gdb
  drwxr-xr-x gray       512     Jun 7 07:13 ./gnustuff/tos/documentation
  -rw-r--r-- gray       103464  Jun 7 07:10 ./gnustuff/tos/documentation/docs.arc
  -rw-r--r-- gray       2072    Jun 7 07:10 ./gnustuff/tos/documentation/gcc-st.aux
  -rw-r--r-- gray       120400  Jun 7 07:10 ./gnustuff/tos/documentation/gcc-st.dvi
  -rw-r--r-- gray       2815    Jun 7 07:10 ./gnustuff/tos/documentation/gcc-st.log
  -rw-r--r-- gray       96526   Jun 7 07:10 ./gnustuff/tos/documentation/gcc-st.tex
  -rw-r--r-- gray       1454    Jun 7 07:10 ./gnustuff/tos/documentation/gcc-st.toc
  -rw-r--r-- gray       68592   Jun 7 07:10 ./gnustuff/tos/documentation/lib-card.dvi
  -rw-r--r-- gray       431     Jun 7 07:10 ./gnustuff/tos/documentation/lib-card.log
  -rw-r--r-- gray       58381   Jun 7 07:10 ./gnustuff/tos/documentation/lib-card.tex
  -rw-r--r-- gray       74886   Jun 7 07:10 ./gnustuff/tos/documentation/texinfo.tex
  drwxr-xr-x gray       512     Jun 7 07:02 ./gnustuff/tos/g++jrd
  drwxr-xr-x gray       512     Jun 7 07:01 ./gnustuff/tos/archivers
  drwxr-xr-x gray       512     Jun 7 08:35 ./gnustuff/tos/currentgnu
  drwxr-xr-x gray       512     Jun 7 08:35 ./gnustuff/tos/currentgnu/diff
  drwxr-xr-x gray       512     Jun 7 09:08 ./gnustuff/tos/currentgnu/src
  -rw-r--r-- gray       659     Jun 7 11:41 ./gnustuff/tos/currentgnu/src/README.admin
  drwxr-xr-x gray       512     Jun 7 08:51 ./gnustuff/tos/currentgnu/bin
  -rw-rw-rw- gray       734664  Jun 7 08:40 ./gnustuff/tos/currentgnu/bin/gcc139bin.zoo
  drwxr-xr-x gray       512     Jun 7 07:11 ./gnustuff/tos/oldsources
  drwxr-xr-x gray       1024    Jun 7 11:17 ./gnustuff/tos/othergnu
  drwxr-xr-x gray       512     Jun 7 08:28 ./gnustuff/tos/othergnu/gnu881
  drwxr-xr-x gray       1024    Jun 7 08:29 ./gnustuff/tos/oldgcc
  drwxr-xr-x gray       512     Jun 7 08:29 ./gnustuff/tos/oldgcc/gcc138
  drwxr-xr-x gray       512     Jun 7 08:30 ./gnustuff/tos/oldgcc/gcc138/diff
  drwxr-xr-x gray       512     Jun 7 07:22 ./gnustuff/tos/oldgcc/gcc136
  drwxr-xr-x gray       512     Jun 7 07:22 ./gnustuff/tos/oldgcc/gcc136/bin
  drwxr-xr-x gray       512     Jun 7 07:03 ./gnustuff/tos/oldgas
  drwxr-xr-x gray       512     Jun 7 07:00 ./gnustuff/tos/emacs
  drwxrwx--- gray       512     Jun 7 09:26 ./gnustuff/admin-shed
  -rw-r--r-- gray       12750   Jun 7 08:34 ./gnustuff/admin-shed/Index
  -rw-r--r-- gray       1271    Jun 7 09:20 ./gnustuff/admin-shed/gnu.g
  -rw-r--r-- gray       2315    Jun 7 09:20 ./gnustuff/admin-shed/gnustuff
  -rw-r--r-- gray       0       Jun 7 09:19 ./gnustuff/This_Area_Is_Under_Reorganisation
  drwxrwxr-x jon        1536    Jun 7 11:25 ./printing
  lrwxrwxrwx gray       37      Jun 7 11:24 ./printing/gsbin.zoo ->
 ../gnustuff/tos/othergnu/ghscrptb.zoo
  lrwxrwxrwx gray       37      Jun 7 11:25 ./printing/gssrc.zoo ->
 ../gnustuff/tos/othergnu/ghscrpts.zoo
  -rw-r--r-- weiner     78371   Jun 7 22:46 ./Index
  -rw-r--r-- weiner     1354    Jun 7 22:41 ./mint/Index
  -rw-r--r-- weiner     39452   Jun 7 22:46 ./CompInd.Z
  -rw-r--r-- weiner     65399   Jun 7 22:49 ./ls-lR.Z

------------------------------

End of Info-Atari16 Digest
******************************