COURS207.TXT
****************************************************************** * * * 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. We can take fonts as an example. Where are they located? With MONST, by wandering through memory, it will always be possible to find them. Unfortunately, they are not in the same place in all machines. This is not a problem, just go through line A. Indeed, function $A000 allows initialization but largely just provides us with addresses. Thanks to these, we can deduce many things (location of fonts among others). Again, it is preferable to go through DC.W $A000 and then make some shifts to find what interests us. The little joker who boasts of having found the hidden address that gives the fonts will soon realize that it does not work all the time whereas with line A, it's less flashy but it's reliable! For the use of line A, the description of functions in the Bible is sufficient. Start with rectangles, lines, place points where to ask for their colors, etc... Here is an example that was among the first I realized with line A: Displaying a small text in the top left (about 5 lines of 20 characters). Using a loop, ask for the color of the pixels, and recolor the pixels on the right of the screen so that the text appears vertically. As for determining the location of certain data thanks to a jump in the line A initialization addresses, the Bible is a bit silent on this while the Developer's Book by Micro-App is more informative. Last-minute advice: do a lot of exercises with line A and especially make yourself a library of Macros for its functions.
Back to ASM_Tutorial