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 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/ 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/ 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/ 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 " - 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" 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 ******************************