grr@cbmvax.UUCP (George Robbins) (01/01/70)
In article <20043@ucbvax.BERKELEY.EDU> robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) writes: > In article <2695@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes: > >In article robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) writes: > >[regarding a double speed 68000/10 add-on] > > Yes, yes, yes, I know. I hate to keep bothering everyone with this, but the > purpose of my original posting was to try and determine whether there would > be a speed-up even with fast RAM. If a memory expansion does not use > demand/contention refresh, but rather assumes that the processor can safely > be locked out of every other cycle, then there will be almost no speed > increase in fast RAM either. I still haven't heard anything from anyone > affiliated with the various manufacturers of memory expansions. Am I to > assume from the silence that every manufacturer of memory expansions for > the Amiga is cheating on the refresh? Perry? You could refrain from calling it cheating or otherwise implying that there is something wrong with designing memory such that it works nicely with the the Amiga as it comes from the box. In the marjority of cases it is better to blow alternate cyccles for hidden refresh than to use a contention refresh scheme that causes wait states as do some of the external expansion devices. If I didn't mention this previously, Commodore A2000 2MB and 8MB boards use hidden refresh. I don't know that any of the expansion boards that will run double speed, although you should send mail to Perry, his hardware designer is a clever person with performance on his mind. I suspect though, that if you want fast:fast:fast RAM, you have to put it on your board... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
robinson@renoir.Berkeley.EDU (Michael Robinson) (08/05/87)
I have located part numbers and suppliers for a circuit which will deliver
an exactly doubled, crystal controlled, syncronized clock signal to a
16MHz 68010 sitting on a daughter board in the processor socket.
This will, in theory, double (plus some) the processor speed of the
Amiga. To the rest of the system, this will mean the processor will be
making data requests every clock cycle, instead of every other.
Before I initiate any mutilation, I would like to know what effects this will
have on the various "fast" ram upgrades available. Presumably, memory
refresh magic goes on behind the 68000's back during the "off" cycles in
normal operation. However, do the memory expansions lock out all the
"off" cycles, or only the ones they need for refresh. In other words,
if the processor starts requesting data transfer on every system clock,
what percent of the time will it get it?
I would greatly appreciate it if those associated with the manufacture
of the various expansion boards could comment.
Thank you.
------------------------------------------------------------------------------
Mike Robinson USENET: ucbvax!ernie!robinson
ARPA: robinson@ernie.berkeley.edugrr@cbmvax.UUCP (George Robbins) (08/06/87)
In article <19965@ucbvax.BERKELEY.EDU> robinson@renoir.Berkeley.EDU (Michael Robinson) writes: > I have located part numbers and suppliers for a circuit which will deliver > an exactly doubled, crystal controlled, syncronized clock signal to a > 16MHz 68010 sitting on a daughter board in the processor socket. > > This will, in theory, double (plus some) the processor speed of the > Amiga. To the rest of the system, this will mean the processor will be > making data requests every clock cycle, instead of every other. I am not familiar with a 68010 board of this description, however there are some common issues to consider. 1) even if the processor is running at twice the speed, it must externally emulate a 68000 to interact with the on-board logic and to access the onboard RAM. This would mean that multi-cycle instructions would go faster, but memory bound ones would not. 2) expansion RAM could conceivably handle faster cycles by returning DTACK themselves, rather than accepting the default system timing, however i am not aware of any boards that do this. 3) for real speed, you would have to put some RAM on your adapter board that runs a roughly processor speed. Life will soon become complicated. 4) if you're going to all the trouble to do the above, you might as well use a 68020 and get some real performance. The software already supports this. 5) some memory boards use traditional demand/contention based refresh, others use hidden refresh, knowing that unless they do something special, memory cycles are double length. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
rap@dana.UUCP (Rob Peck) (08/06/87)
In article <19965@ucbvax.BERKELEY.EDU>, robinson@renoir.Berkeley.EDU (Michael Robinson) writes: > I have located part numbers and suppliers for a circuit which will deliver > an exactly doubled, crystal controlled, syncronized clock signal to a > 16MHz 68010 sitting on a daughter board in the processor socket. > > This will, in theory, double (plus some) the processor speed of the > Amiga. To the rest of the system, this will mean the processor will be > making data requests every clock cycle, instead of every other. > > Before I initiate any mutilation, I would like to know what effects this will > have .... [devil's advocate mode on] FOR ACCESS TO CHIP MEMORY ------------------------- Unfortunately, there is a reason that the 68000 only grabs every alternate clock cycle to access the memory. That is to allow the other DMA, (that includes Video - one of Amiga's strong points) to access the RAM to create the display. The other DMA includes the sound, the sprites and the onboard RAM refresh that occurs during the first 8 clock cycles of the horizontal video scan line; these DMAs being spaced at each alternate clock position. Purchasers of the early docs for the Amiga got a chart that shows how DMA is distributed (that chart unfortunately got missed when the AW final versions of ROMK got printed). Bottom line is that during NON display times, your circuit might cause a speedup. This happens at the end of each display line time (a coupla percent) and during the vertical retrace time (about 62/263rds of the time). This advantage would be further cut if someone was running MOREROWS since more video time would be alloted and correspondingly less idle time. Video and other DMA automatically take precedence over the processor, so DTACK will be held off for your new speedup circuit until a processor grant could actually be made. Thus, it would indeed be ABLE to make a memory access each clock cycle, but it would end up waiting just as long as the original processor, effecting no speedup during times of heavy video DMA, (when accessing exclusively CHIP RAM). COMBINATION OF CHIP MEM AND NONCHIP MEM ACCESS ---------------------------------------------- For a 4 bit plane low resolution display, the video DMA still allows the normal 68000 to run full speed, leaving every alternate slot open for 68000 access. For a 2 bit plane high resolution display, it is the same situation. You WILL gain speed when: a) less than this number of low or high res bit planes is used (more memory time slots available for your higher speed processor) b) accessing external memory boards exclusively (or onboard ROM) (due to the split bus design of the Amiga, wherein the DMA access and the processor access to memory take place on separate busses and don't clash with each other). [ devil's advocate mode off ] When I create things for the Amiga, I am usually so embroiled in showing what the graphics or sound can do, I sometimes forget that it is a perfectly good general purpose computer with a well-designed multi-tasking exec built in, that works in ROM (or ROM equivalent, that is), or with whatever RAM is in the system, not necessarily all in CHIP mem. (Then too, I've lived with an exclusively CHIP mem machine for so long, no wonder I forget. In light of this, I must conclude this by saying that I LIKE YOUR IDEA, and encourage you to pursue it further; good luck; I want to try one when you've completed it. (CSA musta started this way, somehow). It may not give 2X+ performance, but it would certainly help depending on what kind of program was being run. I just wanted to point out some possible limitations. :-) :-) :-) Rob Peck ...ihnp4!hplabs!dana!rap DISCLAIMER: These opinions are mine, based on educated guesses and old documentation.
robinson@renoir.Berkeley.EDU (Michael Robinson) (08/07/87)
In article <2184@cbmvax.UUCP> George Robbins write: >In article <19965@ucbvax.BERKELEY.EDU> I write: >> I have located part numbers and suppliers for a circuit which will deliver >> an exactly doubled, crystal controlled, syncronized clock signal to a >> 16MHz 68010 sitting on a daughter board in the processor socket. >> >> This will, in theory, double (plus some) the processor speed of the >> Amiga. To the rest of the system, this will mean the processor will be >> making data requests every clock cycle, instead of every other. > > I am not familiar with a 68010 board of this description, however > there are some common issues to consider. Sorry if I wasn't clear. The circuit does not exist yet, but will if I decide to make it. > 1) even if the processor is running at twice the speed, it must > externally emulate a 68000 to interact with the on-board logic > and to access the onboard RAM. This would mean that multi-cycle > instructions would go faster, but memory bound ones would not. Exactly why I am concerned about the behavior of "fast" memory expansion. > 2) expansion RAM could conceivably handle faster cycles by returning > DTACK themselves, rather than accepting the default system timing, > however i am not aware of any boards that do this. I do not want faster cycles, but rather maximum usage of the cycles that are already there. That is, by doubling the speed of a 68010, it will access the bus on every system cycle, rather than every other system cycle. > 3) for real speed, you would have to put some RAM on your adapter > board that runs a roughly processor speed. Life will soon become > complicated. The design I have is extremely simple and inexpensive (<$20), and if I can make it work without extra headaches, all the better. > 4) if you're going to all the trouble to do the above, you might as > well use a 68020 and get some real performance. The software > already supports this. Since I do not intend to go to the trouble of #3, #4 is equally out of the question. > 5) some memory boards use traditional demand/contention based > refresh, others use hidden refresh, knowing that unless they > do something special, memory cycles are double length. This is what I need to know--which boards to demand/contention refresh, and which boards cheat. ------------------------------------------------------------------------------ Mike Robinson USENET: ucbvax!ernie!robinson ARPA: robinson@ernie.berkeley.edu
hah@mipon3.intel.com (Hans Hansen) (08/09/87)
In article <204@dana.UUCP> rap@dana.UUCP (Rob Peck) writes: >In article <19965@ucbvax.BERKELEY.EDU>, robinson@renoir.Berkeley.EDU (Michael Robinson) writes: >> I have located part numbers and suppliers for a circuit which will deliver >> an exactly doubled, crystal controlled, syncronized clock signal to a >> 16MHz 68010 sitting on a daughter board in the processor socket. >> > >[devil's advocate mode on] > >FOR ACCESS TO CHIP MEMORY >------------------------- > >Unfortunately, there is a reason that the 68000 only grabs every alternate >clock cycle to access the memory. That is to allow the other DMA, >(that includes Video - one of Amiga's strong points) to access the RAM >Rob Peck ...ihnp4!hplabs!dana!rap [devil's, devil advocate mode on] <But first ... Hi Rob> The 14MHz 68010 idea is a real winner! Why? 1) I thought of it too! 2) Not all 68K cycles are also memory cycles. Therefore all multiple processor cycles will be sped up. ***** Problem ***** The R/W access of a 68000/68010 running at 14MHz will not allow sufficient address setup time for the DRAMs and the 8520s. A 1 micro cycle delay is needed during all reads and writes to the existing DRAM and 8520s. I proposed such a circuit to Bill Kolb in Dec 1984 or Jan 1985. <It was never followed up on due to the lack of 14.5MHz 68000/68010s at that time.> Second problem: The TrackDisk device will need to be tuned. Third problem: Copy protected programs will for the most part not load. Hans The kid with an idea a little ahead of its time.
robinson@renoir.Berkeley.EDU (Michael Robinson) (08/09/87)
In article <942@omepd> hah@mipon3.UUCP (Hans Hansen) writes: >In article <204@dana.UUCP> rap@dana.UUCP (Rob Peck) writes: >>In article <19965@ucbvax.BERKELEY.EDU>, robinson@renoir.Berkeley.EDU (Michael Robinson) writes: >>> I have located part numbers and suppliers for a circuit which will deliver >>> an exactly doubled, crystal controlled, syncronized clock signal to a >>> 16MHz 68010 sitting on a daughter board in the processor socket. >[devil's, devil advocate mode on] > >2) Not all 68K cycles are also memory cycles. Therefore all multiple >processor cycles will be sped up. The big win (which many people seem to be overlooking) is that the 68000 and 68010 only use half the memory bandwidth available (the "every other" phenomenon). This circuit will hopefully remedy that situation. >***** Problem ***** > >The R/W access of a 68000/68010 running at 14MHz will not allow sufficient >address setup time for the DRAMs and the 8520s. A 1 micro cycle delay is >needed during all reads and writes to the existing DRAM and 8520s. I >proposed such a circuit to Bill Kolb in Dec 1984 or Jan 1985. <It was >never followed up on due to the lack of 14.5MHz 68000/68010s at that time.> How is this so? According to my 68000 timing diagrams, the address lines are set and stable upon assertion of AS, and will remain so for at least one and a half processor cycles after assertion of DTACK. Supposedly, the processor should not get DTACK until the address has been decoded and there is valid data on the bus. I thought that was the whole point of asynchonous bus control. If this is not the case with the Amiga, why not? >Second problem: The TrackDisk device will need to be tuned. Why? >Third problem: Copy protected programs will for the most part not load. Well, f*@# them. For me, doubled performance is more important than catering to juvenile paranoia. ------------------------------------------------------------------------------ Mike Robinson USENET: ucbvax!ernie!robinson ARPA: robinson@ernie.berkeley.edu
farren@hoptoad.uucp (Mike Farren) (08/10/87)
In article robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) writes: [regarding a double speed 68000/10 add-on] > >The big win (which many people seem to be overlooking) is that the 68000 and >68010 only use half the memory bandwidth available (the "every other" >phenomenon). This circuit will hopefully remedy that situation. The big win isn't quite as big as you might think. If accesses are being done to CHIP RAM, the normal arbitration circuitry of the Amiga will lock out the faster processor during most of those "every other" cycles, anyway. Only if you are accessing FAST RAM will the full speed-up come into being. Not that it isn't a good idea, though, but I just don't want people getting big hopes up, looking for 100% speed improvements, and getting 20%. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
robinson@renoir.Berkeley.EDU (Michael Robinson) (08/10/87)
In article <2695@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes: >In article robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) writes: >[regarding a double speed 68000/10 add-on] > >Only if you are accessing FAST RAM will the full speed-up come into being. Yes, yes, yes, I know. I hate to keep bothering everyone with this, but the purpose of my original posting was to try and determine whether there would be a speed-up even with fast RAM. If a memory expansion does not use demand/contention refresh, but rather assumes that the processor can safely be locked out of every other cycle, then there will be almost no speed increase in fast RAM either. I still haven't heard anything from anyone affiliated with the various manufacturers of memory expansions. Am I to assume from the silence that every manufacturer of memory expansions for the Amiga is cheating on the refresh? Perry? >Not that it isn't a good idea, though, but I just don't want people getting >big hopes up, looking for 100% speed improvements, and getting 20%. > > >-- >---------------- > "... if the church put in half the time on covetousness >Mike Farren that it does on lust, this would be a better world ..." >hoptoad!farren Garrison Keillor, "Lake Wobegon Days" ------------------------------------------------------------------------------ Mike Robinson USENET: ucbvax!ernie!robinson ARPA: robinson@ernie.berkeley.edu
grr@cbmvax.UUCP (George Robbins) (08/11/87)
In article <20005@ucbvax.BERKELEY.EDU> robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) writes: >In article <2184@cbmvax.UUCP> George Robbins write: >>In article <19965@ucbvax.BERKELEY.EDU> I write: >>> I have located part numbers and suppliers for a circuit which will deliver >>> an exactly doubled, crystal controlled, syncronized clock signal to a >>> 16MHz 68010 sitting on a daughter board in the processor socket. >> I am not familiar with a 68010 board of this description, however >> there are some common issues to consider. >Sorry if I wasn't clear. The circuit does not exist yet, but will if I >decide to make it. Uh, minor technical issue: where are you going to get these 16 MHz 68010 parts from? The Motorola folks were by today an I asked them what the status of fast 16 bit parts was at the present. They indicated that 12 MHz was the top speed for both the 68000 and 68010, although there was some chance that they might offer a ~16 MHz version of the CMOS 68HC000 sometime in the future. Now of course there's a pretty good chance you can get some some of the 12 MHz parts to clock at 14 MHz with reasonable reliability, but the timing margins won't be the best. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
daveh@cbmvax.UUCP (Dave Haynie) (08/11/87)
in article <2201@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) says: >>>In article <19965@ucbvax.BERKELEY.EDU> I write: >>>> I have located part numbers and suppliers for a circuit which will deliver >>>> an exactly doubled, crystal controlled, syncronized clock signal to a >>>> 16MHz 68010 sitting on a daughter board in the processor socket. > Uh, minor technical issue: where are you going to get these 16 MHz 68010 > parts from? The Motorola folks were by today and ... they indicated that > 12 MHz was the top speed for both the 68000 and 68010 ... Thompson (sp?) has been making a 16MHz 68000 for quite some time now. That could substitute until a faster 68010 can be found. I don't know if any of the second sources make 68010s, though lots of companies make 68000s. There may actually be others besides Thompson who are making the fast 68000s, but there is at least this one source. If you can take much advantage of the double clock speed (like, with some 14Mhz memory), you'll get a big speedup. The difference between the 68000 vs 68010 won't be all that great at equivalent speeds. -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" PLINK : D-DAVE H BIX : hazy "Catch a wave and you're sittin' on top of the world" -Beach Boys
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (08/11/87)
In article <2201@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <> robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) writes: >>In article <2184@cbmvax.UUCP> George Robbins writes: >>>In article <19965@ucbvax.BERKELEY.EDU> (Micheal Robinson) writes: >>>> >>>> I have located part numbers and suppliers for a circuit which will deliver >>>> an exactly doubled, crystal controlled, syncronized clock signal to a >>>> 16MHz 68010 sitting on a daughter board in the processor socket. > >Uh, minor technical issue: where are you going to get these 16 MHz 68010 >parts from? The Motorola folks [said 12 MHz was tops for the 68000 & 68010] >, although there was some chance that they might offer a ~16 MHz version of >the CMOS 68HC000 sometime in the future. I'll interject here: Not from moto, obviously. Dim memories from long ago bubble to the surface: I saw a full page add in "Electronic Engineering Times" for a 16 Mhz 68000. My memory is foggy enough to have forgotten if that was a vanila 68000 or if the 68010 was available also. Moto's stingey mask transfer policy may be the bottleneck here. *At least* the 68000 was shipping, for sure (or so the ad claimed). It was CMOS. The name of the company is on the tip of my tounge... tounge... European for sure... ummm... this was a while ago... ummm... aw drat. Seimens, I think. Thomson Components-Mostek as a long shot. I can't check a recent issue. I gave up reading EE Times 'cause it was not worth what I paid for the free subsription -> time to read it. ----------------------------- |\ /| . Ack! (NAK, EOT, SOH) {0 0} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "Success leads to stagnation; stagnation leads to failure."
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (08/11/87)
>In the marjority of cases it is better >to blow alternate cyccles for hidden refresh than to use a contention >refresh scheme that causes wait states... There is another option which allows a system to achieve near zero refresh wait-states without "resorting" to hidden refresh. It's only practical if you are building your own refresh controller from scratch. It involves a refresh count down timer that has multiple taps, the first tap is "refresh_request" the second is "refresh_demand". When request is active the controller will refresh the RAM whenever any *other* bank or area of memory is accessed, or when there is an idle slot. "demand" does the obvious and takes the refresh no matter what. Any design is simpler if you have CAS before RAS dram chips... This can be enhanced by always designing boards with at least two banks of memory, and setting them up at alternate machine-word addresses. A sequential read of memory by the processor would result in a free refresh slot on alternate banks, every cycle. You can simplify your design at the expense of hiking your power use by resetting a counter and refreshing at *every* free slot. If the counter ever runs down then you "demand" a refresh cycle. If you use this idea, be sure to inscribe credit "in copper" near the proper section of your circuit board. 1/2 :-) ----------- I first learned of the hidden refresh concept with relation to a memory board that only took a hidden cycle after a processor cycle on it's ram. So far so good. If the processor spent any meaningful time accessing some *other* ram then *this* ram would start to forget... forg... fo... f. BTW1: Dynamic ram can take a *long* time to decay. On the order of multiple seconds. Not that this information is of any use -> I'm sure a refresh system built on this as fact would be quite doomed. BTW2: Making OpticRAMs by taking the top off ceramic DIPs works! Your software refreshes a row, then reads it later to see if it decayed to zero (due to light). Use multiple cycles with different times for gray scale calculation. I had a lot of fun with this-> but I never go byond using a paper mask to create test images. I didn't and don't have a lens set up of any type. (Hand grining lenses... yeah that's the ticket. :-) >George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr Would the A2000 memory boards properly hold off a processor that tried to take a read cycle at the end of its hidden refresh, or would that tend to cause problems? |\ /| . Ack! (NAK, EOT, SOH) {o O} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "Success leads to stagnation; stagnation leads to failure."
robinson@renoir.Berkeley.EDU (Michael Robinson) (08/11/87)
In article <2201@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
)Uh, minor technical issue: where are you going to get these 16 MHz 68010
)parts from? The Motorola folks were by today an I asked them what the
)status of fast 16 bit parts was at the present. They indicated that 12 MHz
)was the top speed for both the 68000 and 68010, although there was some chance
)that they might offer a ~16 MHz version of the CMOS 68HC000 sometime in the
)future.
Well, there's a Motorola distributor in San Jose who claims to have 16MHz
68010's for sale. Maybe they lied to me. Maybe they're 12MHz parts that
test out well. I guess I'll have to call back and find out.
-Mike
------------------------------------------------------------------------------
Mike Robinson USENET: ucbvax!ernie!robinson
ARPA: robinson@ernie.berkeley.eduhah@mipon3.intel.com (Hans Hansen) (08/12/87)
The source for the 16MHz 68000/68010 is CSF Tompson(sp). Hans
grr@cbmvax.UUCP (George Robbins) (08/12/87)
In article <20065@ucbvax.BERKELEY.EDU> robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) writes: > In article <2201@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > )Uh, minor technical issue: where are you going to get these 16 MHz 68010 > )parts from... > > Well, there's a Motorola distributor in San Jose who claims to have 16MHz > 68010's for sale. Maybe they lied to me. Maybe they're 12MHz parts that > test out well. I guess I'll have to call back and find out. Could be the people I was talking to were confused, since they came in primarily to give a presentation on Analog stuff. I also apparently neglected some 16 MHz 68000 parts availabe from other vendors that would serve, although as far as I know Motorola is still the sole source for the 68010, although the somewhat illusory Signetics/Phillips 68070 is supposed to re-implement some of the 68010 stuff, albeit in Amiga incompatible form. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
scotty@l5comp.UUCP (Scott Turner) (08/17/87)
In article <2201@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >Uh, minor technical issue: where are you going to get these 16 MHz 68010 >parts from? The Motorola folks were by today an I asked them what the >status of fast 16 bit parts was at the present. They indicated that 12 MHz >was the top speed for both the 68000 and 68010, although there was some chance Yeah Motorola retreated from the high ground with the 68000 back in late '83. Until then they had plans of making a MC68000L16, they even made a few samples that went to places like Tektronix. But a 16MHz 68000 would be a tough chip to keep up with and yields etc... But leave it to the Europeans (How come they get all this neat stuff first?) to go where Motorola wouldn't. I think it's Phillips (but could be some other company) that has a CMOS 16MHz capable 68000. Also as one further note, just TRY and get a MC68010L12. Most 68010's are used in virtual memory systems which with the speed delays from the MMU are nearly ALWAYS limited to 10Mhz. If you walk in off the street and try to get a L12 you'll more than likely be out of luck, order 100 to 250 of them and you may only have to wait 6 to 10 weeks. In any case, a MC68000L12 is about $16 bux, a MC68010L12 is $158. For even more fun take a look at the price of a MC68020RC12 ~$100. I haven't figured out why a 68010 should cost more than a 68020 but the real point here is that unless you're going for a high speed 68000 design you may find it cheaper to use a 68020 rather than a 68010. >Now of course there's a pretty good chance you can get some some of the >12 MHz parts to clock at 14 MHz with reasonable reliability, but the timing >margins won't be the best. The 68000 is an amazing chip. :-) One of the cute things about it is that alot of it's timing values are based on the shape of the clock. You can "tweak" a 68000 chip into operating at higher speeds by carefully adjusting the shape of the clock signal feeding the chip. I've been selecting MC68010L10's in order to get parts that can run at 12Mhz. This can lead to weird happenings though. There was one system I had running on one of these selected parts that ran fine so long as the office coffee pot was turned off. But about an hour after they'd turn it on the computer would start crashing. Leave the coffee pot off for three days, no crashes. Turn it back on, crashes within the hour. (BTW 68010L10's are ~$50 which can be a strong motive for digging through them to find 12Mhz capable parts ;) Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan "Pirated software? Just say *NO*!" S. Turner
scotty@l5comp.UUCP (Scott Turner) (08/17/87)
In article <8708111710.AA12671@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >>In the marjority of cases it is better >>to blow alternate cyccles for hidden refresh than to use a contention >>refresh scheme that causes wait states... Yeah but just make sure you don't blow EVERY alternate cycle for refresh! You only need a refresh cycle every 15us... In fact the number 28 works out real slick on a 7.14MHz Amiga as the number of memory cycles to skip before using an alternate cycle for a refresh, or stealing a processor cycle. >BTW1: Dynamic ram can take a *long* time to decay. On the order of multiple >seconds. Not that this information is of any use -> I'm sure a refresh >system built on this as fact would be quite doomed. Actually the ol' 16Kx1 DRAMs could take 10 to 15 seconds to decay at room temp. I wrote this program to load the ram then cease activity till I told it to scan the ram and check it to see if any bits had decayed. I had to do it that way because of course the act of reading all the ram would refresh it! :) I then turned off the refresh and played with it. I found that if it cooled the board down with freeze mist I could make those suckers hold their values for over a minute! Hit it with the heat gun and none would last more than 4 seconds. But as chips got denser and denser the capacitors got smaller and smaller... The current 256Kx1's and 1Mx1's can't perform these herculean refresh feats. >calculation. I had a lot of fun with this-> but I never go byond using a >paper mask to create test images. I didn't and don't have a lens set up of >any type. I'll give ya a hint Bryce, Micron Technology. Not only do these guys make DRAMs with clear lids they even have lenses. ;) One point Bryce didn't touch on, if any of yall were going to play with yer DRAM's, is that once you take that lid off the chip is EXPOSED. This is OK for fooling around but for longer periods of time the chip will breakdown. (This is why Micron Technology puts a clear lid on their OptiRAMs) Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan "Pirated software? Just say *NO*!" S. Turner