Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 158
Info-Atari16 Digest Thu, 21 Mar 91 Volume 91 : Issue 158
Today's Topics:
Art/Drawing Program Wanted
Laser printer recommendation sought
Pre-modulator ST
Problem with demo disk on Atari ST
Standardized disk layout/folder names
standard practices (3 msgs)
ST Book specs
ST Disks & Sparcstation Drives
ST Pad specs (2 msgs)
ST Stuff FOR SALE : CHEAP
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: 20 Mar 91 14:59:22 GMT
From: aurs01!whitcomb@uunet.uu.net (Jonathan Whitcomb)
Subject: Art/Drawing Program Wanted
To: Info-Atari16@naucse.cse.nau.edu
I am interested in getting an art program for my ST. All I
have now is the Neochrome program that was bundled with my
ST back in 1986 (V0.5?).
I'd appreciate thoughts about and comparisons amoung commercial
and public domain art programs, STE and TT compatibility, prices
and availability.
Other considerations are whether the picture formats produced
may be imported into document processors and DTP packages, and
whether printer drivers are included.
Thanks.
**********************************************************************
Jonathan Whitcomb UUCP: <...!mcnc!aurgate!whitcomb>
(919) 850-6231 I'm not a software engineer,
Raleigh, NC but I play one on TV.
------------------------------
Date: 20 Mar 91 16:49:37 GMT
From: littlei!intelhf!watson!ajw@uunet.uu.net (Alan Waldock)
Subject: Laser printer recommendation sought
To: Info-Atari16@naucse.cse.nau.edu
This is a repost, as our news servers are up the creek AGAIN.
I'm looking to buy a laser printer, and would like to be able
to hook it not only to my 1040ST but also to an AT-class machine.
I need a postscript capability.
My budget starts getting a bit tight around the $3000 mark.
Does anybody have any strong recommendations and/or avoidables
they'd like to share? Email preferred - I'll summarize.
-- Alan Waldock, from but not on behalf of Intel Corporation
ajw@watson.hf.intel.com ...uunet!intelhf!watson!ajw
------------------------------
Date: Thu, 21 Mar 91 12:59 GMT
From: MIKE <JENKINSMJ%KIRK.VAX.ASTON.AC.UK@pucc.PRINCETON.EDU>
Subject: Pre-modulator ST
To: INFO-ATARI16@naucse.cse.nau.edu
I have a very ancient (1985) St with no built in modulator/disk drive/power
supply. I have a monitor which will accept a composite video input.
Inside my St
, there is a large empty space where the modulator would go. There are two sets
of holes through the P.c.b. labelled 1-10 and 12-14.I would like to know if one
of these pins contains composite video.
Another point. Is it alright to leave the shielding out ?! Is it there to
protect the St from the outside world, or vice-versa ?
Regards
Mike Jenkins [jenkinsmj@uk.ac.aston.spock]
------------------------------
Date: 21 Mar 91 11:49:10 GMT
From: wxh@lanl.gov (William Harvey)
Subject: Problem with demo disk on Atari ST
To: Info-Atari16@naucse.cse.nau.edu
I just got the Atari minix demo disk. When I try "mkfs /dev/hd8 16384"
I get:
No space on root device 1/0
Error: put_block couldn't write
Line 1 bewing processed when error detected.
If I try it again, there is a 10 sewcond pause, and then the same error.
However, a "ls -l" shows:
-rwxrwxrwx 1 root 16777216 Jan 1 00:07 hd8
When the system boots it has hd1 through hd5. Trying mkfs on one of those
gives errors too.
Trying mount on hd8 gives:
mount: Block device required.
1I think the problem is number 1.
1. Under GEM, I need a hard disk driver. I have a Micropolis with several
16M partitions. This is attached to an ICD Advantaghe Plus. Is a compatabile
driver loaded under minix? Can I load one with the demo disk?
2. mkfs in the accompanying manual show a -o option for systems other than
floppies. That doesn't work either.
Thanks for any help.
Billy Harvey wxh@lanl.gov
~:w
------------------------------
Date: 21 Mar 91 08:25:02 GMT
From: ucla-seas!crowe.seas.ucla.edu@locus.ucla.edu (Plinio Barbeito/)
Subject: Standardized disk layout/folder names
To: Info-Atari16@naucse.cse.nau.edu
Again, as long as we're on the subject of standards, how do people
feel about having some sort of disk layout standard, like Unix has
(i.e. the binaries are kept in /bin, system database files are kept in
/etc, user files are kept in /usr, manuals for programs are kept in
/usr/man, and so on).
Having a standard of a few common directories would mean that
programs could make assumptions about directory structure to allow
users that aren't expert enough to edit files or pathname lists or
just "don't know what the heck is going on" to get by with few
problems most of the time they use or install applications.
Installation scripts or programs could be distributed for each program
that would automatically take care of unpacking, putting the binary,
the manual file and help file(s) in standardized directories, adding a
line to the desktop.inf so that double clicking a data file starts the
application, and...(do you want to add anything?)
For GEM applications that require at most one resource file but no
other extra files, we might have one directory to put these (I call
it c:/gembin on my system) and store the doc files in say,
c:/usr/gemdoc so that they're only two mouse clicks away. Where to
keep the resource file? I'd put it in c:/rsc or out of the way in
c:/usr/gemrsc if possible, but some programs require the rsc file to be
around the prg file (or even worse, in the root directory).
For bigger GEM applications, some of these require an obnoxious
/itsfatname folder to be present. We may have no choice but to continue
this trend. I would prefer to put these folders in c:/gembin myself, or
under something like c:/wordproc or c:/apps. The day might come when a
novice user could install software on his hard disk by simply double
clicking on the standardly named install.prg (or install.sh, or whatever),
not having to know anything about GEM other than how to open "things" on
the desktop.
That reason alone (the continued sanity of non-quasi-experts in
the user base) is why I haven't been one of the many critics
complaining that Atari shouldn't have made the hard disk on the TT
a standard option (I feel justified in complaining about its price,
in Canada at least).
People might balk at the inconvenience of putting GEM applications
too many levels below the root directory. OK, maybe now it is,
but if we had a builtin desktop that allowed putting frequently
used executables on the desktop next to the file icons, this
wouldn't be a problem. Neodesk and probably some other
replacement desktops allow this, but forcing people to buy
something to be part of a standard is a great incentive not to
follow the standard. Put this one off, I guess.
Another thing to think about is the partitioning scheme, but that
may be too device dependent for us to agree on a standard (some people
may have 20M, others 200M). If we wanted to get around that, looks
like mounting one partition from another is the nicest solution (so
that /bin on c: is actually linked to the root of d:, for example).
When TOS will allow this is a good question. An alternate file
system running under MiNT seems like our nearest chance for this.
So, to sum up, how about these preliminary choices:
What Where When
-------- ------ ----
'Text' Binaries c:/bin
Small GEM Binaries c:/gembin
Large GEM Binaries (In the application's folder) now
c:/gembin/<appname> future
RSC files (no choice) now
c:/usr/gemrsc future
'Text' program Doc files c:/usr/man
Small GEM App doc files c:/usr/gemdoc
Large GEM App doc files (In the application's folder) now
c:/usr/gemdoc/<appname> future
'Text' program help files c:/usr/man/extra ?
Large GEM App Help files (In the application's folder) now
Large GEM App Help files c:/usr/gemhelp/<appname> future
System database files c:/etc
Fonts c:/gemsys or whatever now
c:/etc/fonts future
desktop.inf file / now
/etc/desktop.inf future
Accessories to load / now
check /, then /usr/accs future
pre-GEM programs to load /auto now
check /auto, then /usr/auto future
Well, post up what y'all think. Look out -- if this gets far enough
maybe Atari will include some of our ideas for this on its new TT
disks, or even ask official developers to abide by it. It will
be worth it even if it gets them to think in that direction.
plin
--
----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu
I don't think, I'm crazy.
------------------------------
Date: 21 Mar 91 05:20:42 GMT
From: ucla-seas!crowe!plinio@locus.ucla.edu (Plinio Barbeito)
Subject: standard practices
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William
Rosencranz) writes:
>
>while on the subject of standards, can i throw in my 2 cents on another
>plead for consistency?
>
>it would be really nice if unix-like programs on the ST (or anywhere, for
>that matter) would include the following command line switches:
>
> -debug to turn on internal debugging, if any
In a beta release of something, but for a bugless program?
> -help to print a usage synopsis
It would be nice to standardize this. Do people prefer sticking to
the cryptic (but quick to type and group) single-letter options names,
and typing the command without arguments to get usage info, or to chuck
that pseudo-standard and start using descriptive tokens?
> -version to print current program version
> -changes to print major changes since last rev (or indicate
> that this is first rev)
[Code deleted...]
>does this sound reasonable? i have adopted this myself for both unix and
>TOS. i just wish P1003.2 would say something about this...
Think what you are doing! You are trying to make Unix user-friendly,
and force programmers to document their code AT THE SAME TIME. One of
these would be unreasonable enough :-)
(back to reality)
Anyway, my two cents is that it's a tad too baroque. Maybe the -help
or -version options would be useful, but it seems like not all
applications would benefit from the clutter of informing the user that
he can use an option to see the debugging output, for example. In the
interest of speed and size, debugging output should go by the wayside
in most cases, IMHO.
To sum things up, I think the usefulness of your suggestion will
depend on the specific application in mind ("tiny" versus "big enough
to have an option called -verbose").
plin
--
----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu
I don't think, I'm crazy.
------------------------------
Date: 21 Mar 91 06:58:17 GMT
From:
noao!asuvax!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!sun-barr!newsto
p!texsun!convex!rosenkra@arizona.edu (William Rosencranz)
Subject: standard practices
To: Info-Atari16@naucse.cse.nau.edu
[ after re-reading my response, i should mention this is not any sort of
personnal attack. no offense intended. i just like to debate :-) ]
In article <324@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes:
>In <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William Rosencranz)
writes:
>>it would be really nice if unix-like programs on the ST (or anywhere, for
~~~~~~~~~~~~~~~~~~
i was not refering to gem stuff. and nor would i assume people who prefer
gem are "_potentially_ dim wits". to each his own...
>-debug - Very rarely used, so should be #IFDEFed out in releaase.
i use it alot. and it can often help users who just want to see what goes
on behind the scenes (i.e. seeking knowledge not found in a manpage) or
are trying to find out why the command is not working the way they expect.
i leave in debug stuff, regardless how much larger it makes the code,
especially in large, complicated codes (like nroff). i am thinking about
saving MY time, not the computer's.
>-help - No way! I MUCH prefer "man <command>" - and again, save on program
>size.
the "save on program size" argument was fine in the days of < 64k memory
and 160k floppies. this is 1991 and we can get megabytes for real cheap
these days. i think you should start thinking about *your* time and not
a couple of dollars saved on disk/memory. i am talking about less than
1k for all this, text+data. 1k out of 4 MB memory is nothing. 1k * 100
programs out of 60 MB (or even 20MB) of disk is nothing. less than 2
spectrum or 3 degas pictures, to put it in perspective.
>-changes - No, stick it in the manual.
often the manual does not match the program. putting a few lines out to
the screen does not hurt here. i'd rather do:
gcc -changes
than wade thru endless readme (or worse: source) files, if they even exist!
>See. Standards only work if they are inarguably beneficial.
i think u are argumentative just for the sake of argument...
all these things ARE beneficial. tell me, just who does it hurt? if u don't
want to type "cmd -help", so don't. but lots of times i just plain forget
lesser used options. like on (my) cc(1) which has a zillion options.
or are u suggesting that we limit functionality to make use easier?
doing "cc -help" and getting the info in a very terse, concise way is
much faster than using man and wading thru pages of docs. i work mostly
from home at 2400 baud. and believe me, reading man pages is no great joy.
having a "-help" option in no way hurts my (sizable) ego. in fact, just
the opposite: i would call the programmer considerate for not making me
try to remember every single scrap of information without openning a book,
electronic or otherwise.
>Personally, I write more GEM stuff than TOS stuff, and in THAT CASE, "help",
> "version"
>and "changes" are good things to include - because the average GEM user is
>_potentially_
>a dim wit - so it goes to make the program more User Friendly. People who use
>command lines are used to using "man" or just "more"ing the documentation.
boy, i sure hope you are not trying to sell your codes, after demeaning
your potential customers :-)
you are defeating your own argument: making code user friendly, even for
(or ESPECIALLY for) experienced users is why we have computers in the first
place. i'd rather the computer be my slave than visa versa.
i have been using command lines for over 15 years. i have been using "man"
for 7 years and NOS equivilents long before that. believe me, i am very
used to it. before that i used cards and lugged around pounds of paper for
my "man" command (let my fingers to the walking :-). but i also am keenly
aware of what makes people productive programmers and users. and not having
to stop and look something up is of great value to me, at least. if i can't
remember the switch on make(1) to print out the internal macros (is it "-m"
for "macro" or is it "-p" for "print" or is it "-z" because it is unix :-),
i'd rather, in 1.5 seconds, do:
% make -help
usage: make [options] [definitions] [targets]
options: -i ignore error codes
-s silent
-r no built-in rules
-n no execute mode
-t touch target files
-q question
-p print out macros
-d debug mode
-f file alternate makefile (searches for "makefile"
then "Makefile")
%
about 275 bytes data, and about everything an experience user needs to
know, though adding environment variable info is also helpful. self
documenting code is the best, IMHO.
and see, make DOES have a debug option! not #ifdef'd (at least alliant's
make the closest *MANUAL* i had available :-)... incidently it took 25
seconds to find it in paper manual (another 30 sec to find the manual).
"man make" would take about the same, maybe somewhat faster, maybe slower,
depending on how many times "macro" appeared befor your PAGER's /string
search found -p (i use less). or do i have to remember the propper
search string, too? i am not blessed with a photographic memory. with
a "-help" option, there is only one thing to remember: use -help for
a command synopsis. i would wager that the average programmer has to
remember millions of rules and facts. my goal is to try and minimize
this so that he can concentrate on creative programming and deductions
rather than remembering still more rules and facts.
anyway, thanx for the input. i am not going to stop doing this in my
programs which i post. i was just hoping that others would start doing it
in theirs. since i post source, you are free to remove all this seemingly
wasted space :-)
question: if posix 1003.2 had said something like this, would u still
disfavor it? just curious...
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP:
Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
------------------------------
Date: 21 Mar 91 07:10:29 GMT
From:
noao!asuvax!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!sun-barr!new
stop!texsun!convex!rosenkra@arizona.edu (William Rosencranz)
Subject: standard practices
To: Info-Atari16@naucse.cse.nau.edu
In article <2231@lee.SEAS.UCLA.EDU> plinio@crowe.seas.ucla.edu (Plinio Barbeito)
writes:
>In article <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William
Rosencranz) writes:
>> -debug to turn on internal debugging, if any
>
>In a beta release of something, but for a bugless program?
i never saw one :-). what is a "bugless program"?
>> -help to print a usage synopsis
>It would be nice to standardize this. Do people prefer sticking to
>the cryptic (but quick to type and group) single-letter options names,
i say stick to POSIX, whatever it may be, no matter how cryptic. at least
you would potentially only have to learn it once. i think few people
would be interested in *removing* what they expect in favor of tokens.
however, *adding* tokens (not really what i was thinking, but a reasonable
idea for novices) is fine.
>and typing the command without arguments to get usage info, or to chuck
not all commands can be typed without args. stdin is usually inferred
as source of input.
>that pseudo-standard and start using descriptive tokens?
don't chuck anything (just as i was gettin used to unix after 6-7 years :-)
>Think what you are doing! You are trying to make Unix user-friendly,
>and force programmers to document their code AT THE SAME TIME. One of
>these would be unreasonable enough :-)
yikes! did i really say that? infinite and humblest apologies!!!! :-)
>Anyway, my two cents is that it's a tad too baroque. Maybe the -help
>or -version options would be useful, but it seems like not all
>applications would benefit from the clutter of informing the user that
>he can use an option to see the debugging output, for example. In the
>interest of speed and size, debugging output should go by the wayside
>in most cases, IMHO.
ok, so skip the debug, tho i really think it can be valuable in debugging
user data errors, believe it or not, if you do the debug with that in
mind. the alternative is...what IS the alternative? proofread 100k of
data looking for a typo? i HOPE not...
>To sum things up, I think the usefulness of your suggestion will
>depend on the specific application in mind ("tiny" versus "big enough
>to have an option called -verbose").
no. these are additional thinks which you can count on to exist in all
unix-like commands. it should be implicit. and not get in the way. i
think "cmd -help" does not get in the way, is very descriptive, easy
to remember, etc.
>plin
>--
>----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu
>I don't think, I'm crazy.
no, you're not crazy...
-bill
rosenkra@convex.com
(i am...)
--
Bill Rosenkranz |UUCP:
Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
------------------------------
Date: 18 Mar 91 16:06:23 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!news-serv
er.csri.toronto.edu!torsqnt!geac!maccs!johns@arizona.edu (Conan the Barbarian)
Subject: ST Book specs
To: Info-Atari16@naucse.cse.nau.edu
ST BOOK
--------------------------------------------------------------------------
CPU: 68000 at 8MHz
RAM: 1MB and 4MB versions
ROM: 512KB
Other: PSG Sound
Real time clock
low power control circuitry
Internal HD 20MB, 40MB or 60MB versions
Internal optional FAX/Modem
External FDD (optional)
Battery:7 NICADS in pack, or 8AA Alkalines, 2 lithium backup cells.
Size: A4 Footprint, 34mm thick
LCD: 640 x 400 STN, no backlighting at the moment.
Connectors:
MIDI 2 x 5 Minipin
RS232 1 x 9 pin
Parallel DB25
Power 3 pin
DMA 28 pin Micro-D
Keyboard 10 pin
Expansion: 120 pin connector, WREN expansion compatible.
Keyboard: 84/85 keys compatible with STe and TT computers with built
in numeric keypad accessed using the FUJI key.
Mouse: fitted pressure sensitive compatible with Atari mouse
Options: two RAM versions 1MB or 4MB
Software:
TOS with additional built in features and applications.
--------------------------------------------------------------------------
--
John Schmitt
johns@maccs.dcss.mcmaster.ca
!unet!utai!utgpu!maccs!johns
------------------------------
Date: 21 Mar 91 06:55:37 GMT
From: noao!asuvax!ncar!gatech!prism!mailer.cc.fsu.edu!nu!boyd@arizona.edu
(Mickey Boyd)
Subject: ST Disks & Sparcstation Drives
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Mar20.193859.11943@m.cs.uiuc.edu>, totty@flute.cs.uiuc.edu
(Brian Totty) writes:
> Specifically, I want to read files from a double sided disk onto
> my Sparc and then transfer them to my ST hard disk via modem (I
> only have a single-sided floppy).
Hmm, if you already have it on a DSDD disk, why not just transfer it on a
PC to a DSSD disk (by formatting using "format x: /t:40 /n:9"). If you
still want mtools, you should ftp it from 129.217.64.63. All I had to
do to compile it was to add a "#define sparc" somewhere, the docs tell it
all. Email if you have questions.
--
---------------------------------+-------------------------------------
Mickey R. Boyd | "It's amazing how much growing up
FSU Computer Science | resembles being too tired."
Technical Support Group |
email: boyd@fsucs.cs.fsu.edu | - Heinlein
---------------------------------+-------------------------------------
------------------------------
Date: 18 Mar 91 16:08:32 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!news-serv
er.csri.toronto.edu!torsqnt!geac!maccs!johns@arizona.edu (Conan the Barbarian)
Subject: ST Pad specs
To: Info-Atari16@naucse.cse.nau.edu
ST PAD
--------------------------------------------------------------------------
The ST Pad is a notepad version of the Atari STe computer. It is
fully ST compatible, and will run any software which is written
to work in the 640 x 400 monochrome mode.
The ST Pad weighs 3 pounds and has an A4 size footprint. There is
no keyboard, mouse or floppy drive. The entire user interface is
based around a pen device. With the pen you can draw on the touch
sesitive LCD as if it were a piece of paper. The ST Pad will
recognise your handwriting and written gestures removing the need
for a either a keyboard or mouse.
Instead of a mechanical floppy drive the machine uses two silicon
drive slots for removable media. The slots can take RAM or ROM
cards for data storage or application software. Each slot can
accomodate up to four MB of data.
The hardware is designed to radically reduce power consumption. This
has been achieved with some innovative design techniques resulting
in a battery life of over ten hours.
One of the most important new features is a suspend and resume mode.
This allows the user to put the ST Pad into a standby mode and then
resume work later at exactly where he or she left off. In standby
mode the the batteries can last several months without losing data.
CPU: 68000 at 8MHz
RAM: 1MB and 4MB versions
ROM: 512KB
Other: PSG Sound
Real time clock
low power control circuitry
Pseudo static ram
External FDD (optional)
Size: A4 Footprint, 36mm thick
LCD: 640 x 400 STN, no backlighting at the moment.
Stylus: Wired stylus with two buttons L/R Mouse functions)
Connectors:
MIDI 2 x 5 Minipin
RS232 1 x 9 pin
Parallel DB25
Power 3 pin
DMA 28 pin Micro-D
Keyboard RJ11, compatible with the Mega ST
JEIDA cards 2 slots, 68 pin
Stylus 4 pin MiniDIN
Expansion: 120 pin connector, WREN expansion compatible.
External expansion:
Address bus, Data bus, interrupts, compatible with WREN, supports
WREN compatible locking screws on the side of the unit as well as
underneath.
Software:
TOS with additional stylus features including mouse emulation and
handwriting recognition.
--------------------------------------------------------------------------
--
John Schmitt
johns@maccs.dcss.mcmaster.ca
!unet!utai!utgpu!maccs!johns
------------------------------
Date: 21 Mar 91 08:01:26 GMT
From: ucdavis!csusac!csuchico.edu!ekrimen@ucbvax.berkeley.edu (Ed Krimen)
Subject: ST Pad specs
To: Info-Atari16@naucse.cse.nau.edu
johns@maccs.dcss.mcmaster.ca (Conan the Barbarian) writes:
- TOS with additional stylus features including mouse emulation and
- handwriting recognition.
I don't know, but for some reason 'TOS with...handwriting recognition'
doesn't seem to jive, if you know what I mean. :~)
Thanks for posting the information. May I ask where you found it? I
just like to know the sources of these things. :~)
--
Ed Krimen ...............................................
||| Video Production Major, California State University, Chico
||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661
/ | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0
------------------------------
Date: Wed, 20 Mar 91 22:32 EST
From: "Scott P Leslie"
<UNCSPL%UNC.BITNET@ncsuvm.ncsu.edu>
Subject: ST Stuff FOR SALE : CHEAP
To: Info-Atari16@naucse.cse.nau.edu
-=-=-=-=-=-=-=- ST Stuff FOR SALE =-=-=-=-=-=-=-=-
ST Color Monitor : $150 or best offer (must go soon)
ST External Single Sided Disk Drive : $30 (or BO)
ST MotherBoard w/ 1MEG : $BEST OFFER$
(great for hardware hacks)
-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-====-=-=-=-=-=-=-=-=-=-
No offer will be overlooked!!!!!!!
-=-=-
Send mail to :
leslie@cs.unc.edu
or
call (919) 932-9963 after 5:00pm
------------------------------
End of Info-Atari16 Digest
******************************
