Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 571
Info-Atari16 Digest Mon, 4 Nov 91 Volume 91 : Issue 571
Today's Topics:
8mhz ST = 16mhz 386 (4 msgs)
desperatly looking for a GOOD UUCP p
HD backup
Indus GTS-100 floppy drive
PD or shareware Fortran Compiler out there
SIMPLE NETWORK!?
TT sound broken!
Wants (What's!) happening?
Where is Happy Computer /Discovery ?
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: 4 Nov 91 01:57:07 GMT
From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
Subject: 8mhz ST = 16mhz 386
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Nov3.204636.3057@murdoch.acc.Virginia.EDU>
lch3e@holmes.acc.Virginia.EDU (Lauren C. Howard) writes:
>An article in the October Current Notes magazine reviews up-to-date
>benchmarks comparing the ST and TT vs. 286/386sx/386/486
is this online somewhere?
>Our little ol' 8mhz ST's come out equal to or slightly better than
>the 386sx in ALL benchmarks, including running identical programs.
>
>The 386 is only slightly better (20mhz), and conjecture is that the
>Mega STE would blow any 386 away.
>
>The TT was mucho better than the 486, though unclear by how much.
can u be a wee bit more specific? when u say "identical programs", are
these source code (that u compiled) or common applications? if the former,
are you sure u are not really benchmarking compilers? on the ST itself,
any 2 different compilers may differ by 2x or more in dhrystones, for
example. i measured dhrystones (2.0 or 2.1) with alcyon at about 800 and
gcc, turbo C, etc all do over 2000, i think. has nothing to do with the
hardware, only compiler. i find it REAL hard to believe an 8Mhz system
outperforms a 16 Mhz system, and is close to a 20 Mhz system, especially
with this very simple architecture which pc's (generic) represent.
also, is there _detailed_ configuration info on these benchmarks, eg disk,
memory size, compiler, etc? are we really comparing the same thing, either
by power or price, or is this an ultra-biased attempt to make the ST look
good (for some unknown reason)? and do these benchmarks represent some
real workload or are they things the ST may do particularly well at?
a comprehesive test would include display (text and graphics), calculation
(integer and floating point), i/o, telecom, etc. it would also be fair
to have a 386/486 "expert" do their tests and an atari "expert" do ours.
such an expert would choose the proper configuration, compilers, etc.
i could see the TT doing well against a 486, however, given comparable
clock (and disk) speeds. since i don't have access to a TT (or a 486)
this is pure conjecture on my part.
>Chew on that awhile.
munch, munch, munch...all done. give me (us) more :-)...
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 4 Nov 91 03:35:00 GMT
From:
noao!ncar!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!spool.mu.edu
!munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick@arizona.edu
(Warwick Allison)
Subject: 8mhz ST = 16mhz 386
To: Info-Atari16@naucse.cse.nau.edu
In <1991Nov04.015707.11599@convex.com> rosenkra@convex.com (William Rosenkranz)
writes:
>In article <1991Nov3.204636.3057@murdoch.acc.Virginia.EDU>
lch3e@holmes.acc.Virginia.EDU (Lauren C. Howard) writes:
>>Our little ol' 8mhz ST's come out equal to or slightly better than
>>the 386sx in ALL benchmarks, including running identical programs.
>>
>>The 386 is only slightly better (20mhz), and conjecture is that the
>>Mega STE would blow any 386 away.
>can u be a wee bit more specific? when u say "identical programs", are
>these source code (that u compiled) or common applications? if the former,
>are you sure u are not really benchmarking compilers? on the ST itself,
>any 2 different compilers may differ by 2x or more in dhrystones, for
>example. i measured dhrystones (2.0 or 2.1) with alcyon at about 800 and
>gcc, turbo C, etc all do over 2000, i think. has nothing to do with the
>hardware, only compiler. i find it REAL hard to believe an 8Mhz system
>outperforms a 16 Mhz system, and is close to a 20 Mhz system, especially
>with this very simple architecture which pc's (generic) represent.
The Intel architecture is NOT a simple architecture. That's what makes it
so slow. Where a 680x0 has one continuous expanse of memory, the 386
system would be using 64K chunks, adding base registers and all that stuff.
(The 386 is CAPABLE of running with continuous memory, but the OS generally
isn't). These figures do not suprise me at all. 16MHz 386 is probably
around the power of a 8MHz 68000. Although I agree, the methods for
finding the results are very inexplicit.
Warwick.
Did you know that the screen memory on a 386 runs about 1/5 the speed of
normal memory? And I thought the TT was slow with video memory!!!!
--
_-_|\ warwick@cs.uq.oz.au
/ * <-- Computer Science Department,
\_.-._/ University of Queensland,
v Brisbane, AUSTRALIA.
------------------------------
Date: 4 Nov 91 08:52:34 GMT
From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
Subject: 8mhz ST = 16mhz 386
To: Info-Atari16@naucse.cse.nau.edu
In article <4924@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes:
>The Intel architecture is NOT a simple architecture. That's what makes it
>so slow. Where a 680x0 has one continuous expanse of memory, the 386
>system would be using 64K chunks, adding base registers and all that stuff.
>(The 386 is CAPABLE of running with continuous memory, but the OS generally
>isn't). These figures do not suprise me at all. 16MHz 386 is probably
>around the power of a 8MHz 68000.
nobody hates segmented memory more than me. well, there may be someone :-).
just look what it did to minix/PC :-(. long ago i made a conscious decision
to avoid intel 80x86 chips just because of the horrid memory architecture.
(my favorite quip re: the '86 is "segments are for worms". i wish i had
said that :-).
well, we could argue about what "simple" means. to me unitasking uniCPU
non-vector/parallel unibank/non-interleaved non-cached CISC systems are
"simple". this pretty much sums up the ST (and many 386 implementations).
i have not used a 386 in quite a while so i don't claim to be expert in
what it can do. in fact, i don't even think i have much technical info on
the 386 on my shelves. i do know of some 386 _implementations_ which are
used in very demanding applications (like embedded system data processors).
as much as i hate the 386, i would think a good 16Mhz implementation will
beat a good 8Mhz 68000 implementation handily. now we can argue about what
"good" means (and what good costs). and the 486 does have an on-chip
instruction/data cache and FPU. also many instructions execute in 1 clock
(the 68000 takes 8 clocks to do a register/register longword add), tho i
think memory bandwidth is usually the critical issue.
on a somewhat related note, since the ST has multiple memory banks, are
they interleaved? will stride 1 memory access on the ST run faster
than (say) stride n where n is the number of banks (4 as i recall)?
i was under the impression that each bank holds a contiguous address
range. if it _is_ interleaved, is it byte-wise or word-wise interleaved?
and what is a "word" in this context? or is the bank cycle time included
in the move cycle count? consulting my 68000 move table, for example,
a "move.l d0,(a0)" takes 16 cycles. it seems to be independent of memory
architecture. is this similar to the 386? does zero wait state make sense
on a 68000? is the ST memory bandwidth limited?
> Although I agree, the methods for
>finding the results are very inexplicit.
exactly. we need more info than "8Mhz = 16Mhz" or "TT >= 486"...
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 4 Nov 91 10:37:27 GMT
From: mcsun!hp4nl!alchemy!piet@uunet.uu.net (Piet van Oostrum)
Subject: 8mhz ST = 16mhz 386
To: Info-Atari16@naucse.cse.nau.edu
>>>>> rosenkra@convex.com (William Rosenkranz) (BR) writes:
BR> hardware, only compiler. i find it REAL hard to believe an 8Mhz system
BR> outperforms a 16 Mhz system, and is close to a 20 Mhz system, especially
BR> with this very simple architecture which pc's (generic) represent.
The MHz don't mean anything if you compare different CPU architectures. It
is just the frequency of the clock. It is a well known fact that a 8 MHz
68000 is roughly equivalent to a 16MHz 80*86. The 68000 just does about
twice as much in one clock pulse than the 80*86. It also uses less overhead
because of the more regular instruction set, addressing modes and the
better register structure. With the "improvement" in architecture on the
[34]86 machines this is expected to become less significant, but then the
680[34]0 also improve.
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet
Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete')
------------------------------
Date: 3 Nov 91 19:36:44 GMT
From:
noao!ncar!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!spool.mu.edu
!cs.umn.edu!msi.umn.edu!math.fu-berlin.de!unido!mcshh!malihh!pfunk.hanse.de!bla
ckbox@arizona.edu (Michael Kistenmacher)
Subject: desperatly looking for a GOOD UUCP p
To: Info-Atari16@naucse.cse.nau.edu
In <1991Oct31.094337.14377@frmug.fr.mugnet.org>, Mathias Herberts writes:
>
>Well there I am again , looking for a UUCP package ...
>does anybody have a UUCP package in which both uucp and uucico allow the user
>to retrieve files from a remote system ??
HERMES does this very well. You can use the 'uucp' command to write a
workfile-line for the uucico, which is already able to send the request-
command to the other side of the line. I use this weekly to get some index-
files from my host.
>Few days ago someone talked about a Hermes package , could some one give me
>his address so I can send him a disk ?
I already sent the package to someone in the U.S. to publish them on
c.b.a.s. You hopefully won't need to send the disk. Perhaps you might
send the shareware fee to the author (No, it isn't me and I haven't
seen him ever :-)).
>I'm kinda frustrated , I have the GNU-UUCP sources but cannot compile them !
>I'll send them in when sending the disk for Hermes
You should not try to compile the gnuucp sources, because they are even
badder than our GFA-cico. The gnuuio doesn't support windowed transactions,
so you would get very slow connections. Our 'cico' doesn't run under mint
or other environments, but all other things are done perfectly.
Bye.....Michael
--
/------------------------------------\
| Michael Kistenmacher / blackbox |
| 2000 Hamburg 61 / Schippelsweg 64 |
| West Germany / ++ 49 40 552 37 66 |
\------------------------------------/
------------------------------
Date: Mon, 4 Nov 91 13:54 MET
From: "Chris Evelo: MFAGKCHR@HMARL5 (BITNET)"
<MFAGKCHR%RULIMBURG.NL@pucc.PRINCETON.EDU>
Subject: HD backup
To: Info-Atari16@naucse.cse.nau.edu
Todd Drga asks:
>Are there any backup programs out there that can backup a HD directly to
>a Syqest 44 meg cart? I have an 89 meg HD that I'd like to back up with
>my Syuest drive. I have an ICD Advantage + Host adapter, if that makes
>a difference.
May be my partback program would be of use to you. Below is the readme file.
Note that partback does not use any tricks like Cheetah and the like.
But this might also be an advantage.
----------------------------------------------------------------------
PartBack v0.05
Partback is available from:
Chris Evelo
Op de Vey 54
NL-6165 CD Geleen
The Netherlands
Send $ 20,- or equivalent and you will receive the program on disk.
PartBack is a backup program. It makes full backups from one partition on to
another. This is especially useful if you can make the backup from a fixed
disk to a removable unit, like a Syquest unit.
Backups can be made directly from one root directory to another, or from one
partition to a folder on the other. In both cases the full directory structure
of the source partition is copied. If the backup is directed to a folder, the
folder will have the name of the source partition. If the target folder does
not exist it will be created. You can choose to backup more than one partition
to the same target partition. In this case it is highly advisable to select
"To Directory".
You can select that only newer files are copied. PartBack will use the GEMDOS
creation date and time to check what file is newer. With TOS 1.4 or higher you
can also choose to use the archive bit. If you select "Use Bit" PartBack will
check whether a file was backuped before. If you select "Set Bit" PartBack
will tell GEMDOS when a file was backuped. This way the file will not be
copied again during a subsequent run with "Use Bit" selected.
PartBack uses standard GEMDOS calls to find files and directories. This means
that it is very likely that you will run in to the so called 40 folder bug,
when you use TOS versions older than 1.4 without additional tools to enlarge
the buffer for directories. If you use FOLDERxxx it is advisable to use a
rather high value for xxx. Two times the amount of folders to be copied should
be the minimum.
After initiation PartBack searches the default path for a file called
partback.inf. This file can contain files, folders and filetypes that partback
should not copy. A sample configuration file is shown below. The first line
"#partback" is obligatory. Possible entries are #skipdir, #skipfile and
#skiptype. They may be given in any order. If you use skipdir the whole path
below a directory with the given name will not be copied.
#partback
#skipdir=clipbrd
#skipdir=trashdir
#skipfile=rubbish.txt
#skiptype=bak
#skiptype=log
Limitations: currently the maximum number of directories per partition is 400.
The maximum number of skipdirs is 20 and the maximum number of skipfiles and
skiptypes is 100. This limitation will be removed in a future version (as soon
as I or some registered user need it). There is no limit to the amount of
files to be copied. Error handling is minimal. PartBack will notice write
protected target files, and will notice a full target disk. That is about
all there is. Other errors will be taken care of when they are encountered.
------------------------------------------------------------------------------
Bug reports and comments to: Chris Evelo. MFAGKCHR@HMARL5.BITNET
PartBack was developed with GFA-Basic 3.50E D.
Disclaimer.
PartBack was tested in normal daily use. Errors may however occur.
I will not be responsible for any losses that may result from the use of the
program.
------------------------------
Date: 4 Nov 91 02:34:16 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rphroy!caen!u
florida!mailer.cc.fsu.edu!boyd@arizona.edu (Mickey Boyd)
Subject: Indus GTS-100 floppy drive
To: Info-Atari16@naucse.cse.nau.edu
Howdy,
I have a been offered a GTS-100 for a song. However, it (like its
brethren) does not seem to work quite right. When I connect it to my
Mega2, it not only refuses to format in twisted mode, it also somehow
prevents my internal from doing it! My questions are:
What exactly is wrong with this drive (ie what does it do wrong).
Is there any way I can disable or fix the "wrongness"?
I remember this thread from years past, but time has clouded my memory. I
want the drive to work with my system (obviously), be able to format out
to at least 82 tracks 10 sector/track, and be able to twist format. I assume
there is something non-standard with the Indus board in the drive, and
not the drive mech itself. Could it be an internal cabling problem? I would
not hesitate to rip it apart and fix it if I knew what needed tweeking, nor
would I care too much if the little digital track display was lost in the
process.
The drive mech inside is a Shugart SA310-16. Can anyone tell me if this
one will work ok with the ST (ie no media change problem)?
Related to this, is there any document which outlines the method of hooking
a generic 3.5" drive to the ST? I seem to remember that this only requires a
special cable. Could I hack the drive cable and connect it directly to the
mechanism, thus ignoring any Indus specific hardware?
Any information would be appreciated. Please email, and I will post a
summary if there is interest.
--
Mickey R. Boyd | "God is a comedian playing to an
FSU Computer Science | audience too afraid to laugh."
Technical Support Group |
email: boyd@nu.cs.fsu.edu | - Voltaire
------------------------------
Date: 4 Nov 91 11:40:36 GMT
From: mcsun!unido!sbsvax!lupus@uunet.uu.net (Markus Wolf)
Subject: PD or shareware Fortran Compiler out there
To: Info-Atari16@naucse.cse.nau.edu
Hi Folks,
is there a PD or shareware version of a FORTRAN77 Compiler out there in
netland. Please, post me a server.
Lupus
------------------------------
Date: 4 Nov 91 08:30:43 GMT
From: cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!mig@rutgers.rutgers.edu
(Meir I Green)
Subject: SIMPLE NETWORK!?
To: Info-Atari16@naucse.cse.nau.edu
Would it be possible to network a few PCs and Macs by connecting their
TX/Data and Rx/Data lines together and simply sending some simple
header information before each transmission? Would this essentially
be any different from any single-channel network? Would it simply be
a problem of impedance matching? In that case, I suppose that about 3
PCs should work with no special matching circuits. Is this what the
$25 network is? How about a simple TSR which would allow transparent file
operations using the serial port, or, perhaps, remote logins--OS/2 should
allow this already, I suppose!
Thanks.
Meir
* * * * * * ================== Internet mig@cunixb.cc.columbia.edu
* * * * * * * = Meir I. Green == or Internet mig@asteroids.cs.columbia.edu
* * * * * * ================== UUCP Bang! ...rutgers!columbia!cunixb!mig
* * * * * * * ================== Amateur Radio N2JPG@W2XO.PA.USA.NOAM
------------------------------
Date: 4 Nov 91 03:35:22 GMT
From: vax5.cit.cornell.edu!wwhy@cu-arpa.cs.cornell.edu
Subject: TT sound broken!
To: Info-Atari16@naucse.cse.nau.edu
I just recently bought a TT and I've had it for a couple weeks. For some
reason the sound no longer works. Nothing I do will make the sound come back
on. I've tried the control panel, I've tried every program that has sound
effects or music. Nothing works. I'm very upset. I've only had the thing
for a couple weeks and already it is broken! If anyone has had similar
problems and knows how to fix this please let me know, and if anyone from
Atari is listening, I'm beginning to lose my faith after spending tons of
money on a computer that isnt realiable.
Bill
------------------------------
Date: 4 Nov 91 00:55:35 GMT
From: noao!asuvax!cs.utexas.edu!milano!cactus.org!covert@arizona.edu (Richard
Covert)
Subject: Wants (What's!) happening?
To: Info-Atari16@naucse.cse.nau.edu
In article <3NOV199115015563@zeus.tamu.edu> jmm2948@zeus.tamu.edu (Jeffrey M.
Mayzurk) writes:
>(original text deleted)
>
>>
>>The Atari market is soo starved for good professional development tools
>>that they will buy products that no one others would even consider.
>>HyperLink with its poor design and lack of features, TC2 with its
>>German only docs, Lattice C 5 with its lack of source code debugger and
>>MAKE utility are just a few of the lousy tools that I have bought
>>for my ST.
>>
>>for me, the Mac is the only machine that makes sense. Heck, even the
>>great new Atari UNIX System V package is worthless to me. It doesn't
>>support a link to the TOS environment. Mac has too UNIX versions
>>available. an old AT&T System V Release 2 (which is admittedly an
>>old UNIX), and A new BSD 4.3 UNIX called MachTen. Both of these support
>>seemlessly the Mac apps, so you can run your Mac apps while inside
>>UNIX and X Windows. That is years beyond what Atari is capable of.
>>
>>So, that is why I am so flamed at Atari Corporation!!
>>--
>I am afraid that I have to agree with you. I have owned and used Atari
>computers since 1982, way back to the 400 days with 16k ram. Things have
>changed a lot. I have owned an ST since 1986, and I really do like the
>machines. Unfortunately, I just can't use a machine that isn't supported.
>I NEED software -- it's that simple. I hate to leave Atari, but I really
>have no choice. I'm not going to sell my machine -- it's still useful --
>but I am currently in the market for a Mac II. (blasphemy, I know...)
>
>However, I'm not flamed at Atari Corp. They did it to themselves, and
>noone else is to blame. Back in '86, they really had a good position in
>the market -- a fresh product with lots of potential, but they never
>developed it to it's full extent. If they had only advertised!
>
>Oh well.. I hope (by some miracle) things turn around, but I'm not holding
>my breath. The STe and TT have a lot of potential, but it's too late now
>for Atari to get any real support.
>
>Jeff Mayzurk
Lack of professional tools is a big reason why I think that the
ST/TT is a doomed marklet. Just to give another example, why did
Atari Corp fail so dismally with the CD ROM? Heck they announced a
product back in 1987. I remember going to my local Atari dealer
in Phoenix AZ and placing an order for one! I would have bought it
sight unseen in those days. But to this day you can't buy an Atari
CD ROM drive. As for the CD ROM software, I saw a notuce here
on USENET for 50 CD ROMs from NASA with hundreds of mewgabytes of
digitized photos from various space programs. None of these CD ROMs
are configured for the ST/TT. All come with software for the
PC and for the Mac platforms. Say what you want about the ST/TT
but it is rapidly becoming an obsolete non-supported platform
that is too expensive for me to justify further support of!!
Want more examples of peripherals too advanced for
the ST/TT? well, have the newest Digital Audio Tape backup systems?
There are several different makers of them for the Mac. None for the
ST/TT. Now that must be because no one would spend $1500.00 for
a peripheral for the ST/TT huh? Or what about those new 3.5"
optical read/write drisk drives. Available for the Mac, not for the
ST.
What about that new Hyperlink product being hawked as a HyperCard
clone. Well, the ads in ST INFORMER make it said really great, but
then you find out that HL is basically just a shell over dBMAn. The
released version 1.52 doesn't support sounds or even printing. So
whil;e it makes a nice platform to demo some limited ideas you can't
use it in a production environment. And yet HL is listed at $150.
Heck, the full Hypercard Deverloper's package sells for only $99.
So, the Atari HL product is 50% more expensive than HyperCard
but with much less capability!!
What about the fabled much praised German Turbo C? Well, it is now
renamed "Pure C", but it still is available only with German docs.
the Gribnif folks on GEnie admit that their "Pure C" will come
with German docs only. They site "legal reasons" (which are
unspecified on GEnie) for that. but the ST/TT market is starving
for decent tools that it will support even such products as German
documented only compilers!! And even then the ST version of
Turbo C is double or triple the cost of the PC version of Turbo C.
And the PC TC comes with English docs, and with USA support.
there are literally tens of hardware and software peripherals available
for the Mac that aren't for the ST/TT. As for the fantastic DTP packs
for the ST/TT, some maybe be as good as those for the Mac, but when
you add in all of the other Mac programs which aren't available for the
ST/TT then how can you justify the cost of a fully decked out TT? Or
even for a new Mega STe4?
For all of the above reasons, I class Atari Owners in the same
group as other Religous Fanatics!! You can not justify buying
an Atari product in rational terms, as it doesn't other the
same level of support as other platforms. But if you criticize
the ST/TT then the Atari Fanatics attack you!!
So don't buy an Atari on rational reasons, just buy it and enjoy
whatever software you can find for it!! And enjoy being one of the
few and brave Atari owners!! Join the Religion!!
--
Richard E. Covert covert@cactus.org
CACTUS ..!cs.utexas.edu!cactus.org!covert
------------------------------
Date: 4 Nov 91 08:06:37 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!snorkelwacker.mit
.edu!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!nuug!ifi.uio.no!jkr@arizona.ed
u (Johan Kristian Rosenvold)
Subject: Where is Happy Computer /Discovery ?
To: Info-Atari16@naucse.cse.nau.edu
Does anybody have happy computer's phone number or BBS number ?
(The producers of the discovery cartridge. European magazines
have stopped taking their ads. (For reasons I can understand)).
--
K. Rosenvold, jkr@ifi.uio.no Short signatures R QT.
------------------------------
End of Info-Atari16 Digest
******************************
