Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!lll-winken!uunet!portal!cup.portal.com!Sullivan From: Sullivan@cup.portal.com (sullivan - segall) Newsgroups: comp.sys.amiga Subject: Re: AmigaDos 1.3 (dh0: vs ASDG 8mb board) Message-ID: <16593@cup.portal.com> Date: 2 Apr 89 20:38:46 GMT References: <95522@sun.Eng.Sun.COM> <584@madnix.UUCP> Distribution: usa Organization: The Portal System (TM) Lines: 72 >In article <95522@sun.Eng.Sun.COM> drh@sun.Eng.Sun.COM (D. Ryan Hawley) writes: >>I posted a question a few weeks ago regarding problems between >>my 50 MB Fuji disk drive Pacific Periphs. controller and the >>ASDG 8 MB board (System gurus with board installed, worked o.k. >>under 1.2 AmigaDos, seems to be related to FastFilesystems). >>Did anyone see any replies? I must have missed them. If >>you posted a reply, or saved any replies please send them directly >>to me. > >After testing the Overdrive controller here at ASDG, we feel that there >is reason to believe that a timing inconsistancy is present in that disk >controller (the details of which we have discussed in previous messages >on this subject). > >The FastFileSystem exacerbates the problem by allowing lengthy transfers >of greater than 512 byte blocks where the OFS always did i/o in 512 byte >clumps. By doing longer transfers, the likelyhood of hitting the timing >gotcha goes up. > There is in my mind, some question as to whether or not the ASDG boards should rely on any timing peculiarities of the Amigas. Everyone wants to cut corners to keep the chip count, and therefor the cost of their hardware down, but when those modifications make the hardware very timing dependent, they should be avoided. Similarly, P-p's controller should have left in enough logic not to generate those spurious signals. That doesn't mean that the ASDG card is not at fault. Every add on peripheral should be robust on input and legal on output. Accepting obvious timing flaws (such as not asserting some signal before cycle X) is a design requirement in a system where multiple vendors will be playing with those signals. >Try setting your MaxTransfer value in your mountlist to successively >lower and lower numbers until the problem disappears. If it doesn't >go away give the service department of Pacific Peripherals call for >any pointers they might have. Calling us for assistance will earn a >more detailed answer but with the same bottom line (we are unable >to come up with any change or modification to our board which will >unilaterally cure the problem). > Since this negates most of the benefit of using the fast filing system, it is obviously an insufficient answer. Two other alternatives might be to pull some of the memory out of your 8 meg board, or to purchase one from some other company. I haven't had any trouble with my A2052 and P-p controller. >(Clearly, you may perceive this note as being biased since the author >is associated with ASDG. Be that as it may, we are ready to provide >the supporting technical data to any interested parties). > Personally I've never heard ASDG admit any fault with any of their hardware, yet I've never had similar problems with any other memory boards. Yes I perceive this note as being a little bit biased. >-- > Perry Kivolowitz, ASDG Inc. >ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque! >UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry >CIS: 76004,1765 (what was that about ``giggling teenagers''?) Not a flame, just an opinion. The hardware doesn't work together. Memory boards are easy to find. I'd stick with the P-p controller. I'd replace the memory card. -Sullivan Segall _____________________________________________________________ /V\ Sully set the example: to fly without moving. We shall ' learn to soar on wings of thought. And the student will surpass the teacher. To Quote the immortal Socrates: "I drank what?" -Sullivan _____________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com