🚀 go-pugleaf

In article <197@oliveb.UUCP>, spud@oliveb.UUCP (John E. Purser) writes:
> In article <1189@dataio.UUCP> bright@dataio.UUCP (Walter Bright) writes:
> >I am interested in copying pixel data from one page to another on the
> >IBM EGA. This involves moving 128k bytes of data. Doing it with a
> >REP MOVSW takes about 1/2 second (on an AT), which is too slow.
> 
> How did you arrive at the time of 1/2 second? The way I figure this
> it should only take about .05 seconds. According to the 286 programmers
> referance guide a REP MOVSW takes 5+(4*CX) clocks. In your example that would
> be 64k words times 4 plus 5 or a total of 262,149 clocks. The clock speed
> of the AT is 6Mhz so dividing the 262,149 by 6,000,000 leaves us with .045
> seconds. It may be that the video RAM is slow and requires a wait state
> or 2 on each access but thats a memory limitation and it won't help to use
> DMA in that case.
> 
First off, if you want to move 128K "pages", I presume that you are using the
EGA in the highest resolution, 640x350x16 colors, mode 10 (hex).  In this mode
the video refresh seems to eat up much of the memory bandwidth; thus the EGA
inserts wait states as needed until a free "access slot" is available to
service the processor - this happens even on a 4.77 MHz 8088 in the PC, not
to mention, for example, my 8 MHz 80286.  Because of this, and the very well
optimized string instructions on the 286, I doubt that DMA could do any faster
than CPU based moves, copying EGA->EGA.  (Even if you could get memory->memory
DMA working, that is).

You have two basic possibilities for EGA->EGA moves: plane by plane or all at
once.  For plane by plane, set the EGA to read a given plane (of 4), and to
write only to the same plane, do the copy (80x350 = 28KBytes) using MOVSW
with CX = 14000; then switch read and write enables to the next plane and
repeat.  This will be hampered by the fact that each 16 bit read or write
will actually be done as 2 back to back 8 bit writes (transparent to the
CPU - the EGA is an 8 bit card), each with several wait states, so this
will be considerably slower than the MOVSW calculation above (which assumed
real 16 bit transfers with 0 wait states).

The other way is to set up the EGA to write from its internal latches,
which hold 32 bits retrieved by the last EGA read (8 bits x 4 planes).
Then you do a 1 byte read from the source, and a 1 byte write (contents of
write do not matter, only the write strobe and address), in order to xfer
32 bits (1 byte x 4 planes).  You cannot do this word at a time because the
internal latches are only 8 bits wide.  So in this case you use a MOVSB
with CX=28000.  Each cycle transfers 32 bits with only two memory cycles
(and the corresponding wait states), as opposed to the first method which
transfers 16 bits/rep with 4 memory cycles and corresponding waits.  This
should be much faster; ironically, it should run at approximately the same
speed on a PC or AT, since the limitation is the EGA cycle stealing and
8 bit wide internal path.  Did that come across - the second technique
should work faster on a PC than the first does on an AT?

Also note that a full screen image in this mode only occupies 114 KBytes,
not 128 - so you can save another 10% or so if you only need to move the
visible image.

The exact ways to set up the EGA registers for this can be found in the
IBM manuals, or PC Tech Journal had an article, etc.  To much to go into
here and now.  Good luck.


-- 
--
Zhahai Stewart
{hao | nbires}!gaia!zhahai