Re: asm.e questions
On Sun, 24 Oct 1999 13:48:19 -0500, Kat <KSMiTH at PELL.NET> wrote:
>----- Original Message -----
>From: Bernie Ryan <bwryan at PCOM.NET>
>To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
>Sent: Sunday, October 24, 1999 1:11 PM
>Subject: Re: asm.e questions
>
>
>> On Sun, 24 Oct 1999 12:29:37 -0500, Kat <KSMiTH at PELL.NET> wrote:
>>
>> >
>> >True DMA on a motherbd with only ISA slots?
>> >
>> >Kat
>>
>> Then how do you think the floppys work on your motherbord ?
>> The dma controller is on the motherboard.
>>
>
>I've never seen a DMA with a floppy. I know there is chip to handle the
DMA,
>it's been on motherbds at least since the ZX80 in one form or another. But
>you couldn't tell the hard drives to DMA to a memory location inside your
>program. On the early motherbds with PCI slots, not all the slots supported
>DMA *from* sound cards, hd cards, etc,, because they couldn't get that
>chip's attention to shut it off. What he needs to do is set the hd as a
buss
>*master* , not under the control of that chip. When the hd is running buss
>master dma, the dma chip on the motherbd does one job, the cpu does another
>job, and the card doing pci buss mastering does it's job. For instance, you
>could have the motherbd chip doing an ems page swap, the cpu running your
>app, and the hd dropping data into xms somewhere.
>
>Kat
Kat,
What is the relevance of this discussion? Soundblaster has been DMAing sound
data for lo these many years on the ISA bus, no less. Many SCSI cards and
some IDE/MultiIO cards supported DMA for IO on the ISA bus. Yes the PCI bus
with bus-mastering extended the control to a small extent and the speed to a
much greater extent. And there are only so many paths to memory...two to be
exact. As long as the two buses are not writing to the same leaf of the
tree, they can operate somewhat independently, but there are strong timing
considerations involved...AND NONE OF THIS IS WITHIN CONTROL OF MOST
PROGRAMS. Most of it happens at the BIOS level and most of it is as they say
is "hard" coded. Regardless of their pretended sophistication and "event"
orientation, most things that happen at the user program level are truly
procedural or interleaved at best. Simultaneity is not happening except at
the machine Rommed level. That is why Eu is so beautiful. It tends to make
explicit what is really happening for most programs...that is that they are
"proceeding" from beginning to end without ever having two things happen in
parallel. However sinuous the path, it still can be stretched out linearly
as if it had been written that way.
Yes, it would be nice to have explicit means of handling "threaded" code to
take advantage of IO and other wait times, but at the moment, I don't know
of any such facilities native to Eu. Thats what operating systems are for.
Where and how can this be related to programming in Eu, or for that manner
most other programming languages.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
