cpetterb@glacier.sim.es.com (Cary Petterborg) (04/02/91)
The Amiga has been out for years now. There have been improvements made to the custom chips, Agnus in particular. But, I am amazed at the fact that their clock speed, etc. has remained the same. In an industry where last years chip runs twice as fast this year, C= sure has sat back on their b*tts as far as performance is concerned. Is it because they aren't willing to invest any more money into the technology because they can sell so many A500's as they are now? What gives? Certainly the technology exists to speed them up. Cary PS. Sorry if this has already been discussed much. I just got back to reading this and other Amiga newsgroups. -- _______________ Cary Petterborg (801)582-5847 x6446 Evans & Sutherland Computer Corp. Simulation Division SLC, UT 84108 UUCP: ...!uunet!sim.es.com!cpetterb *NET: cpetterb@glacier.sim.es.com
daveh@cbmvax.commodore.com (Dave Haynie) (04/03/91)
In article <CPETTERB.91Apr2105151@mickey.glacier.sim.es.com> cpetterb@glacier.sim.es.com (Cary Petterborg) writes: >The Amiga has been out for years now. There have been improvements >made to the custom chips, Agnus in particular. But, I am amazed at >the fact that their clock speed, etc. has remained the same. In an >industry where last years chip runs twice as fast this year, C= sure >has sat back on their b*tts as far as performance is concerned. Is >it because they aren't willing to invest any more money into the >technology because they can sell so many A500's as they are now? >What gives? Certainly the technology exists to speed them up. Well, yes and no. First of all, you're confusing two problems. CPU speedup have been going on for quite some time. But that's pretty independent of the rest of the world. And it doesn't generally take lateral leaps. For example, Motorola would have had a faster 68000 much sooner than the 68020 if all they did was convert the 68000 over to high speed CMOS. But not soon enough to not go ahead with the more advanced 68020 architecture. That's pretty typical of the industry. Specific to the Amiga, there were several problems. First of all, the video chips are directly tied to video. If you speed up the bus cycle, you speed up the video shift rate, unless you go to a multiple of it. The current Agnus runs a 280ns cycle. To double that, and go to 140ns, you would need 60ns DRAM, which are only now becoming available in large quantities, and are still quite expensive (though, if they're on schedule, they'll get cheap in the next year or so). Any somewhat faster bus speedup and you lose NTSC or VGA scan and pixel rates. While it's conceivable that you could divorce the scan rate from the bus rate, that's a MAJOR architectural change, far more complex than building new chips that speed up in other ways (32 bit bus is the way the microprocessors gained their modern speed, more than clock rate speedups). -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
xgr39@CCVAX.IASTATE.EDU (Marc Barrett) (04/03/91)
In article <CPETTERB.91Apr2105151@mickey.glacier.sim.es.com>, cpetterb@glacier.sim.es.com (Cary Petterborg) writes: >The Amiga has been out for years now. There have been improvements >made to the custom chips, Agnus in particular. But, I am amazed at >the fact that their clock speed, etc. has remained the same. In an >industry where last years chip runs twice as fast this year, C= sure >has sat back on their b*tts as far as performance is concerned. Is >it because they aren't willing to invest any more money into the >technology because they can sell so many A500's as they are now? >What gives? Certainly the technology exists to speed them up. Here is why Commodore has not improved the Amiga's custom chipset. The following table lists the amounts that Commodore has invested in R&D since 1984, both as a raw figure and as a percentage of total sales (the better figure for comparing companies): Commodore International, Ltd. ----------------------------------------------- Year | Total Sales | R&D | R&D as % of Sales | ----------------------------------------------- 1990 | 887.3 | 27.7 | 3.12 % | 1989 | 939.7 | 19.3 | 2.05 % | 1988 | 871.1 | 15.4 | 1.77 % | 1987 | 806.7 | 16.4 | 2.03 % | 1986 | 889.3 | 36.8 | 4.14 % | 1985 | 883.1 | 46.5 | 5.27 % | 1984 | 1267.2 | 40.3 | 3.18 % | ----------------------------------------------- However, looking at stats from a single company is not very useful. Therefore, let's look at the same figures for a *REAL* company, one whose management knows exactly what they are doing: Sun Microsystems ------------------------------------------------ Year | Total Sales | R&D | R&D as % of Sales | ------------------------------------------------ 1989 | 1765.366 | 234.1 | 13.26 % | 1988 | 1051.618 | 139.9 | 13.30 % | 1987 | 537.537 | 69.6 | 12.94 % | 1986 | 210.104 | 30.6 | 14.59 % | 1985 | 115.249 | 15.2 | 13.18 % | 1984 | 38.860 | 4.8 | 12.38 % | ------------------------------------------------ As you can see, compared to SUN, Commodore has never invested much in their own future, which is the reason why the custom chipset is so ancient, and why improvements are nowhere in sight. This information also gives us some insight into the success of the two companies. As you can see from the first table, between 1984 and 1990, Commodore's total sales steadily declined. The decline is actually much worse than it appears, once you take inflation into account. A look at Sun, however, shows a different story. This company is run by management that is totally committed to the R&D process, and it shows, both from their R&D investments and their corporate growth. Between 1984 and 1989, Sun grew at a very impressive rate of 200% per year. This is very good for a company that was only founded in 1983. The results are very apparent. Sun controls a very respectable percentage of the worldwide workstation market, and there are actually more active readers of the comp.sys.amiga newsgroups who work for Sun than who work for Commodore. BTW, there is more to these R&D figures than just development of future chipsets. The R&D budgets given in these tables are the total R&D investments, including both software and hardware R&D. If you look around at what Commodore has been doing lately, you can easily see that Commodore seems to be putting more priority into software projects (especially AmigaDOS and UNIX) than into development of future hardware. This lowers the amounts that Commodore has actually been spending on development of the chipset. If software R&D only accounts for 50% of Commodore's total R&D budget (a conservative figure, since I think it accounts for more), and 'other hardware projects' account for 50% of Commodore's hardware R&D budget, then this leaves only a tiny portion of an already-tiny R&D budget for devlopment of that chipset. It is no wonder why that improved chipset is so very long-delayed. This also explains more than just why the heart of the Amiga's hardware is so old and frail. It also explains why more than six years have gone by between when the Amiga's original O.S. was finished and a truly significant update was available. It also explains many significant features -- including virtual memory, memory protection, resource tracking, and device-independent video -- are still absent from the Amiga's O.S. I sill maintain that there are no valid reasons why that 32-bit 'Super ChipSet' should not be available right now. Sun started devlopment of their first RISC microprocessors in 1984, and was shipping complete systems based on these microprocessors in 1987. Sun was still a very small company during these years, and yet they were able to develop the SPARC microprocessor completely from scratch and ship complete systems based on the SPARC in less than four years. By comparison, with the 'Super ChipSet' Commodore has it made. Commodore is still a much bigger company now than Sun was at that time, and Commodore is not designing from scratch but is merely improving an existing design. Despite this, more than five years have gone by since the original chipset was finished and significant improvements are still 2-3 years away. Short Bibliography: The tables containing the R&D and Total Sales information for Sun and Commodore came from the Moodies OTC and Moodies International volumes, respectively. The information about the development of the Sun SPARC microprocessor came from The Sun Technical Journal, in a paper called 'The SPARC Papers'. Check this information for yourself if you wish to verify this information. > >Cary > >PS. Sorry if this has already been discussed much. I just got back to >reading this and other Amiga newsgroups. >-- >_______________ >Cary Petterborg (801)582-5847 x6446 >Evans & Sutherland Computer Corp. Simulation Division SLC, UT 84108 >UUCP: ...!uunet!sim.es.com!cpetterb *NET: cpetterb@glacier.sim.es.com -MB- ---------------------------------------------------------- / Marc Barrett | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ----------------------------------------------------------
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (04/03/91)
I'm not going comment on your 'charts' because I have no idea what the units on your numbers mean. And in the past you have demonstrated your inability to read market statistics, so for all I know, those numbers could be the number of pizzas C= execs ordered last year. You still have no idea what your talking about and you fail to see the big picture. Sun innovated SPARC. What have they done since then? Refined it. Amiga innovated the custom chips, they have been refined since then. You don't know what it takes to build a 32bit faster chip set, your clueless. Consider the ramifications: The Amiga is mainly a 16bit machine except for the A3000, so what about all those other models out there? The majority of the machines are A500s. Redesigning the custom chips means breaking most of all the software out there. It also means abandoning the low-end machines. Do we really want to do that? Now let's consider this question Marc. Why hasn't MS-DOS been significantly improved? The answer is, because of its design limitations any 'quantum leap' or major improvements will break BILLIONS of dollars of software. The Amiga, by design, uses a shared memory model to achieve its speed. This rules out memory protection. Also by design, resource tracking ala UNIX is impossible since Amiga programs are allowed to allocate a resource and pass it to another task, then exit cleanly. Sure, code can be added to allow programs to request tracking of certain resources, but this won't do a bit of good to poorly written programs that haven't been updated. And back to memory protection, about 80% (probably higher) of Amigas don't have MMU's, so how the hell are you going to provide memory protection. Are you suggesting Commodore release a different version of the OS for MMU machines? WHat about software that has been following Commodore rules for years where passing a memory pointer to another task is legal? Every time you press a key on your keyboard this is happening. If Amiga dropped it's memory sharing message system it would be dog slow. Resource tracking on 68000s would eat up huge amounts of ram and be dog slow. Memory protection is impossible without an MMU and so is Virtual Memory(UNIX flavor). Device independence would be good, but on 68000 machines it would slow them down. You see Marc, you fail to consider the big picture and how hard these problems are to solve. Throwing money at them doesn't help. The IBM Market beeen trying to solve the MS-DOS problem for years throwing more R&D (total market wise) than Commodore's total net worth. Do you think if we invested 100 billion dollars in AIDS research we could cure it in a month? These problems aren't impossible, but they are difficult. Somewhere along the line a trade off is to be made. Do we abadon the 16bit Amigas? Remember how many A1000 owners got hurt when it got abadoned? Do we sacrifice the Amiga's performance so it can look like UNIX and run slower? Shall we break thousands of software titles to solve a problem that can be solved by good programming and debugging? If you think these problems are easy, when don't you write/draw up your new custom chip designs and send them to Commodore? Why don't you post your solutions to the Memory Protection/Resource Tracking/Device Independence problems? If they're viable, you might(I hope not) have yourself a job working at Commodore. -- /~\_______________________________________________________________________/~\ |n| rjc@albert.ai.mit.edu Amiga, the computer for the creative mind. |n| |~| .-. .-. |~| |_|________________________________| |_| |________________________________|_|
daveh@cbmvax.commodore.com (Dave Haynie) (04/04/91)
In article <1991Apr2.235710.13984@news.iastate.edu> xgr39@CCVAX.IASTATE.EDU writes: > I sill maintain that there are no valid reasons why that 32-bit >'Super ChipSet' should not be available right now. Sun started >devlopment of their first RISC microprocessors in 1984, and was >shipping complete systems based on these microprocessors in 1987. >Sun was still a very small company during these years, and yet they >were able to develop the SPARC microprocessor completely from scratch >and ship complete systems based on the SPARC in less than four years. >By comparison, with the 'Super ChipSet' Commodore has it made. So, let's look at that. Sun got to start from scratch, nothing at all to be compatible with. With semiconductor partners, rather than doing all the chip fab stuff themselves. On a simpler design (eg, fewer transistors) than an improved chip set would entail. And still, it took them four years. >Commodore is still a much bigger company now than Sun was at that >time, and Commodore is not designing from scratch but is merely >improving an existing design. ECS was just an improvement to the existing chips. We have been shipping some ECS chips in systems for quite some time, in A2000s and laters A3000s. Any improvement beyond ECS would require "designing from scratch", though of course you are totally ignorant of the chip design process and would not be expected to understand any of the details involved. >Despite this, more than five years have gone by since the original chipset was >finished and significant improvements are still 2-3 years away. With the same degree of accuracy, I could claim that your eventual degree is at least 5-10 years away from being granted. Since I know absolutely nothing about the subject at hand, it's a complete shot in the dark. > ---------------------------------------------------------- > / Marc Barrett | BITNET: XGR39@ISUVAX.BITNET / >/ ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / >---------------------------------------------------------- -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
cpetterb@glacier.sim.es.com (Cary Petterborg) (04/04/91)
In article <20324@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > In article <1991Apr2.235710.13984@news.iastate.edu> xgr39@CCVAX.IASTATE.EDU writes: > > > I sill maintain that there are no valid reasons why that 32-bit > >'Super ChipSet' should not be available right now. Sun started > >devlopment of their first RISC microprocessors in 1984, and was > >shipping complete systems based on these microprocessors in 1987. > >Sun was still a very small company during these years, and yet they > >were able to develop the SPARC microprocessor completely from scratch > >and ship complete systems based on the SPARC in less than four years. > >By comparison, with the 'Super ChipSet' Commodore has it made. > > So, let's look at that. Sun got to start from scratch, nothing at all to > be compatible with. With semiconductor partners, rather than doing all the > chip fab stuff themselves. On a simpler design (eg, fewer transistors) than > an improved chip set would entail. And still, it took them four years. > > >Commodore is still a much bigger company now than Sun was at that > >time, and Commodore is not designing from scratch but is merely > >improving an existing design. > > ECS was just an improvement to the existing chips. We have been shipping some > ECS chips in systems for quite some time, in A2000s and laters A3000s. Any > improvement beyond ECS would require "designing from scratch", though of course How long did it take C= to design the first chips? Should it take any longer to develop the next set? > you are totally ignorant of the chip design process and would not be expected > to understand any of the details involved. > > Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "That's me in the corner, that's me in the spotlight" -R.E.M. > Cary -- _______________ Cary Petterborg (801)582-5847 x6446 Evans & Sutherland Computer Corp. Simulation Division SLC, UT 84108 UUCP: ...!uunet!sim.es.com!cpetterb *NET: cpetterb@glacier.sim.es.com
milamber@caen.engin.umich.edu (Daryl Scott Cantrell) (04/04/91)
In article <1991Apr2.235710.13984@news.iastate.edu> xgr39@CCVAX.IASTATE.EDU writes: >In article <CPETTERB.91Apr2105151@mickey.glacier.sim.es.com>, cpetterb@glacier.sim.es.com (Cary Petterborg) writes: >[...] >available. It also explains many significant features -- including >virtual memory, memory protection, resource tracking, and >device-independent video -- are still absent from the Amiga's O.S. >[...] What is the big deal about memory protection and resource tracking? Sure, it might be a nice toy, but it wouldn't be real useful on a single-user system. Is this one of those things people want just because Unix has it? > / Marc Barrett | BITNET: XGR39@ISUVAX.BITNET / >/ ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / -- +---------------------------------------+----------------------------+ | // Daryl S. Cantrell | These opinions are | | |\\\ milamber@caen.engin.umich.edu | shared by all of // | | |// Evolution's over. We won. | Humanity. \X/ | +---------------------------------------+----------------------------+
jimm@amiga.UUCP (Jim Mackraz) (04/04/91)
In article <1991Apr3.130218.25163@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
)
) I'm not going comment on your 'charts' because I have no idea what the
)units on your numbers mean. And in the past you have demonstrated your
)inability to read market statistics, so for all I know, those numbers
)could be the number of pizzas C= execs ordered last year.
)
) You still have no idea what your talking about and you fail to see the
)big picture.
I tell ya, if you posted more quantitative facts and fewer words, your
point might be a compelling as Marc's. His documented point is that
C= spends much less on R&D than other computer companies.
This is true. It's a problem. In case you haven't noticed the
Amiga is evolving *very* slowly, particularly in the "crown jewels,"
the custom chips. We all wonder why the A500 isn't trumpeted as
a leader in the new "home computer influx" and the answer is that
it's just too old to be of great interest to the media or the public.
C= gets pretty good bang for its buck from the Engineering team, esp.
if you consider how much effort is spent on interim band-aids,
such as the A2024 monitor, the Amber circuit, and the "Productivity mode"
of ECS Denise (which also ate up a considerable amount of system
software resources to support...).
But there should be more dollars, if the plan is to compete as
a computer, or even as a home computer or game machine. Real
improvements in graphics and display are still missing in action.
As a software developer, I like faster CPU's and disks most of all,
though, but I sure would like a couple hundred more high-res colors.
By the time we see that on the Amiga (unknown) I fear the rest of
the world will be doing millions of colors, with full-motion video.
But I take issue with Marc's implication that C= doesn't know what
it's doing. Perhaps Irving and Mehdi know exactly what they're
doing, and maybe they're making a conscious choice to focus on the
"new" consumer market for CDTV, to the exclusion of the difficult
"proprietary architecture PC" efforts.
... and just aren't bothering to tell us in so many words.
The computer business can be a problem. For example, it requires too
much R&D money to be competitive...
But CDTV, whoa, we could get Big Rich here. Their frontman (Bushnell)
has talked about C= owning 80% of a $40 Billion market. Who needs
computers...?
jimm
--
--- opinions expressed herein are my own. ---
"... Because they can."
- profound punchline to joke about dogsjdickson@jato.jpl.nasa.gov (Jeff Dickson) (04/04/91)
In article <1991Apr3.201259.8377@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: >In article <1991Apr2.235710.13984@news.iastate.edu> xgr39@CCVAX.IASTATE.EDU writes: >>In article <CPETTERB.91Apr2105151@mickey.glacier.sim.es.com>, cpetterb@glacier.sim.es.com (Cary Petterborg) writes: >>[...] >>available. It also explains many significant features -- including >>virtual memory, memory protection, resource tracking, and >>device-independent video -- are still absent from the Amiga's O.S. >>[...] > > What is the big deal about memory protection and resource tracking? >Sure, it might be a nice toy, but it wouldn't be real useful on a >single-user system. Is this one of those things people want just >because Unix has it? > I partially disagree. I could care-less about resource tracking, but memory protection is important and not because UNIX has it. While the Amiga may not be multiuser, it is multi-tasking and it is very disturbing to have the entire machine go belly up due to a memory error induced by one task. In the past, I thought it would be nice to have a BBS run concurrently while I did development work, but the lack of memory protection doesn't warrant this. Yes, the Amiga is a single user machine and unfortunately it is single purpose for some of my purposes. I can only hope that one day, some- kind of memory protection is incorporated into the O.S. if an MMU is avail- able. I've heard the arguments against it, but nothing that hasn't already been done on costlier (had to put that in) systems. -jeff > >> / Marc Barrett | BITNET: XGR39@ISUVAX.BITNET / >>/ ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / > > >-- >+---------------------------------------+----------------------------+ >| // Daryl S. Cantrell | These opinions are | >| |\\\ milamber@caen.engin.umich.edu | shared by all of // | >| |// Evolution's over. We won. | Humanity. \X/ | >+---------------------------------------+----------------------------+
lag@itsgw.rpi.edu (Jose Raffucci) (04/04/91)
In article <1991Apr3.201259.8377@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: > > What is the big deal about memory protection and resource tracking? >Sure, it might be a nice toy, but it wouldn't be real useful on a >single-user system. Is this one of those things people want just >because Unix has it? > What's the 'big deal' about memory protection? Well, I used to think like that...Until, that is, I had to _write and debug_ a real program. I always used to wonder what all those 'segmentation fault -- core dumped' messages meant. Here's what they mean: 1. No panicking because you had something in your ram disk and now it's toasty in guru heaven 2. No constant check of how true your faith is in the Gomf gods. 3. Not having to worry about losing your data connection because your machine decided to ponder its own existance. 4. Not having to wonder where the last copy of code you made was. 5. Of course, a handy dandy picture of the memory you trashed to go over at your leisure, or post to ab20 if it's particularly interesting. I hope you begin to see the picture. It's really annoying having your machine dump you just because you tried to move a window just a tad fast, or you were squaring instead of adding one to your counter. Even though I like the lattice compiler, I'm usually forced to use the campus suns to compile my projects because they won't crash so easily on me. -hOz -- /*-------------------------------------------------------------------------+ // The Amigoids from hell, lagnaf@rpitsmts.bitnet \X/ Renssepolyinstatechnitute lag@rpi.edu 'That's what you get when you don't put out...' - 1/31/91 */
jesup@cbmvax.commodore.com (Randell Jesup) (04/04/91)
In article <1991Apr2.235710.13984@news.iastate.edu> xgr39@CCVAX.IASTATE.EDU writes:
[ flames about commodore not having introduced new chip sets...]
Stupid me, for responding to M. Barrett, but....
A quick head-count around here reveals that software guys are
outnumbered by chippies, not even counting hardware guys like Dave. However,
no amount of torture will get out of me they work on... ;-) As usual, you
have absolutely no concept what you're talking about.
Also, Sun (a relatively high-end (and thus high-overhead)) startup
would be expected to put more % into R&D. They have far bigger margins, and
your figures were as a percentage of total sales.
As for Commodore, we understand quite well the issues involved, and
your comments do nothing more than act as catharsis for you (apparently, you
need a lot of catharsis) (and of course to annoy people reading them).
followups to .advocacy...
--
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup
Disclaimer: Nothing I say is anything other than my personal opinion.
Thus spake the Master Ninjei: "To program a million-line operating system
is easy, to change a man's temperament is more difficult."
(From "The Zen of Programming") ;-)dlou@sdcc13.ucsd.edu (Dennis Lou) (04/04/91)
In article <1991Apr3.130218.25163@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > The Amiga is mainly a 16bit machine except for the A3000, so what about all >those other models out there? The majority of the machines are >A500s. Redesigning the custom chips means breaking most of all the software >out there. It also means abandoning the low-end machines. Do we really >want to do that? Now let's consider this question Marc. Why hasn't MS-DOS Is abandoning the low end machines really that bad? In the MS-DOS world, the 8088 is virtually being dropped. Most of the software that is on the market is designed for only the 80286/i386 and those that aren't have weak concessions to the 8088. I suspect that a lot of this is due to 80286/i386 prices dropping like rocks; 386sx systems are approaching the price of a comparably equpped A2000. >been significantly improved? The answer is, because of its design >limitations any 'quantum leap' or major improvements will break >BILLIONS of dollars of software. The Amiga, by design, uses a shared memory Again, the MS-DOS world, you break it slowly. > You see Marc, you fail to consider the big picture and how hard these >problems are to solve. Throwing money at them doesn't help. The IBM Market >beeen trying to solve the MS-DOS problem for years throwing more R&D >(total market wise) than Commodore's total net worth. Do you think >if we invested 100 billion dollars in AIDS research we could cure it in a >month? Throwing money at MS-DOS is not the same as throwing money at AIDS research. You throw money at R&D for MS-DOS for the purpose of advancing the state of the art and for making more money. You throw money at AIDS research to solve a specific problem. -- Dennis Lou | dlou@ucsd.edu | "But Yossarian, what if everyone thought that way?" [backbone]!ucsd!dlou | "Then I'd be crazy to think any other way!"
sl242003@silver.ucs.indiana.edu (Jon Paul Baker) (04/05/91)
I agree with the need for more high-resolution colors, but there is a point where this becomes ludicrous. So an IBM with Super-VGA (a non-standard, by the way), can do 640x480x256 (or 1024x768x256 if he has 1meg of video ram). What good does this do? It makes for pretty fractals, and nice GIF's and suchlike, but for animation... The best animations I have seen (done with hand-coded, hand optimized assembly code) just cannot animate like an Amiga. You get weird flicker, and parts of things dissapear in rotation (as in its not smooth and things flicker in and out) and the rotation is SLOW. And this was on a 33mhz '386. If you are trying to do real-time games, or real-time modeling, you still need an Amiga or a high-end workstation. If you are not doing these, than what need is there for the resolution? Some particular things need it (surface mapping, etc), but how many people would really NEED it? I can wait for now. When you pull out an animation like Spigot (old, I know) and IBM programmers just look and sigh, because to do that they need hardware that costs as much as a hard-drive Amiga system. Jon
am66@cunixa.cc.columbia.edu (Alexander Maldutis) (04/05/91)
In article <1991Apr4.200011.23370@bronze.ucs.indiana.edu> sl242003@silver.ucs.indiana.edu (Jon Paul Baker) writes: > >I agree with the need for more high-resolution colors, but there is a >point where this becomes ludicrous. > >So an IBM with Super-VGA (a non-standard, by the way), can do >640x480x256 (or 1024x768x256 if he has 1meg of video ram). What good >does this do? It makes for pretty fractals, and nice GIF's and >suchlike, but for animation... The best animations I have seen (done >with hand-coded, hand optimized assembly code) just cannot animate >like an Amiga. You get weird flicker, and parts of things dissapear >in rotation (as in its not smooth and things flicker in and out) and >the rotation is SLOW. And this was on a 33mhz '386. > >If you are trying to do real-time games, or real-time modeling, you >still need an Amiga or a high-end workstation. If you are not doing >these, than what need is there for the resolution? Some particular >things need it (surface mapping, etc), but how many people would >really NEED it? > >I can wait for now. When you pull out an animation like Spigot (old, >I know) and IBM programmers just look and sigh, because to do that >they need hardware that costs as much as a hard-drive Amiga system. > >Jon I agree totally. As someone who invested money in an S-VGA (you can guess what the S stands for), I find that I have maybe two pictures which use anything above 640x480. Even in low-res on my 386-20, animation is jerky - ever see Wing Commander animate? - Puhlease! It looks like 5 or six independent strips of graphics being dragged across the screen at different speeds. While I would like the Amiga to have more colors, I don't think that that would make games really better. IBMs are good for maybe flight sims and Sierra animated adventures, but Amigas are much better for action, high-speed animations, graphics and games, hands down. Commodore should release the ULowell board soon, simply as a standard for 24bit graphics. Nobody wrote game software to take advantage of higher speed Amigas 'till the A3000 came out, and then presto, many games have selectors for detail, etc. If C= were to do this for graphics, much of the debate would disappear. My $0.02 ****************************************************************************** HA HA! YOU THINK THIS IS THE REAL .SIGNATURE? IT IS! Total Computing!**********************************am66@cunixa.cc.columbia.edu*
urjlew@uncecs.edu (Rostyk Lewyckyj) (04/05/91)
In article <6456@amiga.UUCP>, jimm@amiga.UUCP (Jim Mackraz) writes: > C= spends much less on R&D than other computer companies. > > This is true. It's a problem. In case you haven't noticed the > Amiga is evolving *very* slowly, particularly in the "crown jewels," > the custom chips. We all wonder why the A500 isn't trumpeted as > a leader in the new "home computer influx" and the answer is that > it's just too old to be of great interest to the media or the public. > > ......................................... > > But there should be more dollars, if the plan is to compete as > a computer, or even as a home computer or game machine. Real > > .......................................... > > But I take issue with Marc's implication that C= doesn't know what > it's doing. Perhaps Irving and Mehdi know exactly what they're > doing, and maybe they're making a conscious choice to focus on the It is my understanding that both Messrs Irving and Mehdi are getting on in years. Perhaps it is their concious decision not to worry very much about futures, and just enjoy their incomes. Plowing receipts back into research means less money for dividends, Less money for a nice salary now . Why worry about the fate of the company in 5 - 10 years from now. Perhaps it would be good for the continued existance of the company and in the longer run for the shareholders also, if the leadership were changed, and I don't mean the second level of management which at C= appears to be a revolving door anyways. Sorry this is advocacy not hardware. ----------------------------------------------- Reply-To: Rostyslaw Jarema Lewyckyj urjlew@ecsvax.UUCP , urjlew@unc.bitnet or urjlew@uncvm1.acs.unc.edu (ARPA,SURA,NSF etc. internet) tel. (919)-962-6501
urjlew@uncecs.edu (Rostyk Lewyckyj) (04/05/91)
In article <6456@amiga.UUCP>, jimm@amiga.UUCP (Jim Mackraz) writes: > > C= gets pretty good bang for its buck from the Engineering team, esp. > if you consider how much effort is spent on interim band-aids, > such as the A2024 monitor, the Amber circuit, and the "Productivity mode" > of ECS Denise (which also ate up a considerable amount of system > software resources to support...). > I completely fail to follow your reasoning here. How can the return on investment be good if it is being spent on a bad (poor) overall design? Perhaps the individual detail engineers are good, but if the high level design engineers specify a RUBE GOLDBERG or otherwise inappropriate design, then no amount of clever circuit design will overcome that. The original AMIGA was conceived as a game machine and converted into a home computer before birth. It is now trying to be evolved into a conventional multipurpose computer. Because of its very unique and innovative original design, and its stormy and difficult gestation it suffers from many deformities that are holding back normal growth and evolution.
milamber@caen.engin.umich.edu (Daryl Scott Cantrell) (04/05/91)
In article <1991Apr3.225433.16594@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >In article <1991Apr3.201259.8377@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: >>In article <1991Apr2.235710.13984@news.iastate.edu> xgr39@CCVAX.IASTATE.EDU writes: >> >> What is the big deal about memory protection and resource tracking? >>Sure, it might be a nice toy, but it wouldn't be real useful on a >>single-user system. Is this one of those things people want just >>because Unix has it? >> > I partially disagree. I could care-less about resource tracking, but >memory protection is important and not because UNIX has it. While the Amiga >may not be multiuser, it is multi-tasking and it is very disturbing to have the >entire machine go belly up due to a memory error induced by one task. In the >past, I thought it would be nice to have a BBS run concurrently while I did >development work, but the lack of memory protection doesn't warrant this. > > Yes, the Amiga is a single user machine and unfortunately it is >single purpose for some of my purposes. I can only hope that one day, some- >kind of memory protection is incorporated into the O.S. if an MMU is avail- >able. I've heard the arguments against it, but nothing that hasn't already >been done on costlier (had to put that in) systems. > > -jeff > 1) Memory protection isn't a whole lot of good without resource tracking. Sure, you may keep this buggy program from dragging other stuff down with it, but everything it was using when it dies is "gone". You'll end up having to reboot to get the stuff back anyways. 2) Are you sure you understand all the arguments against it? The Amiga OS has been shuffling pointers around between tasks for years now, making every program out there behave for a memory protection scheme would be a ridiculous amount of work. It would be easier to simply go through and debug all those programs we're trying to protect ourselves from. 3) There are a lot better things software people at CBM should worry about. Virtual memory comes to mind as a far more productive use for the MMU. Can you say 100 MB free? [insert drool noise] Not to mention color X-Windows for Unix, etc., etc... All of which (ok, some of which anyway..) I'm sure they're thinking-about/designing/coding/lying-to-us-about-not-having-yet at this very moment. -- +---------------------------------------+----------------------------+ | // Daryl S. Cantrell | These opinions are | | |\\\ milamber@caen.engin.umich.edu | shared by all of // | | |// Evolution's over. We won. | Humanity. \X/ | +---------------------------------------+----------------------------+
tagreen@bronze.ucs.indiana.edu (Todd A. Green) (04/05/91)
In article <1991Apr5.034303.14202@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: >In article <1991Apr3.225433.16594@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >>In article <1991Apr3.201259.8377@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: >>>In article <1991Apr2.235710.13984@news.iastate.edu> xgr39@CCVAX.IASTATE.EDU writes: >>> >> > [stuff about memory protection and resources deleted] > >3) There are a lot better things software people at CBM should worry about. >Virtual memory comes to mind as a far more productive use for the MMU. Can >you say 100 MB free? [insert drool noise] Not to mention color X-Windows >for Unix, etc., etc... All of which (ok, some of which anyway..) I'm sure >they're thinking-about/designing/coding/lying-to-us-about-not-having-yet at >this very moment. Can you say let's watch this window get paged in from disk? [insert yawn noise here]. Have you ever used virtual memory on a system with a relatively slow HD? Such as the Mac, NeXT, or MicroVaxII? (Not meant as a flame, but just as a curiosity.) I'm assuming that you are being a little bit on the facetious side when you say 100 mb free, so I won't comment on that. But, having VM on any pc, is not quite like having it on a mainframe (like our RISC DEC 5840 with 4 CPU's running at 64 MIPS). Besides the advantage in pure processing power, these puppies have disk transfer rates that would blow your mind. Don't get me wrong VM is nice and has its purpose, but it is NOT a substitute for RAM. Case in point. My workstation is a NeXT '030 cube that used to have 8mb of memory. A day (actually more like a minute :)) did not go by that I didn't have to wait on the machine as my processes got swamped into and out of memory. You seriously can see your windows get read from disk. (It's kinda cool for about the first 5 minutes). I've since upgraded to 16mb of memory and the performance increase is incredible. Like night and day...thought someone had slipped an '040 board into the machine (until I actually used a NeXT slab). My point is that VM is nice, VM is good, VM is your friend, but it ain't never gonna nohow replace RAM. Todd ----- Internet: tagreen@bronze.ucs.indiana.edu NeXTMail: tagreen@lothario.ucs.indiana.edu
sschaem@starnet.uucp (Stephan Schaem) (04/06/91)
To anyone looking for 'new' idea... Look at the2 3 year old X68000. 16bit, but use 'multy bus'.With a text mode overlay with all the diferent video mode up to 2 256 color dualplayfield (plus text mode overlay) and another mode. Plus a bank for 65535 colors sprites (alot of them!).So for any kind of anymation a blitter is useless. Or the video from the FM_Towns.With hardware posibilities like 360 degrea real time screen rotation on a 24 bitplane screen. or real time zoom on its linkable sprites etc... Both have CD suport for year. The above is what I saw, and both machine are not that expansive (Check LOGIN for latest price tag). The first is a 680x0 based machine (with accelerator available) from Sharp. The second is from Fujitsu, intel based machine :-( FM_TOWNS 32bit machine, X68000 16bit. You dont have to go 32 bit to have more power on amiga?! Put 2 set of custom chip in parrale:-) Stephan
kdarling@hobbes.ncsu.edu (Kevin Darling) (04/06/91)
> What is the big deal about memory protection and resource tracking? > Sure, it might be a nice toy, but it wouldn't be real useful on a > single-user system. Is this one of those things people want just > because Unix has it? Personally, I think memory protection on a single-user system is far less important than resource tracking is. Users usually sift out (or become prepared for) programs which are buggy enough to warrant memory protection. But resource tracking is a prime function of an OS. Abnormally stopping a program should not clutter the system up with memory loss, device blockage, etc... or require the user to run special cleanup utilities. And programmers shouldn't have to worry about handling this common task. The OS allocates the resources on call; it should also deallocate those resources automatically. "Lean and mean" is no excuse for sloppiness. Anyway, my two cents <g>. cheers - kev <kdarling@catt.ncsu.edu>
kdarling@hobbes.ncsu.edu (Kevin Darling) (04/06/91)
In article <1991Apr4.200011.23370@bronze.ucs.indiana.edu> sl242003@silver.ucs.indiana.edu (Jon Paul Baker) writes: > >I agree with the need for more high-resolution colors, but there is a >point where this becomes ludicrous. > >So an IBM with Super-VGA (a non-standard, by the way), can do >640x480x256 (or 1024x768x256 if he has 1meg of video ram). What good >does this do? It makes for pretty fractals, and nice GIF's and >suchlike, but for animation... The best animations I have seen (done >with hand-coded, hand optimized assembly code) just cannot animate >like an Amiga. You get weird flicker, and parts of things dissapear >in rotation (as in its not smooth and things flicker in and out) and >the rotation is SLOW. And this was on a 33mhz '386. You get flicker because stock IBM programs don't support double-buffering. Try non-buffered animation on the Amiga, and you'll see the same flicker; and worse, the infamous color ghosting because of bitplanes being changed one at a time. Nevertheless, I've seen plenty of Amiga ANIM-5's played back on a '386 with a no-wait-state VGA card, and they looked just as nice as could be. More to the point, my own 12Mhz-equiv 68000 machine has 256-color gfx, and it animates just fine, thank you very much. Of course the fact that the video ram access doesn't bog down at higher color resolutions like the Amiga's does, no doubt helps ;-). Plus chunky pixel memory instead of bitplanes helps at times... to change one pixel only requires one byte write, instead of bit diddling for each separate Ami bitplane. And finally, for the zinger: what about all the people around here who claim incredible animation using the new Amiga add-on gfx boards? Are THEY crazy? You can't have it both ways <g>. Either it's possible to have nice animation with more colors or grey shades, or it isn't. But in fact, it _is_ possible. best - kev <kdarling@catt.ncsu.edu>
ben@epmooch.UUCP (Rev. Ben A. Mesander) (04/06/91)
>In article <FPi1Z2w161w@nstar.rn.com> tbissett@nstar.rn.com (Travis Bissett) writes: [...] >add the gigabytes they need. How many people can actually afford to allocate >100 MB of hard disk for VM swap space? And who would possibly want to run a >mix of users/applications that might NEED 100 MB of swap? Lawd awmighty it >would be a slllooowwwwwww way to work. Well, if you very occasionally need 130MB of swap space on your Sun workstation because you do image processing it's a good thing. I don't think I needed to buy 130MB of semiconductor memory because of a job I've run twice. Yes, it was somewhat slow, but not too bad because of locality of reference. (It also helps that I have a fileserver model, which can do very fast disk I/O). There are people who would do this kind of work on an Amiga, if they could. Also, you must not program in LISP :-) >But for a single user platform -- even tho' mul;titasking -- VM >and MMU is moslty marketing hype and not a true technical requirement >(IMHO). I use a unix 386 (16MHz) at work and I'm glad to come home to a >"lowly" PC with a keyboard garage that at least doesn;t feel like a waltzing >elephant! That's odd. I used to have a 20MHz 386 at work (running DOS and not UNIX). When I compiled the same code on the 386 as on the Amiga, the 386 was a *lot* faster. Perhaps you also need to look at your hard drive and host adaptor on your 386. I had a WD FASST controller, and a Wren III HD. I think if I had the ability to page, it would have been pretty quick. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
jimm@amiga.UUCP (Jim Mackraz) (04/07/91)
(Rostyk Lewyckyj) writes: )(Jim Mackraz) (Me) writes: )> )> C= gets pretty good bang for its buck from the Engineering team, esp. )> if you consider how much effort is spent on interim band-aids, )> such as the A2024 monitor, the Amber circuit, and the "Productivity mode" )> of ECS Denise (which also ate up a considerable amount of system )> software resources to support...). )> )I completely fail to follow your reasoning here. )How can the return on investment be good if it is being spent on )a bad (poor) overall design? Perhaps the individual detail engineers )are good, but if the high level design engineers specify a RUBE )GOLDBERG or otherwise inappropriate design, then no amount of clever )circuit design will overcome that. The team is strong and does good work. This is my point. I think there have been problems at the strategy level, and budget. If CDTV is cutting deeply into hardware Engineering resources, or is screwing up the future OS enhancement (CDTV runs V1.3), then there is a very significant "strategy" being played. Whether that's true, and whether it's a bright move or not, remain to be seen. But I get the feeling that Irving wouldn't be in the computer business if he didn't have to be. Personal opinion, and I don't know the man. jimm -- --- opinions expressed herein are my own. --- "... Because they can." - profound punchline to joke about dogs
tbissett@nstar.rn.com (Travis Bissett) (04/07/91)
milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: > > 3) There are a lot better things software people at CBM should worry about. > Virtual memory comes to mind as a far more productive use for the MMU. Can > you say 100 MB free? [insert drool noise] Not to mention color X-Windows > for Unix, etc., etc... All of which (ok, some of which anyway..) I'm sure > they're thinking-about/designing/coding/lying-to-us-about-not-having-yet at > this very moment. > In my humble opinion VM is much overrated and strikes me as mostly fad. Maybe it was important when oxide was a lot cheaper than silicon. But ram is cheap. I've heard that Crays don't bother with virtual memory -- they just add the gigabytes they need. How many people can actually afford to allocate 100 MB of hard disk for VM swap space? And who would possibly want to run a mix of users/applications that might NEED 100 MB of swap? Lawd awmighty it would be a slllooowwwwwww way to work. It just strikes me as humorous in a Douglas Adams sort of way that the computer industry believes the hype about VM and MMU, but the first thing they read in the manual for improving system performance is to add more ram so as to reduce the need for memory swapping! Pleae don't misunderstand me. For a multiuser computer (can we still say "minicomputer"?) virtual memory and memory protection are absolutely necessary. But for a single user platform -- even tho' mul;titasking -- VM and MMU is moslty marketing hype and not a true technical requirement (IMHO). I use a unix 386 (16MHz) at work and I'm glad to come home to a "lowly" PC with a keyboard garage that at least doesn;t feel like a waltzing elephant! Travis -- Travis Bissett NSTAR conferencing site 219-289-0287 internet: tbissett@nstar.rn.com 1300 newsgroups - 8 inbound lines uucp: ..!uunet!nstar.rn.com!tbissett 99 file areas - 4300 megabytes --- backbone news & mail feeds available - contact larry@nstar.rn.com ---
Fletcher@cup.portal.com (fletcher sullivan segall) (04/07/91)
>In article <CPETTERB.91Apr2105151@mickey.glacier.sim.es.com>, cpetterb@glacier . >sim.es.com (Cary Petterborg) writes: >>The Amiga has been out for years now. There have been improvements >>made to the custom chips, Agnus in particular. But, I am amazed at >>the fact that their clock speed, etc. has remained the same. In an >>industry where last years chip runs twice as fast this year, C= sure >>has sat back on their b*tts as far as performance is concerned. Is >>it because they aren't willing to invest any more money into the >>technology because they can sell so many A500's as they are now? >>What gives? Certainly the technology exists to speed them up. > > Here is why Commodore has not improved the Amiga's custom chipset. The >following table lists the amounts that Commodore has invested in R&D since >1984, both as a raw figure and as a percentage of total sales (the better >figure for comparing companies): > >... > > As you can see, compared to SUN, Commodore has never invested much >in their own future, which is the reason why the custom chipset is so >ancient, and why improvements are nowhere in sight. This information >also gives us some insight into the success of the two companies. As >you can see from the first table, between 1984 and 1990, Commodore's >total sales steadily declined. The decline is actually much worse than >it appears, once you take inflation into account. > You are forgetting the basic history of the Amiga. Commodore didn't design the chips in the Amiga, and wouldn't be able to afford to design an equialent chip set from scratch in any case. The custom chips were hand optimized in NMOS for a home video game. As such they were designed to be as economical as possible on a very large scale production. The chip set is considerably more complex than the most advanced display cards available for the PC... ...but they are also essentially cast in stone. Redesigning in CMOS would require re-optimizing, or a loss of performance. Adding features has to be tested thoroughly because the chips are extremely interdependent, and any introduced bug could well affect the whole system. Expanding to 32 bits would require a hefty redesign of the chips to remain consistent with earlier versions. ... It should also be noted that Sun didn't put the SPARC chips in silicon, they only wrote the specifications for the chip, and allowed other manufacturers to build it. (Not impossible for commodore if they choose to give away the existing chip masks (so that they can be modified by other companies) but it isn't likely that commodore would want to release something that valuable for free.) Additionally, RISC processors are the easiest type of processor to implement in silicon, so spotting actual implementations after 4 years is quite reasonable. -F. Sullivan Segall _______________________________________________________________ /V\ E-Credibility: (n -- ME) The unguaranteed likelyhood that ' the electronic mail you are reading is genuine rather than someone's made up crap. _______________________________________________________________ Mail to: ...sun!portal!cup.portal.com!fletcher or fletcher@cup.portal.com
svante@kberg.se (Svante Gellerstam) (04/08/91)
In article <1991Apr4.211339.30360@cunixf.cc.columbia.edu> am66@cunixa.cc.columbia.edu (Alexander Maldutis) writes: >Commodore should release the ULowell board soon, simply as a standard for >24bit graphics. Nobody wrote game software to take advantage of higher >speed Amigas 'till the A3000 came out, and then presto, many games have >selectors for detail, etc. If C= were to do this for graphics, much of the >debate would disappear. The only thing the Amiga needs for the video and high res display adapter market to explode is a well defined screen driver interface a la MAC QuickDraw-32. Please note that I am not advocating for the MAC, just stating what effect such a standard can have. Just have a look at the quantum quality leap HDs took when the hardblocks standard came out. Today the Amiga has many of the best and most effective HDs working flat out. I would love to have the Amiga using the existing video image technology to the same extent. >****************************************************************************** > HA HA! YOU THINK THIS IS THE REAL .SIGNATURE? > IT IS! >Total Computing!**********************************am66@cunixa.cc.columbia.edu* -- Svante Gellerstam svante@kberg.se, d87sg@efd.lth.se
svante@kberg.se (Svante Gellerstam) (04/08/91)
In article <1991Apr4.223101.7618@uncecs.edu> urjlew@uncecs.edu (Rostyk Lewyckyj) writes: >In article <6456@amiga.UUCP>, jimm@amiga.UUCP (Jim Mackraz) writes: >> C= spends much less on R&D than other computer companies. >> >> This is true. It's a problem. In case you haven't noticed the >> Amiga is evolving *very* slowly, particularly in the "crown jewels," >> the custom chips. We all wonder why the A500 isn't trumpeted as >> a leader in the new "home computer influx" and the answer is that >> it's just too old to be of great interest to the media or the public. >> >> ......................................... >> >> But there should be more dollars, if the plan is to compete as >> a computer, or even as a home computer or game machine. Real >> >> .......................................... >> >> But I take issue with Marc's implication that C= doesn't know what >> it's doing. Perhaps Irving and Mehdi know exactly what they're >> doing, and maybe they're making a conscious choice to focus on the > > It is my understanding that both Messrs Irving and Mehdi are >getting on in years. Perhaps it is their concious decision not >to worry very much about futures, and just enjoy their incomes. >Plowing receipts back into research means less money for dividends, >Less money for a nice salary now . Why worry about the fate of the >company in 5 - 10 years from now. I find it very annoying that most people just complain about so and so not putting enough resources into this problem X which is very dear to the person complaining. Everybody seems to think along the lines that it is Commodore that has to do all new peripherals and all new inventions. This becomes a very hard task for Commodore to do as more and more expensive technology and know-how has imported into the company and researched from scratch. My view is that Commodore has to exploit the presence of companies who already has the solutions and knowledge. This would cut the development time as Commodore would not have to do the research part themselves. All that Commodore has to do to control the general formation of products is to provide standards - a general interface or form of appearance in the Amiga system. In all areas where Commodore has not yet presented a template for development, all that exists are niche solutions - products that costs much and has limited use (or 'well defined function' as a sales person would put it :-). The Amiga concept can only move so fast if niche solutions represents the broad cutting edge of the machine family. Evolutionary steps require the groundwork of theory that spans more than the immediate step in development. > Perhaps it would be good for the continued existance of the >company and in the longer run for the shareholders also, if the >leadership were changed, and I don't mean the second level of >management which at C= appears to be a revolving door anyways. It is rarely good for the stability of a company to change management. It usually causes some amount of turbulence among the employees. My belief is that if Commodore only creates the right 'feeling' about the company as a low-cost, state-of-the-art operation (or rather intensifies that image), the right people will want to find their way into the company. We already know this - the trick (and the problem is to let it be known all over). Am I talking sense here? > Reply-To: Rostyslaw Jarema Lewyckyj > urjlew@ecsvax.UUCP , urjlew@unc.bitnet > or urjlew@uncvm1.acs.unc.edu (ARPA,SURA,NSF etc. internet) > tel. (919)-962-6501 Please follow this up in the .advocacy group. -- Svante Gellerstam svante@kberg.se, d87sg@efd.lth.se
lou@vaxsc (04/08/91)
In article <1991Apr5.152157.13339@bronze.ucs.indiana.edu>, "Todd A. Green" <tagreen@bronze.ucs.indiana.edu> writes: (in response to the discussion regarding VM for the Amiga) >Can you say let's watch this window get paged in from disk? [insert >yawn noise here]. Have you ever used virtual memory on a system with >a relatively slow HD? Such as the Mac, NeXT, or MicroVaxII? (Not meant ^^^^^^^^^^ >as a flame, but just as a curiosity.) I'm assuming that you are being Guess where this message is coming from? Anyway, this I agree with. I constantly curse this "boat anchor" because of verrrrrry long swap times. >Don't get me wrong VM is nice and has its purpose, but it is NOT a >substitute for RAM. Case in point. My workstation is a NeXT '030 >cube that used to have 8mb of memory. A day (actually more like a >minute :)) did not go by that I didn't have to wait on the machine as >my processes got swamped into and out of memory. You seriously can >see your windows get read from disk. (It's kinda cool for about the >first 5 minutes). I've since upgraded to 16mb of memory and the >performance increase is incredible. Like night and day...thought I tend to think that it would be nice for a micro such as the A3000. I agree that it is NOT an *adequate* subsitute for RAM. It is nice to be able to extend past your physical memory, but you can't depend on it as a substitute for RAM. In the Amiga's case, it may be useful for long animations, etc, just so that "average joe" can run them. If you're building an animation you would have to have the ram. In my environment (NeXT 030, and MicroVAX II) it helped to conclusively prove/disprove (respectively) the need for more RAM to be purchased. An animator may be able to finish a sequence while waiting on additional RAM as well, thus allowing him/her to work even though the RAM hasn't hit the door yet. Oh yea, I never really thought my NeXT was very cool watching windows swap in. FrameMaker is almost useless, especially when you've got to have a paper out in 2 days, and half of that time is spent swapping. Oh well, I guess I'm just too critical. ---------------------------------------------------------------- -Lou Williams Via Bitnet : william8@niehs.bitnet Via Internet: lou@vaxsc.niehs.nih.gov Computer Sciences Corporation, Research Triangle Park, NC ---------------------------------------------------------------- -Sometimes in order to feel better about yourself, you have to make others feel bad, and I'm tired of making others feel good about themselves. -Homer Simpson. ----------------------------------------------------------------
monty@sagpd1 (04/09/91)
In article <41008@cup.portal.com> Fletcher@cup.portal.com (fletcher sullivan segall) writes: >You are forgetting the basic history of the Amiga. Commodore didn't ^ Me thinks you are the one forgetting history! ^ This part is true,but.. >design the chips in the Amiga, and wouldn't be able to afford to design >an equialent chip set from scratch in any case. The custom chips were >hand optimized in NMOS for a home video game. As such they were designed ^^^^^^^^^^^^^^^^ This part, if you will remember was the cover story to hide development. R.J Michals (sp) and crew were designing a home COMPUTER. The keyboard and expansion ports were not an after thought, they had (and have stated such) always designed a COMPUTER, not a video game. It was CBM who cut back the design (i.e. removed internal expansion) to make it less expensive to produce. CBM did not have the foresight at that time (I believe they have since changed their views) to actively pursue the COMPUTER market. >to be as economical as possible on a very large scale production. The >chip set is considerably more complex than the most advanced display >cards available for the PC... > Monty Saine
ckp@grebyn.com (Checkpoint Technologies) (04/11/91)
In article <1991Apr9.150928.21660@sagpd1> monty@sagpd1.UUCP (Monty Saine) writes: >In article <41008@cup.portal.com> Fletcher@cup.portal.com (fletcher sullivan segall) writes: >>You are forgetting the basic history of the Amiga. Commodore didn't > ^ > Me thinks you are the one forgetting history! ^ This part is true,but.. > >>design the chips in the Amiga, and wouldn't be able to afford to design >>an equialent chip set from scratch in any case. The custom chips were >>hand optimized in NMOS for a home video game. As such they were designed > ^^^^^^^^^^^^^^^^ > This part, if you will remember was the cover story to hide development. > R.J Michals (sp) and crew were designing a home COMPUTER. The keyboard > and expansion ports were not an after thought, they had (and have stated > such) always designed a COMPUTER, not a video game. It was CBM who cut > back the design (i.e. removed internal expansion) to make it less > expensive to produce. CBM did not have the foresight at that time > (I believe they have since changed their views) to actively pursue the > COMPUTER market. I've heard the story from R J Mical, and from Jay Miner (whom I spoke to one-on-one about it). When it all started, there were these investors who wanted to make a game console, because they saw how the Atari VCS market was growing. So they founded the Amiga company, hid it's true purpose behind a facade of building joysticks, and set Miner and Needle and RJ and the rest to work. Well, Miner in particular wanted a True Home Computer, with disk and keyboard and serial and parallel etc., so he pushed through some design concessions for that purpose. But he wasn't allowed to increase the cost, so the disk controller and the serial port went into Paula because it had room, to avoid the cost of the disk controller and serial port chips. As it turned out, these concessions saved the machine. The game console market dried entirely up, and the original investors lost interest. There still was no game console market when Commodore bought Amiga. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / ckp@grebyn.com \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
willmore@iastate.edu (Willmore David A) (04/12/91)
Just a little thought about the origin of this train of thought...
The idea was advanced that it would be a Good Thing (tm) if the amiga chip
set would be re-implemented in current technology silicon. (Or that's what
they should have ment. :) )
Next came the idea from someone at (or near) commodore that you couldn't add
much to the chips (or change the chip clock rate) without going away from
NTSC compatable video (or some such thought.)
My idea...
If NTSC went away some night as I sleep, my computing habits wouldn't change
one little bit. NTSC is no god to be prayed to. (really, I like english.)
Go for all that you can, leave NTSC in the dust if you have to. I would rather
have 1K by 1K that be able to feed my video into a VCR. Just because you
have extra modes, that doesn't mean you have to use them. Or, better yet,
use the good modes (the hi-res ones) to compose things and the old modes to
output them to whatever NTSC device that needs it.
What brought this to my attention was some article on the diferences in
resolution on the A2024 (?? you know, the really big one). Both modes were
1008 by something. The PAL model had a higher resolution in the vertical
direction. Ok, stupid question but, why? Does anyone have a 1008 by 1024
television? Would you like to sell it? :)
It was just an idea.
David Willmore
willmore@iastate.edu (internet claro)
twills@amiga.actrix.gen.nz (Tony Wills) (04/12/91)
Quoted from - tagreen@bronze.ucs.indiana.edu (Todd A. Green): > In article <1991Apr5.034303.14202@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: [...] > >Virtual memory comes to mind as a far more productive use for the MMU. Can > >you say 100 MB free? [insert drool noise] Not to mention color X-Windows > > Can you say let's watch this window get paged in from disk? [insert > yawn noise here]. Have you ever used virtual memory on a system with [...] > My point is that VM is nice, VM is good, VM is your friend, but it > ain't never gonna nohow replace RAM. I certainly agree that the Amiga I/O etc is a little slow for virtual memory if you considered swapping tasks (or just code/data 'pages') in and out during task switching. I envisage using virtual memory principles to allow me to swap out complete Amiga programs, ie take the code, data, and current register state, and stuff them onto disk thus freeing up memory, but allowing the program to continue at a later time from where it left off. (Of course if the program isn't self modifying no need to copy it to disk) A major problem with this idea is the Amigas lack of resource tracking, ie you don't know which bits of memory belong to which task. But then I suppose you can just intercept the memory allocation system calls, and keep your own resource table - retrofit resource tracking :-( Why would I want to do this ? (manually switch out tasks), I was thinking of things like raytracing and mandelbrots, which take a lot of processing time, and consume memory all that while - if I could swap them out, freeing up my whole machine temporarily for other large, short lived, tasks it would improve my productivity. If you switched out more information (like system task table entries, and any other info required by the operating system about executing tasks), you could even swap out tasks and switch off the machine ... then resurect them later to continue as though nothing had happened! This would be a non trivial operating system hack, it'd be easier just to purchase a 100 Megs!! :-) -- _ o(_) (c) Tony Wills 19** | All the world should live in alt.folklore, / /\ twills@actrix.gen.nz | unfortunately some die in sci.skeptic NZAmigaUG | -AJW 1991
greg@travis.cica.indiana.edu (Gregory TRAVIS) (04/12/91)
twills@amiga.actrix.gen.nz (Tony Wills) writes: >Quoted from - tagreen@bronze.ucs.indiana.edu (Todd A. Green): >> In article <1991Apr5.034303.14202@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes: >[...] >> >Virtual memory comes to mind as a far more productive use for the MMU. Can >> >you say 100 MB free? [insert drool noise] Not to mention color X-Windows >> Color X-Windows? Can you just say no? >> My point is that VM is nice, VM is good, VM is your friend, but it >> ain't never gonna nohow replace RAM. Good point - remember virtual memory s a transitory kludge dictated by economy and the gluttonous products of our universities. >I certainly agree that the Amiga I/O etc is a little slow for virtual memory >if you considered swapping tasks (or just code/data 'pages') in and out during >task switching. The Amiga's I/O subsystem (if it can be called that) is actually quite fast. And there's nothing that says paging I/O has to go through the I/O system (I assume you mean the filesystem). Most UNIX boxes don't. >I envisage using virtual memory principles to allow me to swap out complete >Amiga programs, ie take the code, data, and current register state, and stuff >them onto disk thus freeing up memory, but allowing the program to continue at >a later time from where it left off. >(Of course if the program isn't self modifying no need to copy it to disk) This is called swapping and has been around for about forty years. It has nothing to do with virtual memory. How quickly they forget. *sigh* >A major problem with this idea is the Amigas lack of resource tracking, ie >you don't know which bits of memory belong to which task. But then I >suppose you can just intercept the memory allocation system calls, and >keep your own resource table - retrofit resource tracking :-( This is nearly impossible. Unfortunately AmigaDos/Exec screwed itself out of ever having resource tracking. Remember that a program may allocated memory and silently pass a pointer to that memory to another program. How do you know what other running programs depend on that memory you just swapped out? Same thing with library resources, fonts, etc. ad nauseum. Sure they were SUPPOSED to use MEMF_PUBLIC... >If you switched out more information (like system task table entries, and >any other info required by the operating system about executing tasks), you >could even swap out tasks and switch off the machine ... then resurect them >later to continue as though nothing had happened! Why would you want to switch off the machine? Here's a man who was obviously born while cheap computers ruled! Life is short! >This would be a non trivial operating system hack, it'd be easier just to >purchase a 100 Megs!! :-) I think you're on to something here. -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.indiana.edu Center for Innovative Computer Applications This signature intentionally left blank.
daveh@cbmvax.commodore.com (Dave Haynie) (04/19/91)
In article <1991Apr9.150928.21660@sagpd1> monty@sagpd1.UUCP (Monty Saine) writes: >In article <41008@cup.portal.com> Fletcher@cup.portal.com (fletcher sullivan segall) writes: >>You are forgetting the basic history of the Amiga. Commodore didn't > Me thinks you are the one forgetting history! ^ This part is true,but.. >It was CBM who cut back the design (i.e. removed internal expansion) to make >it less expensive to produce. Guess again. The "Zorro" motherboard, the system at Amiga when C= took over, wasn't all that different than the A1000, but what got added was generally good. The Zorro system had a ROM cartridge slot up front, in addition to an "Expansion Chimney", which was the same idea as the A1000's expansion port -- a place to hook up an external expansion box, though in this case, more easily on top of the computer, rather than on the side where most A1000 things wound up. The computer used a 5.25", Apple-II compatible disk drive, and came with 64K of RAM standard. We had a couple of that vintage machine around here just after C= bought Amiga, and inherited the Genlock project. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.