pierre@pro-graphics.cts.com (Peter Altamore) (01/21/90)
I would like to address this letter to any and all Commodore technical staff
whomight be listening. Recently I've been considering the purchase of the
2500/30 package offered by CBM through the education program. However I have
certian reservations about the performance and possible future expansion of
such a system. It's my understanding that the A2630 comes with 2 megs of RAM
soldered onboard and has room to solder 2 additional megs, to bring it up to 4
megs of 32-bit RAM. It is also my understanding that the A2630 is an
asynchronous design that'll allow for the addition of an 030 that's faster
than the 25MHz one currently implemented. I have 2 problems with this: [1]
How the heck am I supposed to upgrade beyond 4 megs of 32-bit RAM? [2] How can
I upgrade to a faster processor if adding faster RAM means soldering and
de-soldering sensitive and expensive RAM chips? I need socketed RAM! or at
least SIMMs. The first problem is the most pressing, I DO anticipate having
an 8 meg 030'ed machine by summertime and it seems like the A2630 won't be the
ticket. I'm also having problems finding someone to reconcile some other RAM
considerations I have. Is it possible to have an AT Bridgeboard AND and 030
card with 8 megs? I realize that the AT Bridge takes up considerable 68000
address space. Will peripherals that are on the 68000 bus (in the slots)
affect the amount of RAM that the 030 can use? What will happen if I have 4
megs of 16-bit RAM AND 8 megs of 32-bit RAM? What this all boils down to is
that the GVP 030 card seems like a much more logical and sound design (please
disspell this if it isn't true!
). I've also 'heard' that the A2630 has wait states! Please tell me this
isn't true! I want the price that the Commodore solution provides, but it
seems like the product design (A2630) has been *seriously* compromised for one
reason or another. Thank you for your time.
_______________________________________________________________________________
ProLine: pro-generic!pro-graphics!loginID | Pro-Graphics 24hrs
UUCP: crash!pnet01!pro-generic!pro-graphics!loginID | 201/469-0049 3/12/24
ARPA/DDN: crash!pnet01!pro-generic!pro-graphics!loginID@nosc.mil
_______________________________________________________________________________daveh@cbmvax.commodore.com (Dave Haynie) (01/24/90)
in article <1251@crash.cts.com>, pierre@pro-graphics.cts.com (Peter Altamore) says: > It's my understanding that the A2630 comes with 2 megs of RAM soldered > onboard and has room to solder 2 additional megs, to bring it up to 4 > megs of 32-bit RAM. That's true. However, there is a daughterboard connector on the A2630 which will logically support the addressing of 64 megabytes of 32 bit memory. Or a cache. Commodore hasn't announced any A2630 daughterboards yet, and you'd have to be pretty clever to stuff 64 megabytes on a board that size using current DRAM technology, but the upgrade path is there. > It is also my understanding that the A2630 is an asynchronous design that'll > allow for the addition of an 030 that's faster than the 25MHz one currently > implemented. I have 2 problems with this: [2] How can I upgrade to a faster > processor if adding faster RAM means soldering and de-soldering sensitive and > expensive RAM chips? An "asynchronous" design, as in reference to an Amiga CPU slot board, is simply a claim that the CPU speed is not not coupled to the speed of the motherboard or video clocks. That's all it's saying. It does not imply that you can drop in a faster CPU and go faster. And there are many issues related to going faster that have nothing to do with RAM speed. You can't expect to drop in a faster CPU, memory, and crystal into a arbitrary asynchronous board any more than you can drop a faster 68000, memory, and crystal into the A2000 itself and go faster. On the other hand, it's possible to design a system where the memory and CPU speeds are basically decoupled. > The first problem is the most pressing, I DO anticipate having an 8 meg 030'ed > machine by summertime and it seems like the A2630 won't be the ticket. No one's forcing you to buy the A2630 or any other 68030 card. Obviously, if the A2630 were the ultimate answer every Amiga owner was looking for in the accelerator market, a few other companies would be in trouble. Some others may claim to be upgradable to a faster clock speed, but don't expect any current design to just up and run when you drop in that 50MHz CPU and crystal and some 50ns DRAM. There's just much more to systems design than plug and chug. No matter who you buy from, if expect to upgrade to a specific CPU speed, GET IT IN WRITING. From a reputable company, too. > I'm also having problems finding someone to reconcile some other RAM > considerations I have. Is it possible to have an AT Bridgeboard AND and 030 > card with 8 megs? I realize that the AT Bridge takes up considerable 68000 > address space. Will peripherals that are on the 68000 bus (in the slots) > affect the amount of RAM that the 030 can use? What will happen if I have 4 > megs of 16-bit RAM AND 8 megs of 32-bit RAM? All of this depends on where things are mapped. Autoconfig space is by definition an 8 megabyte chunk of memory from $00200000-$009fffff. All 16 bit cards sit there (except for very small I/O typs cards, which have another small space they can live in). All autoconfig cards live there too. If your 32 bit memory is autoconfiguring, it takes away some of the space used for 16 bit cards. A bridge card takes up 2 megs. If you have 8 megs of autoconfig memory on an 68030 card, you can't have the bridge card at the same time. It's up to the designers if that 32 bit memory can be mapped elsewhere and AddMemed. However, having ONLY AddMemed 32 bit memory will slow down your DMA performance with hard disks. These are what we call trade-offs. > What this all boils down to is that the GVP 030 card seems like a much > more logical and sound design (please disspell this if it isn't true! ). Translation: The GVP card seems to meet your needs better than the A2630. It very well may. Commodore had certain requirements for the A2630. First was that it have on-board 32 bit memory, since a 32 bit CPU is crippled without it. You could certainly build a bigger and possibly faster memory system, given the space of a whole card, than you can in the corner of an already-full Coprocessor card. Commodore also required a 2 megabyte option, which does limit a number of the "tricks" you can play with the 68030 to make things go a little faster. GVP obviously had different requirements and goals. Neither of these are wrong. > I've also 'heard' that the A2630 has wait states! Please tell me this > isn't true! All 25MHz 68030 systems using DRAM have wait states. To run without wait states you need a memory _cycle_ time of 80ns. To put this in prespective, an 80ns DRAM has a _cycle_ time of around 150ns, a 100ns DRAM have a cycle time of around 190ns. Anyone who claims they're running 0 wait states is using major trickery or lying to you; probably both. There are some standard techniques for getting a little more performance out of your memory; they all require larger memory banks (4 meg a chunk) or more logic, probably both. The A2630 goes as fast to 100ns memory as a 25MHz 68030 can without resorting to any real cleverness that would violate the design constraints (eg, the design fits on the A2630 card and can support both 2 and 4 meg configurations). > I want the price that the Commodore solution provides, but it seems like > the product design (A2630) has been *seriously* compromised for one > reason or another. Thank you for your time. I don't know what you heard, but you're confused. There are some tradeoffs in the A2630 design, just like any other design in existence. You may or may not agree with the direction it went in; I may not either -- Commodore made the choices. I just designed it for them. But there are no serious comprimises. > ProLine: pro-generic!pro-graphics!loginID | Pro-Graphics 24hrs -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
swarren@convex.com (Steve Warren) (01/24/90)
About the 64M daughter card, now that the 4Mbit DRAM chips are in
production we can get 4Mbytes on an 8-chip simm, which means, let's
see... ...16 simms for 64M, yes that does seem a little excessive
for a daughter-card ;^).
It should be possible to build a 0-wait-state memory board for the
'030 now, though, since Hitachi has just come out with these speedy
little 35ns 1Mbit DRAMs. Unfortunately they are selling for >$100
each right now :(. (They just started sampling, I understand - I
hope to get some literature on these chips soon). They may not have
improved the overall cycle time that much. I understand the access
time improvement was achieved primarilly by de-muxing the address
lines. None of the press releases give precharge or cycle times.
--
--Steve
-------------------------------------------------------------------------
{uunet,sun}!convex!swarren; swarren@convex.COMsteve@digibd (Steve Wahl) (01/24/90)
It was mentioned that there were trade-offs made so that the 2630 card can work in a 2Meg 32bit memory configuration. Does this mean it can't do Burst-mode cache fill? (This is a special mode on the '030 that, if conditions are right, gets things from memory faster). If it can't, does that mean never or does it mean you have to go to 4 Megs to get Burst-fill? If someone answers this, maybe you can provide a better description of the '030 burst mode for those unfamiliar with it. I know what it means, but I can't seem to come up with the words to discribe it right now... --> Steve -- Steve Wahl uunet!digibd!steve DigiBoard Inc. St. Louis Park, MN (612) 922-8055
keithh@atreus.uucp (Keith Hanlan) (02/01/90)
I think this one disappeared somewhere... daveh@cbmvax.commodore.com (Dave Haynie) writes: >pierre@pro-graphics.cts.com (Peter Altamore) says: >>[...] >...there is a daughterboard connector on the A2630 which >will logically support the addressing of 64 megabytes of 32 bit memory. ^^^^^^^^^^^^ Yeeeeeeeeeee Haaaah! :-) >> Will peripherals that are on the 68000 bus (in the slots) >> affect the amount of RAM that the 030 can use? What will happen if I have 4 >> megs of 16-bit RAM AND 8 megs of 32-bit RAM? > >All of this depends on where things are mapped. >cards sit there (except for very small I/O typs cards, which have another >small space they can live in). All autoconfig cards live there too. If your >32 bit memory is autoconfiguring, it takes away some of the space used for >16 bit cards. A bridge card takes up 2 megs. If you have 8 megs of autoconfig >memory on an 68030 card, you can't have the bridge card at the same time. >It's up to the designers if that 32 bit memory can be mapped elsewhere and >AddMemed. However, having ONLY AddMemed 32 bit memory will slow down your >DMA performance with hard disks. These are what we call trade-offs. Dave, I'm a little on the dense (in-experienced) side. Could you elaborate this last bit for me please. o What is the difference between AddMemed memory and Autoconfig memory to a DMA device? o Is it possible to autoconfig only, say, 6MB of the 32bit RAM and let an additional device, such as a Bridgeboard or my 2058/2, use the remaining 2MB of autoconfig space? Is this basically a question of whether or not the manufacturer provides enough flexibility through jumpers? o Is there a way to conditional autoconfig different cards depending on whether or not the machine is booted in 68000 mode? That is, say I have the following: A2630/8MB (eventually) and A2058/4MB: 1. In default 68030 mode, I want all the 32bit RAM to be autoconfig and the 16bit RAM to be AddMemed since you imply that the autoconfig RAM is faster for DMA. (right?) 2. In 68000 mode, I want the 16bit RAM to be autoconfig since the 32bit RAM is unusable. (right?) 3. If I can't have (1), can I autoconfig the 4MB of 16bit and only 4MB of the 32bit? >...Commodore also required a 2 megabyte option, >which does limit a number of the "tricks" you can play with the 68030 to >make things go a little faster. Can you suggest why they imposed this constraint? I concede that it certainly makes for a less expensive, (and thus more marketable?), board. Is that basically all there is too it or did they insist on permitting the completely autoconfig 6MB + 2MB Bridgeboard. Lovely machine eh guys? geez I'm in a good mood today. Love you all... Keith Hanlan Bell-Northern Research, Ottawa, Canada 613-765-4645 uunet!bnrgate!atreus!keithh or (via bitnet) keithh@bnr.ca "You're making me feel wierd Adrian" Jack Carney to Adrian LeDuc, Apartment Zero
daveh@cbmvax.commodore.com (Dave Haynie) (02/16/90)
In article <1287@bmers58.UUCP> keithh@atreus.UUCP (Keith Hanlan) writes: >I think this one disappeared somewhere... >>All of this depends on where things are mapped. > Dave, I'm a little on the dense (in-experienced) side. Could you > elaborate this last bit for me please. > o What is the difference between AddMemed memory and > Autoconfig memory to a DMA device? Autoconfig memory is memory that supports the Amiga AUTOCONFIG(TM) protocols and is automatically recognized and added by the Amiga's expansion.library. AddMemed memory is manually added at a hardwared memory location, usually a line somewhere in your Startup-Sequence if you have such memory. By the rules, any device in the $00200000-$009FFFFF range MUST be autoconfiguring, and any device that doesn't autoconfigure MUST be located outside of that range. That puts extra 32 bit memory outside of the 68000's address space, since there isn't any other space available to add-ons in the 68000 address space. So if you follow the rules, on A2500/xx and below, all autoconfigured memory will be accessible by DMA device, no AddMemed memory will be. > o Is it possible to autoconfig only, say, 6MB of the 32bit RAM and > let an additional device, such as a Bridgeboard or my 2058/2, > use the remaining 2MB of autoconfig space? Is this basically > a question of whether or not the manufacturer provides enough > flexibility through jumpers? Autoconfiguration units come in power-of-two sizes. If a 68030 board allowed configuration of 4, 6, and 8 megs of memory, it would have to actually offer two separate configuration units, since the 6 meg size is actually composed of a 4 meg unit and a 2 meg unit. ASDG's standard 16 bit Zorro II memory board did this, but most don't. The A2630 only have 4 megs of memory in 68000 space, which may actually be set by jumper as either 2 or 4 megs. > o Is there a way to conditional autoconfig different cards > depending on whether or not the machine is booted in 68000 mode? > That is, say I have the following: A2630/8MB (eventually) and > A2058/4MB: > 1. In default 68030 mode, I want all the 32bit RAM to be autoconfig > and the 16bit RAM to be AddMemed since you imply that the > autoconfig RAM is faster for DMA. (right?) Well, things work out the way you want them in 68030 mode. You MUST autoconfigure any autoconfiguration unit, you can't simply addmem them. And it's the OS that does it; at least without going to a great deal of trouble, you have little choice how cards get configured. But with an A2630 system or pretty much anything else that lives in the CPU slot, any autoconfiguration unit there will show up before anything in the Zorro II bus. So your 32 bit memory will appear before any 16 bit memory available. The only real question would be if you had a mixture of 16 and 32 bit resources, and wanted a special setup in 68000 mode. For instance, you have 4 megs of 32 bit memory, an AT bridgecard, and 4 megs of 16 bit memory. If the 4 megs of 16 bit memory is ahead of the bridge card on the bus, it'll get configured first and the bridge card, no longer having any room, will be told to shut up. So you'd have to locate the Bridge Card before the extra 16 bit memory for things to work out just great. The 1.4 OS will be more robust in autoconfig slot allocation, but I don't know if it has any plans to support this rather weird type of situation. > 3. If I can't have (1), can I autoconfig the 4MB of 16bit and only > 4MB of the 32bit? Well, on an A2630, only the 4 megs of on-board memory will autoconfigure; any daughtercard memory will have to be added in via AddMem type utilities. >>...Commodore also required a 2 megabyte option, >>which does limit a number of the "tricks" you can play with the 68030 to >>make things go a little faster. > Can you suggest why they imposed this constraint? I'm certain it was the cost. While memory prices have fallen dramatically over the past year, you have to realize that the A2630 was basically done a year ago this month. At the time I was designing it, 2 megs of DRAM was over 1/2 the cost of the card. Given infinite time I probably could have done something more clever, but the A3000 was already biting at out heels, so the A2630 was done as-is for several reasons. I still today think it's a good design, it just might have been a tad faster had constraints been different. >Keith Hanlan -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
swarren@convex.com (Steve Warren) (02/17/90)
In article <9696@cbmvax.commodore.com> daveh@cbmvax.cbm.commodore.com (Dave Haynie) writes: >In article <1287@bmers58.UUCP> keithh@atreus.UUCP (Keith Hanlan) writes: [...] >> o What is the difference between AddMemed memory and >> Autoconfig memory to a DMA device? > >Autoconfig memory is memory that supports the Amiga AUTOCONFIG(TM) protocols >and is automatically recognized and added by the Amiga's expansion.library. >AddMemed memory is manually added at a hardwared memory location, usually a >line somewhere in your Startup-Sequence if you have such memory. By the >rules, any device in the $00200000-$009FFFFF range MUST be autoconfiguring, >and any device that doesn't autoconfigure MUST be located outside of that >range. That puts extra 32 bit memory outside of the 68000's address space, >since there isn't any other space available to add-ons in the 68000 address >space. So if you follow the rules, on A2500/xx and below, all autoconfigured >memory will be accessible by DMA device, no AddMemed memory will be. [...] Dave, Is this just because the controller can't get to the 'extended' address bus bits for 32-bit processors? If so then the distinction would appear to be location in the address mapping, not addmemed/non-addmemed (oh yes, you did mention that this applies for systems that follow the rules. Is it illegal to have non-autoconfig devices within the 68000 address space?). I am not making light of the "rules", I am just trying to make sure I properly understand how they apply. I assume that DMA would be possible via an extended bus connection? Perhaps by running an address-cable with the extra bits directly to the card in question? That would allow DMA to an AddMemed memory card. Would that be a problem? BTW, I would have redirected this to comp.sys.amiga.hardware, but this group still hasn't shown up at our gateway, and then I wouldn't be able to read the response. Who invoked the new group, and why are some of us still not getting it? If it was done right it should show up automatically, right? -- --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
jlg3@uafhcx.uucp (Jennifer L. Garner) (02/17/90)
Dave: I'm sure you've been asked this a zillion times, but maybe you could be patient with a hardware neophyte. Why does the jump from a straight 2000 to a 2500 (2620 or 2630) represent such an incredible increase in the disk operating speed? I guess I always assumed that the DMA speeds were constant regardless of processor speed (fixed bus speed). I am working on an application that requires the absolute maximum speed on reads and writes, regardless of hardware configuration. What methodologies, particularly in software, can be used within CBM guidelines to guarantee full advantage of DMA disk transfers? We are working on real-time transfer of stereo audio to HD. This will require ~100k/sec transfer rate @ 16 bit words (48k per channel). Is this reasonable to expect from an unexpanded system, or should we demand the use of a speed up card? Don Kennedy Vision Quest
daveh@cbmvax.commodore.com (Dave Haynie) (02/20/90)
In article <3716@uafhp.uark.edu> jlg3@uafhcx.uucp (Jennifer L. Garner) writes: >Dave: >I'm sure you've been asked this a zillion times, but maybe you could be >patient with a hardware neophyte. Why does the jump from a straight 2000 >to a 2500 (2620 or 2630) represent such an incredible increase in the disk >operating speed? I guess I always assumed that the DMA speeds were constant >regardless of processor speed (fixed bus speed). The actual DMA from controller to memory is going, ideally, to be the same speed between all A2000s (or, for that matter, any Zorro II bus to bus transfers). There are certainly several differences between an A2000 and an A2500; for DMA I suspect the most notable might be that you have chip memory in the system. While it's not well known, a DMA on an A2000 into Chip or $00C00000 memory takes an extra wait state. This is due to the extremely tight timings on the Fat Agnus/Gary architecture; it was impossible to guarantee the specified Zorro II bus timing into Chip memory with this design, though it came pretty close (A2000s have a jumper, J900, which can be removed to eliminate this wait, but some DMA devices certainly won't work with J900 removed). To further aggrevate the situation, the custom chips always run 2 clock cycles, so you really can't add just one wait to state to a chip RAM DMA; the next access will require resynchronization, and things just aren't really happy. All A2500s come with real Fast memory, which _almost_ never adds a wait state during DMA (there's an occasional refresh cycle that could collide with DMA, but those are pretty quick). So DMA is going at full possible speed on any A2500 or A2000 with Fast memory, but it's a bit slower on a plain A2000. Next you can start considering the actual A2500 differences. Any software driven aspect of A2500 operation is going to be faster, and any DMA transfer isn't purely hardware driven. The actual transfer is of course based on the best match between bus speed and disk speed, but there are other factors. Interrupt response time is faster on the 2500, even though the actual interrupt vectors are in chip memory. The device driver code itself _can_ be loaded into 32 bit memory (SetCPU with a CardROM entry can do this for 2090A and possibly 2091 controllers, though I never worked it out for a 2091 controller). Of course, the program that's running, the Fast Filesystem, the data that's actually DMAed, etc. all wind up in 32 bit wide memory. And the thing that you think is completely disk bound may show up to be more CPU bound than you suspected. This means, in reality, that it may actually be much close to disk bound when the CPU is going so much faster -- things like compilers show much more of this behavior on 2500 systems. >We are working on real-time transfer of stereo audio to HD. This will >require ~100k/sec transfer rate @ 16 bit words (48k per channel). Is this >reasonable to expect from an unexpanded system, or should we demand the use >of a speed up card? That shouldn't be a problem for a basic system, within limits. The actual bus bandwidth available is roughly 3.5 MB/s on a plain A2000 transferring to Fast memory. You won't find any SCSI device that keeps up with that until you start to play with synchronous SCSI. To prevent undue slowing of a DMA device, you would have to be careful about too much chip bus activity in critical areas, since a busy chip bus can cause a transfer lag; the DMA device may have to wait for the end of a scan line before it can master the bus, if the CPU is stuck waiting on Chip bus access. I guess the bottom line will really have to be the details of the rest of the application. If you need DMA into Chip memory, things will be slower. If you have lots of other CPU or interrupt activity, there may be some management necessary to make sure you get disk stuff done when the system isn't otherwise fully loaded. But my guess is that you'd have plenty of bandwidth left over on a basic system if things are set up carefully. On '030 systems, we've even had a few jokers around here doing simple, smooth, real-time animations directly from disk. > Don Kennedy > Vision Quest -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
daveh@cbmvax.commodore.com (Dave Haynie) (02/20/90)
In article <-1773786386@convex.convex.com> swarren@convex.com (Steve Warren) writes: >In article <9696@cbmvax.commodore.com> daveh@cbmvax.cbm.commodore.com (Dave Haynie) writes: >>By the rules, any device in the $00200000-$009FFFFF range MUST be autoconfiguring, >>and any device that doesn't autoconfigure MUST be located outside of that >>range. That puts extra 32 bit memory outside of the 68000's address space, >>since there isn't any other space available to add-ons in the 68000 address >>space. So if you follow the rules, on A2500/xx and below, all autoconfigured >>memory will be accessible by DMA device, no AddMemed memory will be. > [...] >Is this just because the controller can't get to the 'extended' address >bus bits for 32-bit processors? Yes, the reason the DMA devices can't DMA outside of the 68000 address space is their inherent addressing limitation. This is based on the Zorro II bus specification, which only tells you what to do with 24 bits of addressing information. >If so then the distinction would appear to be location in the address mapping, >not addmemed/non-addmemed (oh yes, you did mention that this applies for systems >that follow the rules. Is it illegal to have non-autoconfig devices within the >68000 address space?). Well, it is based on address mapping. The rules are that it's illegal to add a memory mapped expansion device that's not autoconfiguring, period. However, that's a bit restrictive; what's closer to the truth is that it's illegal to plug a device into the Zorro II bus that's not autoconfiguring, and it's also illegal to add a device through any other means that puts itself into space reserved by Commodore as motherboard space. The first restriction is a logical outgrowth of being a Zorro II board -- it's impossible to follow the Zorro II spec and still work without also being an autoconfiguring board -- this is enforced in hardware. This last restriction, of course, means that everyone who follows it will be happy in the future with new memory maps, and those that don't might have just hard-mapped their favorite toy over the space that Commodore was planning for some new thing on the next new motherboard. There is a bit of middle ground, that of the 32 bit address space. CBM wasn't the first to deliver a full 32 bit system, or desire more than an extra 8 megs or so of memory. There aren't alot of these systems running around with gobs of memory, but they do exist, and of course they had to put that memory somewhere. At the time, there was no great master plan through the 90's of where things go, so it has been pretty much up to the individual 32 bit card where memory goes. If it's possible for such memory to act as if it were a valid autoconfig device, I think it belongs in autoconfig space, at least up to the limits of memory. That's what we did on the A2620 and A2630. Once that space is out, autoconfig is impossible; there's no support in Zorro II for more than 24 bit addressing, in software or hardware. But some folks still want the memory. My guess at the time was "how about starting at the next 16 meg chunk and working your way up". But I see things like these extra memory cards, such as an A2630 daughterboard, very system-specific. You're not going to add 10 daughterboards, or 5, or even 2 to an A2630 -- you'll add one at most. So the location of the memory is not a serious problem, and hardwiring it to link it in with AddMem is the best solution for this kind of thing. >I am not making light of the "rules", I am just trying to make sure I >properly understand how they apply. I assume that DMA would be possible >via an extended bus connection? Perhaps by running an address-cable >with the extra bits directly to the card in question? That would allow >DMA to an AddMemed memory card. Would that be a problem? Given a new system, new DMA cards, new memory cards, etc. you could expect things to work pretty much like they do now -- everything autoconfigs, all support DMA, only in 32 instead of 24 bits. But there's no good way to retrofit this. If everyone back in 1985 had decided on some address extension spec, maybe now you'd have an extra cable or something, but nothing can be done at this point, and in general, that probably would not have been the proper solution. Either a card respects 32 bit addressing or it doesn't, there's no middle ground. Today's DMA cards very likely don't have the extra 8 bits available anywhere on them, probably not even at the register level. If you started running 32 bit cycles without more cleverness, you'd have all your 24 bit stuff responding to the 24 bit portion of a 32 bit address that in fact was looking for something outside of the 24 bit space. Believe me, there are solutions that are upward compatible to this kind of problem, but nothing that'll give you 32 bit DMA with today's 24 bit cards. >BTW, I would have redirected this to comp.sys.amiga.hardware, but this >group still hasn't shown up at our gateway, and then I wouldn't be able >to read the response. Who invoked the new group, and why are some of >us still not getting it? If it was done right it should show up >automatically, right? I think that was Ben Blish and the gang at BlackBelt Systems. I dunno this net stuff, but it all just magically appeared at my electronic front door one day. You may have to consult with the local usenet gurus on your end to see if they maybe need to request the new group(?). >--Steve -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
jeh@elmgate.UUCP (Ed Hanway) (02/23/90)
Dave Haynie writes: >There aren't alot of these systems running around >with gobs of memory, but they do exist, and of course they had to put that >memory somewhere. At the time, there was no great master plan through the >90's of where things go, so it has been pretty much up to the individual >32 bit card where memory goes. If it's possible for such memory to act as >if it were a valid autoconfig device, I think it belongs in autoconfig >space, at least up to the limits of memory. That's what we did on the >A2620 and A2630. Once that space is out, autoconfig is impossible; there's >no support in Zorro II for more than 24 bit addressing, in software or >hardware. But some folks still want the memory. My guess at the time was >"how about starting at the next 16 meg chunk and working your way up". But >I see things like these extra memory cards, such as an A2630 daughterboard, >very system-specific. You're not going to add 10 daughterboards, or 5, or >even 2 to an A2630 -- you'll add one at most. So the location of the >memory is not a serious problem, and hardwiring it to link it in with AddMem >is the best solution for this kind of thing. I have a fully populated 8 meg card and a 4 meg A2630. Is there anything I can do to the A2630 to turn its autoconfig memory into addmem memory? As it is now, the A2630 autoconfigs first, then half of the RAM card autoconfigs, then I run out of autoconfig space. Obviously the RAM card can't be remapped to a 32-bit address, but are there any possibilities for the A2630? I can live with addmem, and I can live with a solution that I'll have to undo down the road when I slap a 64 meg daghterboard on the A2630 :-), but I cringe whenever I think of that wasted 4 megs just sitting there dropping in value every day. Ed Hanway Eastman Kodak Company ...!rochester!kodak!elmgate!jeh #include <std_disclaimer.h> jeh@elmgate.UUCP jeh@elmgate.sisd.kodak.com
pochron@cat6.cs.wisc.edu (David Pochron) (02/24/90)
Speaking of the A2630 card...what's going on here in the March issue of
AmigaWorld where they benchmarked several '030 boards. Here's what they
achieved using Turbo Silver:
A2630 GVP25 GVP28 H2800 GVP33
--------------------------------------------------
61:04 36:38 33:52 39:46 31:26
^^
What in the world is going on here?!? All the other boards finished
rendering in roughly half the time that the A2630 board took. The weird
thing is, all the other floating point tests gave similar results with respect
to all boards tested except for this test. Is there something about the A2630
that makes it slower with TSilver, or did AmigaWorld just screw up somewhere?
Has anyone done their own benchmarks w/ TSilver using the GVP25 and A2630
cards? Thanks!
--
-- David M. Pochron | "Life's a blit,
| and then you VBI."
pochron@garfield.cs.wisc.edu |watters@penguin.cis.ohio-state.edu (david r watters) (02/24/90)
In article <4358@daffy.cs.wisc.edu> pochron@cat6.cs.wisc.edu (David Pochron) writes: > >Speaking of the A2630 card...what's going on here in the March issue of >AmigaWorld where they benchmarked several '030 boards. Here's what they >achieved using Turbo Silver: > > A2630 GVP25 GVP28 H2800 GVP33 > -------------------------------------------------- > 61:04 36:38 33:52 39:46 31:26 > ^^ > What in the world is going on here?!? All the other boards finished >rendering in roughly half the time that the A2630 board took. The weird >thing is, all the other floating point tests gave similar results with respect >to all boards tested except for this test. Is there something about the A2630 >that makes it slower with TSilver, or did AmigaWorld just screw up somewhere? I think I know what was going on here! If I am right, this infuriates me, as it is the responsibilty of a powerfull magazine to present acurate data. The Boards were listed as being stock, so there is an overwhelming chance that the A2630 was a 2meg version. When you are using TurboSilver and have any decent sized data, that first 2megs runs out very quickly. This means the rendering was now being done in 16bit memory. Since 32bit memory is twice as wide, it makes sense that the render time would be twice as slow, which is what looks like happened. I have found this to happen with the A2620/2meg, and I think this magazine needs to be immediately contacted and FORCED to revise their findings! I helped out in the GVP booth at the July AmiExpo, and they were running an A3001 against an A2620 and the GVP was twice as fast with a Turbo Silver render, and we know that the A2630 is twice as fast as an A2620. During the demonstration, I had to make sure that the data stayed in the 32bit memory region on the A2620, as the GVP had 4megs on it. watters@cis.ohio-state.edu