...... You find a girl to love, STEP TWO She falls in love with you, STEP THREE You kiss and hold her tightly, Well that sure, seems like Heaven, to me (WOP WOP WOO) ______________________________________________________________________ And if you don't know what all that is about, I suggest that you rush out immediately and buy a copy of Showaddywaddy's Greatest Hits! All that aside, however, this isn't going to teach you very much about coding the Amiga in 68000, is it? So, onto the meaty bit, and the definition of the first of the Monk's golden rules of coding. During the course of this series, we will be presenting a number of rules, which will always be highlighted in capital letters on a line of their own. These rules are meant to be adhered to, and if you follow them closely, you won't got far wrong! So, for the first time ever, here is the Monk's first golden rule of coding: RULE 1: WE DON'T USE THE OPERATING SYSTEM. (THIS IS NOT STRICTLY TRUE AS WE NEED TO USE IT TEMPORARILY TO GET AT CERTAIN THINGS, BUT WE DITCH IT AS SOON AS WE CAN, AND DON'T HAND IT BACK UNTIL WE ARE GOOD AND READY I.E. WHEN OUR PROGRAM HAS ENDED). Now then, that in itself is going to cause a few people to hold their heads in their hands in anguish. The Amiga's operating system is written so that it is easy to use and develop utilities upon, and for that purpose it is very good. We, however, want to write demos and mega-fast shoot-em-ups with zillions of bobs and sprites flying around the screen without a graphics glitch in sight. This is simply not possible when coding using the operating system routines, so we ditch it and hit the metal. Hard. Directly. Coding using the operating system is the 'proper' way of coding, and in the past there have been many interesting and lively discussions between rival groups of coders about what is the correct way of doing things. Once such debate appeared in one of the very early issues of Amiga Computing between Dave Parkinson (of the BBC Emulator fame as well as the Compunet Terminal Software), and Jez San (he of Starglider and Afterburner fame(!)). Dave was, and still is, a firm believer in coding using the O/S, whilst Jez lays heavily on the 'metal-bashers' side. The debate was, as all such discussions will be, inconclusive, but if anything did come out of it, it was that if you want to write super-fast stuff, the O/S isn't going to help you an awful lot. That being the case, we ditch it! Ok, we have laid down our hats, and know what we are going to do, the question is, how do we do it? This month's source code is by necessity a very simple piece of code which takes a 16 colour (four bitplane) lo-res screen (320x256), and fades it on, waits for a mouse click (left or right buttons) or the joystick fire button to be pressed, before fading off the picture and quitting the program. To demonstrate the use of this program, it is used as the loader to this disk. Due to memory restrictions on the disk, we are unable to store the picture on The Missionary, but it is fairly simple to include a picture of your own. To do this, use the following steps: 1. Draw a 16 colour 320x256 picture in DPAINT (or similar) - or pinch one from somewhere! - and save it to disk. 2. Using the PALETTE requester in DPAINT, copy down all the colours. You will have to convert them to hex, so for those of you who don't know hex or haven't got a calculator to do the conversions for you, here is a quick conversion table: DECIMAL HEX DECIMAL HEX 0 0 8 8 1 1 9 9 2 2 10 A 3 3 11 B 4 4 12 C 5 5 13 D 6 6 14 E 7 7 15 F So, let us say that your colour 0 (the background colour) is a rather putrid shade of pink the same as this disk. DPAINT would describe this as: R 15 G 11 B 15 but using our new conversion table we could convert this to FBF. Now, to tell the assembler that this is a hexadecimal number, we have to put a dollar sign in front of it, and to even it up, we will add a leading zero as well. So, our colour 0 in hex would look like this: $0FBF Do this for all sixteen colours, and write them all down (don't worry, there are FAR, FAR easier ways of saving out the colour information which we will show you soon, but as an introduction to hex and a quick way of getting your own pictures into a program, this isn't bad at all!) 3. Load up the IFF CONVERTER program which is in this directory. Using the right mouse button (RMB from now on), select the LOAD IFF option, and when prompted, type in the name of the DPAINT file which you have previously saved. Next, use RMB and go to the OTHER menu and select CMAP, and from that submenu select NO CMAP. This will save the picture without any additional colour information. Now, select SAVE BITMAP, and when the requester comes up, type in the name of the filename you wish to save the grafix to, and then click on the SAVE gadget (NOT frame & save!). The converter should then save the raw graphics file to disk. ______________________________________________________________________ INTERMISSION 1 - Graphics Formats A few years ago, those clever people at Electronic Arts decided to invent a new file format which would be standard to all Amiga applications (Commodore helped a little bit as well!). This standard is known as IFF (Interchangeable File Format), and the idea is that graphics (or sound and a few other bits and bobs) should be capable of being saved by one application and loaded by another. So, for instance, you should be able to save graphics using, say Deluxe Paint 3 and load them into Graphicraft or merge them into a DTP package or whatever. This is an excellent idea, and to give the guys at EA full credit, one which works very well. Without going into a lot of unnecessary technical detail, what actually happens is that as well as saving the actual graphics data (the 1's and 0's) that make up a picture, a lot of other data is stored as well, such as screen resolution, colours, number of bitplanes and all sorts of stuff. Unfortunately, when we code using the hardware, we have to do things the hard way, and we have to set up all the screen sizes, colours and everything ourselves, so when we load in a graphics file, we only want the actual data (what is known as the RAW data). What IFF CONVERTER does is take an IFF file, and strips off all the header details, and re-saves the file out as RAW data. To build up a picture, the Amiga stores data in BITPLANES. A 2-colour picture (i.e. foreground and background) can be represented by a single bitplane. Each time a bit is set, the foreground colour is shown, each time a bit is not set, the background colour is shown. If we increase the number of bitplanes to 2 and lay them on top of each other, then we have four possible combinations: Both bits clear = Show colour 0 Bottom bit set, Top bit clear = Show colour 1 Bottom bit clear, Top bit set = Show colour 2 Both bits set = Show colour 3 This can be shown more clearly as follows: SINGLE BITPLANE 00000000 00000000 Looking at the top-left bit, if this is 0 00000000 show colour 0, if it is 1, show colour 1 TWO BITPLANES 00000000 \ The two bitplanes are laid on top 0000000 of each other, so looking at the top bit only, there are four combinations: 1. 00000000 \ SHOW COLOUR 0 0000000 2. 10000000 \ SHOW COLOUR 1 00000000 3. 00000000 \ SHOW COLOUR 2 10000000 4. 10000000 \ SHOW COLOUR 3 10000000 By increasing the number of bitplanes even further, we can display more colours. A 3-bitplane picture has 8 colours because there are 8 combinations of 3 digits, and a 4-bitplane picture has sixteen colours as there are 16 combinations of 4 digits. Don't believe me? Well here they are: 0000 COLOUR 0 1000 COLOUR 8 0001 COLOUR 1 1001 COLOUR 9 0010 COLOUR 2 1010 COLOUR 10 0011 COLOUR 3 1011 COLOUR 11 0100 COLOUR 4 1100 COLOUR 12 0101 COLOUR 5 1101 COLOUR 13 0110 COLOUR 6 1110 COLOUR 14 0111 COLOUR 7 1111 COLOUR 15 The more observant among you will notice that this is simple binary arithmetic, and that the logical progression from this is 5 bitplanes which will give 32 colours. This is the usual maximum on the Amiga (although there are exceptions), but for now we will concentrate on 4-bitplane, 16 colour pictures. To re-cap, the number of colours used in a picture is determined by the number of bitplanes: 1 bitplane = 2 colours 2 bitplanes = 4 colours 3 bitplanes = 8 colours 4 bitplanes = 16 colours 5 bitplanes = 32 colours. In lo-res mode, we save a screen which is 320 pixels across by 256 lines down. There are 40 bytes across the screen, because a BYTE is 8 BITS ( a pixel is one bit), and so to store one bitplane of graphics for a lo-res screen, we require 40 x 256 bytes of memory = 10240 bytes As our picture is stored as 4 bitplanes, the total size of our file is 4 x 10240 = 40960 bytes. If we have converted our picture correctly, we should have stored a file on disk which is 40960 bytes long. To check this, if our file has been saved as "DF0:PICCY_WICCY", enter CLI and type: LIST DF0:PICCY_WICCY and a load of information should appear, one bit of which is the file size which should hopefully be 40960 bytes. If it is we are cooking on gas, if it isn't, you had better go back to the beginning and start again! If you don't like using CLI then use the excellent directory utility SID which by amazing coincidence can also be found on this disk! This, however, brings me onto the second of the Monk's golden rules, which is: RULE 2: REAL PROGRAMMERS DON'T NEED 'ARE YOU SURE?' REQUESTERS, AND AT LEAST KNOW WHAT THE CLI IS. Assuming that we have a file of the correct size, we can now carry on...... INTERMISSION TERMINATED ______________________________________________________________________ 4. Load up DEVPAC, and load in the source file contained on this disk (it would be wise to make a backup of it first and work on the backup, as replacement copies of The Missionary cost twenty pounds). At the very end of the source file is the label piccy: ;incbin "dh0:mm/piccy" DEVPAC uses the semi-colon as a comment, and so anything after it is ignored (the * is also used for the same purpose). Remove the semi- colon and in place of the "dh0:mm/piccy" type in the name of your own picture (the RAW version, remember!). So, if you picture is called ACEPIC and is stored in a directory called MEGAPIX on a disk in df1: you would end up with a line which said incbin "df1:megapix/acepic" The word INCBIN stands for INCLUDE BINARY FILE and is a directive to the assembler to copy in a binary file at this label. Our RAW graphics picture is a binary file. 5. We now have to copy our picture colours, and to do this, do the following. Go to the top of the source file and then select FIND using the RMB on the menu bar. When prompted, type in "normal_colours" and hit RETURN. You will be taken to a label in the source file called NORMAL_COLOURS. You should see the following: normal_colours: dc.w $0000,$0c73,$0976,$0a87,$0654,$0330,$0430,$0430 dc.w $0530,$0740,$0840,$0950,$0a51,$0a62,$0643,$0444 These sixteen WORDS are the data for the colours in The Missionary logo, and so what you must do is replace them with the colours you have copied down from the palette requester in DPAINT, starting with colour 0 ($0000 in our palette), and ending with colour 15 ($0444 in our palette). Don't forget to include the $ sign before each word. When you have done this, SAVE the source file to a blank disk under a new filename. 6. You are now ready to see the fruit of your creation, and the best way to do this is select the ASSEMBLE option, and assemble the program to memory. Make sure that the picture you have chosen to include is on a disk with the same pathname you have specified in your INCBIN command, otherwise the assembler will report a 'FILE NOT FOUND' error. Once the program has assembled correctly, you can RUN it from the menu using the RMB. Hopefully, if all has gone well, your new picture (with all the correct colours!) will fade onto the screen, and will then stay there until a mouse button is pressed of the fire button is pressed on the joystick, after which the picture will fade off and the program will quit leaving you in DEVPAC. 7. As I am not telepathic, if your program doesn't work, I am unable to tell you just exactly what is wrong. However, if you have checked everything and it still doesn't work, drop me a line and we will endeavour to get it sorted out. ______________________________________________________________________ THE PROGRAM - HOW DOES IT WORK? The program on this month's disk is, as we have already said, very simple, but it does introduce a number of very important concepts which will be invaluable in months to come. As an overview of what the program does, here is a rough sequential chart of the program's operation: 1. Define MACROS to be used later on. 2. Call the TAKESYS routine to kill the O/S. 3. Define the screen by copying the address of the bitplanes into the copperlist. 4. Enable the system DMA to allow the blitter to work, the screens to be displayed, sprites to be displayed and a custom copperlist to be written. 5. Set up a custom copperlist. 6. Set up a level 3 system interrupt. 7. Use a custom-written fade routine to fade a picture between any two palettes (no need to fade to black). 8. Wait for a mouse button or fire button to be pressed. 9. Again call the fade routine to fade the picture. 10. Safely hand back the O/S in such a way that anything that was running before we called our program will (hopefully!) still be running. Each month we will expand on different parts of the program, so that in a very short space of time we will be able to write our own custom routines such as those used in demos etc. Don't be afraid if you don't understand many (or any) of the terms used, you will soon get the hang of it. The main lesson we want to get across this month is the safe way of shutting down the operating system and then handing it back once we have finished our program. Luckily for us, we have two routines to do just that task for us, which makes life a lot simpler. The two routines are called TAKESYS and FREESYS and were written by GARION, and we would like to say thanks to him for allowing us to use them. If you study the listing carefully, you will see that we call TAKESYS at the very beginning of our program, and call FREESYS at the end to hand the O/S back to it's owner - the Amiga! You don't have to know exactly how they work, simply the general operation. Before we call these two routines, you might notice two strange instructions, CATCHVB and BLITWAIT. These are not normal 68000 instructions, but are MACROS, and stand respectively for "Catch the Vertical Blank" and "Wait for the Blitter to Finish Whatever it is Doing". ______________________________________________________________________ INTERMISSION 2 - MACROS A macro is a piece of code which is to be executed many times. It is usually a sequence of instructions that would normally appear many times in the code, but to save unnecessary typing etc., it is possible to define a macro to equal that sequence of instructions and assign a name to it. Thereafter, any time you type that name into the code, the assembler will insert the previously defined sequence of instructions when the code is assembled. Macros are very powerful beasties, and it is possible to do many things with them such as parameter passing so that the macro can act in different ways depending on what data is passed to it. We will go into this feature more at a later date. For the present, we will just be content to know that macros can be used to replace often called code with a single word. As an example, a piece of code to test if the blitter is still busy might be: BLITTER_CHECK: BTST #14,DMACONR(A5) BNE.S BLITTER_CHECK We can define a MACRO to do the same job like this: Blitwait MACRO bw_\@ btst #14,dmaconr(a5) bne.s bw_\@ ENDM (By writing the label as bw_\@, every time the macro is encountered in the code, a new label address is generated). Now, each time we want to wait for the blitter to be free, instead of having to type in that meaningless code (means nothing to me anyway!), we can just type BLITWAIT. Much easier, much friendlier, and much better to read. This brings us onto The Monk's third golden rule, which is: RULE 3: MACROS ARE GOOD BECAUSE THEY MAKE CODE EASIER TO READ. We will come back to MACROS in more detail at a later date. Intermission ended........ ______________________________________________________________________ What TAKESYS does, effectively, is to store the addresses of everything that the O/S is doing when it is called to shut down. It first calls the O/S routine FORBID which stops any other tasks interfering with what we are doing. It then goes through systematically storing the Operating System's copperlist addresses, the interrupt vectors and all sorts of other weird and wonderful stuff which has no relevance at the moment. It disables all interrupts and turns off the DMA and then returns control to our program. This now allows us to do as we wish, because the operating system can't interfere with us, and we can't harm anything. When our program has finished, we call FREESYS which does the exact opposite of TAKESYS by restoring all the O/S interrupt vectors and copperlist pointers before using the O/S routine PERMIT to re- enable the system. As I have already said, it is not necessary to understand exactly what TAKESYS and FREESYS do, only that they do it, and do it very well. Once TAKESYS has been invoked all the System DMA and Interrupts are off, and we are in a position to modify them as we see fit. That, as they say, will come at a later date! All that aside, however, both routines are sufficiently well documented, and it should not take too long to progress through them if you are interested enough. Anyway, I think that is about enough for this month, as we have covered quite a lot of ground so far. It is difficult to judge, especially in a new publication, just how far we should go, and whether we have left people behind, or not gone fast enough. If you do want to learn, let us know what you think, and how you would like us to progress, Without feedback, we will just carry on at this sort of pace. Anyway, next month we will be discussing custom copperlists and how to display screens. Until then........ Friar Tuck ______________________________________________________________________ EXERCISE 1. Elsewhere in this section is an article on loops in 68000. If you remember earlier on, I said that there were much easier ways to get colour information into your programs? Before we start the exercise, re-run IFF CONVERTER and load up your 16-colour DPAINT picture. This time, however, select the OTHER menu with the RMB, and on the CMAP sub-menu, select BEHIND BITMAP. Now, save the file as a bitmap, but with a different filename. If you now LIST the file, you will see that it is now 40992 bytes long. This is because it has added the colour data onto the end of the file. (40x256) x 4 = 40960 (16x2) + 40960 = 40992 because there are 16 colours, and each one takes up one WORD (2 bytes). Your task is to write a small addition to the program which will copy the colour data at the end of the graphics file to the label NORMAL_COLOURS where the colour information is stored. TIPS: 1. Use the loop technique. 2. The colour data starts at the address of the picture+40960 So, if the label you have loaded your picture at is PICCY (assuming that you haven't changed the label, to get the address of the first colour (colour 0) into register a0, you would use: lea piccy,a0 add.l #40960,a0 or, more efficiently, lea piccy+40960,a0 Ok, see how you do, a proper answer will be printed next issue. Detentions for uncompleted homework may be very severe, so be warned! *************************** END OF TEXT ******************************