Anonymous user
ISA DMA: Difference between revisions
m
many little fixes and replaced SHOUTING by more professional ''emphasis''
[unchecked revision] | [unchecked revision] |
m (many little fixes and replaced SHOUTING by more professional ''emphasis'') |
|||
Line 1:
'''ISA DMA''' ('''Industry Standard Architecture Direct Memory Access''') in today's PC architecture, like ISA itself, is in many ways like an appendix. It is used by the floppy disk controller, ISA sound cards, ISA network cards and parallel ports (if they support ECP mode). Whilst interrupt, keyboard and timer interface circuits have obvious and relevant uses, the ISA DMA controller and it's programming interface are still well and truly stuck in the 1970's where they were first designed. Modern PCI controllers typically have their own
The idea behind DMA is that you can set up a 'channel' with an address pointing into memory and the length of the data to be transferred. Once set up, you can tell the peripheral owning the 'channel' to do whatever it is supposed to do (e.g. read a sector). Then the CPU can go onto something else. Periodically when the data bus isn't being used by the CPU the DMA chip takes over and transfers data between the peripheral and memory without involving the CPU. When the transfer is complete (e.g. an entire sector has been sent to the floppy drive) the DMA chip will than signal that it is finished. The DMA chip can even signal if it has run out of data, allowing the CPU to program some new information and another transaction to proceed.
Line 6:
Of course all good ideas can have downsides and while Intel can't really be blamed for what is about to be described, IBM certainly can.
== DMA Genesis, Chapter 1, Verse 1 ==
In the beginning there was a PC, but the PC was slow. IBM looked down from the heavens and said "Slap on a DMA controller - that should speed it up." IBM's heart was in the right place, its collective brains were elsewhere as the DMA controller never met the needs of the system. The PC/AT standard contains 2 Intel 8237A DMA chips, connected as Master/Slave. The second chip is Master, and its first line (Channel 4) is used by the first chip, which is Slave. (This is unlike the interrupt controller, where the first chip is Master.) The 8237A was designed for the old 8080 8-bit processor and this is probably the main reason for so many DMA problems. 8088 and 8086 processors chosen by IBM for its PC were too advanced for the DMA controller.
Line 14 ⟶ 13:
DMA Channel 0 is unavailable as it was used for memory refresh, and remains reserved because of this (even though modern computers don't use it). DMA channel 4 cannot be used for peripherals because it is used for cascading the other DMA controller.
DMA Channels 1, 2 and 3 can only transfer 64 KB of information at a time (the internal registers are only 16 bit). In order to extend this, IBM added an
DMA Channels 5, 6 and 7 transfer data 16 bits at a time, by shifting addresses one bit to the right and clearing the lower bit. The addressing is exactly the same except you can now start on 128 KB boundaries and transfer up to 128 KB of information at a time before the DMA boldly transfers what has never been
Previously it was mentioned that the DMA controller is able to signal completion and even ask for more information. Unfortunately this would make expansion slots too big, so IBM left all of the connections to the DMA chips off. The only time you know when a transfer is complete is for a peripheral to signal an interrupt. This implies that all peripherals using a DMA channel are limited to no more than 64/128 KB transfers for fear of upsetting the DMA controller.
Finally,
Ignore that
So after reading all the above, the main
* DMA channel 1, 2 and 3 are for 8 bit transfers;
* DMA channel 5, 6 and 7 are 16 bit transfers;
* Transfers shouldn't cross 64 KB or 128 KB boundaries;
* Transfers can only be from the lowest 16 MB of memory;
* DMA is slow - theoretically 4 MB/second but more like 500 KB/second due to ISA bus protocols.
Note that:
* Sound Blaster
* Sound Blaster 16+ supports both;
* Floppy disk controllers only support 8 bit DMA and usually use DMA Channel 2.
== Busmaster DMA ==
The IBM/XT used DMA channel 3 for hard disk connections but instead of using DMA the IBM/AT used direct writing to the hard disk using the processor, this was because of the 128 KB limitations outlined above and the fact that the 286 processor could perform 16 bit transactions at 6 MHz. Even the ISA bus could run at a speed of up to 12 MHz, far faster than the 4.77 MHz the DMA controller was running at.
Expansion card designers were also upset with DMA's lack of capabilities, noticeably
To get around the limitations of the
Busmaster DMA is probably easier to understand than normal DMA. Provided you know what registers are on your expansion card, you can send them the address and the amount of data to transfer. The expansion card will send you an interrupt upon completion.
PCI Bus Masters can of course access memory with 32 bit addressing. Newer PCI cards are starting to support 64 bit addressing (although at the moment most don't). Typically PCI cards use
ISA Bus Masters are still limited to the lower
== Programming the PC DMA controllers ==
=== Paging ===
As this article assumes you are writing your own OS, the subject of memory management is very important unless you are writing a 286 based operating system. This is because as mentioned earlier, all DMA transactions must occur in the lower 16 MiB of memory. (Yes, I'm repeating myself - memorize - it is crucial.)
To be more specific all DMA transactions must occur in ''physical memory''. The DMA controller only functions with ''physical'' memory, if you pass it a virtual address happily mapped into anywhere in memory, the DMA controller will happily ignore your carefully constructed page mapping and access whatever it decides to. VM86 mode does not use ''physical'' addressing. The physical addresses are ''fake''. In VM86 mode the OS must emulate any DMA transactions on behalf of an application, probably in a totally non-DMA way. Almost all DOS memory managers and operating systems that uses V86 mode to run DOS applications (including Windows 3.x enhanced mode and EMM386) supply virtual DMA functions, but these are basically the same, the V86 monitor 'fakes' the DMA transaction. DMA has no knowledge of paging whatsoever and I should point out that this includes Bus Master DMA.
Finally (and this is a great laugh when it happens) don't forget to
"Paging? Whats that then? Dunno. You've just mapped in the password file? No problem, I'll write that out to the floppy instead."
DMA memory is like Memory Mapped I/O - do not move - do not page.
(I apologise for sounding really dictatorial, it's just that DMA is so easy to screw up. Lots' more things to screw up later! - just wait till we get to commands)
One way to handle this situation is to manage memory below 16 MB using a
An example for getting it right:
* Map the lowest 64K of ''physical'' memory elsewhere in memory and aim the DMA channel you are setting up at address 0.
* Set up the DMA channel for the correct type of transaction (more on this later).
* Next DMA Channel, map the next 64K of ''physical'' memory somewhere, aim your DMA channel at address 64K.
* Set up the DMA channel for the correct type of transaction (more on this later).
* Complete building your pages stacks / bitmaps whatever and add any lower memory left over.
Apart from making sure that you have a copy somewhere of the information in the first 4K of memory and the Extended BIOS Data Area (these are for VM86 tasks if you decide to add BIOS/DOS/VESA/PCI support later), the above example will allow you to have a flat paged memory area from 0 to forever while still allowing you OS to use old DMA dependent peripherals. The device drivers work with CPU paged memory areas, while the DMA controller is happily working with low memory
===Registers===
Each 8237A has 5 registers, addressed via I/O space:
{| {{wikitable}}
Line 137 ⟶ 131:
|}
Each DMA Channel has an External Page Address Register that is added to the upper 8 bits of the DMA transfer address:
{| {{wikitable}}
Line 191 ⟶ 185:
|}
* '''REQ3-0''': When set: DMA Request Pending.
* '''TC3-0''': When set: Transfer Complete.
This register isn't very important in light of the fact that the 8237 can't send an IRQ to tell you that it has finished. Usually there is no need to poll this register as again the peripheral owner will send an interrupt when a transaction has finished and polling would be a total waste of time.
;Command Registers 0x08 and 0xD0
{| {{wikitable}}
|-
Line 220 ⟶ 214:
This register really shows how incompatible the 8237 is with the PC hardware.
* Let's start with EXTW and COMP. These increase the speed of DMA transfer by 25% be removing one of the clock cycles. Does it work? No.
* PRIO. When zeroed, this allows DMA priorities to be rotated allowing freedom and liberty for all peripherals that share the data bus. Does it work? No.
* MMT and ADHE. Did you know that the IBM PC could do memory to memory transfers since 1981? Thats right, hardware sprites, hardware frame buffering from one location to another. Does it work? No.
* COND. Hooray the only bit in the control register that does something useful. Setting this bit disables the DMA controller. This lets you set up multiple DMA channels without masking each and every channel.
;Request Registers 0x09 and 0xD2
;DMA Channel Mask Registers 0x0A and 0xD4
{| {{wikitable}}
Line 251 ⟶ 245:
|}
To mask a channel for programming
* To unmask a channel set STCL to 0.
This register only allows you to mask
;DMA Mask Registers 0x0F and 0xDE (Write)
Line 279 ⟶ 273:
|}
Setting the appropriate bits to 0 or 1 allows you to mask or unmask those channels. DMA channels 3, 2, 1, 0 or 7, 6, 5, 4. Note that masking DMA channel 4 will mask 7, 6, 5 and 4 due to cascading.
;DMA Mode Registers 0x0B and 0xD6
{| {{wikitable}}
|-
Line 307 ⟶ 299:
This register is tricky as it depends highly on the peripheral you are programming the DMA controller for.
* '''SEL0''' and '''SEL1'''
* '''TRA0''' and '''TRA1''' selects the transfer type
**
**
**
**
* '''AUTO''': When this bit is set, after a transfer has completed the channel resets itself to the values you programmed into it. This is great for floppy transfers. Read in a track - the values set themselves up for reading again immediately. For writing you'd only need to alter the transfer mode - not the addresses. Some expansion cards do not support auto-init DMA such as Sound Blaster 1.x. These devices will crash if used with auto-init DMA. Sound Blaster 2.0 and later do support auto-init DMA.
* '''IDEC''': Increment/Decrement. I guess if you wanted to write big endian data to a floppy drive you could. Big-endian processor based computers wouldn't be using an 8237.
* '''MOD0''' and '''MOD1''': This is where some problems can arise based on the peripheral the DMA controller is attached to. The DMA controller has several modes:
** 0b00 = Transfer on Demand;
** 0b01 = Single DMA Transfer;
** 0b10 = Block DMA Transfer;
** 0b11 = Cascade Mode (use to cascade another DMA controller).
Single transfer mode is good for peripherals than cannot cache a lot of data at once. A good example is early floppy controllers that have only a very small buffer. The DMA controller and CPU can share the data bus happily. Sound Blaster and Sound Blaster Pro use software or Single Transfer DMA Mode.
Block transfer mode is good for peripherals that can buffer entire blocks of information. A good example of this is an ESDI or SCSI controller without Bus Master DMA.
Demand transfer mode is good for peripherals that start and stop intermittently such as a tape drive. The drive can read a whole load of information for as long as it can and the suspend the transfer to move to another section of the tape. Newer floppy controllers also work well with demand transfer
In addition to the above registers the 8237 has three command registers
The first command register is 0xd8 which is called the 'reset flip-flop' register. The DMA controller is an 8-bit chip. In order to write 16-bit values into an address register or count register you must write two 8 bit values appropriate register address (to follow). Imagine however that you only write one 8 bit value and the the next time try to write a 16 bit value. The DMA chip will be expecting the high byte, not the low byte. Clearing the flip-flop guarantees getting the address into the DMA controller in the right order. To reset the flip-flop write anything to the register :
;ASM
Line 351 ⟶ 330:
void reset_flipflop_DMA()
{
outb(0xdb, 0xFF);
}
</pre>
Another dictate -
The second command register is the 'master reset and clear'. Writing anything to this register (0x0d) resets all count, address and mask values ready for you to program.
;ASM
Line 368 ⟶ 346:
void hard_reset_DMA()
{
outb(0x0d, 0xFF);
}
</pre>
The third command register is the 'clear mask register'. Writing anything to this register (0xDC) will clear the mask register (wow!) releasing all DMA channels to accept DMA requests.
;ASM
Line 383 ⟶ 360:
void unmask_all_DMA()
{
outb(0xdc, 0xFF);
}
</pre>
== Address and Count Registers ==
Each DMA chip has 4 16-bit address registers, 4 16-bit count registers and 4 ''external'' 8-bit page registers.
As previously mentioned a DMA controller ''cannot'' address or transfer more than 65536 bytes or words of information at a time.
The page registers can allow access to the lower 16 MiB of memory but are ''not'' incremented when crossing a 64k boundary. The easiest way is to make sure the address you supply in the address register is ''zero'' and that any addressing that you program the DMA controller to do is done using the external page register. It seems stupid, but unless you know that your transfer will not be over 64k it is the safest.
Example page register settings:
{| {{wikitable}}
! Page register
! Physical address
!
|-
| 0
| 0
|
|-
| 1
| 0x10000
| (64k)
|-
| 2
| 0x20000
| (128k)
|-
| .
| .
|
|-
| .
| .
|
|-
| .
| .
|
|-
| etc...
| etc...
|
|}
Make sure that you map the ''physical address'' of your DMA buffer somewhere in memory if using paging. This buffer can ''then'' be referred to by it's virtual memory address. Mark the memory as non pageable. Even though it's not memory mapped I/O, it is, except that isn't. Think of it as borrowing memory from the system because the expansion card manufacturer was too stingy to supply adequate buffering memory on their card.
OK, the I/O port addresses:
{| {{wikitable}}
! DMA 1
! DMA 2
! Register name
|-
| 0x00
| 0xC0
| Address Register channel 0/4
|-
| 0x01
| 0xC1
| Count Register channel 0/4
|-
| 0x02
| 0xC2
| Address Register channel 1/5
|-
| 0x03
| 0xC3
| Count Register channel 1/5
|-
| 0x04
| 0xC4
| Address Register channel 2/6
|-
| 0x05
| 0xC5
| Count Register channel 2/6
|-
| 0x06
| 0xC6
| Address Register channel 3/7
|-
| 0x07
| 0xC7
| Count Register channel 3/7
|}
; Page Registers
<div>
<div style="float: left; margin: 5px">
{| {{wikitable}}
| 0x87
| channel 0
|-
| 0x83
| channel 1
|-
| 0x81
| channel 2
|-
| 0x82
| channel 3
|}
</div>
<div style="float: left; margin: 5px">
{| {{wikitable}}
| 0x8F
|-
| 0x8B
| channel 5
|-
| 0x89
| channel 6
|-
| 0x8A
| channel 8
|}
</div>
<div style="clear:both"> </div>
</div>
For the pedantic among you, the page and address registers are actually used (not in modern
'''Note:'''
== [[Floppy Driver|Floppy Disk]] DMA Programming ==
After all that ranting, the next section may come as something of a let down. Firstly - you need implement only 3 routines to perform a DMA transfer. The example I am using is the Floppy Drive controller (probably the most common followed Sound Blaster).
So putting it all together - let's set up a DMA buffer for channel 2 (the floppy disk).
<pre>
initialize_floppy_DMA:
; set DMA channel 2 to transfer data from 0 - 64k in memory
; paging must map this
; set the counter to 0x23ff, the length of a track on a 1.
; the length of transfer is programmed count+1 (check
</pre>
Please note:
<pre>
prepare_for_floppy_DMA_write:
prepare_for_floppy_DMA_read:
</pre>
The above uses single transfer only for compatibility, but during the
out 0x0b, 0x56
would change to:
out 0x0b, 0x16.
=== Usage ===
;Initialization
During the initialization of your floppy driver:
* Map enough physical memory to virtual memory for the size of transfer you are going to do.
* ''(No more than 64k, all transfers to be sone in 64k chunks.)''
* ''(Memory must begin on a 64k boundary from between 0 and 16 MiB.)''
* Pin the pages allocated so you don't get page faults during reads or writes.
* Call initialize_floppy_DMA altered with suitable values.
;For a write
Note that there is no need to fiddle with the DMA addressing - it automatically resets itself to 0x0 ready for another transaction.
;For a read
* On the next read you can see if the track you want is in the buffer already and go straight to it. (This is called track buffering.)
The good thing about this setup is that it is simple and fast. There is no need to set up a track caching scheme and associated code (apart from checking if the current track number is in the cache).
I wouldn't advise trying to improve the speed of floppy access any further, the floppy disk is so slow compared to the rest of the computer another 1 millisecond of your time is going to be
Putting it simply, there's no real way to improve the write-performance of a floppy disk unless you are writing entire tracks of information at once and aiming for the fastest floppy formatting time record!
== In Conclusion ==
As I've (constantly) pointed out the DMA chip has lot's of useful features. The main point in programming the chip is remembering the features that '''
== References ==
=== External Links ===
* [http://www.stud.fh-hannover.de/~heineman/extern/231466.pdf Intel 8237A datasheet]
|