Forum unknown
· Hardware
Memory Expansion
31 messages in this thread
Scotty, I think there is only one instruction that uses read-mod-write
(TSAX), and its use is discourage by C-A (according to a developers
newsletter) because it messes things up whe nthe DMA wants the bus.
it's TAS. yeah, it's rare. but why limit software with hardware?? why do
you think we got amigas in the first place? and how might a RMW cycle cause
a DMA device to stumble and fall? –Scotty
Probably because the RMW cycle has the 68K on the bus for an undivided 8
clock cycles, instead of the expected (normal) 4 clock cycles. If there is
an interleaving of the Chip DMA cycles and the 68K R/W cycles, then the 68K
may have just taken a memory cycle allocated to someone else. Just guessing.
/frank
it's an asynchronous bus, for <insert favorite deity's name>'s sake! what
business have you EXPECTING a transfer to take a certain amount of time??
get with the program! that's why they give you XRDY (which is DTACK* as far
as external devices are concerned). –Scotty
Like I said, just guessing about the cycles, But based on my understanding of
the Bus scheduling among those Many, Many DMA channels, etc., That may be the
problem. /frank
but all those DMA channels affect only INTERNAL RAM. there should be no
problem with the slave being outside the box. –Scotty
but all those DMA channels affect only INTERNAL RAM. there should be no
problem with the slave being outside the box. –Scotty
Like I said, just guessing about the cycles, But based on my understanding of
the Bus scheduling among those Many, Many DMA channels, etc., That may be the
problem. /frank
it's an asynchronous bus, for <insert favorite deity's name>'s sake! what
business have you EXPECTING a transfer to take a certain amount of time??
get with the program! that's why they give you XRDY (which is DTACK* as far
as external devices are concerned). –Scotty
Probably because the RMW cycle has the 68K on the bus for an undivided 8
clock cycles, instead of the expected (normal) 4 clock cycles. If there is
an interleaving of the Chip DMA cycles and the 68K R/W cycles, then the 68K
may have just taken a memory cycle allocated to someone else. Just guessing.
/frank
Apparently, the fact that a TAS cannot be split, and that the DMA devices
expect to be able to grab the bus at their usual time causes the problem.
This translates into it being very difficult for the DMA chips to tell when a
TAS is being executed. A minor problem indeed. There are other ways. (I never
dreamed there'd be *SO* many ways to do any given thing on this chip)
i don't understand what the big deal is. the dma device asserts BR*, the
68000 gives BG*, and the dma device waits for AS* to go high, and then
asserts BGACK*. at least that's what i understand from all the 68000 books i
have. i really don't see the big deal if the dma device follows the bus
specs. –Scotty
This is the wrong place to reply for this I Think: 1. My story on TAS is: TAS
holds AS low, the only thing that changes is the status of the R/W pin. For
some reason, it is easier to not account for this.. Ah.. heres the Sidekick
note I wrote: so its fragmented… At 12:50 an hour ya want war and peace? I
got this part off somebody at DELPHI whose name I can't remember, which is a
darn shame as he's really bright… TAS, as well as CAS and CAS2 on the
68020, drops the Address Select line for the duration of the RMW
(read-modifywrite) cycle. Only the state of the R/W pin changes. I'm not
really sure on these details but: The Amiga's ram doesn't accept only the R/W
pin change as a valid bus request. AS HAS to be strobed. TAS is harmless on
the amiga, however: the read is performed, but the memory never sees the
write! Not quite what you wanted! Use BITSET instead.
As it precludes even the possibility of multiple-processoring the current
amiga, and probably creates some of the DMA problems, I'm a tad upset. (I
think everyone will have multiple processor systems in 5 years or so) 'Course
on the ST and Mac these instructions utterly crash the machine last I
looked… Go ahead, plug a 68010, even, into a mac… Stand BACK! there ya
go! Mike.
interesting, about TAS on internal RAM. but what about external RAM? why
shouldn't it be a little more sane? i can understand the limitations of TAS
on the internal RAM, where there are rigid timing constraints due to video
access and other "fixed" DMA. but why should something outside the box be
subject to the same limitations? liberate your CPU! –Scotty
Ahh.. but Scotty, if you use TAS in a program, you have by definiton limited
your market to those who have expansion RAM, and who also never run enough
programs simultaneously to end up with your program in the lower 512.
He hit the nail on the head. Nuthin wrong with BSET, save for when the Amiga
5000 comes out with 12 68020 CPUs… and all your code doesn't work because
you needed to use TAS… Actually… TAS REALLY only needs to be used by the
OS. Expansion ram should work, though I won't put nuthin by these
manufacturers. there's gotta be a sound reason for leaving TAS out. Anyone?
Mike.
He hit the nail on the head. Nuthin wrong with BSET, save for when the Amiga
5000 comes out with 12 68020 CPUs… and all your code doesn't work because
you needed to use TAS… Actually… TAS REALLY only needs to be used by the
OS. Expansion ram should work, though I won't put nuthin by these
manufacturers. there's gotta be a sound reason for leaving TAS out. Anyone?
Mike.
who would need TAS unless there was another CPU out there? <hint> –Scotty
who would need TAS unless there was another CPU out there? <hint> –Scotty
Ahh.. but Scotty, if you use TAS in a program, you have by definiton limited
your market to those who have expansion RAM, and who also never run enough
programs simultaneously to end up with your program in the lower 512.
Even if you could get TAS operating on external RAM, would you really want to
use it? You'd have to tag any section of code using TAS for FASTMEM only,
which would limit you to running only on expanded machines. That's a problem
in several respects. You might get away with running on a A2000 (or whatever
the next one is going to be) if it has built-in FASTMEM, and of course on
current expanded systems. But then suppose an A3000 comes out with 2Megs of
memory in a 2Meg CHIPMEM address space. Then you're right back to running
only on expanded machines. There's certainly no real harm in designing a
board that does handle TAS, or at least acts as intelligently as possible
when given the instruction (i.e. it doesn't crash like an ST or a MAC), but I
wouldn't use the instruction in any program I write.
Even if you could get TAS operating on external RAM, would you really want to
use it? You'd have to tag any section of code using TAS for FASTMEM only,
which would limit you to running only on expanded machines. That's a problem
in several respects. You might get away with running on a A2000 (or whatever
the next one is going to be) if it has built-in FASTMEM, and of course on
current expanded systems. But then suppose an A3000 comes out with 2Megs of
memory in a 2Meg CHIPMEM address space. Then you're right back to running
only on expanded machines. There's certainly no real harm in designing a
board that does handle TAS, or at least acts as intelligently as possible
when given the instruction (i.e. it doesn't crash like an ST or a MAC), but I
wouldn't use the instruction in any program I write.
interesting, about TAS on internal RAM. but what about external RAM? why
shouldn't it be a little more sane? i can understand the limitations of TAS
on the internal RAM, where there are rigid timing constraints due to video
access and other "fixed" DMA. but why should something outside the box be
subject to the same limitations? liberate your CPU! –Scotty
This is the wrong place to reply for this I Think: 1. My story on TAS is: TAS
holds AS low, the only thing that changes is the status of the R/W pin. For
some reason, it is easier to not account for this.. Ah.. heres the Sidekick
note I wrote: so its fragmented… At 12:50 an hour ya want war and peace? I
got this part off somebody at DELPHI whose name I can't remember, which is a
darn shame as he's really bright… TAS, as well as CAS and CAS2 on the
68020, drops the Address Select line for the duration of the RMW
(read-modifywrite) cycle. Only the state of the R/W pin changes. I'm not
really sure on these details but: The Amiga's ram doesn't accept only the R/W
pin change as a valid bus request. AS HAS to be strobed. TAS is harmless on
the amiga, however: the read is performed, but the memory never sees the
write! Not quite what you wanted! Use BITSET instead.
As it precludes even the possibility of multiple-processoring the current
amiga, and probably creates some of the DMA problems, I'm a tad upset. (I
think everyone will have multiple processor systems in 5 years or so) 'Course
on the ST and Mac these instructions utterly crash the machine last I
looked… Go ahead, plug a 68010, even, into a mac… Stand BACK! there ya
go! Mike.
i don't understand what the big deal is. the dma device asserts BR*, the
68000 gives BG*, and the dma device waits for AS* to go high, and then
asserts BGACK*. at least that's what i understand from all the 68000 books i
have. i really don't see the big deal if the dma device follows the bus
specs. –Scotty
Apparently, the fact that a TAS cannot be split, and that the DMA devices
expect to be able to grab the bus at their usual time causes the problem.
This translates into it being very difficult for the DMA chips to tell when a
TAS is being executed. A minor problem indeed. There are other ways. (I never
dreamed there'd be *SO* many ways to do any given thing on this chip)
The 68000 family is famous for throwing out multi-processing and/or virtual
memory with the TAS instruction. Why is there a 68010??? So it can handle
virtual memory. The 68020 also has a few gothca instructions for
multiprocessing. Also, anything that mucks multiprocessing mucks DMA that
makes assumptions. Thats life in the Motorola world. Basically, you just have
to ignore the TAS instruction for machines like the Amiga. L. B. Daniel
TAS is not designed to throw out multiprocessing, but to FACILITATE it. if you
got it, support it.
TAS is not designed to throw out multiprocessing, but to FACILITATE it. if you
got it, support it.
The 68000 family is famous for throwing out multi-processing and/or virtual
memory with the TAS instruction. Why is there a 68010??? So it can handle
virtual memory. The 68020 also has a few gothca instructions for
multiprocessing. Also, anything that mucks multiprocessing mucks DMA that
makes assumptions. Thats life in the Motorola world. Basically, you just have
to ignore the TAS instruction for machines like the Amiga. L. B. Daniel
it's TAS. yeah, it's rare. but why limit software with hardware?? why do
you think we got amigas in the first place? and how might a RMW cycle cause
a DMA device to stumble and fall? –Scotty