simon@ivem1.uucp (Simon) (05/09/91)
Does anyone know the exact difference between a 16mhz A3000 and a 25 mhz A3000 other than these numbers? Another words, is there a way that I could upgrade a 16mhz A3000 to a 25mhz A3000, by say replacing the crystal or the 68030 chip. I'd like to get the 16mhz A3000 w/ PowerUp program, and upgrade myself to a 25mhz. Anyone? Anyone? Anyone? Anyone? Anyone? ... -Simon -- * Simon Lee * Southwestern Regional Resource for * * simon@ivem1.ucsd.edu * Intermediate Voltage * * sulee@ucsd.edu * Electron Microscopy, UC San Diego *
metahawk@itsgw.rpi.edu (Wayne G Rigby) (05/09/91)
In article <5308@network.ucsd.edu> simon@ivem1.uucp (Simon) writes: >Does anyone know the exact difference between a 16mhz A3000 and >a 25 mhz A3000 other than these numbers? Another words, is there >a way that I could upgrade a 16mhz A3000 to a 25mhz A3000, by say >replacing the crystal or the 68030 chip. I'd like to get the >16mhz A3000 w/ PowerUp program, and upgrade myself to a 25mhz. > >Anyone? Anyone? Anyone? Anyone? Anyone? ... >-Simon > >-- >* Simon Lee * Southwestern Regional Resource for * >* simon@ivem1.ucsd.edu * Intermediate Voltage * >* sulee@ucsd.edu * Electron Microscopy, UC San Diego * Nope, can no do. Replacing the crystal and/or the 68030 would be a BAD idea. The only way you could upgrade to a 25 MHz machine is to get a 25 MHz accelerator board. The only boards I've heard for the 3000 are 68040 25 MHz. So, my suggestion would be to either go for a 25 MHz 3000, or get a 16 MHz and upgrade to an '040. PS: thanks for the dissemblance on the bus/timing limitations Dave Haynie! Wayne Rigby Computer and Systems Engineer (in training) Rensselaer Polytechnic Institute metahawk@rpi.edu
daveh@cbmvax.commodore.com (Dave Haynie) (05/10/91)
In article <5308@network.ucsd.edu> simon@ivem1.uucp (Simon) writes: >Does anyone know the exact difference between a 16mhz A3000 and >a 25 mhz A3000 other than these numbers? Another words, is there >a way that I could upgrade a 16mhz A3000 to a 25mhz A3000, by say >replacing the crystal or the 68030 chip. I'd like to get the >16mhz A3000 w/ PowerUp program, and upgrade myself to a 25mhz. There are three component differences, and a couple of jumper settings. The three components: 16MHz 25MHz 32.000 MHz Crystal Module 50.000 MHz Crystal Module MC68030-16, PQFP MC68030-25, PQFP MC68881-16, PLCC MC68882-25, PLCC The deal is, all of these parts are soldered in. You really don't want to de-solder a 140 pin Plastic Quad Flat Pack like the 68030 unless you REALLY know what you're doing. That usually involves special tools. I wouldn't attempt it myself, though we do have technicians capable of it here. No real need to mention that this would violate your warrenty bigtime, is there? It would be very, very easy for someone to build a dirt cheap 16MHz->25MHz upgrade board. All it would need (off the top of my head...) is 68882, 68030, a 50MHz clock module, a 10ns delay line, and a PAL or similar logic to effect the takeover of the A3000 bus from the 16MHz system. Thing is, most of the companies contemplating such upgrade things are thinking much bigger. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
JBK4@psuvm.psu.edu (05/10/91)
Why doesn't Commodore design and market upgrade boards for the Amigas? Somethi ng that you could put in your 3000, or whatever, and get 25Mhz from 16Mhz or ho w about their own '040 upgrade boards for the 3000? With the expansion of the Amiga line, I'd like to see something like this happen. Jason Koszarsky, JBK4@PSUVM.PSU.EDU
brueni@csgrad.cs.vt.edu (05/11/91)
In article <21450@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: [stuff deleted] >It would be very, very easy for someone to build a dirt cheap 16MHz->25MHz >upgrade board. All it would need (off the top of my head...) is 68882, 68030, [stuff deleted] On a similar note, if one were considering purchasing an A3000, and intended later to get a 68040 accellerator, it would be best to save $400 and get the 16Mhz version now, rather than the 25Mhz version. Right? -- %%%%%%%%%%%%%%%%%%%%%-DOT-SIGNATURE-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Dennis Brueni INTERNET: brueni@csgrad.cs.vt.edu
kzyx@vax5.cit.cornell.edu (05/12/91)
I wonder how much I have to change to get a 25 MHz 040 in a 16MHz stock A3000. For instance, do I need to replace the memory chips for faster ones? Will the custom chips work at the higher clock rates, or they use a different clock? Thanks Edval Santos esantos@macdlab.ee.cornell.edu
kilian@cinnet.com (Kilian Jacob) (05/13/91)
From article <5308@network.ucsd.edu>, by simon@ivem1.uucp (Simon): > Does anyone know the exact difference between a 16mhz A3000 and > a 25 mhz A3000 other than these numbers? Another words, is there > a way that I could upgrade a 16mhz A3000 to a 25mhz A3000, by say > replacing the crystal or the 68030 chip. I'd like to get the > 16mhz A3000 w/ PowerUp program, and upgrade myself to a 25mhz. > As far as I heard the only differences between the a3000/16 and the a3000/25 are the crystal and the cpu (16 and 25mhz version). The problem is that it's not *that* easy to replace a surface mounted chip. :-) -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
greg@ccwf.cc.utexas.edu (Greg Harp) (05/13/91)
In article <1991May12.210008.25823@cinnet.com> kilian@cinnet.com (Kilian Jacob) writes: >As far as I heard the only differences between the a3000/16 and the a3000/25 >are the crystal and the cpu (16 and 25mhz version). The problem is that it's >not *that* easy to replace a surface mounted chip. :-) In fact, it's quite hard to do. I guess a good measure of _how_ hard it is to do is to take note fact that Dave Haynie said he wouldn't try it. I think he said that they had some techs that could probably pull it off, but it takes some special tools and the know-how to use them. So, in other words, don't buy the 16Mhz version if you plan to just replace the chips and crystal with faster ones. I want to stress that because I forsee several people complaining because they thought they could pull it off simply. We have enough people thinking C= has screwed them when they have actually screwed themselves already... :) Greg -- Greg Harp |"I was there to match my intellect on national TV, | against a plumber and an architect, both with a PhD." greg@ccwf.cc.utexas.edu| -- "I Lost on Jeopardy," Weird Al Yankovic
mascot@bnr.ca (Scott Mason) (05/14/91)
In article <1991May11.150058.4684@vax5.cit.cornell.edu> kzyx@vax5.cit.cornell.edu writes: > > I wonder how much I have to change to get a 25 MHz 040 in a 16MHz >stock A3000. The 68040 implements a very different bus interface from the 68030. The amount of logic required to interface an 040 to a 68000 or 68030 slave is nontrivial. --
daveh@cbmvax.commodore.com (Dave Haynie) (05/15/91)
In article <4502@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >In article <1991May11.150058.4684@vax5.cit.cornell.edu> kzyx@vax5.cit.cornell.edu writes: >> I wonder how much I have to change to get a 25 MHz 040 in a 16MHz >>stock A3000. >The 68040 implements a very different bus interface from the 68030. >The amount of logic required to interface an 040 to a 68000 or >68030 slave is nontrivial. Well, that's a matter of what you consider trivial. It's certainly not a "do it yourself" exercise, unless you're an experienced hardware hacker. It's also not earthshakingly hard, either. The bus conversion logic for 68030->68000, 68040->68000, or 68040->68030, is typically a couple of PALs and a handful of buffer chips. A designer can increase the performance of such a system by adding more logic, but a basic converter isn't very difficult. In fact, when the 68040 stuff first came out, Motorola published an application note on how to convert a 68040 bus to a 68030 bus. I don't know if it's an optimal design, but it does appear to work. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
mascot@bnr.ca (Scott Mason) (05/17/91)
In article <21601@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <4502@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >>In article <1991May11.150058.4684@vax5.cit.cornell.edu> kzyx@vax5.cit.cornell.edu writes: > >>> I wonder how much I have to change to get a 25 MHz 040 in a 16MHz >>>stock A3000. > >>The 68040 implements a very different bus interface from the 68030. >>The amount of logic required to interface an 040 to a 68000 or >>68030 slave is nontrivial. > >Well, that's a matter of what you consider trivial. It's certainly not a "do >it yourself" exercise, unless you're an experienced hardware hacker. It's also >not earthshakingly hard, either. The bus conversion logic for 68030->68000, >68040->68000, or 68040->68030, is typically a couple of PALs and a handful of >buffer chips. A designer can increase the performance of such a system by >adding more logic, but a basic converter isn't very difficult. In fact, when >the 68040 stuff first came out, Motorola published an application note on how >to convert a 68040 bus to a 68030 bus. I don't know if it's an optimal design, >but it does appear to work. Dave, IMHO you are understating the case. The 68030 is not that different from the 68000 in the bus interface that it implements. A little combinatorial logic to translate the slightly different control signals and synchronizers for a few control signals are about all one would need. The bus protocol of the 68040 is significantly different from the '030 and '020. One basically ends up implementing the entire bus interface logic of the '030. As mentioned in the Motorola app. note that you site: - support for an asynchronous interace - dynamic bus sizing for 8-, 16-, and 32-bit ports (ed: biggie !!) - retry mechanism handled independantly of the 68040 - the bus arbitration protocol of the '020 (ed: or '030) emulated The first thing they drop down is a DMA controller, since the bus adapter may need to execute several slave bus cycles for one '040 access. All told they use: - 6 PALs - a phase-locked loop - upwards of 10 octal buffers - upwards of *115* external signals just for the bus adapter The '040 model for the external interface is significantly more advanced in some areas, such as multiprocessor support, than the '030, but it is correspondingly different. Some of the changes, such as dynamic bus sizing support, are probably because the rich '030 features were really dragging down the performance. --
daveh@cbmvax.commodore.com (Dave Haynie) (05/21/91)
In article <4520@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >In article <21601@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <4502@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >>>In article <1991May11.150058.4684@vax5.cit.cornell.edu> kzyx@vax5.cit.cornell.edu writes: >>>The 68040 implements a very different bus interface from the 68030. >>>The amount of logic required to interface an 040 to a 68000 or >>>68030 slave is nontrivial. >>Well, that's a matter of what you consider trivial. It's certainly not a >>"do it yourself" exercise, unless you're an experienced hardware hacker. >Dave, IMHO you are understating the case. The 68030 is not that different >from the 68000 in the bus interface that it implements. A little >combinatorial logic to translate the slightly different control signals >and synchronizers for a few control signals are about all one would need. It's a little more complex than that. You really do need a state machine for the conversion, because, even though you can get the 68030 doing 16 bit asynchronous cycles thanks to bus sizing, it does most everything on different edges than the 68000. Plus, you rarely want to drive the 68030 at the same clock rate as the 68000. So even where things would have lined up, you can't really take advantage of them. You also need to clock bus arbitration in terms of 68000 clocks, and emulate the VPA/VMA/E clock interface. Most of the Motorola notes on 68020/30 to 68000 bus conversion are insufficient to build a conversion board that's really compatible. And in a system like the A3000 that supports 68000 compatible DMA onto the 68030 bus, you need to go the other way, converting 68000 to 68030 cycles. This takes two extra buffers for bus bridging, so the 16 bit 68000 bus can access either half of the 68030 bus. >The bus protocol of the 68040 is significantly different from the '030 >and '020. One basically ends up implementing the entire bus interface >logic of the '030. As mentioned in the Motorola app. note that you site: > - support for an asynchronous interace Supporting asynchronous vs. synchronous really amounts to an extra clocking stage. That's essentially what happens inside the 68030, when you're using DSACKs* rather than STERM*. > - dynamic bus sizing for 8-, 16-, and 32-bit ports (ed: biggie !!) That's a few more buffers than a 68030->68000 interface, but it's not really that difficult. Handling the 32 and 16 bit ports doesn't take any more parts than the full 68030 to/from 68000 conversion case. The 8 bit ports on the A3000 are few, so in theory you could even keep the 68030 active to service 8 bit ports if you wanted to. Though you really need only one more buffer to service that. > - retry mechanism handled independantly of the 68040 Retry support is good for a complete conversion, but the A3000 doesn't use retry anywhere, so you could get by without it. > - the bus arbitration protocol of the '020 (ed: or '030) emulated That's trivial. >The '040 model for the external interface is significantly more >advanced in some areas, such as multiprocessor support, than the '030, >but it is correspondingly different. Some of the changes, such as >dynamic bus sizing support, are probably because the rich '030 >features were really dragging down the performance. Certainly. Motorola was correct in designing a faster interface for the '040, no matter how you slice it. For example, the memory interface is now efficient enough to cut out a wait state when running at 25MHz with 80ns RAM. That alone is worth dealing with a few annoyances that may creep in for dealing with lower performance things (all 16 or 8 bit ports on the A3000 are I/O or Zorro II related, most run at 68000 speeds anyway, so a little bit of inefficiency in accessing those is no big deal, really). -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
mascot@bnr.ca (Scott Mason) (05/22/91)
In article <21745@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: :In article <4520@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: : :: [ Me, understating the 68030->68000 interface, like many Amiga :: HW hackers :-) ] : :It's a little more complex than that. : [ Dave, commenting about synchronous dependancies for full 68000 : compliance ] Fortunately, I have only had to deal w/ async slaves. The Amiga seems to have taken maximum benefit from sync operation to the 68000, and must place the most stringent requirements of any target on the timing of an accelerator, even an accelerated 68000. :: [ 68040 to 68030 interface discussed] :: - dynamic bus sizing for 8-, 16-, and 32-bit ports : :That's a few more buffers than a 68030->68000 interface, but it's not really :that difficult. Handling the 32 and 16 bit ports doesn't take any more parts :than the full 68030 to/from 68000 conversion case. The 8 bit ports on the :A3000 are few, so in theory you could even keep the 68030 active to service :8 bit ports if you wanted to. Though you really need only one more buffer :to service that. Actually, this is more than just a matter of multiplexing the bytes around. The 68040 expects to run just one cycle for any fetch. The 68030 will run up to four bus cycles to complete a fetch. The bus interface must detect cases when the port size was smaller than the access size, and execute multiple bus cycles to assemble the data. :: - retry mechanism handled independantly of the 68040 : :Retry support is good for a complete conversion, but the A3000 doesn't use :retry anywhere, so you could get by without it. Once you have a complete dynamic bus sizing, you will have the DMA controller needed for retry support. --
daveh@cbmvax.commodore.com (Dave Haynie) (05/23/91)
In article <4540@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >In article <21745@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >:In article <4520@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >:: [ Me, understating the 68030->68000 interface, like many Amiga >:: HW hackers :-) ] >:It's a little more complex than that. >: [ Dave, commenting about synchronous dependancies for full 68000 >: compliance ] >Fortunately, I have only had to deal w/ async slaves. Everyone has to deal with async slaves; there aren't any truely synchronous slaves on any 68000 bus, since the 68000 bus is inherently asynchronous. They do have timings that let you treat it synchronously, which is what the Amiga chips do. But regardless of whether the slave behaves basically synchronous or basically asynchronous, the master has to be 68000 compliant or things will die. A synchronous master (one that bases its operations directly on the Amiga system clocks) can deal with this pretty easily. The real trick is synchronizing to asynchronous master. >The Amiga seems to have taken maximum benefit from sync operation to the >68000, and must place the most stringent requirements of any target on the >timing of an accelerator, even an accelerated 68000. Well, the interleaved cycle of the Amiga system chips is acting very much as a synchronous-timing 68000 device. While, as a slave, it seems to be making the 68000 jump through hoops, the actual timing is pretty lax by today's TTL standards. All the A26x0 68000 interface logic, for example, is LS logic and mainly 20-25ns PALs. The A2630 memory logic, on the other hand, is all F series logic and at least one 10ns PAL (on the edge for a 1988 design). >:: [ 68040 to 68030 interface discussed] >:: - dynamic bus sizing for 8-, 16-, and 32-bit ports >Actually, this is more than just a matter of multiplexing the bytes >around. The 68040 expects to run just one cycle for any fetch. The >68030 will run up to four bus cycles to complete a fetch. The bus >interface must detect cases when the port size was smaller than the >access size, and execute multiple bus cycles to assemble the data. Again, the A3000 doesn't require the full and complete conversion logic you might invision. True byte wide ports are only for I/O, uncached, and only accessed with byte wide instructions, for instance (OK, they were a bad idea in the first place, and not mine). In any case, once you have a cycle generator, it's absolutely no big deal to make it handle a couple of cycles. An optimal A3000 68040 card will probably have a gate array on it anyway, to deal with the 68040 to 68030 conversion correctly. Because the 68040 is so dependent on burst cycles, you want to take advantage of 68030 bus burst reads and writes. If you provide a four word bidirectional FIFO, you can have full speed 68030 bursts with write buffering and let the 68040 run asynchronously to the 68030 bus. Not that anyone has done it this way to date, but it is the best way to do it, and such a gate array won't run more than $10-$15, while even a few bidirectional latching buffers can run over $20. Though such a gate array is hardly required; I have seen several reasonably simple 68040 card designs for the A3000 to date. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.