Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!ut-ngp!werner
From: wer...@ut-ngp.UUCP (Werner Uhrig)
Newsgroups: net.micro.68k,net.micro.mac,net.micro.amiga
Subject: BYTE issue of September 86 focuses on the 68000
Message-ID: <3868@ut-ngp.UUCP>
Date: Sat, 23-Aug-86 18:19:52 EDT
Article-I.D.: ut-ngp.3868
Posted: Sat Aug 23 18:19:52 1986
Date-Received: Sat, 23-Aug-86 22:01:53 EDT
Organization: UTexas Computation Center, Austin, Texas
Lines: 25
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]
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!sri-spam!parcvax!hplabs!sdcrdcf!ism780c!tim
From: t...@ism780c.UUCP (Tim Smith)
Newsgroups: net.micro.68k,net.micro.mac,net.micro.amiga
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <3374@ism780c.UUCP>
Date: Wed, 27-Aug-86 16:08:25 EDT
Article-I.D.: ism780c.3374
Posted: Wed Aug 27 16:08:25 1986
Date-Received: Fri, 29-Aug-86 18:57:40 EDT
References: <3868@ut-ngp.UUCP>
Reply-To: t...@ism780c.UUCP (Tim Smith)
Organization: Interactive Systems Corp., Santa Monica, CA
Lines: 17
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dil...@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.amiga
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <8608292114.AA18102@cory.Berkeley.EDU>
Date: Fri, 29-Aug-86 17:14:03 EDT
Article-I.D.: cory.8608292114.AA18102
Posted: Fri Aug 29 17:14:03 1986
Date-Received: Sat, 30-Aug-86 03:14:25 EDT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 54
>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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!zen!zooey.Berkeley.EDU!c160-aw
From: c160...@zooey.Berkeley.EDU (Christian Wiedmann)
Newsgroups: net.micro.68k,net.micro.mac,net.micro.amiga
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <158@zen.BERKELEY.EDU>
Date: Fri, 12-Sep-86 15:58:34 EDT
Article-I.D.: zen.158
Posted: Fri Sep 12 15:58:34 1986
Date-Received: Sat, 13-Sep-86 03:47:24 EDT
References: <3868@ut-ngp.UUCP> <3374@ism780c.UUCP> <15656@ucbvax.BERKELEY.EDU>
Sender: n...@zen.BERKELEY.EDU
Reply-To: c160...@zooey.Berkeley.EDU.UUCP (Christian Wiedmann)
Followup-To: net.micro.68k,net.micro.mac,net.micro.amiga
Organization: University of California, Berkeley
Lines: 10
Summary: User Interface Rules!
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)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!caip!cbmvax!daveh
From: da...@cbmvax.cbm.UUCP (Dave Haynie)
Newsgroups: net.micro.68k,net.micro.mac,net.micro.amiga
Subject: Re: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <736@cbmvax.cbmvax.cbm.UUCP>
Date: Mon, 15-Sep-86 13:08:57 EDT
Article-I.D.: cbmvax.736
Posted: Mon Sep 15 13:08:57 1986
Date-Received: Tue, 16-Sep-86 05:54:30 EDT
References: <158@zen.BERKELEY.EDU>
Organization: Commodore Technology, West Chester, PA
Lines: 28
> 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.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!husc6!panda!genrad!decvax!mcnc!rti-sel!sas!walker
From: wal...@sas.UUCP (Doug Walker)
Newsgroups: net.micro.68k,net.micro.mac,net.micro.amiga
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <173@sas.UUCP>
Date: Wed, 17-Sep-86 09:32:35 EDT
Article-I.D.: sas.173
Posted: Wed Sep 17 09:32:35 1986
Date-Received: Sat, 20-Sep-86 02:19:31 EDT
References: <3868@ut-ngp.UUCP> <3374@ism780c.UUCP> <15656@ucbvax.BERKELEY.EDU>
<158@zen.BERKELEY.EDU>
Organization: SAS Institute Inc. Cary, NC
Lines: 18
Summary: User Interface
In article <1...@zen.BERKELEY.EDU>, c160...@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.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!voder!apple!lsr
From: l...@apple.UUCP (Larry Rosenstein)
Newsgroups: net.micro.mac,net.micro.amiga
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <167@apple.UUCP>
Date: Fri, 19-Sep-86 12:13:41 EDT
Article-I.D.: apple.167
Posted: Fri Sep 19 12:13:41 1986
Date-Received: Mon, 22-Sep-86 21:21:02 EDT
References: <3868@ut-ngp.UUCP> <3374@ism780c.UUCP> <15656@ucbvax.BERKELEY.EDU>
<158@zen.BERKELEY.EDU> <173@sas.UUCP>
Reply-To: l...@apple.UUCP (Larry Rosenstein)
Organization: Advanced Development Group, Apple Computer
Lines: 47
In article <1...@sas.UUCP> wal...@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: l...@Apple.CSNET
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!caip!sri-spam!nike!ucbcad!ucbvax!
CORY.BERKELEY.EDU!dillon
From: dil...@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.amiga,net.micro.mac
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <8609230545.AA12713@cory.Berkeley.EDU>
Date: Tue, 23-Sep-86 01:45:04 EDT
Article-I.D.: cory.8609230545.AA12713
Posted: Tue Sep 23 01:45:04 1986
Date-Received: Tue, 23-Sep-86 06:03:22 EDT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 54
>(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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!voder!apple!lsr
From: l...@apple.UUCP (Larry Rosenstein)
Newsgroups: net.micro.amiga,net.micro.mac
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <182@apple.UUCP>
Date: Wed, 24-Sep-86 20:07:15 EDT
Article-I.D.: apple.182
Posted: Wed Sep 24 20:07:15 1986
Date-Received: Thu, 25-Sep-86 03:42:06 EDT
References: <8609230545.AA12713@cory.Berkeley.EDU>
Reply-To: l...@apple.UUCP (Larry Rosenstein)
Organization: Advanced Development Group, Apple Computer
Lines: 41
In article <8609230545.AA12...@cory.Berkeley.EDU> dil...@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: l...@Apple.CSNET
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dil...@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.amiga,net.micro.mac
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <8609250635.AA24969@cory.Berkeley.EDU>
Date: Thu, 25-Sep-86 02:35:34 EDT
Article-I.D.: cory.8609250635.AA24969
Posted: Thu Sep 25 02:35:34 1986
Date-Received: Thu, 25-Sep-86 06:17:01 EDT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 60
>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