Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 514
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 <disclaimer>
------------------------------
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
******************************
