Info-Atari16 Digest Sun, 29 Sep 91 Volume 91 : Issue 514 Today's Topics: ARJ? K.I.S.S.! ATARI MEGA 2 ST W/ HD FOR SALE Cartridge Port for STBooks Hi-Rez Vidio card info wanted!!! lharc 2.01e vs zoo 2.1: some tests (2 msgs) More Lies From Atari? People dumping machines (was.. Atari Mega 2 system.. for sale) Problems upgrading to 4M (was SIMMS from a Mac SE into an ST?) question about Megafile 30 STOS Users 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: 28 Sep 91 00:31:28 GMT From: noao!asuvax!cs.utexas.edu!swrinde!mips!apple!portal!atari!kbad@arizona.edu (Ken Badertscher) Subject: ARJ? K.I.S.S.! To: Info-Atari16@naucse.cse.nau.edu rosenkra@convex.com (William Rosenkranz) writes: |[...] burrying GEM code in a an application |making it "bisexual", if you will, makes it larger (obviously). bundling |the gem user interface for like programs (all archivers pretty much do |the same thing) in a separate shell seems like a better approach, though |it may make installation slightly more complicated. True. The problem I have with the archiver situation in the TOS world, though, is that so darned many of them exist. TOS versions of Arc have long been surpassed in performance by more efficient compressors. Yet a lot of the archives I see on BBS's and elsewhere are still ARC format. I find LZH situation depressing. I personally have had little luck getting a single LZH tool that would deal with the variety of LZH formats out there. This is why I was happy to see ZOO version 2.1 appear, with its high- performance option that beats or matches LZH compression. The main reason I like zoo is for its superior directory handling and "novice" command set. Having ARJ available will be even better. After using it under DOS, it became apparent to me that it merges all the best features of the different archivers I've used. Its compression is phenomenal (you want fast? ARJ does fast... you want tiny? you can get that too; slower, but not unreasonably so). It has a complete set of options for handling directories and for creating self-extracting archives, split-volume archives, etc. ad inf. If the programmers porting ARJ make a version that everyone can use conveniently, we may be looking at the StuffIt of TOS archive programs. Because the compression beats the competition (and after all, that's the bottom line in archivers, no?), people will likely latch onto it. If, as an added bonus, it has a user-friendly face, more people will want to look at it. If it's the best archiver in terms of compression vs. speed tradeoffs, and flexibility in file handling, it'd sure be nice if it were also the best in terms of ease of use. As an aside... |also, IF atari plans on ever releasing some flavor of UNIX in the future, |it will be in your best interest to educate users on using CLIs anyway. |[...] i really don't see a way around CLI use in unix |at some point (i.e. sys admin). who knows, atari might suprise us :-). I think the Atari Unix group will do just that! |the other problem is that i fear gem code and the application will get |hopelessly intermingled making it impossible to port to non-GEM platforms. |that is assuming source is even distributed. [Good example of how to insert system-specific GUI code into a CLI-based source distribution deleted] |comments, ken??? could this be a new standard programming practice? :-) You're right on that count. People porting programs like this should be careful about how they wedge GEM features into a CLI-based program. Whenever one modifies a source distribution, the modifications should be as nonintrusive as practical, and there should *always* be a way to retrieve the original, using conditional compilation or other techniques. Also, while it's true that programs bloat a bit when GEM features are added, the rewards are worth the few extra K of disk space consumed. The extra effort can make a program useful to thousands more people. As an example, wiring a non-trivial GEM UI into MicroEMACS costs adds only about 20K of disk space to a 100K or so program. That 20% increase in size makes the program much, much easier to use (in my experience, and in the experience of EMACS users, both novice and pros, on whom I foisted the bug-ridden hack :). -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari Corp. System Software Engine / | \ #include ------------------------------ Date: 28 Sep 91 04:30:14 GMT From: ucivax!gateway@locus.ucla.edu (James Tang) Subject: ATARI MEGA 2 ST W/ HD FOR SALE To: Info-Atari16@naucse.cse.nau.edu I have an Atari Mega 2 ST system for sale. Asking for $1500.00 or best offer (make me an reasonable offer) for the the following: Atari Mega 2 ST unit Atari Color Monitor SM124 85 MB HD for sale (Seagate 296N with ICD FAST Host adaptor) Tweety Board, stereo sound Replay4 sound digitizer Owner's menu for all of the above Items All softwares that I have is included. Such as: Populous and the Promise Land disk ICD HD utilities ..... Please reply with e-mail at: jtang@einstein.oac.uci.edu or call at (714) 725-5798 and ask for James ------------------------------ Date: 27 Sep 91 19:24:01 GMT From: noao!asuvax!cs.utexas.edu!swrinde!mips!apple!portal!atari!trh@arizona.edu (T R Hall) Subject: Cartridge Port for STBooks To: Info-Atari16@naucse.cse.nau.edu As I said in the earlier post, the "120-pin Expansion Port" has all of the signals neccesary to create a cartridge port, and we (Atari) have encouraged/ are encouraging third parties to make a _*very*_ simple board to convert from Expansion to Cartridge. (two connectors and a PCB... _*no*_ active parts) What I wanted to add is that I have built such a board in the lab, and it works just fine. Tracy R. Hall ------------------------------ Date: 27 Sep 91 21:11:15 GMT From: rayssd!jarsun1!drd!d.cs.okstate.edu!cummins@uunet.uu.net (John Cummins) Subject: Hi-Rez Vidio card info wanted!!! To: Info-Atari16@naucse.cse.nau.edu I want to purchase a good vidio setup for my Mega ST. I'd prefer 1024 X 768 pixel modes for both color and monochrome, and I hope to be able to handle standard LO-REZ, MED-RED, and HI-REZ modes as well (For existing software that doesn't check the screen size... or that does check and asks you to set it to LO-REZ or whatever. I intend to do an SST (Gadgets by Small) upgrade on the machine as well... and wish to maintain as much compatability as possible. Prices and impressions Please!!! (Especially BARGAINS!!!) (email too, my news-server expires things in less than 24 hours) jc (john Cummins) cummins@d.cs.okstate.edu ------------------------------ Date: 27 Sep 91 23:01:16 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs .ohio-state.edu!usenet.ins.cwru.edu!ncoast!bjsjr@arizona.edu (Bill Shroka) Subject: lharc 2.01e vs zoo 2.1: some tests To: Info-Atari16@naucse.cse.nau.edu In article <1991Sep26.064525.15427@convex.com> rosenkra@convex.com (William Rosenkranz) writes: > >friends- > >to help understand the claim that lharc is the best thing since sliced >bread, and so much better than zoo 2.1, i ran some tests. this is a rather >long post. if you think i am crazy, hit 'n' now. or put me in your kill >file :-). if you have an open mind, read on for enlightenment... As the person responsible for the ST version of Zoo (and one of the many versions of LHarc), I guess I should make a few comments here. The following will be a highly edited version of Bill's article. >summary: zoo 2.1 is just about as fast as lharc 2.01e and > makes files about the same size. Agreed. Lharc 2.01e is undisputedly the fastest LHarcer available for the ST. The slow version of Zoo (the current version) is almost as fast as lharc 2.01e but is much, much more compatible across (and on the same) platforms. That's why I gave up on LHarc: There was no central development team to make decisions on design. >test platform is mega4 (4 MB) 8 Mhz, TOS 1.2, using gulam CLI. environment >included TMP=ramdisk and TEMP=ramdisk (i confirmed there was no use of >hard disk by observing that no disk access lights went on). Just a note(for those interested): Zoo doesn't use any type of TMP variable. > lharc 2.01e (questor, Assemblerversion vom 14.07.1991) > zoo 2.1 (1991/07/14 22:39:26) > >i would call this "equal" technology since the versions were realized >on the same dates! zoo was compiled with GNU c (gcc) though i do not know >which version. i confirmed this by both "printstk zoo.ttp" which did not I used GCC 1.40. I'm always on the cutting edge of the GNU stuff :-) >fail, listing a reasonable stacksize (16k) and by "strings -10 zoo.ttp" >which listed ascii strings that would appear if gcc was the compiler. >it also looks like zoo 2.1 was compiled with MiNT so that it could be >"backgrounded" in a multiprocessing environment. i could be way off base >here, however. i just spotted the string "MiNT" in the .ttp. i saw no I used Patchlevel 72 (I think) of bammi's library, which is slowly merging with Eric's mintlib. I use the 16K stacksize (as opposed to all available memory) so that Zoo can be used in the background MiNT or RTX. >evidence that lharc was equally endowed. it also looks like zoo may support >UNIXMODE tho i don't use it myself. UNIXMODE allows configuration so that >forward slashes "/" can be used in file paths as well as backslash "\". Yes, Zoo does support UNIXMODE though I don't use it either. >zoo21: extract files: > >this took 25 seconds. the times and dates of extracted files were exactly >correct (same dates and times as files in the archive). Though the times and dates were correct for you, there are some known bugs in Zoo time code, especially the timezone stuff. I have been informed that they have already been fixed for the next version. >---------------------------------------------------------------------------- >test 4: > >i tested each program's ability to be interrupted. during archive creation, >i issued a control-C to both. both stopped. however, lharc left a file >behind "lharc.)2(" so it does not really handle signals. zoo does since >it was compiled with GNU C library (another reason why it is better to >use a compiler with a decent library). zoo cleaned up after itself. The GCC-ST library is a tribute to Jwahar Bammi and Eric Smith (and all of the other contributors). It makes ports like Zoo a breeze. Thanks guys. > - the size of the executables is significantly different. about 2x > (lharc being the smaller). however, after packing with pfxpak, > zoo is about 53k and lharc is about 28k. the difference is not > that significant in a 16 MB partition. what i do find fascinating > is that the executable for lharc is itself an archive! this is > a really super hack. incidently pfxpak was written by the very > same thomas questor who provides the lharc under scrutiny. (and > thomas, i DID disassemble it, tho the crash in test 3 wiped it > out since i had the source on the ramdisk. maybe you could mail > me the source now...:-). still, i generally dislike self extracting > archives though this is a twist on that concept. In these days of massive sized hard drives I personally find executable size VERY, VERY, unimportant. If I have a choice between exec size and speed, I'll take speed every time. I would guess UNIXMODE adds quite a bit to the size of GCC execs (I'm not sure) since it is emulating a new file system. > - the version of zoo sources i have can easily be ported to any > system with POSIX library and an ANSI C compiler. this includes > scores of systems from the PC and ST to supercomputers. lharc Many thanks to R. Dhesi for this! > - i can take the zoo 2.1 archive up to a unix (or VMS) system and > extract the archive with no effort. i do not have to track down > a version which will extract it. the original version posted to > the net (source code) works fine. i have tried unlzhing an lh5 > archive on unix with LHarc for unix v1.02 with no luck. it complains > that it cannot extract this method. in this case someone is going to > berate me saying "well, you should get this_and_such version and > quit moaning". i would (naturally) respond with "so how often do > i have to update lharc on unix to remain current? i already have > 2 versions. how many more do i need? i only need one version of > zoo 2.1!". if it is any consolation, at least 1.02 does not core > dump when it finds this out (0.03 does, at least my port on a > convex does). When Yoshi added -lh5- to lha (as it is now known) he also re-wrote much of lha in assembly. Thus, no version of lha has ever been ported to Unix, so you cannot unlzh any -lh5- archives. >also, i know of some optimizations for zoo which may not have been applied >in the version i have (posted to comp.binaries.atari.st by steve grimm). >i know the unix version with larger i/o buffers is significantly faster >(at least 20% on a convex C210 with VME disks). if that is also true on >the ST, then the small speed advantage lharc has (only on compression, that >is) over zoo goes away. and zoo 2.1 may be even faster than lharc on >extraction in that case. There have been some significant optimizations to ST Zoo, though none of them change any of the Zoo code. All i/o is done with the aid of a 32K buffer (as set by __DEFAULT_BUFSIZ__). When I initially ported Zoo, it took 7:03 to compress gcc-cc1.ttp(roughly 600K) using high compression. After profiling and then 'inlining' the appropriate functions, I was able to get the compression time down to 5:36. I believe that shows some of the power of the GCC compiler. >also note that this version of zoo appeared within days of being posted >to alt.sources. i am sure it has not been tuned in the slightest. and i >hope it stays that way, so we don't end up with 50 versions of zoo. It took me about 1 hour to do my initial port of ST Zoo. Any 'tuning' I did has been added to the mainstream Zoo source. >it would also be nice to look at each program's i/o efficiency by controlled >tests in cluttered hard disk partitions or on virgin-formatted floppies. >i have not done that nor do i think it is worth the effort at this point. >also each program's handling of directory trees should be tested. zoo 2.1 >(on the ST only!) now has an improved method for doing recursive hierarchies >(a//). the unix version still uses the "find . -print | zoo aI archive" >method as far as i know. this is not possible with the ST without CLIs that >support pipes. gulam (and the desktop) do not support pipes. I don't know if I'd call the present method of 'recursive descent of directory trees' improved :-) I think enough people have twisted R. Dhesi's arm so that he will add this feature to the next version of Zoo. At least that's what he told me (I haven't seen the new code yet). >comments??? rebuffs??? name calling??? Thanks for the initial comparison. I wouldn't mind seeing a more in-depth comparison of the archivers (including ARJ if it's ever released). It would help me address any of Zoo's shortcomings. Anyone interested in doing this?? >-bill >rosenkra@convex.com -- -------------------------------------------------------------------------- Bill Shroka bjsjr@NCoast.ORG uunet!usenet.INS.CWRU.Edu!ncoast!bjsjr ------------------------------ Date: 28 Sep 91 13:22:41 GMT From: comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger Sheppard) Subject: lharc 2.01e vs zoo 2.1: some tests To: Info-Atari16@naucse.cse.nau.edu In article <1991Sep27.162345.14991@convex.com> rosenkra@convex.com (William Rosenkranz) writes: > In article <1991Sep27.131642.16914@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes: > >I have just had a look at your rather long posting, well for one thing > >that I find that it is very biased to ZOO 2.1.. > > > >BUGS. I think you will find that the Date/Time Problem is possible caused > >by TOS 1.2, I have tested some files and never found a date or time probem, > >but then I do use TOS 1.4.:-) > > > >ARGV is claimed to be supported, but I have no way to test it, there > >was some comments in the Doc's that Thomas had fixed ARGV in version 201D. > > i do (and did). lharc 2.01e DID cause my system to crash. if there is a > newer version than this, send it to me and i will retest. you never run > across this because you never run CLIs. if you did, your system would > likely crash as well. I have noticed that the system LZH201E was compiled with Torbo C 2.0, may be there is a Problem with a C libary,? that caused ARGV to fail, I do know its there as I have traced it.. > spending money has never been my problem :-). i have 2 ataris (mega 4 > and 1040ST, megafile 60, sh204, at least 3 monitors, etc, etc,etc). i > should upgrade (one of these days) but that is still no excuse for lharc > not to work properly on 1.2 and 1.0 (if it is in fact a TOS 1.4 > incompatibility as you suggest). as far as i know, the Fdatime GEMDOS call > works the same in all TOS versions. it is used to set file timestamps. From some Atari Notes that I have on TOS 1.4, they mention incorrect documentation of the Fdatime GEMDOS call, thats in earlier versions of TOS ?, could this be the problem ?. One thing you did not test with both Archivers was full i/o, did you not state that ZOO 2.1 has a problem with Disk i/o,? if this is the case then none of your tests are valid. I think that it would be far better if some one had done these test, that was not that biased, you new of the new features in zoo 2.1, but you did not bother to find out about any new features of LZH201X.. As far as ZOO is concerned, I find that ZOO is used on only about 2-5% of the PD files that I get. Also I have never made a ZOO archive, I had so many problems with eXtracting ZOO archive that I don't use it as a archiver at all, there are too many switches to understand, unless you have a Computer Science Degree, so far from what I can see only used by Unix Freeks, they like wearing key boards out..:-).. > -bill > rosenkra@convex.com > > -- > Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra > Convex Computer Corp. |ARPA: rosenkra@convex.com -- *** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * * GEnie. R.SHEPPARD5 *** *** Kapiti At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 27 Sep 91 18:04:08 GMT From: noao!asuvax!cs.utexas.edu!swrinde!mips!apple!portal!atari!trh@arizona.edu (T R Hall) Subject: More Lies From Atari? To: Info-Atari16@naucse.cse.nau.edu darling@cellar.UUCP (Thomas Darling) writes: >techno@lime.in-berlin.de (Techno) writes: >> Well, the ST-BOOK is available here in Germany. I've seen one here >> at my dealer two days ago. >> >> Features: >> 1 MByte RAM, 40 MB HD, cost 4000.- DM >> I/O: MIDI, DMA, parallel, serial, system bus, external mouse >> built-in modem optional, external 1.44 MByte (!) 3.5" disk drive optional >> 10h battery life on optional accu pack, rechargeable inside 2h during mains >> operation. >> >> Personal optinion: I like the thing, esp. the screen and the VectorPad. > >What I want to know is this: Does it have a cartridge ("dongle") port? I need >that port for my SMPTE/MIDI expander box (Unitor, from C-Lab). > >If this is, in fact, one of the I/O's mentioned above, please inform me, for I >know not the technical terms. There isn't directly a cartridge port, _*BUT*_... The "120-pin Expansion Port" (my/atari's name for the "system bus") has _*all*_ the signals neccesary to _*create*_ a cartridge port. We have encouraged/are encouraging third parties to make a _*very*_ simple board to convert the "Expansion" to "cartridge". (two connectors and a PCB... no active parts at all). Tracy R. Hall ------------------------------ Date: 28 Sep 91 14:24:10 GMT From: noao!asuvax!cs.utexas.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-b eacon!eru!hagbard!sunic!ugle.unit.no!lise.unit.no!stigvi@arizona.edu (Stig Vidar Hovland) Subject: People dumping machines (was.. Atari Mega 2 system.. for sale) To: Info-Atari16@naucse.cse.nau.edu In article <1991Sep27.143553.27920@magnus.acs.ohio-state.edu>, dhbutler@magnus.acs.ohio-state.edu (David Butler) writes: |> This is a TRUE 25mhz 68030 |> machine (why did Atari screw up the TT with a 16mhz bus system? arrgghh!!), The Motorola 68000 series of microprocessors have an asyncronous bus system. There is no 16MHz or 32Mhz or xxMHZ bus system in the TT. As you probably know, the MC68030 can read from TT-ram in burst-modus and this is as fast as it can be. It is not limited by a "slow bus". Stig Vidar Hovland - stigvi@lise.unit.no ------------------------------ Date: 26 Sep 91 13:25:56 GMT From: ispd-newsserver!psinntp!uupsi!stiatl!iam@uunet.uu.net (Ian Mercado) Subject: Problems upgrading to 4M (was SIMMS from a Mac SE into an ST?) To: Info-Atari16@naucse.cse.nau.edu steve@thelake.mn.org (Steve Yelvington) writes: >[In article <1991Sep21.030908.985@cs.sfu.ca>, > wolfgang@cs.sfu.ca (Wolfgang Jung) writes ... ] > > My feeling of this is that you NEED (i never read you did) to remove or > > at least deactivate the 256K Chips , which normaly reside in BANK 0 > > In the case you forgot that, the hardware gets into VERY big Trouble when > > reading from the rams at an Address greater than 512K. If you leave the > > HIGH Address line unconnected (MAD10 i think) the system reads and writes > > into the same bytes, which shouldn't make any Problems. >How do you do this (temporarily)? I have an old nearly-original 520 (with >modulator, without floppy) that has a half-populated Tech Specialties >piggyback board. I'd like to bring it up to 4MB, since chips are >practically free these days, but to do so I need to disable bank 0. I'd >like to do that without having to get a bunch of chips desoldered -- in >case it doesn't work and I have to restore the original setup. All I did on my original 1040 to disable the leftover bank was clip the L1 inductor which provides power to the chips. Worked like a charm, and I could always solder it back together if I felt it was necessary. (Although WHY I might want to go back to 2.5 meg from 4 meg is way beyond me. -- -------- ---- ---- -- | Ian Mercado: iam@salestech.com | -- - - ----- -- | emory!slammer!stiatl!iam | -- -------- -- ----- | | -------- -- -- -- ---- | "I'd rather be flying." | ------------------------------ Date: 28 Sep 91 13:40:52 GMT From: comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger Sheppard) Subject: question about Megafile 30 To: Info-Atari16@naucse.cse.nau.edu In article <1991Sep27.161732.14365@edm.isac.CA> darius@edm.isac.ca (Darius S. Naqvi) writes: > > Inside my megafile 30 is a seagate ST238R hard drive; the R means RLL > format. Am I correct in assuming, then, that the controller in the > megafile is an RLL-to-ACSI board? Does this mean that if I want to swap > the drive mech., the only choice I have is to use an RLL drive, or is it > possible to use some other type of drive? > > Please be patient with me if this question seems stupid. I'm not a hard > drive expert, just someone who wants an easy way to get a bigger, faster > hard drive. > -- > Darius S. Naqvi mail:darius@edm.isac.ca > ISA Corp. phone:(403) 420-8081 > Edmonton, Alberta, Canada Yes you are right, you can only use a MFM RLL drive, or take a chance and use a normal MFM drive and format it RLL.. Also it is posible to format hard drives with a 1:1 interleave, but this has to be forced with some format software, as the controler is seen as a Adaptec 4070, this normaly can't do 1:1, but this is a Atari one, and it Can..! -- *** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz *** *** 85 Donovan Rd * * GEnie. R.SHEPPARD5 *** *** Kapiti At least I don't Flicker, *** *** New Zealand.. * not like a dying light globe *** ------------------------------ Date: 28 Sep 91 14:32:17 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs .ohio-state.edu!usenet.ins.cwru.edu!cleveland.Freenet.Edu!aj639@arizona.edu (Michael Cox) Subject: STOS Users To: Info-Atari16@naucse.cse.nau.edu I was wondering if anyone programs in STOS? I have an Amiga and use AMOS but would like to try and port some STOS programs over. I'd also like to see what an STOS program looks like. If anyone could help me, please send email to aj639@cleveland.freenet.edu Thanks in advance! Mike -- Okay, folks, look for the newest AMOS PD disk called the AMONER Project. It's available on: ab20 (128.155.23.64) directory: /amiga/games/amos filename: amoner01.dms ux1 (128.174.5.50) directory: /amiga/amoner filename: amoner01.dms ------------------------------ Date: 28 Sep 91 10:46:40 GMT From: umich!terminator!usenet@yale.arpa (Atari Archive Robot) Subject: Weekly Posting of New Stuff To: Info-Atari16@naucse.cse.nau.edu drwxrwxr-x daemon 1024 Sep 21 09:23 . drwxrwxr-x jon 2560 Sep 22 00:37 ./magazines/streport -rw-r--r-- weiner 48866 Sep 22 00:37 ./magazines/streport/str738.txt.Z drwxrwxr-x jon 2048 Sep 22 00:37 ./magazines/znet -rw-r--r-- weiner 28706 Sep 22 00:37 ./magazines/znet/znet9140.txt.Z -rw-rw-r-- weiner 111096 Sep 21 09:23 ./Index drwxr-xr-x weiner 1536 Sep 21 09:21 ./dc -rw-r--r-- weiner 11483 Sep 21 09:21 ./dc/dcpopbr2.arc -rw-r--r-- weiner 1469 Sep 21 09:22 ./dc/Index -rw-rw-r-- weiner 51759 Sep 21 09:23 ./CompInd.Z -rw-rw-r-- weiner 3704 Sep 22 15:50 ./admin/Current.monthly.posting drwxrwxr-x daemon 1024 Sep 24 21:15 . -rw-r--r-- weiner 3206 Sep 24 21:15 ./telecomm/Index -rw-rw-r-- weiner 111170 Sep 24 21:15 ./Index -rwxr-x--- weiner 209 Sep 24 21:13 ./.compind -rw-rw-r-- weiner 51800 Sep 24 21:15 ./CompInd.Z drwxrwxr-x daemon 1024 Sep 25 20:16 . -rw-rw-r-- weiner 9111 Sep 25 20:16 ./games/Index drwxr-xr-x weiner 512 Sep 25 20:15 ./games/tads -rw-r--r-- weiner 178463 Sep 25 20:15 ./games/tads/uu2v101.lzh -rw-rw-r-- weiner 111171 Sep 25 20:16 ./Index -rw-rw-r-- weiner 51804 Sep 25 20:16 ./CompInd.Z drwxrwxr-x daemon 1024 Sep 26 17:11 . -rw-r--r-- weiner 1342 Sep 26 17:11 ./music/Index -rw-rw-r-- weiner 111494 Sep 26 17:11 ./Index -rw-rw-r-- weiner 51988 Sep 26 17:11 ./CompInd.Z drwxrwxr-x daemon 1024 Sep 27 23:29 . drwxrwxr-x jon 1536 Sep 27 23:11 ./demos -rw-rw-r-- weiner 407844 Sep 27 23:11 ./demos/spoon_a.msa -rw-rw-r-- weiner 3250 Sep 27 23:13 ./demos/Index -rw-rw-r-- weiner 379678 Sep 27 23:11 ./demos/spoon_b.msa drwxrwxr-x weiner 1024 Sep 27 23:11 ./ste -rw-r--r-- weiner 401421 Sep 27 23:11 ./ste/delirs3a.msa -rw-rw-r-- weiner 1139 Sep 27 23:15 ./ste/Index -rw-r--r-- weiner 386716 Sep 27 23:11 ./ste/delirs3b.msa -rw-rw-r-- weiner 112061 Sep 27 23:29 ./Index -rw-rw-r-- weiner 80123 Sep 27 23:26 ./ls-lR.Z -rw-rw-r-- weiner 52299 Sep 27 23:29 ./CompInd.Z ------------------------------ End of Info-Atari16 Digest ******************************