Dec 052017
Asm code snippets.

Full Description of File

This file is an ongoing collection
of code snippets and docs from the
Fidonet 80XXX assembly language echo.

File 80XXX_94.ZIP from The Programmer’s Corner in
Category Recently Uploaded Files
Asm code snippets.
File Name File Size Zip Size Zip Type
!README! 526 304 deflated
386CRC32.ASM 4432 1888 deflated
386SXDX.ASM 1854 737 deflated
ABORT.A86 2342 826 deflated
ATZ.ASM 1537 568 deflated
BFIO12.ASM 40842 8682 deflated
BLINK.ASM 1080 418 deflated
BOOK.LST 3326 1449 deflated
BOOTDOS5.ASM 17244 4531 deflated
BOOTSECT.ASM 13263 3556 deflated
BOOTTHRU.ASM 1774 760 deflated
BRESENHM.ASM 3674 989 deflated
CHK-ANSI.ASM 1946 755 deflated
CIRCLE.ASM 2129 784 deflated
CMD-TAIL.ASM 6578 1814 deflated
CONVERT.ASM 4237 1124 deflated
COPPER.ASM 2954 982 deflated
CPUID.ASM 1478 575 deflated
CPUID32.ASM 18070 4701 deflated
CPURES.ASM 5634 1802 deflated
CRC.ASM 10819 3536 deflated
DBVGA.ASM 24272 4345 deflated
DEBUG-AD.ZIP 2275 2203 deflated
DETECTSB.ASM 6788 1477 deflated
DMA.TXT 10937 4160 deflated
DMAFAQ.TXT 35431 7749 deflated
DMA_CODE.ASM 14943 3743 deflated
DMA_VLA.TXT 14330 2288 deflated
DOT.ASM 1523 652 deflated
DPMISPEC.TXT 171681 31465 deflated
DR.TXT 2493 1198 deflated
DR2.TXT 5537 2156 deflated
DRLITE.ASM 3467 1036 deflated
EMS&EEMS.TXT 41913 11980 deflated
EXEC.ASM 5590 1627 deflated
EXEC2.ASM 6462 1762 deflated
EXEC3.ASM 2558 935 deflated
EXEHEADR.TXT 1373 520 deflated
F-IN&OUT.ASM 12135 2669 deflated
FADE.ASM 5831 1203 deflated
FADE2.ASM 4348 1050 deflated
FILE_ID.DIZ 113 99 deflated
FLAT386.ASM 1635 626 deflated
FONT.ASM 3058 990 deflated
FONTS.TXT 1399 510 deflated
GETCOL.ASM 3873 1327 deflated
HEXOUT.ASM 1725 610 deflated
HEXOUT2.ASM 488 228 deflated
HND2NAME.ASM 1840 673 deflated
HWREAD.ASM 8529 2470 deflated
INIT.ASM 3636 1395 deflated
INPUT.ASM 23826 4002 deflated
INWIN.ASM 591 266 deflated
ISPROT.ASM 5921 1484 deflated
LABEL.ASM 1713 680 deflated
LEDS.ASM 3579 955 deflated
MATH.TXT 4378 1667 deflated
MEMALLO1.ASM 4645 1683 deflated
MEMALLO2.ASM 2319 652 deflated
MISC.TSR 2529 1344 deflated
MODEM.ASM 3472 1026 deflated
MODEM.TXT 1657 644 deflated
MODFIL10.TXT 67382 17538 deflated
MOUSETUT.TXT 23036 4469 deflated
MYPART.ZIP 5051 4990 deflated
NEWBEEP.ASM 4063 1217 deflated
NO#47.DOC 5981 2499 deflated
ORGVECTR.ASM 4878 1584 deflated
P87TEST.ASM 9275 2605 deflated
PC-SPKR.TXT 2142 867 deflated
PENTBUG.ASM 2111 920 deflated
PENTID.ASM 4004 1421 deflated
PIC.TXT 9095 2380 deflated
PM.ASM 5774 2170 deflated
PM2REAL.ASM 3244 1286 deflated
PMODE.ASM 5410 1608 deflated
PMREBOOT.ASM 3229 954 deflated
PRDEC32.ASM 7222 2822 deflated
PRIMARY.ASM 1759 690 deflated
PRINTF.ASM 74828 12662 deflated
PRINTHEX.ASM 1891 553 deflated
PRNT.ASM 2323 746 deflated
PROTMODE.ASM 1594 830 deflated
PUTIMAGE.PAS 3231 1199 deflated
PUTPIXEL.TXT 7482 2627 deflated
RANDOM#.TXT 11004 3847 deflated
RANDOM1.ASM 2673 978 deflated
RANDOM2.ASM 1248 536 deflated
RANDOM3.ASM 3718 1471 deflated
RANDOM4.ASM 2140 738 deflated
RANDOM5.ASM 3848 1669 deflated
READ-MAC.TXT 2076 981 deflated
READER.ASM 2775 989 deflated
RINGER.ASM 2301 952 deflated
RTCREF11.TXT 17415 5845 deflated
RTC_REF.TXT 17051 5746 deflated
SBOSC.ZIP 1427 1343 deflated
SCROLL.ASM 6975 1353 deflated
SERIAL15.ZIP 45061 45037 deflated
SHRINK10.ZIP 4146 4039 deflated
SIN-COS1.TXT 2615 1247 deflated
SIN-COS2.TXT 2455 995 deflated
SKELETON.ASM 24449 4867 deflated
SMALLPAL.ASM 4508 1651 deflated
SNDBLSTR.TXT 21429 6832 deflated
SORT.ASM 1354 487 deflated
SOUNDEX2.ASM 14857 4839 deflated
SOUNDS.TXT 1880 675 deflated
SPEED.ASM 2793 1032 deflated
SPIRAL.ASM 2132 609 deflated
SQROOT.TXT 2171 992 deflated
SQRT1.ASM 1325 572 deflated
SQRT2.ASM 1820 748 deflated
SQRT3.ASM 349 198 deflated
ST21R.ASM 26003 6387 deflated
ST21R.ZIP 5394 5333 deflated
STR_MTCH.ASM 3066 964 deflated
TERM.ASM 10832 2661 deflated
TEST4EMS.ASM 6750 1730 deflated
TINYPLAY.ZIP 13476 12967 deflated
TOADEXEC.ASM 5299 1752 deflated
TOADTSR.ASM 6706 2512 deflated
TOADUU21.ZIP 24179 23990 deflated
TPCREAD.ME 199 165 deflated
TRAPTEST.ASM 3451 1169 deflated
TSR.ADD 4016 1569 deflated
TSR.TXT 5246 1421 deflated
TSRES.ASM 6874 1703 deflated
TSRTEMPL.ASM 3690 1091 deflated
UART_TUT.TXT 29923 9222 deflated
VRATE.ASM 5002 1312 deflated
WHOAMI.ASM 5512 1385 deflated
WPHD.ASM 2830 931 deflated
X.ZIP 4128 4030 deflated
XMS2SPEC.DOC 35957 8947 deflated

Download File 80XXX_94.ZIP Here

Contents of the DMA.TXT file

Author unknown.


Consider the problem of moving a large amount of data to or from an I/O
device. This requirment is commonly encountered in the operation of many
peripheral devices (disk drives, for example) that are constantly moving
large amounts of data into and out of memory. An ovious way of making
the transfer would be a short program which for an input operation might
read a byte from the I/O port into the accumulator (AX register) of the
8088 processor, and then move the data from the AX register to a memory
location to store it. In addition, we have to keep track of the memory
locations where the data is going. By far the simplest way of handling
this is to lay the data down in continuous blocks locations within a block
of memory, using one of the processor's index registers to control the
address. Each time a byte is transfered, the index register(usually the
DI or Destination Index register) is incremented or decremented to point
to the next location. A typical example assembly language program to do
this might be as follows:


SETUP: MOV AX,SEGMENT ; setup segment of memory transfer

MOV DI,OFFSET ; setup start address within segment

MOV CX,COUNT ; setup # of bytes

MOV DX,IOPORT ; DX = I/O port address

READ: IN AL,DX ; read byte from I/O port (8)

MOV [DI],al ; store data (10)
INC DI ; increment index (2)
LOOP READ ; continue till CX = 0 (17)

CONT: ...... ; yes, continue with program


The opposite oeration of transfering data from memory to an I/O port is
essentually similar. The numbers in parentheses following the READ: label
are the number if processor clock cycles required to execute each instruction,
with a total of 37 processor clock cycles required to execute the entire
read segment. On a standard IBM PC, the clock runs at 4.77 MHz, corresponding
to a clock cycle period of 210 nanoseconds, and the loop takes 37 cycles or
7.8 microseconds to execute. This would be the fastest we could transfer each
byte. Note also the following:

1. The processor is tied up 100% of the time in transferring data; it cannot
execute any other part of the program while the transfer is underway.

2. The rate at which the data is transferred is controlled by the processor
clock and may not correspond to the rate at which the I/O device wants
to handle the data. This can be circumvented by polling the I/O device
to see if it is ready, or having the I/O device generate a hardware
interrupt; but either of these adds further code to the routine which
will slows down the transfer rate even further. In practice because of
all the stacking of registers that occurs when a hardware intrrupt is
processed, it is impossible to handle data transfers rates much above
5 to 10 Khz using interrupts.

3. If the processor has to handle an interrupt from one device while it is
involved in handling a data transfer to another device then the delays
involved may cause it to miss data, or at least will cause the
discontinuitly in the data flow.

It would be nice to have a way of transferring data without involving the
processor so it can be freed up as much as possible to attend to execution
of the program. It wouldalso be a plus if we could speed the transfer rate
up and be able to control the rate easily. Since all we want to do is move
a byte directly to/from an I/O port from/to memory without any sort of
processing on the way, we are better off not using the processor at all, but
instead proving special hardware that will accomplish this commonly required
task. The process of connecting an I/O device directly to memory is known
as Direct Memory Access (D.M.A.), and the hardware that controls this process
is known as the D.M.A. controller, which the case of the IBM PC is the function
of the 8237 chip on the system board.


What happens when a device wants to transfer data to/from memory? The first
step is for the device to send a signal known as a D.M.A. REQUEST (DREQ for
short) to the D.M.A. controller. The processor normally has control of the
computer's address and data busses as well as control signals such as memory
read/write (MEMR & MEMW) and I/O read/write (IOR & IOW) lines. To accomplish
a D.M.A. transfer, control of these lines must be passed to the D.M.A.
controllers. On receipt of the DREQ, the D.M.A. controller in turn issues
a HOLD REQUEST to the processor. As soon as it is able to, when it has
partially completed the instruction it is currently executing, the processor
issues a HOLD ACKNOWLEDGE signal to the D.M.A. controller, and simultaneously
disconnects itself from the address, data and control busses. This process
is technically known as "TRI-STATING" as the connections to the processor
assume a third, open circut state, compared to thier usual binary states of
1's and 0's or highs and lows. On receipt of the HOLD ACKNOWLEDGE, the D.M.A.
controller goes to work. It realeases its own connections to the address and
control busses from thier tristate condition, asserting a valid memory address
from an internal counter and then issues a D.M.A. ACKNOWLEDGE (DACK) signal
to the I/O device followed by a simultaneous IOW and MEMR for data outpu, or
IOR and MEMW for input. The perepheral in turn responds to the DACK and IOR
or IOW signals by placing or recieving data on the data buss effecting a
transfer directly to/from meory. On completion of the MEMR/IOW or MEMW/IOW
from the D.M.A. controller, the controller removes DACK, releases HOLD
REQUEST, tristates its own address and control lines, and increments or
decrements its internal address counter ready for the next transfer. The
processor in turn regains control of the busses, continuing execution execution
of the next instruction. From the assertion of the DREQ to completion of the
cycle takes about 2 to 5 microseconds, depending on the length of the
instruction that the processor happens to be engaged in on receipt of the
DREQ. The accual amount of time between instructions that the processor
loses the buss to the D.M.A. controler is even less, about 1 microsecond.
The effect on program execution is minimal even when transferring data at
very high rates which can approach 350,000 bytes/sec on the IBM PC. To
prevent the D.M.A. controller from 'hogging' the busses if the DREQ is
held constantly high, the controller always allows the processor to perform
at least part of an instruction between each D.M.A. transfer, so that even
operating "flat-out", D.M.A. cannot grab much more than 30% of the buss

In order to perform D.M.A. operations, the perpheral must include hardware
that generates the DREQ and responds to the DACK. The D.M.A. controller, on
the other hand, is a system component that is a standard feature of the IBM PC
architecture. Most compatibles also include the D.M.A. controller, with the
execption of the TI Professional.

It is important to appreciate that the D.M.A. controller sets the dunamics
of the D.M.A. transfer, that there is nothing in the peripheral I/O device
that can alter the maximum speed at which the controller will handle data.
There are some surpising side effects of this, in particular the IBM PC/AT,
which is genrally 3 times faster than a standard PC or PC/XT, is actually
slower at D.M.A. transfers because its controller operates at 3 MHz instead
of 4.77 MHz on the PC. On the other hand, it can also perform 16-bit
transfers on its extended data buss, as well as 8-bit transfers on PC
compatible section of its data buss which with the right hardware can make
up for the slower transfer rate. Although they can operate in D.M.A. mode
in the PC/AT, many boards perform word (16-bit) transfers by making two
sequential byte (8-bit) and so are unable to take advantage of the AT's
extended buss; this being the price paid for PC compatibility.


Although we have discussed the operation of a single device using the D.M.A.,
it is custom to cater to the needs of several devices by providing several
D.M.A. channels, each one dedicated to a peticualar device. The 8237 provides
four seperate D.M.A. channels, known as levels 0 through 3. Correspondingly,
there are 4 D.M.A. request lines, DACK 0-3. These lines are prioritized
according to two possible protocols set by a bit in the controller command
register, either fixed priority, either fixed priority where lower D.M.A.
levels have higher priority than higher levels, or rotating priority, where
each level takes turn at having the highest priority. The PC BIOS sets the
8237 to operate in fixed priority mode on power up, and it is inadvisable
to change this. The PC/AT adds to the number of D.M.A. channels by using
two 8237 D.M.A. controllers. Since one channel is used to cascade one
controller into the other, this is acually adds an additional 3 channels,
all of which appears on the 16-bit additional expanision connectors of the
PC/AT and dedicated to 16-bit transfers.

Apart from its uses for high speed data transfer, the D.M.A. controller
includes counter hardware that cycles through the memory addresses, so as a
byproduct of its design, it can also be used to refresh dynamic memory, saving
the cost of a separate memory refresh controller. This is what IBM chose to
do in the PC, and on all models Level 0 performs this function with the
DREQ being driven from counter 1 of the 8253 timer at a 15 microsecond
intervals. The complete assignmentes for the levels are as follows.

For all machines, these levels are capable of 8-bit transfers:

Level 0 - Memory Refresh
Level 1 - Not assigned and usally avalible, Certain local
area network interfaces may use this level
Level 2 - Used by the floppy disk controller and not free
for any other purpose
Level 3 - May be used by the hard disk controller on some
PC/XT models. On floppy disk only, PC/AT and some
PC/XT machines, this level is free for other uses.

For the PC/AT only, these levels are capable of 16-bit transfers:

Level 4 - used for cascading
Level 5-7 - Avalaible on AT special connections


 December 5, 2017  Add comments

Leave a Reply