		     USING XLR8er RAM AS A GRAPHICS VIDEO RAM

			    by J.F.R. "Frank" Slinkman


   One of the most powerful, yet least used features of the HD64180 processor
on the XLR8er board are the two Direct Memory Access (DMA) channels.

   The chip provides two DMA channels:  Channel 0 (DMAC0), which is primarily
useful for transferring large blocks of memory from place to place within the
machine, and Channel 1 (DMAC1), which is useful for data transfers between
internal memory and external I/O ports.

   The transfer rates are very impressive.  DMAC0 memory-to-memory transfers
can be as fast as 1 megabyte per second (i.e., 6T per byte @ 6MHz) if memory
waits are set to 0.  DMAC1 memory-to-I/O or I/O-to-memory transfers can be as
fast as 857K per second (i.e., 7T per byte), assuming 0 memory and the one
mandatory I/O wait state.

   At a setting of 0,1,80, DMAC0 transfers are more than twice as fast (14/6)
as LDIR and LDDR instructions, and DMAC1 transfers are more than twice as fast
(15/7) as OTIR or INIR instructions.

   Both commands also have the advantage that memory addresses can be up to 19
bits, which means they can address up to 512K of RAM.  This means you can move
memory to and from any place in either the "bottom 64K" or in XLR8er RAM to any
place else in those areas of RAM, without having to do a lot of bank switching
and double buffering.

   For example, let's say you wanted to copy 32K of data in bank 0 to bank 10.
Using only the @BANK SVC, the only way to accomplish this without resorting to
an external storage device would be to copy the data in portions to addresses
below 0x8000, switch banks, and copy it back up to address above 0x7FFF.

   Using DMAC0, you need only write the source address (0x08000), the destina-
tion address (0x78000), the number of bytes to copy (0x8000) and one control
byte to the proper internal registers, and the job is done -- fast! -- more
than four times as fast, since the bank-switching method requires each byte to
be moved twice.

   As some of you know, I have developed and market some hi-res graphics
programs.  One of these products (since removed from the market for hardware,
not software, reasons) was an XLR8er version of SLOTMOD4, which uses DMAC1 to
send animation data to the graphics board.  The animation consists of spinning
slot machine reels, and all takes place in a 320 pixel (40 byte) x 60 pixel
area -- 2400 bytes of data per animation "frame," with a display rate of 60
animation frames per second.

   The DMAC1 transfer rate is so fast that I actually had to use task slot 11
as a "brake" to keep the program from displaying the data faster than the
monitor's 60 times per second refresh rate could display it.

   Then, a few weeks ago, I saw Mike Harrow's program which loads graphics
images in /HR format and sends them to the graphics board via DMAC1.  I think,
judging from a message he posted in the LDOS/TRSDOS SIG in CompuServe, that he
took a "cue" for that program from SLOTXL.

   In turn, I took a cue from his program.  Why couldn't a background task be
set up to use DMAC1 to continuously refresh the graphics board from a dedicated
area of RAM?  Thinking it out a little further, if this dedicated area of RAM
exists in XLR8er RAM, it could also be treated as an ERAMDISK disk file!

   This means that any program, instead of bothering with the irritating, time
consuming and sometimes complicated overhead of doing all the port twiddling
required to transfer data to and from the graphics board, could simply read and
write data to and from this disk file as an easy, "transparent" way of incorpo-
rating hi-res graphics into any program.  Further, establishing the file with a
logical record length of 80 makes each record correspond to one 80-byte line of
the graphics display.

   The program, GRAM/CMD, does this.  It is not completely developed, by any
means, but the "guts" are there for anyone who wants to incorporate this capa-
bility into their own software.  GRAM/CMD is intended mainly as a demonstration
of the concept.

   It has a *lot* of restrictions.  First, there must be a Type 2 ERAMDISK
installed, and it must include Bank 10, the top bank.  There is no reason it
couldn't be done with a Type 4 ERAMDISK -- I just didn't bother to do it, since
this is only a demonstration.

   There *is* a reason, however, for not doing it on a Type 5 ERAMDISK, that
being that the tracks are 4.5K, not 4K or 8K or some other factor of 32K.  Thus
the physical addresses of the top tracks will vary depending on how many banks
are being used. This makes it difficult to correlate record numbers in the disk
file to graphics board line numbers.

   GRAM/CMD requires the top five tracks of the ERAMDISK to be free, as the
XLR8er RAM from 0x7B000 to 0x7FFFF is used by the program for both the graphics
data (0x7B000 to 0x7FAFF) and most of the program code used by the background
task which continually refreshes the contents of the graphics board RAM.

   Since it uses task slot 11, it requires this task slot to be free.

   Because the data in the graphics RAM is treated as being in /HR file order,
the graphics board must constantly be kept in an "auto increment X on write"
mode.  The only options you have are whether the board is set for "text only,"
"graphics only," or "text overlay" mode.

   Since any application making use of the concept would be writing graphics
data to the disk file, and not directly to be board itself, the restrictions in
the above paragraph should not be overly confining. In fact, it would be point-
less to write to the graphics board itself since whatever you wrote there would
quickly be overwritten by the data in the graphics RAM.

   Therefore, I would suggest you set up three macros or subroutines, one to
establish each of the three permissible graphics board states, and rely solely
on those to switch between text display, graphics display, or text and graphics
overlaid.

   However, if you do need to change the graphics board from the "auto inc X on
write" mode, you MUST disable the interupts FIRST, and restore the board to one
of the three "legal" modes when you've finished, and BEFORE you re-enable the
interupts.  Otherwise, the results will not be very pretty to look at.

   If you're writing software intended to be run on either the Radio Shack or
Micro-Labs board, you should be aware of the differences between the two.  Bit
1 of Port 83H is used to enable/disable video waits on the RS board, and to
disable/enable text overlay on the uLabs board.

   Text overlay on the RS board is accomplished by writing a value with Bit 0
set to port 8EH.  This must be done after graphics display is enabled.  Text
overlay will remain enabled, however, even if you turn graphics display off,
then on; so you must write a value with Bit 0 reset to Port 8EH to disable text
overlay.

   For more complete information, I recommend the text files PORTS/DOC and
PORTS2/DOC, which can be found in the CompuServe TRS80PRO SIG's DL4.

   The operation of GRAM/CMD is very simple.  From DOS Ready, enter:  GRAM.

   You will be given a menu of the various available refresh rates, both in
terms of both graphics board lines per second, and seconds per full-screen
refresh.  These range from 60 lines/second, which translates to 4 seconds per
full-screen refresh, to 480 lines/second, which translates to two full-screen
refreshes per second.

   The faster the refresh rate, the more the system is going to be slowed down.
You can figure roughly 3/4 of 1% slowdown for each 60 lines/second of refresh.
Thus a 480 line/second refresh rate will result in just under a 6% slowdown.

   The task module, GFXTASK, is only 12 bytes long.  It will be placed in low
memory if space is available, and in high memory if not.  The reason it's so
short is that all it does is set up the registers for a @BANK SVC jump to
physical address 0x7FB00.  The real work is done by the 76-byte code segment
which is copied to that address.

   Upon return to DOS Ready, the 19,200-byte graphics video ram will have been
established as the ERAMDISK file GRAM/IMG and filled with nuls, and the high
priority background task which performs continuous graphics board refresh will
be installed and functioning. The graphics board will be in auto inc X on write
with text overlay mode.

   To verify the task is working, simply copy any /HR file to the image file
using the following syntax:

	COPY filename/HR GRAM/IMG (LRL=80)

   The (LRL=80) parameter is IMPORTANT!  Even though GRAM/IMG was CREATEd, and
is therefore never supposed to shrink, it *does* shrink if you omit the LRL=80
parameter.  Also, do not copy any file longer than 75 sectors, as this will
overwrite the task code and cause the system to crash.

   Because interupts are disabled during disk I/O, display cannot begin until
the COPY is completed, although, occasionally, if the timing is just right,
you'll see a couple of lines be displayed between sector or track reads done by
the COPY function, when the interupts are temporarily enabled.

   Unfortunately, there's a chance you won't see anything.  The hardware gurus
tell me this is because the HD64180's DREQ1 pin is left "floating," which means
DMAC1 transfers work on some machines and not on others.  This is the hardware
problem I mentioned which forced me to pull the XLR8er version of SLOTMOD4 off
the market.  The solution is to tie this pin to ground with a 150 ohm resistor.

   An interesting demonstration can be put together by building a JCL file to
display a number of /HR files in succession.  Using your draw-type program,
create one /HR file filled with nothing but black (BLANK/HR) and another with
nothing but white (WHITE/HR).  Then build your JCL file as follows:

	copy filename/hr gram/img (lrl=80)
	cls
	//delay 75
	copy white/hr gram/img (lrl=80)
	cls
	//delay 10
	:
	repeat the first six lines for each /HR file you wish to include in the
	"slide show," using actual file names instead of "filename," of course
	:
	copy blank/hr gram/img (lrl=80)
	//exit

   Then DO the JCL, stand back and watch.

   If you have any questions, comments, suggestions, complaints or whatever,
I can be contacted via CompuServe [72411,650], by phone [(804) 273-0937] or by
mail at 4108-C Fairlake Lane, Glen Allen, VA  23060.
