Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Okay, you Amiga Types, its time to bash your amiga. :) Keywords: Amiga Message-ID: <17615@cbmvax.commodore.com> Date: 15 Jan 91 18:20:51 GMT References: <3783@mentor.cc.purdue.edu> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 85 In article <3783@mentor.cc.purdue.edu> aru@mentor.cc.purdue.edu (Sriram Ramkrishna) writes: >Okay, I got a question here. Now, we all heard how great and wonderful >the Amiga is. Now, I want to know, what are its bad points? Especially, >the new Amiga 3000. Are people finding things wrong with it? I heard that >there are some hardware bugs, and before I sing 4000 dollars into an Amiga >system, I want to know if I should wait till they fix these bugs or if they >will fix them for me or what? Is there a 1 year warrantee? Help me, guys! :) Hardware bugs! Not on the Amiga 3000! You sure they weren't saying "Apollo 3000" or "Archemedes 3000". Actually, there is a bug in the memory controller that we know about. That only affects one mode in that device, and so we don't turn that mode on. The memory controller has two modes that work with static column RAM. The one we do use is a direct support for 68030 burst reads (also does 68040 or Zorro III burst writes), and that works like a champ. The mode that doesn't work quite right is the page-detect mode. In this mode, the chip latches the memory page on any read or write, and keeps the memory page open (RAS* and CS* held low) until the next cycle. If the page on the next cycle is the same as that latched, the cycle runs in 3 clocks instead of 5. If not, the page is closed (taking 2 clocks), then another standard random cycle ensues, taking the standard 5 clocks. The bug in the chip shows up when DMA happens at just the wrong time. So, as I mentioned, we don't use this mode. Newer versions of the memory controller will ultimately fix the problem, which is well understood at this point. So far, our software folks haven't found this mode to help any under AmigaOS anyway, but it could help under UNIX, and will help with strictly block-oriented transfers like DMA and Zorro III burst. Aside from that, I don't know of any hardware-related bugs on the A3000, and of course, this one known one doesn't affect anything. I have been using A3000s longer than just about anyone, and haven't had any problems with them. Since so much of the A3000 design was done in custom chips, we had the actual motherboard design pretty well down way in advance of the system's release. There are some know software problems. Aside from any 2.0 compatibility issues, they all fall into the class of "programmer error" on the part of the offending software. Some are innocent errors, some are blatent disregard of proper Amiga programming rules. Some of the error categories: - 68030 Problems. Some programs ignored the Amiga rules about full 680x0 compatibility. Things like "don't write self modifying code", "use the GetCC() function", etc. Most of these rules were in the pre-1.0 ROM Kernel Manuals that A1000 developers got. I did an expanded talk on this at the Washington D.C. DevCon in 1988. - Speed Dependency. It has always been illegal to use software timing loops, or much else that depends on machine architecture for timing information. Some do it anyway. The A3000 is a tad faster than the A2630 to fast RAM, bit its also twice as fast to Chip RAM for 32 bit operations. So a few speed dependencies that didn't show up on other Amigas are seen now on the A3000. - 32 Bit Addressing Failures. Some programs, accidently or purposely, work only on 24 bit machines. The bad ones are often ports from the Mac, which stuff tags up in the high-order 8 bits of address pointers. This has been strictly forbidden since before the A1000 was released. A few are simply accidental, like string copies that go one byte too far, trashing the high order byte of a pointer following that string in memory. This still works on a 24 bit machine if you're using c-strings, since you're replacing a zero with a zero, but for non-24 bit pointers, that's a problem. In general, there are always programming rules. Each and every one of them is there for a reason, many times a specific reason, something we know about way in advance. It's unfortunate that there's no hard and fast way we can force 3rd party software houses into following those rules, any more than Apple or MicroSoft/IBM can. Our software folks have, over the course of the 2.0 and A3000 development, come up with a number of MMU based tools than can help catch a wide range of hidden programming errors. These tend to make applications more solid on all Amiga platforms, and should minimize the number of program bugs that can sneak past the A3000 but fail on whatever comes after it. With all that said, I can honestly say I have yet to find a program I use that fails on the A3000. I'm not much for playing games, but all my useful software runs fine. Even the stuff I wrote myself.... > sri -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley