Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!oliveb!amiga!cbmvax!grr From: grr@cbmvax.commodore.com (George Robbins) Newsgroups: comp.sys.amiga.hardware Subject: Re: A500/14 MHz 68k? Message-ID: <10704@cbmvax.commodore.com> Date: 7 Apr 90 21:38:33 GMT References: <8903@chaph.usc.edu> <10630@cbmvax.commodore.com> Reply-To: grr@cbmvax (George Robbins) Organization: Commodore, West Chester, PA Lines: 41 In article brent@asparagine.phri.nyu.edu (& Hobbs) writes: > In article <10630@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: > > > In article <8903@chaph.usc.edu> aliu@nunki.usc.edu (Terminal Entry) writes: > > The E-clock problem is simpler, but harder to fix... > > If the timing was a problem couldn't you use the same trick as the > initial hack and put another D flip-flop between CPU clock/10 > and the 8520's, thereby dividing the clock down to 714KHz again? > (Heck, the 74F74 is a dual package -- you could use the other > flip-flop and save yourself $.30!) No, since the E-clock serves two functions - (1) it provides a constant pseudo 1MHz E-clock/phi2 signal to all the I/O parts, and (2) the processor agrees to syncrhonize I/O accesses to "6800" peripherals with the E-clock. Externally dividing by 2 doesn't take care of the second issue, since E is a processor output, rather than input. You need a moderately messy state machine that emulates E clock behavior using VPA/AS as an input and DTACK as and output to handle this correctly. > Also, is there any reason that this hack would be more/less likely to > work on a 1000? Hard to say. Aside from grounding and layout issues, the detail implementation of the system control and decode logic is is different. It might be better or worse. One thing to note is that the Amiga expansion bus is explictly specified to operate as a synchronous bus where boards may expect all transactions to look like 4-clock 68000 CPU cycles and DMA bus masters are expected to look like 68000 CPU. This is to avoid all the painful synchroniztion issues implicit in the broader 68000 "asynchronous" environmnet, however when the processor is run at 14 Mhz, things are no longer happen "when expected" according to this rule. This can break stuff (like the system control logic) not designed in a highly defensive mode. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)