tws@beach.cis.ufl.edu (Thomas Sarver) (05/05/88)
This is to all those developers out there (and the companies for which they work): ***GET ON KNEES*** I WANT HYPERCARD FOR THE AMIGA! Now that we know what I want, let's talk about the possibilities. I spent about six months of '87 waiting for the news on the Magic Sac for the Amiga. I slobbered over the Atari ST because it had one. I was willing to buy one purely to buy HyperCard. I bought Starboard 2Mb so I would have the room ( I could have gotten by with Alegra otherwise). In summary, <Repeat demand>! ***GET UP FROM KNEELING*** Here's a scenario: Get Apple to license a port on a per/copy basis. Charge $X with $(X/Y) going to Apple. Include some PD stacks, maybe even one or two extra disks of them. Remember, Amiga owners don't have access to them. Become a clearinghouse of PD stacks in Amiga disk format. Let commercial Mac developers know you would distribute their work to Amiga community. Sell PD stacks at cost of P&H, skim some off the top of commercial stack sales. Make sure it uses the standard clipboard like OnLine!, Scribble, etc. for easy importing of text. I know, you're saying, "But who's going to spend $600 for memory to buy an $X piece of software?" Along with the main 1M version, sell a Read-Only 512K version. 1M Amiga 500's are commonplace, and A2000's come large (I don't know the particulars, I own a 1000). So what's left are the 1000 owners. Get in cahoots with a hardware distr. and sell HyperCard for $50 w/ purchase of 1M or more. We all know most Mac code is just trying to talk to the system routines. Amiga programs should be less code purely because we have true multi-tasking. **GET ON SOAPBOX*** In the long run: A community of HyperCard users on two types of machines. As memory comes down, more programs are going to require 1M anyway, so that restriction will be removed. A format will be devised so Amiga will be able to download stacks from BBS's in much the same way they can D/L Mac pics or GIF (also a multi-machine format). You'll be making beacoup (that's, boo-koo) bucks and will be heroes for bringing Apple's genius to the Amiga community. (let's face it, Hypertext is genius, but Apple was genius to introduce it for $49.95) [excuse the slobber marks on this page] HyperCard was meant for multi-tasking. Imagine reading uucp using OnLine! as a terminal to a site. You find something interesting. You copy it to the clipboard. You click HyperCard to front, and put it on a card. Make some connections with other cards, get back to OnLine! Incredible! (BTW, you might want another intermediate version that allows text import with only minimal connectivity). ***GET BACK ON KNEES*** (but still on soap box) Final begging: PLEASE! PLEASE! PLEASE! <3 times quick> PLEASEPLEASEPLEASE give us HyperCard. Thank you for your time. If the people want it, you'll make money giving it to them. ***STAND*** (but still on soap box) To hardware vendors: Everyone knows the Amiga laughs and dances (excuse the anthropocentric metaphor) with a meg of memory or more. But people really have to have the wallet to stomach the price. Developers of mega software are not porting to the Amiga because 1M is not standard. I just read in Byte that the first microcomputer based version of POP-11 was for the Mac. Their next port will be the Atari Mega ST, NOT THE AMIGA. We all know the ST is a toy compared to the Amiga, yet it is receiving the high-end ports. Moral of the story: Make memory expansion more affordable. I know the price of chips are high right now, but have those bare boards ready to fill once the price comes back down. And software vendors, you can can help too by making versions of your software that run better with more memory. For example, Logistix comes in two config- urations, one that does a type of overlaying for low memory and one that fits in large memory all at once. This makes user's say, "Yeah, by buying more RAM, I'm letting X,Y,Z,A, & B packages run easier for me." Not just specialty programs like Animation, Video, Sound, Desktop Publishing, but also personal productivity, games (they can use less disk access w/ more RAM), you know, every day type products. ***GET OFF SOAPBOX*** I had a lot to say because I'm not happy with the state-of-affairs of Amiga software/hardware market. One reason for the way it is is that CBM doens't support its machines. Apple puts out a free upgrade of their OS every 8 mo. or so. IBM has such a huge installed base, anyone will put out something. CBM has finally stuck with a computer format that is compatible. I won't go into the number of computers that *were* incompatible with its predecessors, the only ones that were compatible were C128 (w/ C64) and A2000 & A500. The C128 was behind the technology when it first came out, but A2000 & A500 showed real technological advance in two widely different but marketably necessary directions. Bravo CBM! I don't need to tell anyone how badly the Amiga is marketed. Only someone who walks into a Commodore dealership will ever know an Amiga exists. There's no campaign to get naive users to look at Amiga before giving in to peer pressure and buying IBM. I have one thing to say: IIIII L OOO V V EEEE A M M IIIII GGG A I L O O V V E A A MM MM I G A A I L O O V V EEE AAAAA M M M M I G GG AAAAA I L O O V V E A A M M M I G G A A IIIII LLLL OOO V EEEE A A M M M IIIII GGGG A A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But hey, its the best country in the world! Thomas W. Sarver "The complexity of a system is proportional to the factorial of its atoms. One can only hope to minimize the complexity of the micro-system in which one finds oneself." -TWS Addendum: "... or migrate to a less complex micro-system."
doug-merritt@cup.portal.com (05/06/88)
I think it was Bill Atkinson who wrote HyperCard; forgive me if I'm
wrong. Anyway, Bill licensed it to Apple with the proviso that, if
they ever stopped giving it away with new Macs, all rights would
revert to him. Apple will have zero interest in porting it to the
Amiga, or in licensing a port, because the Amiga is a strong competitor
to the Mac(s).
Bill did make one interesting comment in a magazine recently. He said
that, if anyone ever comes up with a HyperCard clone for the IBM PC (!),
then he would release the file format specifications to allow for
stack compatability to machines. He did not say this about other machines,
least of all the Amiga.
I've looked into the possibility of reverse engineering the stack format.
In the process I've developed some tools for dealing with various kinds
of files from the Mac world, that I'll be releasing not long from now.
Anyway, one rumor that surfaced in response to my enquiries was that
they use something like 30 different undocumented compression formats,
and that it hasn't been reverse-engineered because it's so difficult
to figure them all out. A couple of companies have released products
that know about the stack format, but they are apparently licensed
by Apple to do so, and their products run only on Macs.
One key may be Apple's patented image compression method. A friend
of mine has written an article about it for the Fall issue of BMUG
(Berkeley Macintosh User's Group publication). Fall '87, that is.
Odds are that something related to this patent is involved. Apparently
they achieve surprisingly high compression ratios.
Anyone interested in pooling information please contact me. Note that
I don't currently have much information; I'm just getting started.
So it'd be pointless to ask me to post anything as yet.
Doug
Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt
or ucbvax!eris!doug (doug@eris.berkeley.edu)
or ucbvax!unisoft!certes!dougmp1u+@andrew.cmu.edu (Michael Portuesi) (05/06/88)
Thomas Sarver offers us the following plea: > I WANT HYPERCARD FOR THE AMIGA! > Now that we know what I want, let's talk about the possibilities. > I spent about six months of '87 waiting for the news on the Magic Sac for the > Amiga. I slobbered over the Atari ST because it had one. I was willing to > buy one purely to buy HyperCard. I bought Starboard 2Mb so I would have the > room ( I could have gotten by with Alegra otherwise). In summary, <Repeat > demand>! You waited in vain. Hypercard requires the features present in the Mac 128K ROMs and higher. The Magic Sac uses the old Mac 64K roms. It *cannot* run HyperCard. Wanting to buy an ST so you can run Mac software is silly. The Magic Sac will be a dead product as soon as Mac 64K ROMs are in short supply, and so obsolete that current Mac software won't run with them. Moral: If you want to emulate a Mac, buy a Mac. > Get Apple to license a port on a per/copy basis. The plan stops there. HyperCard sells lots of Macintoshes, and Apple is unlikely to allow software that runs exclusively on their hardware to be ported to other machines. Their lawsuit against HP and Microsoft demonstrates that they are not interested in losing the features that make their product unique. Come to think of it, since Claris distributes HyperCard and not Apple, it would not be Apple that would license the port. But you can be sure Claris won't allow it either. Moral: A third-party Amiga software house is going to have to come out with a HyperCard clone. --M
david@ms.uky.edu (David Herron -- One of the vertebrae) (05/06/88)
you'd have to get more than just liscenses from Apple to run
HypeCard on machines other than Mac's. Bill Atkinson (sp?) is
the guy that really owns it. He is giving Apple a monopoly on
distributing it for as long as they bundle it with new machines.
There's no reason why someone couldn't come up with a similarly
working program.
FYI, the 8 meg memory board I just bought (ASDG's 8MI) is a nice
board, and runs around $400 unpopulated. The 2 megs of 1 meg
chips I bought were over $500. I ain't buyin' no more memory
until prices come down :-).
The boards are out there waiting to be bought, but memory is
too expensive.
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- Windowing... The Amiga has windowing. The Mac has windowing (echoes of
<---- Jonathan Livingston Seagull: "Just flying? A mosquito can do that much!").peter@sugar.UUCP (Peter da Silva) (05/06/88)
It'll never happen. If Apple won't even license the "look and feel" of the Mac to HP, why do you think they'd license their latest products? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
mclek@dcatla.UUCP (Larry E. Kollar) (05/07/88)
[ Burn 'em in! Burn 'em in! Burn 'em in! ] In article <15372@uflorida.cis.ufl.EDU> tws@beach.cis.ufl.edu (Thomas Sarver) writes: > >I WANT HYPERCARD FOR THE AMIGA! Apple would never let it happen, of course. Even if they did, there are certain problems: how do you handle XFCN and XCMD (extended function and command) resources in a non-resource environment? Also, since Hypercard uses a 512 X 384 bitmap (hard-wired), you would have to live with interlace. What is more likely is a stack reader (at least at first), and then only for stacks without XFCNs or XCMDs. Someone could get comp.binaries.hypercard (I think that's the name), download some stacks, and reverse-engineer the file format. And there may be something published already; that would leave only the bit-banging. :-) I hope someone does it -- I'd like to see it myself. Larry Kollar ...!gatech!dcatla!mclek
ejkst@cisunx.UUCP (Eric J. Kennedy) (05/07/88)
In article <wWUAwSy00UgyAL6sp5@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >Come to think of it, since Claris distributes HyperCard and not >Apple, it would not be Apple that would license the port. But you >can be sure Claris won't allow it either. I thought Apple distributed HyperCard, and _Not_ Claris. That's why HyperCard is officially "System Software", since if they called it "Application Software", Apple would have to let Claris distribute it, as per the contract between the two. -- ------------ Eric Kennedy ejkst@cisunx.UUCP
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/08/88)
> *Excerpts from ext.nn.comp.sys.amiga: 6-May-88 Re: How 'Bout HyperCard! Eric* > *J. Kennedy@cisunx.U (566)* > In article <wWUAwSy00UgyAL6sp5@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael > Portuesi) writes: > >Come to think of it, since Claris distributes HyperCard and not > >Apple, it would not be Apple that would license the port. But you > >can be sure Claris won't allow it either. > I thought Apple distributed HyperCard, and _Not_ Claris. That's why> > HyperCard is officially "System Software", since if they called it > "Application Software", Apple would have to let Claris distribute it, as > per the contract between the two. True. I later found out that Apple considers HyperCard to be "systems software" to the point that a good amount of HyperCard is actually going to be put into the Mac ROMS (the sort routine, the compression routines, etc). --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
Dickson@his-phoenix-multics.arpa (Paul Dickson) (05/09/88)
I have put a little preliminary thought work into an IFF format for
supporting a Hypertext type data structure. So far, most of my thoughts
have led to a random access format, mainly because I expect the file to
be larger that available memory. Here are some of the thoughts I had:
The file reader would scan through the file looking for labels
(or tags). The positions of these labels would be saved. This task
could be done with a background task.
There would be data associated with the labels, such as how to
put requestors on the screen and when a requestor is selected, what
new label we go to. After selection data, the actual data is
supplied in an older IFF format (such as ILBM).
I haven't gotten much further, real work tends to take a large bite out
of my spare time (oh how I wish this could be real work 8-).
-Paul Dickson
Dickson%pco @ BCO-Multics.ARPAsdl@linus.UUCP (Steven D. Litvintchouk) (05/10/88)
In article <15372@uflorida.cis.ufl.EDU> tws@beach.cis.ufl.edu (Thomas Sarver) writes: > ***GET ON KNEES*** > > I WANT HYPERCARD FOR THE AMIGA! [lots of emotional stuff deleted] I would like to see a variety of hypermedia and hypertext software products for the Amiga. If *any* machine was a natural for hypermedia and hypertext, it's the Amiga. But HyperCard is not hypertext, and it sure isn't hypermedia. Can you activate an *animation* on a card? And the text on a card is extremely primitive. Basically, Hypercard's card design capability is roughly equivalent to MacPaint. I would like to see a hypermedia product for the Amiga that *really* takes advantage of it's capabilities. I envision something like a cross between MicroFiche Filer and Deluxe Video (hint, hint). Namely, using the microfiche metaphor, select a microfiche card, and activate animation, video, music, or any combination, probably on a separate screen. (Or text, of course.) If each microfiche "card" (what do you call them?) could accept a wide variety of IFF forms, that would truly be neat. > HyperCard was meant for multi-tasking. Really? > Imagine reading uucp using OnLine! as > a terminal to a site. You find something interesting. You copy it to the > clipboard. You click HyperCard to front, and put it on a card. Make some > connections with other cards, get back to OnLine! What's important is support for the clipboard device so you can paste among products. I wish more software vendors supported this for the Amiga. Better idea: Activate animations or music on one MicroFiche card, and while it's running, continue to browse the microfiche for other cards! Now that would really show off Amiga multitasking! Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{cbosgd,decvax,genrad,ll-xn,mit-eddie,philabs,utzoo}!linus!sdl "Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.
mike@ames.arc.nasa.gov (Mike Smithwick) (05/11/88)
["excuse me madam, but I must take my toad for a walk. . ."] In article <31411@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: > >I would like to see a variety of hypermedia and hypertext software >products for the Amiga. If *any* machine was a natural for hypermedia >and hypertext, it's the Amiga. > >But HyperCard is not hypertext, and it sure isn't hypermedia. Can you >activate an *animation* on a card? ^^^^^^^^^ As a matter of fact, yes you can. I've seen a hypercard animation of a multiple star system. You selected the size, number and orbits of some stars, and it calculated and displayed, in real-time, their motion. My problem with hypercard, is what happens when Hypercard-The Next Generation comes out. They've run out of hyper prefixes for things like this, will it be Super-Hypercard? HyperHyperCard? Hypercard+? Hypercard!! ?, Or will they just recycle the emotional level on names, and start back at "Card". . . Oh, I know, how 'bout "WarpCard"? *** HyperMike *** -- *** mike (Cyberpunk in training) smithwick *** "Use an Atari, go to jail!" [disclaimer : nope, I don't work for NASA, I take full blame for my ideas]
pds@quintus.UUCP (Peter Schachte) (05/11/88)
In article <31411@linus.UUCP>, sdl@linus.UUCP (Steven D. Litvintchouk) writes: > I would like to see a variety of hypermedia and hypertext software > products for the Amiga. If *any* machine was a natural for hypermedia > and hypertext, it's the Amiga. > ... > What's important is support for the clipboard device so you can paste > among products. I wish more software vendors supported this for the > Amiga. Unfortunately, the clipboard isn't enough. Yes, you can use it to move text from one application to another. But what's needed is a way to move ANYTHING from one application to another. I have two reservations, a minor one and a major one. First the minor one. I think clipping is not as good a metaphor as selection. I'd rather have a SELECTION: device that supports the operations of setting and finding the current selection. This seems better in terms of user interface (it only takes one action -- selecting something somehow, rather than two -- selecting something and then cutting or copying it). It's also probably better in terms of memory usage and performance: setting the selection only requires setting a pointer, rather than copying a (potentially huge) chunk of memory). Ok, my big reservation about clipboards: they really NEED to be object-oriented. When I select (or copy/cut) a spreadsheet, or animation, or picture, or chunk of a wysiwyg document, it needs to carry along with it information about how to manipulate it, or AT LEAST how to display it. The only general way to do this that I know of is with code. The code needs to be encapsulated with the data. Someone needs to spec an abstract datatype (object-oriented) object structure and a standard set of messages (operations) that all such objects are expected to perform, e.g., display, highlight, unhighlight, and print. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
doug-merritt@cup.portal.com (05/12/88)
I must differ with Steven about "Hypercard is not hypertext, nor
hypermedia. Can you do animation with it?"
Yes, you can do animation with it. Yes, it supports text, graphics,
animation, sounds, music, control of external devices, etc.
That qualifies it as hypertext and as hypermedia.
It may not have the features you want, but don't underestimate what it
is. Which, by the way, is "a phenomenon". You wouldn't believe the amount
of activity in this area. Exponential curve.
Doug
---
Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt
or ucbvax!eris!doug (doug@eris.berkeley.edu)
or ucbvax!unisoft!certes!dougpeter@sugar.UUCP (Peter da Silva) (05/12/88)
In the referenced article there was a request that more programs use the clipboard. Be great. Unfortunately the clipboard is a bit of a pain to put into a program. If it was accesible as a device things would be much better. You could use your existing IFF read-write code to immediately use the clip. Commodore: Well, you already did SPEAK:. Personally, I think CLIP: is a bit more important. How about it? Everyone who says "Why not use RAM: files?" (myself included): The clipboard has one nice feature that RAM: files don't have. According to the docs when memory gets low it will automatically save itself in devs:clipboards and free up memory. At least that's what it sounds like to me. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
peter@sugar.UUCP (Peter da Silva) (05/13/88)
In article <956@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > When I select (or copy/cut) a spreadsheet, or > animation, or picture, or chunk of a wysiwyg document, it needs > to carry along with it information about how to manipulate it, or AT > LEAST how to display it. IFF. Some products, at least, already use IFF for clipboards. It's a natural, particularly since any graphics program you do is likely to support IFF anyway. An object-oriented system would be nice, but it's way too late to do that to clipboards. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
andy@cbmvax.UUCP (Andy Finkel) (05/13/88)
In article <956@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >In article <31411@linus.UUCP>, sdl@linus.UUCP (Steven D. Litvintchouk) writes: >then cutting or copying it). It's also probably better in terms of >memory usage and performance: setting the selection only requires >setting a pointer, rather than copying a (potentially huge) chunk of >memory). The current Amiga clipboard.device supports this functionality... its called posting. Basically, an application says to the clipboard.device, "Hey, I got a couple megs of data for you. Call me if anyone asks for it." No data changes hands unless its actually requested, and its not kept in an intermediate place like the clipboard.device itself. > >Ok, my big reservation about clipboards: they really NEED to be >object-oriented. When I select (or copy/cut) a spreadsheet, or >animation, or picture, or chunk of a wysiwyg document, it needs >to carry along with it information about how to manipulate it, or AT >LEAST how to display it. The only general way to do this that I know >of is with code. The code needs to be encapsulated with the data. The way we do it is via IFF...all data sent to/from the clipboard.device must be IFF, which *is* self-identifying. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "C combines the power of assembly language with the flexibility of assembly language." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
wayneck@tekig5.TEK.COM (Wayne Knapp) (05/14/88)
In article <5324@cup.portal.com>, doug-merritt@cup.portal.com writes: > I must differ with Steven about "Hypercard is not hypertext, nor > hypermedia. Can you do animation with it?" > > Yes, you can do animation with it. Yes, it supports text, graphics, > animation, sounds, music, control of external devices, etc. > That qualifies it as hypertext and as hypermedia. > > It may not have the features you want, but don't underestimate what it > is. Which, by the way, is "a phenomenon". You wouldn't believe the amount > of activity in this area. Exponential curve. Yes, you can do animation with pencil and paper too. I'm sure Hypercard is better than pencil and paper, but it is still going to be a lot of work. What is a better and more likey solution is to build the Hypercard program so that it can access animation done by animation programs. Then you could use the Hypercard program as sort of an editor. Hypercard, hypertext, hypermedia are not programs designed to produce data, rather they are programs and tools that allow the user to readily access the data in a way that is useful. So if you had a CD full of frames of animation, hypermedia may be a great way of playing with how the frames are displayed, but if you wanted to change a frame other tools are better. One way to think about it is maybe calling Hypercard a toolbox and other programs as tools. You don't build a house with a toolbox, but rather with the tools in the toolbox. Without the toolbox the other tools are harder to use. Hyperstuff programs just give you means to access information in useful ways. They don't give the information. I'm please to see that Amiga people are really looking at something Apple has brought to the general market. Hypertext has been around for a long time but Apple seems to be the first to really get the micro market excited about it. Sometimes it really seems that Amiga fans are living with real blinders on. I own an Amiga, in some ways it is good, in other areas it really isn't as good as it could be. I also own an Atari ST, same story as Amiga. I've read so many studip blind things in Amiga mags. and Amiga usenet postings that I was really beginning to wonder about Amiga fans. I take heart that some people at least realize that the Amiga is just a machine and not a god. Wayne Knapp PS. In case people are wondering here is my own personal score card. But first my baises. 1. Simple is better, specail hardware can give great results but often makes programs hard to write/modify/create. I prefer simple hardware that is flexible and fast. As an example, instead of a cooper/blitter/whatever I would rather have a simple bitmap with lots of bits per/pixel. Fix the resolution give me a powerful processor that I can program in C or whatever I like. I believe simple fast hardware really opens the door for ideas. True power is in ideas not hardware. 2. I hate to wait for computers. 3. I hate to have to guess at why something isn't working. Here goes: Amiga Apple Mac Atari ST IBM PC ----------------------------------------------------------- GENERAL STUFF price C+ D B (not Mega) A (clones) speed B- A (Mac II) B (faster uP) B disk drives D C B- A+(best yet) file system B A D (11 chars) D (same as ST) os B+ B C C- package B B C C expansion B (2000) B+ (Mac II) C- A PROGRAMMING avil. lang. C A B A complete tools C A B- A debugging D (improving) A B (improving) B cost of system C B B C ease of prog. D A C A GRAPHICS raw power B A (Mac II) B- B (no stardard) ease of use C A B+ C flexiblity A- A+ A A (many cards) resolution B A (Mac II) C B (depends on colors avil. B A (Mac II) C B card used) speed A A- B+ C SOUND General A+ B D F MIDI C C A C quaulity A A- B F ease of use A A C F SOFTWARE public A+ (great) B C A com. C A B A+ Pick what you want. All machines have good points and bad points. The above is form my own experience form working with and programming the above computers. The one thing that is hard for me to believe is that there are some many great programs on Amiga where the Amiga is not easy to program. It shows that many Amiga programmers have great telent. Remember the machine is useless with out the programmers. No machine can stand on it's own, it is mainly what people have done with the machine. So I suggest people should respect the effort of other people instead of respecting the machine.
kent@xanth.cs.odu.edu (Kent Paul Dolan) (05/14/88)
In article <956@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >In article <31411@linus.UUCP>, sdl@linus.UUCP (Steven D. Litvintchouk) writes: >> I would like to see a variety of hypermedia and hypertext software >> products for the Amiga. If *any* machine was a natural for hypermedia >> and hypertext, it's the Amiga. >> ... >> What's important is support for the clipboard device so you can paste >> among products. I wish more software vendors supported this for the >> Amiga. > >Unfortunately, the clipboard isn't enough. Yes, you can use it to move >text from one application to another. But what's needed is a way to >move ANYTHING from one application to another. I have two >reservations, a minor one and a major one. > >First the minor one. I think clipping is not as good a metaphor as >selection. I'd rather have a SELECTION: device that supports the >operations of setting and finding the current selection. This seems >better in terms of user interface (it only takes one action -- >selecting something somehow, rather than two -- selecting something and >then cutting or copying it). It's also probably better in terms of >memory usage and performance: setting the selection only requires >setting a pointer, rather than copying a (potentially huge) chunk of >memory). This isn't per se a bad idea, but it does force you to choose a granularity for each data type at which your SELECTION will operate. The non-trivial problem of standardizing this to everyone's satisfaction is why a "point at start, point at finish, clip" action was chosen, I would guess. It is OK to say {CHARACTER,WORD,SENTENCE,PARAGRAPH,SECTION,CHAPTER,DOCUMENT} are our supported levels of granularity, but that loses by needing a lot of pointers when you want a syllable, a clause, a set of sections, or a group of chapters. The advantage of clipping is that it always costs you exactly two pointers, which makes the design of the data structure a lot simpler. In the cases of music or animation, start time/frame, stop time/frame is pretty simple to specify, but I wouldn't like at all to be part of the group tasked with deciding what constitutes a selectable object in a piece of music. I'm not even sure a consensus exists among musicians. Note? Bar? Phrase? Voice? Melody? Lyric? a non-trivial problem, to say the least, which is part of the reason it has taken so long to get even mildly competent music scoring tools for the Amiga. >Ok, my big reservation about clipboards: they really NEED to be >object-oriented. When I select (or copy/cut) a spreadsheet, or >animation, or picture, or chunk of a wysiwyg document, it needs >to carry along with it information about how to manipulate it, or AT >LEAST how to display it. The only general way to do this that I know >of is with code. The code needs to be encapsulated with the data. >Someone needs to spec an abstract datatype (object-oriented) object >structure and a standard set of messages (operations) that all such >objects are expected to perform, e.g., display, highlight, unhighlight, >and print. Again, a good sounding idea, but remember, these are (collections of) data objects which have a (commercial, marketable) value, and that value is increased as the size of the market is widened. If you embed Amiga specific code in your standard, you just drove a lot of players out of the market, because a port to another micro has become much less trivial. To make this work and be a commercial success, you need to standardize an _abstract_machine_ in terms of which which the application will manipulate the data, and express the "code" side of your objects in terms of this abstract machine. I spent parts of five years doing this for a much more limited problem (ANSI X3H33's Computer Graphics Metafile and corresponding Computer Graphics Interface), and I will tell you frankly, I don't envy you the job. >-Peter Schachte >pds@quintus.uucp >...!sun!quintus!pds Kent, the man from xanth. Originator and "candidate" of the Birthright Party. "The Birthright of Humankind is the Stars!" Join us in talk.bizarre and help us plan the politics of a revitalized man into space program. If you care, then your input is needed. [A short note in memorial of Robert Anson Heinlein, born 21 October 1907, died 8 May 1988, provided thought provoking entertainment to millions in the interim with his science-fiction writings. "Thou art God," Robert, and you will be sorely missed by the generation whose ideas and ideals you helped to mold.]
karl@sugar.UUCP (Karl Lehenbauer) (05/15/88)
In article <2755@tekig5.TEK.COM>, wayneck@tekig5.TEK.COM (Wayne Knapp) writes: > ...I was really beginning to wonder about Amiga fans. I take heart that some > people at least realize that the Amiga is just a machine and not a god. I don't think wanting Hypercard means that we don't think this Amiga is a god ;-) No. Hypercard says more about the resources Apple has and dedicates to the Mac. It may say more for the individual talents of the couple of guys who wrote it. From what I read, HyperCard may have been a gift to Apple in the sense that Unix was a gift to AT&T: the authors did it more or less without supervision or corporate intervention. > 1. Simple is better, specail hardware can give great results but often makes > programs hard to write/modify/create. I prefer simple hardware that is > flexible and fast. As an example, instead of a cooper/blitter/whatever > I would rather have a simple bitmap with lots of bits per/pixel. Fix > the resolution give me a powerful processor that I can program in C or > whatever I like. I believe simple fast hardware really opens the door > for ideas. True power is in ideas not hardware. So in the meantime, workstations and Mac IIs are the only machines that come close to the power to have remotely reasonable windowing performance without a blitter. Hey, you know, the blitter's not that hard to program, I mean, you can call C routines that say "move this rectangle in this raster from here to here" or "move this memory from here to here and perform this simple masking function on it" or draw a line from here to here. Those are the kinds of functions you're going to be doing anyway, and when you can't use the blitter, you can always use the CPU. Therefore, a blitter is an accelerator of common display (and other) functions. The argument that it is restrictive to have such an accelerator, when its presence can be made invisible to the programmer, is facetious. > 2. I hate to wait for computers. Buy a Cray. The point is, you can only buy as much performance as you can afford. Also, too bad you dismiss the blitter: A $550 Amiga 500 will knock the socks off of a Mac II manipulating windows, something most of us spend a whole lot of time doing. > 3. I hate to have to guess at why something isn't working. Memory protection and an operating system to use it, then? [Long chart comparing Amiga, Apple Mac, Atari ST & IBM PC deleted] Naah, your chart is hosed. You substitute Mac II in everywhere for the Mac to get A's for the Mac in performance, resolution, expandability, but not price, which for most of us makes the II "removed from consideration." If you separated the two, Mac would receive poor or OK marks for speed, expandability, graphics resolution and number of colors and Mac II would be F+ on price, not that it's a bad deal, just that it's a lot of money. C+ for price on Amiga? Come on. B- for Amiga speed vs B for Atari ST? We're not talking absolute CPU cycles here, except in the rarest cases, we're talking "How fast is it to use the machine?" and if you use the two machines to actually DO anything, I mean like click open drawers and move windows around and run real programs, you'll never notice the 11% faster CPU clock: the Amiga just blows the ST away. (I, too, own both.) > ... It shows that many Amiga programmers have great telent. Yes. The machine has attracted many great programmers. > Remember the machine is useless with out > the programmers. No machine can stand on it's own, it is mainly what people > have done with the machine. So I suggest people should respect the effort of > other people instead of respecting the machine. Sort of... OK, it is mainly what people have done with the machine, but it's also what the machine can do. HAM was a curiosity when the Amiga first came out, but thanks to the foresight of its creators, it became very, very useful when DigiView, and finally HAM paint programs and utilities, came out. So it takes both a good machine and good programmers, and you fail to make note of the part a powerful machine plays in attracting good programmers. -- "Now here's something you're really going to like!" -- Rocket J. Squirrel ..!{bellcore!tness1,uunet!nuchat}!sugar!karl, Unix BBS (713) 438-5018
dsmall@well.UUCP (David Small) (05/16/88)
(The discussion centers around Hypercard & a little Magic Sac'isms.) I spent a few months very recently hacking Magic Sac into the Amiga and have some news -- well, you *did* say you were looking for Magic Sac news, right? Anywho. First, it has to run in flickermode, otherwise you can't see enough of the screen to do much good. A flicker fixer would be important. Second, the Amiga apparently can read the outer 32 tracks of Mac disks -- not the inner 48, however. Third, there's a big problem in the memory mapping that I can't overcome, and that's why I'm putting the project on hold. On the Mac, RAM memory starts at location 0 and extends upwards for however much memory you have. The memory manager is designed around this -- it compacts the heap, and so forth, during program operation. On the Amy 500, you've got 512K in low memory, which is fine, then a 11 megabyte "hole" in the memory map, then another (optional) 512K. I can't get the Mac OS to work with this for several reasons. Hence, the largest "emulated Mac" I can bring is up at a 256K Mac -- not real useful. 512K is sort of a starting point anymore for Mac software. Hypercard assumes 1 meg. Anywho, over the last two weeks I've reached the conclusion that it's just not worth doing; the resulting product wouldn't be powerful enough. This honestly doesn't have anything to do with Apple, the Lawsuit, or anything else. The reason the Magic Sac for the Amiga is so late is that two seperate consultant groups failed to make it work, over a two year period. The last person to try it more or less gave up in March '88; I see he showed up at the BADGE meeting, broke his non disclosure agreement, and gave several compeltely wrong reasons for why it was being dropped. During those two years, I was much too busy on the Atari end of things to do work on the Amiga end. After giving up on outsiders doing it (in about February), I got a 500 and hard disk, and hacked it together. It took roughly the same time as the ST version -- about 3 months -- to bring up. Anyway, I don't know what to do about the memory map problem. Perhaps a smaller " hole" in RAM can be tolerated in the auto-configure memory machines, if their mapping is moved down as closely as possible to the 512K chip ram. It is also possible that the new 1-meg chipset will help; I'd hate to see a Magic Sac dependent on a retrofit, though. Add to this the flicker mode, and the disk drive <> Mac format directly, and it's just not practical for me right now. I know of a foreign-developed 128K ROM Mac emulator for the A-1000 that runs with both Kickstart and the 512K "regular" RAM; that looks interesting. It runs Multifinder, so it's pretty compatible, and Hypercard is right over the horizon with a 1 meg chip set. Since I don't see any source for 128K ROMs in the US that's legit, I don't think I could market it. Sorry for the lengthy note, but I've owed this newgroup some news for a long time. -- Dave Small (formerly, Data Pacific)
doug-merritt@cup.portal.com (05/17/88)
I said: >> I must differ with Steven about "Hypercard is not hypertext, nor Wayne Knapp says: >Yes, you can do animation with pencil and paper too. I'm sure Hypercard is >better than pencil and paper, but it is still going to be a lot of work. What >is a better and more likey solution is to build the Hypercard program so that >it can access animation done by animation programs. Then you could use the >Hypercard program as sort of an editor. I'm not entire sure exactly what your bottom line point is in this posting. But let's try this out: By analogy with still pictures, we know we need to have (1) a file format, like IFF, (2) display programs, like viewilbm (3) editing programs, like Dpaint, (4) importation/translation of media from other sources, like DigiView, or Sun2Iff (?), etc. Hypercard has implemented a (secret & proprietary but standard) file format, it allows display of hypermedia texts, and it allows editing them, too. It also allows importing text created with document editors, pictures from paint programs, etc. Like I said before, it may be lacking some features you want, but doesn't it cover all the basics??? It is weakest in the edit area, since it must handle many different kinds of media. It has MacPaint-like commands for creating pictures, but it's not the greatest paint program. Same goes for editing text, etc. Isn't this inevitable? How could any single program be the best possible at editing *all* media types? Consider religious wars about plain old text editors! > Hypercard, hypertext, hypermedia are not programs designed to produce data, >rather they are programs and tools that allow the user to readily access the >data in a way that is useful. So if you had a CD full of frames of animation, >hypermedia may be a great way of playing with how the frames are displayed, >but if you wanted to change a frame other tools are better. "Hypermedia" refers to the medium, not to the program. A CD can contain regular video or animation, or it could contain a hypermedia document. I'd definitely agree that Hypercard would be better for *displaying* the contents of a CD full of video than for modifying it. But if the CD contains a hypermedia structure, you might well want to edit that structure using Hypercard. And use a video editor for editing the the video. (Assume "CD" == "writable CD" here.) >Sometimes it really seems that Amiga fans are living with real blinders >on. [...] I've read so many studip blind things in Amiga mags. and Amiga >usenet postings that I was really beginning to wonder about Amiga fans. I >take heart that some people at least realize that the Amiga is just a machine >and not a god. If you substitute the word "jew" or "black" etc for "Amiga fans" in the above, I think you'll find that it doesn't come across quite as nicely as you probably wanted it to. "Damning with faint praise" is the phrase that comes to mind. But I commend you for being open minded enough to overcome your initial prejudice. >I'm please to see that Amiga people are really looking at something Apple >has brought to the general market. Hypertext has been around for a long time >but Apple seems to be the first to really get the micro market excited about >it. Apple is clever about marketing. There have been commercial hypertext systems available since 1970 on mainframes (primarily Doug Englebart's). And they've been available on micros prior to Hypercard. But they were not well understood by the public. They still aren't in general, but giving Hypercard away with Mac's sparked a lot of interest. If you want to make comparisons (a dubious passtime), the appropriate one would be versus "Commodore", not versus "Amiga people". There are lots of Amiga folks who have been keenly interested in hypertext for years. Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
doug-merritt@cup.portal.com (05/17/88)
Karl says: >We're not talking absolute CPU cycles here, except in the rarest cases, >we're talking "How fast is it to use the machine?" and if you use the two >machines to actually DO anything, I mean like click open drawers and move >windows around and run real programs, you'll never notice the 11% faster >CPU clock: the Amiga just blows the ST away. (I, too, own both.) The thing that ST fans miss when they point out the faster cpu on the ST is that the Amiga has *twice* the memory bandwidth...16Mhz. And it is used by the blitter, which is itself much more efficient of memory bandwidth than the 68000 (at simple pixel operations as used in e.g. windowing). This is regularly pointed out, but word never reaches the ST mainstream, and so the Amiga continues to be bad mouthed. I think that there are perfectly good reasons to buy and enjoy an ST; I just wish the Tramiels wouldn't use such low mudslinging tactics to sell them. Doug
wayneck@tekig5.TEK.COM (Wayne Knapp) (05/17/88)
In article <1997@sugar.UUCP>, karl@sugar.UUCP (Karl Lehenbauer) writes: > In article <2755@tekig5.TEK.COM>, wayneck@tekig5.TEK.COM (Wayne Knapp) writes: > > 1. Simple is better, specail hardware can give great results but often makes > > programs hard to write/modify/create. I prefer simple hardware that is > > flexible and fast. ... > > ... True power is in ideas not hardware. . > So in the meantime, workstations and Mac IIs are the only machines that > come close to the power to have remotely reasonable windowing performance > without a blitter. Hey, you know, the blitter's not that hard to program, > I mean, you can call C routines that say "move this rectangle in this raster > from here to here" or "move this memory from here to here and perform > this simple masking function on it" or draw a line from here to here. Those > are the kinds of functions you're going to be doing anyway, and when you can't > use the blitter, you can always use the CPU. Therefore, a blitter is an > accelerator of common display (and other) functions. The argument that > it is restrictive to have such an accelerator, when its presence can be made > invisible to the programmer, is facetious. Not true. I think that the common Mac, Atari ST and Amiga have enough power to do a lot, you don't have to have a Mac II, Sun 3/60 or whatever. In fact the Mac, ST and Amiga were the first machines that really oftered a lot power for the price. In my view they are the first machines that one does not have to use hardware tricks to get the job done. What I'm saying don't write code for the machine today write it to last. Make the code easy to port and put effort into the concept of the code. Sometimes one must use hardware to get the job done but if you do that hide it from the bulk of the code. If you can live without the blitter then write some low level routines that hide the blitter and it's data structure from the real code. I can tell you from real experience - code that uses things like a hardware blitter is HARD to port. Instead of taking the easy way out look at the problem, solve it instead of brute forcing it, then you'll have code to be prode of! Often things like bitters are not needed to get great preformance! > > 2. I hate to wait for computers. > > Buy a Cray. The point is, you can only buy as much performance as you can > afford. Also, too bad you dismiss the blitter: A $550 Amiga 500 will > knock the socks off of a Mac II manipulating windows, something most of > us spend a whole lot of time doing. This is my whole point. People who one use one computer have often have blinders on. An Amiga doesn't even keep up with a standard Mac let alone than Mac II. I've used then side by side I know. The Amiga should be better than a wimpy standard Mac but often it isn't. I don't program that much on Mac's, I don't even like Apple but I really respect what Apple has done with the Mac software. The Mac os is as far above the Amiga in richness and robustness as the Amiga os is above the Atari ST os. Of coarse I'm not talking about multi-taking here but the Mac also has good solutions for multi-taking. Even the Atari ST can do reasonable mutli-tasking. Multi- tasking just isn't that hard and there are many ways to do it. Come on the Amiga can be better than a Mac - it is more powerful, more flexible and cheaper, but it just isn't there yet. This is what I mean the power is in ideas not hardware. Good programs with shine without the hardware and soar when given the right hardware. (I'm not a fool - I know the graphics and sound on a standard Amiga kill a standard Mac's. That is why I own an Amiga, still what has been done on a standard Mac is impressive!) Take good Mac software and put it on a Mac II, the results can be breath taking. My chanage is not to give up the Amiga but for people to right the same kind of great code for the Amiga. Good sound code can really out preform hardware. Then the good code on good hardware is a true winner. Don't depend of hardware to get the job done. Soon the Amiga may be replaced with a machine that has twice the power (without specail hardware) for 1/2 the price. (Maybe even in a couple years) Good code will port easy and soar, hardware dependent code will port hard and often just fade away. Use your heads program great code and make the Amiga a winner! > > > 3. I hate to have to guess at why something isn't working. > > Memory protection and an operating system to use it, then? Guru errors, come on. By the by the Atari ST is also awful weak here, but at least it is easy to put is printf's. At least both machines are getting source level debuggers now, but in honestly both are far behind the Mac and IBM pc in tools. > > [Long chart comparing Amiga, Apple Mac, Atari ST & IBM PC deleted] > > Naah, your chart is hosed. You substitute Mac II in everywhere for the > Mac to get A's for the Mac in performance, resolution, expandability, > but not price, which for most of us makes the II "removed from consideration." > If you separated the two, Mac would receive poor or OK marks for speed, > expandability, graphics resolution and number of colors and Mac II would > be F+ on price, not that it's a bad deal, just that it's a lot of money. Probably true, after all the chart was just my viewpoint. > > C+ for price on Amiga? Come on. B- for Amiga speed vs B for Atari ST? > We're not talking absolute CPU cycles here, except in the rarest cases, > we're talking "How fast is it to use the machine?" and if you use the two > machines to actually DO anything, I mean like click open drawers and move > windows around and run real programs, you'll never notice the 11% faster > CPU clock: the Amiga just blows the ST away. (I, too, own both.) > Huh, I own both an Amiga 1000 and Atari ST. I'm porting Amiga code to the Atari right now. I often run then side by side. I know that the are many factors in speed but seldom does the Amiga beat the Atari. I think a lot of the Amiga speed loss is due to memory use. Maybe if I put a couple megs of memory on the Amiga it would inprove a lot but as it is now a 512k Atari kills a 512k Amiga, no doult about it. Also I never seen disk drives as slow as the Amiga's. A the Amiga graphics and sound often beat the ST's thought, but not it's speed. The Amiga should be faster but it isn't. It really fustrates me! So come on lets write better code for the Amiga! > > ... It shows that many Amiga programmers have great telent. > > Yes. The machine has attracted many great programmers. > > > Remember the machine is useless with out > > the programmers. No machine can stand on it's own, it is mainly what people > > other people instead of respecting the machine. > > Sort of... OK, it is mainly what people have done with the machine, but > it's also what the machine can do. HAM was a curiosity when the Amiga first > came out, but thanks to the foresight of its creators, it became very, very > useful when DigiView, and finally HAM paint programs and utilities, came out. HAM can be great and HAM can also be a real pain. I'd like to have 6 real bit planes than HAM. Or how about 8 real bit planes. Sure that would have been a better use of some of that speical hardware. > So it takes both a good machine and good programmers, and you fail to make > note of the part a powerful machine plays in attracting good programmers. After years of buying, programming and using mirco's I don't think there is any logic as to why programmers like one machine and not another. People are different I guess is the only reason. I heard great points for all machines. Wayne Knapp
pds@quintus.UUCP (Peter Schachte) (05/17/88)
In article <3768@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes: > In article <956@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > >Ok, my big reservation about clipboards: they really NEED to be > >object-oriented. When I select (or copy/cut) a spreadsheet, or > >animation, or picture, or chunk of a wysiwyg document, it needs > >to carry along with it information about how to manipulate it, or AT > >LEAST how to display it. The only general way to do this that I know > >of is with code. The code needs to be encapsulated with the data. > > The way we do it is via IFF...all data sent to/from the clipboard.device > must be IFF, which *is* self-identifying. IFF data is self-identifying, but that really isn't enough. In order to use this approach, every program must include all the code for dealing with all the kinds of data that they expect someone to try to paste in. As the diversity of the Amiga environment increases, this will be more and more impractical. In comp.sys.amiga.tech, I recently suggested a solution to this problem which basically amounts to having a library for each kind of thing (object) that multiple applications may want to deal with. The library contains all the procedures for doing things with these objects, such as displaying them on a screen. The library also contains the info about how to read and write the object to a file, which would answer some people's complaints about the pain of parsing IFF files. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/17/88)
>This is my whole point. People who one use one computer have often have >blinders on. An Amiga doesn't even keep up with a standard Mac let alone >than Mac II. I've used then side by side I know. The Amiga should be better Uhhh... Bullshit. First of all, don't even try to compare a standard Amiga with a Mac II ... for gods sakes the Mac II has got a 68020 in it! It is in a completely different procesor and price class. As far as comparing the Amiga to a 68000 Mac, I beg to differ. Having run tests and used both I see no such discrepancy. In fact, taking the Amiga's worst problem (floppy disk speed) the Mac+ writes files to floppies at about the same speed. And of course, one need not mention graphically oriented IO. >the Mac software. The Mac os is as far above the Amiga in richness and >robustness as the Amiga os is above the Atari ST os. Of coarse I'm not >talking about multi-taking here but the Mac also has good solutions for >multi-taking. Even the Atari ST can do reasonable mutli-tasking. Multi- Again, I say B.S. >Take good Mac software and put it on a Mac II, the results can be breath >taking. My chanage is not to give up the Amiga but for people to right the >same kind of great code for the Amiga. Good sound code can really out >preform hardware. Then the good code on good hardware is a true winner. Frankly, I am not impressed, and Hands-on use of the Mac II doesn't exactly take MY breath away. The only think impressive is the CPU and CPU speed... what I see on a Mac II screen is very sluggish compared to its potential. >Don't depend of hardware to get the job done. Soon the Amiga may be replaced >with a machine that has twice the power (without specail hardware) for 1/2 the >price. (Maybe even in a couple years) Good code will port easy and soar, >hardware dependent code will port hard and often just fade away. Use your >heads program great code and make the Amiga a winner! I disagree. That is, I agree that it is well to hide special hardware but I disagree as to your definition of 'special hardware'. What is a CRT controller? Do you want the processor to stuff the RGB out itself? What is a Disk controller? So now we extend it a little and have Audio DMA, a more complex video controller, another processor, etc... Frankly, that is the future... first start with more specialized controllers and then move on and add more general parallel processing capabilities. You might be able to reduce their advantage to a numerical factor, but don't be deceived. In many cases a factor of 2 can make the difference between perceiving it as slow and perceiving it as fast. What's the difference between 20 mph and 40 mph? 30 and 60? Get the picture.... >source level debuggers now, but in honestly both are far behind the Mac and >IBM pc in tools. Correct. What else is new? I point out that the Mac and PC were introd a couple of years before the Amiga. I also point out that we are beginning to catch up. Your remarks are equivalent to somebody condeming a computer introd two weeks previous because it doesn't have much commercial software available for it. > Huh, I own both an Amiga 1000 and Atari ST. I'm porting Amiga code to >the Atari right now. I often run then side by side. I know that the are >many factors in speed but seldom does the Amiga beat the Atari. I think a >lot of the Amiga speed loss is due to memory use. Maybe if I put a couple >megs of memory on the Amiga it would inprove a lot but as it is now a 512k >Atari kills a 512k Amiga, no doult about it. Also I never seen disk drives >as slow as the Amiga's. A the Amiga graphics and sound often beat the ST's >thought, but not it's speed. The Amiga should be faster but it isn't. >It really fustrates me! So come on lets write better code for the Amiga! I can laugh at that .. excuse me a moment ... ok, I'm back. Frankly, you are dead wrong here. In terms of raw cpu speed the atari is just a little faster, and that is assuming you are NOT in monochrome mode. I find the well integrated enviroment the Amiga provides is just as fast if not faster than all other machines of equivalent stature (read: Atari/Mac. IBM is a lower form of life as far as I'm concerned). Perhaps *YOU* should invest a little money into a few solutions, of which there are many, instead of bitching about your problems. At least when I bitch I create or find my own solutions. I personally use REZ and FACC and since then have never had to wait for my floppies. Oh, and by the way, I do not currently own a hard drive. For less CPU bound programs, the hardware support and low OS overhead easily outweigh such minor processor speed differences. >After years of buying, programming and using mirco's I don't think there is >any logic as to why programmers like one machine and not another. People >are different I guess is the only reason. I heard great points for all >machines. > Wayne Knapp After years of buying, programming, and hacking micros, I find that I have very STRONG opinions as to MY FAVORITE machine... so much so that I find my particular machine a thousand fold better choice then other machines at the time I purchased it (and it's still holding its place after a couple of years). We all know which machine *that* is .... -Matt
peter@sugar.UUCP (Peter da Silva) (05/18/88)
In article <987@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > IFF data is self-identifying, but that really isn't enough. In order > to use this approach, every program must include all the code for > dealing with all the kinds of data that they expect someone to try to > paste in. As the diversity of the Amiga environment increases, this > will be more and more impractical. So what's wrong with an "iff.library"? If you're going to do all the work needed to hack this stuff, why re-invent the wheel? IFF does its job moderately well, and it's supported on *everything*. Also: 'every program must include all the code for dealing with all the kinds of data that they expect someone to try to paste in.' isn't quite true. They only need to deal with the kinds of data that people will try to paste in and that is useful to them. Whether or not it can read them, a text editor isn't going to be able to do anything useful with SMUS files or ANIMs (for example). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
peter@sugar.UUCP (Peter da Silva) (05/18/88)
In article <2768@tekig5.TEK.COM>, wayneck@tekig5.TEK.COM (Wayne Knapp) writes: > This is my whole point. People who one use one computer have often have > blinders on. An Amiga doesn't even keep up with a standard Mac let alone > than Mac II. I've used then side by side I know. The Amiga should be better > than a wimpy standard Mac but often it isn't. I've used a Mac II and an Amiga. And you want to know something? When it comes to just shoving data around (moving windows, etc) the Amiga is way faster. What do you mean by "keep up with" here? The amount of time it took the Mac II to repaint stuff when I clicked in a background window would have made an 8088 ashamed. Microsoft Windows has a better response time. > I don't program that much on > Mac's, I don't even like Apple but I really respect what Apple has done with > the Mac software. You mean what Mac Developers have done with it. > The Mac os is as far above the Amiga in richness and > robustness as the Amiga os is above the Atari ST os. The Mac OS is no more powerful than CP/M. That richness you see is in the grapgics and user interface libraries. Well, the Amiga has libraries, too. In fact the Amiga has a better *model* for adding libraries than the Mac. > Of coarse I'm not > talking about multi-taking here but the Mac also has good solutions for > multi-taking. I've used Multifinder. It's *not* a good solution for multitasking. It's a kludge. It works pretty well for context switching, but it's missing so much. No background processing, for one thing. > Even the Atari ST can do reasonable mutli-tasking. Really? Ask David "Multitasking" Beckmeyer (author of the Multitasking Shell for the ST) about the ST some time. Stand back. > Maybe if I put a couple > megs of memory on the Amiga it would inprove a lot but as it is now a 512k > Atari kills a 512k Amiga, no doult about it. I douBt it. I just upgraded my Amiga over 512K recently, so the experience is fresh in my mind. There's no comparison between the Amiga and the ST. The Amiga wins hands down. I can mouse too fast for the ST to keep up just in normal use. I can do the same thing on the Mac, BTW. No way on the Amiga. > Also I never seen disk drives as slow as the Amiga's. Let's see some benchmarks. > HAM can be great and HAM can also be a real pain. I'd like to have 6 real > bit planes than HAM. Or how about 8 real bit planes. Sure that would have > been a better use of some of that speical hardware. You wouldn't have been able to afford the machine, then. Check out the pricing on 8 bit color boards some time. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
mrr@amanpt1.zone1.com (Mark Rinfret) (05/19/88)
In article <2755@tekig5.TEK.COM>, wayneck@tekig5.TEK.COM (Wayne Knapp) writes: > In article <5324@cup.portal.com>, doug-merritt@cup.portal.com writes: > > I must differ with Steven about "Hypercard is not hypertext, nor > > > Yes, you can do animation with pencil and paper too. I'm sure Hypercard is > better than pencil and paper, but it is still going to be a lot of work. What > is a better and more likey solution is to build the Hypercard program so that > it can access animation done by animation programs. Then you could use the > Hypercard program as sort of an editor. We have done this quite successfully using HyperCard and VideoWorks II. HyperCard, though not a true hypertext tool, is a pretty amazing product which should not be taken lightly. Coupled with Owl International's Guide product, revolutionary solutions to electronic documentation problems can be achieved. -- < Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr > < AMA / HyperView Systems Home: 401-846-7639 > < 28 Jacome Way Work: 401-849-9930 x301 > < Middletown, RI 02840 "If I just had a little more time...">
debate2@watdcsu.waterloo.edu (David Oh) (05/19/88)
In article <8805170742.AA28361@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >>the Mac software. The Mac os is as far above the Amiga in richness and >>robustness as the Amiga os is above the Atari ST os. Of coarse I'm not >>talking about multi-taking here but the Mac also has good solutions for >>multi-taking. Even the Atari ST can do reasonable mutli-tasking. Multi- > > Again, I say B.S. > Hey, there are acutally computers better than the Amiga you know :-) The Mac OS, which I personally haven't seen, could be better. I've seen the Mac Interface (similar to WB - what's it called?) and it looks very clean and easy to use. I've used Mac's before, and I Love the Mac II's. (I also love 16 millions colours!) The problem with the Amiga is that the OS is a bit "messy" for lack of a better term and too complicated.. If you don't make your windows right, and forget one of the hundreds of flags, you get gadgets that flicker, lock of the computer, and generally, mess everything up. Sure, it can be bad code but has this every happened to you? You lock up the IntuiMessages comming from a program, so you can't type or move the mouse, but the tasks are still running? Even good code can do this when you are multitasking. Also, the WorkBench, which I NEVER use, is also bad... What can you do in it? Rename, Format and Copy! Also, the WB takes forever to refresh gadgets and window structures and sometimes, I can even "feel a Guru" comming. Things are all bogged down and getting messy, well, quite frankly, if I were a new buyer, I'd skip the Amiga. 1.3 is fixing the CLI problem, so we can have a half decent CLI to replace our defunct WB to get some more buyers interested. But as for OS, I feel that it is a bit malfunctional at times, and code cannot be blamed. >> Huh, I own both an Amiga 1000 and Atari ST. I'm porting Amiga code to >>the Atari right now. I often run then side by side. I know that the are >>many factors in speed but seldom does the Amiga beat the Atari. I think a >>lot of the Amiga speed loss is due to memory use. Maybe if I put a couple >>megs of memory on the Amiga it would inprove a lot but as it is now a 512k >>Atari kills a 512k Amiga, no doult about it. Also I never seen disk drives >>as slow as the Amiga's. A the Amiga graphics and sound often beat the ST's >>thought, but not it's speed. The Amiga should be faster but it isn't. >>It really fustrates me! So come on lets write better code for the Amiga! > > I can laugh at that .. excuse me a moment ... ok, I'm back. Frankly, >you are dead wrong here. In terms of raw cpu speed the atari is just a >little faster, and that is assuming you are NOT in monochrome mode. I find >the well integrated enviroment the Amiga provides is just as fast if not >faster than all other machines of equivalent stature (read: Atari/Mac. IBM >is a lower form of life as far as I'm concerned). Perhaps *YOU* should >invest a little money into a few solutions, of which there are many, instead >of bitching about your problems. At least when I bitch I create or find my own >solutions. I personally use REZ and FACC and since then have never >had to wait for my floppies. Oh, and by the way, I do not currently own >a hard drive. You don't own a hard drive? I don't know how? I have two drives on my 2000 and with this setup, things get super slow and super frustrating... The only way the Amiga can be TRULY productive is if you have a harddrve, to avoid all that cursed "Insert Workbench in any drive" stuff. PS: After REZ and FACC, on my 1 meg machine, I have 640K. >I have very STRONG opinions as to MY FAVORITE machine... so much so that >I find my particular machine a thousand fold better choice then other >machines at the time I purchased it (and it's still holding its place after a >couple of years). We all know which machine *that* is .... Yes, the Amiga is still my favourite machine... Just take a little criticism. More constructive criticism will mean more improvements (look at 1.3) As for My computer is better that Yours! arguements, I don't think this is the place for things like that... I mean, from my end, Amiga owners are mature and can take tonnes of criticism and don't blindly boast like thost ST owners who talk before the think. (i've heard outragous things like the ST has its own Laser Disk and can display pics like those in the laser disk game Dragonslayer.) PLLLLEEEASSSEEE. Just sit back, and chuckle. It better for all of us. (And makes us look more professional :-) :::> Dave uucp: debate2@watdcsu.waterloo.edu Plink: dave*oh Please, no hate mail. :-)
jason@lakesys.UUCP (Jason) (05/20/88)
Regarding your comment about David Beckemeyer's (sp?) opinion of the ST: I know that he flamed Atari extensively, but I don't recall him complaining about the platform all that much... Jason Hey, don't flame me, this is only my second post!
ken@jose.UUCP (Ken MacLeod) (05/20/88)
In article <5492@cup.portal.com>, doug-merritt@cup.portal.com writes: > The thing that ST fans miss when they point out the faster cpu on the > ST is that the Amiga has *twice* the memory bandwidth...16Mhz. And > it is used by the blitter, which is itself much more efficient of memory > bandwidth than the 68000 (at simple pixel operations as used in e.g. > windowing). Whoa!! Common Amiga owner misconception! The bus _does_not_ run twice as fast as the processor clock! Get "16MHz" out of your mind! It goes like this: The processor clock is 7.14MHz, the 68000 normally accesses memory only every _fourth_ clock cycle. Memory can cycle every _second_ cycle, leaving every other even cycle free for DMA. In other words: Memory does _not_ cycle at twice the processor clock rate, but at _half_ the processor clock rate. Since the processor only uses a _quarter_ of the processor cycles accessing memory, the second quarter is still free. This can all be found in the Hardware Ref., pgs 186-190, and note that they usually use 'memory cycles' in their descriptions, memory cycles are two 'processor cycles' each. Also, the ST does the same thing, it uses the free cycles (one quarter of the available processor cycles, one half of the available memory cycles) to fetch video memory. The reason you never hear about this is because video is the only thing on the ST that uses those cycles so there's nothing really interesting about it. -- Ken MacLeod Price Savers Wholesale Warehouse uunet!iconsys!caeco!pedro!jose!ken Salt Lake City, Utah (801) 277-6966 (evening) (day) (801) 264-7224 Disclaimer: I don't let anyone share my views, there all mine.
eraps2@aspvax.UUCP (05/20/88)
Just read the HyperCard (tm) request notice (I am way behind on the
news).
It seems to me (after playing with it for a while) that HyperCard (tm)
is nothing more than a WorkBench. Each icon is basically a directory
or a file. While certainly not an expert on it (I didn't really have
any use for it -- thus only mucked about a couple of hours), I think
you could get something that operated pretty much the same by taking
WorkBench (I believe there was a PD WorkBench posted called HackBench)
and adding the capability to change the background picture for each
directory (ie. let the .info file contain the whole screen picture,
not just the directory layout info). Also we need to treat the .info
files for directories slightly differently (instead of nesting
directories, selecting a directory icon would cause us to access the
top-level directory of that name. Then REMOVE the capability to move
icons around, REMOVE the actual displaying of icons, REMOVE the menus
(and the menu bar), REMOVE the capability to have more than one
directory open at a time, REMOVE the ability to handle multiple
devices, REMOVE the highlighting of an icon when selected and you have
something that is indistinguishable from the original. Now, how would
it work? When you want to change the picture (set of icon commands),
the icon references a new directory, if we are in a sub-directory, we
go up to the top directory and then down into the new one (close the
current dircetory and open the new one). If we want to run a program,
then the ICON is simply the program.
Am I missing something? After my admittedly brief examination of
the program, it looks like nothing more than a really watered down
workbench with background pictures. If you want something like that
on the Amiga, it looks very easy from the technical viewpoint, of course,
Apple (tm) would probably sue you. Maybe you could get around that by
writing a program which overlays pictures on the current workbench and
then set a system variable for your current location (directory). You
would need a second program to tell the Workbench which directory windows
to open/close. Then, you could arrange the directory structure for
your 'stack' and add the pictures. Now you are running the standard
Amiga Workbench ... what's to sue? Of course, the user has access to
the extra features (icon move, copy, info, etc) but thats not 'much'
of a problem (maybe a program to patch WB to lose these features?).
Just my $1.03.
"You and I are scientists professor, Rob Ginn
we buy our right to experiment at ...burdvax!jtids!aspvax!eraps2
the cost of total responsibility" ...sun!liberty!drexel!aspvax!eraps2
-- The Doctor eraps1@nadc.arpapds@quintus.UUCP (05/21/88)
In article <2019@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > In article <987@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > > IFF data is self-identifying, but that really isn't enough. In order > > to use this approach, every program must include all the code for > > dealing with all the kinds of data that they expect someone to try to > > paste in. > > So what's wrong with an "iff.library"? > Also: 'every program must include all the code for dealing with all the > kinds of data that they expect someone to try to paste in.' isn't quite > true. They only need to deal with the kinds of data that people will try > to paste in and that is useful to them. Ah, but they should be able to deal with the new wiz-bang kind of pie chart that hasn't been invented yet, too. If the code that knows how to manipulate an object is not required to be part of the program that has to do the manipulation, then (1) It doesn't have to be considered by the application writer. (2) An old program can manipulate new kinds of objects invented since the program was published. (3) The code to manipulate all these objects is not stored in every single application that has to deal with them, but once in a library (that's what libraries are for, after all). (4) The code is not present in memory if it is not needed (i.e., there are no instances of it present). Why have the code for handling bar charts in memory if you don't HAVE any bar charts? (5) through the magic of shared libraries, the code for manipulating a particular object is only present in memory once, no matter how many programs (processes) are manipulating that kind of object. > Whether or not it can read them, > a text editor isn't going to be able to do anything useful with SMUS files > or ANIMs (for example). But a hypertext system SHOULD. The point is that this approach makes it possible to deliver small components. By this I don't mean, say, an individual bar chart, but a new KIND of chart. IFF lets me deliver individual bar charts. It makes it possible for me to invent a new kind of chart, but only as part of a program I'm delivering. If someone wants to be able to incorporate this kind of chart into a document, they have to convince a purveyor of word processors to do the work. An object-oriented system would allow the encapsulation of the methods for handling this type of chart in a single place, so that any program could use it without having to know about it ahead of time, other than to know the names of the methods it must support. Another bonus of this is that existing objects can be replaced. For example, if I don't like the way bar chars look or behave, I can write my own bar chart object to replace the old one. A better example might be scrolling windows: if I decide that I want the left mouse button to make the window scroll up the right to scroll down, I could modify the scrolling window class. Thus I've changed the way every program that uses the scrolling window object behaves. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
sdl@linus.UUCP (Steven D. Litvintchouk) (05/21/88)
In article <462@amanpt1.zone1.com> mrr@amanpt1.zone1.com (Mark Rinfret) writes: > We have done this quite successfully using HyperCard and VideoWorks II. > HyperCard, though not a true hypertext tool,is a pretty amazing product which > should not be taken lightly. Coupled with Owl International's Guide product, > revolutionary solutions to electronic documentation problems can be achieved. I've just seen a demo of AMA's attempt to integrate HyperCard, VideoWorks II and Guide. It's certainly worth a look if you're interested in hypertext systems (and don't mind using a Mac). Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{cbosgd,decvax,genrad,ll-xn,mit-eddie,philabs,utzoo}!linus!sdl "Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.
doug-merritt@cup.portal.com (05/23/88)
Rob Ginn writes: >It seems to me (after playing with it for a while) that HyperCard (tm) >is nothing more than a WorkBench. Each icon is basically a directory [...] >you could get something that operated pretty much the same by taking >WorkBench and adding the capability to change the background picture for each I wish. Your observations are accurate in a very, very abstract kind of way. Both Workbench and Hypercard allow you perform potentially arbitrarily complex and powerful actions by clicking on icons with a mouse. There the similarity ends. The set of modifications/enhancements to Workbench/Hackbench that you suggest amount to writing Hypercard from scratch. The only thing you gain from starting from the Work/Hack-bench environment is the ability to specify actions by clicking on icons, which is (A) a trivial subset of the entire functionality required, and (B) is relatively easy to implement outside of the environment of Workbench anyway. Now that I've stressed that you're underestimating the scope of what you suggest, I must admit that you *would* be able to create some kind of simple hypercard stack-like thingie based on Workbench icons more easily than you could if starting from scratch. So it's not necessarily a bad idea. However, for it to save you work, you must a priori accept that you'll be pounding a square peg into a round hole, and you won't be able to get it to do a lot of kinds of things that Hypercard allows (without a ton of work that negates the supposed advantage). If what you wanted was the full functionality of Hypercard, then this really isn't the easy way to go. If you want something less, well, it depends on exactly what you want. It's easy to underestimate what's required for a project if you don't look into the implementation details. *Everything* is *conceptually* simple. Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/23/88)
Peter Schachte writes: > But a hypertext system SHOULD. The point is that this approach makes it > possible to deliver small components. By this I don't mean, say, an > individual bar chart, but a new KIND of chart. IFF lets me deliver > individual bar charts. It makes it possible for me to invent a new kind > of chart, but only as part of a program I'm delivering. If someone > wants to be able to incorporate this kind of chart into a document, they > have to convince a purveyor of word processors to do the work. An > object-oriented system would allow the encapsulation of the methods for > handling this type of chart in a single place, so that any program could > use it without having to know about it ahead of time, other than to know > the names of the methods it must support. Peter has it right on the money. Any of you with access to the X11 distribution should take a long, serious look at the Andrew Toolkit, which was distributed on the X tape. ATK is an object-oriented user-interface toolbox that allows one to define a class and methods for user interface objects, and to allow applications to dynamically load these objects in the course of program execution. Each object has a number of "default methods" it must provide -- a FullUpdate method, a method to initialize an instance of this object, and so on. The neat thing is is that if you implement all of these methods, an ATK-based application can use your object without ever having known about it before. There are classes defined for text, raster images, structured-graphics, animations, requesters/dialog boxes, etc. etc. EZ, which is an ATK editor, is capable of editing any ATK object, since it dynamically loads the object plus all of the methods that are needed to work with it. It does not have to know what the object looks like in advance. For example, you can define a Calculator object plus all of the methods of interaction with it. In an EZ document, you can paste the calculator right in the middle and do calculations with your document! Similarly, Messages (the mail-bboard interface that runs on Andrew) allows users to mail or post raster images and other ATK objects anywhere on the system. I should point out that the net.gods have taken notice of this, and want to extend the current Usenet news software to use ATK as a standard for information exchange. Thus in the not-too-far future you may be able to mail and post ATK objects on Usenet. I would really like to see such a system on the Amiga. IFF standards and an iff.library are nice, but they supply exactly the same kind of capability that machines like the Mac currently have. ATK works with X and the Andrew Window Manager, but it was designed to offer independence of particular window system architectures. I'm not saying that ATK is *the* answer (programs written with ATK do tend to be quite large), but such a system would give the Amiga a capability that no other personal computer (or workstation not running the Andrew environment, for that matter) offers. Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "if you ain't ill it'll fix your car"
doug-merritt@cup.portal.com (05/24/88)
Michael Portuesi writes:
:[the Andrew Toolkit] is an object-oriented user-interface toolbox that allows
:one to define a class and methods for user interface objects [...]
:I should point out that the net.gods have taken notice of this, and
:want to extend the current Usenet news software to use ATK as a
:standard for information exchange. Thus in the not-too-far future
:you may be able to mail and post ATK objects on Usenet.
Sounds very interesting. Where's this being discussed? I'd like
more information about this.
I don't have the X tape; is there another way to find out more about
ATK in general?
Doug
--
Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt
or ucbvax!eris!doug (doug@eris.berkeley.edu)
or ucbvax!unisoft!certes!dougmp1u+@andrew.cmu.edu (Michael Portuesi) (05/25/88)
> *Excerpts from ext.nn.comp.sys.amiga: 24-May-88 Re: How 'Bout HyperCard!* > *doug-merritt@cup.portal. (810)* > Michael Portuesi writes: > :[the Andrew Toolkit] is an object-oriented user-interface toolbox that allows > :one to define a class and methods for user interface objects [...] > :I should point out that the net.gods have taken notice of this, and> :want > to extend the current Usenet news software to use ATK as a > :standard for information exchange. Thus in the not-too-far future > :you may be able to mail and post ATK objects on Usenet. > Sounds very interesting. Where's this being discussed? I'd like > more information about this. > I don't have the X tape; is there another way to find out more about> ATK in > general? Yes. Look in the _Proceedings of the USENIX Technical Conference_, Dallas TX, February 1988 for the following two papers: Andrew Palay, et al. "The Andrew Toolkit -- An Overview" Nathaniel Borenstein, et al. "A Multi-Media Message System for Andrew" --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "if you ain't ill it'll fix your car"
jaf@crcmar.crc.uucp (Jonathan Fischer) (05/27/88)
From article <4710@watdcsu.waterloo.edu>, (David Oh): > > As for My computer is better that Yours! arguements, I don't think this is > the place for things like that... I mean, from my end, Amiga owners are > mature and can take tonnes of criticism and don't blindly boast like thost > ST owners who talk before the think. (i've heard outragous things like > the ST has its own Laser Disk and can display pics like those in the > laser disk game Dragonslayer.) PLLLLEEEASSSEEE. Just sit back, and chuckle. > It better for all of us. (And makes us look more professional :-) Okay, sorry, but this is just too much. I've been reading this newsgroup for about a month now, and it's true: from this end, the Amiga owners look very mature and professional, as opposed to those lowlife ST owners who now and then post something inflamatory over here.... But Aha! I own an ST, and for years, in the ST newsgroup, I've been really p.o.'ed at those incredibly immature Amiga owners who would now and then post something really inflamatory and arrogant over in the ST newsgroup.... The point is, statements like the above are simply uninformed, and not at all well-thought-out. Most Amiga owners, and most ST owners, are generally reasonable and NOT as juvenile as the few who can't resist cross- posting something before cooling down and doing some serious proofreading. P.S. That "outrageous thing" mentioned above actually was demoed at some conference or other, some time ago, so whoever told you about it was neither lying nor misled. It never made it to market, however (as far as I know). -- -Jonathan A. Fischer SMARTMAIL: jaf@crcmar.uucp UUCP: ...utzoo!dciem!nrcaer!crcmar!jaf BITNET: jaf%crcmar@UTORGPU ARPA: dgbt@ncs-dre.arpa (<-- specify my name).
peter@sugar.UUCP (Peter da Silva) (06/02/88)
In article ... pds@quintus.UUCP (Peter Schachte) writes:
[ that he wants to do all sorts of wonderful object-oriented stuff ]
OK, Peter. We're agreed that cool object-oriented stuff is a Good Thing.
Talking about it won't do it. Hows about implementing something? The
framework for your object-oriented IPC would be a good start. Put it
into the competition with Pete Goodeve's simpler IFF-oid code.
Or code a simple o-o graphics system. Thanks to LoadSeg() it should'nt
be to hard to implement the object libraries. At least lay out how an
object and accompanying methods should look. Maybe a coded set of entry
points: you LoadSeg() the class and pass it a message. The reply to the
message contains an array containing the addresses of each entry point and
the names of the methods those entry points use. It's the responsibility
of the class to load any superclasses.
SendMethod then becomes:
Look up address of method in class.
If it's not there, go to superclass and keep going.
Call method with an array containing object[s].
Could all be done in 'C'.
Disclaimer: this is all off the top of my head. I've not done a whole lot
of object-oriented programming. Peter Schachte is obviously way ahead of me
here.
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter
-- Disclaimer: These may be the official opinions of Hackercorp.