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" 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!qsdpA2 0^ 90q!@ I΄ . ,-΄ . $M̬AN .N,m ̮L-% N $-Ό LM. .m- Nd .--,M D ..M$ jn m,,l-% $ ,-΁N  m . L.M,mD.d l% m  .M $.dm - N-΄ .d m.l NL-̄ mAO-Ml .e쭍N mND Dnfo-Atari16@naucse.cse.nau.edu In article 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: 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>> 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 , 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 3HT)=;D4#&wSdx$cSBFs7VF@#!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>" ? fxpAx>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 ******************************