Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: 14 Mhz Hack Message-ID: <21810@cbmvax.commodore.com> Date: 22 May 91 20:36:06 GMT References: <1991May13.081500.7980@rulway.LeidenUniv.nl> <1991May16.093917.28260@rulway.LeidenUniv.nl> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 87 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. Most of the designs that push the edge, from the original Microbotics Hardframe (for awhile, the best and only full speed DMA driven hard disk controller) to the latest 50MHz '030 boards from GVP, are following C= specification. >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. You might find any given Commodore system that seems to go many nanoseconds faster than the specification. That's not a problem, and not something any designer should ever count on. A specification generally says "it won't be any _slower_" or "you won't get any _less_ power", that kind of thing. These specifications are often derived from serious analysis of a system's worst case limits. You might get lucky avoiding the specifications sometimes, but you may not always get that lucky. Your luck could theoretically hold with every Commodore system you deal with, but fail with a 3rd party device, which gets closer to the worst case specification than Commodore does. Again, specs are so that everyone plays by the same rules. They don't tell you what's actually happening, they tell you what you need to know to make sure things always continue to happen \ properly. >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 >about even an FMOVE getting to it. The IEEE libs handle that very nicely >(thanks Dale!), as long as you don't try running a program specifically >compiled for 680x0/88x. As for a PFLUSH getting to an FPU, I find that >highly unlikely with the way the system is set up. 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. When you code an FMOVE or PFLUSH, that gets translated to a specific cpu space address. Part of that address contains the fact that the instruction is for a coprocessor, part tells which coprocessor, and part tells which command. If the 68020 board logic which generates the coprocessor chip select also responds to MMU commands (eg, it doesn't fully consider the coprocessor address), the FPU will respond to MMU instructions. I taught SetCPU to figure out when this was happening without crashing your system. I don't know if Enforcer or any of the other MMU tools are going to be as nice to such a setup. >> 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. 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. 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. > William J. Coldwell PLink: CRYO I'm a 3-DPro, wouldn't you -- 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.