Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!milton!henson!ogicse!pdxgate!parsely!percy!cryo!billc From: billc@cryo.UUCP (William J. Coldwell) Newsgroups: comp.sys.amiga.hardware Subject: Re: 14 Mhz Hack Message-ID: Date: 28 May 91 11:04:08 GMT Article-I.D.: cryo.billc.3378 References: <1991May13.081500.7980@rulway.LeidenUniv.nl> <1991May16.093917.28260@rulway.LeidenUniv.nl> <21810@cbmvax.commodore.com> Organization: Cryogenic Software Lines: 103 In article <21810@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article billc@cryo.UUCP (William J. Coldwell) writes: >>In article <1991May16.093917.28260@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes: >>>In article billc@cryo.UUCP (William J. Coldwell) writes: > >>>>manufacturer's item] when doing [CPU or DMA action]. This in-turn causes >>>>a rush to the [name] board layout package for the changes necessary to make >>>>the [your product] work with the latest rev, reducing the meager profit >>>>margin." ;-) > >>>This is true if you are pushing your board to the edge of performance. You >>>can do that by ignoring the specs of Commodore. It is to be expected that >>>there are then some incompatibilities. >99.9% of the hacks done that violate Commodore specifications are done strictly >out of designer laziness, not to "push your board to the edge". In fact, the >only one I can think of who has ever pushed the limits for performance reasons >is Bill Seymour, with the "PA". It has the option of talking to A2000 ROM at >full speed, rather than dropping down to the normal 560ns cycle a 7.16MHz 68000 >gives you. And that was a calculated risk, not some dumb hack. [stuff deleted] Kelly McArthur and Steve Fordyce are responsible for the PA. Bill did the great job of laying out most of the boards for all of the revisions. I did the software for it (so don't blame me, it's a hardware problem...;-)). >>There are situations that occur when other 3rd party products are mixed with >>certain other 3rd party products produce unwanted results. Commodore specs >>have a tendency to change when they jump from one producer of a specific part >>to another. > >You have to understand the idea of specifications. A system specification can >rarely have that much to do with reality. It's simply a ground rule. If every >third party follows the ground rules, everything should work together. [more specification specifics deleted] >>I find it very unlikely that software would "accidently" send an FPU an MMU >>command. Since the FPU is a peripheral processor, you won't have to worry ^^^^^^^^^^ [stuff deleted] >Apparently not unlikely enough for the "FPU Logic Error" message from SetCPU >to come up on several 68020 boards. We're not talking about 68000 peripherals >here, but the 680x0 coprocessor interface. I was ;-). [0x0/88x FPU vs. MMU deleted] >>> I can >>>get the components for say $150. I have (I may hope so) a knowledge of >>>electronics and the Amiga. It should therefore be possible to build what >>>you want. > >>Don't know about building what I want... the stuff I'm working on is >>finding the Amiga to be the bottleneck. > >If you're doing nothing but graphics manipulation, even an A3000 may appear >to be a bottleneck. At some times, it's important to reconsider your >algorithm rather than kick up to a faster an more expensive CPU. You can never have enough CPU power. BillC's law: The faster the CPU you have, the more you will try to do with it simultaneously - making your total productivity only increase marginally versus exponentially. ;-) The A3000 is not necessarily the bottleneck, and makes a great platform to improve upon. Unfortunantly, there are more 2000's out there, so this setup is for the 2000. Take an '040 w/32bit SRAM/DRAM memory, add a 32bit SCSI chip, and throw in a couple ESCC serial ports, and a PI/T just to round things off. Now take a ZorroII Framebuffer/grabber/genlock with a 32bit processor/mathchip and VRAM/DRAM combo and slap all of this into your common A2000. Being 16bit causes 1 bottleneck, the custom chips cause the other. Changing an algorythm or 100 will not improve this "problem", it's just something that has to be lived with. The solution would be to make a Zorro3 graphics board and SCSI board, and to slap in a PP&S 040, but finances and market don't point that way :-(. So, my statement stands, the Amiga _in this case_ is the bottleneck (a necessary one though). > For instance, >it doesn't make any sense to do image processing in Chip RAM. Most image >processing works better in a packed pixel graphics model, and Fast RAM on an >'030 system can be 10-100 times faster than Chip RAM, depending on what Chip >RAM is trying to display. Doesn't matter, we DISPLAY_OFF (if the user wants) so that the CPU gets the maximum gas mileage. ;-) > Other occupations, like number crunching, plain >old word processing, hard disk speed, etc. has very little to do with the ^^^^^^^^^^^^^^^ >"Amiga" chips on an Amiga system. I (respectfully) disagree. Put up a 16 color HIRES|LACE and max overscan, and watch your disk performance drop. Shut it off, and watch it increase. >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" -- William J. Coldwell PLink: CRYO I'm a 3-DPro, wouldn't you Amiga Attitude Adjuster BIX: wjcoldwell like to be a 3-DPro2 ? Cryogenic Software UUCP:billc@cryo 3-D PROFESSIONAL 2.0 #define STD_DSCLMR "The above opinions are mine. You can't have them."