ç~T01~C07Introduction to the Amiga Operating Systemà ~C02by Poison ~C03\\I know that you demo programmers don't consider the operating system as important code and throw it out of the RAM as fast as possible. But, believe it or not, what hides inside the ROMS is the most advanced and open operating system of all 16 and 32-bit microcomputers. This articles series that will be published in Outlaw and starting with this one intend to explain the structure of this wonderful operating system, called Kickstart by its original developers (Metacomco), and show the use of its relevant parts and functions. Improvements of releases 2.04 and 3.0 will be signalled and covered. All these goodies will obviously require some knowledge of programming to be fully understood. ç~C05Exec insideà \\~C02The Kickstart can be considered a bit like a building. It's seperated into different levels, linked but quite independent. The roof is the user interface, what you users can see of the operating system work. But it's as always the lower level which does the capital job. This level, the foundations for our example, has been given by its developer the name ''Exec''. You all know this name, but maybe not what lies behind. Exec handles all low-level commands needed by the rest of the operating system. It allocates, deallocates, add, removes, freezes, wakes up... It's also the first interface with hardware, and the first program called upon cold/warm boot. ç~C04At the beginning were the listsà \\~C01Exec, and therefore the whole system, handles any information through lists and nodes. This is capital to understand for programming the Kickstart, but is fortunately very simple\: to store a list of informations, the first solution that you may think of is a simple array. But the problem of any array is that once you have set its size you cannot change it anymore. For example, the thing that looks like a workbench on the Atari ST can't open more than four windows (if I remember well) in the same time, simply because there must be an array of windows with space for four, not more. All right, you could increase the size of the array to remember e.g. 1000 windows, but it would take lots of memory\! Instead of this dusty method, Exec developers decided to use a method that permits to add or remove any number of elements, anytime. That method is called a list\: every element in the list keeps a pointer on the next one and eventually the previous one. You can then add or remove elements at start, at end, in the middle of the list by simply changing these pointers, there is no limit except the memory itself\! Exec handles utterly everything witht hese lists\: tasks, memory, messages... Therefore a standard format has been implemented to describe every element for any kind of list. This is a kind of ''header'' that you must stick before any element and which keeps\: a pointer on the next element and a pointer on the previous one (if required), as lists need it, but also the type of element (that can be a memory zone, a task, a message, a port, etc.), the priority of the element if required, and its name. This standard structure is called a node. This node is then followed by the element itself. I repeat it, the whole system is based on this double concept of lists and nodes. ç~C06Multitask and meaning of lifeà \\~C02Among the stuff handled by Exec, one of the most important is obviously the tasks. Exec is as everybody knows a multitask kernal. Better, let's say that it is able to share the processor time between different programs, giving the illusion that they run in the same time. The whole system is thinked from this multitask idea. Running in the same time programs created by different persons is a problem, and there we see the drawback of any multitask system\: sharing the resources of the machine. It's because of this that f.ex. you can NOT choose the location of your program in memory, because someone could perfectly use the same location as you and.. crash\! To minimize user's work, the developers have given Exec and the other parts of system the right to handle resources (that means hardware). User will then use the system functions that share everything automatically. Following this idea, the different system layers can be put into three different classes\: the libraries, sets of functions available for all tasks in the same time, and grouped together by theme (e.g. graphic functions, I/O functions...), the devices, interfaces with specific hardware (e.g. diskdrives, printer...), and the resources, kind of protocol that enable you to use a part of the hardware directly (e.g. parallel port) but you should have good reasons (specific transmission protocol\?). As these three classes are handled through lists, it is possible to add any library or device (resource is a bit harder, don't ask me why) from disk, you know it. But the Kickstart already keeps in its ROM (since v36 (2.0), it is a 512K ROM located at adresses $F80000-$FFFFFF). The way the ROM is assembled is also very particular - if you have hardware to burn new ROMS it is almost possible to add your libs etc. directly in ROM by just sticking it after the others - as all system levels (libraries, devices, resources) are seperated and kept into ''ROM-modules'', that are explicitely 'hunt' and initialized in RAM when the machine starts. ç~C05The boot processà \\~C01Maybe is it good here to remember or explain you the way a cold boot (switch on) or warm boot (reset, slightly different) is performed on the Amiga\: when you switch on, the chips wait to be ready to work, and then is the OVL* (memory overlay) line on the processor bus set, putting an image of the ROM at adresses $0-$7FFFF, replacing partly or totally the chip-ram. The 680x0, as it would do on any other computer based on it, warps in supervisor mode, trace off, no interrupts, then loads its stack pointer with the longword kept at address $0, loads its program counter with the longword kept at address $4 and begins executing instructions. On the Amiga, the overlay has actually made the 680x0 to read adresses $F80000 and $F80004, or $FC0000/$FC0004 on pre-2.0 256KB ROMS (for the rest of the explanation I will continue with $F8xxxx, please translate the adresses yourself for these ROMs). Adress $F80004 makes the processor reach address $F800D2, start point of Exec, and by the way, of the reset routine. Memory overlay is then removed (chip ram comes back at $0), chipram size is checked, ''expansion'' -another system level which configures the machine- is built into this chipram to check and initialize all machine hardware, and when done, Exec builds itself into public memory. After that, the multitask begins (so early\!) then all ''ROM-modules'' are hunt in ROM and RAM and initialized. Here comes the complete list of these ROM-modules kept in v39 ROM, in order of priority (the higher the priority of a module is, the earlier this element is brought to life upon booting, and generally, the lower level in system it is)\: Start Init Pri Ver Type Name 00F83704 00F837D8 110 39 Library expansion.library 00F800B6 00F80444 105 39 Library exec.library 00F8371E 00F83AB8 105 39 Program diag init * 00F85A34 00F85A78 103 39 Library utility.library * 00FCD35C 00FCD39C 100 37 Resource potgo.resource 00F8E93C 00F8E9A4 80 39 Resource cia.resource 00F9EECC 00F9EF64 80 39 Resource FileSystem.resource * 00F8C600 00F8C68A 70 39 Resource battclock.resource * 00F95164 00F95190 70 37 Resource disk.resource 00FC3E68 00FC3EA8 70 37 Resource misc.resource 00F8CF68 00F8CFEC 69 39 Resource battmem.resource * 00FA4F78 00FA4FBE 65 39 Library graphics.library 00FC0C84 00FC0C9E 64 39 Library layers.library 00FC67F8 00FC6812 60 37 Device gameport.device 00F84174 00F841F2 50 39 Device timer.device 00F8A9E8 00F8AAF0 48 37 Resource card.resource * 00FC6822 00FC683C 45 37 Device keyboard.device 00FC0008 00FC00DE 40 37 Library keymap.library * 00FC684C 00FC6866 40 37 Device input.device 00F85440 00F8545A 25 39 Device ramdrive.device 00FCD494 00FCD7FA 20 39 Device trackdisk.device 00F8A070 00F8A1D4 15 37 Device carddisk.device * 00F87780 00F877C2 10 37 Device scsi.device 00FCF1D8 00FCF1F2 10 39 Library intuition.library 00F914C4 00F914DE 5 39 Device console.device 00F86530 00F8659A 0 37 Library mathieeesingbas.library 00F8D18C 00F8E310 -35 39 Program syscheck * 00FCC434 00FCC498 -40 39 Program romboot 00F8D14C 00F8E398 -50 39 Program bootmenu * 00FCC44E 00FCC6B8 -60 39 Program strap * : didn't exist on pre-2.0 Roms (1.2/1.3) Note that exec has a lower priority than expansion because, even if it is the first module to be called, it is installed only when expansion has listed all the available memory, so that exec can build itself in expansion memory (e.g. $200000). That works like this since v37 (2.04) kickstart (before exec was built in chipmem when no A500 fake-fastram was present\!) Note also that modules showing 'program' type are system routines called once by the boot process (e.g. the boot menu) and then forgot and never installed in memory unlike libraries, devices and resources. On this article series will we follow the order set by the developers. If you prefer, we will study the system levels in the same order of priority has the one described with the previous list. That means we will go from the lowest levels to the highest.. Well, that seems logical. ç~C05I will be backà \\~C01This article intented to be really general and I think it is quite, don't hesitate anyway to write me your feelings about this. On next issue we will start the real job, with a deeper jump into Exec. But for now I let you read this article four-five times again to try to understand, or, I don't know, beat your sister, turn your tape, answer your mom, do your homework... Ok, c u in issue 3... Poison.