werner@ut-ngp.UUCP (Werner Uhrig) (08/24/86)
THEME: 68000 MACHINES (p.163) 68000 Trips and Traps (by Mike Morton) Programming in assembly language will help you exploit the 68000 to the fullest. (p.179) UNIX and the MC68000 (by Andrew L. Rood, Robert C. Cline, Jon Brewster) The powerful yet simple programmer's model offered by the 68000's architecture makes UNIX implementation easy. (p.205) A Comparison of MC68000 Family Processors (by Thomas Johnson) High levels of hardware and software compatibility distinguish the five members of this family. (p.223) Atari ST Software Development (by Michael Rothman) A programmer surveys TOS operating system and how the 68000 influences it. (p.241) Amiga Animation (by Elaine A. Ditton and Richard A. Ditton) An exploration of the exciting possibilities of animation on the Amiga. (p.249) Amiga vs. Macintosh (by Adam Brook Webber) A comparison of the system calls on two 68000-based machines reveal one as the clear winner. [the Amiga, if you don't want to wait]
tim@ism780c.UUCP (Tim Smith) (08/27/86)
I am very annoyed by this issue of BYTE. First of all, remember the issue they had earlier this year that was ALL Intel/PC stuff? They said that a later issue would cover 68k stuff. I expected to see an entire issue of 68k stuff. Instead we get a regular issue whose theme is 68k. Arrggghh!! Unless we get a full 68k issue to restore the balance of the universe, it will wobble off its axis and destroy us all!!!! :-) Next, many of the articles are badly done. For example, the Mac vs Amiga article is full of errors ( e.g., nearly everything it says about DAs, and much of what it says about memory allocation ). -- "I *DO* believe in Mary Worth" Tim Smith USENET: sdcrdcf!ism780c!tim || ima!ism780!tim Compuserve: 72257,3706 Delphi || GEnie: mnementh
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/30/86)
>I am very annoyed by this issue of BYTE. First of all, remember >the issue they had earlier this year that was ALL Intel/PC >stuff? They said that a later issue would cover 68k stuff. I >expected to see an entire issue of 68k stuff. Instead we get a >regular issue whose theme is 68k. Arrggghh!! Unless we get a >full 68k issue to restore the balance of the universe, it will >wobble off its axis and destroy us all!!!! :-) "Originally planning for a separate issue of the magazine, we put together a series of articles exploring the MC68000 and many of the machines it powers. Those articles make up this month's theme section and the continuing coverage of the MC68000 that will appear in our Features section over the next several months." -G. Michael Vose, Sen. Tech editor themes. (BYTE september 86 v11-n9) Well, you can't have everything. Seems strange that the Themes editor would say something like that (especially the last line).. Looks like the policy decision caused some disention at BYTE. The articles were geared more to the non-tech people... they didn't have very much deep rooted information in them. >Next, many of the articles are badly done. For example, the Mac vs >Amiga article is full of errors ( e.g., nearly everything it says about >DAs, and much of what it says about memory allocation ). I kinda liked that one. I agree that Mr. Webber made some mistakes, especially in the graphics section... I think he was talking about V1.1 rather than 1.2 . Also, I seem to get the idea that maybe he didn't have a full manual when he wrote the article. He shrugged off the blitter like it was nothing special. Jeeezzzuuss, Thomas Rockiki just posted a 'game of life' program using the blitter. Using (I think it was 9) blitter passes on a 320x200 screen. The entire screen going through 19 generations a second. Pretty wild to look at (I played with it all night). If you start doing some calculations, you find that: 320x200 bits * 9 passes * 19 updates/second ------------------------------------------- 16 bits/word is 6.8 Million accesses per second or a throughput of 13.68 MegaBytes/second. That's a lot to shrug off. However, I rather liked his description of the hackintosh. -Matt
jimomura@lsuc.UUCP (Jim Omura) (08/30/86)
In article <3374@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >I am very annoyed by this issue of BYTE. First of all, remember >the issue they had earlier this year that was ALL Intel/PC >stuff? They said that a later issue would cover 68k stuff. I >expected to see an entire issue of 68k stuff. Instead we get a >regular issue whose theme is 68k. Arrggghh!! Unless we get a >full 68k issue to restore the balance of the universe, it will >wobble off its axis and destroy us all!!!! :-) > Actually, I prefer to see increased 68K coverage on a monthly basis, which I feel *has* been happening, rather than a Byte Special Issue and the same old "mainly IBM-PC, CP/M and Apple II" we saw in the past. Also, I've been *very* glad to see the variety of 68K coverage we've seen so far. Note that the DSI coverage and VME-10 coverage have been in recent issues. I am also glad that the Atari ST and Amiga have been very strongly backed by Byte right from the beginnings of both machines. The support which I've received by BIX in the 'os.9' conference has been very gratifying *even though* OS-9'ers have *not* by and large shown up. The only regret I have is that from what I've heard (and I have not seen the Sept. Byte yet), OS-9 was not covered in this issue. On the otherhand, a lot of the OS-9 stuff just didn't happen over the summer as I expected it would, so I can't really blame Byte for not publishing much on it. >Next, many of the articles are badly done. For example, the Mac vs >Amiga article is full of errors ( e.g., nearly everything it says about >DAs, and much of what it says about memory allocation ). > I can't comment on this because I don't have the September issue yet. -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880
grr@cbmvax.cbm.UUCP (George Robbins) (08/30/86)
In article <8608292114.AA18102@cory.Berkeley.EDU> you write: > "Originally planning for a separate issue of the magazine, > we put together a series of articles exploring the MC68000 > and many of the machines it powers. Those articles make up > this month's theme section and the continuing coverage of the > MC68000 that will appear in our Features section over the next > several months." > -G. Michael Vose, Sen. Tech editor > themes. > (BYTE september 86 v11-n9) > > Well, you can't have everything. Seems strange that the Themes > editor would say something like that (especially the last line).. > Looks like the policy decision caused some disention at BYTE. > > -Matt You can probably translate that as: We were planning on doing a special 68000 issue, but our advertising people couldn't sell enough space in a 68000 only issue to justify the expense... ... just a guess, but Byte is anything but non-profit... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jimomura@lsuc.UUCP (Jim Omura) (09/01/86)
In article <679@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <8608292114.AA18102@cory.Berkeley.EDU> you write: >> "Originally planning for a separate issue of the magazine, >> we put together a series of articles exploring the MC68000 >> and many of the machines it powers. Those articles make up >> this month's theme section and the continuing coverage of the >> MC68000 that will appear in our Features section over the next >> several months." >> -G. Michael Vose, Sen. Tech editor >> themes. >> (BYTE september 86 v11-n9) >> >> Well, you can't have everything. Seems strange that the Themes >> editor would say something like that (especially the last line).. >> Looks like the policy decision caused some disention at BYTE. >> I don't see any 'disention' at all. The point is that 68K coverage is going to be strongly represented in future issues of Byte. This was in my own mind much more important that the Special Issue. I never thought the Special Issue was such a wonderful idea in the first place. If monthly cover- age of the 68K world was going to be negligible on a monthly basis, then why should I or anyone primarily interested in 68K technology subscribe to Byte? It would have been cheaper to buy the special issue and ignore the general monthly issues. The Byte Magazine which we will see in the coming year will be (just as the last year's Byte Magazine has been so far) more worth your subscription dollar than the Byte of the 2-3 years previous from this standpoint. If you have doubts, then start looking back over the magazine from about 1981 onward and add up the column inches and look at the topics covered. > > >You can probably translate that as: > >We were planning on doing a special 68000 issue, but our advertising people >couldn't sell enough space in a 68000 only issue to justify the expense... > >... just a guess, but Byte is anything but non-profit... >-- >Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) I don't think you should read that into the choice. Oh, I expect it *may* have been a factor, but there was likely much more to it. I think that the Special Issues approach wasn't such a wonderful idea in any context. I barely browsed through my IBM-PC Special Issues. I certainly would not have bought one off-the-shelf. Would the IBM special issues have influenced my subscrip- tion? Only negatively. If you get the impression that I would be happy to see Byte drop the special issues completely, you wouldn't be far wrong. Exactly what is the point of Byte as a *monthly* magazine? If the features don't fill the role, then why not just start a smaller quarterly magazine for special topics? -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880
wert@titan.UUCP (09/04/86)
Also, somewhere in this issue is a box detailing all the things that one must do to resize a window (on a Macintosh and on an Amiga). This is presented as a comparison, supposedly demonstrating that the Amiga is better than the Macintosh because you have to do less to resize a window. The operation was expressed as one step for the Amiga, seven (more or less, I don't have it in front of me) for the Macintosh. This is misleading, because in any application that I have ever written, that code appeared once and only once. Ignored is the possibility that the Macintosh method allows greater flexibility, etc. A casual, uninformed reader would conclude that the Amiga was better, and that was the intent of the demonstration. This is yellow journalism to the max, and certainly worthy of The National Inquirer. All in the guise of objectivity. I quit buying BYTE years ago... scott
cmcmanis@sun.UUCP (09/08/86)
In Article <213@dione.rice.EDU>, wert@titan.UUCP (Scott Comer) writes : > Also, somewhere in this issue is a box detailing all the things that one > must do to resize a window (on a Macintosh and on an Amiga). This is > presented as a comparison, supposedly demonstrating that the Amiga is > better than the Macintosh because you have to do less to resize a window. > The operation was expressed as one step for the Amiga, seven (more or > less, I don't have it in front of me) for the Macintosh. > > This is misleading, because in any application that I have ever written, > that code appeared once and only once. Ignored is the possibility that the > Macintosh method allows greater flexibility, etc. A casual, uninformed > reader would conclude that the Amiga was better, and that was the intent > of the demonstration. > > This is yellow journalism to the max, and certainly worthy of The National > Inquirer. All in the guise of objectivity. > > I quit buying BYTE years ago... > scott Why is this misleading? To give my windows on the Amiga the ability to change size dynamically I include the WINDOWSIZING flag and a max.x and max.y size. Everything else is essentially transparent. (I get a message if Intuition thinks I need to refresh my window and when it arrives I just call the routine that redisplays the current state of the window) As for the fact that the MAC way might be more flexible I doubt it. Since with a similar amount of effort I can size my windows in any way I want. I don't know if the point was that the Amiga was "better" because of all this stuff, but it is easier to program window applications and multiple window applications for. I suggest if you gave two equally competent programmerss the task of vreating an application from scratch on both machines and they had both not had any previous experience with the machine they were working with the Amiga programmer would be finished first. Of course with dedicated hackers programming in their "home" environment it would probably be a tie. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
kearns@garfield.columbia.edu (Steve Kearns) (09/09/86)
I have programmed many different window systems and I found the byte article very accurate. The only reason the Macintosh is programmable at all is thanks to "skeleton" programs laboriously created by some people. In the near future the problem will be nicely solved by MacApp; the use of object oriented programming enables new code to go outside of the skeleton program. -steve
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/09/86)
> Xref: cbmvax net.micro.68k:253 net.micro.mac:2584 net.micro.amiga:2500 > > Also, somewhere in this issue is a box detailing all the things that one > must do to resize a window (on a Macintosh and on an Amiga). This is > presented as a comparison, supposedly demonstrating that the Amiga is > better than the Macintosh because you have to do less to resize a window. > The operation was expressed as one step for the Amiga, seven (more or > less, I don't have it in front of me) for the Macintosh. > > This is misleading, because in any application that I have ever written, > that code appeared once and only once. Ignored is the possibility that the > Macintosh method allows greater flexibility, etc. A casual, uninformed > reader would conclude that the Amiga was better, and that was the intent > of the demonstration. > > This is yellow journalism to the max, and certainly worthy of The National > Inquirer. All in the guise of objectivity. > > I quit buying BYTE years ago... > scott -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
DMB@PSUVMA.BITNET (09/12/86)
Macintosh Problems,
What's all this whining about the difficulty of MacPrograms. I find
Lines: 9
Xref: cbatt net.micro.68k:114 net.micro.mac:910 net.micro.amiga:886
the standard interface easy to program, straightforward, and intelligent.
The power of it all is being able to redesign stuff (WDEF's, etc) and
that is the stuff that gives me fits, but then again you deserve some
trouble if you want the power of flexibility.
dave
-
- This morning I was...., oh no, that wasn't me.
munson@ernie.Berkeley.EDU (Ethan Munson) (09/12/86)
I only scanned the coverage, but I did give a quick scan to the Amiga vs. Mac article. It endorsed the Amiga. The author apparently wrote True Basic for the Mac and from what I could tell disliked the Mac because its interface with the _programmer_ was more awkward or time consuming or something. This article is only one man's opinion but I think it may reflect something real. The Amiga has a lot of nifty hardware features that the Mac does not (I'm not sure I care about them myself, but some people do) and I know that the Mac is not particularly easy to program. I think the Mac's strength lies at the user's level rather than the developer's level. Does anyone, particularly someone with experience with both, have any comments on my rambblings? Ethan Munson ARPANET: munson@ernie.berkeley.edu
c160-aw@zooey.Berkeley.EDU (Christian Wiedmann) (09/12/86)
The whole point of the Mac is its User Interface. The strategy is to make all the hardships of using a computer disappear. Naturally, this also forces the programmer to do a lot more. This means that the most accepted way of writing programs will be to use a skeleton such as MacApp. Hopefully there will be enough programmers willing to put up with this hassle, because the market sure needs a computer that's easy to use. Christian Wiedmann (Insert cute signature here)
ken@argus.UUCP (Kenneth Ng) (09/14/86)
In article <158@zen.BERKELEY.EDU>, c160-aw@zooey.Berkeley.EDU (Christian Wiedmann) writes: > The whole point of the Mac is its User Interface. The strategy is to make > all the hardships of using a computer disappear. Naturally, this also forces > the programmer to do a lot more. This means that the most accepted way of > writing programs will be to use a skeleton such as MacApp. Hopefully there > will be enough programmers willing to put up with this hassle, because the > market sure needs a computer that's easy to use. > > Christian Wiedmann > > (Insert cute signature here) But wouldn't good software be easier to write if the programmer didn't have to do so much work? One reason the old Altari 800 became so popular was because the hardware chips made software development so much easier. -- Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp(for a while) ihnp4!allegra!bellcore!argus!ken *** WARNING: NOT ken@bellcore.uucp *** !psuvax1!cmcl2!ciap!andromeda!argus!ken bitnet(prefered) ken@orion.bitnet --- Please resend any mail between 10 Aug and 16 Aug: --- the mailer broke and we had billions and billions of --- bits scattered on the floor.
merchant@dartvax.UUCP (Peter Merchant) (09/14/86)
> > > I don't know if the point was that the Amiga was "better" because of > all this stuff, but it is easier to program window applications and > multiple window applications for. > > I suggest if you gave two equally competent programmerss the task of > vreating an application from scratch on both machines and they had > both not had any previous experience with the machine they were > working with the Amiga programmer would be finished first. Of course > with dedicated hackers programming in their "home" environment it > would probably be a tie. > -- > --Chuck McManis Hmm...amusing thought. But, then, does anybody really create a Macintosh Application from scratch anymore? With things like Skel and such around, when would I ever be writing the code to do that. I did it, just to learn it. After that, I never wrote one again. The only difference is that Apple seems to have put this stuff up out of the ROM and made you write the code. Commodore didn't. Curiousity: Doesn't MPW have code to allow you to do just what was written in the Byte article (ie, "A window was resized. Great.") -- "I'm a shot in the dark without you Peter Merchant A rebel without a clue."
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/15/86)
> Summary: User Interface Rules! > Xref: cbmvax net.micro.68k:272 net.micro.mac:2631 net.micro.amiga:2556 > > The whole point of the Mac is its User Interface. The strategy is to make > all the hardships of using a computer disappear. Naturally, this also forces > the programmer to do a lot more. This means that the most accepted way of > writing programs will be to use a skeleton such as MacApp. Hopefully there > will be enough programmers willing to put up with this hassle, because the > market sure needs a computer that's easy to use. > > Christian Wiedmann > > (Insert cute signature here) The whole point of the article was that the Amiga and MAC user interfaces were performing exactly the same functions, but that the MAC forces the programmer to explicitly call functions to do what the Intuition task on th Amiga does for him automatically. The ease of use here is identical. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
walker@sas.UUCP (Doug Walker) (09/17/86)
In article <158@zen.BERKELEY.EDU>, c160-aw@zooey.Berkeley.EDU (Christian Wiedmann) writes: > The whole point of the Mac is its User Interface. The strategy is to make > all the hardships of using a computer disappear. Naturally, this also forces > the programmer to do a lot more. Yes, but that is NOT the point here. The User Interfaces are basically the same here - window oriented, mouse driven, etc. How does it make the user interface better to force the programmer to work harder? The example cited in the article shows a series of about 8 or 9 steps required on the Mac to resize a window. On the Amiga, it was one step - the system did all the resizing, and just informed you about it. The Amiga method is much better than the Mac method on two counts - 1. it is less work for the programmer, and 2. it encourages a more consistent user interface, since most people will use the system-supplied way rather than go to all the trouble of doing it like the Mac. I agree that it is better to force the programmer to do all that than to be lazy and use a DOS-type interface, but I think that if it can be done the easy way rather than forcing programmers to do that much, so much the better.
tim@ism780c.UUCP (Tim Smith) (09/18/86)
In an article daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: > >The whole point of the article was that the Amiga and MAC user interfaces >were performing exactly the same functions But they were performing those functions in isolation ( I assume we are still talking about changing window size. If not, forget the rest of this posting ). A Mac program is event driven. It consists of a loop that asks the system for events, and then processes them. If all your program is doing is sticking up a window ( i.e., no menus, no dialogs, etc ), then there is extra work because you have to write the event loop. If your program is doing real stuff, then dealing with windows is just one more case statement in the event loop and is no big deal. Besides, most programmers don't have to write this extra stuff more than once or twice. For example, whenever I start to write something on the Mac, I start with my most similar previous program, and change it. -- scum scum scum scum scum scum scum scum SCUM! Wonderful scum scum scum scum Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 Delphi or GEnie: mnementh
lsr@apple.UUCP (Larry Rosenstein) (09/19/86)
In article <173@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: >The example cited in the article shows a series of about 8 or 9 steps >required on the Mac to resize a window. On the Amiga, it was one step - >the system did all the resizing, and just informed you about it. The >Amiga method is much better than the Mac method on two counts - 1. it is >less work for the programmer, and 2. it encourages a more consistent user >interface, since most people will use the system-supplied way rather than >go to all the trouble of doing it like the Mac. Two points to make here. (1) On the Mac there are high level tools that implement features like window resizing automatically. In MacApp, for example, the programmer writes no code to resize windows. MacApp also takes care of more complicated things like printing, scrolling, and document opening/closing. MacApp also encourages a consistent user interface and improves programmer productivity. I think it goes further than the Amiga in both those areas, simply because it takes a much higher level approach. (I use MacApp as an example simply because I have been working on implementing it; there are equivalent frameworks available for sale and as shareware/public domain software. In addition, once a programmer has finished one Mac project s/he usually has implemented an application framework that can use reused over and over again.) (2) One thing that no one has mentioned yet is how does the Amiga system software manages scroll bars. The example in BYTE listed several steps on the Mac side for moving and resizing scroll bars. Since I don't know anything about the Amiga, I would like to see a short description of how a programmer specifies where the scroll bars belong in a window, and how much space this specification requires. The Mac architecture give the programmer the flexibility to have status windows adjacent to the scroll bars (as in Microsoft Word and File, Pagemaker, and MPW Shell). I want to hear how the Amiga software would handle a similar feature. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
hadeishi@h-sc4.harvard.edu (mitsuharu hadeishi) (09/22/86)
The important point made by the author of the Amiga-Mac article in the September 86 BYTE issue was that it was a lot easier for the programmer to implement a friendly user interface on the Amiga than on the Mac. The example given, that of resizing a window with a scroll bar, is indicative of the different level of support the operating system gives the programmer. In the case of the Mac, it is a very complex and lengthy process to resize such a window, whereas on the Amiga the operation is simple, from the programmer's point of view. From the user's point of view the two machine appear identical; however if it is easier for the programmer then A) the programmer is free to concentrate on details of the program's operation, thereby enhancing the product the user is using, and B) programs can be written much more quickly and with less debugging. These two points can potentially make a great deal of difference for the\ average user. It is also true that lazy programmers can write programs with crummy user interfaces; but this can also be done on the Mac (although it typically is not done.) -Mitsu (hadeishi@h-sc4.UUCP)
werner@ut-ngp.UUCP (Werner Uhrig) (09/23/86)
one "shy" contribution to the discussion comparing Amiga and Mac (which is totally above my head otherwise). If a "later" product is not "better", it is "worse" .... Even though it is not necessarily true that the Amiga was developed as a competitor to the Mac, at least not early on, it is, however, still true that it is the "later" product and there should have been some time to learn, at least, some lessons from the Mac. Given the checkered history of hardware and software development of the Amiga, it is not really surprising that it disappointed those of us that hoped for a machine that the "Mac should have been but wasn't". With years passed, even IBM PCs have become somewhat useful machines now, even though I never had the patience to bother with one. The Mac, however, had promise from the start when it was only a "toy" machine, even though it is my feeling that Apple made as many hardware and software mistakes with the Mac, as it did brilliant features. With time, the machine has grown and things have improved, but there are inherent shortcomings in the design which only a new machine-design will be able to overcome. And that machine is just around the corner (to believe the rumours), even though I wonder, and very much at that, what new pitfalls the new Operating System is going to contain. How the hell Apple is going to marry the "friendly" Mac-user-interface with UNIX-flexibility and stay upward compatible without falling into a snake's nest of bugs *AND* still be efficient in execution is beyond me. I expect '87 will hear a lot of moaning from Mac-Users that migrate early to that "new" machine. On the other hand, MPW and MacApp will make a lot of developers happy, that have suffered through Lisas and early releases of Inside Macintosh. The Amiga, on the other hand, had a lot more promise right from the start in some California garage, and if only luck had blessed the hardware design and married it with the right kind of money and software-development teams, this article might well have been written on an Amiga (or rather, not been written at all; about 2 years ago, I actually expected to be using an Amiga by now). Alas, while the Amiga is not quite dead yet (and I still wish it well), I think the "window" for it has just about disappeared. While I have friends that have found the Amiga to be a useful tool for some special applications, I can't see sales reach "critical mass" numbers that will generate the quantity and quality of independent software developers that is needed to make the machine a success. I'd be happy for events to prove me wrong, so anyone that is terrible optimistic about hardware and software is welcome to fill my mailbox with "good news," but I am not out looking for either a discussion or an argument, but will soak up whatever information will show up here. PS and BTW: I posted that first article with the pointer to the Byte-issue focusing on the 68,000 *WITHOUT* having read it; when I did read it I was tempted to cancel my article *AND* my subscription to Byte because I was so disappointed by the quality of the articles. From what others had to say about it, I see I'm not alone in that reaction to the issue ....Oh well, it's even less effort not to resubscribe ..
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/23/86)
>(2) One thing that no one has mentioned yet is how does the Amiga system >software manages scroll bars. The example in BYTE listed several steps on >the Mac side for moving and resizing scroll bars. Since I don't know >anything about the Amiga, I would like to see a short description of how a >programmer specifies where the scroll bars belong in a window, and how much >space this specification requires. Ok, in this answer I'm assuming you're talking about little sliding-box gadgets that allows you to specify what part of a much larger window or document is to be displayed in the on-screen window. Implimentation on the amiga is as follows: -Create a Proportional gadget for the scroll bar(s). Simple flags within the gadget structure tells intuition whether it's in a border (in which case the border is modified to take into account the gadget), and whether the gadget is relative to the window size (so it changes size dyanmically and automatically when you resize a window) The proportional gadget structure can handle both 1D (slim-rectangle) or 2D (box). Thus, the gadget in Preferences to center the screen on the monitor is simply a 2D gadget. Usually one uses two 1D prop gadgets to control what part of a much larger bitmap you are looking at (example: the new Lines demo runs in something like 1000x800, but its window can be any size up to 640x200). -In the message stream comming from intuition, you place a case for that particular gadget being activated and have code to handle it. However, this entails less work than you might think. Since standard intuition windows utilize cliprects, you don't have to do anything special with the graphics functions in the rest of the program. Using the example of the Lines demo again: The routines to draw the lines don't know or care how large the viewing window is, they simply do the graphics calls over 1000x800. The graphics functions will handle, through cliprects, what is actually displayed within the viewing window. >The Mac architecture give the programmer the flexibility to have status >windows adjacent to the scroll bars (as in Microsoft Word and File, >Pagemaker, and MPW Shell). I want to hear how the Amiga software would >handle a similar feature. You weren't explicit enough for me to come up with a better example. Certainly, the easiest way of doing something like this is to simply open two windows and place them next to each other (or one on top of another) ... etc.. in any way you wish. As I said before, cliprects are completely integrated with the graphics functions and a program doesn't (need to) know or care whether there are other windows over its window or not. Another method is to simply link in a gadget in the border region right next to the scroll bars. (the gadget would be a simple bitmap). -Matt
lsr@apple.UUCP (Larry Rosenstein) (09/25/86)
In article <8609230545.AA12713@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >Ok, in this answer I'm assuming you're talking about little sliding-box >gadgets that allows you to specify what part of a much larger window or >document is to be displayed in the on-screen window. > >Implimentation on the amiga is as follows: What about the scroll and paging arrows? On the Mac, a scroll bar consists of 5 parts: up/down arrows (scroll by a small amt), up/down pagers (scroll by screenful), and scroll box (random access scrolling). Proportional gadgets sound like just the last of these. From a quick scan of the Intuition manual it seemed that you have to add 4 button-type gadgets to implement the arrows and pagers. Is that right, and does the system automatically move and resize all 5 gadgets? (If you resize the window, you want the proportional gadget to grow and shrink, and the 4 button gadgets to remain adjacent to it.) > You weren't explicit enough for me to come up with a better example. Sorry. I was talking about a small status area within a window. For example, the bottom edge of a window looks like: | status area |<=======scroll bar ======>| In other words, the horizontal scroll bar does not extend to the left edge of the window, leaving room for status information without using up too much of the window. My question was whether this case was automatically handled by the Amiga software. Thanks for the informative reply. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/25/86)
>Larry Rosenstein writes: >What about the scroll and paging arrows? On the Mac, a scroll bar consists >of 5 parts: up/down arrows (scroll by a small amt), up/down pagers (scroll >by screenful), and scroll box (random access scrolling). Proportional >gadgets sound like just the last of these. > >\From a quick scan of the Intuition manual it seemed that you have to add 4 >button-type gadgets to implement the arrows and pagers. Is that right, and >does the system automatically move and resize all 5 gadgets? (If you >resize the window, you want the proportional gadget to grow and shrink, and >the 4 button gadgets to remain adjacent to it.) Right, you could impliment the up/down arrows and pagers with boolean gadgets, and the scroll box with a proportional gadget. You can specify that the system automatically resize the proportional gadget, and make all of them relative to the window top or bottom and right or left borders (satisfying all the requirements). That much Intuition will handle. All you have to do is wait for the activation messages. >Sorry. I was talking about a small status area within a window. For >example, the bottom edge of a window looks like: > > | status area |<=======scroll bar ======>| > >In other words, the horizontal scroll bar does not extend to the left edge >of the window, leaving room for status information without using up too much >of the window. My question was whether this case was automatically handled >by the Amiga software. > >Thanks for the informative reply. On the amiga, the top border is taken up by: |close-gadget|<===title and scroll bar===>|back-gadget|front-gadget| (an example of the configuration one uses the most often). Usually Only Intuition puts gadgets in this area. However, you can place your own gadgets here also. All you have to do is give them a priority higher than intuition's gadgets and they'll appear on top of them. (The priority is determined by a gadget's position in the gadget list). Thus, you could create a gadget overiding the left side of the scroll bar and put whatever you want in it. This works fine. This doesn't require much more work than normal gadget creation. Alternately, you could: -Not worry about gadgets and write directly over the title (not completely kocher, but it can be made clean). This involves including the ACTIVE/INACTIVE and other IDCMP message whos intuition operation would rewrite (or do something to) the title area. -Use the window title as your status area via Intuition calls to set the text. -Matt
higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (09/25/86)
In article <182@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >In article <8609230545.AA12713@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>Ok, in this answer I'm assuming you're talking about little sliding-box >>gadgets that allows you to specify what part of a much larger window or >>document is to be displayed in the on-screen window. >> >>Implimentation on the amiga is as follows: > >What about the scroll and paging arrows? On the Mac, a scroll bar consists >of 5 parts: up/down arrows (scroll by a small amt), up/down pagers (scroll >by screenful), and scroll box (random access scrolling). Proportional >gadgets sound like just the last of these. > Correct. >From a quick scan of the Intuition manual it seemed that you have to add 4 >button-type gadgets to implement the arrows and pagers. Is that right, and >does the system automatically move and resize all 5 gadgets? (If you >resize the window, you want the proportional gadget to grow and shrink, and >the 4 button gadgets to remain adjacent to it.) You wouldn't need to resize non-proportional gadgets (arrows), but yes, Intuition does reposition them (if programmed as position dependent relative to the appropriate window boarders), and will automatically size the proportional gadget. >> You weren't explicit enough for me to come up with a better example. > >Sorry. I was talking about a small status area within a window. For >example, the bottom edge of a window looks like: > > | status area |<=======scroll bar ======>| > >In other words, the horizontal scroll bar does not extend to the left edge >of the window, leaving room for status information without using up too much >of the window. My question was whether this case was automatically handled >by the Amiga software. > Yes, no problem - proportional gadget position over to the right, and a program can render right into the windows borders for status info. >Thanks for the informative reply. I hope it helped. > >-- >Larry Rosenstein > >Object Specialist >Apple Computer > >AppleLink: Rosenstein1 >UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr >CSNET: lsr@Apple.CSNET Paul Higginbottom Disclaimer: I do not work for Commodore, and my opinions are my own.
hadeishi@husc4.harvard.edu (mitsuharu hadeishi) (09/26/86)
In article <4027@ut-ngp.UUCP> Werner Uhrig writes: > If a new machine isn't better, it is worse . . . Obviously you know very little about the Amiga. The Amiga IS better than the Mac, in many ways, and in ways which make it intrinsically more adaptable to the future than the Mac design. First of all, it has a well-defined high-performance expansion architecture, otherwise known as (the option to have) "slots". With this you can easily add 68020's, 68881's, (running at 14Mhz!), 68030's possibly in the future, expansion RAM, mutifunction cards, very-high-performance hard disk drives, and a whole plethora of hardware yet to be manufactured. This is backed up by a well-thought out operating system support called the "autoconfiguration standard" which allows the system to automatically configure itself to the presence of almost any kind of expansion hardware you can imagine. Secondly, the Amiga has a very efficient (fast) multitasking multiwindow multiscreen operating system including message passing and generalized event processing which is far more sophisticated than the Mac operating system. This means that programs written NOW will run perfectly well on future systems with much more power, UNIX compatibility, etc. The Mac software architecture, although revolutionary in its time, makes it MUCH more difficult for old applications to run comfortably in a multitasking environment (and much less efficient, since an event loop is inherently less efficient than a event-driven task (that uses task Wait()ing.)) The Amiga also, out of the box, will be able to upgrade to full 640x400 color screen with NO FLICKER once the price of high-persistence RGB monitors falls within reach. This resolution is much higher than the Mac and allows very detailed, colorful screens. (High-persistence RGB monitors are the same as low-persistence with the exception of about a $3 difference in phosphor cost. The only reason for high price was low demand. With the Amiga, there is VERY high demans for these kinds of monitors.) In is perfectly reasonable to expect a machine to go slow in the first couple years; after all, EVERY machine EVER introduced pretty much had no software to speak of for at LEAST one to two years after its introduction. (Here I am speaking of the Apple II, the IBM PC, the Macintosh, especially.) The point is that the Amiga, AT THE OUTSET, is a better machine to develop for, and is easier to program. The existence of MacApp changes this somewhat, but future tools for the Amiga should promise to take things way beyond what Mac developers call sophisticated tools. (Metascope and the new Aztec multitasking debuggers already put Macsbug to shame.) This is not to say the Mac doesn't have good tools, but that the operating system is outmoded and needs revamping (read: the Mac needs Servant.) Sales for the Amiga have been quite high, and have passed the 100,000 mark by now (the actual number seems to be shrouded in secrecy, but I think this number is a pretty accurate figure, plus or minus 20,000, based on data from Dataquest, Commodore, and Future Computing.) It takes a while, folks, to develop really hot applications for a new machine, but believe me, really hot applications are being developed for this machine. At first PC owners had to put up with Wordstar (UGH), Mac owners had to deal with an excruciatingly slow MacWrite that could only handle (max) 10 pages of text, Apple II owners could play Breakout with their machines, etc. On the Amiga? Well, why don't you Mac owners visit your friend's Amiga and give it a spin? Then compare it with the Mac after a year. The Amiga clearly IS better. -Mitsu
tim@ism780c.UUCP (Tim Smith) (09/26/86)
In article <255@husc6.HARVARD.EDU> hadeishi@husc4.UUCP (mitsuharu hadeishi) writes: > >Mac software architecture, although revolutionary in its time, makes >it MUCH more difficult for old applications to run comfortably in a >multitasking environment (and much less efficient, since an event loop >is inherently less efficient than a event-driven task (that uses >task Wait()ing.)) Not so. Most Mac applications that don't do things that Apple says not to do should have no trouble in a multitasking environment. The main problems with multitasking on the Mac are in the OS, not the applications. MultiMac showed that most Mac applications can deal with multitasking. Also, I don't think that a polled event loop has to be "much less" efficient. When there is no event for the process, GetNextEvent will just return a null event. The process would most likely then just call GetNextEvent again. This is less efficient, but not by much. -- What's the difference between a duck? Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 Delphi or GEnie: mnementh
tim@hoptoad.uucp (Tim Maroney) (09/29/86)
Hertzfeld recently admitted that the Mac OS just did not work well for
multitasking. I wasn't there, but I see a number of reasons.
First, the whole idea of low-memory globals. A lot has to be switched in
and out with each context switch. Even on a memory-managed system, the
switch would require a lot of actual variable setting rather than a single
change to a memory map register, because some of the globals needing
switching are in the middle of generally global (non-switched) areas, and
there are global areas in the middle of switched areas.
I have a paper design that removes the global-switching overhead for most
context switches, but it is not pretty, and for some applications (those
that access lots of low-memory globals themselves, rather than leaving them
for the managers) it will degrade to the simplistic algorithm. Even in this
design, there are still around eighty bytes that have to be switched every
time, which also requires cycles for the code to do the switching as well as
for the switched data.
Second, the system file. This requires the ugliest part of Switcher context
switching: all resources in the system file which are not marked for the
system heap must be switched in the system file resource map on each context
switch. There is no way this could be sped up with memory management.
Also, any application may now add resources to the system file, meaning the
file can be corrupted, crashing everyone else.
Third, the system heap. This is a very bad idea on a multitasking, memory
managed system; and multitasking, non-memory managed systems tend to crash a
lot. The problem is that existing applications are perfectly capable of
allocating storage in the system heap, meaning they need write access to the
system heap zone; they almost always reference resources in the system heap,
so they need read access as well. This means any process can see data
belonging to other processes, a security hole; and any process can run amuck
and corrupt the system heap, causing the whole system to crash.
Fourth, the asynchronous parts of the system, particularly the vertical
retrace queue and file/device completion routines. These just don't work
with memory management, because user processes can't be allowed to run in
the OS kernel memory environment. Some way has to be found to make them run
in the user process space after scheduling the process to run; but
applications may depend on them running asynchronously as soon as possible.
For these reasons, I think Apple is going to have to do an incompatible
revision of the operating system to support multitasking really well. It
will have to get rid of the system heap, redefine the role of the system
file, get rid of all switched low-memory globals, and redefine asynchronous
parts of the operating system. This is not impossible; remember that
converting to HFS required new versions for half or more of the released
applications. I'm just sorry they didn't have the foresight to deal with
these issues during the design of the operating system.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)farren@hoptoad.uucp (Mike Farren) (09/30/86)
In article <3681@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: > >...I don't think that a polled event loop has to be "much less" efficient. >When there is no event for the process, GetNextEvent will just return a >null event. The process would most likely then just call GetNextEvent >again. This is less efficient, but not by much. > By a lot. Remember, all of the time that's being used by your process to poll GetNextEvent, PLUS all of the time that is taken to do a context switch to allow your process to run, would ALL be available for some other process to use if you weren't polling, but instead sleeping in a Wait() state. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"