******************************************************************
* *
* 68000 ASSEMBLER COURSE ON ATARI ST *
* *
* by The Fierce Rabbit (from 44E) *
* *
* Second series *
* *
* Lesson number 7 *
******************************************************************
There's no need to flatter yourselves needlessly, but if you have been
following the lessons from the beginning calmly, and if you have made sure
to practice with small applications, you should already have a decent level
in assembler! Therefore, do not forget the main commandments: comment your
programs well, think simply, use paper and pencil etc... As you progress,
your listings will be longer, and clean programming will become essential!!!
Similarly, try to figure things out on your own before asking questions,
this will often save asking just anything...
In this lesson as well as in the following two, we will tackle two taboo
subjects: Line A and GEM.
Regarding these two subjects, criticism is common: Line A is not easy, it's
useless and GEM, yuck!!! After spending quite some time discussing and
listening to the opinions of several people, I have come to the following
conclusion: First off, the critics are rarely Line A or GEM programmers.
Secondly, let's imagine for a moment our ST without GEM and prepare ourselves
to make an effort, GEM is well rewarding! Lastly, I would say that these
lessons are meant to make you programmers, not tinkerers. You must therefore
be aware of the possibilities of Line A and those of GEM. However, do not
think that these courses will cover all GEM commands. The intention of these
courses is to lift a corner of the veil and, if possible, to provide you
with the means to continue your research.
In any case, I can assure you that Line A and GEM are no harder than
anything else (Besides, is there anything hard in assembler?????). There is
also a significant advantage concerning Line A and especially GEM: until
now, we have used 68000 assembler instructions, and it seemed evident
that in a book on PASCAL, BASIC GFA, or C, we would have been hard-pressed
to find details on the MOVEM.L instruction, for example! Concerning Line A,
but especially GEM, we will mainly use macros (you see why this subject
was tackled earlier!). Each of these macros has a name, and this name is a
'GEM' name and not related to any particular assembler!! Thus, opening a
window to show it on the screen will be done with a macro named WIND_OPEN.
The advantage is that this GEM function is used in Pascal, C etc... For
this reason, you can look for documentation on GEM regardless of the language
used in it. In 99% of cases, it will be C.
Personally, my knowledge of C is limited, yet a large part of the GEM
documents I work with refer to this language. Above all do not be satisfied
with works dealing with GEM in assembler because you will soon be disgusted!!
The same principle applies to Line A, the necessary parameters do not depend
on the language!!
Another very important advantage, especially for GEM, concerns data formats.
Being able to work on Macs, many things there make manipulating programs
easier than on ST. For example, you load a drawing software, do a little
doodle, then load any word processor and voila, you paste our doodle into it.
On ST there is a 99% chance that the format of one will not be recognized by
the other! If we take a look at the PC world, we realize that there is no
standardized format for this type of machine, and it is chaos at this level.
Such standardized formats exist on Mac, they are respected, and the rare
software not complying with this standard is doomed to a quick disk formatting!!!
Ironically, such format standards exist on ST, but they are not respected....
In fact, using Line A and especially GEM, should lead us to a broader
reflection on what programming is. Raymond Loewy (1893-1986), who can be
considered as the father of industrial design, had many thoughts on what
should be offered to the consumer. In our language, we talk about software
users, but it's actually the same person we're talking about. Let's compare
a Mac software and an ST software. The screen is on, the software is loaded,
and all we do is move our eyes over the icons and the mouse in the menu bar.
Difficult to judge the respective qualities of the 2 softwares without going
further. Yet, the simple arrangement of the entries in the menus, the
positioning of the icons, the small number of these but at the same time their
impression of clarity gives in 99% of the cases the advantage to the Mac
Intosh. On the ST, the menus are overflowing everywhere (especially in recent
software), and the icons cover a desktop that does not ask for so much! This
is related to a reflection of Raymond Loewy that I ask you to ponder: "An
aerodynamic vehicle well designed gives an impression of speed, even when it
is stopped". So there's no need to add more at will, the 14524874 functions
of the ST software is simply programmers' delirium, while the 20 functions
of the Mac software have been thought out for the user. When Raymond Loewy
was asked to create the new Shell company logo, as well as design the gas
stations, he simply told his employers: "Your clients are not the automobiles,
they are the motorists". Obviously, except that at the time Shell was selling
to automobiles, without realizing it!
Well, on ST, programmers program for the ST (or for themselves!) but very
rarely for the users...
Having said all this, we will now tackle Line A, hoping however that this
will make you reflect when you design your programs!
LINE A
Official Atari Doc, Line A Chapter: Good description of the different
functions, quite raw but effective.
ST Bible: Good description of functions Developer's Book: same, but also
describing the data from which the location with Line A can be deduced.
GFA 3.00 Doc: Quite strange. Although the GFA Line A functions are called
the same way as in assembler, the designer of this language managed to
'invent' functions claiming loud and clear that they are Line A functions!!!
Maybe so the GFA is even less compatible... On this note, it seems that
Line A is no longer officially supported by the TT.... To be seen...
In the first kilo of memory of our machine, we have a good packet of
addresses used by the microprocessor. We spent quite some time going through
the principle of operation of this kilo, which serves the 68000 as a 'relay'
to find the address of the routine it must execute for such and such a reason.
I hope with all my heart that you have perfectly assimilated this principle
because for Line A, GEM, interruptions etc... it is again and always this
same principle that is applied! Take the sheet that was provided with the
series 1 courses, which shows this first kilo. Vector 10 (address 40 in
decimal and $28 in hex.) has as 'description': emulator 1010 line. Let's
convert 1010 to hexadecimal, we get.... $A! First observation, if this vector
is in the first kilo of memory, it's then an emulator Line A is not a
feature of the ST but well of the 68000. These vectors will give us access
to one or more routines, by always using the same principle:
Order to the 68000, it analyzes the order, jumps into the first kilo of
memory at the address corresponding to this order, finds there the address
of the routine to execute, then all it has to do is to jump to it.
So how to call the routines accessible by the Line A emulator, what do these
routines do, and how to 'talk' with them, meaning how to pass any
parameters to them?
In the case of the Atari ST, the routines accessible through the Line A
emulator are basic graphic routines. These routines are the basic graphics
routines of our machine. They are used by GEM. Their access is crude and
inconvenient but convenience is not the sought goal. Generally in assembler
you often try to make your own routines (it's always better than those of
friends) However, it should be noted that in many cases, a good use of Line
A or Gem is amply sufficient. Moreover, it's often a good knowledge of these
interfaces that will allow you to improve your routines. Another additional
reason lies in the ease of implementation and the ease of improvement. It's
quite possible that the company for which you created a software, asks for
the version 2.00 several years after version 1.00. The nasty patches to save
3 clock cycles will then seem much less clear than a classic call to Line A,
perhaps a bit slower. But here again, we must think while putting ourselves
in the user's shoes! Thus SPECTRUM 512 is an excellent software thought with
a programmer mindset and the result is that everyone uses DEGAS...
The Line A routines are thus basic graphic routines. There are 16 of them,
numbered from 0 to 15. Here are their functions by number:
0 = initialization
1 = set a pixel to a given color
2 = ask for the color of a pixel
3 = draw any line
4 = draw a horizontal line
5 = draw a filled rectangle
6 = fill a line of a polygon
7 = transfer a block of bits
8 = transfer a character matrix
9 = show the mouse
10 = hide the mouse
11 = transform the shape of the mouse
12 = erase sprite
13 = display sprite
14 = copy area (FDB)
15 = fill area
We have answered the first question: "what does it do?" We can move on
to the next one: "how is it called?" A Line A call is made with a word.
The least significant byte of this word contains the function number,
and the most significant byte is equivalent to $A (hence the name Line A).
Thus, to call function 3, we will use the word $A003. But where to place
it? Well, simply in our program! To be able to mark it as such, we will
precede it with DC.W so that DEVPACK does not try to transform this into
68000 code since no mnemonic corresponds to this number! To call function
1 of Line A we will therefore put in our program:
DC.W $A001
Note: if you are interested, you can follow the Line A calls in the same
way as the Trap calls, under MONST, at least if you have one of the latest
versions of MONST.
Next question: how to pass parameters. Indeed, if for example, we want to
use function 2 to know the color of a pixel, we will have to provide its
coordinates. We saw with Gemdos, Bios, and Xbios that parameters were
passed through the stack. We also used this principle in our own routines.
Stacking, jump to the routine (by BSR or TRAP) then stack correction.
Regarding Line A and GEM, the stack is not used. Indeed, Line A and GEM
use a table system. We have studied arrays and we saw how to read in them.
Well, it is a bit of this principle that will be used. The parameters,
sometimes very numerous, will be placed in one or more tables, at specific
places, before the call of the chosen function. It will then look for the
necessary parameters and then return its results also in tables. The
advantage of the macro system becomes evident: if for Gemdos, Bios, and
Xbios calls it suffices to stack (the number of parameters is not enormous
and the principle and always the same), however, it takes a hefty dose of
memory to remember in which table and above all where in this table the
parameters must be placed for each function. Unfortunately, there are no
macros for Line A in the Devpack library. We will therefore detailed some
functions 'by hand'. Given that you have the course on macros at hand, I
can only recommend you make the corresponding macros for these functions.
We will first draw a rectangle on the screen. See listing number 5.
First of all, inclusion of the program startup routine, a small presentation
message while clearing the screen on the way. Then initialization of Line A.
Upon return, we have in A0 the address of the table that we will fill with
parameters. These are quite numerous and must be passed to specific
places. Some require a brief explanation: Clipping. It's a useful system
that we'll find in GEM. For example, we want to display on the screen an
image but it should only appear within a small rectangle. We will therefore
have to complicate ourselves seriously to not display the whole image. Instead
of that we can use clipping. This will consist in giving the coordinates of
the rectangle within which we want the image to appear, and to say that it is
the clipping rectangle. Then it remains to display the image over the entire
screen and it will appear only in the rectangle, the rest of the screen being
'clipped'. Again, it is quite clear that this slows down the display, we have
indeed displayed a whole image to only see a piece of it, and moreover the
system had to test constantly to see if it had to show us this pixel, then
the other etc... Nevertheless, this method is super useful and we will see
it many times.
The display type. It is a descriptor allowing to know how the display
will be made. 0= replacement mode, 1=transparent mode, 2=XOR mode,
3=transparent reverse mode. Try to make a second rectangle that overlaps and
observe the result by varying the modes.
We will now use another function, which asks for the color of a pixel. In the
case of drawing a rectangle, we used the table whose address was in A0 to
pass the parameters. For the color request of a pixel and for the coloring of
a pixel, we will use other tables. So pay attention to the tables that we
will describe now because they are also used by GEM? We will therefore be
killing two birds with one stone!!!!
Like GEM, Line A uses arrays intended to receive or give back different
things. The first table is the CONTRL (Control) table. It receives the
function number and a few other parameters. The second is the INT_IN table.
This means Integer In, so it's a table that will receive integers (an integer
is an integer in English). The third table is PTSIN (Points In). It's a
table intended to receive the coordinates of points or dimensions. Let's say
this table will receive, for example, the X and Y coordinates for the center of
a circle, but also its radius. There is some confusion in the explanations
about this table. Indeed it receives among other things coordinates, which
often go by couple (X and necessarily Y), which means that often it is said,
for example, "one piece of data must be put in PTSIN" when in fact a couple
has to be put! The fourth table is INTOUT. It's the same as INT_IN except
it's for output, for results. You can guess now, the last table, it's PTSOUT!!!!
Let's now take a look at listing number 6. A little reflection and it should
not pose any problem to you. However, try to redo this listing with loops
because with a single pixel coloring, of course, it's a bit limited... Just
one thing, try to well imagine what happens with the tables Contrl, Int_in,
Ptsin, Intout and Ptsout because in the next chapter there will be many of
them.....
Well now that you know how to draw a rectangle, you can also draw lines,
place points or ask for their colors etc... The most delicate function I
believe is the one that serves for text display. It allows for quite
interesting effects (writing with different styles).
To now use Line A, refer to the function descriptions in the Bible and try!
However, a remark: with GEM and Line A we tackle in a way the multi-user/
multi-machine concept. Indeed, GEM uses Line A a lot and therefore shares
the tables with it. However, your software may very well be in the process
of drawing beautiful rectangles when it occurs to the user to move his mouse
into the drop-down menu... Call to GEM, modification of the tables shared by
GEM and Line A, and upon return, goodbye rectangles...
There again caution and reflection to put ourselves in the user's place...
Second remark, the addresses provided by Line A.
Let's take for example the fonts. Where are they? With MONST, by wandering
in memory, it will always be possible to find them. Unfortunately, they are
not in the same place on all machines. It doesn't matter, simply go through
Line A. Indeed, function $A000 allows to initialize but largely it only
provides us with addresses. Thanks to them, we can deduce many things
(including the location of the fonts). Yet again, it's best to go through
DC.W $A000 then make shifts to find what interests us. The little guy who
brags about having found the hidden address that gives the fonts will
quickly realize that it does not always work while with Line A, it's less