Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 323
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!qsdpAÚ2 0^þùùùùó 9ð0q!ðÁÀ@ òIðÎ
.ä ,Äîì-Î
.
Ä
¯$Mî̬
A¡N ¤ .N,m¤ ìÌ®L-% N® ¯$ì-ά
¬¤äL®îM.¤
.®m-Ìä ¡¡Nííd .Ì--,M¤ ÍîD ¤..M$
jn ¬m,Í,l-%Ä
¯$ ,Äîì-ΡN î
¤ä
mÍîä . ¤L.Mì,mDì.d ¤
l¯%Ä
äm
îä .¡M¬®
ìíìï$ì.dmä
-®
îN-Î .dä ¬m.l¤ ¤ NL-Ì
ìÄ mí®®®A¡O-î¤íîMl¬
íÄì.eì
Níä
®¬mN®D ÍîDnfo-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 3H¦T)=;D4#&wSdþx$§c¹ÄúäSBFs7VF@Ð#âá!1 DÉ !> !??!>B > #>0 !> >8>0 >80 >ÁÃ> >800 >> 8 >>" !>> >!> >&!>2 >> ÁÃ>> !>8>9> 288> 8>0 '>2!> 28 '> !ÁÃ?ÁÂB >2 !> !> #>!>
80>& 8>" >!?! >2 > >!? >8'? ÁÂ !>8!?>0 0>00 >2 ? x>8'>!>">08>" ? fxpAÁÂx>I>8n%+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
******************************
