moore@NCSC.ARPA (Moore) (09/09/86)
I have a couple of questions that I hope aren't too inane:
1) Is 1ST WORD free or not? I know it's currently shipped with the 520ST, but
can just anyone make themselves a copy of it? I've seen a place *selling*
the word processor for (I believe) $34.95. What gives?
2) What is the size of the memory area set aside for ACCessories? Or is there
a numerical limit on the number of accessories you can have at one time:
i.e., you can only have 6 desk accessories? A friend, who has TOS in ROM,
gets 380-odd K memory when he runs FREERAM with a PD CALCULATOR, CALENDAR,
PALETTE CHANGE, CONTROL PANEL, and INSTALL PRINTER as accessories. Is
*that* much memory required for the accessories? And, is there any way to
remove the INSTALL PRINTER to make room for another accessory? I got rid
of his VT52 emulator (he has FLASH!), but I couldn't find any ACC file for
INSTALL PRINTER.
Thanks for any help.
Jim Moore
NCSC
Panama City, FLfouts@AMES-NAS.ARPA (09/09/86)
1) There are two versions of 1ST WORD, the one that comes with your system and one called 1ST WORD PLUS. Neither of them is free, as I understand it. 1ST WORD is bundled with the system, but still belongs to Atari. 1ST WORD PLUS is (will be?) available at an extra cost. Since 1ST WORD comes with, the dealer should have been selling 1ST WORD PLUS, but. . .(?) 2) The limit is numeric. You can have no more than six desk accessories loaded at once. A gotcha is that some desk accessory files contain more than one desk accessory. This is true for both emulator.acc, which contains 'VT52' and 'configure rs232', and control.acc, which contains the 'control panel' and 'install printer'. To do away with 'install printer', you also have to do away with 'control panel'. There also appears to be no way to unload a loaded desk accessory, other than changing the .ACC to something and rebooting. Marty ----------
appelbau@topaz.RUTGERS.EDU (Marc L. Appelbaum) (09/11/86)
Both 1st word and the updated version should be available from your
local ATARI user group From what I understand both are free and
considered to be in the public domain.
--
Marc L. Appelbaum
Arpa: appelbau@topaz.RUTGERS.EDU
Uucp: ...{allegra| harvard| seismo| sri-iu| ut-sally}!topaz!appelbaucms@vlsvax1.UUCP (Chuck M. Sweeney) (09/11/86)
In article <5756@topaz.RUTGERS.EDU> appelbau@topaz.RUTGERS.EDU (Marc L. Appelbaum) writes: >Both 1st word and the updated version should be available from your >local ATARI user group From what I understand both are free and >considered to be in the public domain. ^^ ^^^ ^^^^^^ ^^^^^^ WRONG! GST owns First Word. Atari has (had) distribution rights to it and paid GST for every copy that went out with a system and every copy that a dealer gave away (every one with a label on it, anyway). It is *NOT* in the public domain. Notice the copyright notices on it and on the documentation when you print it. Neil Harris (Atari Marketing type) just spoke at our user's group meeting last Monday and discussed this issue, so this information is straight from the horse's mouth (so to speak - no offense, Neil). If you have further doubts, call Atari. Better yet, call GST, that'll cost more. Sweeney
Bicer.ES@XEROX.COM (09/12/86)
Has anyone compiled an Atari ST user group listing recently? Jack Bicer Bicer.ES@Xerox.COM
appelbau@topaz.RUTGERS.EDU (Marc L. Appelbaum) (09/15/86)
Both the Sept. & Oct. issue's of ANALOG include a user group list,
also a recent issue of ATARI EXPLORER had a list. You can also send a
SASE to Atari's user group coordinator and they'll send you a list.
--
Marc L. Appelbaum
Arpa: appelbau@topaz.RUTGERS.EDU
Uucp: ...{allegra| harvard| seismo| sri-iu| ut-sally}!topaz!appelbaurns@aicchi.UUCP (Schreiner) (09/19/86)
In article <5793@topaz.RUTGERS.EDU> appelbau@topaz.RUTGERS.EDU (Marc L. Appelbaum) writes: >Both the Sept. & Oct. issue's of ANALOG include a user group list, The premier issue of "COMPUTE!'s Atari ST" has a user group list on the disk that comes with it. -- Ron Schreiner ****** RS Consulting ...ihnp4!ronsat!rns ******** ___ P.O. Box 594 CSI 76515,3152 ****\ (__ Mundelein, Il (312) 949-4719 *** \_____) 60060-0594
olson@endor.harvard.edu (Eric Olson) (09/22/86)
References: OK, guys, I have a few questions for anyone to try to field about the ST: - Why "lazy" menus? I am constantly going for the top of a window and ending up in the menu bar. This causes a menu pull, and I have to go far away from where I'm trying to click just to get the thing to go away. Is there a way to turn this off (i.e., make it like the Mac?). - When I try to (for instance) grow a window, sometimes the ST doesn't realize I've pressed the mouse button until the pointer is no longer on the grow box. I pressed the button while it was on the grow box, though (I'm quite sure). It seems like the button is checked only about 4 times a second. Is there any way to speed this up? - If I edit the DESKTOP.INF file so that one of the windows displays only *.PRG files, it works until the window is closed and reopened. But the window display remains d:\. This isn't that important, but is there a way to fix it? - When I grow a window, the corner of the frame immediately jumps to the tip of the pointer, rather than tracking on the point where I pressed the mouse button. Is this avoidable? - The Resource Construction Set allows creation of Alerts, but there is no call to run them. The form_alert call creates the alert from a text string instead. Do I need to write my own routine to run an alert from a .RSC file? (Incidentally, the RCS has a bunch of Alerts in its .RSC file, but doesn't use them, and apparently uses form_alert). - Holding down the arrow in a scroll bar doesn't cause continuous scrolling (like on the Mac). WHY NOT? This seems like a very obvious thing to do. - Nothing I've seen except NeoChrome (which throws away the user interface standard altogether) uses the right mouse button. The documentation doesn't talk about it. In fact, I don't think GEM supports it. Good thing it's there, huh? - A large number of programs (for instance, GEM KERMIT) seem to look for their resource files (or something) on A:\. Since I have a hard disk, I'd really prefer they look on the current default drive. Also, everything seems to want to be at root. Subdirectories are virually useless on this machine. And don't create more than 40 of them (well, don't access more than 40 of them between boots). As far as I can tell, there's no way to tell the linker to look anywhere else for the .O files besides root. You can't append drive or directory specs to the files in the command line, and there's no option like -I in the preprocessor (CP68), which tells it to look "at a different drive" (but a directory spec worked there) for the #include files. Something tells me Atari didn't develop the software for this machine on itself. - Since the desktop is sooooo difficult to use (compared to, say, a Mac), it would be nice if there were a reasonable CLI. Is there? The one I have (version 0.1) doesn't have a single error message, and no documentation. So far I can change the directory, ls, and run programs. Is there a copy command? Pipes? I/O Redirection? If I had a good CLI I could just pretend I've gone back in time and I'm working on a PDP-8 again. How about a CLI that launches GEM applications in GEM mode? In case you're wondering, I'm not too happy with the software on the ST. It seems like a PC running GEM, not a small Mac. But, of course, it's not a PC (although why not, marketingwise, I'll never understand), it has a 68000. Running CP/M-68K (essentially). And GEM/VDI. And GEM/AES. MicroEmacs, of course, is great. But doen't use the mouse (it's not supposed to). Why isn't there an editor like Edit (for the Mac) available? I'm slightly sorry to vent all these complaints, but I see very little to praise. What is this machine good for? Anxiously awaiting any reply, I remain, Very annoyed at Atari. -Eric
oyster@uwmacc.UUCP (Vicarious Oyster) (09/23/86)
In article <233@husc6.HARVARD.EDU> olson@endor.UUCP (Eric Olson) writes: >OK, guys, I have a few questions for anyone to try to field about the ST: > >- Why "lazy" menus? ... (i.e., make it like the Mac?). Ask the lawyers at Apple, Corp. (Weren't you around for the Apple vs. DRI discussion?) Anyway, there is a utility in the latest issue of STart magazine which claims to be able to make the ST do stuff "like the Mac". >- Holding down the arrow in a scroll bar doesn't cause continuous scrolling >(like on the Mac). WHY NOT? This seems like a very obvious thing to do. (See above answer) >- Nothing I've seen except NeoChrome (which throws away the user interface >standard altogether) uses the right mouse button. The documentation doesn't >talk about it. In fact, I don't think GEM supports it. Good thing it's >there, huh? Is this a serious comment? I'll assume so and treat it as such. First off, there *is* a use for it that you can demonstrate for yourself, in the privacy of your own home. First, open two windows. Now, hold down the right mouse button. OK, double-click (left) on a file in the *non*-active window. Whaddya know! A use for the right mouse button! Even ignoring that small but useful use, do you think there's a possibility that A) people may want to use it in their own applications, and B) there just may be some things in life that you haven't yet encountered? Good thing it's there, huh? It's sorta like the cigarette lighter and ashtray in my car; I sure as hell won't use 'em, but I'm sure there are a few people who would, and I'm not going to complain to the dealer that they're there. >- A large number of programs (for instance, GEM KERMIT) seem to look for >their resource files (or something) on A:\. Since I have a hard disk, >I'd really prefer they look on the current default drive. Also, everything >seems to want to be at root. Subdirectories are virually useless on this >machine. And don't create more than 40 of them (well, don't access more >than 40 of them between boots). As far as I can tell, there's no way >to tell the linker to look anywhere else for the .O files besides root. >You can't append drive or directory specs to the files in the command line, >and there's no option like -I in the preprocessor (CP68), which tells >it to look "at a different drive" (but a directory spec worked there) for >the #include files. Something tells me Atari didn't develop the software >for this machine on itself. The above points are all good; they are either programming bugs or laziness, or the result of short-sighted operating system design. The linker and compiler I use are fairly good about allowing me to specify different directories for include files, source and object files, and library files. If you're the legitimate owner of a piece of software which you believe needs enhancements, write a letter to the company. I'm sure they'd be happy to make their product more attractive. Complaining to me won't get you far. The only thing I'd disagree with is the RSC files on the A:\ drive problem. All the programs I've seen, including GEM kermit, seem to look for the RSC file on the drive/folder from which the program is executing. > >- Since the desktop is sooooo difficult to use (compared to, say, a Mac), >it would be nice if there were a reasonable CLI. Is there? The one I have >(version 0.1) doesn't have a single error message, and no documentation. >So far I can change the directory, ls, and run programs. Is there a copy >command? Pipes? I/O Redirection? If I had a good CLI I could just pretend >I've gone back in time and I'm working on a PDP-8 again. How about a CLI >that launches GEM applications in GEM mode? Oh, the Mac again, eh? Well, I'll explain a little better. The fine, original-thinkers at Apple made the Macintosh in the image of a Xerox icon-based OS interface. The folks at DRI did the same. However, one of those companies was bigger, and had more money to spend on lawyers, so they made the other company make some small yet significant changes to their OS interface, so they wouldn't have the same "look and feel" as that original Xerox product. Life is strange, no? As far as CLI's go, are you complaining about a PD (i.e. free) program? If not, are you complaining to *us* because *you* wasted money on a product that doesn't deliver what *you* think it should? Anyway, Michael Beckmeyer's (sp?) Micro C Shell seems like a good, Unix-like CLI, complete with pipes, I/O redirection, a copy command, and a host of other Unix-like commands. Look into it, unless you don't want to have to pay a nominal fee (~$30) for a very useful program. And as for PDP 8's, go back in time and see how much your PDP 8 costs. I think too many detractors of reasonably-priced personal computers expect them to be MicroVaxen, not pc's. If you want the capabilities of a Vax buy a Vax. But don't complain when you buy a $500 machine and it can't outperform a Vax. >In case you're wondering, I'm not too happy with the software on the ST. >It seems like a PC running GEM, not a small Mac. But, of course, it's >not a PC (although why not, marketingwise, I'll never understand), it has >a 68000. Running CP/M-68K (essentially). And GEM/VDI. And GEM/AES. The ST is maturing, in both hardware and software. The Macintosh has a good 2-year lead on it. If you need a monochrome machine that has software now, and a user interface you like, why didn't you buy a Macintosh? >I'm slightly sorry to vent all these complaints, but I see very little to >praise. What is this machine good for? I dunno. Who would be dumb enough to buy a useless machine? -- - Joel Plutchak uucp: {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster ARPA: oyster@unix.macc.wisc.edu Warning: The above constitutes a large amount of opinion, with a smattering of fact thrown in for good measure.
tynor@gitpyr.UUCP (Steve Tynor) (09/25/86)
>>- Nothing I've seen except NeoChrome (which throws away the user interface >>standard altogether) uses the right mouse button. The documentation doesn't >>talk about it. In fact, I don't think GEM supports it. Good thing it's >>there, huh? > > Is this a serious comment? I'll assume so and treat it as such. > First off, there *is* a use for it that you can demonstrate for yourself, >in the privacy of your own home. First, open two windows. Now, hold down >the right mouse button. OK, double-click (left) on a file in the *non*-active >window. Whaddya know! A use for the right mouse button! Even ignoring >that small but useful use, do you think there's a possibility that A) people >may want to use it in their own applications, and B) there just may be some >things in life that you haven't yet encountered? Good thing it's there, huh? >It's sorta like the cigarette lighter and ashtray in my car; I sure as hell >won't use 'em, but I'm sure there are a few people who would, and I'm not >going to complain to the dealer that they're there. The fact is that the AES event library calls do *not* allow you to wait for a right mouse button event. In order to use the right mouse button, you must poll the mouse. Methinks the gentleman has a valid gripe. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Never put off until tomorrow what you can avoid altogether. Steve Tynor Georgia Instutute of Technology ...{akgua, allegra, amd, harpo, hplabs, ihnp4, masscomp, ut-ngp, rlgvax, sb1, uf-cgrl, unmvax, ut-sally} !gatech!gitpyr!tynor
demillo@uwmacc.UUCP (Rob DeMillo) (09/27/86)
In article <2285@gitpyr.UUCP> tynor@gitpyr.UUCP (Steve Tynor) writes: >>>- Nothing I've seen except NeoChrome (which throws away the user interface >>>standard altogether) uses the right mouse button. The documentation doesn't >>>talk about it. In fact, I don't think GEM supports it. Good thing it's >>>there, huh? >> >> Is this a serious comment? I'll assume so and treat it as such. >> First off, there *is* a use for it that you can demonstrate for yourself, >>in the privacy of your own home. First, open two windows. Now, hold down >>the right mouse button. OK, double-click (left) on a file in the *non*-active >>window. Whaddya know! A use for the right mouse button! Even ignoring >>that small but useful use, do you think there's a possibility that A) people >>may want to use it in their own applications, and B) there just may be some >>things in life that you haven't yet encountered? > >The fact is that the AES event library calls do *not* allow you to wait for >a right mouse button event. In order to use the right mouse button, you >must poll the mouse. Methinks the gentleman has a valid gripe. > > Steve Tynor Methinks you ought to RTFM... ev_breturn = evnt_button(ev_bclicks, ev_bmask, ev_bstate, &ev_bmx, &ev_bmy, &ev_button, &ev_bkstate); where ev_bmask: the mouse buttons to be taken into account when reading the mouse: 01 = left button 02 = right button 03 = both buttons I've tried it, it works...I think you should consider point (B) from the second poster... -- --- Rob DeMillo Madison Academic Computer Center usenet: {ihnp4,harvard,seismo,topaz,decvax}!uwvax!uwmacc!demillo ARPA: demillo@unix.macc.wisc.edu (now isn't that easier?) ---------------------------------------- "I am not so sure what you want me for! 'War Games' Either your machine is a - Crosby, Stills and Nash fool, or me..."
tynor@gitpyr.UUCP (Steve Tynor) (09/30/86)
In article <301@uwmacc.UUCP> demillo@uwmacc.UUCP (Rob DeMillo) writes: >In article <2285@gitpyr.UUCP> tynor@gitpyr.UUCP (Steve Tynor) writes: >>>>standard altogether) uses the right mouse button. The documentation doesn't >>>>talk about it. In fact, I don't think GEM supports it. Good thing it's >>>>there, huh? >> >>The fact is that the AES event library calls do *not* allow you to wait for >>a right mouse button event. In order to use the right mouse button, you >>must poll the mouse. Methinks the gentleman has a valid gripe. >> >Methinks you ought to RTFM... > > ev_breturn = evnt_button(ev_bclicks, ev_bmask, > ev_bstate, &ev_bmx, &ev_bmy, > &ev_button, &ev_bkstate); > > where ev_bmask: the mouse buttons to be taken into account > when reading the mouse: > 01 = left button > 02 = right button > 03 = both buttons My manual doesn't say anything about 03 = both buttons, but I have tried 02 for the right button with no success. I admit that I've been using evnt_multi, not evnt_button. Could this be why it's never worked for me? If so, I maintain that the gripe is valid. Most programs are going to have to wait for keystrokes and menu events as well as button events... If I'm wrong, I withdraw my remark... (BTW: what does the F stand for in RTFM?) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If the facts do not conform to the theory, they must be disposed of. Steve Tynor Georgia Instutute of Technology ...{akgua, allegra, amd, harpo, hplabs, ihnp4, masscomp, ut-ngp, rlgvax, sb1, uf-cgrl, unmvax, ut-sally} !gatech!gitpyr!tynor
tim@ism780c.UUCP (Tim Smith) (09/30/86)
In article <280@uwmacc.UUCP> oyster@uwmacc.UUCP (Vicarious Oyster) writes: > > Oh, the Mac again, eh? Well, I'll explain a little better. The fine, >original-thinkers at Apple made the Macintosh in the image of a Xerox >icon-based OS interface. The folks at DRI did the same. However, one of >those companies was bigger, and had more money to spend on lawyers, so >they made the other company make some small yet significant changes to >their OS interface, so they wouldn't have the same "look and feel" as that >original Xerox product. Life is strange, no? Isn't it interesting that Amiga has not had any problems with Apple? ( or have they and I just haven't heard about it? ). The point is that it is possible to make a reasonable user interface for a mouse based windowing system without copying the "look and feel" of the Mac. Why couldn't DRI go to the trouble of doing this? From what I have seen, it looks like Apple looked at the Xerox stuff as a source of ideas. DRI appears to have looked at Apple and tried to look as much like them as possible. There's a difference. -- What's the difference between a duck? Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 Delphi or GEnie: mnementh
ram@YALE.ARPA (Ashwin Ram) (10/01/86)
In article <233@husc6.HARVARD.EDU> olson@endor.UUCP (Eric Olson) writes: >OK, guys, I have a few questions for anyone to try to field about the ST: > >- Why "lazy" menus? ... (i.e., make it like the Mac?). Ask the lawyers at Apple, Corp. (Weren't you around for the Apple vs. DRI discussion?) Anyway, there is a utility in the latest issue of STart magazine which claims to be able to make the ST do stuff "like the Mac". >- Holding down the arrow in a scroll bar doesn't cause continuous scrolling >(like on the Mac). WHY NOT? This seems like a very obvious thing to do. (See above answer) Wait a minute. They couldn't make it look like the Mac, so they make it look *worse* than the Mac??? You lost me there. The Mac's not perfect (play with one for an hour and you'll see). For example, you could make the drop-down menus come down automatically when you move the cursor on them, then go away when you move the cursor off (rather than waiting for a mouse click). "Apple has tough lawyers" is no justification for sloppy software design. >In case you're wondering, I'm not too happy with the software on the ST. >It seems like a PC running GEM, not a small Mac. But, of course, it's >not a PC (although why not, marketingwise, I'll never understand), it has >a 68000. Running CP/M-68K (essentially). And GEM/VDI. And GEM/AES. >I'm slightly sorry to vent all these complaints, but I see very little to >praise. What is this machine good for? I dunno. Who would be dumb enough to buy a useless machine? - Joel Plutchak I think you have totally missed the point of Eric's message. I think what he was saying is that the Atari is a LOT of machine. It's *much* nicer than a PC, and it's *much* nicer than a Mac, "hardwarewise". So why don't they get their act together and design some good software? Personally, I like the machine; I just think it has tremendous potential for improvement. You can either sell a raw machine or an ergonomically designed product; looks like the Atari hit the left end of this spectrum. While we're on the subject, here's another design question I've been wondering about. The screen redraw algorithm seems to be completely brainwashed. Consider this: you have three windows open, say, on drives A, B, and D. You have only one physical drive, so it's doubling both as A and B. D is your ramdisk. Now you double-click on a file and go through the silly show/print/cancel dialog box to see it on the screen (why not just use a GEM window?). Now comes the fun part. The file ends, it tries redraws your screen. First it redraws the outline of the lowermost window (say, D). Now it makes you insert disk B in drive A, and redraws the outline of the B window. Next, you insert disk A in drive A, and it redraws the outline of the A window. Now it fills in the D window, and then the B window, and then the A window. Even without the disk change operation, this process takes several seconds, and results several rewrites of parts of your screen. Slow and annoying. There is NO reason to do this (our unmentionable competitor redraws the screen almost instantaneously). The OS doesn't check that you inserted the correct disk for B (i.e., the same disk it expected), nor does it care if you insert a different disk for B when you get down to using B again. So why does it need to read the disk (slow, slow) when it redraws the screen? If you really care about consistency of the window with the current disk in the drive (and it isn't obvious that you need to in all cases), it is easy to detect whether the user has ejected/reinserted a disk. In fact, you could easily update an open window automatically if the user changes a disk. These aren't flames or complaints or "why did I buy this machine?" rantings; I'm only suggesting that with a little bit of thought, Atari can improve its desktop and user interface considerably *without* running over the Mac's copyrights. Why isn't there a MOVE operation, only a COPY? Why can't you rename folders? Why is file renaming hidden away in SHOW INFO? Why only four windows? Why use such an immutably large font in the windows (with broad scroll bars), thereby making what is really a larger screen than the Macs have look like it has much less space on it? Why make us adjust the volume of the monitor *every* time you turn it on, rather than saving it in DESKTOP.INF? There are several things in their design that could do with some polishing. And then there are several things that they didn't even think of. How about using the right mouse button as a way of getting help on a particular menu item while it is lit? Or even the HELP key? Even the Mac doesn't do this. I have a million *constructive* ideas if anyone wants to listen, and I'm sure anyone who has used the Atari for more than a day has a million of his/her own. This isn't, of course, an issue of Atari vs. Mac. In fact, if they don't try to copy the Mac, they should be able to come up with something *better* than the Mac. (And then it'll be their turn to hire tough lawyers :-)). -- Ashwin. ARPA: Ram-Ashwin@yale UUCP: ...!yale!Ram-Ashwin BITNET: Ram@yalecs -------