plouff@nac.dec.com (Wes Plouff) (11/11/88)
[The first posting of this message got caught in mail-virus madness, so here it is again.] First, hats off to Brad Fowles! It's not ugly at all. Cheap, yes, ugly, no. The DSACK tuning seems a minor weakness in an excellent effort. Herewith a few short comments... - Brad recommends storing the unused 68000 chip in styrofoam. That's a real static electricity no-no. Use conductive foam, black and crumbly or pink and bubbly. Even though 68000s cost only $12 or so, this is a dumb way to lose one. - In urging Commodore to produce a "68030 for Amiga 2000," Chris Gray (myrias!cg) says: >We hear stories on the net that Commodore has a 33 MHz 68030 card for the >Amiga 2000 running. >Is something along this lines the reason why they haven't released the > 68020 card yet? After all, it's 14 MHz doesn't seem like a lot, especially > now that there is a public domain one (LUCAS) that's faster than that for > considerably less money. Higher clock speed is not the only way to get performance. Faster memory and 32-bit memory each add significant performance to a 68020 system. When the memory "granddaughter" card is available, then make a comparison. Until then, I'd bet on the Commodore card. Hal Hardenbaugh's columns in _Programmer's Journal_ and elsewhere have explained this memory bandwidth problem. - Dave Haynie (who certainly ought to know about 68020s) calls Lucas a "hack." Well, compared to some A1000 products out there, Lucas is pretty good. As a hardware engineer, I cringe at the design where DSACK timing depends on choosing U9, rather than on worst case timing. But that seems a minor sin compared to the flaky bus timing of many SOTS boxes. Now the questions... - How should the jumpers (next to U4 on the schematic) be connected? - With superfast RAM installed through the DIN connector, how will short memory cycles (about 2 clocks on the Amiga bus) affect the regular Amiga timing circuits, especially the Chip RAM multiplexing? -- Wes Plouff, Digital Equipment Corp, Littleton, Mass. plouff%nac.dec@decwrl.dec.com "All the popular bugs in the RAM-Handler were fixed in Version 1.3." Amiga Enhancer Software Manual, page 1-17
daveh@cbmvax.UUCP (Dave Haynie) (11/15/88)
in article <8811110336.AA17455@decwrl.dec.com>, plouff@nac.dec.com (Wes Plouff) says: > - Dave Haynie (who certainly ought to know about 68020s) calls Lucas a > "hack." Well, compared to some A1000 products out there, Lucas is > pretty good. Hacks aren't necessarily bad things, either; I'm not trying to badmouth LUCAS. In fact, I like the idea. But it's very much like using some of the PD software out there: [A] It costs much less than a commercial product. [B] It might not work with all possible system configurations. [C] If it doesn't work, you have the plans (source code), and if you're knowledgable, you might be able to fix it. [D] You can learn how it works. [A] is certainly important to lots of folks, especially those who are using Amigas for hobby rather than to put food on their tables. [B] is something I definitely expect for LUCAS, but I don't mind, that's part of being non-commercial, at least for the moment. Brad obviously didn't have a company like Commodore paying for his efforts over the last year, so you expect this. A commercial product is (ideally, at least, some folks are more than willing to sell you junk) the result lots of additional effort, and along with the board you get someone to yell at if it doesn't work right. They provide [C] instead of you doing it yourself. Of course, a very good PD program may be supported better than some commercial stuff, but if you buy a commercial product, you have a right to expect support, if it's PD, you're fortunate if you get it. Point [D] is for those who enjoy doing it themselves, and learning the how and why of it. I think LUCAS succeeds here, too; it's a bite sized design, and easy to understand. > As a hardware engineer, I cringe at the design where DSACK timing depends > on choosing U9, rather than on worst case timing. I'm not going to point any fingers, but there was a commercial product for the A1000 that had exactly the same kind of hand-tuning problem. That's another of the things I mean when I call it a hack. I have no problem with hand tuning something in onsy-twosy quantities, but you certainly can't build 10,000 of something and have that same option. > - With superfast RAM installed through the DIN connector, how will short > memory cycles (about 2 clocks on the Amiga bus) affect the regular Amiga > timing circuits, especially the Chip RAM multiplexing? The proper thing to do here is to hide those cycles from the main Amiga system, by holding off /AS to the Amiga when you detect you'll be running a fast cycle. I don't recall how LUCAS does this, I really do plan to learn some of it's details as time permits. > Wes Plouff, Digital Equipment Corp, Littleton, Mass. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession