Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!pikes!bscott From: bscott@pikes.Colorado.EDU (Ben Scott) Newsgroups: comp.sys.amiga.tech Subject: Re: Why no enhancer for the 500 right away. Summary: What's all this then? Message-ID: <3652@pikes.Colorado.EDU> Date: 2 May 90 12:20:40 GMT References: <9004260523.AA15404@jade.berkeley.edu> <1748@corpane.UUCP> <11212@cbmvax.commodore.com> Reply-To: bscott@pikes.Colorado.EDU (Ben Scott) Organization: University of Colorado, Denver Lines: 42 In article <11212@cbmvax.commodore.com> peter@cbmvax (Peter Cherna) writes: >Incidentally FastMemFirst arranges to use any true fast memory before >this 512K of "not-chip" so-called-fast memory, which is the most >efficient ordering. This is not required anymore under 2.0, or under >1 MB chip machines. I was under the impression that FastMemFirst actually helped prevent CHIP RAM being used before Fast RAM, and had little to do with "slow-fast". Either way, great news that 2.0 has this built-in. >the A500 and A2000 were designed for. So the conversion to true chip >memory is (at most) one jumper. [...] >No, the A501 (and a jumper change along with Super Agnus if you don't >have it) is all you need. News to me! I had to saw through a trace on my 500 when I put in the Super Agnus, and it was a real female dog... those suckers are a lot tougher than they look! And since I didn't trust myself with a soldering iron, I just cut the one half of the jumper and taped a tiny piece of foil across the other half... hey, it worked (for about 8 hours). Finally got someone qualified to finish the job. But the "Official" CBM instruction sheet I got clearly stated you must cut one trace and change a jumper, and it works. And here's a question for you tech gurus out there, re: the endless DMA- vs-nonDMA HD controller (personally I favor the DMA side, but...). Why is it not possible (or is it?) to make a hybrid controller that uses parts of BOTH halves of the bus? I know it would be fairly complicated, but wouldn't it be worth the effort to write a smart algorithm that could sense which half was being used more (either the custom chip half in heavy use due to a hires screen or two, or the CPU half under a load due to a busy program) and tailor it's transfers to use what capacity was available? At optimum, this could result in nearly double the overall bandwidth available, and it would also eliminate any graphics collision or CPU lockup problems at a stroke. I'm assuming this is too hard, because it hasn't been done yet, but...? . <<<>>> -- |Ben Scott, professional goof-off and consultant at The Raster Image, Denver| |Available at FIDO address 1:104/421.2 & the Arvada 68K BBS at (303)424-9831| |"Racket? That's BRAHMS! Brahms' Third Racket!" - Basil Fawlty/John Cleese| |"Tell him yes on one and no on two." - Buckaroo Banzai | *AMIGA POWER!* |42|