grr@cbmvax.commodore.com (George Robbins) (04/08/90)
In article <BRENT.90Apr6143037@asparagine.phri.nyu.edu> 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)
phupp@warwick.ac.uk (S Millington) (05/02/90)
I was away for a bit, vacation & exams, the origional article timed out
before I could get to read it - would someone be kind enough to e-mail it
to me. Thanks.
>DOES ANYONE HAVE THE STEP-RATE SLOWDOWN PROGRAM FOR THIS MOD?
Have I also missed this posting, if so e-mail please. Thanks alot.
*************************************************************************
* Stuart Millington * "A Mind Is A Terrible Thing, Remember *
* * That." - David Bryan, Bon Jovi *
* JANET:phupp@uk.ac.warwick.cu *****************************************
* ? :phupp%warwick.ac.uk@nsfnet-relay.ac.uk *
*************************************************************************p554mve@mpirbn.UUCP (Michael van Elst) (05/02/90)
In article <3673@minyos.xx.rmit.oz> rxtajp@minyos.xx.rmit.oz (Andrew Pettifer) writes: >Kramden SI reports performance of: >Integer 1.8 times A1000 >Floeting 1.4 times A1000 >After trying several programs like Aegis Drawplus, and sculpt 3d, >i am very dissappointed, the speed up seems to only be about 5%. >Hardly worth the effort. In this case, the memory cycles will slow down the operation of the 68000. You can either build a faster memory and operate twice as fast as an normal Amiga except for anything that runs in chip memory. A second approach does give about 70-80% speedup on average programs and will affect kickstart operations as well. This is a cache for the CPU. A direct-mapped cache is easily built. You'll need some fast cache tag rams plus the cache memory itself and three pals. This has been done for the Atari ST for a while. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."