We all know the quality of Atari
computers when it comes to graphics displays but many of the high
resolution geometric or graph drawing programs take quite a time
to create a screen, and artistic masterpieces are often unrepeatable.
It would be useful to store a completed screen for later recall
by saving the screen data directly so that the original program
is not needed to display the picture again. The recall must be fast
if it is to be effective. A high resolution screen (graphics 8)
takes 8138 bytes of memory so there is a lot of data to move - for
this sort of task Basic is far too slow.
CIO - FAST DATA TRANSFER
I am not a machine code programmer
and so was delighted to find that the Atari operating system includes
machine routines for the fast transfer of data. These reside in
a utility called Central Input/Output (CIO) which is used for all
data transfer processes such as program load/save or output to screen
or printer. The use of this general purpose device for data transfer
routines was well described in Analog Computing No.13 (Sept/Oct
1983), by Richard Groszkiewicz and his article gave clear advice
on how to use the CIO from basic. I will restrict this article to
the specific use of CIO for screen data dumps to disk and for the
SLIDESHOW program which will display a sequence of saved pictures.
IOCBs
Before using CIO utilities some
preparation must be made. This consists of setting various parameters
in the Input/Output Control Blocks (IOCBs). There are 8 IOCBs of
which IOCB #0 is normally used for the screen editor (E:), IOCB
#6 is normally used for graphics screen display (S:) and IOCB #7
is normally used for LPRINT, LOAD and SAVE routines. We will use
IOCB #1 for our screen data transfers. Each IOCB occupies 16 bytes
with IOCB #0 starting at memory location 832, IOCB #1 at 848 and
so on. The IOCB can be set up from basic by POKEs to the required
memory locations. For our purposes the important memory locations
are:
| IOCB+2 |
Must contain 7 for Get or 11
for Put routines |
| IOCB+4 |
Low byte of the starting address
in memory from/to which you will transfer data |
| IOCB+5 |
High byte of address location |
| IOCB+8 |
Low byte of the number of bytes
of data you wish to transfer |
| IOCB+9 |
High byte of the number of
bytes to be transferred. |
This will become clearer as we
go through the first program.
CIODUMP
The first listing, CIODUMP, is
a short program which may be appended to a graphics program to dump
the resulting screen data to disk. This data will be in the correct
format to be used by the SLIDESHOW program later. A brief description
follows:
The first set of REMs are inserted
to give a reminder that this program will not work alone. It has
to be appended to a program which generates the picture to be saved.
The graphics program must dimension a string F$ and give a name
for the file to which the picture data will be stored such as D:MYPIC.PIC.
The .PIC extender is recognised by the SLIDESHOW program. Choose
a file name that is not in use already or the new data will overwrite
the old.
Line 5000 selects IOCB #1 and
opens it to Put data.
Line 5020 saves the graphics mode
of the current screen to disk file F$
Line 5040 saves the colour register
values.
Lines 5050 to 5070 work out the
start of screen memory (DLIST) and the number of bytes to transfer
(NUMBER)
Lines 5090 to 5160 find the starting
address of the IOCB. Poke 11 into IOCB+2 (for a Put operation) then
split DLIST and NUMBER into high and low bytes and poke the resulting
values into the correct IOCB registers.
Line 5170 calls the CIO routine
- the short string "h-h-h- inverse *-L-V-inverse d" is a machine
code routine which calls CIO.
SLIDESHOW
The second program SLIDESHOW is
a program which will display all the picture files on a disk. All
that is needed is to ensure that the files have a .PIC extender.
Lines 30 to 60 retrieve all file
names with a .PIC extender from the disk and load them into a string
B$.
Line 70 branches to 230 if no
picture files are found.
Lines 80 to 110 get a file name
(A$) from B$ and ensure it is in the right format for use with the
OPEN command in Line 20 (i.e. D:FILE.PIC)
Lines 120 to 210 are very similar
to the CIODUMP routine - note the POKE IOCB+2,7 in line 160 for
a Get routine.
Line 130 is there to ensure that
there is no text window in the display and to allow each picture
to overwrite the previous one. If you prefer to switch one picture
off before loading the next delete line 132. This is usually better
when a disk with several pictures in different graphics modes is
being displayed - some odd effects are generated when the graphics
mode is changed while the picture data is retained.
Line 220 displays the picture for
a short time before returning to 90 for another file. The POKE 77,0
is to stop the display going into attract mode if the program is
left to repeat for a long time.
MEMORY USE
These programs will handle all
graphic modes and even mixed mode screens as the display list is
saved as well as the screen data - but you will soon realise that
the various modes take up very different amounts of space. The adage
that one picture is worth a thousand words is borne out by the relative
amounts of data required to store them! The space taken up on a
disk by each mode is shown in the table:
|
Graphic Mode
|
Disk Sectors
|
|
0
|
9
|
|
1
|
6
|
|
2
|
4
|
|
3
|
4
|
|
4
|
6
|
|
5
|
10
|
|
6
|
18
|
|
7
|
34
|
|
8 and over
|
66
|
High resolution screens soon fill
up a disk but you can give impact to your slideshow by interleaving
pages of Graphics 1 or Graphics 2 text. They load very fast and
can be used to commentate on the pictures.
FURTHER DEVELOPMENT
There are some obvious enhancements
which can be made to these programs which would improve them - for
instance how about using a memory saving algorithm to compact the
screen memory before saving it, or adding a screen dump so that
hard copy of the pictures can be made at any time? I would be pleased
to hear from anyone who works out improvements to the programs.
I will send a copy of the programs
with a set of demonstration graphics to anyone who sends me a disk
and return postage, (and your address clearly written!) and would
also like to build up a library of graphics on disk if any of you
with stunning displays would send me a copy - I will send your disk
back!!
My address is:
Ian Finlayson,
60 Roundstone Crescent,
E.Preston,
W .SUSSEX BN16 1DQ
top
