mykes@zorch.SF-Bay.ORG (Mike Schwartz) (02/01/91)
In article <18018@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <42828@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >>In article <1991Jan20.042633.16661@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > >>>I sure wish I could put 64MB of RAM on my AT&T 6300 like I can on my Amiga. > >>(Just curious, but does anyone out there have that much RAM installed?) > >I set up an A3000 with 16MB of motherboard Fast RAM, 2MB of Chip RAM, 32MB >of Zorro III expansion RAM, and 2MB of Zorro II expansion RAM just for kicks >once. I didn't really have anything useful to do with all that memory, so I >gave back most of the 4MB DRAMs, and I'm now back to the basic 10MB setup >(8MB Fast, 2MB Chip) that I've found I can't use up in anything I normally do >with my system. > > >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "What works for me might work for you" -Jimmy Buffett I am definately crampped in 4MB or RAM, because I would like to make more "resident" programs (i.e. ARexx servers). I don't want to see these programs limit themselves to a small (i.e. < 1MB) memory use, otherwise you can get them all thrashing around on the disk from time to time. I often wonder what it would be like to have 64MB, but I also don't see the need for it - YET. When 24-bit graphics are standard issue on the Amiga, it might make sense to use a lot of RAM for layers (window buffers). It might also be useful to keep a bunch of digitized sound and video samples in RAM at once, too. Last time I talked to Sam Dicker (author of Audio.device), he was working at Apple, using their Cray to see what kind of user applications could make use of such a powerful machine. They figure that someday, a machine as powerful as the Cray will be on everybody's desk. For now, the Amiga is the next best choice. So what would you do with all that RAM? You could have a lot of large lookup tables, a huge disk cache, and perhaps some video/audio applications might require a lot of RAM. Oh, yeah, then you might be able to run Unix on it (until a couple of years from now it still won't be enough RAM).
baxter_a@wehi.dn.mu.oz (06/26/91)
In article <1991Jun24.230638.7865@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: > No, the design isn't inferior, it's the implementation that is. > The Amiga clipboard.device is very robust and can take any type of > data. If developers don't support it, that doesn't make the clipboard.device > itself inferior, it makes the implementation inferior in practice. > The clipboard is buggier than a dingo in a shanty town. Just try using it in low memory conditions with CLIPS: assigned to a disk (better not make it your hard disk). > Your example is flawed. The clipboard.device has been in the OS > since the beginning and nothing had to be rewritten. A more accurate example > would be if Apple made some interface routines for the AMD and developers > didn't use it. That doesn't make the AMD itself inferior to the Amiga > chipset, it makes the implementation of it's use inferior. > It hasn't really. C= didn't write the parsing routines. Their _own_ programs didn't support it. > Sheesh, what a nitpick. It takes about 12 lines of code to do a > Cut() to the clipboard. If a developer is so lazy that he can't > implement a very easy routine like this than he needs to pack up his > computer and head for the IBM. Apple's problem is they like to put > EVERYTHING in the OS. Hell, they may as well incorperate Microsoft > Word into the OS with a single function cal{, void Word(char *path); > Just so you know, 2.0's iffparse.library includes 2 calls, > OpenClipBoard and CloseClipBoard which aid the programmer who is too lazy > to set up an IORequest. > Crap. The C= bits and pieces from the Fish disks are much greater than 12 lines, and then you need to get the data into some sort of interchange format. > So we have concluded > 1) The Amiga clipboard.device is totally open in design and supports > the same amount of data that the Mac's does. (contrary to > Marc's uninformed statement that it supports ASCII only) It is used for ascii only. Name one graphics program that cuts to clipboard. (I'd really like to know). > 2) The clipboard.device never took off because Amiga developers choose > not to support the clipboard (and some of them don't even support the > Amiga OS, e.g. bypass it and go to the hardware, etc) There is nothing > Commodore can do about this, the users must demand an end to this > and not buy products that break the rules. > C= didn't support it. Writing for it is a _real_ pain. Especially debugging, when there isn't anything to view your clips with. > When you talk about the Amiga's clipboard, you must distinguish between > the clipboard _itself_ and how developers choose to use it. > And you must distinguish what C= could do with it from what they have. Regards Alan
lrg7030@uxa.cso.uiuc.edu (Loren J. Rittle) (06/27/91)
In article <1991Jun26.122255.24634@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >It is used for ascii only. Name one graphics program that cuts to >clipboard. (I'd really like to know). Snap v1.61 does! ProVector reads and writes DR2D (a 2D structured drawing IFF format) clips from/to the clipboard. >C= didn't support it. Writing for it is a _real_ pain. Especially >debugging, when there isn't anything to view your clips with. You are right! It *was* a pain, iffparse.library makes this a joy, now. >Regards Alan Loren J. Rittle -- ``NewTek stated that the Toaster *would* *not* be made to directly support the Mac, at this point Sculley stormed out of the booth...'' --- A scene at the recent MacExpo. Gee, you wouldn't think that an Apple Exec would be so worried about one little Amiga device... Loren J. Rittle l-rittle@uiuc.edu
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/27/91)
In article <1991Jun26.122255.24634@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >In article <1991Jun24.230638.7865@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >> No, the design isn't inferior, it's the implementation that is. >> The Amiga clipboard.device is very robust and can take any type of >> data. If developers don't support it, that doesn't make the clipboard.device >> itself inferior, it makes the implementation inferior in practice. >> > >The clipboard is buggier than a dingo in a shanty town. Just try using >it in low memory conditions with CLIPS: assigned to a disk (better not >make it your hard disk). The whole OS has always had problems in low-memory conditions, this has been fixed in 2.0. It's not a problem local to the clipboard. In 1.3 try eating up almost all memory, then get intuition to put up a few requesters..boom guru. (usually FreeListCorrupt) >> Your example is flawed. The clipboard.device has been in the OS >> since the beginning and nothing had to be rewritten. A more accurate example >> would be if Apple made some interface routines for the AMD and developers >> didn't use it. That doesn't make the AMD itself inferior to the Amiga >> chipset, it makes the implementation of it's use inferior. >> > >It hasn't really. C= didn't write the parsing routines. Their _own_ >programs didn't support it. The Notepad does. >> Sheesh, what a nitpick. It takes about 12 lines of code to do a >> Cut() to the clipboard. If a developer is so lazy that he can't >> implement a very easy routine like this than he needs to pack up his >> computer and head for the IBM. Apple's problem is they like to put >> EVERYTHING in the OS. Hell, they may as well incorperate Microsoft >> Word into the OS with a single function cal{, void Word(char *path); >> Just so you know, 2.0's iffparse.library includes 2 calls, >> OpenClipBoard and CloseClipBoard which aid the programmer who is too lazy >> to set up an IORequest. >> > >Crap. The C= bits and pieces from the Fish disks are much greater than >12 lines, and then you need to get the data into some sort of >interchange format. I was estimating the amount of code needed to set up an IORequest. Converting it to a format is different, that's what 2.0 IFFParse is for. > >> So we have concluded >> 1) The Amiga clipboard.device is totally open in design and supports >> the same amount of data that the Mac's does. (contrary to >> Marc's uninformed statement that it supports ASCII only) > >It is used for ascii only. Name one graphics program that cuts to >clipboard. (I'd really like to know). Snap. >> 2) The clipboard.device never took off because Amiga developers choose >> not to support the clipboard (and some of them don't even support the >> Amiga OS, e.g. bypass it and go to the hardware, etc) There is nothing >> Commodore can do about this, the users must demand an end to this >> and not buy products that break the rules. >> > >C= didn't support it. Writing for it is a _real_ pain. Especially >debugging, when there isn't anything to view your clips with. Try using notepad. > >> When you talk about the Amiga's clipboard, you must distinguish between >> the clipboard _itself_ and how developers choose to use it. >> > >And you must distinguish what C= could do with it from what they have. Try looking at 2.0. >Regards Alan -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
andy@cbmvax.commodore.com (Andy Finkel) (06/27/91)
In article <1991Jun26.122255.24634@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >In article <1991Jun24.230638.7865@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >The clipboard is buggier than a dingo in a shanty town. Just try using >it in low memory conditions with CLIPS: assigned to a disk (better not >make it your hard disk). It has a bug in low memory, true. The bug was fixed for 2.0. Leaping from one bug to a shanty town is a huge leap; perhaps you should use a smaller dingo next time. >It hasn't really. C= didn't write the parsing routines. Their _own_ >programs didn't support it. The format for the clipboard is IFF. C= has always made an IFF code disk available through CATS (and I believe, as a Fish disk as well) For 2.0, we have included a new library (iffparse.library) which should make it easier to use the clipboard. >Crap. The C= bits and pieces from the Fish disks are much greater than >12 lines, and then you need to get the data into some sort of >interchange format. True; but all Amiga graphics programs already contain the code to do this conversion, as the standard Amiga interchange file format is (surprise) the same format the clipboard expects. >> So we have concluded >> 1) The Amiga clipboard.device is totally open in design and supports >> the same amount of data that the Mac's does. (contrary to >> Marc's uninformed statement that it supports ASCII only) > >It is used for ascii only. Name one graphics program that cuts to >clipboard. (I'd really like to know). If you go way back, the Graphicraft program from the early Amiga days uses the clipboard. In fact, several of the programs that C-A paid for in the early days use the clipboard. There are other programs, of course. >C= didn't support it. Writing for it is a _real_ pain. Especially >debugging, when there isn't anything to view your clips with. It does take a bit of effort to learn to use any Amiga device. FYI, if you ever looked at the files created in CLIPS: you might realize that you can type or display those files, if you choose. When spooled to disk they are just iff files, after all. >Regards Alan andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "2.0 is not the answer. 2.0 is the question. Yes is the answer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
galetti@uservx.afwl.af.mil (06/27/91)
In article <1991Jun25.075911.635@ncsu.edu>, kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >> Personally, it really irks me that the Toaster will >>be marketed (possibly for the Mac) using Amiga innards, >>with the Amiga getting no credit. Is it legal to construct >>a commercial product (i.e. a stand-alone Toaster) using >>another company's (Commodore's) designs? > > Sure. "Parts is parts" :-) There are cash registers which use PCs as guts, > kiosks with Amigas, and tons of gizmos which use either CoCo or C64 boards. > None of them power up and say "Hey I'm really a XX machine in here!" :-) > > And often these things are built using cutdown systems bought directly from > the computer maker, which I believe someone said is also the case for > the Mac/Toaster unit. > >>It seems like some kind of licensing infringement to me. > > I suppose if you put your own label on the computer and sold it as a > computer, you might... ummm.. actually that's probably okay too. > Any lawyers around here, btw? cheers - kev <kdarling@catt.ncsu.edu> Well, I'm NOT a lawyer (thank God!) but I used to work for a company that did exactly what you're saying. Of course, the real manufacturer of the computer allowed the company I worked for to do this. It helped to boost sales of their computers. -- ___________________________________________________________________________ / Ralph Galetti Internet: galetti@uservx.afwl.af.mil \ | PL/LITT Interests: computers, music, computers | | Kirtland AFB, NM 87117-6008 and music, golf, sleep. | \__"No, they couldn't actually prove that it was HIS vomit" - Nigel Tufnel__/
lron@easy.lrcd.com (Dwight Hubbard) (06/27/91)
In article <1991Jun26.225018.18846@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <1991Jun26.122255.24634@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >>In article <1991Jun24.230638.7865@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >>It hasn't really. C= didn't write the parsing routines. Their _own_ >>programs didn't support it. > > The Notepad does. IconEdit does as well. >>It is used for ascii only. Name one graphics program that cuts to >>clipboard. (I'd really like to know). > > Snap. IconEdit as well, it can even Paste from the clipboard. >>C= didn't support it. Writing for it is a _real_ pain. Especially >>debugging, when there isn't anything to view your clips with. > > Try using notepad. Or AZ, IconEdit. There are some others out there as well. >>And you must distinguish what C= could do with it from what they have. > > Try looking at 2.0. Yep, under 2.0 any program can support cut and paste by opening the right kind of console window. -- ---------------------------------------------------------------------- -Dwight Hubbard INTERNET: lron@easy.lrcd.com - -Kaneohe, Hawaii USENET : ...!uunet!easy!lron - - BIX : lron - ----------------------------------------------------------------------
es1@cunixb.cc.columbia.edu (Ethan Solomita) (06/28/91)
In article <22717@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: >In article <1991Jun26.122255.24634@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: > >>C= didn't support it. Writing for it is a _real_ pain. Especially >>debugging, when there isn't anything to view your clips with. > >It does take a bit of effort to learn to use any Amiga device. >FYI, if you ever looked at the files created in CLIPS: you >might realize that you can type or display those files, if you choose. >When spooled to disk they are just iff files, after all. > I know practically nothing about the clipboard, however that brings up an interesting issue. Perhaps it is "illegal", but is it possible to add something to the clipboard by copying an IFF image into the clips: directory? -- Ethan FF buckets of bits on the bus, FF buckets of bits. Take one down, Short it to ground, FE buckets of bits on the bus.