Uniwersytet Ślaski
˛ w Katowicach
Wydział Matematyki, Fizyki i Chemii
Zbigniew Trzcionkowski
AmigaOS – internal structure of operating
system
Praca licencjacka
Promotor: dr Joachim J. Włodarz
Jastrz˛ebie Zdrój, 2004
Contents
1
Introduction
6
2
Hardware – technical conditions
2.1 Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Specialised chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Input/output devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
9
9
3
Brief history of AmigaOS
3.1 History . . . . . . . . . . . . . .
3.2 BCPL, C and asembler languages
3.2.1 Asembler . . . . . . . . .
3.2.2 C . . . . . . . . . . . . .
3.2.3 BCPL . . . . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Structure and working of AmigaOS
4.1 What is in ROM? . . . . . . . . . . . . . . . . .
4.2 Lists and libraries . . . . . . . . . . . . . . . . .
4.2.1 The exec library . . . . . . . . . . . . .
4.3 How Amiga scheduler does work . . . . . . . . .
4.3.1 Interrupts . . . . . . . . . . . . . . . . .
4.3.2 Guru meditation . . . . . . . . . . . . .
4.3.3 Structure describing task . . . . . . . . .
4.4 AmigaOS initialisation . . . . . . . . . . . . . .
4.4.1 What could do Kickstart ROM itself . . .
4.4.2 graphics.library . . . . . . . . . . . . . .
4.4.3 Contact with user (intuition.library) . . .
4.4.4 Packets, ports, messages... . . . . . . . .
4.4.5 devices, handlers . . . . . . . . . . . . .
4.5 AmigaDOS . . . . . . . . . . . . . . . . . . . .
4.5.1 Krótka charakterystyka . . . . . . . . . .
4.5.2 Command examples . . . . . . . . . . .
4.5.3 The startup-sequence file . . . . . . . . .
4.5.4 How does it look like inside . . . . . . .
4.5.5 Structure of executable files in AmigaOS
4.5.6 The Process structure . . . . . . . . . . .
4.6 Amiga Workbench . . . . . . . . . . . . . . . .
4.6.1 Characteristic features . . . . . . . . . .
4.6.2 Preferences and commodities . . . . . .
4.6.3 WBStartup . . . . . . . . . . . . . . . .
4.7 Attempts to modernise . . . . . . . . . . . . . .
4.8 Interesting solution in AmigaOS . . . . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
12
12
12
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
13
13
14
16
16
18
18
19
20
20
21
22
22
23
24
26
26
27
29
29
29
30
31
32
4.8.1
4.8.2
4.8.3
4.8.4
4.8.5
4.8.6
4.8.7
4.8.8
4.8.9
5
Ram Disk - virtual disk . . . . . . .
RAD - resetproof virtual disk . . .
xpk and xfd libraries . . . . . . . .
xadmaster.library . . . . . . . . . .
translator.library, voice.library . . .
Locale – wieloj˛ezyczność . . . . .
Datatypes – multiformat capability .
ARexx Language . . . . . . . . . .
Installer script . . . . . . . . . . . .
Conclusions
5.1 Real resons of Amiga fall . .
5.2 What is good in AmigaOS .
5.3 What is wrong in AmigaOS .
5.4 Summary . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
32
34
35
35
36
36
38
.
.
.
.
40
40
40
40
41
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
Software Failure Alert . . . . . . . . . . . . . . .
List of tasks in Scout . . . . . . . . . . . . . . . .
Boot Menu . . . . . . . . . . . . . . . . . . . . .
Example of graphical interface based on intuition .
AmigaDOS – console window . . . . . . . . . . .
User-startup file in CED editor . . . . . . . . . . .
Example of use WBPattern and Time programs . .
Exchange program – managing other Commodities
Screen of PowerPacker program . . . . . . . . . .
Screen of StoneCracker program . . . . . . . . . .
Multiview called from console . . . . . . . . . . .
Example of installation script . . . . . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
18
19
21
22
25
29
30
33
33
36
38
Sorry for low quality of the translation.
Author
5
1
Introduction
The main aim of that work is to explain operating system of Amiga. I tried to objectively
explain facts concerning system and computer which is quite controversional. Some people keep
Amiga as subject of cult where popularly is Amiga is known as trendy toy from the past.
Additional aim was to illustrate internal structure and working of multitasking operating
system. To achive that I did analyse of structure of systems elements that are in most cases
unavailable for programmers and has no documentation in developper stuffs.
In a separate chapter I have presented interesting, sometimes unique soultions we can see
in AmigaOS. Some of them like xad library has no comparable in qulity equivalent on other
platforms.
I paid special attention for problems caused by commercial character of the operating system
(even so opened as AmigaOS).
I concentrated on explanation of pure AmigaOS witch special stress on versions 2.0 and
newer. Earlier versions were weakly supported even by Amiga users themselves – 97% of games
from the A500 times refer directly to hardware.
In work I assumed elementary knowledge about operating systems and used self-explanatory
conventions. For instance OS2.0+ means system in version 2.0 or newer. Acronymes were
explained in place of the first appearance.
Contrary to most of modern operating systems AmigaOS is heavily connected with hardware.
Currently computers and system explained in this work are called Classic line.
6
2
Hardware – technical conditions
Average owner of A500 model even didn’t know he has multitasking operating system, therefore the biggest fans of AmigaOS we can find among users of so called professional models
and people who could afford to expand lower models. Primarily we have to see how Amiga does
look like seen as the hardware.
2.1 Processors
Construction of the Amiga computers is based on 680x0 processors family from Motorola
company. All procesors have following features:
• CISC(Complex Instruction Set Computer) architecture – wide set of instructions including
such interesting ones as operations on single bits.
• internally 32-bit architecture
• eight 32-bit universal data registers (d0-d7). Use of the registers is not limited for special
instructions like in processors of x86 family and similar.
• eight 32-bit universal address registers (a0-a7). The a7 register is intended to be stack
poiner.
• support for multitasking – 680x0 processors since the beginning were designed for multitasking environments hece two modes of work: supervisor mode intended for operating
system and user mode for applications. SSP and USP registers contain poiners for supervisor and user stack pointers. Depending on current mode one of them is visible as address
register a7.
• senseful instruction format
instruction.size source,destination
Operations could have 8, 16 or 32 bit size, what corresponds to types: BYTE, WORD and
LONG.
• good interpretation of data – byte is seen in lower 8 bits of register, word in lower 16 bits.
Long word is remembered as full 32 bits of data and there is no intel-like ”mixation”.
• plenty of addressing modes which can be almost freely mixed together. All available
modes are well thinked and useful.
Manual example of 68020+ processor abilities is:
move.l ([4,a1,d3.w*8],10),([10,a1,d2.l*2],44)
7
This instruction is interpreted by the processor as: move long word from address 4 plus
content of a1 plus d3 (lower 16 bits) muliplied by 8 and plus 10 to memory at addres 10
plus content of a1 plus double content of d2 (full 32 bits) and plus 44. We can clearly see
how great abilities has assembler of 680x0 family of processors.
Historically most meaningful enhancements in processors of 680x0 family:
• 68000 and 68010 have 16-bit data bus,
• 68010 has VBR (Vector Base Register) which let for keeping of interrupt vectors table at
other address than 0
• 68020 has 256 bytes of instruction cache memory and is 100% 32-bit
• 68030 has 256 bajtów byte long caches for data and instructions and built in MMU (Memory Management Unit) which is required for virtual memory handling or launching Unix
systems (e.g. NetBSD, Debian68k)
• 68040 and 68060 has 4KB of caches for instructions and data and built in FPU(Floating
Point Unit) compatible with external 68882 chip.
In Amiga computers we can see all procesors of the family:
• 68000 – in A1000, A500, A2000, A500+, CDTV, A600
• 68010 – in turbo boards to models above
• 68020 – in A1200, CD32
• 68030 – in A3000, A4000 and turbo boards
• 68040 – in A4000 and turbo boards
• 68060 – in turbo boards
• additionally processors 68020 and 68030 are often acompanied with arithmetic coprocessors of 68881 or 68882 type.
In case of Amiga boards with better processor or additional memory we always very popular
and are called turbo boards.
Lack of processors with MMU in typical models suggests that AmigaOS doesn’t provide
resource protection neither virutal memory... It is true what caused amateur use of MMU done
beside system. It let to use MMU only in limited way for: virtual memory systems, debuggers
and for mapping ROM. Situation was complicated due to diffent philosophy of MMU handling
in 68030 and 68040/68060 processors. It got standarised and ”highlevelised” with mmu.library
created by Thomas Richter (also sub author of 3.5 and 3.9 systems).
8
2.2 Specialised chips
Amiga as standard has set of specialised chips which provide integrated handling of graphics and sound. These chips use directly by so called DMA (Direct Memory Access) channels
standard memory called CHIP (or graphics memory) without use of processor.
More important chips are:
• blitter - graphical coprocessor equipped with 4 DMA channels responsible for copying of
memory with optional one of 256 logical operations on such memory block
• copper - coprocessor connected with beam position which is able to write value in to
registers of other chips (e.g. change colours)
• denise - chip responsible for 4 channels of 8-bit sound
And here we come across the first bad decision of creators of the Amiga: market models of
Amiga (maybe beside A3000 and A4000) has only so called graphic memory which is extremally slow for processor. Normal operating memory is called in Amiga FAST. The reason is that
on A500 difference in speed isn’t noticable, however from 68020 in A1200 code from FAST memory executes 200faster. Amount of CHIP memory depends on version of specialised chips and
usually it is 0.5MB till 2MB. Maximal amount of FAST depends on used boards and expansions.
32MB of FAST memory is in case of such an economic system as AmigaOS a good standard.
graphics in Amiga computers is created from so called bitplanes (value of pixel is determined
by state of bits from following bitplanes). OCS/ECS chipset of typical models handled up to 6
bitplanes, AGA chipset indexchipset!AGA of A1200, CD32 and A4000 models up to 8 bitplanes.
Additionally there are so called photorealistic modes called HAM and HAM8 (hold and modify),
which due to low speed didn’t get wider use beside computer graphics.
At the late eightys Amiga had several years of technological reserve. Strong blitter , system
of sprites (independant graphical objects) and bitplane graphics provided easy creation of the
games. Since 3D games turned to be popular chunky pixel (one pixel is one byte) turned to be
necessary. These modes on Amiga are created in software way, beside CD32 console. CD32 is
equipped with additional chip called Akiko which provides hardware chunky to planar conversion, however it did’t get much dedicated software. The console itself turned to be source of
cheap A1200 mainboards and CD readers 2x.
Major features of the hardware, which affected the shape of the operating system are surely
copper responisble for realisation of pull-down screens typical for AmigaOS (this feature does
not exist under control of external graphical board). It’s clean that bitplane graphics and strong
blitter affected very much handling of the graphics in the AmigaOS system. On the other hand
lack of operating memory forced AmigaOS to be one of the most economical systems in the
world.
2.3 Input/output devices
First Amiga computers were designed as floppy disk based systems. Built into all models
FDD (floppy disk drive) controller can handle up to four such drives. Alas in case of Amiga the
9
standard is 3.5 inch drive for DD(double density) diskettes formatted for c.a. 880KB (or 720KB
in MS-DOS).
Older models such as A500, A1200 did not have on the mainboard the HDD (hard disk drive)
controller, however there always were available external controllers of ALF, SCSI and SCSI-II
standards. Due to high popularity of SCSI in the world of Amiga Commodore company located
before it’s bankrupcy on the boards of A600 and A1200 models AT-BUS controllers. These are
controllers based on ISO document X3T10.pdf describing ATA-1 standard. As in Amiga there
was no selected channel for HDD’s DMA it’s handling is done in the processor mode caled PIO.
What is interesitng handling of the AT-BUS in AmigaOS is done by scsi.device what provides the
programmer with interface comparable with SCSI. It’s worth to mention that part of A600 had
ROM memory version which did not handle the built-in controller. Note that to the ”keyboard”
box only small 2.5 inch disks fitted what forced low popularity of hard disks at all.
Of course there exist wide range of controllers from various vendors often built into turbo
boards.
So called professional models which were shipped with HDD were equipped with:
• A3000 – SCSI controller
• A4000 – AT-BUS and SCSI-II controllers
On hard disks world does not end – readers for CD, DVD, LS120 and ZIP aren’t bigger problem,
however system itself does not support them. In most cases there is need to use software created
by the community. The best example of such program is FryingPan for CD mastering.
Each normal Amiga model has serial and parallel bus what let for handling of modems,
samplers and printers. Only the last ones has somekind of support of the system itself.
A600 and A1200 models were equipped with PCMCIA , which cannot be used without special adapter inside tower box. Due to Commodore’s choice to use 16-bit PCMCIA use of the ram
cards as memory expansions is out of question in case of A1200 (in case of A600 model with
68000 it’s acceptable). Kickstart ROM 2.0+ provides booting from PCMCIA cards prepared
as quick silicon disks. There also exist some PCMCIA devices especially for the Amiga. For
instance famous digitaliser which let for getting eight frames in 384x283 per second.
10
3
Brief history of AmigaOS
Before showing of the system itself it’s worth to see at least briefly the stormy history of the
computer what affected several elements of the system.
3.1 History
In 1982 former employee of Atari – Jay Miner founded Hi-Toro company, which name soon
changed to Amiga Inc. At the beginning the aim was o create something based on 68000
what would dominate market of the 16 bit game devices (a console). Author of the kernel
(exec.library) is Carl Sasenrath .
In 1984 the company has results to show, however has financial problems. Here Commodore
came in and after year we had not console but whole computer – Commodore Amiga(called later
A1000).
In 1987 A500 and A2000 models has been released. They soon became very popular in
Europe. These machines equipped with OS1.2(OS1.3) had graphical user interface and operating system with multitasking comparable to workstations of the time. Operating systems were
created in a big hurry what affected their quality.
In 1990 Commodore release fully 32 bit A3000 with SCSI and new system 2.0. That system
was better in any way. Changes in graphical interface looked very well. From programmer’s
point of view programming turned very much easier. Hence soon OS2.0 became a minimum for
all remarkable software.
In 1992 we got new computers A1200 and A4000 equipped with OS3.0(OS3.1). The most
interesting enhancements were somekind of support for CD readers as standard and system od
datatypes described in appropriate chapter.
At the beginning AmigaOS was connected with hardware and with the on-board ROM memory:
• System 1.x – A1000,A500,A1500,CDTV,A2000
• System 2.x – A500+,A600,A3000
• System 3.x – CD32,A1200,A4000
After several years since Commodore’s bankrupcy there has been release system 3.5 and later
system 3.9. Finally user hpt as standard things he had from other sources: TCP/IP stack, WWW
browser and e-mail client. Rest of the changes was cosmetic beside players for AVI, MPEG and
MP3.
And this is the end of the computer and AmigaOS known currently as classic line. The future
is described in appropriate section.
3.2 BCPL, C and asembler languages
It’s worth to mention what langauges were most used during the creation of the system.
11
3.2.1
Asembler
Obviously during the creation of the basics of the operating system an assembler was used.
Because assembler of the 680x0 processors is easy and gives big possibilites assembler was used
more often than it was required. It’s worth to mention that parameters for the system functions
are given in processor’s registers instead of stack what we could expect from language...
3.2.2
C
The C language is standard language for programming in operating systems at all. There’s
no exception in case of AmigaOS. Most of system programs were written in this language. The
creators of the systems and high speed fans probably used compilators in kind of GNU C.
3.2.3
BCPL
BCPL – Basic Combined Programming Language is created in 1969 language and is said
to be ancestor of the C language. Typical features are lack of types and maximally one dimensional arrays. It’s worth to mention that the most ported program in the world Hello world was
originally written in BCPL.
AmigaOS wasn’t created in BCPL language as some sources say – it applies to AmigaDOS
only. Due to lack of time works on CAOS (Commodore Amiga Operating System) were dropped before premiere, the quick solution was to: port DOS from already existing system called
TRIPOS. TRIPOS was product of Univeristy of Cambridge written in BCPL. This BCPL based
AmigaDOS has of course most of the features planned for original CAOS except one – resource
tracking. Dos processes built on the base of exec’s tasks had to have linked list of all resources
used by them. On the other hand CAOS has to handle file with sizes up to 1MB, what in the
eigthy’s was enough for everyone.
In the 2.0+ system ready form of AmigaDOS was only enhanced and rewritten in C language.
Alas the shados of the BCPL has left. To keep compatibility whole infrastructure of BCPL called
GlobVec, which none of new created programs used (mainly due to lack of documention).
Below few disadvantages for programmers caused by BCPL past:
• normal pointers in C style are mixed with BPTR pointers (address divided by 4)
• besides strings in C style there are used BCPL strings (something like Pascal strings:
length-content)
• most of the dos structures has to be located on the addresses dividible by 4
More about AmigaDOS in it’s real shape in appropriate chapter.
12
4
Structure and working of AmigaOS
4.1 What is in ROM?
In ROM memory called Kickstart are gathered most important from the computer creators
point of view elements of the operating system. Here are placed routines responsible for recognition of processor, hardware and drives. The core of the most popular systems 2.0 and newer
is located in kept memories of 512KB size.
4.2 Lists and libraries
The major structure in the system is two-directional list. Whole operating system is organised
with such lists and practically each object begins from node.
Various operating system functions were gathered in so called libraries. Library functions
are procedures written in a special way, that has to be reentrant – their code has to be able to
be executed in the context of many tasks. Necessary libraries were put into ROM memory, rest
is read from storage media if required. This feature provided modular structure to the system
and lets for easy expansion. Users created hundreds of libraries, from which only dozen were so
popular as to became somekind of standard. Example of such an library is reqtools.library with
functions for file requesters and message boxes called in Amiga world requesters. essage boxy
zwane w świecie Amigi requesterami.
From the programmer’s point of view the only solid address in the system of Amiga is address
4, where is kept address of the exec.library.
4.2.1
The exec library
Exec.library is most important library of the system – it contains all basic functions for handling of system lists, memory allocation, also creation and opening of other libraries.
4.3 How Amiga scheduler does work
Alas from stuffs for developpers it is only possible to determine names of exec’s private
functions used for scheduling. This chapter despite of basing on amateur analyses should show
the hidden gearworks of AmigaOS.
Each task in AmigaOS is represented by appropriate structure. Every amiga task can be in
one of the following states:
• in state of running (TS_RUN flag)
• be on TaskReady list (tasks wating for processor’s time – TS_READY flag)
• be on TaskWait list (tasks of waiting for event – TS_WAIT flag)
AmigaOS provides preemptive multitasking – in the other works the only real multitasking,
where each task can be held at any time and replaced with another. This work is done by so called
scheduler and in case of Amiga scheduler is a mechanism built into the system of interrupts.
13
4.3.1
Interrupts
During initialisation of the system special routines are set up to handle processor’s interrupts.
AmigaOS offers multilevel interrupt handling – each program can add it’s own code to be executed during interrupt by adding node appropriate system list. User’s code will be called by the
system interrupt handling routine . Apparently the ExitIntr(), function called at the end of
the each system interrupt handling routines calls internally function Schedule().
The Schedule() function takes several decisions:
1. if there is another interrupt pending current task is left untouched
2. if exec/TaskReady list is empty then current task is left untouched
3. if exec/TaskReady list contains task with higher priority then perform Switch()
4. if time for task has exceeded then do Switch()
5. otherwise current task is left untouched
The Switch() function stores in the structure describing task state of the processor in terms
of program counter, registers etc. Such switched off task is stored in appropriate list TaskReady
or TaskWait. Another procedure is Dispatch().
The Dispach() function check if on the top of the TaskReady list is task ready to run (it
is possible it’s once again the same one switched off before). If there is no task waiting for
processor’s time we can see unusual in normal programming loop inside which the processor is
stopped:
stop
move.l
bra.s
#$2000
D0,D0
check_again
When this particular loop gets task then the state of the processor stored before with Switch()
function.
Functions Switch() and the restoring one are depending on the system configuration. If
the computer is equipped with arithmetic coprocessor then it’s registers also have to be saved. In
simplies case it looks like that:
lea
move
move.l
move.w
movem.l
rte
$42(A5),A2
A2,USP
(A5)+,-(SP)
(A5)+,-(SP)
(A5),D0-D7/A0-A6
;addresss of stack address
;set user stack pointer
;push on stack program counter(PC)
;push on stack status register(SR)
;restore other registers
;enter Supervisor mode.
;rte writes the values into PC and SR
14
Each task has mask of bits describing signals it’s sensitive for. Typical example of signal
is SIGBREAK_C generated with keyboard shortcut CTRL+C. In typical system most of tasks
instead of conquering for processor’s time are in state of waiting for signals. task enters this state
after indirect or direct call of Wait(signalSet) function which internally calls explained
before function Switch(). SignalSet means bit mask of signals. Amount of signals is limited
by the amount of bits in longword to 32.
For waking up of tasks Signal(task,signals) function is responsible. This function
adds destination task to the TaskReady list, and even check wheter to preempt ”itself” (task
which generates the signal).
15
Figure 1: Software Failure Alert
4.3.2
Guru meditation
AmigaOS doesn’t have resource protection hence from the programmer’s point of view it can
be easily crashed. The memory management of the system supports only keeping track of the
free memory. For instance memory allocated by the tasks is equipped only with hader containing
length and isn’t tracked in any way. It’s no surprise that badly written programs can easily
”drive” out of the allocated block and destroy something in the system. Memory allocations that
last forever are also typical problem of new created software. Practically all other disasters in the
systems are result of the above.
Depending of the damages there are following situations possible:
• the system displays yellow border called Recoverable Alert with unclear warning
• the system displays box called Software Failure with reset or suspending of the task forever
in TaskWait list. In this case held program remains in the memory till reboot. As the
libraries has open counters they also will be not freed even no other program make use
them.
• the system displays red border called Software Failure(Guru Meditation) with unclear
justification and restarts the system.
Few words concering the numbers shown in the alerts. In most cases they are coded representation of the processor exceptions like illegal instruction or division by zero (alas the exception
handling is also up to the programmer). The key to understand the numbers is available with developper materials(i mean for programming aware persons). There are also programs which try
as precisely as possible explain such a number. The problem is that these numbers were unclear
even for the creators of the operating system. The Guru Meditation message got changed
for Software Failure, however it can be seen in the 1.3 version of OS. The creators of the
system wrote down such a number for further meditation on it. In fact the system is very stable.
4.3.3
Structure describing task
Each task in the system is described with the Task structure. It is built on the base of the node
structure describing list node. The Task structure alone is used rarely, however it’s base of the
Process structure created by AmigaDos.
Structure describing task in AmigaOS:
16
0
4
8
9
10
14
15
16
17
18
22
26
30
34
36
38
42
46
50
54
58
62
66
70
74
88
ln_Succ
ln_Pred
ln_Type
ln_Pri
ln_Name
tc_Flags
tc_State
tc_IDNestCnt
tc_TDNestCnt
tc_SigAlloc
tc_SigWait
tc_SigRecvd
tc_SigExcept
tc_TrapAlloc
tc_TrapAble
tc_ExceptData
tc_ExceptCode
tc_TrapData
tc_TrapCode
tc_SPReg
tc_SPLower
tc_SPUpper
tc_Switch
tc_Launch
tc_MemEntry
tc_UserData
address of next node
address of previous node
priority -128 till +127
address of the name
state of the task e.g. TS_READY
mask of the signals to wait for
address of the stack register
end of the stack
begin of the stack
optional code during task switch
optional code during task switch
For direct use of programmer there is intended one long word – tc_UserData. The rest is
filled in and controlled by the operating system. For modification there are intended special
library functions e.g. SetTaskPri() .
The system by deafult doesn’t have program for task managment. One of the programs with
such features is Scout program.
17
Figure 2: List of tasks in Scout
4.4 AmigaOS initialisation
The multistasking environment itself would be useless without communication between the
tasks and what is most important with the external world. I will describe now briefly the subsustems used in the process of graphical interface creation, and circulation of the information in
the system.
4.4.1
What could do Kickstart ROM itself
In the moment of computer’s reset all structures in the system are desactualised. Whole
process of hardware recognition (such as storage devices, controllers or memory expansions)
is repeated. The exception of that rule are special routines which under several terms could be
executed. This let for including in the system routines exchanging elements which normally
aren’t changeable. For instance loading of new Kickstart ROM from storage media. Other
example of that mechanism’s use is described in one of next chapters RAD: device.
The core of the AmigaOS are:
• already described exec library
• graphics library responsible for handling of graphics from the level of the operating system
• intuition library responsible for creation of graphical user interfaces
18
Figure 3: Boot Menu
• dos library responsible for high level input/outpu operations
These libraries are inside ROM memory and are practically necessary for the system to work
at all. Just then routines of the ROM memory begin the process of booting from the device with
the highest priority. Partition priorities are changeable with the partitioning program, devices
like floppy drive or PCMCIA card has priority defined by the system. We can choose the device
we wish to boot in the boot menu. Boot menu is operated with mouse program built in ROM
memory. Depending on computer version there can be: chosen drive we wish to boot from, the
processor’s cache memory can be switched off, or the emulation of the A500 chipsed can be
forced. We can eneter into the bootmenu by holding both mouse keys during reset (depending
on keyboard: Amiga+Amiga+Ctrl or Win+Win+Ctrl).
4.4.2
graphics.library
Amiga doesn’t have character modes such as older architecture PC computers has. Graphical
subsystem handling built in graphical chips is integral part of ROM and is initialised at the beginning of the system startup. Typical programmer uses only part of the functions – mainly one’s
concerning drawing of graphical primitives inside of structures created by intuition subsystem.
Graphics library ideas are based on built in chipset of Amiga. With system 3.0+ there were
introduced major changes for support of external graphical cards and handling of modes like
chunky pixel. However all features of hardware are(have to be) available through that library.
19
It’s lov level operations didn’t get wider popularity among game creators and creations of so
called amiga scene. One of the reasons was publication by Commodore full documentation to
registers of specialised chips, what led to the situation which forced new chips be compatible
with the older ones on the hardware level. Such happened in case of AGA chips, and such
had to be with another chipset for which there didn’t last money. Such strategy closed Amiga for
dynamically growing market of cheap graphical chips used commonly in the world of PC. Partial
incompatibility of AGA chipset introduced with A4000/A1200 touched in the larges degree the
market of the games. Some of the games were able to run after use of several tricks like switching
harddisk off, mapping of old ROM or even switching of cache memory. The biggest disadvantage
of direct hardware usage is reling on toy modes PAL and NTSC despite of the fact that AGA
chipset is able to generate VGA signal.
The most important usage of graphics.library is realisation of graphical environment created
and handled with intution.library.
4.4.3
Contact with user (intuition.library)
The intuition library is responsible for creation of mouse and keyboard operated user interface. Thank to intuition the operating system has system of screens, windows, and several kinds
of gadgets. Initially their use wasn’t easy but starting with system 2.0 intuition got enhanced
with many new functions. There have also appeared libraries designed especially to increase
comfort of user interface creation. Worth to mention is fact, that graphical environment built
with graphics and intuition is supervisory to AmigaDos. Console windows are always opened as
windows in already set up graphical environment.
4.4.4
Packets, ports, messages...
Filesystems or devices aren’t handled directly by the programer (there is no need for), but
indirectly through dos library. It’s worth to mention how dos communicates with tasks representing drives. When a program needs to read file from a floppy disk dos library after recognition
of destination device begins correspond with task called DF0:. This task is logical represention of floppy disk drive in the system. Communication is done through messages - which are
structures filled with defined content and sent with appropriate function to so called message
port of a destination task. Message port is a list with messages received by task. Packets are
commands understood by task which represents device (and devices, handlers and filesystems
standing behind). Packets are sent through system of messages. In described example there will
be sent packet and after processing it will be sent back as a packet with result of the operation.
Then another packet can be sent. In this place it’s worth to mention that disk operations in Amiga
are synchronous (a program is blocked to wait for packet reply and doesn’t do anything else at
that time). Alternative idea to bypass this behaviour of AmigaDOS is asyncio.library, however it
didn’t get wide popularity.
20
Figure 4: Example of graphical interface based on intuition
4.4.5
devices, handlers
Devices and handlers are system elements comparable to libraries. They are responsible for
handling of logical and hardware resources. Example of devices are:
• timer.device – responsible for use of computer’s timers
• input.device – responsible for low level handling of mouse, keyboard etc.
• trackdisk.device – responsible for floppy disk drives
• scsi.device – responsible for hard disks
Handlers and filesystems are responisble for handling of definite solutions. This only refers
to devices where file operations are supported.
21
Figure 5: AmigaDOS – console window
4.5 AmigaDOS
For high level handling of disk operations in Amiga operating system dos.library is responsible. Dos library gathers all required functions and is placed in the ROM, so in this way DOS is
almost always available.
4.5.1
Krótka charakterystyka
In systems before version 2.0 dos.library is only interface for so called GlobVec which is
infrastructure of BCPL ported from TRIPOS. In later systems the situation has been inverted
and as such left unchanged to achieve maximal program compatibility. After booting up the
system from empty bootable disk initilised AmigaDOS appears as console window (called Shell
in system 2.0+, earlier Command Line Interface). To make it possible to do anything command
files are required – they should exist in C: directory. Commands are separate little programs
delivered together with operating system. In system 2.0+ they are written in C language and use
dos library. In earlier systems they are BCPL programs that does not use dos.library at all.
22
The above description shows that DOS is integral part of operating sstem and is available
for applications even without command files. Commands are only interface between user and
system and can easily be replaced with user’s solutions.
AmigaDos let in file and directory names for use of any characters except ":" and "/". File
and directory names cannot exceed 30 characters, and system does not recognise small and big
letters (however remembers their state). System commands used to know typical patterns and for
example "#?" means any amount of any characters. Alas from CAOS specification there wasn’t
implemented convention of directories on Unix style therefore there is no root with devices as
directories and there is no ".." to point parent directory.
Files in the system are equipped with several flags:
• R – readable, possible to read from
• W – writable, possible to write to
• E – executable, however programs are recognised by file structure but lack of this flag
prevents their execution
• D – deletable,
• H – hidden, this flag simply doesn’t work
• S – script, AmigaDos script
• P – pure, resident program – described below
• A – archive, safe – for use of archivisation programs
Not all of the flags are interpreted by the system and their use has been left for hipotethical
programmer’s invention.
The P flag was intended to mark resident programs and is connected with Amiga’s multitasking. Once loaded program code has to be run several times as several tasks – whole program
has to behave like library functions. Almost all commands written in BCPL in a natural way
has this feature and that probably the only advantage of this language. In system 2.0+ few more
important commands are not only resident but alos go placed in ROM. Example of such resident
command is run, which in system 2.0+ doesn’t need to have it’s file on the storage medium.
4.5.2
Command examples
Typical programs or commands executed from AmigaDOS console are run in the context of
this console process blocking CLI/Shell. Command run lets for execution of program/command
on the separate „task”. There also exist command newcli, which simply opens another console.
Another important command is assign. In Amiga operating system there exist several
logical devices which represent content of one or more physical directories on disk. Here is list
of most improtant:
• device SYS: is an alias for disk the system was booted from
23
• device C: is an equivalent for SYS:C/ and contains command files
• device LIBS: is an equialent for SYS:LIBS/ and contains library files
• device S: is an equialent for SYS:S/ and is intended for AmigaDosu scripts
• device ENV: contains temporaty system settings
• device ENVARC: is an equialent for SYS:Prefs/Env-archive/ and contains saved
system settings
Amiga initially was floppy disk based system therefore all files were locared through disk
label. When hard disks got more popular logical devices created in any directory with assign
turned very useful.
And for example:
assign game_disk4: WORK:game/
adds to the system apropriate logical device. To decrease scale of this practise in system 2.0+
there was introduced logical device PROGDIR: describing home directory in the context of
current task. To increase users comfort there was introduced DEFER parameter for assign
command which causes the added device does not appear until some of the programs refer to it.
We already know that other commands we can find in logical device C:. List of all commands can be displayed with dir command. Syntax of arguments for this and for other system
commands always can be shown by calling the command with "?" as an argument.
4.5.3
The startup-sequence file
If file S:startup-sequence exists and is AmigaDOS script it will be executed just after
AmigaDOS initialisation. As it is quite important script for whole system for users alteration
there is another script called S:user-startup.
Startup-sequence of a typical system disk:
• installs appropriate for system version patches with SetPatch command ,
• creates various logical devices,
• loads drivers, mounts devices,
• calls user-startup script,
• in system 2.0+ system settings are loaded with IPrefs program
• runs Workbench described below with loadwb command .
Typical content of user-startup are series of assign and path commands placed there
by wiser users or automatically by intalled software.
24
Figure 6: User-startup file in CED editor
25
4.5.4
How does it look like inside
Programs and commands in system are run with arguments given in processor registers and/or
in structure describing process. Programs are obligated to return result in d0 register. As standard d0=0 means the program has finished successfully. AmigaDos interprets dozens values as
paricular erros.
For example program:
moveq #-1,d0
rts
causes console to be interpreted as „unknown command”. It is commonly used way of protection system files such as libraries against direct execution by the user. Without falling into
programming it’s worth to take a look at the structure of executable files used by AmigaOS.
4.5.5
Structure of executable files in AmigaOS
Executable program files has strictly defined structure and during reading through library
function dos/LoadSeg() data from file is located in different places of operating memory. Operating system recognises executable files by their internal structure divided into blocks called
hunks. Each hunk contains appropriate data and information to support process of loading.
The more important hunks are:
• HUNK_HEADER – which is required. Contains information concerning memory required for another hunks. It can be bigger than real block of data which is connected with
possibility of passive memory allocation for code.
• HUNK_CODE – intended for program’s code. Execution of loaded code begins from start
of data of the first such hunk.
• HUNK_DATA – indended for data. It doesn’t differ from previous one and if file is constructed with HUNK_DATA instead of HUNK_CODE then system will execute it without
any problems.
• HUNK_END – in most cases optional identifier placed by the compilators at the end of
other hunks.
• HUNK_BSS – this hunk is intended to passive allocation of memory during loading of the
program.
• HUNK_RELOC – these hunks are generated automatically by the compilators and assemblers. Due to dynamic character of memory management in AmigaOS there is no point
talking about reading data at defined address. Relocable code can be created with using of
indirect addressing and short jumps, however even best compilator or assembler programmer cannot beat limitations caused by growing code. There is also need to recalculate calls
between different hunks. Thats what for HUNK_RELOC was introduced. Before giving
26
back control to loaded program apropriate addresses in read code will be replaced with
recalculated ones.
It’s worth to mention, that data in executable files is gathered as longwords (quanted by 4
byte portions). Additionally compilator can specify what kind memory is indended for each
hunk. Function LoadSeg() operates in most cases on lower words in hunk lengths, this means
older bits are free to use for memory type specification – CHIP or FAST. Default type PUBLIC
describes any memory (FAST or CHIP in cases that other memory is not available).
In AmigaOS there is also mechanism of so called overlays. It is done in the way that all
program file isn’t processed during loading, and control over process of loading is given to the
program itself. In such case program file can be even bigger than available operating memory.
Alas due to little of documentation this feature left almost unused. The exception are described
below together with xfd library TitanicsCruncher and file format created by muLink tool from
mmu library package. muLink uses internal procedures to load data and then write protect it
in memory (somekind of memory protection known from big operating systems). In most cases
memory on which MMU unit works is described with 4KB precision – so large rounds are not
supported by any of memory allocation functions (first A1000 had 256KB if operating memory).
4.5.6
The Process structure
Loaded program isn’t represented in memory only as task structure, but as it’s extended
version called Process.
Structure describing AmigaOS process:
0
92
pr_Task
pr_MsgPort
- Task structure
- standard port for communications
with devices by dos library
126
128
132
136
140
144
148
152
156
160
164
168
172
176
180
184
188
pr_Pad
pr_SegList
- list of segments loaded by LoadSeg()
pr_StackSize - stack size
pr_GlobVec
- table of BCPL functions
pr_TaskNum
pr_StackBase
pr_Result2
pr_CurrentDir - so called lock on current directory
pr_CIS
- so called handle of input stream
pr_COS
- so called handle of output stream
pr_ConsoleTask
pr_FileSystemTask
pr_CLI
- address of Shell structure
pr_ReturnAddr
pr_PktWait
pr_WindowPtr
pr_HomeDir
- lock on program’s home directory
27
192
196
200
204
208
220
224
pr_Flags
pr_ExitCode
pr_ExitData
pr_Arguments
pr_LocalVars
pr_ShellPrivate
pr_CES
Similar to task structure most of these fields are handled internally by the operating system.
For example functions of dos library make use of MsgPort for internal packet level realisation of
high level user’s dos operations when emphdos/PutStr() function during printing text out internally uses opened output file specified in pr_COS. Some of the fields we can alter from console
level. For example using redirections we can alter streams pr_CIS and pr_COS:
echo "tekst" >RAM:plik.txt
or even:
run <>NIL: program_detached_from_console
28
Figure 7: Example of use WBPattern and Time programs
4.6 Amiga Workbench
Workbench is graphical interface for AmigaDOS. It is built in system program, and can be
run with loadwb command. Workbench is also associated with system disk(s) that afer booting
initialise full Workbench environment. System of icons, windows, pull down menus is similar to
solutions known from other systems: MacOS, X-Windows, Windows or even GeOS for C-64.
4.6.1
Characteristic features
Programs run from Wokrbench elvel get arguments in a quite different way than in case of
console execution. In icon file .info can be specified so called which are Workbenech variant
of parameters.
Similar to AmigaDos flag H is ignored, however it is possible to switch between showing
files with icons or all files.
Disk with Workbench contains several example programs such as clock, calculator, file displayer or simple text editor.
4.6.2
Preferences and commodities
System of Preferences programs let for changing of various Workbench settings like: used
screen fonts, keyboard map, language, screen wallpaper or mouse pointer shape. In system 2.0
29
Figure 8: Exchange program – managing other Commodities
or newer settings are stored in dedicated files held in especially created logical devices: ENV:
current settings and ENVARCH: saved settings. In earlier system versions basic Workbench
settings were editable with single program and stored in system-configuration file . This
file is interpreted also by newer operating systems, however there is no longer possibility to
change it and new preferences settings are has higher priority.
Commodities programs are programs written in special way with one or two features. Example might be system Blanker or ClickToFront program pulling clicked windon on the top (standard feature of Windows). Programs of that kind are written in special way and intended to work
in the background. Besides commodities delivered with operating system there has been created
so many other ones that on Aminet server (www.aminet.de) there is specified special directory
for them. Commodity programs has graphical user interface. It can ve called by double program
execution, by keyboard combination (so called hot key) or from the level of commodities supervisor Exchange program. . Exchange is program which lets for opening of GUI of any active
commodity. It can be also deactivated or even closed.
4.6.3
WBStartup
In SYS:WBStartup directory are placed programs that we want to be executed during
opening of Workbench. The content used to be set of patches, additions and antiviruses.
30
4.7 Attempts to modernise
Workbench in terms of features and appearance was soon outdone by solutions on other
platforms. After Commodore bankrupcy all developpment depended on programmers invention
who created different additions and patches. Worth mentioning are three major improvements:
• MagicWB is simply addition to system with eight-colored icons in palette that minimalises
annoying of interlaced modes (640x512 on TV of PAL monitor really exhausts one’s eyes).
• MUI (Magic User Interface) is quite big package that provides progammer with object
approach to creation of user interface. Whereas user gets very configurable and esthetic
compared to standard one user interface. Altough MUI is not element of Workbench itself
it gives new quility to software using it.
• DirectoryOpus Magellan – here situation is different – Directory Opus was one of many
dir-util progams, just like known from other platforms NortonCommander, MidnightCommander and even TotalCommander. In Magellan version there was introduced Workbench
emulation mode and performed synthesis of dir-util philosophy with graphical system based on icons. Solution turned so comfortable, that many Amiga users cannot imagine their
system without this addition.
31
4.8 Interesting solution in AmigaOS
In AmigaOS there are several interesting solutions which I will attempt to present. Part of
them might be inspiration during creation corresponding solutions for platfoms, which already
doesn’t have such feature.
4.8.1
Ram Disk - virtual disk
System of Amiga is equipped with logical device RAM:. It is virutal disk created in computer’s operating memory. That disk takes only so much memory as files stored in it. It is widely
used as temporary directory not only during copying or dearchivisation but also to keep current
settings and configurations (logical devices ENV: and T:) .
4.8.2
RAD - resetproof virtual disk
Little bit different approach characterises virtual disk RAD:. Content of RAD: isn’t lost in
the time of reset, however size of that disk is defined once in apropriate configuration file (e.g.
DEVS:mountlist or SYS:Storage/DosDrivers/RAD).
Due to technical reasons that disk uses only shortage CHIP memory , so by default this disk
isn’t mounted and has to be mounded with command:
mount RAD:
Natural use of RAD: disk is quick dearchivisation of whole disk archives in DMS (Disk
Masher System) format, which do contain image of disk compressed as single sectors. The
system is able to boot from RAD: disk just like from physical disk.
4.8.3
xpk and xfd libraries
These libraries are solutions out of original system however very quickly became widely accepted standard. As known Amiga for many years as disk based system didn’t provide large areas
of disk space. Compression of data very quickly became very popular. It used to be implementations of well known alghorythms such as Huffmann coding etc. In short time appeared dozens
if not hundreds of compressed data formats as till half of the ninety’s any creator or cracker taked the opportunity to protect the data against unathorised alteration. Only several compression
programs became widely popular.
The more important are:
• PowerPacker and Imploder that compress not only data but also almost every executable
AmigaDOS files
• CrunchMania i StoneCracker widely used by so called amiga scene
• TitanicsCruncher intended especially for large executable files. It’s advantage was decrompression of file in parts from disk – the feature other such programs lack.
32
Figure 9: Screen of PowerPacker program
Figure 10: Screen of StoneCracker program
33
As visible situation became more and more complicated. Most of programs died naturally
with came of new 68030 and 68040 processors. Cache memory for code and date forced changes – decompression routines that didn’t flush it with system function e.g. CacheClearU()
before jump to decompressed code caused system to crash. Additional problem was use of untypical compression progams to hide viruses and trojan horses. It was clean that unification of
compression standards is required.
Xpk is modular library that is able to compress/decompress and decrypt/encrypt data. As
standard the library was supplied with modules that provided compression and encryption with
well known alghorythms which is pointed even by the sublibrary names: IDEA, HUFF, SHRI,
BLZW. Xpk provides logical standard of compression and encryption of data with almost any
implemented algorythm. Developper version of Xpk package contains everything required to
create own sublibraries if required.
On the base of xpk library there was created addtion to operating system called: xfh-handler
. It provides adding of logical devices with "on air" compression. In most cases there was added
device, which content was compressed with SQSH sublibrary. SQSH sublibrary is intended for
fast compression of 8-bit music data – it compressed the differences between bytes.
Xfd is modular library providing decompression of almost every data compressed on Amiga
at all. This library is standard for antivirus programs. Basic interface for that library is set of
small programs – AmigaDOS commads.
For example the command:
xfdDecrunch RAM:temp/
decompresses all files placed there if only they are recognised as compressed data.
Also this library lets for easy creation of decompression modules which can be created by all
eager programmers. That provides handling of large amount of compression formats either of
data and AmigaDOS executable files. Untypical file formats generated by different sometimes
strange programs are also handled. Bootblock sector of diskette written in as executable file is
not problem such as isn’t problem written in executable form "compiled" ARexx scripts hidden
in executable file. Standar module ZbL! done by me "decompresses" executable text files for
instance.
4.8.4 xadmaster.library
Besides single file compression archivisation is used. Standards of archivisation for Amiga
are: lha i lzx to store files and dms to store whole disks.
Xad library, created similarily to xfd, is responsible for handling of archives of any kind. Set
of external sublibraries lets unarchive different formats using only one interface. Due to above
user needs only one tool using this library to unarchive any data. Disk based archives can be
unarchived to devices (as mentioned above RAD:), to memory or into the directory. This library
is also equipped with simple shell based interface and for example:
xadUnFile example.lha RAM:
unarchive contents of archive into the RAM: device , whereas:
34
xadUnDisk example.dms example.adf
converts dms archive to adf file format used by several Amiga emulators.
Currently xad library deals with such formats like: ACE, ARJ, BZip2, CAB, GZip, Lha, Rar,
StuffIt, Zip and Zoo.
Worth mentioning is fact that executable versions of archives (with intel extensions) also
aren’t problem. Currently the library is part of AmigaOS3.9, earlier it was developped as SHAREWARE. Such past caused that library got really good debugged. Author – Dirk Stoecker had
accepted as fee 3 bug reports or new sublibrary. Xad library very quickly got support even for
such untypical formats as: C64 tape image, LBR C64, Outlook4Mailbox, MacBinary or even
RPM (RedHat Package Manager).
4.8.5
translator.library, voice.library
System of Amiga in older versions was equipped with speech synthetiser. Responsible for
that process was translator.library which translates english text to phonems which were interpreted and played by narrator.device. Standard interface to this capability was system program Say
placed (till OS version 1.3) on disk with Workbench. Due to unknow reasons the development of
speech synthesis was dropped. Possibly the reason was multilanguage capability introduced in
later versions of the system. After copying of mentioned files everyting works properly. Seems
once again there was too few time and money. Alas single programmers were not able to write
something in the kind of narrator.device, however there were attempts to write diffrent language versions of translator library with quite indifferent results. Polish text spoken with english
phonems is difficult to understand.
After equipping with sampler and microphone Amiga can recognise speech. Responsible
for this capability is voice.library and programs which use it. Example of such program is VoiceShell. It lets to execute chosen programs with voice commands. It’s enough to record voice
commands and specify paths to programs. Alas used algorythms are not excellent, so it’s poinless
to count on recognition of similar words like CED and ED for example.
4.8.6
Locale – wieloj˛ezyczność
With system 2.0 locale library appeared. It supplies multilanguage of programs created with
it’s use. Depending of language settings program is able to use built in language (in most cases
it’s english) or read file with texts so called catalog. Files of catalog type are generated from
special text files with special software. File .cd (catalog description) contains original texts,
it’s labels and possible limitations. Files .ct (catalog translation) contain translated texts described in .cd file. Programmers used to know two languages I mean english and their nativ
language, however there was founded Amiga Translators Organisation , which members from
all the world voluntarily work on preparation of translations to their own languages. Thank to
such approach many programs have not only different catalogs but often also documentaton in
several languages.
35
Figure 11: Multiview called from console
4.8.7
Datatypes – multiformat capability
In system 3.0 there were introduced datatypes. It is extension which has to give object approach to different types of data. Programs using datatypes are not limited to built in formats,
but could open files in all formats installed in the system.
For example picture viewer checks if file chosen by user is recognised by class picture, to
display it with apropriate method. Example of program using datatypes is system program called
multiview, to show every data recognised by the computer. System of datatypes provides users
with support of new created formats, and even versions optimalised for specific hardware which
author of program even doesn’t need to have. For example there are versions of akPNGdatatype
optimalised for different versions of processor including PowerPC on two-processor cards.
4.8.8
ARexx Language
RexxMast is standard addition on original disk with Workbench. It’s ARexx interpreter.
After installation depending on throwing it into the WBStartup directory, users gets great capabilities of ARexx language. ARexx language is Amiga implementation of script language Rexx.
Standard usage of that language covers communication and controlling of programs with so called ARexx port. After installing apropriate scripts under function keys of text editor it is possible
for example to send word under the cursor to the program that checks it’s spelling. Capabilities
are really huge and depend only on program options available from ARexx language.
36
Below example script that inserts current date in the place of the cursor of the text editor CED
:
/*
insertdate.ced
*/
ADDRESS ’rexx_ced’
TEXT Date("N")
EXIT 0
We assumed that CED can’t insert date itself(what isn’t truth), so inserted with editor command
TEXT date returned by ARexx function Date().
ARexx itself lets for automatisation of many works done on computer. Further capabilities
opens when REBOL language is used to connect indirectly ARexx ports of computers placed in
the net. Inveneted by Carl Sasenrath, the author of AmigaOS kernel REBOL language is cut out
to network uses. Currently REBOL ports exist for almost every platform met in the Internet.
37
Figure 12: Example of installation script
4.8.9
Installer script
To make programmer’s life easier and to standarise process of software installation Commodore introduced Installer program. Similarily to RexxMast it’s interpreter of simple language
created especially to write installation scripts. The major advantage are functions to add assigns
to S:user-startup and to copy libraries with check of the currently installed version. Additionally
there is possiblity of creation of the script on three levels called Novice, Intermediate and Expert.
It’s bound up with control over installation process given to the user.
Below part of installation script of my program called TurboVal.
(if (= @language "polski")
(
(set CPNG "Kopiuj˛
e plik VAL do ")
...
38
(set app-name "TurboVAL v2.5")
(if(<(/(getversion)65536)37)(abort NEED))
(complete 0)
(message (cat WELC))
(set dirk (askdir (prompt WHER) (help WHLP) (default "C:")))
(set @default-dest dirk)
(copyfiles (prompt CPNG dirk) (source "VAL") (dest dirk))
(complete 100)
As noticeable installer script language gives big possibilities including creation of scripts that
interact with user in his own language and even additional explanations with help parameter.
39
5
Conclusions
5.1 Real resons of Amiga fall
First reason of Amiga fall was bad marketing and bankrupcy of company responsible for it.
At the beginning Amiga was on the winning positiona and was one generation ahead compared
to other machines. This advantage got quickly wasted. Since PC computers got graphical environment the futere was almost lost. Major vice of Amiga was being closed from solutions form
the PC platform such as graphical and sound cards. Default displaying in PAL mode only confirmed place of Amiga in the world of toys. Rather lack of VGA modes is vice, as PAL modes
opened Amiga for wide range of video works (in cable televisions for instance) till today. Let’s
take a closer look at the major advantages and disadvantages of AmigaOS itself.
5.2 What is good in AmigaOS
Surely unique solution is xad library. Recently autor dropped works on XAD for Amiga and
said the first test versions for Unix are at libxad-Sourceforge CVS.
Very impressing is very good multitaking which works very well even without memory protection of resource tracking.
Interesning solutions as installer, ARexx or speech recogniton and synthesis are worth attention and are good to take cue from.
Big advantage of AmigaOS is simplify of creating of enhancements, patches and commodities. Thank to that programmers didn’t sit on their hands and could actively take part creation of
the shape of the computer without looking back for another owners rights to system and computer.
5.3 What is wrong in AmigaOS
Absolutely wrong solution was to drop works on own DOS and porting analogous procedures
in BCPL. Shadow of this left foreven in the system and made programming under dos little bit
more difficult.
Also high connection with hardware is as vice. The graphics subsystem even in version 3.9
doesn’t offer spectacular support for solutions out of the mainboard.
Dependence of the developpment on one company, working on time also affected working
and design of the system. Choice of one family of processors also wan’t meaningless. System
grown into hardware more than it was required maybe due to easy assembler programming for
680x0 processors. .
Another mistake was missing the chance given by Coldfire processors. These processors are
so compatible with 680x0 that after use in turbo boards would be gained some time to create new
version of the system. Alas it didn’t happen. The community is get smaller again and the works
on AmigaOS 4.0 for PPC are pending till today.
Releasing of two-processor boards with PowerPC as coprocessor solved nothing but faster
raytracing. In spite of anticipations these cards didn’t get wide popularity due to rather high price
40
and lack of dedicated software.
5.4 Summary
Certainly AmigaIS in shape presented here is already history. We could expect that new
system 4.0 in PowerPC version will not copy bugs of the ancestor. It will not get wide popularity,
but there is something in AmigaOS, that users are eager to back to it. Good computer is such a
one can use, what Amiga users explicitly shown enhancing and developping their system in spite
of everything.
41
Index
alert, 16
Guru Meditation, 16
Recoverable Alert, 16
Software Failure, 16
Amiga Translators Organisation, 35
AmigaDOS, 22, 23
assign, 23, 24
echo, 28
executable
overlays, 27
executable file, 26
hunks, 26
flags, 23
IPrefs, 24
LoadSeg(), 26, 27
loadwb, 24, 29
mount, 32
newcli, 23
path, 24
RexxMast, 36
run, 23, 28
Say, 35
SetPatch, 24
startup-sequence, 24
user-startup, 24, 38
VoiceShell, 35
xadUnDisk, 34
xadUnFile, 34
xfdDecrunch, 34
Aminet, 30
archive
DMS, 32
archivisation, 34
ACE, 35
adf, 35
ARJ, 35
BZip2, 35
CAB, 35
dms, 34
GZip, 35
lha, 34, 35
lzx, 34
rar, 35
StuffIt, 35
Zip, 35
Zoo, 35
bitplane, 9
blitter, 9
boot menu, 19
bootblock, 34
cache memory, 20, 34
CacheClearU(), 34
CAOS, 12, 23
catalog, 35
CED, 37
chipset
AGA, 20
ECS, 9
OCS, 9
chunky pixel, 9, 19
commodities, 30
Blanker, 30
ClickToFront, 30
Exchange, 30
Commodore, 11, 20, 31, 38
compression, 32
CrunchMania, 32
Huffman coding, 32
Imploder, 32
PowerPacker, 32
StoneCracker, 32
TitanicsCruncher, 27, 32
xfh-handler, 34
xpk
BLZW, 34
HUFF, 34
SHRI, 34
SQSH, 34
42
console, 22
CLI, 22, 23
commands, 22
Shell, 22, 23
VoiceShell, 35
controller
AT-BUS, 10
SCSI, 10, 11
SCSI-II, 10
C, 12
installer script, 38
Rexx, 36
library, 13, 18
datatypes, 36
dos, 20, 22, 28
exec, 13
graphics, 19, 20
intuition, 20
locale, 35
mmu, 27
reqtools, 13
translator, 35
voice, 35
xad, 34, 40
xfd, 34
xpk, 34
Debian, 8
device, 21
C:, 24
ENV:, 30, 32
ENVARCH:, 30
input, 21
PROGDIR:, 24
RAD:, 18, 32, 34
RAM:, 32, 34
scsi, 21
T:, 32
timer, 21
trackdisk, 21
DirectoryOpus Magellan, 31
DMA, 9
memory
CHIP, 9, 27, 32
FAST, 9, 27
management, 16, 26
protection, 16, 27, 28
PUBLIC, 27
message, 20
message port, 20
packet, 20
Miner, Jay, 11
MMU, 8, 27
multitasking
Dispach(), 14
ExitIntr(), 14
process, 16, 27
resource protection, 16
Schedule(), 14
scheduler, 13
SetTaskPri(), 17
signals, 15
CTRL+C, 15
Signal(), 15
Switch(), 14, 15
task, 13, 16
Wait(), 15
encryption, 34
xpk
IDEA, 34
filesystem, 21
handler, 21
interrupt, 14
Kickstart ROM, 13
language
ARexx, 34, 36, 37
asembler, 12
BCPL, 12, 23, 40
BPTR, 12
GlobVec, 12, 22
GlovVec, 27
43
NetBSD, 8
PCMCIA, 10, 19
preferences, 29
system-configuration, 30
processor
680x0, 7, 8, 12, 40
68020, 7
CISC, 7
Coldfire, 40
PowerPC, 40, 41
x86, 7
reset, 18, 19
sampler, 35
Sasenrath, Carl, 11, 37
speech synthesis, 35
type, 7
BYTE, 7
LONG, 7
WORD, 7
Workbench, 29
Installer, 38
MagicWB, 31
MUI, 31
RexxMast, 36
Say, 35
ToolTypes, 29
WBStartup, 30, 36
44
References
[1] AmigaDevelopperCD – original developper stuffs
[2] www.aminet.de/dev – other developper stuffs
[3] M68010UM/AD – processor’s manual, instruction set
[4] M68030UM/AD – processor’s manual, instruction set
[5] M68040UM/AD – processor’s manual, instruction set
[6] M68060UM/AD – processor’s manual, instruction set
[7] M68000PM/AD – programmer’s manual for 680x0
[8] AmigaOS 3.1 Workbench – user’s manual
[9] X3T10.pdf – an ISO organisation document describing AT-BUS
[10] www.dstoecker.de – XAD author’s homepage
45