A2630 questions
Peter Altamore
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!log...@nosc.mil
_______________________________________________________________________________
Dave Haynie
> 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
Steve Warren
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; swa...@convex.COM
Steve Wahl
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
Jonathan Hue
In article <1990Jan24.061335.29369@digibd> st...@digibd.UUCP (Steve Wahl) writes:
>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 just a guess. I really don't know anything about the hardware in
question.
The easiest way I can think of to support burst mode access with the '030
is to use nibble mode DRAM. If the 2630 supports 2M of memory, that must
mean that the memory is made of 256Kx4 DRAMs, as 32 1Mx1 DRAMs adds up to 4M.
I'm not sure, but I don't think 256Kx4 DRAMs are available in nibble-mode
(or maybe they're just rare). If this is the case, this would explain why
the 2M minimum memory requirement prevented the support of burst mode. With
the price of memory where it is now, maybe this wasn't a good decision by
Commodore.
Another possibility might be tricks you can play by with interleaving
4 1-megabyte banks of memory, but can't do with 2.
Am I even close, Dave?
-Jonathan
Keith Hanlan
>pie...@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?
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/2MB:
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.
>> 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.
>Anyone who claims they're running 0 wait states is
>using major trickery or lying to you; probably both.
I'll spell it out a little clearer than Dave can in good corporate
etiquette: GVP advertises an *AVERAGE* of 0 wait states. This is
possible by using page-mode RAM and a addressing scheme specific to
the 68030/40 whereby 1 byte (word?) is received in 3 clock cycles and
then 3 bytes (words?) are received in the next clock cycle.
This compares with 2 clock cycles/byte(word?). HOWEVER,
o This only works for convenient fetches - I really don't know how
often they occur.
o It requires the more expensive page-mode ram.
o Limits the banks to 4MB per reducing flexibility. (As Dave pointed
out)
o The test results I got showed only a 5% speed-up. In Canada you
pay an extra $1000 for that 5%. In another perspective, (see my
article on the comparison of the 3001/2630/2620), the speed up
is from 7.8% of stock speed to 7.4% of stock speed. Personally
I wouldn't notice...
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) kei...@bnr.ca
Dave Haynie
> 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?
Not from on-board 32 bit memory, though it could, of course, support this
feature on a daughterboard memory system.
> If it can't, does that mean never or does it mean you have to go to
> 4 Megs to get Burst-fill?
The on-board memory system never does support burst.
> If someone answers this, maybe you can provide a better description of
> the '030 burst mode for those unfamiliar with it.
The 68030 has two basic memory fetch modes; the synchronous mode, which
takes 2 clock cycles to fetch one 32 bit word, and the asynchronous mode
(like the 68020 memory cycle), which takes 3 clock cycles to fetch one
32 bit word. The actual 68030 CPU can always use longwords at the rate
of one per every 2 clock cycles as long as it has work to do. When fetching
from internal caches, it can sometime use one longword of data and one
of instruction in the same basic clock cycle, so it's obviously a good
idea to keep both caches full most of the time.
Burst mode is a special fetching mechanism that lets the cache prefetch
an entire cache line. When bursting is enabled, the 68030 will assert it's
cache burst requirest line, CBREQ*, early in a memory cycle. If the
responding memory system can support burst, it'll assert the cache burst
acknowldege line, CBACK*, during a normal synchronous memory cycle. Once
the normal synchronous cycle is complete, the 68030 will permit the next
3 longwords MOD 4 to be loaded at one longword per clock. The 68030 is
only necessarily going to use the first longword, fetched during the
standard synchronous cycle; the others are placed in cache and will
hopefully be used, but may be discarded, depending on program activity.
The other piece of this interaction is the reality of memory systems. To
keep up with a 25MHz 68030's synchronous mode, without adding wait states,
you'd need a memory system with a cycle time of 80ns and an extremely fast
access time. As a comparison, 100ns DRAM has a 100ns access time and a
190ns cycle time, 80ns DRAM has an 80ns access time and a 150ns cycle time.
You also need to add additional time for logic that'll actually drive this
memory. So taking 100ns DRAM as a model, the fastest cycle you can run
with the 25MHz 68030 is 200ns, which amounts to 5 clocks, rather than the
possible 2 or 3 clocks depending on whether the memory follows synch or
asynch rules. However, certain memory types have built-in a special mode
which works very nicely with burst mode on the 68030. The so-called
nybble-mode DRAM, for example, requires a standard memory cycle, 5 clocks
for 100ns parts, for the first bit out of it (standard nybble-mode
memories come in 1meg x 1 packages). However, you may be able to get the
next 3 bits in as little as 25ns each. Hook this up right to a 68030
and you end up with a 4 meg bank of memory where the first access takes
5 clocks, but each burst access takes only one additional clock. Adding
that up, you get 4 longwords in 8 clocks. Zero wait-state synchronous
memory without burst would also get 4 longwords in 8 clocks. The
synchronous memory would be faster, since it would never fetch anything
that wasn't used, but based on enough difference between the standard
and the burst fetch timings, a burst fetch can on the average be a
noticable speed improvement.
I mentioned nybble-mode memory above as being the easiest to use with
68030 burst mode, since it's nybble cycle is almost identical to the
68030 burst cycle. Unfortunately, that requires 4 megs per bank of
memory, which is why you'll find burst memory systems like the GVP
daughterboard or the NeXT computer always grow in 4 meg chunks. It's
also possible to achieve burst mode via other methods. An intelligent
controller could use page or static-column memory to support burst
mode, at the expense of extra logic. It would also be possible to
build some sort of interleaved memory system; for example, a system
that actually read 128 bits at a time, but only gated 32 onto the
68030's bus at a time. This also has the unfortunate aspect of needing
more buffers and external logic, but with enough room on the memory
board, could be a viable alternative to nybble memory.
> Steve Wahl uunet!digibd!steve
Dave Haynie
> If the 2630 supports 2M of memory, that must mean that the memory is made
> of 256Kx4 DRAMs, as 32 1Mx1 DRAMs adds up to 4M.
Yup, that's exactly the case.
> With the price of memory where it is now, maybe this wasn't a good decision by
> Commodore.
Memory is back down these day, maybe they could have done with a 4-meg only
version at this point. However, the design was about 95% finished around
this time last year, and we were already in about the 3rd revision of the
board. If anyone recalls what memory went for last year at this time, they
can certainly understand why Commodore considered the 2 meg version imprortant.
> Another possibility might be tricks you can play by with interleaving
> 4 1-megabyte banks of memory, but can't do with 2.
I played around with that somewhat, but ran into a unavoidable tradeoff.
The memories themselves weren't fast enough on and off the bus to reliably
support such a banking scheme, and there wasn't enough room to add in
fast TTL buffers that could do the job. Practically any scheme would
fit nicely on an 8 meg daughterboard...
> Am I even close, Dave?
Right on, actually.
> -Jonathan
Keith Hanlan
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) kei...@bnr.ca
"You're making me feel wierd Adrian" Jack Carney to Adrian LeDuc, Apartment Zero
Checkpoint Technologies
> [a whole lotta other stuff, and:]
>Autoconfig memory is memory that supports the Amiga AUTOCONFIG(TM) protocols
>and is automatically recognized and added by the Amiga's expansion.library.
Well, I just tossed this in because I thought of it when you
said this... The screen of one of the new Tandy laptop computers, in
the middle of the screen, there's a box labelled "AUTOCONFIG". This
computer is running DeskMate (TM; surely that's a Tandy trademark). The
computer is pictured on the back cover of the 1990 catalog.
So, go get 'em! Sue 'em blind! :-)
Dave Haynie
>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
Jennifer L. Garner
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
Steve Warren
>> 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?
Dave Haynie
>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
>In article <96...@cbmvax.commodore.com> da...@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
Ben M Scott
A-501 slot. Obviously, you'll need some connection to the motherboard (I'd
guess the Gary, since it's close) for the extra address lines. However, I've
been asking hither and yon whether these cards are autoconfig; CAN they be,
is it possible to do this sort of a hack and still be autoconfig, and if so
do you know for sure which boards do this? I only have 3 megs on my 500...
4.5 would be nice(r)...
Thanks for your time and thanks for the Amiga!
. <<<<Infinite K>>>>
Michael van Elst
>I've seen stuff about 1.8 and 2 meg expanders that fit in the Amiga 500's
>A-501 slot. Obviously, you'll need some connection to the motherboard (I'd
>guess the Gary, since it's close) for the extra address lines. However, I've
>been asking hither and yon whether these cards are autoconfig;
That's indeed possible (and done). Those expanders replace the orignal
512k ram expansion. The additional memory is placed in the so called
"ranger" memory space starting at address $c00000 (and of course as
additional CHIP RAM at $080000 if you have a big agnus).
Exec checks up to 1.8 meg, the following addresses are dedicated to
the battery backed clock and the custom chip registers.
Since this is on the chip memory bus its only "slow"-fast memory.
Michael van Elst
uunet!unido!mpirbn!p554mve
Ed Hanway
>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> j...@elmgate.UUCP j...@elmgate.sisd.kodak.com