AmigaOS Documentation Wiki - User contributions [en]

Exec Memory Allocation

2024-04-03T16:02:39Z

Steven Solie:

== Exec Memory Allocation ==

Exec manages all of the free memory currently available in the system. Using a slab allocation system, Exec keeps track of memory and provides the functions to allocate and access it.

When an application needs some memory, it can either declare the memory statically within the program or it can ask Exec for some memory. When Exec receives a request for memory, it searches its free memory regions to find a suitably sized block that matches the size and attributes requested.

Prior to AmigaOS 4.0, the OS did not make use of the CPU's memory management unit and used memory "as-is". That is, if you have different memory expansions plugged into your system, the memory will be seen as chunks located somewhere in the 4 gigabyte address space. Since version 4.0, the MMU will be used to "map" memory pages from their physical location to a virtual address. There are multiple reasons why this is better than using the verbatim physical addresses - among other things it reduces the effect of "memory fragmentation" and simplifies the possibility to swap currently unused memory pages to persistent storage such as a hard disk.

The "downside" is that the virtual address of a memory block is almost never identical to the physical address. This isn't much of a downside, since an application will never really need to care about it. If an application allocates a block of memory of n bytes, it will get a pointer back that points to at least n continuous addresses as expected. The pages that "fill" this memory block may come from different physical locations scattered throughout the physical memory but a program will never noticed that. For all intent and purpose, the application sees a single continuous block of memory.

=== Program Address Space ===

It is important to remember that, just like in classic AmigaOS, a single address space is used for all programs. Sometimes the mention of an MMU can lead people to assume that each process on the Amiga will have its own personal, partitioned address space. The following two programs demonstrate that, even though they are separate processes, it is possible to read and write another's memory. The memory locations are the same virtual address and that virtual address maps onto the same physical address.

This program has a global variable. It prints out the virtual address of the global, the value at that address (which can be optionally specified), waits for a keypress and, finally, prints out the value at that same address again in case it has been externally updated (which is done by the subsequent program listing):
<pre>
#include <stdlib.h>
#include <stdio.h>

volatile char x = 127;

/* Usage: a [VAL] */
int main(int argc, char *argv[])
{
if(argc==2)
x = (char)atoi(argv[1]);

printf("Virtual Address of `x': %p\n", (void*)&x);
printf("Dereferenced Value of `x': %d\n", x);
(void)getchar();
printf("Final Value of `x': %d\n", x);
return 0;
}
</pre>

This program reads in an address as an argument and prints the value at that address even though it does not "own" the memory. By adding an additional argument, this program can also write to that "foreign" address. After this program is complete, you can press a key on the previous program and see that the value changed:
<pre>
#include <stdlib.h>
#include <stdio.h>

/* Usage: b ADDR [VAL_TO_WRITE] */
int main(int argc, char *argv[])
{
if(!(argc==2 || argc==3))
return 10;

volatile char *byte = (volatile char*)strtol(argv[1],NULL,16);
printf("Selected Virtual Address : %p\n",(void*)byte);
printf("Dereferenced Value of Address: %d\n",*byte);
if(argc==3)
{
printf("Writing Value `%d' to Address: %p\n",atoi(argv[2]),(void*)byte);
*byte=(char)atoi(argv[2]);
}

return 0;
}
</pre>

=== Slab allocation ===

[[File:SlabDiagram.jpg|right]]

The AmigaOS memory architecture is based on the "slab allocator" system or "object cache". In essence, the slab allocator only allocates objects of a single size, allocating these in larger batches ("slabs") from the low-level page allocator. These slabs are then divided up into buffers of the required size, and kept within a list in the slab allocator.

Allocating an object with the slab allocator becomes a process of simple node removal: the first node in the first slab containing free nodes is removed and returned for use. Since the slab allocator keeps free slabs or partially free slabs in a separate list from the full slabs, this operation can be carried out in constant time. Freeing memory is accomplished by returning the buffer to its cache, and adding it to its original slab's free list. Slabs that are completely free can be returned to the system's page pool (this operation is actually driven by demand, and timestamps are used to avoid unnecessary loading of data, or "thrashing"). External fragmentation is minimal, and internal fragmentation is controlled and guaranteed not to exceed a certain amount.

=== Object caching ===

The slab allocator can also be used to cache objects. In the real world a lot of memory allocation operations will be used to allocate the same object. The system has a number of data structures which are allocated frequently (semaphores, message ports and the like). Every time such structures are allocated, they must be initialised, and when they are deleted again, they must be cleaned up. It's likely, however, that such a structure will be needed again in the future, so that it can be kept in its initialised state and re-used later. This further reduces the load on the allocator routines, and thus improves system performance.

The object caches work on memory that has already been mapped into the virtual memory space.

=== More Advantages ===

Another advantage is the possibility to improve CPU cache usage. Usually, most objects have "hot spots", i.e. they have a few fields that are used often. Since most of the time a little memory is left unused in a slab (the object size might not be a multiple of the slab size), this additional memory can be used to "shift" the hot spots by a few bytes to optimise the memory structure, leading to better cache usage.

Finally, the system can be expanded to multiple CPUs with next to no overhead. On multi-CPU system, these expanded slab allocators scale almost linearly with the number of CPUs employed, making it the ideal choice for such systems.

The combination of object caching and keeping caches for different memory blocks (for AllocVec/FreeVec emulation) makes the memory management more efficient, faster, and generally more future-proof than the old free list approach used in AmigaOS 3.x and earlier.

See Wikipedia for more information on [http://en.wikipedia.org/wiki/Slab_allocation slab allocator systems].

=== Physical page allocation ===

Every memory location in a computer system has its own, unique address. That is, there is a byte location at address x where you can store and retrieve a single byte. This address is fixed; there is no way to change it without physically changing the hardware. Therefore, this address is called the “physical” address.

The physical address of a memory page is most often completely irrelevant to the application. The CPU will typically only see the virtual address. AmigaOS will take care of assigning virtual addresses to memory paging. This is often called “mapping” a page. Only in very special cases will the physical address be relevant. For example, device drivers that want to pass memory to a hardware device via DMA. Since the MMU is part of the CPU, any external hardware like an IDE controller will not see the virtual but only physical addresses.

A common operation in memory allocation is the assignment of virtual addresses to physical memory locations. Allocation of physical memory is usually done differently from virtual allocations, since it's necessary to free up only part of the allocation (when for example the pager kicks in).

The de-facto standard in allocation of physical pages is a method invented by Knuth, called [http://en.wikipedia.org/wiki/Buddy_memory_allocation the "buddy system"]. Basically every modern operating system uses it and AmigaOS is no exception.

Buddy systems are in essence size-segregated free lists. To allocate, the system searches for a free block of at least the size of the allocation. Then, if the block is too large, it's split into two even-sized blocks. These blocks are called "buddies". One block is returned to it's appropriate free list, and the other is considered further, maybe splitting it further until it's size matches that of the allocation.

In a buddy system, it's easy to determine whether the "buddy" is free or not, because it's address can simply be decided based on the address of the block to be freed.

=== Virtual address space allocation ===

Most CPUs come with a special unit that is called a "memory management unit" or "MMU" for short. The MMU's primary job is to rearrange the physical memory within the 4 gigabytes of address space in a way that is convenient for the operating system and/or applications. To do that effectively, it divides the memory into blocks (called "pages"). For every page the MMU has an entry in a table that specifies where the CPU should "see" this page, and what special attributes the page has. The address where the CPU "sees" this page is a 32 bit address as well, but since the memory is not really located there, we call that a "virtual" address.

AmigaOS uses a resource map allocator for allocating virtual address space. Basically this is a means of managing a set of resources (not necessarily memory). For performance reason, it uses several optimization techniques.

For one, all free resource blocks are held in space-segregated lists, i.e. there is a list for each power-of-two resource group. This makes allocations a lot faster by providing an upper and lower bound for a search. For example, if you want to allocate a block of 2^10 bytes, you can basically skip searching any block below 2^10 bytes in size simply because it won't fit. Similarly, you don't need to search for blocks that are larger than, say, twice the size of the block, since there might still be blocks of a size near to what we need. Size-segregated free lists help narrow down the search, making the search itself faster and the result better in terms of fragmentation.

In addition, the resource maps use object caches for accelerating "small" allocations. Most allocations are below a certain size. For example, the virtual addresses are always allocated in chunks of at least one "page" in memory (4096 bytes). So it's common to allocate blocks of one, two, four, or eight pages. The object caches provide an easy method for keeping these common sizes, making every allocation of these sizes an exact fit, further reducing fragmentation.

=== Page cache ===

A lot of the time spent in allocating memory was spent looking for the appropriate pages in memory. A 256 MB memory system has 65536 4KB pages. These pages have to be searched for from time to time. Originally, hash tables were used but it turned out that distributing 65536 page entries over a few hash buckets still produced lists of several thousand pages that had to be traversed to find a page. The hash table was replaced with a radix tree. These trees are rather broad, but shallow, making traversal very fast. In usual circumstances, the tree does not grow more than 4 to 5 levels in depth, making searching of a page a matter of maximum 4 to 5 compare operations.

=== Pager ===

AmigaOS has the possibility to swap out parts of memory to disk in order to free up more memory for other applications. This feature allows applications to use more memory than is actually physically installed in the system.

Paging is commonly referred to as "virtual memory" by users and sometimes even software developers. The fact AmigaOS uses virtual memory does not imply the use of the pager.

The system can be tuned to different strategies, either page out only on demand (for highly interactive tasks), or based on other needs (lots of free memory in core for disk caches etc.).

The optimized data structures allow the memory system to operate at a very high speed.

The time for a memory allocation is now in the order of a few microseconds. This is especially true for small allocation (below 8096 bytes). During system testing it was observed that by the time the system has booted up to Workbench, there have already been 40,000 allocations to the global memory pool below 2096 bytes.

== Memory Functions ==

Normally, an application uses the AllocVecTags() function to ask for memory:

<syntaxhighlight>
void *AllocVecTags(uint32 size, uint32 tag1, ...);
</syntaxhighlight>

The size argument is the amount of memory the application needs and the tag list specifies the type of memory and any special memory characteristics (described later). If AllocVecTags() is successful, it returns a pointer to a block of memory. The memory allocation will fail if the system cannot find a big enough block with the requested attributes. If AllocVecTags() fails, it returns NULL.

Because the system only keeps track of how much free memory is available and not how much is in use, it has no idea what memory has been allocated by any task. This means an application has to explicitly return, or deallocate, any memory it has allocated so the system can reuse it. If an application does not return a block of memory to the system, the system will not be able to reallocate that memory to some other task. That block of memory will be lost until the Amiga is reset. If you are using AllocVecTags() to allocate memory, a call to FreeVec() will return that memory to the system:

<syntaxhighlight>
void FreeVec(void *memoryBlock);
</syntaxhighlight>

Here memoryBlock is a pointer to the memory block the application is returning to the system. The size of the memory block is tracked internally by the system.

Unlike some compiler memory allocation functions, the Amiga system memory allocation functions return memory blocks that are at least longword aligned. This means that the allocated memory will always start on an address which is at least evenly divisible by four. This alignment makes the memory suitable for any system structures or buffers which require word or long word alignment, and also provides optimal alignment for stacks and memory copying.

=== Memory Types ===

There are three primary types of memory in AmigaOS which are summarized in the following table:

{| class="wikitable"
! Type
! Use
|-
| MEMF_PRIVATE
| This memory is private and only accessible within the context of the Task which allocated it. Private memory should always be preferred. Private memory is also swappable by default (i.e. not locked). This memory will not be visible to any other address space.
In a future version of AmigaOS, it is planned to have Task specific address spaces. This means each task could potentially address up to 4 GB of private memory each.
|-
| MEMF_SHARED
| The memory is shared and accessible by any Task in the system without restriction. This memory can be shared between all address spaces and will always appear at the same address in any address space. Shared memory is locked by default and thus is not swappable.
|-
| MEMF_EXECUTABLE
| The memory is used to store executable PowerPC code. This is used two-fold in AmigaOS. First, it allows the system to determine if a function pointer points to real native PowerPC code as opposed to 68k code which needs to be emulated. Second, it prevents common exploits that use stack overflows to execute malicious code. Executable memory is locked by default and thus is not swappable.
|}

=== Memory Attributes ===

Memory allocation on AmigaOS has traditionally been rather complicated. Over time, as new hardware models were released, more memory attribute flags were introduced.

All the various memory allocation functions and strategies have been consolidated and distilled into a single AllocVecTags() function call. Programmers are strongly encouraged to stop using any other function to allocate system memory. Using AllocVecTags() is the only way to guarantee future compatibility with more advanced AmigaOS features yet to come.

If an application does not specify any attributes when allocating memory, the system tries to satisfy the request with the fastest memory available on the system memory lists.

{{Note|title=Make Sure You Have Memory|text=Always check the result of any memory allocation to be sure the type and amount of memory requested is available. Failure to do so will lead to trying to use an non-valid pointer.}}

==== Using Tags ====

The AllocVecTags() function uses a tag list to define what attributes a block of memory must have. The currently supported tags are listed below.

{| class="wikitable"
! Tag (Default)
! Description
|-
| rowspan="4" | AVT_Type
(MEMF_PRIVATE)
|-
| MEMF_PRIVATE: Allocate from the task private heap. This memory will not be visible to any other address space.
|-
| MEMF_SHARED: Allocate from the system shared heap. This memory can be shared between all address spaces and will always appear at the same address in any address space. This memory is locked by default (see AVT_Lock tag below).
|-
| MEMF_EXECUTABLE: Allocate memory that is marked executable. This memory is locked by default (see AVT_Lock tag below).
|-
| AVT_Contiguous
(FALSE)
| Memory allocated with this property is allocated from a contiguous block of physical memory. This makes the memory suitable for DMA purposes when the DMA device does not support scatter/gather operation. For devices that do support scatter/gather use StartDMA() instead.
''Note:'' Physical pages can move at any time, be removed from memory due to paging or otherwise made unavailable unless the memory pages are locked (see LockMemory() function or AVT_Lock tag).
|-
| AVT_Lock
(TRUE or FALSE)
| After allocating memory, lock the associated pages in memory. This will prevent the pages from being moved, swapped out or otherwise being made unavailable. This is useful in conjunction with the AVT_Contiguous tag since it will ensure that the memory will stay contiguous after allocation.
This tag defaults to FALSE for MEMF_PRIVATE allocations and to TRUE for MEMF_SHARED or MEMF_EXECUTABLE.
|-
| AVT_Alignment
(16)
| Define an alignment constraint for the allocated memory block. The returned memory block will be aligned to the given size (in bytes). It's virtual address will be at least a multiple of the AVT_Alignment value.
''Note:'' Alignment values must be powers of two. MEMF_EXECUTABLE memory is always aligned to the current page size.
|-
| AVT_PhysicalAlignment
(16)
| Define an alignment constraint for the allocated memory block physical address. See AVT_Alignment for more information.
''Note:'' This functionality is mainly used for DMA drivers that require a specific alignment. Alignment values must be powers of two. MEMF_EXECUTABLE memory is always aligned to the current page size.
|-
| AVT_ClearWithValue
| Clear the newly allocated memory with the given byte value. If this tag is not given the memory block is not cleared.
|-
| AVT_Wait
(TRUE)
| Wait for the memory subsystem to be available. If TRUE, the calling task will be retired until the memory subsystem is available. This might cause a Forbid() to break. When FALSE and the memory subsystem is not currently available, the function will return immediately and the allocation will fail.
|-
| AVT_NoExpunge
(FALSE)
| If allocation fails because of unavailability, prevent invocation of low memory cleanup handlers. The default is FALSE which means that when memory is not available, cleanup handlers are invoked to try and satisfy the allocation.
|}

==== Using Flags ====

The use of memory flags was the only supported way to allocate memory prior to AmigaOS 4.0. It may be still useful to know more about this obsolete system for porting older applications. For more information about the memory flags system see [[Obsolete Exec Memory Allocation]].

=== Allocating System Memory ===

The following examples show how to allocate memory.

<syntaxhighlight>
APTR apointer = IExec->AllocVecTags(100, TAG_END);

if (apointer == NULL)
{ /* COULDN'T GET MEMORY, EXIT */ }
</syntaxhighlight>

AllocVecTags() returns the address of the first byte of a memory block that is at least 100 bytes in size or NULL if there is not that much free memory. Because there are no tags specified, private memory is assumed so this memory cannot be shared with any other tasks.

In addition to allocating a block of memory, this function keeps track of the size of the memory block, so your application doesn't have to remember it when it deallocates that memory block. The AllocVecTags() function allocates a little more memory to store the size of the memory allocation request.

{{Note|title=Make No Assumptions|It is not legal to peek the longword in front of the returned memory pointer to find out how big the block is. This has always been illegal regardless of what any other documentation may have stated to the contrary. Your application has access to the memory returned by AllocVecTags() and the only guarantee made is that the returned block has n bytes of continuous address space starting at the returned address. Anything outside this area is not to be touched.}}

<syntaxhighlight>
APTR anotherptr = IExec->AllocVecTags(1000,
AVT_Type, MEMF_SHARED,
AVT_Lock, FALSE,
AVT_ClearWithValue, 0,
TAG_END);

if (anotherptr == NULL)
{ /* COULDN'T GET MEMORY, EXIT */ }
</syntaxhighlight>

The example above allocates shared memory which is accessible by any task in the system and clears the memory contents to zero. MEMF_SHARED memory is locked by default for compatibility with the obsolete MEMF_PUBLIC flag. This is by far the most common case when allocating shared memory.

<syntaxhighlight>
APTR lockedmem = IExec->AllocVecTags(3000,
AVT_Type, MEMF_SHARED,
TAG_END);

if (lockedmem == NULL)
{ /* COULDN'T GET MEMORY, EXIT */ }
</syntaxhighlight>

The example above allocated shared memory which is accessible by any task in the system. MEMF_SHARED memory is locked by default so the underlying memory pages are not moveable and cannot be swapped out. Such memory could be used to share memory between a Process and an interrupt routine for example.

If the system free memory list does not contain enough contiguous memory bytes in an area matching your requirements, AllocVecTags() returns a zero. You ''must'' check for this condition.

<syntaxhighlight>
APTR yap = IExec->AllocVec(500, MEMF_CHIP);

if (yap == NULL)
{ /* COULDN'T GET MEMORY, EXIT */ }
</syntaxhighlight>

The deprecated AllocVec() function is used in the example above because it is the only way to allocate MEMF_CHIP memory on a classic Amiga system.

=== Locking System Memory ===

The LockMem() function is used to explicitly lock a memory block. This function will make sure your memory block is not unmapped, swapped out or somehow made inaccessible. Use this function wisely. If there is no good reason to lock memory then do not do it. It will prevent the memory system from optimizing memory layout and may lead to poor performance.

<syntaxhighlight>
IExec->LockMem(mem, 1000);
</syntaxhighlight>

Before deallocating the memory is must be unlocked as well.

<syntaxhighlight>
IExec->UnLockMem(mem, 1000);
</syntaxhighlight>

{{Note|title=''Do not forget to UnlockMem()''|Failure to unlock memory will have adverse affects on the memory system. Locked memory pages cannot be moved so the system cannot optimize the layout of locked memory pages.}}

Be careful to always match the number of locks and the number of unlocks. If something else may have locked memory in the same page and an extraneous UnlockMem() decreases the lock reference counter to 0, that page can be paged out or moved. If that happens, for example, with data used in an interrupt handler or by the device driver which handles the swap partition the system will crash.

=== Freeing System Memory ===

The following examples free the memory chunks shown in the previous calls to AllocVecTags().

<syntaxhighlight>
IExec->FreeVec(apointer);

IExec->FreeVec(anotherptr);

IExec->FreeVec(lockedmem);

IExec->FreeVec(yap);
</syntaxhighlight>

A memory block allocated with AllocVecTags() or AllocVec() must be returned to the system pool with the FreeVec() function. This function uses the stored size in the allocation to free the memory block, so there is no need to specify the size of the memory block to free.

Any memory that is locked must be explicitly unlocked with UnlockMem() prior to freeing it. Failure to unlock memory will not cause any immediate problems but any pages which are locked cannot be moved or swapped out which can decrease system performance.

FreeVec() returns no status. However, if you attempt to free a memory block in the middle of a chunk that the system believes is already free, you will cause a system crash. It is also illegal to free the same memory block twice and this will lead to a system crash.

{{Note|title=''Leave Memory Allocations Out Of Interrupt Code''|text=Do not allocate or deallocate system memory from within interrupt code. The [[Exec_Interrupts|Exec Interrupts]] section explains that an interrupt may occur at any time, even during a memory allocation process. As a result, system data structures may not be internally consistent at this time.}}

=== Memory may be Locked by Default ===

By default, the system memory allocation routines will allocate MEMF_SHARED and MEMF_EXECUTABLE memory and implicitly lock it. This memory must not be explicitly unlocked. Let the system handle the unlocking internally.

Here is the right way to allocate and free MEMF_SHARED memory:
<syntaxhighlight>
APTR ptr = IExec->AllocVecTags(10,
AVT_Type, MEMF_SHARED,
TAG_END);
IExec->FreeVec(ptr);
</syntaxhighlight>

Here is the wrong way:
<syntaxhighlight>
APTR ptr = IExec->AllocVecTags(10,
AVT_Type, MEMF_SHARED,
TAG_END);
IExec->UnlockMem(ptr, 10); // Doing this could lead to undefined system behaviour.
IExec->FreeVec(ptr);
</syntaxhighlight>

Unlocking memory not explicitly locked does not immediately cause any issues. However, in a future version of AmigaOS the memory pages may be handled differently than they are handled today. This could lead to incompatibilities with your applications and AmigaOS. The simple rule is that if you called LockMem() you must also call UnlockMem(). All other times you should not call UnlockMem().

{{Note|Memory locking is done at the page level. Even if a single byte of memory is locked in a page that entire page is locked. The programmer has no control over which pages may be used to satisfy a memory allocation.}}

{{Note|Shared and executable memory is locked implicitly for 68K backwards compatibility reasons. Use AVT_Lock (or equivalent) to ensure your shared and executable memory is not locked. MEMF_PRIVATE memory has no backwards compatibility issues and is always unlocked by default.}}

=== Memory Information Functions ===

The memory information routines AvailMem() and TypeOfMem() can provide the amount of memory available in the system, and the attributes of a particular block of memory.

==== Memory Requirements ====

The same attribute flags used in memory allocation routines are valid for the memory information routines. There is also an additional flag, MEMF_LARGEST, which can be used in the AvailMem() routine to find out what the largest available memory block of a particular type is. Specifying the MEMF_TOTAL flag will return the total amount of memory currently available.

==== Calling Memory Information Functions ====

The following example shows how to find out how much memory of a particular type is available.

<syntaxhighlight>
uint32 size = IExec->AvailMem(MEMF_CHIP | MEMF_LARGEST);
</syntaxhighlight>

AvailMem() returns the size of the largest chunk of available chip memory.

{{Note|title=''AvailMem() May Not Be Totally Accurate''|text=Because of multitasking, the return value from AvailMem() may be inaccurate by the time you receive it.}}

The following example shows how to determine the type of memory of a specified memory address.

<syntaxhighlight>
uint32 memtype = IExec->TypeOfMem((APTR)0x090000);
if ((memtype & MEMF_CHIP) == MEMF_CHIP) { /* ... It's chip memory ... */ }
</syntaxhighlight>

TypeOfMem() returns the attributes of the memory at a specific address. If it is passed an invalid memory address, TypeOfMem() returns NULL. This routine is normally used to determine if a particular chunk of memory is in chip memory.

=== Using Memory Copy Functions ===

For memory block copies, the CopyMem() and CopyMemQuick() functions can be used.

==== Copying System Memory ====

The following samples show how to use the copying routines.

<syntaxhighlight>
APTR source = IExec->AllocVecTags(1000, AVT_ClearWithValue, 0, TAG_END);
APTR target = IExec->AllocVecTags(1000, AVT_Type, MEMF_SHARED, TAG_END);
IExec->CopyMem(source, target, 1000);
</syntaxhighlight>

CopyMem() copies the specified number of bytes from the source data region to the target data region. The pointers to the regions can be aligned on arbitrary address boundaries. CopyMem() will attempt to copy the memory as efficiently as it can according to the alignment of the memory blocks, and the amount of data that it has to transfer. These functions are optimized for copying large blocks of memory which can result in unnecessary overhead if used to transfer very small blocks of memory.

CopyMemQuick() is now identical to CopyMem(). In previous versions of the operating system, CopyMemQuick() performed more optimized copying of the specified number of bytes from the source data region to the target data region. The source and target pointers must be longword aligned and the size (in bytes) must be divisible by four. There are no such restrictions starting with AmigaOS 4.0.

{{Note|title=''Not All Copies Are Supported''|text=Neither CopyMem() nor CopyMemQuick() supports copying between regions that overlap. For overlapping regions see MoveMem() in the [[Utility Library]].}}

=== System Memory Pools ===

A construct carried over from the AmigaOS 3.x Exec is the memory pool. The code handling memory pools uses an algorithm based on boundary tags and size-segregated memory lists. The speed gain is tremendous: even for the "dumb" case of just allocating 100000 blocks and freeing them again, the speed is ten times faster than the previous implementation. Due to the size-segregated free lists and the easy coalescing due to the boundary tags, real-life performance gain is even higher and would be between 10 and 20 times.

Two types of memory pools are available depending on the needs of the application:
* [[Exec_Item_Pools|Item Pools]] are built for speed and are used for allocating large numbers of items that are all the same size.
* Generic [[Exec_Memory_Pools|Memory Pools]] can handle allocations of different sizes at the expense of some speed.

=== Summary of System Controlled Memory Handling Routines ===

; AllocVecTags() and FreeVec()
: These are system-wide memory allocation and deallocation routines. They use a memory free-list owned and managed by the system.

; LockMem() and UnlockMem()
: These routines explicitly lock and unlock underlying memory pages.

; AvailMem()
: This routine returns the number of free bytes in a specified type of memory.

; TypeOfMem()
: This routine returns the memory attributes of a specified memory address.

; CopyMem() and CopyMemQuick()
: CopyMem() is a general purpose memory copy routine. CopyMemQuick() is an optimized version of CopyMemQuick(), but has restrictions on the size and alignment of the arguments.

== Allocating DMA Memory ==

Device drivers often use DMA to transfer data to and from the device. The StartDMA(), GetDMAList() and EndDMA() functions are used to create a scatter/gather list suitable for such DMA transfers.

The following conditions are guaranteed to be met when using these DMA functions:
* The memory region given is guaranteed to be mapped to physical memory.
* The mapping will not change as long as EndDMA() is not called.
* All cache entries in this region will be flushed out.

The example code below demonstrates how to perform a DMA write transfer:

<syntaxhighlight>
APTR addr;
uint32 size;

/* Tell the system to prepare for DMA */
uint32 arraySize = IExec->StartDMA(addr, size, 0);
if (arraySize > 0)
{
/* The memory area is prepared, allocate and retrieve the DMA list */
struct DMAEntry *DMAList = IExec->AllocSysObject(ASOT_DMAENTRY,
ASODMAE_NumEntries, arraySize,
TAG_END);

if (DMAList != NULL)
{
IExec->GetDMAList(addr, size, 0, DMAList);

/* Feed the DMA controller and do stuff */
...
/* Get rid of the DMAList's memory */

IExec->EndDMA(addr, size, endFlags);
IExec->FreeSysObject(ASOT_DMAENTRY, DMAList);
}
else
{
// Note We still call EndDMA() even though the actual
// transfer didn't happen.
IExec->EndDMA(addr, size, DMAF_NoModify);

IDOS->Printf("Can't allocate DMA list\n");
}
}
else
{
IDOS->Printf("Can't initiate DMA transfer\n");
}
</syntaxhighlight>

== Syncing and Memory Access ==

The PowerPC is a pure load/store architecture. That means, it will never operate on memory arguments like x86, to modify data, you have to load, modify and store.

All PowerPC/POWER cpus have a load/store queue, i.e. a queue where load and store operations are queued to reduce memory latency. If more than one store is made to the same long word (i.e. you write the first byte and then the second byte), then those stores are combined. As you can see, this will cause a problem for a chip register since both are written at the same time which is likely not what you want.

Similar for reading: A read might shortcut through the load/store queue and use a value that's already been read and is present in the load/store queue. Again, for chip registers, this will cause a problem because you might read an old value.

There are two instructions that deal with this: '''eieio''' (Ensure In-order Execution of I/O) and '''sync'''.

The eieio instruction simply inserts a "barrier" into the load/store queue. When combining ''stores'' the CPU never searches past this barrier for possible combines. This means that the sequence

# store to some address
# eieio
# store to some address + 1

will never be combined because of the eieio barrier between them.

The sync instruction will simply halt all execution and flush the load/store queue, executing and finishing all loads and stores.

As you can imagine, sync is MUCH MORE costly than eieio.

=== When to use eieio and sync ===

If you want to write, post fix your writes with an eieio instruction.

If you want to read, prefix your reads with a sync instruction.

This is also where the "GUARDED" memory flag comes in. GUARDED memory simply ensures program order of loads and stores, that is, it's an implicit eieio.

{{Note|Knowing when and how to use the '''eieio''' and '''sync''' instructions is somewhat vital for driver developers.}}

== Allocating Multiple Memory Blocks ==

Exec provides the routines AllocTaskMemEntry() and FreeEntry() to allocate multiple memory blocks in a single call.

AllocTaskMemEntry() accepts a data structure called a MemList, which contains the information about the size of the memory blocks to be allocated and the requirements, if any, that you have regarding the allocation.

The MemList structure is found in the include file <exec/memory.h> and is defined as follows:

<syntaxhighlight>
struct MemList
{
struct Node ml_Node;
UWORD ml_NumEntries; /* number of MemEntrys */
struct MemEntry ml_ME[1]; /* where the MemEntrys begin*/
};
</syntaxhighlight>

; ml_Node
: allows you to link together multiple MemLists. However, the node is ignored by the routines AllocTaskMemEntry() and FreeEntry().

; ml_NumEntries
: tells the system how many MemEntry sets are contained in this MemList. Notice that a MemList is a variable-length structure and can contain as many sets of entries as you wish.

The MemEntry structure looks like this:

<syntaxhighlight>
struct MemEntry
{
union {
ULONG meu_Reqs; /* the AllocMem requirements */
APTR meu_Addr; /* address of your memory */
} me_Un;
ULONG me_Length; /* the size of this request */
};
</syntaxhighlight>

=== Sample Code for Allocating Multiple Memory Blocks ===

Here's an example of showing how to use the AllocTaskMemEntry() with multiple blocks of memory.

<syntaxhighlight>
// alloctaskmementry.c - example of allocating several memory areas.
#include <exec/types.h>
#include <exec/memory.h>
#include <proto/exec.h>
#include <proto/dos.h>

struct MemList *memlist; /* pointer to a MemList structure */

struct MemBlocks /* define a new structure because C cannot initialize unions */
{
struct MemList mn_head; /* one entry in the header */
struct MemEntry mn_body[3]; /* additional entries follow directly as */
} memblocks; /* part of the same data structure */

int main()
{
memblocks.mn_head.ml_NumEntries = 4; /* 4! Since the MemEntry starts at 1! */

/* Describe the first piece of memory we want. Because of our MemBlocks structure */
/* setup, we reference the first MemEntry differently when initializing it. */
memblocks.mn_head.ml_ME[0].me_Reqs = MEMF_CLEAR;
memblocks.mn_head.ml_ME[0].me_Length = 4000;

memblocks.mn_body[0].me_Reqs = MEMF_PRIVATE | MEMF_CLEAR;/* Describe the other pieces of */
memblocks.mn_body[0].me_Length = 100000; /* memory we want. Additional */
memblocks.mn_body[1].me_Reqs = MEMF_SHARED | MEMF_CLEAR; /* MemEntries are initialized this */
memblocks.mn_body[1].me_Length = 200000; /* way. If we wanted even more en- */
memblocks.mn_body[2].me_Reqs = MEMF_EXECUTABLE; /* tries, we would need to declare */
memblocks.mn_body[2].me_Length = 25000; /* a larger MemEntry array in our */
/* MemBlocks structure. */

memlist = (struct MemList *)IExec->AllocTaskMemEntry((struct MemList *)&memblocks);

if (memlist == NULL)
{
IDOS->Printf("AllocTaskMemEntry FAILED\n");
return RETURN_FAIL;
}

/* We got all memory we wanted. Use it and call FreeEntry() to free it */
IDOS->Printf("AllocTaskMemEntry succeeded - now freeing all allocated blocks\n");
IExec->FreeEntry(memlist);

return 0;
}
</syntaxhighlight>

AllocTaskMemEntry() returns a pointer to a new MemList of the same size as the MemList that you passed to it. For example, ROM code can provide a MemList containing the requirements of a task and create a RAM-resident copy of the list containing the addresses of the allocated entries. The pointer to the MemList is used as the argument for FreeEntry() to free the memory blocks.

=== Result of Allocating Multiple Memory Blocks ===

The MemList created by AllocTaskMemEntry() contains MemEntry entries. MemEntrys are defined by a union statement, which allows one memory space to be defined in more than one way.

If AllocTaskMemEntry() returns a non-NULL value then all of the meu_Addr positions in the returned MemList will contain valid memory addresses meeting the requirements you have provided. To use this memory area, you would use code similar to the following:

<syntaxhighlight>
struct MemList *mlist = IExec->AllocTaskMemEntry(&ML);
APTR memory = NULL;

if ( mlist != NULL )
{
memory = mlist->ml_ME[0].me_Un.meu_Addr;
}
</syntaxhighlight>

=== Multiple Memory Blocks and Tasks ===

If you want to take advantage of Exec's automatic cleanup, use the MemList and AllocTaskMemEntry() facility to do your dynamic memory allocation.

In the Task control block structure, there is a list header named tc_MemEntry.

This is the list header that you initialize to include MemLists that your task has created by call(s) to AllocTaskMemEntry(). Here is a short program segment that handles task memory list header initialization only. It assumes that you have already run AllocTaskMemEntry() as shown in the simple AllocTaskMemEntry() example above.

<syntaxhighlight>
struct MemList *ml;

struct Task *tc = IExec->FindTask(0);

IExec->AddTail(tc->tc_MemEntry, ml);
</syntaxhighlight>

Assuming that you have only used the AllocTaskMemEntry() method (or AllocVecTags() and built your own custom MemList), the system now knows where to find the blocks of memory that your task has dynamically allocated. The RemTask() function automatically frees all memory found on tc_MemEntry.

{{Note|title=''CreateTask() Sets Up A MemList.''|text=The CreateTask() function, and other system task and process creation functions use a MemList in tc_MemEntry so that the Task structure and stack will be automatically deallocated when the Task is removed.}}

=== Summary of Multiple Memory Blocks Allocation Routines ===

These are routines for allocating and freeing multiple memory blocks with a single call.

This routine initializes memory from data and offset values in a table. Typically only assembly language programs benefit from using this routine. See the SDK for more details.

== Allocating Memory at an Absolute Address ==

For special advanced applications, AllocAbs() is provided. Using AllocAbs(), an application can allocate a memory block starting at a specified absolute memory address. If the memory is already allocated or if there is not enough memory available for the request, AllocAbs() returns a zero.

Be aware that an absolute memory address which happens to be available on one Amiga may not be available on a machine with a different configuration or different operating system revision, or even on the same machine at a different times. For example, a piece of memory that is available during expansion board configuration might not be available at earlier or later times. Here is an example call to AllocAbs():

<syntaxhighlight>
APTR absoluteptr = (APTR)IExec->AllocAbs(10000, 0x2F0000);
if (!(absoluteptr))
{ /* Couldn't get memory, act accordingly. */ }

/* After we're done using it, we call FreeMem() to free the memory block. */
IExec->FreeMem(absoluteptr, 10000);
</syntaxhighlight>

== Function Reference ==

The following are brief descriptions of the Exec functions that handle memory management. See the SDK for details on each call.

{| class="wikitable"
! Memory Function
! Description
|-
| AllocMem()
| Allocate memory with specified attributes. '''This function is obsolete.'''
|-
| AllocAbs()
| Allocate memory at a specified location.
|-
| AllocTaskMemEntry()
| Allocate multiple memory blocks.
|-
| AllocVec()
| Allocate memory with specified attributes and keep track of the size. This function is obsolete.
|-
| AllocVecTags()
| Allocate memory with specified attributes defined by tags and keep track of the size. If an application needs to allocate some memory, it will usually use this function.
|-
| AvailMem()
| Return the amount of free memory, given certain conditions.
|-
| CopyMem()
| Copy memory block, which can be non-aligned and of arbitrary length.
|-
| CopyMemQuick()
| Copy aligned memory block.
|-
| FreeEntry()
| Free multiple memory blocks, allocated with AllocTaskMemEntry().
|-
| FreeMem()
| Free a memory block of specified size, allocated with AllocMem() or AllocAbs().
|-
| FreeVec()
| Free a memory block allocated with AllocVecTags() or AllocVec().
|-
| InitStruct()
| Initialize memory from a table.
|-
| LockMem()
| Lock the underlying pages given a memory block address and size.
|-
| TypeOfMem()
| Determine attributes of a specified memory address.
|-
| UnlockMem()
| Unlock the underlying pages given a memory block address and size.
|}

Exec Signals

2021-10-26T03:09:19Z

Steven Solie: /* SIGB_SINGLE Example */

== Exec Signals ==

[[Exec Tasks|Tasks]] often need to coordinate with other concurrent system activities (like other [[Exec Tasks|tasks]] and [[Exec Interrupts|interrupts]]). This coordination is handled by Exec through the synchronized exchange of specific event indicators called ''signals''.

This is the primary mechanism responsible for all inter-task communication and synchronization on the Amiga. This signal mechanism operates at a low level and is designed for high performance. Signals are used extensively by the Exec message system as a way to indicate the arrival of an inter-task message. The message system is described in more detail in [[Exec Messages and Ports]].

{{Note|title=Not for Beginners.|text=This section concentrates on details about signals that most applications do not need to understand for general Amiga programming. For a general overview of signals, see [[Introduction to Exec]].}}

== The Signal System ==

The signal system is designed to support independent simultaneous events, so several signals can occur at the same time. Each task has 32 independent signals, 16 of which are pre-allocated for use by the operating system. The signals in use by a particular task are represented as bits in a 32-bit field in its Task structure (<exec/tasks.h>). Two other 32-bit fields in the Task structure indicate which signals the task is waiting for, and which signals have been received.

Signals are ''task relative''. A task can only allocate its own signals, and may only wait on its own signals. In addition, a task may assign its own significance to a particular signal. Signals are not broadcast to all tasks; they are directed only to individual tasks. A signal has meaning to the task that defined it and to those tasks that have been informed of its meaning.

For example, signal bit 12 may indicate a timeout event to one task, but to another task it may indicate a message arrival event. You can never wait on a signal that you did not directly or indirectly allocate yourself, and any other task that wishes to signal you must use a signal that ''you'' allocated.

=== Signal Allocation ===

As mentioned above, a task assigns its own meaning to a particular signal. Because certain system libraries may occasionally require the use of a signal, there is a convention for signal allocation. It is unwise ever to make assumptions about which signals are actually in use.

Before a signal can be used, it must be allocated with the AllocSignal() function. When a signal is no longer needed, it should be freed for reuse with FreeSignal().

<syntaxhighlight>
BYTE AllocSignal( LONG signalNum );
VOID FreeSignal( LONG signalNum );
</syntaxhighlight>

AllocSignal() marks a signal as being in use and prevents the accidental use of the same signal for more than one event. You may ask for either a specific signal number, or more commonly, you would pass -1 to request the next available signal. The state of the newly allocated signal is cleared (ready for use). Generally it is best to let the system assign you the next free signal. Of the 32 available signals, the lower 16 are reserved for system use (see [[#Reserved_System_Signals|Reserved System Signals]]). This leaves the upper 16 signals free for application programs to allocate. Other subsystems that you may call depend on AllocSignal().

The following example asks for the next free signal to be allocated for its use:

<syntaxhighlight>
if (-1 == (signal = IExec->AllocSignal(-1)))
IDOS->Printf("no signal bits available\n");
else
{
IDOS->Printf("allocated signal number %ld\n", signal);
/* Other code could go here */
IExec->FreeSignal(signal)
}
</syntaxhighlight>

The value returned by AllocSignal() is a signal bit number. This value cannot be used directly in calls to signal-related functions without first being converted to a mask:

<syntaxhighlight>
uint32 mask = 1UL << signal;
or
uint32 mask = (uint32)1 << signal;
</syntaxhighlight>

It is important to realize that signal bit allocation is relevant ''only'' to the running task. You ''cannot'' allocate a signal from another task. Note that functions which create a signal MsgPort will allocate a signal from the task that calls the function. Such functions include OpenWindow() and AllocSysObject(). For this reason, only the creating task may Wait() (directly or indirectly) on the MsgPort's signal. Functions which call Wait() include DoIO(), WaitIO() and WaitPort().

=== Waiting for a Signal ===

Signals are most often used to wake up a task upon the occurrence of some external event. Applications call the Exec Wait() function, directly or indirectly, in order to enter a wait state until some external event triggers a signal which awakens the task.

Though signals are usually not used to interrupt an executing task, they can be used this way. Task ''exceptions'', described in [[Exec_Interrupts|Exec Interrupts]], allow signals to act as a task-local interrupt.

The Wait() function specifies the set of signals that will wake up the task and then puts the task to sleep (into the waiting state).

<syntaxhighlight>
ULONG Wait( ULONG signalSet );
</syntaxhighlight>

Any one signal or any combination of signals from this set are sufficient to awaken the task. Wait() returns a mask indicating which signals satisfied the Wait() call. Note that when signals are used in conjunction with a message port, a set signal bit does not necessarily mean that there is a message at the message port.

See [[Exec_Messages_and_Ports|Exec Messages and Ports]] for details about proper handling of messages.

Because tasks (and interrupts) normally execute asynchronously, it is often possible to receive a particular signal before a task actually Wait()s for it. In such cases the Wait() will be immediately satisfied, and the task will not be put to sleep.

The Wait() function implicitly clears those signal bits that satisfied the wait condition. This effectively resets those signals for reuse. However, keep in mind that a task might get more signals while it is still processing the previous signal. If the same signal is received multiple times and the signal bit is not cleared between them, some signals will go unnoticed.

Be aware that using Wait() will break a Forbid() or Disable() state. Wait() cannot be used in supervisor mode or within interrupts.

A task may Wait() for a combination of signal bits and will wake up when any of the signals occur. Wait() returns a signal mask specifying which signal or signals were received. Usually the program must check the returned mask for each signal it was waiting on and take the appropriate action for each that occurred. The order in which these bits are checked is often important.

Here is a hypothetical example of a process that is using the console and timer devices, and is waiting for a message from either device and a possible break character issued by the user:

<syntaxhighlight>
uint32 consoleSignal = 1L << ConsolePort->mp_SigBit;
uint32 timerSignal = 1L << TimerPort->mp_SigBit;
uint32 userSignal = SIGBREAKF_CTRL_C; /* Defined in <dos/dos.h> */

uint32 signals = IExec->Wait(consoleSignal | timerSignal | userSignal);

if (signals & consoleSignal)
IDOS->Printf("new character\n");

if (signals & timeOutSignal)
IDOS->Printf("timeout\n");

if (signals & userSignal)
IDOS->Printf("User Ctrl-C Abort\n");
</syntaxhighlight>

This code will put the task to sleep waiting for a new character, or the expiration of a time period, or a <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">Ctrl</kbd> + <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">C</kbd> break character issued by the user. Notice that this code checks for an incoming character signal before checking for a timeout. Although a program can check for the occurrence of a particular event by checking whether its signal has occurred, this may lead to busy wait polling. Such polling is wasteful of the processor and is usually harmful to the proper function of the Amiga system. However, if a program needs to do constant processing and also check signals (a compiler for example) SetSignal(0,0) can be used to get a copy of your task's current signals.

<syntaxhighlight>
ULONG SetSignal( ULONG newSignals, ULONG signalSet );
</syntaxhighlight>

SetSignal() can also be used to set or clear the state of the signals. Implementing this can be dangerous and should generally not be done. The following fragment illustrates a possible use of SetSignal().

<syntaxhighlight>
uint32 signals = SetSignal(0,0); /* Get current state of signals */

if (signals & SIGBREAKF_CTRL_C) /* Check for Ctrl-C. */
{
IDOS->Printf("Break\n"); /* Ctrl-C signal has been set. */
IExec->SetSignal(0, SIGBREAKF_CTRL_C) /* Clear Ctrl-C signal. */
}
</syntaxhighlight>

==== Looking for Break Keys ====

One common usage of signals on the Amiga is for processing a user break. The OS reserves 16 of a tasks 32 signals for system use. Four of those 16 signals are used to tell a task about the <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">Ctrl</kbd> + <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">C</kbd>, <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">D</kbd>, <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">E</kbd>, and <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">F</kbd> break keys. An application can process these signals. Usually, only CLI-based programs receive these signals because the Amiga's console handler is about the only user input source that sets these signals when it sees the <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">Ctrl</kbd> + <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">C</kbd>, <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">D</kbd>, <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">E</kbd>, and <kbd class="keyboard-key nowrap" style="border: 1px solid #aaa; border-radius: 0.2em; box-shadow: 0.1em 0.2em 0.2em #ddd; background-color: #f9f9f9; background-image: -moz-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -o-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: -webkit-linear-gradient(top, #eee, #f9f9f9, #eee); background-image: linear-gradient(to bottom, #eee, #f9f9f9, #eee); padding: 0.1em 0.3em; font-family: inherit; font-size: 0.85em;">F</kbd> key presses.

The signal masks for each of these key presses are defined in <dos/dos.h>:

<syntaxhighlight>
SIGBREAKF_CTRL_C
SIGBREAKF_CTRL_D
SIGBREAKF_CTRL_E
SIGBREAKF_CTRL_F
</syntaxhighlight>

Note that these are ''bit masks'' and '''not''' ''bit numbers''.

=== Generating a Signal ===

Signals may be generated from both tasks and system interrupts with the Signal() function.

<syntaxhighlight>
VOID Signal( struct Task *task, ULONG signalSet );
</syntaxhighlight>

For example Signal(tc,mask) would signal the task with the specified mask signals. More than one signal can be specified in the mask. The following example code illustrates Wait() and Signal().

<syntaxhighlight>
// signals.c

#include <exec/types.h>
#include <exec/memory.h>
#include <dos/dos.h>

#include <proto/exec.h>
#include <proto/dos.h>

static CONST_STRPTR VersTag = "$VER: signals 53.1 (20.6.2012)";

void subtaskcode(void); /* prototype for our subtask routine */

struct Task *maintask = NULL;
uint32 mainsig = 0;

int main()
{
BOOL Done = FALSE;
BOOL WaitingForSubtask = TRUE;

/* We must allocate any special signals we want to receive. */
int8 mainsignum = IExec->AllocSignal(-1);
if (mainsignum == -1)
IDOS->Printf("No signals available\n");
else
{
mainsig = 1U << mainsignum; /* subtask can access this global */
maintask = IExec->FindTask(NULL); /* subtask can access this global */

IDOS->Printf("We alloc a signal, create a task, wait for signals\n");

struct Task *subtask = IDOS->CreateTaskTags("subtask", 0, subtaskcode, 16000, TAG_END);

if (subtask == NULL)
IDOS->Printf("Can't create subtask\n");
else
{
IDOS->Printf("After subtask signals, press CTRL-C or CTRL-D to exit\n");

while (!Done || WaitingForSubtask)
{
/* Wait on the combined mask for all of the signals we are
* interested in. All processes have the CTRL_C thru CTRL_F
* signals. We're also Waiting on the mainsig we allocated
* for our subtask to signal us with. We could also Wait on
* the signals of any ports/windows our main task created ... */

uint32 wakeupsigs = IExec->Wait(mainsig | SIGBREAKF_CTRL_C | SIGBREAKF_CTRL_D);

/* Deal with all signals that woke us up - may be more than one */
if (wakeupsigs & mainsig)
{
IDOS->Printf("Signalled by subtask\n");
WaitingForSubtask = FALSE; /* OK to kill subtask now */
}

if (wakeupsigs & SIGBREAKF_CTRL_C)
{
IDOS->Printf("Got CTRL-C signal\n");
Done = TRUE;
}

if(wakeupsigs & SIGBREAKF_CTRL_D)
{
IDOS->Printf("Got CTRL-D signal\n");
Done = TRUE;
}
}
}

IExec->FreeSignal(mainsignum);
}
}

void subtaskcode(void)
{
IExec->Signal(maintask, mainsig);
IExec->RemTask(0); // Remove myself from the system.
}
</syntaxhighlight>

== Reserved System Signals ==

There are 16 signal bits which are reserved for system use. Applications are never allowed to use these signal bits unless explicitly documented (e.g. SIGF_SINGLE).

=== SIGB_ABORT ===

Reserved for system use.

=== SIGB_CHILD ===

Reserved for system use.

=== SIGB_SINGLE (SIGB_BLIT) ===

When a system function needs a Task to stop and IExec->Wait() for a single signal it will use SIGB_SINGLE.

This signal used to be named SIGB_BLIT when it was used to wait on the classic hardware blitter.

=== SIGB_INTUITION ===

Reserved for system use.

=== SIGB_NET ===

Reserved for system use.

=== SIGB_DOS ===

SIGB_DOS is currently used as the wait signal bit for the embedded message port in the process structure. This message port is initialised by the IDOS->CreateNewProc() function. This message port is used by default for DosPacket transactions via IDOS->DoPkt() and IDOS->WaitPkt() and it is also used for sending the initial ACTION_STARTUP DosPacket for DOS handlers. This message port is also where the workbench.library sends the initial struct WBStartup message to every process it starts.

=== SIGBREAKB_CTRL_C ===

The SIGBREAKB_CTRL_C signal bit is used extensively as the general purpose "Break" signal. It is used by all shell handler commands
and many applications to invoke a normal exit of the program. It is up to all applications to follow this recommendation.

Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_C signal bit from any source.

=== SIGBREAKB_CTRL_D ===

The SIGBREAKB_CTRL_D signal bit is used mostly by the shell handler to stop execution of a script file or non-interactive stream. It may also be used by applications.

Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_D signal bit from any source.

=== SIGBREAKB_CTRL_E ===

The SIGBREAKB_CTRL_E signal bit is not currently used by the shell handler but may be used by some other handlers, OS subsystems or multi-process applications for general undefined inter process signalling.

Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_E signal bit from any source.

=== SIGBREAKB_CTRL_F ===

The SIGBREAKB_CTRL_E signal bit is not currently used by the shell handler but may be used by some other handlers, OS subsystems or multi-process applications for general undefined inter process signalling.

Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_F signal bit from any source.

== Signalling with SIGB_SINGLE ==

Many of a task's 32 signal bits are reserved for the operating system's private use, but, like any good rule, there is an exception. One of these bits, the SIGB_SINGLE bit, can be useful to some applications, if used correctly.

Many system functions need to put their task to sleep while waiting for a single event, which requires using one of the task's signals. Rather than forcing each of these system functions to allocate a signal, then Wait(), then deallocate the signal, the operating system
has permanently allocated one signal, the SIGB_SINGLE, for this type of signalling. When a system function needs stop a task to Wait()
for a single signal, it can use SIGB_SINGLE.

The only purpose a program can use SIGB_SINGLE for is Wait()ing because the task cannot call any system functions while it is using SIGB_SINGLE. A program that calls system functions while using SIGB_SINGLE can cause itself and the operating system serious problems because the system functions can use SIGB_SINGLE as well. If a program calls a system function while using SIGB_SINGLE, two bad
things can happen:

1) The errant task's event takes place before the system function waits on SIGB_SINGLE (or while the system function is waiting on
SIGB_SINGLE). In this case, the system function will think its event has taken place because its signal became set. The errant task will never find out that its event has taken place, as the system function will clear the SIGB_SINGLE bit after Wait()ing on it.

2) The errant task's event and the system function's event take place while the system function is waiting on SIGB_SINGLE. In this case,
the system function will function normally, clear the SIGB_SINGLE bit, and exit. The errant task will never know that its event has
taken place.

Before Wait()ing on SIGB_SINGLE, clear it using SetSignal():

<syntaxhighlight>
IExec->SetSignal(0, SIGF_SINGLE); // Note SIGF_SINGLE is the bit mask. SIGB_SINGLE is the signal bit.
</syntaxhighlight>

This step is necessary because it is possible that the last system function that used the SIGB_SINGLE signal did not clear the SIGB_SINGLE bit.

Also, an application should not wait on other signals while it is waiting on SIGB_SINGLE. Waiting on other signals at the same time
makes it possible for a program to wake up while the SIGB_SINGLE is still outstanding. If this happens, the program will still have to
go back to sleep, which requires calling a system function.

=== SIGB_SINGLE Example ===

Below is a simple example of using the SIGB_SINGLE signal. It starts a child process and waits for that child process to signal
the main process using the SIGB_SINGLE signal.

<syntaxhighlight>
// This example program illustrates simple usage of the SIGB_SINGLE
// signal for "single shot" signalling. This signal is one of the
// system private signals, but applications can use it in certain
// cases, but only if used carefully. Specifically, applications
// should use it only to Wait() on, and using only that signal
// (applications cannot Wait() on other signals in the same
// Wait()). Not following these rules can cause serious system
// problems.

#include <exec/types.h>
#include <exec/memory.h>
#include <dos/dosextens.h>
#include <dos/dostags.h>

#include <proto/exec.h>
#include <proto/dos.h>

#include <stdio.h>

int32 childprocesscode(void); /* prototype for our childprocess routine. */

struct Process *mainprocess = NULL, *childprocess = NULL;
UBYTE childprocessname[] = "RKM_signal_childprocess";

BPTR output;

int main(int argc, char **argv)
{
if (output = IDOS->Open("CONSOLE:", MODE_OLDFILE)) /* Open the console for the */
/* child process. */
{
mainprocess = (struct Process *)IExec->FindTask(NULL); /* childprocess can */
/* access this global.*/

if (childprocess = IDOS->CreateNewProcTags(
NP_Entry, childprocesscode, /* The child process */
NP_Name, childprocessname,
NP_Output, output,
NP_FreeSeglist, FALSE,
NP_CloseOutput, TRUE,
NP_Child, TRUE,
TAG_END))
{
IDOS->Printf("Main Process: Created a child process and waiting on SIGB_SINGLE.\n");

IDOS->FFlush(IDOS->Output()); /* Make sure the Printf() above appears */
/* in the console window before the child */
/* process starts printing to the console. */

IExec->SetSignal(0, SIGF_SINGLE); /* Use SIGF_SINGLE only after */
/* clearing it. */

/* Wake up the child. */
IExec->Signal((struct Task *)childprocess, SIGBREAKF_CTRL_F);

IExec->Wait(SIGF_SINGLE); /* Only use SIGF_SINGLE for Wait()ing and */
/* Wait on that signal alone! */

IDOS->Printf("Main Process: Received signal from child.\n");
}
else
IDOS->Printf("Main Process: Can't create child process. Exiting.\n");
}
else
IDOS->Printf("Main Process: Can't open CONSOLE:. Exiting.\n");
}

int32 childprocesscode(void) /* This function is what CreateNewProcTags() */
{ /* loads as the child process. This child */
/* signals the parent using SIGF_SINGLE. */

/* Wait for a startup signal. This is to allow the parent process to
* print its banner message and clear SIGF_SINGLE.
*/
IExec->Wait(SIGBREAKF_CTRL_F);

IDOS->Printf("Child Process: I'm alive and starting a 5 second TimeDelay()");
IDOS->FFlush(IDOS->Output());

for (uint32 x = 0; x < 5; x++)
{
IDOS->Delay(50); /* Delay for 5 seconds, printing a */
IDOS->Printf(" ."); /* dot during each second. */
}

IDOS->Delay(50);

IDOS->Printf(" Finished.\n");
IDOS->Printf("Child Process: Signalling main process and exiting. Bye.\n");
IDOS->FFlush(IDOS->Output());

IExec->Signal((struct Task *)mainprocess, SIGF_SINGLE); /* Finished waiting, */
/* signal the main */
/* process and exit */
/* child process. */
return 0;
}
</syntaxhighlight>

== Function Reference ==

The following chart gives a brief description of the Exec functions that control task signalling. See the SDK for details about each call.

{| class="wikitable"
! Exec Signal Function
! Description
|-
| AllocSignal()
| Allocate a signal bit.
|-
| FreeSignal()
| Free a signal bit allocated with AllocSignal().
|-
| SetSignal()
| Query or set the state of the signals for the current task.
|-
| Signal()
| Signal a task by setting signal bits in its Task structure.
|-
| Wait()
| Wait for one or more signals from other tasks or interrupts.
|}

Tutorials:Main

2020-01-25T23:04:44Z

Steven Solie: /* Amiga Ireland 2020 */

= Tutorials =

Tutorials have been provided by various authors.

== General ==

[[The Hacking Way: Part 1 - First Steps]]

[[The Right Tool for the Job (Shared Objects)]]

[[How to Build Stubs for 68k Libraries]]

[[How to create an AmigaOS 4 library]]

== Amiga Future Programming Articles ==

[[Programming AmigaOS 4: The Development Environment]]

[[Programming AmigaOS 4: Exec - The Kernel]]

[[Programming AmigaOS 4: DOS - The Data Administrator]]

[[Programming AmigaOS 4: Intuition - The User Interface]]

[[Programming AmigaOS 4: Drawing Graphics]]

[[Programming AmigaOS 4: Transparent Windows]]

[[Programming AmigaOS 4: Datatypes - Making Life Easy]]

[[Programming AmigaOS 4: GUI Toolkit ReAction]]

[[Programming AmigaOS 4: Utility - Little Helpers]]

== Debugging ==

[[How to install a hardware interrupt]]

[[How to open and use the exec debug interface]]

[[GDB for Beginners]]

[[Using Crash-Logs for Debugging]]

[[Debug Logging on AmigaOS]]

[[Redirecting Debug Output to the Serial Port on Startup]]

[[Advanced Serial Debugging Guide]]

== GUI ==

[[BOOPSI Gadget Help Strings]]

[[BOOPSI Popup Menus - Part 1]]

[[BOOPSI Popup Menus - Part 2]]

[[BOOPSI Popup Menus - Part 3]]

[[Screen Programming]]

== Amiga Ireland 2020 ==

[[Media:Execsg-team.pdf|ExecSG Team Presentation Slides]]

== AmiWest 2019 ==

[[AmiWest Setup]]

[[AmiWest 2019 DevCon]]

== AmiWest 2018 ==

[[AmiWest Setup]]

[[AmiWest 2018 DevCon]]

== AmiWest 2017 ==

[[AmiWest Setup]]

[[AmiWest 2017 DevCon]]

== AmiWest 2016 ==

[[AmiWest Setup]]

[[AmiWest 2016 DevCon]]

== AmiWest 2015 ==

[[AmiWest Setup]]

[[AmiWest 2015 DevCon]]

== AmiWest 2014 ==

[[AmiWest Setup]]

[[AmiWest 2014 Programming Seminar]]

== AmiWest 2013 ==

[[AmiWest 2013 Programming Conference Synopsis]]

[[AmiWest Setup]]

[[AmiWest 2013 Lesson 1|AmiWest Lesson 1: How to Crash]]

[[AmiWest 2013 Lesson 2|AmiWest Lesson 2: Interpreting Crash Reports]]

[[AmiWest 2013 Lesson 3|AmiWest Lesson 3: ProcTree Redux]]

[[AmiWest 2013 Lesson 4|AmiWest Lesson 4: Simple IP Clients & Servers]]

[[AmiWest 2013 Lesson 5|AmiWest Lesson 5: Bars&Pipes Tools]]

== AmiWest 2012 ==

[[AmiWest Setup]]

[[AmiWest Lesson 1|AmiWest Lesson 1: Coding Basics]] [https://youtu.be/-m3QSN2Q3LI - Video Part 1] [https://youtu.be/gCStZJD5R6o - Video Part 2]

[[AmiWest Lesson 2|AmiWest Lesson 2: AmigaOS Fundamentals]] [https://youtu.be/0KIsNfIaI_g - Video]

[[AmiWest Lesson 3|AmiWest Lesson 3: Input and Output]] [https://youtu.be/f6X6Gqhtg_s - Video]

[[AmiWest Lesson 4|AmiWest Lesson 4: ProcTree]] [https://youtu.be/6bHYHJu9-7o - Video]

[[AmiWest Lesson 5|AmiWest Lesson 5: MIDI]] [https://youtu.be/_Z-EhEnhh08 - Video]

[[AmiWest Lesson 6|AmiWest Lesson 6: Application Library - Not Presented]]

[[AmiWest Lesson 7|AmiWest Lesson 7: Screen Blanker]] [https://youtu.be/xm9cn1J2pa8 - Video]

[[AmiWest Lesson 8|AmiWest Lesson 8: ARexx Ports]] [https://youtu.be/6osaMcxNhUE - Video]

[[AmiWest Support]] [https://youtu.be/NZyl2CsVcgE - Video]

File:Execsg-team.pdf

2020-01-25T23:02:40Z

Steven Solie: ExecSG Team presentation slides

ExecSG Team presentation slides

Tutorials:Main

2020-01-25T22:59:02Z

Steven Solie: /* Amiga Ireland 2020 */

= Tutorials =

Tutorials have been provided by various authors.

== General ==

[[The Hacking Way: Part 1 - First Steps]]

[[The Right Tool for the Job (Shared Objects)]]

[[How to Build Stubs for 68k Libraries]]

[[How to create an AmigaOS 4 library]]

== Amiga Future Programming Articles ==

[[Programming AmigaOS 4: The Development Environment]]

[[Programming AmigaOS 4: Exec - The Kernel]]

[[Programming AmigaOS 4: DOS - The Data Administrator]]

[[Programming AmigaOS 4: Intuition - The User Interface]]

[[Programming AmigaOS 4: Drawing Graphics]]

[[Programming AmigaOS 4: Transparent Windows]]

[[Programming AmigaOS 4: Datatypes - Making Life Easy]]

[[Programming AmigaOS 4: GUI Toolkit ReAction]]

[[Programming AmigaOS 4: Utility - Little Helpers]]

== Debugging ==

[[How to install a hardware interrupt]]

[[How to open and use the exec debug interface]]

[[GDB for Beginners]]

[[Using Crash-Logs for Debugging]]

[[Debug Logging on AmigaOS]]

[[Redirecting Debug Output to the Serial Port on Startup]]

[[Advanced Serial Debugging Guide]]

== GUI ==

[[BOOPSI Gadget Help Strings]]

[[BOOPSI Popup Menus - Part 1]]

[[BOOPSI Popup Menus - Part 2]]

[[BOOPSI Popup Menus - Part 3]]

[[Screen Programming]]

== Amiga Ireland 2020 ==

[[Media:execsg-team.pdf|ExecSG Team Presentation Slides]]

== AmiWest 2019 ==

[[AmiWest Setup]]

[[AmiWest 2019 DevCon]]

== AmiWest 2018 ==

[[AmiWest Setup]]

[[AmiWest 2018 DevCon]]

== AmiWest 2017 ==

[[AmiWest Setup]]

[[AmiWest 2017 DevCon]]

== AmiWest 2016 ==

[[AmiWest Setup]]

[[AmiWest 2016 DevCon]]

== AmiWest 2015 ==

[[AmiWest Setup]]

[[AmiWest 2015 DevCon]]

== AmiWest 2014 ==

[[AmiWest Setup]]

[[AmiWest 2014 Programming Seminar]]

== AmiWest 2013 ==

[[AmiWest 2013 Programming Conference Synopsis]]

[[AmiWest Setup]]

[[AmiWest 2013 Lesson 1|AmiWest Lesson 1: How to Crash]]

[[AmiWest 2013 Lesson 2|AmiWest Lesson 2: Interpreting Crash Reports]]

[[AmiWest 2013 Lesson 3|AmiWest Lesson 3: ProcTree Redux]]

[[AmiWest 2013 Lesson 4|AmiWest Lesson 4: Simple IP Clients & Servers]]

[[AmiWest 2013 Lesson 5|AmiWest Lesson 5: Bars&Pipes Tools]]

== AmiWest 2012 ==

[[AmiWest Setup]]

[[AmiWest Lesson 1|AmiWest Lesson 1: Coding Basics]] [https://youtu.be/-m3QSN2Q3LI - Video Part 1] [https://youtu.be/gCStZJD5R6o - Video Part 2]

[[AmiWest Lesson 2|AmiWest Lesson 2: AmigaOS Fundamentals]] [https://youtu.be/0KIsNfIaI_g - Video]

[[AmiWest Lesson 3|AmiWest Lesson 3: Input and Output]] [https://youtu.be/f6X6Gqhtg_s - Video]

[[AmiWest Lesson 4|AmiWest Lesson 4: ProcTree]] [https://youtu.be/6bHYHJu9-7o - Video]

[[AmiWest Lesson 5|AmiWest Lesson 5: MIDI]] [https://youtu.be/_Z-EhEnhh08 - Video]

[[AmiWest Lesson 6|AmiWest Lesson 6: Application Library - Not Presented]]

[[AmiWest Lesson 7|AmiWest Lesson 7: Screen Blanker]] [https://youtu.be/xm9cn1J2pa8 - Video]

[[AmiWest Lesson 8|AmiWest Lesson 8: ARexx Ports]] [https://youtu.be/6osaMcxNhUE - Video]

[[AmiWest Support]] [https://youtu.be/NZyl2CsVcgE - Video]

Tutorials:Main

2020-01-25T22:58:48Z

Steven Solie: /* Tutorials */

= Tutorials =

Tutorials have been provided by various authors.

== General ==

[[The Hacking Way: Part 1 - First Steps]]

[[The Right Tool for the Job (Shared Objects)]]

[[How to Build Stubs for 68k Libraries]]

[[How to create an AmigaOS 4 library]]

== Amiga Future Programming Articles ==

[[Programming AmigaOS 4: The Development Environment]]

[[Programming AmigaOS 4: Exec - The Kernel]]

[[Programming AmigaOS 4: DOS - The Data Administrator]]

[[Programming AmigaOS 4: Intuition - The User Interface]]

[[Programming AmigaOS 4: Drawing Graphics]]

[[Programming AmigaOS 4: Transparent Windows]]

[[Programming AmigaOS 4: Datatypes - Making Life Easy]]

[[Programming AmigaOS 4: GUI Toolkit ReAction]]

[[Programming AmigaOS 4: Utility - Little Helpers]]

== Debugging ==

[[How to install a hardware interrupt]]

[[How to open and use the exec debug interface]]

[[GDB for Beginners]]

[[Using Crash-Logs for Debugging]]

[[Debug Logging on AmigaOS]]

[[Redirecting Debug Output to the Serial Port on Startup]]

[[Advanced Serial Debugging Guide]]

== GUI ==

[[BOOPSI Gadget Help Strings]]

[[BOOPSI Popup Menus - Part 1]]

[[BOOPSI Popup Menus - Part 2]]

[[BOOPSI Popup Menus - Part 3]]

[[Screen Programming]]

== Amiga Ireland 2020 ==

[[Media:execsg-team.pdf|ExecSG Team Presentation Slides]].

== AmiWest 2019 ==

[[AmiWest Setup]]

[[AmiWest 2019 DevCon]]

== AmiWest 2018 ==

[[AmiWest Setup]]

[[AmiWest 2018 DevCon]]

== AmiWest 2017 ==

[[AmiWest Setup]]

[[AmiWest 2017 DevCon]]

== AmiWest 2016 ==

[[AmiWest Setup]]

[[AmiWest 2016 DevCon]]

== AmiWest 2015 ==

[[AmiWest Setup]]

[[AmiWest 2015 DevCon]]

== AmiWest 2014 ==

[[AmiWest Setup]]

[[AmiWest 2014 Programming Seminar]]

== AmiWest 2013 ==

[[AmiWest 2013 Programming Conference Synopsis]]

[[AmiWest Setup]]

[[AmiWest 2013 Lesson 1|AmiWest Lesson 1: How to Crash]]

[[AmiWest 2013 Lesson 2|AmiWest Lesson 2: Interpreting Crash Reports]]

[[AmiWest 2013 Lesson 3|AmiWest Lesson 3: ProcTree Redux]]

[[AmiWest 2013 Lesson 4|AmiWest Lesson 4: Simple IP Clients & Servers]]

[[AmiWest 2013 Lesson 5|AmiWest Lesson 5: Bars&Pipes Tools]]

== AmiWest 2012 ==

[[AmiWest Setup]]

[[AmiWest Lesson 1|AmiWest Lesson 1: Coding Basics]] [https://youtu.be/-m3QSN2Q3LI - Video Part 1] [https://youtu.be/gCStZJD5R6o - Video Part 2]

[[AmiWest Lesson 2|AmiWest Lesson 2: AmigaOS Fundamentals]] [https://youtu.be/0KIsNfIaI_g - Video]

[[AmiWest Lesson 3|AmiWest Lesson 3: Input and Output]] [https://youtu.be/f6X6Gqhtg_s - Video]

[[AmiWest Lesson 4|AmiWest Lesson 4: ProcTree]] [https://youtu.be/6bHYHJu9-7o - Video]

[[AmiWest Lesson 5|AmiWest Lesson 5: MIDI]] [https://youtu.be/_Z-EhEnhh08 - Video]

[[AmiWest Lesson 6|AmiWest Lesson 6: Application Library - Not Presented]]

[[AmiWest Lesson 7|AmiWest Lesson 7: Screen Blanker]] [https://youtu.be/xm9cn1J2pa8 - Video]

[[AmiWest Lesson 8|AmiWest Lesson 8: ARexx Ports]] [https://youtu.be/6osaMcxNhUE - Video]

[[AmiWest Support]] [https://youtu.be/NZyl2CsVcgE - Video]

DMA Resource

2019-11-27T04:43:22Z

Steven Solie: /* Author */

== Author ==

Jamie Krueger, BITbyBIT Software Group LLC<br/>
Copyright (c) 2019 Trevor Dickinson<br/>
Used by permission.

== DMA Engine ==

Some hardware targets include a DMA engine which can be used for general purpose copying. This article describes the DMA engines available and how to use them.

=== Hardware Features ===

The Direct Memory Access (DMA) Engines found in the NXP/Freescale p5020, p5040 and p1022 System On a Chip (SoC)s, as found in the AmigaONE X5000/20, X5000/40 and A1222 respectively, are quite flexible and powerful. Each of these chips contains two distinct engines with four data channels each. This provides the ability to have a total of eight DMA Channels working at once, with up to two DMA transactions actually being executed at the same time (one on each of the two DMA Engines).

Further, each of the four DMA Channels found in a DMA Engine may be individually programmed to handle either; a single transaction, a ''Chain'' of transactions, or even ''Lists'' of ''Chains'' of transactions. The DMA Engines automatically arbitrate control between each DMA Channel following programmed bandwidth settings for each Channel (typically 1024 bytes).

This means that after completing a transfer of 1024 bytes (for example), the hardware will consider switching to the next Channel to allow it to move another block of data, and so on in a round-robin fashion. If all other DMA Channels on a given DMA Engine are idle when arbitration would take place, the hardware will not arbitrate control to another Channel, but simply continue processing the transaction(s) for the Channel it is on.

=== DMA Copy Memory - Execution Flow Diagram ===

[[File:DMACopyMem-Diagram.png]]

=== What a call to perform a DMA copy does internally ===

As shown in the above diagram, when the user makes a call to request a memory copy be performed by the DMA hardware, the next available DMA Channel is selected for use and a DMA Transaction (source, destination and size) is constructed. The DMA Transaction is then programmed into the DMA Engine which owns the available DMA Channel.

At this point the calling task will Wait() until it hears the transaction has been completed. It will then return to the caller with the result. This provides a basic ''blocking'' function, which only returns to the caller once that data has been copied. This single tasking behavior is the simplest to use and what is normally expected by most applications using a memory copy function.

=== Diagram of multitasking DMA Copies ===

[[File:DMACopyMem-Multitasking-Diagram.png]]

=== How multiple simultaneous DMA copies are handled ===

When multiple user calls requesting a DMA copy arrive at once, each one is handed to a dedicated DMA Channel handling task for processing. As the diagram above demonstrates, there are two separate DMA Engines available, each with four channels that may be programmed at the same time. The hardware will then arbitrate the actual data move across these channels according to their respective bandwidth settings (usually 1024 bytes).

In the diagram above, a separate color indicates a distinct data path from the caller through the DMA hardware to the system RAM. A dashed line of the matching color indicates an Interrupt line signaling the respective DMA Channel Handler with the completion of the transaction. The handler task then signals back to the original caller, which returns to the user with a success or failure result.

All eight DMA Channels can handle each a single block transaction or an entire chain of block transactions before it signals completion and returns to the original caller. If all eight DMA Channels are busy processing their requested transactions when further DMA copy requests arrive, they will each be assigned a DMA Channel to wait on (managed via a Mutex lock on each Channel) and will block until allowed to add their DMA transaction to the Channel's queue.

== fsldma.resource ==

The fsldma.resource API is provided automatically in the kernel for all supported machines (Currently the AmigaONE X5000/20, X5000/40 and A1222).

=== The FslDMA API ===

The API provided by the fsldma.resource breaks down into three main parts:
:* Memory management
:* Copy Memory functions
:* Utility / Miscellaneous

==== Memory Management Functions ====

The FslDMA resource API provides convenience functions for the allocation and freeing of '''DMA Compliant''' blocks of memory. Two functions are provided for this purpose; DMAAllocPhysicalMemory() and DMAFreePhysicalMemory().

The memory allocation function also includes two Tags based versions of the call to allow for addition variables to be passed into the call using a variable set of Tags or fixed TagList. Currently the only supported Tag is ''FSLDMA_APM_ClearWithValue'', which is the equivalent to the IExec->AllocVecTagList() function's AVT_ClearWithValue tag. If the FSLDMA_APM_ClearWithValue tag is not provided then the requested memory block is cleared with zeroes by default before being returned. DMAAllocPhysicalMemory() returns the ''Physical'' Address pointer to the allocated memory or NULL if it is unable to allocate the requested memory.

<syntaxhighlight>
APTR DMAAllocPhysicalMemoryTagList( uint32 lSize, const struct TagItem *tags );
APTR DMAAllocPhysicalMemoryTags( uint32 lSize, uint32 Tag1, ... );
APTR DMAAllocPhysicalMemory( uint32 lSize );
</syntaxhighlight>

The corresponding function to allocating a DMA Compliant memory block is DMAFreePhysicalMemory(). Any memory allocated using DMAAllocPhysicalMemory() must be eventually freed using DMAFreePhysicalMemory().

<syntaxhighlight>
void DMAFreePhysicalMemory( APTR pPhysicalMemoryBlock );
</syntaxhighlight>

==== Copy Memory Functions ====

Two API calls make up the core of the FslDMA API; DMAPhysicalCopyMem() and DMACopyMem().
Both of these calls will "block" (not return to the user) until after the requested transfer has either succeeded or failed. A value of TRUE is returned upon success and FALSE if an error occurred.

<syntaxhighlight>
BOOL DMAPhysicalCopyMem( CONST_APTR pPhysicalSourceBuffer, APTR pPhysicalDestBuffer, uint32 lBufferSize );
BOOL DMACopyMem( CONST_APTR pSourceBuffer, APTR pDestBuffer, uint32 lBufferSize );
</syntaxhighlight>

As the name implies the first (and core version) of the copy memory functions, DMAPhysicalCopyMem(), accepts the Physical Addresses to the source and destination buffers (as returned by DMAAllocPhysicalMemory()), along with an unsigned 32-Bit value for the amount of bytes that should be copied (lBuffsize must be greater than zero(0) and no more than the maximum size of the source and destination buffers).

DMAPhysicalCopyMem() is the most direct an efficient means of using the DMA hardware to effect a single memory copy. The DMACopyMem() function is provided as an alternative way to request a DMA transfer by passing in the ''Virtual Addresses'' to the source and destination buffers instead of the Physical Addresses. DMACopyMem() will attempt to determine if the supplied memory buffers are DMA Compliant and if so it will internally use DMAPhysicalCopyMem() to handle the transaction. If DMACopyMem() determines that the supplied memory is '''not''' DMA Compliant it will return FALSE and no data copy will occur.

In theory any ''contiguous'' block of memory from 1 Byte up to 4GB in size may be transferred using either one of these calls. In practice the DMA hardware can directly accept memory blocks up to FSLDMA_MAXBLOCK_SIZE (or 64MB - 1 Byte). Therefore any data blocks greater than FSLDMA_MAXBLOCK_SIZE will automatically be feed to the DMA hardware in a series of smaller chunks. For maximum efficiency transfer sizes should be at least 256 Bytes in size and be an even multiple of 64 Bytes. Odd sizes are handled by the hardware but will degrade performance.

If you are transferring many large blocks of data in series and wish to manually send them to the FslDMA API's memory copy functions one block at a time, then setting your block sizes to FSLDMA_OPTIMAL_BLKSIZE (or 64 MB - 64 Bytes) and exclusively using DMAPhysicalCopyMem() will provide the fastest transfer speeds will the least amount of CPU overhead.

==== Utility / Miscellaneous Functions ====

The last section to the FslDMA API provides a single convenience function call; DMAGetVirtualAddress().

<syntaxhighlight>
APTR DMAGetVirtualAddress( APTR pPhysicalAddress );
</syntaxhighlight>

The DMAGetVirtualAddress() function returns the Virtual memory location for the Physical memory location that was itself allocated and returned by the DMAAllocPhysicalMemory() function. DMAGetVirtualAddress() will not work on physical addresses returned by IMMU->GetPhysicalAddress() on memory not allocated using DMAAllocPhysicalMemory().

The main purpose of this function (other then debugging purposes) is to provide the "normal" Virtual Address of memory allocated by the FslDMA API for use by functions that expect "normal" Virtual address locations; for example IExec->CopyMemQuick().

==== Further reference - The fsldma.resource AutoDoc ====

See the [[http://wiki.amigaos.net/amiga/autodocs/fsldmares.doc.txt fsldma.resource AutoDoc]] file for more details on each API call.

=== Example usage ===
<syntaxhighlight>
#include <interfaces/fsldma.h>
// Obtain the fsldma.resource
struct fslDMAIFace *IfslDMA = IExec->OpenResource(FSLDMA_NAME);
if ( NULL != IfslDMA )
{
uint32 lTestSize = 1024;
CONST_APTR pPhysicalSrcAddr = NULL;
APTR pPhysicalDestAddr = NULL;
// Allocate the Source Buffer (for DMA)
// and set the contents to 0xB3 (just an example value)
pPhysicalSrcAddr = (CONST_APTR)IfslDMA->DMAAllocPhysicalMemoryTags(lTestSize,
FSLDMA_APM_ClearWithValue, 0xB3,
TAG_END);
if ( NULL != pPhysicalSrcAddr )
{
// Allocate the Destination Buffer (for DMA)
// - contents will by cleared by default
pPhysicalDestAddr = IfslDMA->DMAAllocPhysicalMemory(lTestSize);
if ( NULL != pPhysicalDestAddr )
{
// Call IfslDMA->DMAPhysicalCopyMem()
// to perform the memory copy using the DMA hardware
if ( TRUE == IfslDMA->DMAPhysicalCopyMem(pPhysicalSrcAddr,
pPhysicalDestAddr,lTestSize) )
{
// Success - Do something with the copied data
}
else
{
// Fallback and use CPU Copy instead (or do something else)
// Since we allocated the memory buffers using the FslDMA API,
// which returns the Physical address to that memory, and the
// IExec->CopyMemQuick() function expects the Virtual address,
// we first need to obtain the Virtual address for the Physical
// ones (using the FslDMA API again) before we can call our
// fallback copy function.
CONST_APTR pVirtualSrcAddr = NULL;
APTR pVirtualDestAddr = NULL;
pVirtualSrcAddr = IfslDMA->DMAGetVirtualAddress((APTR)pPhysicalSrcAddr);
pVirtualDestAddr = IfslDMA->DMAGetVirtualAddress(pPhysicalDestAddr);
IExec->CopyMemQuick(pVirtualSrcAddr,pVirtualDestAddr,lTestSize);
}
// We *must* use DMAFreePhysicalMemory() to free the memory
// that we allocated with DMAAllocPhysicalMemory()
IfslDMA->DMAFreePhysicalMemory(pPhysicalDestAddr);
}
// We *must* use DMAFreePhysicalMemory() to free the memory
// that we allocated with DMAAllocPhysicalMemory()
IfslDMA->DMAFreePhysicalMemory((APTR)pPhysicalSrcAddr);
}
}
</syntaxhighlight>

==== Obtaining the fsldma.resource ====

Breaking the above example down the first thing we do is include the interface header for the fsldma.resource and obtain the resource itself.

<syntaxhighlight>
#include <interfaces/fsldma.h>
struct fslDMAIFace *IfslDMA = IExec->OpenResource(FSLDMA_NAME);
</syntaxhighlight>

==== Allocating DMA Compliant Memory ====

Once we have successfully obtained the DMA resource we can directly use its API. The next step we need to do is to allocate some memory '''which we know is DMA compliant''' for use by the resource. The easiest way to accomplish this is to use the IfslDMA->DMAAllocPhysicalMemory() function. This will automatically take care of ensuring the memory that is returned is properly aligned, contiguous, cache-inhibited and coherent.

We use the Tags version of the allocate memory function first so we can allocate a block of memory for our source buffer and fill it with some test value (in this case the byte value 0xB3).

<syntaxhighlight>
pPhysicalSrcAddr = (CONST_APTR)IfslDMA->DMAAllocPhysicalMemoryTags(lTestSize,
FSLDMA_APM_ClearWithValue, 0xB3,
TAG_END);
</syntaxhighlight>

We also need a destination buffer for our test. Since it only needs to start out being cleared (filled with zeroes), we can use the simplest form of the allocate memory function here as the allocated memory is cleared by default.

<syntaxhighlight>
pPhysicalDestAddr = IfslDMA->DMAAllocPhysicalMemory(lTestSize);
</syntaxhighlight>

==== The core function - Copy Physical Memory ====

Now that we have two DMA Compliant memory buffers available we can get to the heart of the API usage and make the call to IfslDMA->DMAPhysicalCopyMem().

<syntaxhighlight>
IfslDMA->DMAPhysicalCopyMem(pPhysicalSrcAddr,pPhysicalDestAddr,lTestSize);
</syntaxhighlight>

Looking at the full [[#Example usage|Example]] source above you can see that the DMAPhysicalCopyMem() call returns a Boolean value to indicate success or failure. Therefore, TRUE will be returned after the DMA hardware had completed copying the requested data (blocking call) and FALSE will be returned if a problem occurred.

Since the memory buffers we are using were allocated using the FslDMA API and our transfer size was greater than zero and less than or equal to the total size of either buffer, (in others words a legal copy request), there is '''very''' little chance that the DMAPhysicalCopyMem() function will fail. In fact, about the only reason the DMA hardware would fail to handle a legal transaction would be if the physical RAM installed in the system was faulty.

So even though it is extremely unlikely for our DMA copy to have failed and returned FALSE, let's take a look at how we might handle the failure. In other words, falling back and using a CPU based copy function instead to complete the data move.

Since we are reverting back to using a normal system copy memory function here, we first need to obtain the ''Virtual Addresses'' to both our source and destination buffers. This is accomplished by using the DMAGetVirtualAddress() function and passing in the Physical Address that was returned by DMAAllocPhysicalMemory().

<syntaxhighlight>
CONST_APTR pVirtualSrcAddr = NULL;
APTR pVirtualDestAddr = NULL;
pVirtualSrcAddr = IfslDMA->DMAGetVirtualAddress((APTR)pPhysicalSrcAddr);
pVirtualDestAddr = IfslDMA->DMAGetVirtualAddress(pPhysicalDestAddr);
</syntaxhighlight>

Now that we have the Virtual Address equivalents to the Physical Addresses that were returned by DMAAllocPhysicalMemory(), we can proceed to call the Exec CopyMemQuick() function to complete the copy. Here we can only trust that the IExec->CopyMemQuick() call can not fail since it does not return a result code.

<syntaxhighlight>
IExec->CopyMemQuick(pVirtualSrcAddr,pVirtualDestAddr,lTestSize);
</syntaxhighlight>

==== Cleaning up - Freeing DMA Compliant memory ====

It is essential that you free any memory that was allocated using the DMAAllocPhysicalMemory() function using the corresponding DMAFreePhysicalMemory() call. The reason for this is two-fold; first because additional resource tracking is maintained by the FslDMA API whenever it allocates memory which must itself be released, and second because the ''Physical Address'' to the memory is returned by the allocate call and not the ''Virtual Address'', so if you attempt to pass the address returned by DMAAllocPhysicalMemory() directly into IExec->FreeVec() it would likely result in a crash.

<syntaxhighlight>
IfslDMA->DMAFreePhysicalMemory(pPhysicalSrcAddr);
IfslDMA->DMAFreePhysicalMemory(pPhysicalDestAddr);
</syntaxhighlight>

== Performance ==

Testing DMA memory copies vs their CPU based equivalent indicates that the DMA hardware on all three models (X5000/20, X5000/40 and A1222)
move data approximately two to three times faster than the CPU does so alone.

It should also be noted that these tests were performed when the CPU was effectively idle. CPU memory copy operations scale down roughly
equal with the CPU actively scaling up. So the more the CPU is doing, the longer it takes to complete the memory copy.

Conversely, DMA memory copy operation times are far more predictable as they use the same amount of (minimal) CPU overhead for each copy,
and the actual time it takes the DMA hardware to complete the transaction can be calculated to range from all the DMA Channels being idle,
to all DMA Channels being busy at once and data moves arbitrating between channels every 1024 bytes.

=== Optimal use of the DMA Engine ===

To gain the best performance from the DMA Engines, block sizes of 256 bytes or more should be used.
Also, if possible the size should be an even multiple of at least 4 bytes.

Additionally the memory blocks (source and destination) should be aligned to start on a 64 Byte boundary.
Alignment requirements are one of items taken care of for you by the DMAAllocPhysicalMemory() function.

The DMA Engine can and does handle misaligned and odd sized data blocks by first shifting the minimum
required bytes to correct the alignment, then taking smaller chunks of data until the largest chunk of
the block can be moved. It can also handle copies of as little as one byte (don't do this).

However, this does degrade performance.

In general, the larger the data block the better.

DMA Resource

2019-11-27T04:42:30Z

Steven Solie: /* Author */

== Author ==

Jamie Krueger<br/>
Copyright (c) 2019 Trevor Dickinson<br/>
Used by permission.

== DMA Engine ==

Some hardware targets include a DMA engine which can be used for general purpose copying. This article describes the DMA engines available and how to use them.

=== Hardware Features ===

The Direct Memory Access (DMA) Engines found in the NXP/Freescale p5020, p5040 and p1022 System On a Chip (SoC)s, as found in the AmigaONE X5000/20, X5000/40 and A1222 respectively, are quite flexible and powerful. Each of these chips contains two distinct engines with four data channels each. This provides the ability to have a total of eight DMA Channels working at once, with up to two DMA transactions actually being executed at the same time (one on each of the two DMA Engines).

Further, each of the four DMA Channels found in a DMA Engine may be individually programmed to handle either; a single transaction, a ''Chain'' of transactions, or even ''Lists'' of ''Chains'' of transactions. The DMA Engines automatically arbitrate control between each DMA Channel following programmed bandwidth settings for each Channel (typically 1024 bytes).

This means that after completing a transfer of 1024 bytes (for example), the hardware will consider switching to the next Channel to allow it to move another block of data, and so on in a round-robin fashion. If all other DMA Channels on a given DMA Engine are idle when arbitration would take place, the hardware will not arbitrate control to another Channel, but simply continue processing the transaction(s) for the Channel it is on.

=== DMA Copy Memory - Execution Flow Diagram ===

[[File:DMACopyMem-Diagram.png]]

=== What a call to perform a DMA copy does internally ===

As shown in the above diagram, when the user makes a call to request a memory copy be performed by the DMA hardware, the next available DMA Channel is selected for use and a DMA Transaction (source, destination and size) is constructed. The DMA Transaction is then programmed into the DMA Engine which owns the available DMA Channel.

At this point the calling task will Wait() until it hears the transaction has been completed. It will then return to the caller with the result. This provides a basic ''blocking'' function, which only returns to the caller once that data has been copied. This single tasking behavior is the simplest to use and what is normally expected by most applications using a memory copy function.

=== Diagram of multitasking DMA Copies ===

[[File:DMACopyMem-Multitasking-Diagram.png]]

=== How multiple simultaneous DMA copies are handled ===

When multiple user calls requesting a DMA copy arrive at once, each one is handed to a dedicated DMA Channel handling task for processing. As the diagram above demonstrates, there are two separate DMA Engines available, each with four channels that may be programmed at the same time. The hardware will then arbitrate the actual data move across these channels according to their respective bandwidth settings (usually 1024 bytes).

In the diagram above, a separate color indicates a distinct data path from the caller through the DMA hardware to the system RAM. A dashed line of the matching color indicates an Interrupt line signaling the respective DMA Channel Handler with the completion of the transaction. The handler task then signals back to the original caller, which returns to the user with a success or failure result.

All eight DMA Channels can handle each a single block transaction or an entire chain of block transactions before it signals completion and returns to the original caller. If all eight DMA Channels are busy processing their requested transactions when further DMA copy requests arrive, they will each be assigned a DMA Channel to wait on (managed via a Mutex lock on each Channel) and will block until allowed to add their DMA transaction to the Channel's queue.

== fsldma.resource ==

The fsldma.resource API is provided automatically in the kernel for all supported machines (Currently the AmigaONE X5000/20, X5000/40 and A1222).

=== The FslDMA API ===

The API provided by the fsldma.resource breaks down into three main parts:
:* Memory management
:* Copy Memory functions
:* Utility / Miscellaneous

==== Memory Management Functions ====

The FslDMA resource API provides convenience functions for the allocation and freeing of '''DMA Compliant''' blocks of memory. Two functions are provided for this purpose; DMAAllocPhysicalMemory() and DMAFreePhysicalMemory().

The memory allocation function also includes two Tags based versions of the call to allow for addition variables to be passed into the call using a variable set of Tags or fixed TagList. Currently the only supported Tag is ''FSLDMA_APM_ClearWithValue'', which is the equivalent to the IExec->AllocVecTagList() function's AVT_ClearWithValue tag. If the FSLDMA_APM_ClearWithValue tag is not provided then the requested memory block is cleared with zeroes by default before being returned. DMAAllocPhysicalMemory() returns the ''Physical'' Address pointer to the allocated memory or NULL if it is unable to allocate the requested memory.

<syntaxhighlight>
APTR DMAAllocPhysicalMemoryTagList( uint32 lSize, const struct TagItem *tags );
APTR DMAAllocPhysicalMemoryTags( uint32 lSize, uint32 Tag1, ... );
APTR DMAAllocPhysicalMemory( uint32 lSize );
</syntaxhighlight>

The corresponding function to allocating a DMA Compliant memory block is DMAFreePhysicalMemory(). Any memory allocated using DMAAllocPhysicalMemory() must be eventually freed using DMAFreePhysicalMemory().

<syntaxhighlight>
void DMAFreePhysicalMemory( APTR pPhysicalMemoryBlock );
</syntaxhighlight>

==== Copy Memory Functions ====

Two API calls make up the core of the FslDMA API; DMAPhysicalCopyMem() and DMACopyMem().
Both of these calls will "block" (not return to the user) until after the requested transfer has either succeeded or failed. A value of TRUE is returned upon success and FALSE if an error occurred.

<syntaxhighlight>
BOOL DMAPhysicalCopyMem( CONST_APTR pPhysicalSourceBuffer, APTR pPhysicalDestBuffer, uint32 lBufferSize );
BOOL DMACopyMem( CONST_APTR pSourceBuffer, APTR pDestBuffer, uint32 lBufferSize );
</syntaxhighlight>

As the name implies the first (and core version) of the copy memory functions, DMAPhysicalCopyMem(), accepts the Physical Addresses to the source and destination buffers (as returned by DMAAllocPhysicalMemory()), along with an unsigned 32-Bit value for the amount of bytes that should be copied (lBuffsize must be greater than zero(0) and no more than the maximum size of the source and destination buffers).

DMAPhysicalCopyMem() is the most direct an efficient means of using the DMA hardware to effect a single memory copy. The DMACopyMem() function is provided as an alternative way to request a DMA transfer by passing in the ''Virtual Addresses'' to the source and destination buffers instead of the Physical Addresses. DMACopyMem() will attempt to determine if the supplied memory buffers are DMA Compliant and if so it will internally use DMAPhysicalCopyMem() to handle the transaction. If DMACopyMem() determines that the supplied memory is '''not''' DMA Compliant it will return FALSE and no data copy will occur.

In theory any ''contiguous'' block of memory from 1 Byte up to 4GB in size may be transferred using either one of these calls. In practice the DMA hardware can directly accept memory blocks up to FSLDMA_MAXBLOCK_SIZE (or 64MB - 1 Byte). Therefore any data blocks greater than FSLDMA_MAXBLOCK_SIZE will automatically be feed to the DMA hardware in a series of smaller chunks. For maximum efficiency transfer sizes should be at least 256 Bytes in size and be an even multiple of 64 Bytes. Odd sizes are handled by the hardware but will degrade performance.

If you are transferring many large blocks of data in series and wish to manually send them to the FslDMA API's memory copy functions one block at a time, then setting your block sizes to FSLDMA_OPTIMAL_BLKSIZE (or 64 MB - 64 Bytes) and exclusively using DMAPhysicalCopyMem() will provide the fastest transfer speeds will the least amount of CPU overhead.

==== Utility / Miscellaneous Functions ====

The last section to the FslDMA API provides a single convenience function call; DMAGetVirtualAddress().

<syntaxhighlight>
APTR DMAGetVirtualAddress( APTR pPhysicalAddress );
</syntaxhighlight>

The DMAGetVirtualAddress() function returns the Virtual memory location for the Physical memory location that was itself allocated and returned by the DMAAllocPhysicalMemory() function. DMAGetVirtualAddress() will not work on physical addresses returned by IMMU->GetPhysicalAddress() on memory not allocated using DMAAllocPhysicalMemory().

The main purpose of this function (other then debugging purposes) is to provide the "normal" Virtual Address of memory allocated by the FslDMA API for use by functions that expect "normal" Virtual address locations; for example IExec->CopyMemQuick().

==== Further reference - The fsldma.resource AutoDoc ====

See the [[http://wiki.amigaos.net/amiga/autodocs/fsldmares.doc.txt fsldma.resource AutoDoc]] file for more details on each API call.

=== Example usage ===
<syntaxhighlight>
#include <interfaces/fsldma.h>
// Obtain the fsldma.resource
struct fslDMAIFace *IfslDMA = IExec->OpenResource(FSLDMA_NAME);
if ( NULL != IfslDMA )
{
uint32 lTestSize = 1024;
CONST_APTR pPhysicalSrcAddr = NULL;
APTR pPhysicalDestAddr = NULL;
// Allocate the Source Buffer (for DMA)
// and set the contents to 0xB3 (just an example value)
pPhysicalSrcAddr = (CONST_APTR)IfslDMA->DMAAllocPhysicalMemoryTags(lTestSize,
FSLDMA_APM_ClearWithValue, 0xB3,
TAG_END);
if ( NULL != pPhysicalSrcAddr )
{
// Allocate the Destination Buffer (for DMA)
// - contents will by cleared by default
pPhysicalDestAddr = IfslDMA->DMAAllocPhysicalMemory(lTestSize);
if ( NULL != pPhysicalDestAddr )
{
// Call IfslDMA->DMAPhysicalCopyMem()
// to perform the memory copy using the DMA hardware
if ( TRUE == IfslDMA->DMAPhysicalCopyMem(pPhysicalSrcAddr,
pPhysicalDestAddr,lTestSize) )
{
// Success - Do something with the copied data
}
else
{
// Fallback and use CPU Copy instead (or do something else)
// Since we allocated the memory buffers using the FslDMA API,
// which returns the Physical address to that memory, and the
// IExec->CopyMemQuick() function expects the Virtual address,
// we first need to obtain the Virtual address for the Physical
// ones (using the FslDMA API again) before we can call our
// fallback copy function.
CONST_APTR pVirtualSrcAddr = NULL;
APTR pVirtualDestAddr = NULL;
pVirtualSrcAddr = IfslDMA->DMAGetVirtualAddress((APTR)pPhysicalSrcAddr);
pVirtualDestAddr = IfslDMA->DMAGetVirtualAddress(pPhysicalDestAddr);
IExec->CopyMemQuick(pVirtualSrcAddr,pVirtualDestAddr,lTestSize);
}
// We *must* use DMAFreePhysicalMemory() to free the memory
// that we allocated with DMAAllocPhysicalMemory()
IfslDMA->DMAFreePhysicalMemory(pPhysicalDestAddr);
}
// We *must* use DMAFreePhysicalMemory() to free the memory
// that we allocated with DMAAllocPhysicalMemory()
IfslDMA->DMAFreePhysicalMemory((APTR)pPhysicalSrcAddr);
}
}
</syntaxhighlight>

==== Obtaining the fsldma.resource ====

Breaking the above example down the first thing we do is include the interface header for the fsldma.resource and obtain the resource itself.

<syntaxhighlight>
#include <interfaces/fsldma.h>
struct fslDMAIFace *IfslDMA = IExec->OpenResource(FSLDMA_NAME);
</syntaxhighlight>

==== Allocating DMA Compliant Memory ====

Once we have successfully obtained the DMA resource we can directly use its API. The next step we need to do is to allocate some memory '''which we know is DMA compliant''' for use by the resource. The easiest way to accomplish this is to use the IfslDMA->DMAAllocPhysicalMemory() function. This will automatically take care of ensuring the memory that is returned is properly aligned, contiguous, cache-inhibited and coherent.

We use the Tags version of the allocate memory function first so we can allocate a block of memory for our source buffer and fill it with some test value (in this case the byte value 0xB3).

<syntaxhighlight>
pPhysicalSrcAddr = (CONST_APTR)IfslDMA->DMAAllocPhysicalMemoryTags(lTestSize,
FSLDMA_APM_ClearWithValue, 0xB3,
TAG_END);
</syntaxhighlight>

We also need a destination buffer for our test. Since it only needs to start out being cleared (filled with zeroes), we can use the simplest form of the allocate memory function here as the allocated memory is cleared by default.

<syntaxhighlight>
pPhysicalDestAddr = IfslDMA->DMAAllocPhysicalMemory(lTestSize);
</syntaxhighlight>

==== The core function - Copy Physical Memory ====

Now that we have two DMA Compliant memory buffers available we can get to the heart of the API usage and make the call to IfslDMA->DMAPhysicalCopyMem().

<syntaxhighlight>
IfslDMA->DMAPhysicalCopyMem(pPhysicalSrcAddr,pPhysicalDestAddr,lTestSize);
</syntaxhighlight>

Looking at the full [[#Example usage|Example]] source above you can see that the DMAPhysicalCopyMem() call returns a Boolean value to indicate success or failure. Therefore, TRUE will be returned after the DMA hardware had completed copying the requested data (blocking call) and FALSE will be returned if a problem occurred.

Since the memory buffers we are using were allocated using the FslDMA API and our transfer size was greater than zero and less than or equal to the total size of either buffer, (in others words a legal copy request), there is '''very''' little chance that the DMAPhysicalCopyMem() function will fail. In fact, about the only reason the DMA hardware would fail to handle a legal transaction would be if the physical RAM installed in the system was faulty.

So even though it is extremely unlikely for our DMA copy to have failed and returned FALSE, let's take a look at how we might handle the failure. In other words, falling back and using a CPU based copy function instead to complete the data move.

Since we are reverting back to using a normal system copy memory function here, we first need to obtain the ''Virtual Addresses'' to both our source and destination buffers. This is accomplished by using the DMAGetVirtualAddress() function and passing in the Physical Address that was returned by DMAAllocPhysicalMemory().

<syntaxhighlight>
CONST_APTR pVirtualSrcAddr = NULL;
APTR pVirtualDestAddr = NULL;
pVirtualSrcAddr = IfslDMA->DMAGetVirtualAddress((APTR)pPhysicalSrcAddr);
pVirtualDestAddr = IfslDMA->DMAGetVirtualAddress(pPhysicalDestAddr);
</syntaxhighlight>

Now that we have the Virtual Address equivalents to the Physical Addresses that were returned by DMAAllocPhysicalMemory(), we can proceed to call the Exec CopyMemQuick() function to complete the copy. Here we can only trust that the IExec->CopyMemQuick() call can not fail since it does not return a result code.

<syntaxhighlight>
IExec->CopyMemQuick(pVirtualSrcAddr,pVirtualDestAddr,lTestSize);
</syntaxhighlight>

==== Cleaning up - Freeing DMA Compliant memory ====

It is essential that you free any memory that was allocated using the DMAAllocPhysicalMemory() function using the corresponding DMAFreePhysicalMemory() call. The reason for this is two-fold; first because additional resource tracking is maintained by the FslDMA API whenever it allocates memory which must itself be released, and second because the ''Physical Address'' to the memory is returned by the allocate call and not the ''Virtual Address'', so if you attempt to pass the address returned by DMAAllocPhysicalMemory() directly into IExec->FreeVec() it would likely result in a crash.

<syntaxhighlight>
IfslDMA->DMAFreePhysicalMemory(pPhysicalSrcAddr);
IfslDMA->DMAFreePhysicalMemory(pPhysicalDestAddr);
</syntaxhighlight>

== Performance ==

Testing DMA memory copies vs their CPU based equivalent indicates that the DMA hardware on all three models (X5000/20, X5000/40 and A1222)
move data approximately two to three times faster than the CPU does so alone.

It should also be noted that these tests were performed when the CPU was effectively idle. CPU memory copy operations scale down roughly
equal with the CPU actively scaling up. So the more the CPU is doing, the longer it takes to complete the memory copy.

Conversely, DMA memory copy operation times are far more predictable as they use the same amount of (minimal) CPU overhead for each copy,
and the actual time it takes the DMA hardware to complete the transaction can be calculated to range from all the DMA Channels being idle,
to all DMA Channels being busy at once and data moves arbitrating between channels every 1024 bytes.

=== Optimal use of the DMA Engine ===

To gain the best performance from the DMA Engines, block sizes of 256 bytes or more should be used.
Also, if possible the size should be an even multiple of at least 4 bytes.

Additionally the memory blocks (source and destination) should be aligned to start on a 64 Byte boundary.
Alignment requirements are one of items taken care of for you by the DMAAllocPhysicalMemory() function.

The DMA Engine can and does handle misaligned and odd sized data blocks by first shifting the minimum
required bytes to correct the alignment, then taking smaller chunks of data until the largest chunk of
the block can be moved. It can also handle copies of as little as one byte (don't do this).

However, this does degrade performance.

In general, the larger the data block the better.

DMA Resource

2019-11-27T04:42:09Z

Steven Solie: /* DMA Engine */

== Author ==

Jamie Krueger
Copyright (c) 2019 Trevor Dickinson
Used by permission.

== DMA Engine ==

Some hardware targets include a DMA engine which can be used for general purpose copying. This article describes the DMA engines available and how to use them.

=== Hardware Features ===

The Direct Memory Access (DMA) Engines found in the NXP/Freescale p5020, p5040 and p1022 System On a Chip (SoC)s, as found in the AmigaONE X5000/20, X5000/40 and A1222 respectively, are quite flexible and powerful. Each of these chips contains two distinct engines with four data channels each. This provides the ability to have a total of eight DMA Channels working at once, with up to two DMA transactions actually being executed at the same time (one on each of the two DMA Engines).

Further, each of the four DMA Channels found in a DMA Engine may be individually programmed to handle either; a single transaction, a ''Chain'' of transactions, or even ''Lists'' of ''Chains'' of transactions. The DMA Engines automatically arbitrate control between each DMA Channel following programmed bandwidth settings for each Channel (typically 1024 bytes).

This means that after completing a transfer of 1024 bytes (for example), the hardware will consider switching to the next Channel to allow it to move another block of data, and so on in a round-robin fashion. If all other DMA Channels on a given DMA Engine are idle when arbitration would take place, the hardware will not arbitrate control to another Channel, but simply continue processing the transaction(s) for the Channel it is on.

=== DMA Copy Memory - Execution Flow Diagram ===

[[File:DMACopyMem-Diagram.png]]

=== What a call to perform a DMA copy does internally ===

As shown in the above diagram, when the user makes a call to request a memory copy be performed by the DMA hardware, the next available DMA Channel is selected for use and a DMA Transaction (source, destination and size) is constructed. The DMA Transaction is then programmed into the DMA Engine which owns the available DMA Channel.

At this point the calling task will Wait() until it hears the transaction has been completed. It will then return to the caller with the result. This provides a basic ''blocking'' function, which only returns to the caller once that data has been copied. This single tasking behavior is the simplest to use and what is normally expected by most applications using a memory copy function.

=== Diagram of multitasking DMA Copies ===

[[File:DMACopyMem-Multitasking-Diagram.png]]

=== How multiple simultaneous DMA copies are handled ===

When multiple user calls requesting a DMA copy arrive at once, each one is handed to a dedicated DMA Channel handling task for processing. As the diagram above demonstrates, there are two separate DMA Engines available, each with four channels that may be programmed at the same time. The hardware will then arbitrate the actual data move across these channels according to their respective bandwidth settings (usually 1024 bytes).

In the diagram above, a separate color indicates a distinct data path from the caller through the DMA hardware to the system RAM. A dashed line of the matching color indicates an Interrupt line signaling the respective DMA Channel Handler with the completion of the transaction. The handler task then signals back to the original caller, which returns to the user with a success or failure result.

All eight DMA Channels can handle each a single block transaction or an entire chain of block transactions before it signals completion and returns to the original caller. If all eight DMA Channels are busy processing their requested transactions when further DMA copy requests arrive, they will each be assigned a DMA Channel to wait on (managed via a Mutex lock on each Channel) and will block until allowed to add their DMA transaction to the Channel's queue.

== fsldma.resource ==

The fsldma.resource API is provided automatically in the kernel for all supported machines (Currently the AmigaONE X5000/20, X5000/40 and A1222).

=== The FslDMA API ===

The API provided by the fsldma.resource breaks down into three main parts:
:* Memory management
:* Copy Memory functions
:* Utility / Miscellaneous

==== Memory Management Functions ====

The FslDMA resource API provides convenience functions for the allocation and freeing of '''DMA Compliant''' blocks of memory. Two functions are provided for this purpose; DMAAllocPhysicalMemory() and DMAFreePhysicalMemory().

The memory allocation function also includes two Tags based versions of the call to allow for addition variables to be passed into the call using a variable set of Tags or fixed TagList. Currently the only supported Tag is ''FSLDMA_APM_ClearWithValue'', which is the equivalent to the IExec->AllocVecTagList() function's AVT_ClearWithValue tag. If the FSLDMA_APM_ClearWithValue tag is not provided then the requested memory block is cleared with zeroes by default before being returned. DMAAllocPhysicalMemory() returns the ''Physical'' Address pointer to the allocated memory or NULL if it is unable to allocate the requested memory.

<syntaxhighlight>
APTR DMAAllocPhysicalMemoryTagList( uint32 lSize, const struct TagItem *tags );
APTR DMAAllocPhysicalMemoryTags( uint32 lSize, uint32 Tag1, ... );
APTR DMAAllocPhysicalMemory( uint32 lSize );
</syntaxhighlight>

The corresponding function to allocating a DMA Compliant memory block is DMAFreePhysicalMemory(). Any memory allocated using DMAAllocPhysicalMemory() must be eventually freed using DMAFreePhysicalMemory().

<syntaxhighlight>
void DMAFreePhysicalMemory( APTR pPhysicalMemoryBlock );
</syntaxhighlight>

==== Copy Memory Functions ====

Two API calls make up the core of the FslDMA API; DMAPhysicalCopyMem() and DMACopyMem().
Both of these calls will "block" (not return to the user) until after the requested transfer has either succeeded or failed. A value of TRUE is returned upon success and FALSE if an error occurred.

<syntaxhighlight>
BOOL DMAPhysicalCopyMem( CONST_APTR pPhysicalSourceBuffer, APTR pPhysicalDestBuffer, uint32 lBufferSize );
BOOL DMACopyMem( CONST_APTR pSourceBuffer, APTR pDestBuffer, uint32 lBufferSize );
</syntaxhighlight>

As the name implies the first (and core version) of the copy memory functions, DMAPhysicalCopyMem(), accepts the Physical Addresses to the source and destination buffers (as returned by DMAAllocPhysicalMemory()), along with an unsigned 32-Bit value for the amount of bytes that should be copied (lBuffsize must be greater than zero(0) and no more than the maximum size of the source and destination buffers).

DMAPhysicalCopyMem() is the most direct an efficient means of using the DMA hardware to effect a single memory copy. The DMACopyMem() function is provided as an alternative way to request a DMA transfer by passing in the ''Virtual Addresses'' to the source and destination buffers instead of the Physical Addresses. DMACopyMem() will attempt to determine if the supplied memory buffers are DMA Compliant and if so it will internally use DMAPhysicalCopyMem() to handle the transaction. If DMACopyMem() determines that the supplied memory is '''not''' DMA Compliant it will return FALSE and no data copy will occur.

In theory any ''contiguous'' block of memory from 1 Byte up to 4GB in size may be transferred using either one of these calls. In practice the DMA hardware can directly accept memory blocks up to FSLDMA_MAXBLOCK_SIZE (or 64MB - 1 Byte). Therefore any data blocks greater than FSLDMA_MAXBLOCK_SIZE will automatically be feed to the DMA hardware in a series of smaller chunks. For maximum efficiency transfer sizes should be at least 256 Bytes in size and be an even multiple of 64 Bytes. Odd sizes are handled by the hardware but will degrade performance.

If you are transferring many large blocks of data in series and wish to manually send them to the FslDMA API's memory copy functions one block at a time, then setting your block sizes to FSLDMA_OPTIMAL_BLKSIZE (or 64 MB - 64 Bytes) and exclusively using DMAPhysicalCopyMem() will provide the fastest transfer speeds will the least amount of CPU overhead.

==== Utility / Miscellaneous Functions ====

The last section to the FslDMA API provides a single convenience function call; DMAGetVirtualAddress().

<syntaxhighlight>
APTR DMAGetVirtualAddress( APTR pPhysicalAddress );
</syntaxhighlight>

The DMAGetVirtualAddress() function returns the Virtual memory location for the Physical memory location that was itself allocated and returned by the DMAAllocPhysicalMemory() function. DMAGetVirtualAddress() will not work on physical addresses returned by IMMU->GetPhysicalAddress() on memory not allocated using DMAAllocPhysicalMemory().

The main purpose of this function (other then debugging purposes) is to provide the "normal" Virtual Address of memory allocated by the FslDMA API for use by functions that expect "normal" Virtual address locations; for example IExec->CopyMemQuick().

==== Further reference - The fsldma.resource AutoDoc ====

See the [[http://wiki.amigaos.net/amiga/autodocs/fsldmares.doc.txt fsldma.resource AutoDoc]] file for more details on each API call.

=== Example usage ===
<syntaxhighlight>
#include <interfaces/fsldma.h>
// Obtain the fsldma.resource
struct fslDMAIFace *IfslDMA = IExec->OpenResource(FSLDMA_NAME);
if ( NULL != IfslDMA )
{
uint32 lTestSize = 1024;
CONST_APTR pPhysicalSrcAddr = NULL;
APTR pPhysicalDestAddr = NULL;
// Allocate the Source Buffer (for DMA)
// and set the contents to 0xB3 (just an example value)
pPhysicalSrcAddr = (CONST_APTR)IfslDMA->DMAAllocPhysicalMemoryTags(lTestSize,
FSLDMA_APM_ClearWithValue, 0xB3,
TAG_END);
if ( NULL != pPhysicalSrcAddr )
{
// Allocate the Destination Buffer (for DMA)
// - contents will by cleared by default
pPhysicalDestAddr = IfslDMA->DMAAllocPhysicalMemory(lTestSize);
if ( NULL != pPhysicalDestAddr )
{
// Call IfslDMA->DMAPhysicalCopyMem()
// to perform the memory copy using the DMA hardware
if ( TRUE == IfslDMA->DMAPhysicalCopyMem(pPhysicalSrcAddr,
pPhysicalDestAddr,lTestSize) )
{
// Success - Do something with the copied data
}
else
{
// Fallback and use CPU Copy instead (or do something else)
// Since we allocated the memory buffers using the FslDMA API,
// which returns the Physical address to that memory, and the
// IExec->CopyMemQuick() function expects the Virtual address,
// we first need to obtain the Virtual address for the Physical
// ones (using the FslDMA API again) before we can call our
// fallback copy function.
CONST_APTR pVirtualSrcAddr = NULL;
APTR pVirtualDestAddr = NULL;
pVirtualSrcAddr = IfslDMA->DMAGetVirtualAddress((APTR)pPhysicalSrcAddr);
pVirtualDestAddr = IfslDMA->DMAGetVirtualAddress(pPhysicalDestAddr);
IExec->CopyMemQuick(pVirtualSrcAddr,pVirtualDestAddr,lTestSize);
}
// We *must* use DMAFreePhysicalMemory() to free the memory
// that we allocated with DMAAllocPhysicalMemory()
IfslDMA->DMAFreePhysicalMemory(pPhysicalDestAddr);
}
// We *must* use DMAFreePhysicalMemory() to free the memory
// that we allocated with DMAAllocPhysicalMemory()
IfslDMA->DMAFreePhysicalMemory((APTR)pPhysicalSrcAddr);
}
}
</syntaxhighlight>

==== Obtaining the fsldma.resource ====

Breaking the above example down the first thing we do is include the interface header for the fsldma.resource and obtain the resource itself.

<syntaxhighlight>
#include <interfaces/fsldma.h>
struct fslDMAIFace *IfslDMA = IExec->OpenResource(FSLDMA_NAME);
</syntaxhighlight>

==== Allocating DMA Compliant Memory ====

Once we have successfully obtained the DMA resource we can directly use its API. The next step we need to do is to allocate some memory '''which we know is DMA compliant''' for use by the resource. The easiest way to accomplish this is to use the IfslDMA->DMAAllocPhysicalMemory() function. This will automatically take care of ensuring the memory that is returned is properly aligned, contiguous, cache-inhibited and coherent.

We use the Tags version of the allocate memory function first so we can allocate a block of memory for our source buffer and fill it with some test value (in this case the byte value 0xB3).

<syntaxhighlight>
pPhysicalSrcAddr = (CONST_APTR)IfslDMA->DMAAllocPhysicalMemoryTags(lTestSize,
FSLDMA_APM_ClearWithValue, 0xB3,
TAG_END);
</syntaxhighlight>

We also need a destination buffer for our test. Since it only needs to start out being cleared (filled with zeroes), we can use the simplest form of the allocate memory function here as the allocated memory is cleared by default.

<syntaxhighlight>
pPhysicalDestAddr = IfslDMA->DMAAllocPhysicalMemory(lTestSize);
</syntaxhighlight>

==== The core function - Copy Physical Memory ====

Now that we have two DMA Compliant memory buffers available we can get to the heart of the API usage and make the call to IfslDMA->DMAPhysicalCopyMem().

<syntaxhighlight>
IfslDMA->DMAPhysicalCopyMem(pPhysicalSrcAddr,pPhysicalDestAddr,lTestSize);
</syntaxhighlight>

Looking at the full [[#Example usage|Example]] source above you can see that the DMAPhysicalCopyMem() call returns a Boolean value to indicate success or failure. Therefore, TRUE will be returned after the DMA hardware had completed copying the requested data (blocking call) and FALSE will be returned if a problem occurred.

Since the memory buffers we are using were allocated using the FslDMA API and our transfer size was greater than zero and less than or equal to the total size of either buffer, (in others words a legal copy request), there is '''very''' little chance that the DMAPhysicalCopyMem() function will fail. In fact, about the only reason the DMA hardware would fail to handle a legal transaction would be if the physical RAM installed in the system was faulty.

So even though it is extremely unlikely for our DMA copy to have failed and returned FALSE, let's take a look at how we might handle the failure. In other words, falling back and using a CPU based copy function instead to complete the data move.

Since we are reverting back to using a normal system copy memory function here, we first need to obtain the ''Virtual Addresses'' to both our source and destination buffers. This is accomplished by using the DMAGetVirtualAddress() function and passing in the Physical Address that was returned by DMAAllocPhysicalMemory().

<syntaxhighlight>
CONST_APTR pVirtualSrcAddr = NULL;
APTR pVirtualDestAddr = NULL;
pVirtualSrcAddr = IfslDMA->DMAGetVirtualAddress((APTR)pPhysicalSrcAddr);
pVirtualDestAddr = IfslDMA->DMAGetVirtualAddress(pPhysicalDestAddr);
</syntaxhighlight>

Now that we have the Virtual Address equivalents to the Physical Addresses that were returned by DMAAllocPhysicalMemory(), we can proceed to call the Exec CopyMemQuick() function to complete the copy. Here we can only trust that the IExec->CopyMemQuick() call can not fail since it does not return a result code.

<syntaxhighlight>
IExec->CopyMemQuick(pVirtualSrcAddr,pVirtualDestAddr,lTestSize);
</syntaxhighlight>

==== Cleaning up - Freeing DMA Compliant memory ====

It is essential that you free any memory that was allocated using the DMAAllocPhysicalMemory() function using the corresponding DMAFreePhysicalMemory() call. The reason for this is two-fold; first because additional resource tracking is maintained by the FslDMA API whenever it allocates memory which must itself be released, and second because the ''Physical Address'' to the memory is returned by the allocate call and not the ''Virtual Address'', so if you attempt to pass the address returned by DMAAllocPhysicalMemory() directly into IExec->FreeVec() it would likely result in a crash.

<syntaxhighlight>
IfslDMA->DMAFreePhysicalMemory(pPhysicalSrcAddr);
IfslDMA->DMAFreePhysicalMemory(pPhysicalDestAddr);
</syntaxhighlight>

== Performance ==

Testing DMA memory copies vs their CPU based equivalent indicates that the DMA hardware on all three models (X5000/20, X5000/40 and A1222)
move data approximately two to three times faster than the CPU does so alone.

It should also be noted that these tests were performed when the CPU was effectively idle. CPU memory copy operations scale down roughly
equal with the CPU actively scaling up. So the more the CPU is doing, the longer it takes to complete the memory copy.

Conversely, DMA memory copy operation times are far more predictable as they use the same amount of (minimal) CPU overhead for each copy,
and the actual time it takes the DMA hardware to complete the transaction can be calculated to range from all the DMA Channels being idle,
to all DMA Channels being busy at once and data moves arbitrating between channels every 1024 bytes.

=== Optimal use of the DMA Engine ===

To gain the best performance from the DMA Engines, block sizes of 256 bytes or more should be used.
Also, if possible the size should be an even multiple of at least 4 bytes.

Additionally the memory blocks (source and destination) should be aligned to start on a 64 Byte boundary.
Alignment requirements are one of items taken care of for you by the DMAAllocPhysicalMemory() function.

The DMA Engine can and does handle misaligned and odd sized data blocks by first shifting the minimum
required bytes to correct the alignment, then taking smaller chunks of data until the largest chunk of
the block can be moved. It can also handle copies of as little as one byte (don't do this).

However, this does degrade performance.

In general, the larger the data block the better.

DMA Resource

2019-11-07T04:12:07Z

Steven Solie: Created page with "== DMA Engine == Some hardware targets include a DMA engine which can be used for general purpose copying. This article describes the DMA engines available and how to use them."

== DMA Engine ==

Some hardware targets include a DMA engine which can be used for general purpose copying. This article describes the DMA engines available and how to use them.

Kernel

2019-11-07T04:10:04Z

Steven Solie: /* Additional Components */

== Exec ==

[[Introduction to Exec]]

[[Exec Libraries|Libraries]]

[[Exec Device I/O|Device I/O]]

[[Exec Memory Allocation|Memory Allocation]]
: [[Exec Memory Pools|Memory Pools]]
: [[Exec Item Pools|Item Pools]]
: [[Exec Named Memory|Named Memory]]
: [[Exec Extended Memory|Extended Memory]]
: [[Obsolete_Exec_Memory_Allocation|Obsolete Memory Allocation Techniques]]

[[Exec Tasks|Tasks]]

[[Exec Signals|Signals]]

[[Exec Lists and Queues|Lists and Queues]]

[[Exec Messages and Ports|Messages and Ports]]

[[Exec Semaphores|Semaphores]]

[[Exec Mutexes|Mutexes]]

[[Exec Interrupts|Interrupts]]

[[Exec Resources|Resources]]

[[Exec Debug|Debugging Facilities]]

== Additional Components ==

[[Expansion Library]]
:[[PCI]]

[[Utility Library]]
:[[Tags]]
:[[Callback Hooks]]
:[[String Functions]]
:[[Date Functions]]
:[[Named Objects]]
:[[Data Structures]]

[[DMA Engine]]

AmiWest 2019 DevCon

2019-10-22T00:30:37Z

Steven Solie: /* October 23 (Wednesday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

We are aiming to cover the following topics:

* ExecSG past/present/future

* A-EON's Enhancer Software Core walkthrough

* The AmigaOS Daily Driver

* A1222 Graphics Driver

* ExecSG DMA Engine

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* A-EON's Enhancer Software Core Walkthrough - Steven Solie
* The new "struct" text editor - Mark Ritter

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie
* Introducing the fsldma.resource - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-22T00:30:15Z

Steven Solie: /* Syllabus */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

We are aiming to cover the following topics:

* ExecSG past/present/future

* A-EON's Enhancer Software Core walkthrough

* The AmigaOS Daily Driver

* A1222 Graphics Driver

* ExecSG DMA Engine

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* Enhancer Software Core Walkthrough - Steven Solie
* The new "struct" text editor - Mark Ritter

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie
* Introducing the fsldma.resource - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-21T20:51:38Z

Steven Solie: /* October 24 (Thursday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

We are aiming to cover the following topics:

* ExecSG past/present/future

* The 3rd party "Enhancer" Software pack or the original Amiga OS API?

* The AmigaOS Daily Driver

* A1222 Graphics Driver

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* Enhancer Software Core Walkthrough - Steven Solie
* The new "struct" text editor - Mark Ritter

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie
* Introducing the fsldma.resource - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-07T03:29:03Z

Steven Solie: /* October 23 (Wednesday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

We are aiming to cover the following topics:

* ExecSG past/present/future

* The 3rd party "Enhancer" Software pack or the original Amiga OS API?

* The AmigaOS Daily Driver

* A1222 Graphics Driver

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* Enhancer Software Core Walkthrough - Steven Solie
* The new "struct" text editor - Mark Ritter

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-05T22:31:13Z

Steven Solie: /* October 23 (Wednesday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

We are aiming to cover the following topics:

* ExecSG past/present/future

* The new Enhancer Software Core

* The AmigaOS Daily Driver

* A1222 Graphics Driver

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* Enhancer Software Core Walkthrough - Steven Solie

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-05T22:31:02Z

Steven Solie: /* Syllabus */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

We are aiming to cover the following topics:

* ExecSG past/present/future

* The new Enhancer Software Core

* The AmigaOS Daily Driver

* A1222 Graphics Driver

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* Enhancer Core Walkthrough - Steven Solie

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-05T21:47:55Z

Steven Solie: /* Syllabus */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

We are aiming to cover the following topics:

* ExecSG past/present/future

* The new Enhancer Core

* The AmigaOS Daily Driver

* A1222 Graphics Driver

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* Enhancer Core Walkthrough - Steven Solie

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-05T21:47:36Z

Steven Solie: /* Syllabus */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

We are aiming to cover the following topics:

* ExecSG past/present/future

* The AmigaOS Daily Driver

* A1222 Graphics Driver

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* Enhancer Core Walkthrough - Steven Solie

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-05T21:42:07Z

Steven Solie: /* October 24 (Thursday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

Still in development.

Note: The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Introducing the ExecSG Team - Steven Solie
* Enhancer Core Walkthrough - Steven Solie

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt
* The Amiga Development Manifesto - Steven Solie

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-10-05T21:41:34Z

Steven Solie: /* October 23 (Wednesday) */

AmiWest 2019 DevCon

2019-09-29T23:49:33Z

Steven Solie: /* October 23 (Wednesday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

Still in development.

Note: The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

* Enhancer Core Walkthrough - Steven Solie

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-09-29T23:48:40Z

Steven Solie: /* October 24 (Thursday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

Still in development.

Note: The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

TBD

== October 24 (Thursday) ==

* Building a graphics driver for the A1222 - Tony Wyatt

== October 25 (Friday) ==

AmiWest Classic Day

AmiWest 2019 DevCon

2019-03-18T00:07:29Z

Steven Solie: Created page with "= Getting Ready = Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See AmiWest Setup for complete details on how to get ready. = Syllabus =..."

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =

Still in development.

Note: The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

We will start at 09:30 each day so please be there for 09:00. We'll have a lunch break around noon. There is no scheduled end time.

== October 23 (Wednesday) ==

TBD

== October 24 (Thursday) ==

TBD

== October 25 (Friday) ==

AmiWest Classic Day

Tutorials:Main

2019-03-18T00:01:26Z

Steven Solie: /* AmiWest 2018 */

= Tutorials =

Tutorials have been provided by various authors.

== General ==

[[The Hacking Way: Part 1 - First Steps]]

[[The Right Tool for the Job (Shared Objects)]]

[[How to Build Stubs for 68k Libraries]]

[[How to create an AmigaOS 4 library]]

== Amiga Future Programming Articles ==

[[Programming AmigaOS 4: The Development Environment]]

[[Programming AmigaOS 4: Exec - The Kernel]]

[[Programming AmigaOS 4: DOS - The Data Administrator]]

[[Programming AmigaOS 4: Intuition - The User Interface]]

[[Programming AmigaOS 4: Drawing Graphics]]

[[Programming AmigaOS 4: Transparent Windows]]

[[Programming AmigaOS 4: Datatypes - Making Life Easy]]

[[Programming AmigaOS 4: GUI Toolkit ReAction]]

[[Programming AmigaOS 4: Utility - Little Helpers]]

== Debugging ==

[[How to install a hardware interrupt]]

[[How to open and use the exec debug interface]]

[[GDB for Beginners]]

[[Using Crash-Logs for Debugging]]

[[Debug Logging on AmigaOS]]

[[Redirecting Debug Output to the Serial Port on Startup]]

[[Advanced Serial Debugging Guide]]

== GUI ==

[[BOOPSI Gadget Help Strings]]

[[BOOPSI Popup Menus - Part 1]]

[[BOOPSI Popup Menus - Part 2]]

[[BOOPSI Popup Menus - Part 3]]

[[Screen Programming]]

== AmiWest 2019 ==

[[AmiWest Setup]]

[[AmiWest 2019 DevCon]]

== AmiWest 2018 ==

[[AmiWest Setup]]

[[AmiWest 2018 DevCon]]

== AmiWest 2017 ==

[[AmiWest Setup]]

[[AmiWest 2017 DevCon]]

== AmiWest 2016 ==

[[AmiWest Setup]]

[[AmiWest 2016 DevCon]]

== AmiWest 2015 ==

[[AmiWest Setup]]

[[AmiWest 2015 DevCon]]

== AmiWest 2014 ==

[[AmiWest Setup]]

[[AmiWest 2014 Programming Seminar]]

== AmiWest 2013 ==

[[AmiWest 2013 Programming Conference Synopsis]]

[[AmiWest Setup]]

[[AmiWest 2013 Lesson 1|AmiWest Lesson 1: How to Crash]]

[[AmiWest 2013 Lesson 2|AmiWest Lesson 2: Interpreting Crash Reports]]

[[AmiWest 2013 Lesson 3|AmiWest Lesson 3: ProcTree Redux]]

[[AmiWest 2013 Lesson 4|AmiWest Lesson 4: Simple IP Clients & Servers]]

[[AmiWest 2013 Lesson 5|AmiWest Lesson 5: Bars&Pipes Tools]]

== AmiWest 2012 ==

[[AmiWest Setup]] [https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Introduction-360.mp4 - Video]

[[AmiWest Lesson 1|AmiWest Lesson 1: Coding Basics]] [https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson01-360.mp4 - Video]

[[AmiWest Lesson 2|AmiWest Lesson 2: AmigaOS Fundamentals]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson02-360.mp4 - Video]

[[AmiWest Lesson 3|AmiWest Lesson 3: Input and Output]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson03-360.mp4 - Video]

[[AmiWest Lesson 4|AmiWest Lesson 4: ProcTree]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson04-360.mp4 - Video]

[[AmiWest Lesson 5|AmiWest Lesson 5: MIDI]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson05-360.mp4 - Video]

[[AmiWest Lesson 6|AmiWest Lesson 6: Application Library - Not Presented]]

[[AmiWest Lesson 7|AmiWest Lesson 7: Screen Blanker - Not Presented]]

[[AmiWest Lesson 8|AmiWest Lesson 8: ARexx Ports]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson07-360.mp4 - Video]

[[AmiWest Support]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Wrap-Up-360.mp4 - Video]

AmigaOS Applications

2019-03-03T03:09:44Z

Steven Solie: /* Note */

= Disclaimer =
The following list of applications are neither endorsed by nor supported by Hyperion Entertainment. This list is strictly informational only.

= Applications =

AmigaOS Applications

2019-03-03T03:07:53Z

Steven Solie: /* Note */

= Note =
The following list of applications are neither endorsed by nor supported by Hyperion Entertainment. This list is strictly informational only.

= Applications =

AmigaOS Applications

2019-03-03T03:06:37Z

Steven Solie: Created page with "= Note = The following list of applications are neither endorsed by nor supported by Hyperion Entertainment. This list is strictly informational only."

= Note =
The following list of applications are neither endorsed by nor supported by Hyperion Entertainment. This list is strictly informational only.

UserDoc:Main

2019-03-03T03:04:50Z

Steven Solie:

== Welcome to AmigaOS ==

AmigaOS was born in 1985 and delivered what contemporary personal computer operating systems could only dream of. As the first "multimedia" operating system, it was trivial for AmigaOS computers to display animations while playing music and reading data from disks. Such multimedia and multitasking finesse drew many people to this system. Some of them are famous: [http://www.amigahistory.co.uk/warhol.html Andy Warhol], Sir Arthur C. Clarke, [http://www.polyphoto.com/upchug/AEcastro.html NASA], Hollywood and the TV broadcasting industry, and many others that thought [http://www.youtube.com/watch?v=PWeO5IkCssk only Amiga makes it possible].

Today many people still think AmigaOS has something special that makes it more interesting and rewarding than other systems. This system allows the user to control the computer, not the other way around. It is a system you fully understand that is easier and more flexible to use. In other words, AmigaOS is '''more fun'''.

=== AmigaOS: The flexible operating system ===
AmigaOS is an operating system: a collection of efficient programs written to start the computer, let the user control the computer, and present feedback to the user.

AmigaOS is designed with ease of use and flexibility in mind. To begin with, AmigaOS provides a clear view of your computer, your applications and files. A number of methods are available to let your computer serve you, whether graphically with a mouse, using the "Shell" command line, or by some other means the user prefers.

AmigaOS strives to avoid stupid limitations that can be found on other systems. AmigaOS users can organise their files the way they like. There are few limits on file hierarchy, locations and file names. Drives don't have to be named with a letter or cryptic names (such as C:, or sda1), your files don't have to reside in your "Documents" folder and your hard drives aren't hidden from you. If you're not writing to drives and you want to "shut down", why wait for the OS to allow that? With AmigaOS, just hit the power switch. Done.

An Amiga does not start with pre-installed applications serving some sales conglomerate, marketing organization or their big brother. AmigaOS does not do actions behind the user's back. As unique as it is today, the AmigaOS computer serves the user and not the other way around. With one of the largest proportions of user-programmers around, the trustworthy AmigaOS user-friendly ethic is mirrored in AmigaOS applications.

Since the first versions more than twenty-five years ago, AmigaOS has also been designed to serve efficiently. Optimizing applications and OS code has always been the goal of programmers and developers of this operating system. The result is an operating system and applications that take less space on your hard drives, waste less time loading, consume less memory, require less processing power, and respond more quickly to the user.

And every update of AmigaOS doesn't demand you must buy newer, more powerful hardware. AmigaOS currently runs on twenty year old 200MHz computers or brand new dual core 1,800MHz computers. It's the user's choice how they want to '''enjoy''' AmigaOS.

=== Some AmigaOS features ===
Here are some of the features of AmigaOS that make it easy to control your computer. Some of these concepts were copied by other operating systems which tend to show they are the correct way of doing things.

* '''Small footprint:''' AmigaOS can work with 64 MB of memory. On disk, a default installation only takes around 200 MB. The smaller footprint translates into a more responsive user experience given any hardware.

* '''Straightforward operating system design:''' With a clear layout and easy to understand names (Classes, Libs, Fonts, Prefs, Storage, etc.), you can easily understand what everything in AmigaOS is and what it does for you. Nothing is hidden from the user and the user is not restricted by AmigaOS.

*'''User configurable graphic interface:''' Using the provided "preferences editors," the user can dramatically reconfigure how AmigaOS looks, sounds, runs and responds to every user whim.

* '''File recognition based on file content:''' You can name a file '''whatever you want''', even without an extension. Examples: "my file" or "picture of Jay in Santa Clara". There is no need to add an extension to explain what the file is, like ".txt" or ".jpg". AmigaOS really examines the '''file content''' to recognise what type of file it is.

* '''Logical assignments:''' Easily set and use logical names names for directories located anywhere on your system. For example, "Auto:" can point to your directory "car show pictures" buried on your media drive.

* '''Ram disk concept:''' On AmigaOS there is a special disk called the '''Ram disk''' which represents a part of your computer memory. This area is not fixed. It automatically grows whenever you store files in it. For example, it's a great place to unpack files to install from there, greatly speeding up the installation.

* '''Command line and graphical user interfaces:''' Both the the graphical user interface (GUI) and command line interface (where you type commands into a window with the keyboard) can be used to manage AmigaOS, its programs and files. Both interfaces are intergated with each other so you can easily use command lines from the GUI or open graphical elements from a command line.

*'''ARexx Ports:''' Throughout AmigaOS and third party programs, "ARexx" message ports let one application talk with others so that apps work together to serve the user. AmigaOS also provides the lightweight ARexx and modern Python programming languages that can control AmigaOS and applications with ARexx ports.

* '''Resident Commands:''' Commands can be made resident, i.e., they are kept in memory so that they can be reused with no loading time.

* '''Restart only the operating system:''' if you feel the need to restart the system, you can do so by restarting '''only AmigaOS''' and not the whole computer.

=== AmigaOS platform targets ===

While the original versions of AmigaOS ran on computers of the eighties using Motorola 68k series CPU chips, the current AmigaOS runs on computers using PowerPC processor chips [http://www.amigaos.net/content/72/supported-hardware hardware]. These can be older Amiga computers (also called "Classic Amigas") with PPC "accelerator cards" or new generation Amiga PPC computers.

In this guide, we will concentrate on the current AmigaOS running on the [[AmigaOS_Platforms|supported hardware]].

== How does AmigaOS work? - Concepts ==

In this page we will discuss [[UserDoc:How AmigaOS Works|how AmigaOS works]]:

* [[UserDoc:How_AmigaOS_Works#The_most_important_components|The most important components]] (Exec, AmigaDOS, Intuition...)
* [[UserDoc:How_AmigaOS_Works#How_is_my_data_stored.3F|how files and data are stored]]
* [[UserDoc:How_AmigaOS_Works#All_AmigaOS_components|all AmigaOS components are described]]
* [[UserDoc:How_AmigaOS_Works#AmigaOS_boot_procedure|how AmigaOS is booted on your Amiga computer]]
* [[Workbench/Prefs|AmigaOS settings programs]]
* ...

== How to use AmigaOS? ==

AmigaOS is a collection of components that oversee the computer hardware & data and provide the user with easy, understandable tools to manage and use them.

In the following [[UserDoc:Introduction to AmigaOS|Introduction to AmigaOS pages]] we will discuss the basic concepts:

* how to use AmigaOS
* what the AmigaOS graphic user interface is composed of
* what interfaces AmigaOS provides, including the [[UserDoc:Workbench|Workbench]], the [[UserDoc:Shell|Shell]] or scripting languages.

From the introduction page, you can continue with more detailed pages on the [[UserDoc:Workbench|Workbench]] and the [[AmigaDOS manual]] . Now let's start with this [[UserDoc:Introduction to AmigaOS|Introduction to AmigaOS]].

== Manuals ==

[[AmigaOS Manual]] - AmigaOS Manual

[[Bars & Pipes Professional]] - MIDI Sequencer

== Applications ==

[[AmigaOS Applications]] - Sample list of AmigaOS applications

AmigaKit

2019-02-12T17:10:50Z

Steven Solie:

AmigaKit is an Amiga retailer, distributor and manufacturer based in the UK.

They supply products worldwide from the current generation of Amiga computers and products through to the 'Classic' range.

AmigaKit are the official distributor of the [http://wiki.amiga.org/index.php?title=AmigaONE_X5000 AmigaOne X5000].

'''AmigaKit website:'''

http://www.amigakit.com

AmigaKit

2019-02-12T17:05:38Z

Steven Solie:

AmigaKit is an Amiga retailer, distributor and manufacturer based in the UK.

They supply products worldwide from the current generation of Amiga computers and products through to the 'Classic' range.

AmigaKit are the official distributor of the AmigaOne X5000.

'''AmigaKit website:'''

http://www.amigakit.com

Amiga Hardware Manufacturer ID Registry

2018-11-13T03:10:54Z

Steven Solie: /* Registry */

__TOC__

= How to Obtain a Manufacturer Number =

Manufacturer's numbers are assigned by the AmigaOS development team. To obtain your unique manufacturer number use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Be sure and include your name, email and the type of expansion product you are developing.

= Your Manufacturer Number =

Attention hardware manufacturers. If you are developing a hardware expansion product for the Classic Amiga (e.g. 500, 2000, 3000) then you will need to obtain a special manufacturer ID number from the AmigaOS development team to identify your product. This manufacturer number is used by the Amiga to link your hardware with its driver software at boot time.

Your manufacturer number is part of the special protocol that the Amiga uses to automatically configure all expansion devices on the bus without the user having to cut jumpers or adjust dip switches. This is called auto-config.

At start-up time, the system first polls each board in the system and assigns the board its own address space. If it is a memory board, its RAM is linked into the memory free pool. Later in the boot sequence, after DOS is initialized, the binddrivers program is run. Binddrivers will search the directory SYS:Expansion for the drivers that go with the boards.

To do this binddrivers looks in the Tool Type field of all icon files in SYS:Expansion. If the first seven bytes of the Tool Type field are "PRODUCT", then this is an icon file for a driver.

Binddrivers will then attempt to match the drivers it has found with the boards that were found earlier. This is where your manufacturer number comes in.

Your manufacturer number goes in two places. First, it is burned in hex form into the PAL which is part of ALL auto-config expansion products. Second, it appears in ASCII in the Tool Type field of the icon file for your product's driver. By matching these two numbers, the Amiga can automatically configure your board and bind it's software driver into the system as well.

The manufacturer's number is a 16-bit ID which appears in PAL offsets $10-$17. There is also an 8-bit product number which you assign. The product number is for uniquely identifying different products from the same vendor. The product number will appear in PAL offsets $04-$07. This gives you a total of 24 bits to identify each of your products.

These 24 bits of information in the PAL which identify your product are matched against the information in the Tool Type field of all icon files in the SYS:Expansion drawer. For example, suppose you are manufacturer #1019. You have two products, #1 and #2 which both use the same driver. The icon for your driver for these two products would have a Tool Type set to "PRODUCT=1019/1|1019/2". This means: I am an icon for a driver that works with product number 1 or 2 from manufacturer 1019, now bind me. Spaces are not legal. Here are two other examples:

; PRODUCT=1208/11
: is the Tool Type for a driver for product 11 from manufacturer number 1208.

; PRODUCT=1017
: is the Tool Type for a driver for any product from manufacturer number 1017.

For an informal explanation of the auto-configuration process, see the chapter on Software Expansion Architecture from the 2nd Annual Amiga Developer's Conference Notes (available on ADCD 2.1). For the details of timing, power, the PAL equations and PAL address specifications and the expansion library documentation, see sections 3.1 to 3.3 of the A500/A2000 Technical Reference Manual. The original auto-config spec appears in the A1000 Schematics and Expansion Specification.

The auto-config process makes the addition of expansion products to the system very easy. All the user has to do is put the board in any slot and copy the driver from the release disk to his own SYS:Expansion drawer. Everything else is automatic. There are no jumpers or dip switches to set. Best of all, you will get a lot less support calls asking how to make your product work with the XYZ-Corp-battery-backed-clock.

= Notes =

Some notes on hardware manufacturer ID assignment.

* Manufacturer ID numbers are assigned free of charge.
* Please provide the following information when requesting an ID:
*# Name of the company or person
*# Postal address/contact address
*# Name of the contact person, with a corresponding e-mail address
*# A brief description of the kind of products you want to produce
* All ID numbers smaller than 5000 must be considered unsafe because no information exists on which numbers exactly were taken during the time Commodore, Inc. disintegrated.
* ID numbers in the range 8192 to 18841 must be considered unsafe because some hardware developers mistook the numbers assigned to them to be given in hexadecimal format. Hence 0x2000 = 8192 and 0x4999 = 18841.

= Example code =

<syntaxhighlight>
/*-----------------------------------------------*/
/* Here is a short program which will tell you */
/* about the expansion boards configured in your */
/* system without you opening up the machine. */
/* Code by Bill Koester of CATS */
/*-----------------------------------------------*/
#include <libraries/configvars.h>
#include <libraries/expansion.h>

struct ExpansionBase *ExpansionBase;

void cleanup();
void printdev();

int main()
{
struct ConfigDev *MyConfigDev;

/*----------------------------------*/
/* Open the expansion library, */
/* if there is a problem then exit */
/*----------------------------------*/

ExpansionBase =(struct ExpansionBase *) OpenLibrary(EXPANSIONNAME,0);
if(ExpansionBase==NULL)
{
printf("Error opening expansion library!!\n");
cleanup();
exit(0);
}

/*--------------------------------------------*/
/* Use FindConfigDev to get info on the first */
/* expansion board on the list maintained by */
/* Exec. If there are no expansion boards in */
/* the system then exit. */
/*--------------------------------------------*/

MyConfigDev = NULL;

/*--------------------------------------------------*/
/* FindConfigDev(oldConfigDev,manufacturer,product) */
/* oldConfigDev = NULL for the top of the list */
/* manufacturer = -1 for any manufacturer */
/* product = -1 for any product */
/*--------------------------------------------------*/

MyConfigDev = FindConfigDev(NULL,-1,-1);

if(MyConfigDev==NULL)
{
printf("No Configured Devices found!!\n");
cleanup();
exit(0);
}

printdev(MyConfigDev);

/*-----------------------------------*/
/* OK, there is at least one board, */
/* so loop and get the entire list */
/* printing as we go with printdev() */
/*-----------------------------------*/

while(MyConfigDev = FindConfigDev(MyConfigDev,-1,-1))
{
printdev(MyConfigDev);
}
cleanup();
return 0;
}

/*-------------------*/
/* Close up shop... */
/*-------------------*/
void cleanup()
{
if(ExpansionBase)
CloseLibrary(ExpansionBase);
}

/*----------------------------------*/
/* Print out the contents of the */
/* dev structure for this expansion */
/* product. */
/*----------------------------------*/

void printdev(dev)
struct ConfigDev *dev;
{
char buff[200];

printf("Flags = ");
if(dev->cd_Flags==NULL)
printf("NULL ");
if(dev->cd_Flags&CDF_SHUTUP)
printf("CDF_SHUTUP ");
if(dev->cd_Flags&CDF_CONFIGME)
printf("CDF_CONFIGME ");
printf("\n");
printf("Board Address = %x\n",dev->cd_BoardAddr);
printf("Board Size = %d bytes\n",dev->cd_BoardSize);
printf("Slot Address = %d\n",dev->cd_SlotAddr);
printf("Slot Size = %d\n",dev->cd_SlotSize);
printf("Driver code at %x\n",dev->cd_Driver);

printf("er_Type = %x\n",dev->cd_Rom.er_Type);
printf("er_Product = %x\n",dev->cd_Rom.er_Product);
printf("er_Flags = %x\n",dev->cd_Rom.er_Flags);
printf("er_Reserved03 = %x\n",dev->cd_Rom.er_Reserved03);
printf("er_Manufacturer = %x\n",dev->cd_Rom.er_Manufacturer);
printf("er_SerialNumber = %x\n",dev->cd_Rom.er_SerialNumber);
printf("er_InitDiagVec = %x\n",dev->cd_Rom.er_InitDiagVec);
printf("er_Reserved0c = %x\n",dev->cd_Rom.er_Reserved0c);
printf("er_Reserved0d = %x\n",dev->cd_Rom.er_Reserved0d);
printf("er_Reserved0e = %x\n",dev->cd_Rom.er_Reserved0e);
printf("er_Reserved0f = %x\n",dev->cd_Rom.er_Reserved0f);

printf("Hit Return to continue:\n");
gets(buff);
}
</syntaxhighlight>

= Registry =

{| class="wikitable"
! ID (decimal)
! ID (hexadecimal)
! Manufacturer
! Notes
|-
| 1
| 0001
| Micronik
|-
| 211
| 00D3
| Pacific Peripherals/Profex
|-
| 221
| 00DD
| Kupke Computertechnik GmbH
|-
| 256
| 0100
| Memphis
| Originally registered to MacroSystems US
|-
| 512
| 0200
| 3-State Computertechnik
|-
| 513
| 0201
| Commodore (Braunschweig)
|-
| 514
| 0202
| Commodore (West Chester)
|-
| 515
| 0203
| Commodore (West Chester)
| Originally registered to Combitech/Macrosystem
|-
| 756
| 02F4
| Progressive Peripherals & Software
|-
| 767
| 02FF
| Kolff Computer Supplies
|-
| 1001
| 03E9
| Tecmar
|-
| 1002
| 03EA
| Telesys
|-
| 1003
| 03EB
| The Micro-Forge
|-
| 1004
| 03EC
| Kronos/C Ltd.
| Originally registered to Card Co. (Supra)
|-
| 1005
| 03ED
| A-Squared
|-
| 1006
| 03EE
| Comspec Communications
|-
| 1007
| 03EF
| HT Electronics
|-
| 1008
| 03F0
| RDS Software
|-
| 1009
| 03F1
| Anakin Research
|-
| 1010
| 03F2
| MicroBotics
|-
| 1011
| 03F3
| Bob Krauth
|-
| 1012
| 03F4
| Access Associates (Alegra)
|-
| 1013
| 03F5
| Mini Comp Systems Ltd.
|-
| 1014
| 03F6
| Cypress Technology
|-
| 1015
| 03F7
| Fuller Computers
|-
| 1016
| 03F8
| Galaxy Computers
|-
| 1017
| 03F9
| ADA Research
|-
| 1018
| 03FA
| Computer Service Italia
|-
| 1019
| 03FB
| Amigo
|-
| 1020
| 03FC
| Micro-Solutions Inc.
|-
| 1021
| 03FD
| Stacar International
|-
| 1022
| 03FE
| Video Precisions
|-
| 1023
| 03FF
| ASDG, Inc.
|-
| 1025
| 0401
| Ing. Buero Kalawsky
|-
| 1026
| 0402
| Computer Tuning
|-
| 1027
| 0403
| Interplan Unternehmensberatung
|-
| 1028
| 0404
| Imtronics/Memphis
| Originally registered to Peter Ohlich
|-
| 1030
| 0406
| Commodore (Lowell University)
| Originally registered to Productivity Center
|-
| 1041
| 0411
| Design Labs
|-
| 1042
| 0412
| MCS
|-
| 1043
| 0413
| B. J. Freeman
|-
| 1044
| 0414
| Side Effects Inc.
|-
| 1045
| 0415
| Oklahoma Personal Comp.
|-
| 1046
| 0416
| Advanced Micro Innovations
|-
| 1047
| 0417
| Industrial Support Services
|-
| 1048
| 0418
| Technisoft
|-
| 1049
| 0419
| Prolific, Inc.
|-
| 1050
| 041A
| Softeam, Inc.
|-
| 1051
| 041B
| GRC Electronics
|-
| 1052
| 041C
| David Lai
|-
| 1053
| 041D
| Ameristar Technologies
|-
| 1054
| 041E
| Cline Refrigeration
|-
| 1055
| 041F
| Cardiac Pacemakers, Inc.
|-
| 1056
| 0420
| Supra Corp. (Creative Microsystems)
|-
| 1057
| 0421
| Wayne Diener
|-
| 1058
| 0422
| Computer Systems Associates (CSA)
|-
| 1059
| 0423
| Trionix, Inc.
|-
| 1060
| 0424
| David Lucas
|-
| 1061
| 0425
| Analog Precision
| Also assigned to D & L Distributing
|-
| 1267
| 04F3
| RBM Digitaltechnik
|-
| 1282
| 0502
| M-TEC Hardware Design
|-
| 1337
| 0539
| Thomas Stenzel (DaFR34K)
|-
| 1576
| 0628
| Boris Križma
|-
| 1761
| 06E1
| Great Valley Products
|-
| 1803
| 070B
| UAE Amiga Emulator
|-
| 2002
| 07D2
| Mimetics Corp.
|-
| 2003
| 07D3
| ACDA
|-
| 2004
| 07D4
| Finn R. Jacobsen
|-
| 2005
| 07D5
| Elthen Electronics
|-
| 2006
| 07D6
| Nine Tiles Computer Systems Ltd.
|-
| 2007
| 07D7
| Analog Electronics
|-
| 2008
| 07D8
| Bell & Howell
|-
| 2009
| 07D9
| Roland Kochler
|-
| 2010
| 07DA
| Byte Corp.
|-
| 2011
| 07DB
| Reserved
|-
| 2012
| 07DC
| DKB, Inc.
| Previously named Michigan Software
|-
| 2013
| 07DD
| Pacific Peripherals
|-
| 2014
| 07DE
| Sysaphus Software
|-
| 2015
| 07DF
| Digitronics
|-
| 2016
| 07E0
| Akron Systems
|-
| 2017
| 07E1
| Great Valley Products
|-
| 2018
| 07E2
| Calmos
|-
| 2019
| 07E3
| Dover Research
|-
| 2020
| 07E4
| David Krehbiel
|-
| 2021
| 07E5
| Synergy Peripheral Systems
| Also known as California Access
|-
| 2022
| 07E6
| Xetec
|-
| 2023
| 07E7
| Micron Technology
|-
| 2024
| 07E8
| CH Electronics
|-
| 2025
| 07E9
| American Liquid Light
|-
| 2026
| 07EA
| Progressive Peripherals & Software
| Also used by Ateo
|-
| 2027
| 07EB
| Wicat Systems
|-
| 2028
| 07EC
| Applied Systems & Peripherals
|-
| 2029
| 07ED
| Delaware Valley Software
|-
| 2030
| 07EE
| Palomax
|-
| 2031
| 07EF
| Incognito Software
|-
| 2032
| 07F0
| Jadesign
|-
| 2033
| 07F1
| BVR
|-
| 2034
| 07F2
| Spirit Technology
|-
| 2035
| 07F3
| Spirit Technology
|-
| 2036
| 07F4
| Atronic
|-
| 2037
| 07F5
| Scott Karlin
|-
| 2038
| 07F6
| Howitch
|-
| 2039
| 07F7
| Sullivan Brothers Visual Engineers
|-
| 2040
| 07F8
| G I T
|-
| 2041
| 07F9
| Amigo Business Computers
|-
| 2042
| 07FA
| Micro E Ab
|-
| 2043
| 07FB
| Ralph Kruse
|-
| 2044
| 07FC
| Clearpoint Research
|-
| 2045
| 07FD
| Kodiak
|-
| 2046
| 07FE
| BSC
| Originally registered to Phoenix Electronics
|-
| 2047
| 07FF
| No Name Shown
|-
| 2048
| 0800
| Commodore Braunschweig
|-
| 2049
| 0801
| BSC
| Originally registered to Elaborate Bytes
|-
| 2050
| 0802
| Kronos/C Ltd.
|-
| 2051
| 0803
| Spartanics
|-
| 2052
| 0804
| Jochheim Computer Tuning
|-
| 2053
| 0805
| Trans Data Systems
|-
| 2054
| 0806
| Applied Systems & Peripherals Ltd.
|-
| 2055
| 0807
| Checkpoint Technologies
| Originally registered to Amiga Solutions
|-
| 2056
| 0808
| Adept Development
|-
| 2057
| 0809
| Advanced Computer Design
|-
| 2058
| 080A
| Sir Netics
|-
| 2059
| 080B
| Expert Services
|-
| 2060
| 080C
| Digital Art Systems
|-
| 2061
| 080D
| Adept Development
|-
| 2062
| 080E
| Expansion Technologies (Expansion Systems)
|-
| 2063
| 080F
| Alphatech
|-
| 2064
| 0810
| Edotronik GmbH
|-
| 2065
| 0811
| California Access/Synergy
| Originally registered to Logical Design Works
|-
| 2066
| 0812
| Bowden, Williams, Full & Assoc.
|-
| 2067
| 0813
| NES, Inc.
|-
| 2068
| 0814
| Amdev
|-
| 2069
| 0815
| Big Brother Security Systems
|-
| 2070
| 0816
| Active Circuits Inc.
|-
| 2071
| 0817
| ICD, Inc.
|-
| 2072
| 0818
| Multi-Meg Electronique
|-
| 2073
| 0819
| Kupke Computertechnik GmbH
|-
| 2074
| 081A
| The Checkered Ball
|-
| 2075
| 081B
| Hi Tension Computer Services Ltd. (UK)
|-
| 2076
| 081C
| Alfa Data
| Originally assigned to Elmtech Research, Ltd. (UK)
|-
| 2077
| 081D
| Great Valley Products
| Originally registered to Clartscreen, Ltd. (UK)
|-
| 2078
| 081E
| Interworks
|-
| 2079
| 081F
| Galysh Enterprises
|-
| 2080
| 0820
| Hardital Synthesis
| Originally registered to Realtime Games Software Ltd.
|-
| 2081
| 0821
| GBS
|-
| 2082
| 0822
| Circum Design Inc.
|-
| 2083
| 0823
| Alberta Micro Electronic Center
|-
| 2084
| 0824
| Bestech
|-
| 2085
| 0825
| Lasar Fantasy
|-
| 2086
| 0826
| Pulsar
|-
| 2087
| 0827
| Ivis
|-
| 2088
| 0828
| Applied Engineering
|-
| 2089
| 0829
| Solid-State Design & Development
|-
| 2090
| 082A
| Vison Quest
|-
| 2091
| 082B
| Seaview Software
|-
| 2092
| 082C
| BSC
| Mistakenly used by ADS (Advanced Development Software)
|-
| 2093
| 082D
| Bernd Culenfeld
|-
| 2094
| 082E
| American Liquid Light
|-
| 2095
| 082F
| CEGITES
|-
| 2096
| 0830
| Quadlite Computers Ltd.
| Originally registered to EV Industries
|-
| 2097
| 0831
| Silicon Peace
|-
| 2098
| 0832
| Black Belt Systems
|-
| 2099
| 0833
| Village Tronic
| Originally registerd to Steve Yaeger
|-
| 2100
| 0834
| ReadySoft
|-
| 2101
| 0835
| Phoenix Micro Technologies
|-
| 2102
| 0836
| Advanced Systems & Software
| Orignally assigned to Preferred Technology
|-
| 2103
| 0837
| Rombo Productions
|-
| 2104
| 0838
| Impulse Inc.
|-
| 2105
| 0839
| Beta Unlimited
|-
| 2106
| 083A
| Memory Expansion System, Ltd.
|-
| 2107
| 083B
| Vortex Computer Systems GmbH
|-
| 2108
| 083C
| Platypus Systems
|-
| 2109
| 083D
| Gigatron OHG
|-
| 2110
| 083E
| PG Electronics
|-
| 2111
| 083F
| New Technologies Group
|-
| 2112
| 0840
| Interactive Video Systems (IVS)
| Pacific Peripherals
|-
| 2113
| 0841
| Vector
| Originally registered to H. K. Computer
|-
| 2114
| 0842
| Pacific Digital
| Originally registered to C. H. Helfrich Elektronik
|-
| 2115
| 0843
| Xanadu
|-
| 2116
| 0844
| Pacific Digital
| Originally registered to AMS
|-
| 2117
| 0845
| X-Pert
|-
| 2118
| 0846
| The Amiga Centre
|-
| 2119
| 0847
| Digital Pacific
|-
| 2120
| 0848
| Solid State Leisure
|-
| 2121
| 0849
| Hydra Systems
| Originally registered to Analog Electronics
|-
| 2122
| 084A
| Cumana
|-
| 2123
| 084B
| KAPS 2C Conception
|-
| 2124
| 084C
| Mike Mason
|-
| 2125
| 084D
| For Your Eyes
|-
| 2126
| 084E
| Volkmar Breitfeld Computersysteme
|-
| 2127
| 084F
| Sunrize Industries
|-
| 2128
| 0850
| Scott Advanced Micro Designs
|-
| 2129
| 0851
| Digital Micronics
|-
| 2130
| 0852
| Alfa-Laval
|-
| 2131
| 0853
| Multigros A/S
|-
| 2132
| 0854
| Archos
|-
| 2133
| 0855
| Icom Simulations
|-
| 2134
| 0856
| Commodore Test Engineering Group
|-
| 2135
| 0857
| Microcreations
|-
| 2136
| 0858
| Shoestring Productions
|-
| 2137
| 0859
| Faberushi
|-
| 2138
| 085A
| Evesham Micro Ltd.
|-
| 2139
| 085B
| Panagolin Laser Software
|-
| 2140
| 085C
| Thomas Rudloff
|-
| 2141
| 085D
| Daniel Hohabir
|-
| 2142
| 085E
| GfxBase, Inc.
|-
| 2143
| 085F
| Axellabs
|-
| 2144
| 0860
| Roctec Electronics Inc.
|-
| 2145
| 0861
| Omega Datentechnik
|-
| 2146
| 0862
| Atlantis
|-
| 2147
| 0863
| Skytec Computers
|-
| 2148
| 0864
| Protar Electronics
|-
| 2149
| 0865
| ACS
|-
| 2150
| 0866
| Software Results Enterprises
| Originally registered to University of Illinois
|-
| 2151
| 0867
| Infinity Systems Design Group
|-
| 2152
| 0868
| Trade It
|-
| 2153
| 0869
| Suntec, Inc.
|-
| 2154
| 086A
| DJW Micro Systems
| Originally registered to Tritec Marketing
|-
| 2155
| 086B
| Power Computing Ltd.
|-
| 2156
| 086C
| MacroSystems
|-
| 2157
| 086D
| Masoboshi GmbH (DCE)
|-
| 2158
| 086E
| HAL Software Hardware Handel
|-
| 2159
| 086F
| Mainhattan Data
| Originally registered to Michael Lamm Computersysteme
|-
| 2160
| 0870
| Digital Processing System
| Originally registered to bbdp Electronics
|-
| 2161
| 0871
| Blue Ribbon Soundworks
| Originally registered to Design Computer Systems
|-
| 2162
| 0872
| XPert
| Originally registered to The Station
|-
| 2163
| 0873
| DelaComp
| Originally registered to Bryan Williams
|-
| 2164
| 0874
| Superformance Computer Engineering GmbH
|-
| 2165
| 0875
| Overland Engineering
|-
| 2166
| 0876
| Thomas Hamren
|-
| 2167
| 0877
| Village Tronic
|-
| 2168
| 0878
| Toolbox Design
|-
| 2169
| 0879
| Digital Processing System
|-
| 2170
| 087A
| Superformance
|-
| 2171
| 087B
| Utilities Unlimited
|-
| 2172
| 087C
| phase 5
|-
| 2173
| 087D
| Juergen Kommos
|-
| 2174
| 087E
| Electronic Design
|-
| 2175
| 087F
| James Cook University of North Queensland
|-
| 2176
| 0880
| AmiTrix Development
|-
| 2177
| 0881
| Ferranti
|-
| 2178
| 0882
| Leviathan Development
|-
| 2179
| 0883
| United Video Inc.
|-
| 2180
| 0884
| GPSoft Pty. Ltd.
| Originally registered to Juergen Kommos
|-
| 2181
| 0885
| ArMAX
| Oliver Bausch
|-
| 2182
| 0886
| CP Computer
|-
| 2183
| 0887
| AMOK - Amiga Module & Oberon Klub
|-
| 2184
| 0888
| ITEK Neser & Sieber GbR
|-
| 2185
| 0889
| Phillip C. Lello
|-
| 2186
| 088A
| Cyborg Design Services
|-
| 2187
| 088B
| G2 Systems
|-
| 2188
| 088C
| Pro System Computersysteme
|-
| 2189
| 088D
| ZEUS Electronic
| Originally registered to MSPI (Markt & Technik)
|-
| 2190
| 088E
| Altatech
|-
| 2191
| 088F
| NewTek
|-
| 2192
| 0890
| M-TEC Hardware Design
| Originally registered to Hardware Design Udo Neuroth
|-
| 2193
| 0891
| Great Valley Products
| Originally registered to Viona Development
|-
| 2194
| 0892
| Amitek
| Originally assigned to Marpet Developments
|-
| 2195
| 0893
| Ingenieurbuero Helfrich
|-
| 2196
| 0894
| The Neo Group
|-
| 2197
| 0895
| Cyon
|-
| 2198
| 0896
| Bob Research Group
|-
| 2199
| 0897
| Richmond Sound Design Ltd.
|-
| 2200
| 0898
| US Cybernetics
|-
| 2201
| 0899
| Fulvio Ieva
|-
| 2202
| 089A
| Silicon Studio
|-
| 2203
| 089B
| MacroSystems (USA)
| Was named Micro System Devices
|-
| 2204
| 089C
| Conspector Entertainment
|-
| 2205
| 089D
| Laserforum
|-
| 2206
| 089E
| Elbox Computer
| Mistakenly used by Index Information Ltd.
|-
| 2207
| 089F
| Applied Magic Inc.
|-
| 2208
| 08A0
| SDL Ltd.
|-
| 2560
| 0A00
| Harms
|-
| 2588
| 0A1C
| A1K.org Community
|-
| 2640
| 0A50
| Micronik
|-
| 3084
| 0C0C
| Team 4
|-
| 3643
| 0E3B
| E3B
| Michael Boehmer
|-
| 3855
| 0F0F
| Micronik
|-
| 4096
| 1000
| MegaMicro
|-
| 4110
| 100E
| DigiFeX
|-
| 4136
| 1028
| Imtronics/Memphis
|-
| 4149
| 1035
| PROTAR
|-
| 4369
| 1111
| Frank Strauß Elektronik
| Also used by Kupke
|-
| 4626
| 1212
| Individual Computers
|-
| 4648
| 1228
| Flesch Hornemann Computer Elec.
|-
| 4680
| 1248
| Kupke Computertechnik GmbH
|-
| 4711
| 1267
| RBM digitaltechnik
|-
| 4754
| 1292
| MacroSystems
|-
| 5000
| 1388
| ITH
|-
| 5001
| 1389
| VMC
|-
| 5010
| 1392
| Ambience Creation Technology
|-
| 5011
| 1393
| Creative Development
|-
| 5012
| 1394
| Georg Braun
|-
| 5013
| 1395
| Swedish User Group of Amiga
|-
| 5014
| 1396
| Jakub Bednarski
|-
| 5015
| 1397
| KryoFlux, Ltd.
|-
| 5016
| 1398
| Igor Majstorovic
|-
| 5017
| 1399
| Alastair M. Robinson
|-
| 5018
| 139A
| Austex Software
|-
| 5019
| 139B
| Sören Gust
|-
| 5020
| 139C
| Rok Krajnc
|-
| 5030
| 13A6
| Tim Tashpulatov
|-
| 5040
| 13B0
| 7-bit
|-
| 5050
| 13BA
| Sakura IT
|-
| 5060
| 13C4
| FPGAArcade
|-
| 5070
| 13CE
| CancerSoft Inc.
|-
| 5080
| 13D8
| Stephen Leary
|-
| 5090
| 13E2
| DMA Softlab LLC
|-
| 5100
| 13EC
| Brookhouse Engineering
|-
| 5110
| 13F6
| Eduardo Arana
|-
| 5120
| 1400
| CS-LAB
|-
| 5130
| 140A
| Robert Miranda
|-
| 5140
| 1414
| RastPort
|-
| 5132
| 140C
| UAS Interface Ltd6
|-
| 5150
| 141E
| Amiga Kit
|-
| 5160
| 1428
| Central Texas Commodore User Group
|-
| 5170
| 1432
| Confusion Research Center
|-
| 5180
| 143C
| Solar Soyuz Zaibatsu
|-
| 5500
| 157C
| Inhouse Information
|-
| 5768
| 1688
| Bio Con
|-
| 6148
| 1804
| HK-Computer
|-
| 6502
| 1966
| Cloanto
|-
| 6520
| 1978
| Oliver Gantert
|-
| 7777
| 1E61
| Rafal Gabriel Chyla
|-
| 8215
| 2017
| Vortex
|-
| 8244
| 2034
| Spirit Technology
|-
| 8290
| 2062
| Expansion Systems
|-
| 8448
| 2100
| ReadySoft
|-
| 8512
| 2140
| Phase 5 Digital Products
|-
| 8553
| 2169
| Digital Processing Systems Inc.
|-
| 8704
| 2200
| ACT Elektronik
|-
| 8738
| 2222
| ACT Elektronik
|-
| 9512
| 2528
| Tower Technologies
|-
| 10676
| 29B4
| Electronic Design
|-
| 14195
| 3773
| Media-net-Point
|-
| 14501
| 38A5
| Petsoff, Finland
|-
| 16375
| 3FF7
| Uwe Gerlach
|-
| 16707
| 4143
| Ateo Concepts
|-
| 16708
| 4144
| ALiENDESiGN
|-
| 16945
| 4231
| A.C.T.
|-
| 17740
| 454C
| HK-Computer (ELSAT)
|-
| 18260
| 4754
| MacroSystems (Germany)
|-
| 19796
| 4D54
| Markt & Technik
|-
| 22359
| 5757
| Markt & Technik
|-
| 26464
| 6760
| Combitec
|-
| 26470
| 6766
| Combitec
|-
| 28014
| 6D6E
| MNT Media and Technology UG
|-
| 32768
| 8000
| M.A.S.T.
|-
| 42240
| A500
| Aethreum Digital
|-
| 43437
| A9AD
| Reis-Ware
|-
| 43521
| AA01
| Cameron
|-
| 43537
| AA11
| Reis-Ware
|-
| 44359
| AD47
| Matay
|-
| 46504
| B5A8
| Phoenix
|-
| 49160
| C008
| Combitec
|-
| 61453
| F00D
| Forefront Technologies Inc.
|}

For any changes/additions to this registry please use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Amiga Hardware Manufacturer ID Registry

2018-09-29T21:46:15Z

Steven Solie: /* Registry */

__TOC__

= How to Obtain a Manufacturer Number =

Manufacturer's numbers are assigned by the AmigaOS development team. To obtain your unique manufacturer number use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Be sure and include your name, email and the type of expansion product you are developing.

= Your Manufacturer Number =

Attention hardware manufacturers. If you are developing a hardware expansion product for the Classic Amiga (e.g. 500, 2000, 3000) then you will need to obtain a special manufacturer ID number from the AmigaOS development team to identify your product. This manufacturer number is used by the Amiga to link your hardware with its driver software at boot time.

Your manufacturer number is part of the special protocol that the Amiga uses to automatically configure all expansion devices on the bus without the user having to cut jumpers or adjust dip switches. This is called auto-config.

At start-up time, the system first polls each board in the system and assigns the board its own address space. If it is a memory board, its RAM is linked into the memory free pool. Later in the boot sequence, after DOS is initialized, the binddrivers program is run. Binddrivers will search the directory SYS:Expansion for the drivers that go with the boards.

To do this binddrivers looks in the Tool Type field of all icon files in SYS:Expansion. If the first seven bytes of the Tool Type field are "PRODUCT", then this is an icon file for a driver.

Binddrivers will then attempt to match the drivers it has found with the boards that were found earlier. This is where your manufacturer number comes in.

Your manufacturer number goes in two places. First, it is burned in hex form into the PAL which is part of ALL auto-config expansion products. Second, it appears in ASCII in the Tool Type field of the icon file for your product's driver. By matching these two numbers, the Amiga can automatically configure your board and bind it's software driver into the system as well.

The manufacturer's number is a 16-bit ID which appears in PAL offsets $10-$17. There is also an 8-bit product number which you assign. The product number is for uniquely identifying different products from the same vendor. The product number will appear in PAL offsets $04-$07. This gives you a total of 24 bits to identify each of your products.

These 24 bits of information in the PAL which identify your product are matched against the information in the Tool Type field of all icon files in the SYS:Expansion drawer. For example, suppose you are manufacturer #1019. You have two products, #1 and #2 which both use the same driver. The icon for your driver for these two products would have a Tool Type set to "PRODUCT=1019/1|1019/2". This means: I am an icon for a driver that works with product number 1 or 2 from manufacturer 1019, now bind me. Spaces are not legal. Here are two other examples:

; PRODUCT=1208/11
: is the Tool Type for a driver for product 11 from manufacturer number 1208.

; PRODUCT=1017
: is the Tool Type for a driver for any product from manufacturer number 1017.

For an informal explanation of the auto-configuration process, see the chapter on Software Expansion Architecture from the 2nd Annual Amiga Developer's Conference Notes (available on ADCD 2.1). For the details of timing, power, the PAL equations and PAL address specifications and the expansion library documentation, see sections 3.1 to 3.3 of the A500/A2000 Technical Reference Manual. The original auto-config spec appears in the A1000 Schematics and Expansion Specification.

The auto-config process makes the addition of expansion products to the system very easy. All the user has to do is put the board in any slot and copy the driver from the release disk to his own SYS:Expansion drawer. Everything else is automatic. There are no jumpers or dip switches to set. Best of all, you will get a lot less support calls asking how to make your product work with the XYZ-Corp-battery-backed-clock.

= Notes =

Some notes on hardware manufacturer ID assignment.

* Manufacturer ID numbers are assigned free of charge.
* Please provide the following information when requesting an ID:
*# Name of the company or person
*# Postal address/contact address
*# Name of the contact person, with a corresponding e-mail address
*# A brief description of the kind of products you want to produce
* All ID numbers smaller than 5000 must be considered unsafe because no information exists on which numbers exactly were taken during the time Commodore, Inc. disintegrated.
* ID numbers in the range 8192 to 18841 must be considered unsafe because some hardware developers mistook the numbers assigned to them to be given in hexadecimal format. Hence 0x2000 = 8192 and 0x4999 = 18841.

= Example code =

<syntaxhighlight>
/*-----------------------------------------------*/
/* Here is a short program which will tell you */
/* about the expansion boards configured in your */
/* system without you opening up the machine. */
/* Code by Bill Koester of CATS */
/*-----------------------------------------------*/
#include <libraries/configvars.h>
#include <libraries/expansion.h>

struct ExpansionBase *ExpansionBase;

void cleanup();
void printdev();

int main()
{
struct ConfigDev *MyConfigDev;

/*----------------------------------*/
/* Open the expansion library, */
/* if there is a problem then exit */
/*----------------------------------*/

ExpansionBase =(struct ExpansionBase *) OpenLibrary(EXPANSIONNAME,0);
if(ExpansionBase==NULL)
{
printf("Error opening expansion library!!\n");
cleanup();
exit(0);
}

/*--------------------------------------------*/
/* Use FindConfigDev to get info on the first */
/* expansion board on the list maintained by */
/* Exec. If there are no expansion boards in */
/* the system then exit. */
/*--------------------------------------------*/

MyConfigDev = NULL;

/*--------------------------------------------------*/
/* FindConfigDev(oldConfigDev,manufacturer,product) */
/* oldConfigDev = NULL for the top of the list */
/* manufacturer = -1 for any manufacturer */
/* product = -1 for any product */
/*--------------------------------------------------*/

MyConfigDev = FindConfigDev(NULL,-1,-1);

if(MyConfigDev==NULL)
{
printf("No Configured Devices found!!\n");
cleanup();
exit(0);
}

printdev(MyConfigDev);

/*-----------------------------------*/
/* OK, there is at least one board, */
/* so loop and get the entire list */
/* printing as we go with printdev() */
/*-----------------------------------*/

while(MyConfigDev = FindConfigDev(MyConfigDev,-1,-1))
{
printdev(MyConfigDev);
}
cleanup();
return 0;
}

/*-------------------*/
/* Close up shop... */
/*-------------------*/
void cleanup()
{
if(ExpansionBase)
CloseLibrary(ExpansionBase);
}

/*----------------------------------*/
/* Print out the contents of the */
/* dev structure for this expansion */
/* product. */
/*----------------------------------*/

void printdev(dev)
struct ConfigDev *dev;
{
char buff[200];

printf("Flags = ");
if(dev->cd_Flags==NULL)
printf("NULL ");
if(dev->cd_Flags&CDF_SHUTUP)
printf("CDF_SHUTUP ");
if(dev->cd_Flags&CDF_CONFIGME)
printf("CDF_CONFIGME ");
printf("\n");
printf("Board Address = %x\n",dev->cd_BoardAddr);
printf("Board Size = %d bytes\n",dev->cd_BoardSize);
printf("Slot Address = %d\n",dev->cd_SlotAddr);
printf("Slot Size = %d\n",dev->cd_SlotSize);
printf("Driver code at %x\n",dev->cd_Driver);

printf("er_Type = %x\n",dev->cd_Rom.er_Type);
printf("er_Product = %x\n",dev->cd_Rom.er_Product);
printf("er_Flags = %x\n",dev->cd_Rom.er_Flags);
printf("er_Reserved03 = %x\n",dev->cd_Rom.er_Reserved03);
printf("er_Manufacturer = %x\n",dev->cd_Rom.er_Manufacturer);
printf("er_SerialNumber = %x\n",dev->cd_Rom.er_SerialNumber);
printf("er_InitDiagVec = %x\n",dev->cd_Rom.er_InitDiagVec);
printf("er_Reserved0c = %x\n",dev->cd_Rom.er_Reserved0c);
printf("er_Reserved0d = %x\n",dev->cd_Rom.er_Reserved0d);
printf("er_Reserved0e = %x\n",dev->cd_Rom.er_Reserved0e);
printf("er_Reserved0f = %x\n",dev->cd_Rom.er_Reserved0f);

printf("Hit Return to continue:\n");
gets(buff);
}
</syntaxhighlight>

= Registry =

{| class="wikitable"
! ID (decimal)
! ID (hexadecimal)
! Manufacturer
! Notes
|-
| 1
| 0001
| Micronik
|-
| 211
| 00D3
| Pacific Peripherals/Profex
|-
| 221
| 00DD
| Kupke Computertechnik GmbH
|-
| 256
| 0100
| Memphis
| Originally registered to MacroSystems US
|-
| 512
| 0200
| 3-State Computertechnik
|-
| 513
| 0201
| Commodore (Braunschweig)
|-
| 514
| 0202
| Commodore (West Chester)
|-
| 515
| 0203
| Commodore (West Chester)
| Originally registered to Combitech/Macrosystem
|-
| 756
| 02F4
| Progressive Peripherals & Software
|-
| 767
| 02FF
| Kolff Computer Supplies
|-
| 1001
| 03E9
| Tecmar
|-
| 1002
| 03EA
| Telesys
|-
| 1003
| 03EB
| The Micro-Forge
|-
| 1004
| 03EC
| Kronos/C Ltd.
| Originally registered to Card Co. (Supra)
|-
| 1005
| 03ED
| A-Squared
|-
| 1006
| 03EE
| Comspec Communications
|-
| 1007
| 03EF
| HT Electronics
|-
| 1008
| 03F0
| RDS Software
|-
| 1009
| 03F1
| Anakin Research
|-
| 1010
| 03F2
| MicroBotics
|-
| 1011
| 03F3
| Bob Krauth
|-
| 1012
| 03F4
| Access Associates (Alegra)
|-
| 1013
| 03F5
| Mini Comp Systems Ltd.
|-
| 1014
| 03F6
| Cypress Technology
|-
| 1015
| 03F7
| Fuller Computers
|-
| 1016
| 03F8
| Galaxy Computers
|-
| 1017
| 03F9
| ADA Research
|-
| 1018
| 03FA
| Computer Service Italia
|-
| 1019
| 03FB
| Amigo
|-
| 1020
| 03FC
| Micro-Solutions Inc.
|-
| 1021
| 03FD
| Stacar International
|-
| 1022
| 03FE
| Video Precisions
|-
| 1023
| 03FF
| ASDG, Inc.
|-
| 1025
| 0401
| Ing. Buero Kalawsky
|-
| 1026
| 0402
| Computer Tuning
|-
| 1027
| 0403
| Interplan Unternehmensberatung
|-
| 1028
| 0404
| Imtronics/Memphis
| Originally registered to Peter Ohlich
|-
| 1030
| 0406
| Commodore (Lowell University)
| Originally registered to Productivity Center
|-
| 1041
| 0411
| Design Labs
|-
| 1042
| 0412
| MCS
|-
| 1043
| 0413
| B. J. Freeman
|-
| 1044
| 0414
| Side Effects Inc.
|-
| 1045
| 0415
| Oklahoma Personal Comp.
|-
| 1046
| 0416
| Advanced Micro Innovations
|-
| 1047
| 0417
| Industrial Support Services
|-
| 1048
| 0418
| Technisoft
|-
| 1049
| 0419
| Prolific, Inc.
|-
| 1050
| 041A
| Softeam, Inc.
|-
| 1051
| 041B
| GRC Electronics
|-
| 1052
| 041C
| David Lai
|-
| 1053
| 041D
| Ameristar Technologies
|-
| 1054
| 041E
| Cline Refrigeration
|-
| 1055
| 041F
| Cardiac Pacemakers, Inc.
|-
| 1056
| 0420
| Supra Corp. (Creative Microsystems)
|-
| 1057
| 0421
| Wayne Diener
|-
| 1058
| 0422
| Computer Systems Associates (CSA)
|-
| 1059
| 0423
| Trionix, Inc.
|-
| 1060
| 0424
| David Lucas
|-
| 1061
| 0425
| Analog Precision
| Also assigned to D & L Distributing
|-
| 1267
| 04F3
| RBM Digitaltechnik
|-
| 1282
| 0502
| M-TEC Hardware Design
|-
| 1337
| 0539
| Thomas Stenzel (DaFR34K)
|-
| 1576
| 0628
| Boris Križma
|-
| 1761
| 06E1
| Great Valley Products
|-
| 1803
| 070B
| UAE Amiga Emulator
|-
| 2002
| 07D2
| Mimetics Corp.
|-
| 2003
| 07D3
| ACDA
|-
| 2004
| 07D4
| Finn R. Jacobsen
|-
| 2005
| 07D5
| Elthen Electronics
|-
| 2006
| 07D6
| Nine Tiles Computer Systems Ltd.
|-
| 2007
| 07D7
| Analog Electronics
|-
| 2008
| 07D8
| Bell & Howell
|-
| 2009
| 07D9
| Roland Kochler
|-
| 2010
| 07DA
| Byte Corp.
|-
| 2011
| 07DB
| Reserved
|-
| 2012
| 07DC
| DKB, Inc.
| Previously named Michigan Software
|-
| 2013
| 07DD
| Pacific Peripherals
|-
| 2014
| 07DE
| Sysaphus Software
|-
| 2015
| 07DF
| Digitronics
|-
| 2016
| 07E0
| Akron Systems
|-
| 2017
| 07E1
| Great Valley Products
|-
| 2018
| 07E2
| Calmos
|-
| 2019
| 07E3
| Dover Research
|-
| 2020
| 07E4
| David Krehbiel
|-
| 2021
| 07E5
| Synergy Peripheral Systems
| Also known as California Access
|-
| 2022
| 07E6
| Xetec
|-
| 2023
| 07E7
| Micron Technology
|-
| 2024
| 07E8
| CH Electronics
|-
| 2025
| 07E9
| American Liquid Light
|-
| 2026
| 07EA
| Progressive Peripherals & Software
| Also used by Ateo
|-
| 2027
| 07EB
| Wicat Systems
|-
| 2028
| 07EC
| Applied Systems & Peripherals
|-
| 2029
| 07ED
| Delaware Valley Software
|-
| 2030
| 07EE
| Palomax
|-
| 2031
| 07EF
| Incognito Software
|-
| 2032
| 07F0
| Jadesign
|-
| 2033
| 07F1
| BVR
|-
| 2034
| 07F2
| Spirit Technology
|-
| 2035
| 07F3
| Spirit Technology
|-
| 2036
| 07F4
| Atronic
|-
| 2037
| 07F5
| Scott Karlin
|-
| 2038
| 07F6
| Howitch
|-
| 2039
| 07F7
| Sullivan Brothers Visual Engineers
|-
| 2040
| 07F8
| G I T
|-
| 2041
| 07F9
| Amigo Business Computers
|-
| 2042
| 07FA
| Micro E Ab
|-
| 2043
| 07FB
| Ralph Kruse
|-
| 2044
| 07FC
| Clearpoint Research
|-
| 2045
| 07FD
| Kodiak
|-
| 2046
| 07FE
| BSC
| Originally registered to Phoenix Electronics
|-
| 2047
| 07FF
| No Name Shown
|-
| 2048
| 0800
| Commodore Braunschweig
|-
| 2049
| 0801
| BSC
| Originally registered to Elaborate Bytes
|-
| 2050
| 0802
| Kronos/C Ltd.
|-
| 2051
| 0803
| Spartanics
|-
| 2052
| 0804
| Jochheim Computer Tuning
|-
| 2053
| 0805
| Trans Data Systems
|-
| 2054
| 0806
| Applied Systems & Peripherals Ltd.
|-
| 2055
| 0807
| Checkpoint Technologies
| Originally registered to Amiga Solutions
|-
| 2056
| 0808
| Adept Development
|-
| 2057
| 0809
| Advanced Computer Design
|-
| 2058
| 080A
| Sir Netics
|-
| 2059
| 080B
| Expert Services
|-
| 2060
| 080C
| Digital Art Systems
|-
| 2061
| 080D
| Adept Development
|-
| 2062
| 080E
| Expansion Technologies (Expansion Systems)
|-
| 2063
| 080F
| Alphatech
|-
| 2064
| 0810
| Edotronik GmbH
|-
| 2065
| 0811
| California Access/Synergy
| Originally registered to Logical Design Works
|-
| 2066
| 0812
| Bowden, Williams, Full & Assoc.
|-
| 2067
| 0813
| NES, Inc.
|-
| 2068
| 0814
| Amdev
|-
| 2069
| 0815
| Big Brother Security Systems
|-
| 2070
| 0816
| Active Circuits Inc.
|-
| 2071
| 0817
| ICD, Inc.
|-
| 2072
| 0818
| Multi-Meg Electronique
|-
| 2073
| 0819
| Kupke Computertechnik GmbH
|-
| 2074
| 081A
| The Checkered Ball
|-
| 2075
| 081B
| Hi Tension Computer Services Ltd. (UK)
|-
| 2076
| 081C
| Alfa Data
| Originally assigned to Elmtech Research, Ltd. (UK)
|-
| 2077
| 081D
| Great Valley Products
| Originally registered to Clartscreen, Ltd. (UK)
|-
| 2078
| 081E
| Interworks
|-
| 2079
| 081F
| Galysh Enterprises
|-
| 2080
| 0820
| Hardital Synthesis
| Originally registered to Realtime Games Software Ltd.
|-
| 2081
| 0821
| GBS
|-
| 2082
| 0822
| Circum Design Inc.
|-
| 2083
| 0823
| Alberta Micro Electronic Center
|-
| 2084
| 0824
| Bestech
|-
| 2085
| 0825
| Lasar Fantasy
|-
| 2086
| 0826
| Pulsar
|-
| 2087
| 0827
| Ivis
|-
| 2088
| 0828
| Applied Engineering
|-
| 2089
| 0829
| Solid-State Design & Development
|-
| 2090
| 082A
| Vison Quest
|-
| 2091
| 082B
| Seaview Software
|-
| 2092
| 082C
| BSC
| Mistakenly used by ADS (Advanced Development Software)
|-
| 2093
| 082D
| Bernd Culenfeld
|-
| 2094
| 082E
| American Liquid Light
|-
| 2095
| 082F
| CEGITES
|-
| 2096
| 0830
| Quadlite Computers Ltd.
| Originally registered to EV Industries
|-
| 2097
| 0831
| Silicon Peace
|-
| 2098
| 0832
| Black Belt Systems
|-
| 2099
| 0833
| Village Tronic
| Originally registerd to Steve Yaeger
|-
| 2100
| 0834
| ReadySoft
|-
| 2101
| 0835
| Phoenix Micro Technologies
|-
| 2102
| 0836
| Advanced Systems & Software
| Orignally assigned to Preferred Technology
|-
| 2103
| 0837
| Rombo Productions
|-
| 2104
| 0838
| Impulse Inc.
|-
| 2105
| 0839
| Beta Unlimited
|-
| 2106
| 083A
| Memory Expansion System, Ltd.
|-
| 2107
| 083B
| Vortex Computer Systems GmbH
|-
| 2108
| 083C
| Platypus Systems
|-
| 2109
| 083D
| Gigatron OHG
|-
| 2110
| 083E
| PG Electronics
|-
| 2111
| 083F
| New Technologies Group
|-
| 2112
| 0840
| Interactive Video Systems (IVS)
| Pacific Peripherals
|-
| 2113
| 0841
| Vector
| Originally registered to H. K. Computer
|-
| 2114
| 0842
| Pacific Digital
| Originally registered to C. H. Helfrich Elektronik
|-
| 2115
| 0843
| Xanadu
|-
| 2116
| 0844
| Pacific Digital
| Originally registered to AMS
|-
| 2117
| 0845
| X-Pert
|-
| 2118
| 0846
| The Amiga Centre
|-
| 2119
| 0847
| Digital Pacific
|-
| 2120
| 0848
| Solid State Leisure
|-
| 2121
| 0849
| Hydra Systems
| Originally registered to Analog Electronics
|-
| 2122
| 084A
| Cumana
|-
| 2123
| 084B
| KAPS 2C Conception
|-
| 2124
| 084C
| Mike Mason
|-
| 2125
| 084D
| For Your Eyes
|-
| 2126
| 084E
| Volkmar Breitfeld Computersysteme
|-
| 2127
| 084F
| Sunrize Industries
|-
| 2128
| 0850
| Scott Advanced Micro Designs
|-
| 2129
| 0851
| Digital Micronics
|-
| 2130
| 0852
| Alfa-Laval
|-
| 2131
| 0853
| Multigros A/S
|-
| 2132
| 0854
| Archos
|-
| 2133
| 0855
| Icom Simulations
|-
| 2134
| 0856
| Commodore Test Engineering Group
|-
| 2135
| 0857
| Microcreations
|-
| 2136
| 0858
| Shoestring Productions
|-
| 2137
| 0859
| Faberushi
|-
| 2138
| 085A
| Evesham Micro Ltd.
|-
| 2139
| 085B
| Panagolin Laser Software
|-
| 2140
| 085C
| Thomas Rudloff
|-
| 2141
| 085D
| Daniel Hohabir
|-
| 2142
| 085E
| GfxBase, Inc.
|-
| 2143
| 085F
| Axellabs
|-
| 2144
| 0860
| Roctec Electronics Inc.
|-
| 2145
| 0861
| Omega Datentechnik
|-
| 2146
| 0862
| Atlantis
|-
| 2147
| 0863
| Skytec Computers
|-
| 2148
| 0864
| Protar Electronics
|-
| 2149
| 0865
| ACS
|-
| 2150
| 0866
| Software Results Enterprises
| Originally registered to University of Illinois
|-
| 2151
| 0867
| Infinity Systems Design Group
|-
| 2152
| 0868
| Trade It
|-
| 2153
| 0869
| Suntec, Inc.
|-
| 2154
| 086A
| DJW Micro Systems
| Originally registered to Tritec Marketing
|-
| 2155
| 086B
| Power Computing Ltd.
|-
| 2156
| 086C
| MacroSystems
|-
| 2157
| 086D
| Masoboshi GmbH (DCE)
|-
| 2158
| 086E
| HAL Software Hardware Handel
|-
| 2159
| 086F
| Mainhattan Data
| Originally registered to Michael Lamm Computersysteme
|-
| 2160
| 0870
| Digital Processing System
| Originally registered to bbdp Electronics
|-
| 2161
| 0871
| Blue Ribbon Soundworks
| Originally registered to Design Computer Systems
|-
| 2162
| 0872
| XPert
| Originally registered to The Station
|-
| 2163
| 0873
| DelaComp
| Originally registered to Bryan Williams
|-
| 2164
| 0874
| Superformance Computer Engineering GmbH
|-
| 2165
| 0875
| Overland Engineering
|-
| 2166
| 0876
| Thomas Hamren
|-
| 2167
| 0877
| Village Tronic
|-
| 2168
| 0878
| Toolbox Design
|-
| 2169
| 0879
| Digital Processing System
|-
| 2170
| 087A
| Superformance
|-
| 2171
| 087B
| Utilities Unlimited
|-
| 2172
| 087C
| phase 5
|-
| 2173
| 087D
| Juergen Kommos
|-
| 2174
| 087E
| Electronic Design
|-
| 2175
| 087F
| James Cook University of North Queensland
|-
| 2176
| 0880
| AmiTrix Development
|-
| 2177
| 0881
| Ferranti
|-
| 2178
| 0882
| Leviathan Development
|-
| 2179
| 0883
| United Video Inc.
|-
| 2180
| 0884
| GPSoft Pty. Ltd.
| Originally registered to Juergen Kommos
|-
| 2181
| 0885
| ArMAX
| Oliver Bausch
|-
| 2182
| 0886
| CP Computer
|-
| 2183
| 0887
| AMOK - Amiga Module & Oberon Klub
|-
| 2184
| 0888
| ITEK Neser & Sieber GbR
|-
| 2185
| 0889
| Phillip C. Lello
|-
| 2186
| 088A
| Cyborg Design Services
|-
| 2187
| 088B
| G2 Systems
|-
| 2188
| 088C
| Pro System Computersysteme
|-
| 2189
| 088D
| ZEUS Electronic
| Originally registered to MSPI (Markt & Technik)
|-
| 2190
| 088E
| Altatech
|-
| 2191
| 088F
| NewTek
|-
| 2192
| 0890
| M-TEC Hardware Design
| Originally registered to Hardware Design Udo Neuroth
|-
| 2193
| 0891
| Great Valley Products
| Originally registered to Viona Development
|-
| 2194
| 0892
| Amitek
| Originally assigned to Marpet Developments
|-
| 2195
| 0893
| Ingenieurbuero Helfrich
|-
| 2196
| 0894
| The Neo Group
|-
| 2197
| 0895
| Cyon
|-
| 2198
| 0896
| Bob Research Group
|-
| 2199
| 0897
| Richmond Sound Design Ltd.
|-
| 2200
| 0898
| US Cybernetics
|-
| 2201
| 0899
| Fulvio Ieva
|-
| 2202
| 089A
| Silicon Studio
|-
| 2203
| 089B
| MacroSystems (USA)
| Was named Micro System Devices
|-
| 2204
| 089C
| Conspector Entertainment
|-
| 2205
| 089D
| Laserforum
|-
| 2206
| 089E
| Elbox Computer
| Mistakenly used by Index Information Ltd.
|-
| 2207
| 089F
| Applied Magic Inc.
|-
| 2208
| 08A0
| SDL Ltd.
|-
| 2560
| 0A00
| Harms
|-
| 2588
| 0A1C
| A1K.org Community
|-
| 2640
| 0A50
| Micronik
|-
| 3084
| 0C0C
| Team 4
|-
| 3643
| 0E3B
| E3B
| Michael Boehmer
|-
| 3855
| 0F0F
| Micronik
|-
| 4096
| 1000
| MegaMicro
|-
| 4110
| 100E
| DigiFeX
|-
| 4136
| 1028
| Imtronics/Memphis
|-
| 4149
| 1035
| PROTAR
|-
| 4369
| 1111
| Frank Strauß Elektronik
| Also used by Kupke
|-
| 4626
| 1212
| Individual Computers
|-
| 4648
| 1228
| Flesch Hornemann Computer Elec.
|-
| 4680
| 1248
| Kupke Computertechnik GmbH
|-
| 4711
| 1267
| RBM digitaltechnik
|-
| 4754
| 1292
| MacroSystems
|-
| 5000
| 1388
| ITH
|-
| 5001
| 1389
| VMC
|-
| 5010
| 1392
| Ambience Creation Technology
|-
| 5011
| 1393
| Creative Development
|-
| 5012
| 1394
| Georg Braun
|-
| 5013
| 1395
| Swedish User Group of Amiga
|-
| 5014
| 1396
| Jakub Bednarski
|-
| 5015
| 1397
| KryoFlux, Ltd.
|-
| 5016
| 1398
| Igor Majstorovic
|-
| 5017
| 1399
| Alastair M. Robinson
|-
| 5018
| 139A
| Austex Software
|-
| 5019
| 139B
| Sören Gust
|-
| 5020
| 139C
| Rok Krajnc
|-
| 5030
| 13A6
| Tim Tashpulatov
|-
| 5040
| 13B0
| 7-bit
|-
| 5050
| 13BA
| Sakura IT
|-
| 5060
| 13C4
| FPGAArcade
|-
| 5070
| 13CE
| CancerSoft Inc.
|-
| 5080
| 13D8
| Stephen Leary
|-
| 5090
| 13E2
| DMA Softlab LLC
|-
| 5100
| 13EC
| Brookhouse Engineering
|-
| 5110
| 13F6
| Eduardo Arana
|-
| 5120
| 1400
| CS-LAB
|-
| 5130
| 140A
| Robert Miranda
|-
| 5140
| 1414
| RastPort
|-
| 5132
| 140C
| UAS Interface Ltd.
|-
| 5500
| 157C
| Inhouse Information
|-
| 5768
| 1688
| Bio Con
|-
| 6148
| 1804
| HK-Computer
|-
| 6502
| 1966
| Cloanto
|-
| 6520
| 1978
| Oliver Gantert
|-
| 7777
| 1E61
| Rafal Gabriel Chyla
|-
| 8215
| 2017
| Vortex
|-
| 8244
| 2034
| Spirit Technology
|-
| 8290
| 2062
| Expansion Systems
|-
| 8448
| 2100
| ReadySoft
|-
| 8512
| 2140
| Phase 5 Digital Products
|-
| 8553
| 2169
| Digital Processing Systems Inc.
|-
| 8704
| 2200
| ACT Elektronik
|-
| 8738
| 2222
| ACT Elektronik
|-
| 9512
| 2528
| Tower Technologies
|-
| 10676
| 29B4
| Electronic Design
|-
| 14195
| 3773
| Media-net-Point
|-
| 14501
| 38A5
| Petsoff, Finland
|-
| 16375
| 3FF7
| Uwe Gerlach
|-
| 16707
| 4143
| Ateo Concepts
|-
| 16708
| 4144
| ALiENDESiGN
|-
| 16945
| 4231
| A.C.T.
|-
| 17740
| 454C
| HK-Computer (ELSAT)
|-
| 18260
| 4754
| MacroSystems (Germany)
|-
| 19796
| 4D54
| Markt & Technik
|-
| 22359
| 5757
| Markt & Technik
|-
| 26464
| 6760
| Combitec
|-
| 26470
| 6766
| Combitec
|-
| 28014
| 6D6E
| MNT Media and Technology UG
|-
| 32768
| 8000
| M.A.S.T.
|-
| 42240
| A500
| Aethreum Digital
|-
| 43437
| A9AD
| Reis-Ware
|-
| 43521
| AA01
| Cameron
|-
| 43537
| AA11
| Reis-Ware
|-
| 44359
| AD47
| Matay
|-
| 46504
| B5A8
| Phoenix
|-
| 49160
| C008
| Combitec
|-
| 61453
| F00D
| Forefront Technologies Inc.
|}

For any changes/additions to this registry please use the [http://www.amigaos.net/contact AmigaOS web site contact form].

AmiWest 2018 DevCon

2018-09-12T16:11:49Z

Steven Solie: /* October 20 (Friday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =
We are aiming to cover the following topics:

* AmigaOne X5000 and A1222 SATA driver deep dive. How to make your own AmigaOS disk device drivers. (Steven Solie)

* Introducing the infodata.gadget class. (Mark Ritter)

* Tower57 port optimizations explained. (Daniel Müßener)

* "Surprise" developer related software. (Jamie Krueger)

* Ethernet driver development explained including a new framework. (Jamie Krueger)

* Inside the A1222 laptop project. (Hans de Ruiter)

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

Here is the schedule for the Dev Con.

== October 10 (Wednesday) ==

Set up your AmigaOS systems and test them out. This is the time to troubleshoot any equipment or Internet access issues.

== October 11 (Thursday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when we run out of energy.

== October 12 (Friday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when the Classic Clinic starts setting up which should be around 17:00 or so.

AmiWest 2018 DevCon

2018-09-12T16:11:42Z

Steven Solie: /* October 19 (Thursday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =
We are aiming to cover the following topics:

* AmigaOne X5000 and A1222 SATA driver deep dive. How to make your own AmigaOS disk device drivers. (Steven Solie)

* Introducing the infodata.gadget class. (Mark Ritter)

* Tower57 port optimizations explained. (Daniel Müßener)

* "Surprise" developer related software. (Jamie Krueger)

* Ethernet driver development explained including a new framework. (Jamie Krueger)

* Inside the A1222 laptop project. (Hans de Ruiter)

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

Here is the schedule for the Dev Con.

== October 10 (Wednesday) ==

Set up your AmigaOS systems and test them out. This is the time to troubleshoot any equipment or Internet access issues.

== October 11 (Thursday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when we run out of energy.

== October 20 (Friday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when the Classic Clinic starts setting up which should be around 17:00 or so.

AmiWest 2018 DevCon

2018-09-12T16:11:36Z

Steven Solie: /* October 18 (Wednesday) */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =
We are aiming to cover the following topics:

* AmigaOne X5000 and A1222 SATA driver deep dive. How to make your own AmigaOS disk device drivers. (Steven Solie)

* Introducing the infodata.gadget class. (Mark Ritter)

* Tower57 port optimizations explained. (Daniel Müßener)

* "Surprise" developer related software. (Jamie Krueger)

* Ethernet driver development explained including a new framework. (Jamie Krueger)

* Inside the A1222 laptop project. (Hans de Ruiter)

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

Here is the schedule for the Dev Con.

== October 10 (Wednesday) ==

Set up your AmigaOS systems and test them out. This is the time to troubleshoot any equipment or Internet access issues.

== October 19 (Thursday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when we run out of energy.

== October 20 (Friday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when the Classic Clinic starts setting up which should be around 17:00 or so.

AmiWest 2018 DevCon

2018-09-12T16:04:27Z

Steven Solie: /* Syllabus */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =
We are aiming to cover the following topics:

* AmigaOne X5000 and A1222 SATA driver deep dive. How to make your own AmigaOS disk device drivers. (Steven Solie)

* Introducing the infodata.gadget class. (Mark Ritter)

* Tower57 port optimizations explained. (Daniel Müßener)

* "Surprise" developer related software. (Jamie Krueger)

* Ethernet driver development explained including a new framework. (Jamie Krueger)

* Inside the A1222 laptop project. (Hans de Ruiter)

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

Here is the schedule for the Dev Con.

== October 18 (Wednesday) ==

Set up your AmigaOS systems and test them out. This is the time to troubleshoot any equipment or Internet access issues.

== October 19 (Thursday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when we run out of energy.

== October 20 (Friday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when the Classic Clinic starts setting up which should be around 17:00 or so.

AmiWest 2018 DevCon

2018-09-11T15:21:32Z

Steven Solie: /* Syllabus */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =
We are aiming to cover the following topics:

* AmigaOne X5000 and A1222 SATA driver deep dive. How to make your own AmigaOS disk device drivers. (Steven Solie)

* Introducing the infodata.gadget class (Mark Ritter).

* (Watch this space for more info coming soon)

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

Here is the schedule for the Dev Con.

== October 18 (Wednesday) ==

Set up your AmigaOS systems and test them out. This is the time to troubleshoot any equipment or Internet access issues.

== October 19 (Thursday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when we run out of energy.

== October 20 (Friday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when the Classic Clinic starts setting up which should be around 17:00 or so.

AmiWest 2018 DevCon

2018-09-10T03:31:11Z

Steven Solie: /* Syllabus */

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =
We are aiming to cover the following topics:

* AmigaOne X5000 and A1222 SATA driver deep dive. How to make your own AmigaOS disk device drivers.

* (Watch this space for more info coming soon)

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

Here is the schedule for the Dev Con.

== October 18 (Wednesday) ==

Set up your AmigaOS systems and test them out. This is the time to troubleshoot any equipment or Internet access issues.

== October 19 (Thursday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when we run out of energy.

== October 20 (Friday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when the Classic Clinic starts setting up which should be around 17:00 or so.

AmiWest 2018 DevCon

2018-09-10T03:30:54Z

= Getting Ready =

Be sure to have the AmigaOS 4.1 Final Edition SDK installed and ready to go. See [[AmiWest Setup]] for complete details on how to get ready.

= Syllabus =
We are aiming to cover the following topics:

* AmigaOne X5000 and A1222 SATA driver deep delve. How to make your own AmigaOS disk device drivers.

* (Watch this space for more info coming soon)

* Personal Projects. You are encouraged to bring your own personal projects to the DevCon where we, as a group, may be able to help you out.

The DevCon will also be tailored to the group. If something is not interesting we can skip it and move on to something that is interesting. Class participation and feedback during the DevCon is mandatory - repeat, mandatory.

= Schedule =

Here is the schedule for the Dev Con.

== October 18 (Wednesday) ==

Set up your AmigaOS systems and test them out. This is the time to troubleshoot any equipment or Internet access issues.

== October 19 (Thursday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when we run out of energy.

== October 20 (Friday) ==

We will start at 09:30 so please be there for 09:00. We'll have a lunch break around noon. We will stop when the Classic Clinic starts setting up which should be around 17:00 or so.

Tutorials:Main

2018-09-10T03:27:48Z

Steven Solie:

= Tutorials =

Tutorials have been provided by various authors.

== General ==

[[The Hacking Way: Part 1 - First Steps]]

[[The Right Tool for the Job (Shared Objects)]]

[[How to Build Stubs for 68k Libraries]]

[[How to create an AmigaOS 4 library]]

== Amiga Future Programming Articles ==

[[Programming AmigaOS 4: The Development Environment]]

[[Programming AmigaOS 4: Exec - The Kernel]]

[[Programming AmigaOS 4: DOS - The Data Administrator]]

[[Programming AmigaOS 4: Intuition - The User Interface]]

[[Programming AmigaOS 4: Drawing Graphics]]

[[Programming AmigaOS 4: Transparent Windows]]

[[Programming AmigaOS 4: Datatypes - Making Life Easy]]

[[Programming AmigaOS 4: GUI Toolkit ReAction]]

[[Programming AmigaOS 4: Utility - Little Helpers]]

== Debugging ==

[[How to install a hardware interrupt]]

[[How to open and use the exec debug interface]]

[[GDB for Beginners]]

[[Using Crash-Logs for Debugging]]

[[Debug Logging on AmigaOS]]

[[Redirecting Debug Output to the Serial Port on Startup]]

[[Advanced Serial Debugging Guide]]

== GUI ==

[[BOOPSI Gadget Help Strings]]

[[BOOPSI Popup Menus - Part 1]]

[[BOOPSI Popup Menus - Part 2]]

[[BOOPSI Popup Menus - Part 3]]

[[Screen Programming]]

== AmiWest 2018 ==

[[AmiWest Setup]]

[[AmiWest 2018 DevCon]]

== AmiWest 2017 ==

[[AmiWest Setup]]

[[AmiWest 2017 DevCon]]

== AmiWest 2016 ==

[[AmiWest Setup]]

[[AmiWest 2016 DevCon]]

== AmiWest 2015 ==

[[AmiWest Setup]]

[[AmiWest 2015 DevCon]]

== AmiWest 2014 ==

[[AmiWest Setup]]

[[AmiWest 2014 Programming Seminar]]

== AmiWest 2013 ==

[[AmiWest 2013 Programming Conference Synopsis]]

[[AmiWest Setup]]

[[AmiWest 2013 Lesson 1|AmiWest Lesson 1: How to Crash]]

[[AmiWest 2013 Lesson 2|AmiWest Lesson 2: Interpreting Crash Reports]]

[[AmiWest 2013 Lesson 3|AmiWest Lesson 3: ProcTree Redux]]

[[AmiWest 2013 Lesson 4|AmiWest Lesson 4: Simple IP Clients & Servers]]

[[AmiWest 2013 Lesson 5|AmiWest Lesson 5: Bars&Pipes Tools]]

== AmiWest 2012 ==

[[AmiWest Setup]] [https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Introduction-360.mp4 - Video]

[[AmiWest Lesson 1|AmiWest Lesson 1: Coding Basics]] [https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson01-360.mp4 - Video]

[[AmiWest Lesson 2|AmiWest Lesson 2: AmigaOS Fundamentals]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson02-360.mp4 - Video]

[[AmiWest Lesson 3|AmiWest Lesson 3: Input and Output]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson03-360.mp4 - Video]

[[AmiWest Lesson 4|AmiWest Lesson 4: ProcTree]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson04-360.mp4 - Video]

[[AmiWest Lesson 5|AmiWest Lesson 5: MIDI]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson05-360.mp4 - Video]

[[AmiWest Lesson 6|AmiWest Lesson 6: Application Library - Not Presented]]

[[AmiWest Lesson 7|AmiWest Lesson 7: Screen Blanker - Not Presented]]

[[AmiWest Lesson 8|AmiWest Lesson 8: ARexx Ports]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Lesson07-360.mp4 - Video]

[[AmiWest Support]][https://dl.dropboxusercontent.com/u/680455/AmiWest-2012-Programming/Wrap-Up-360.mp4 - Video]

Amiga Hardware Manufacturer ID Registry

2018-04-30T04:05:28Z

Steven Solie: /* Registry */

__TOC__

= How to Obtain a Manufacturer Number =

Manufacturer's numbers are assigned by the AmigaOS development team. To obtain your unique manufacturer number use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Be sure and include your name, email and the type of expansion product you are developing.

= Your Manufacturer Number =

Attention hardware manufacturers. If you are developing a hardware expansion product for the Classic Amiga (e.g. 500, 2000, 3000) then you will need to obtain a special manufacturer ID number from the AmigaOS development team to identify your product. This manufacturer number is used by the Amiga to link your hardware with its driver software at boot time.

Your manufacturer number is part of the special protocol that the Amiga uses to automatically configure all expansion devices on the bus without the user having to cut jumpers or adjust dip switches. This is called auto-config.

At start-up time, the system first polls each board in the system and assigns the board its own address space. If it is a memory board, its RAM is linked into the memory free pool. Later in the boot sequence, after DOS is initialized, the binddrivers program is run. Binddrivers will search the directory SYS:Expansion for the drivers that go with the boards.

To do this binddrivers looks in the Tool Type field of all icon files in SYS:Expansion. If the first seven bytes of the Tool Type field are "PRODUCT", then this is an icon file for a driver.

Binddrivers will then attempt to match the drivers it has found with the boards that were found earlier. This is where your manufacturer number comes in.

Your manufacturer number goes in two places. First, it is burned in hex form into the PAL which is part of ALL auto-config expansion products. Second, it appears in ASCII in the Tool Type field of the icon file for your product's driver. By matching these two numbers, the Amiga can automatically configure your board and bind it's software driver into the system as well.

The manufacturer's number is a 16-bit ID which appears in PAL offsets $10-$17. There is also an 8-bit product number which you assign. The product number is for uniquely identifying different products from the same vendor. The product number will appear in PAL offsets $04-$07. This gives you a total of 24 bits to identify each of your products.

These 24 bits of information in the PAL which identify your product are matched against the information in the Tool Type field of all icon files in the SYS:Expansion drawer. For example, suppose you are manufacturer #1019. You have two products, #1 and #2 which both use the same driver. The icon for your driver for these two products would have a Tool Type set to "PRODUCT=1019/1|1019/2". This means: I am an icon for a driver that works with product number 1 or 2 from manufacturer 1019, now bind me. Spaces are not legal. Here are two other examples:

; PRODUCT=1208/11
: is the Tool Type for a driver for product 11 from manufacturer number 1208.

; PRODUCT=1017
: is the Tool Type for a driver for any product from manufacturer number 1017.

For an informal explanation of the auto-configuration process, see the chapter on Software Expansion Architecture from the 2nd Annual Amiga Developer's Conference Notes (available on ADCD 2.1). For the details of timing, power, the PAL equations and PAL address specifications and the expansion library documentation, see sections 3.1 to 3.3 of the A500/A2000 Technical Reference Manual. The original auto-config spec appears in the A1000 Schematics and Expansion Specification.

The auto-config process makes the addition of expansion products to the system very easy. All the user has to do is put the board in any slot and copy the driver from the release disk to his own SYS:Expansion drawer. Everything else is automatic. There are no jumpers or dip switches to set. Best of all, you will get a lot less support calls asking how to make your product work with the XYZ-Corp-battery-backed-clock.

= Notes =

Some notes on hardware manufacturer ID assignment.

* Manufacturer ID numbers are assigned free of charge.
* Please provide the following information when requesting an ID:
*# Name of the company or person
*# Postal address/contact address
*# Name of the contact person, with a corresponding e-mail address
*# A brief description of the kind of products you want to produce
* All ID numbers smaller than 5000 must be considered unsafe because no information exists on which numbers exactly were taken during the time Commodore, Inc. disintegrated.
* ID numbers in the range 8192 to 18841 must be considered unsafe because some hardware developers mistook the numbers assigned to them to be given in hexadecimal format. Hence 0x2000 = 8192 and 0x4999 = 18841.

= Example code =

<syntaxhighlight>
/*-----------------------------------------------*/
/* Here is a short program which will tell you */
/* about the expansion boards configured in your */
/* system without you opening up the machine. */
/* Code by Bill Koester of CATS */
/*-----------------------------------------------*/
#include <libraries/configvars.h>
#include <libraries/expansion.h>

struct ExpansionBase *ExpansionBase;

void cleanup();
void printdev();

int main()
{
struct ConfigDev *MyConfigDev;

/*----------------------------------*/
/* Open the expansion library, */
/* if there is a problem then exit */
/*----------------------------------*/

ExpansionBase =(struct ExpansionBase *) OpenLibrary(EXPANSIONNAME,0);
if(ExpansionBase==NULL)
{
printf("Error opening expansion library!!\n");
cleanup();
exit(0);
}

/*--------------------------------------------*/
/* Use FindConfigDev to get info on the first */
/* expansion board on the list maintained by */
/* Exec. If there are no expansion boards in */
/* the system then exit. */
/*--------------------------------------------*/

MyConfigDev = NULL;

/*--------------------------------------------------*/
/* FindConfigDev(oldConfigDev,manufacturer,product) */
/* oldConfigDev = NULL for the top of the list */
/* manufacturer = -1 for any manufacturer */
/* product = -1 for any product */
/*--------------------------------------------------*/

MyConfigDev = FindConfigDev(NULL,-1,-1);

if(MyConfigDev==NULL)
{
printf("No Configured Devices found!!\n");
cleanup();
exit(0);
}

printdev(MyConfigDev);

/*-----------------------------------*/
/* OK, there is at least one board, */
/* so loop and get the entire list */
/* printing as we go with printdev() */
/*-----------------------------------*/

while(MyConfigDev = FindConfigDev(MyConfigDev,-1,-1))
{
printdev(MyConfigDev);
}
cleanup();
return 0;
}

/*-------------------*/
/* Close up shop... */
/*-------------------*/
void cleanup()
{
if(ExpansionBase)
CloseLibrary(ExpansionBase);
}

/*----------------------------------*/
/* Print out the contents of the */
/* dev structure for this expansion */
/* product. */
/*----------------------------------*/

void printdev(dev)
struct ConfigDev *dev;
{
char buff[200];

printf("Flags = ");
if(dev->cd_Flags==NULL)
printf("NULL ");
if(dev->cd_Flags&CDF_SHUTUP)
printf("CDF_SHUTUP ");
if(dev->cd_Flags&CDF_CONFIGME)
printf("CDF_CONFIGME ");
printf("\n");
printf("Board Address = %x\n",dev->cd_BoardAddr);
printf("Board Size = %d bytes\n",dev->cd_BoardSize);
printf("Slot Address = %d\n",dev->cd_SlotAddr);
printf("Slot Size = %d\n",dev->cd_SlotSize);
printf("Driver code at %x\n",dev->cd_Driver);

printf("er_Type = %x\n",dev->cd_Rom.er_Type);
printf("er_Product = %x\n",dev->cd_Rom.er_Product);
printf("er_Flags = %x\n",dev->cd_Rom.er_Flags);
printf("er_Reserved03 = %x\n",dev->cd_Rom.er_Reserved03);
printf("er_Manufacturer = %x\n",dev->cd_Rom.er_Manufacturer);
printf("er_SerialNumber = %x\n",dev->cd_Rom.er_SerialNumber);
printf("er_InitDiagVec = %x\n",dev->cd_Rom.er_InitDiagVec);
printf("er_Reserved0c = %x\n",dev->cd_Rom.er_Reserved0c);
printf("er_Reserved0d = %x\n",dev->cd_Rom.er_Reserved0d);
printf("er_Reserved0e = %x\n",dev->cd_Rom.er_Reserved0e);
printf("er_Reserved0f = %x\n",dev->cd_Rom.er_Reserved0f);

printf("Hit Return to continue:\n");
gets(buff);
}
</syntaxhighlight>

= Registry =

{| class="wikitable"
! ID (decimal)
! ID (hexadecimal)
! Manufacturer
! Notes
|-
| 1
| 0001
| Micronik
|-
| 211
| 00D3
| Pacific Peripherals/Profex
|-
| 221
| 00DD
| Kupke Computertechnik GmbH
|-
| 256
| 0100
| Memphis
| Originally registered to MacroSystems US
|-
| 512
| 0200
| 3-State Computertechnik
|-
| 513
| 0201
| Commodore (Braunschweig)
|-
| 514
| 0202
| Commodore (West Chester)
|-
| 515
| 0203
| Commodore (West Chester)
| Originally registered to Combitech/Macrosystem
|-
| 756
| 02F4
| Progressive Peripherals & Software
|-
| 767
| 02FF
| Kolff Computer Supplies
|-
| 1001
| 03E9
| Tecmar
|-
| 1002
| 03EA
| Telesys
|-
| 1003
| 03EB
| The Micro-Forge
|-
| 1004
| 03EC
| Kronos/C Ltd.
| Originally registered to Card Co. (Supra)
|-
| 1005
| 03ED
| A-Squared
|-
| 1006
| 03EE
| Comspec Communications
|-
| 1007
| 03EF
| HT Electronics
|-
| 1008
| 03F0
| RDS Software
|-
| 1009
| 03F1
| Anakin Research
|-
| 1010
| 03F2
| MicroBotics
|-
| 1011
| 03F3
| Bob Krauth
|-
| 1012
| 03F4
| Access Associates (Alegra)
|-
| 1013
| 03F5
| Mini Comp Systems Ltd.
|-
| 1014
| 03F6
| Cypress Technology
|-
| 1015
| 03F7
| Fuller Computers
|-
| 1016
| 03F8
| Galaxy Computers
|-
| 1017
| 03F9
| ADA Research
|-
| 1018
| 03FA
| Computer Service Italia
|-
| 1019
| 03FB
| Amigo
|-
| 1020
| 03FC
| Micro-Solutions Inc.
|-
| 1021
| 03FD
| Stacar International
|-
| 1022
| 03FE
| Video Precisions
|-
| 1023
| 03FF
| ASDG, Inc.
|-
| 1025
| 0401
| Ing. Buero Kalawsky
|-
| 1026
| 0402
| Computer Tuning
|-
| 1027
| 0403
| Interplan Unternehmensberatung
|-
| 1028
| 0404
| Imtronics/Memphis
| Originally registered to Peter Ohlich
|-
| 1030
| 0406
| Commodore (Lowell University)
| Originally registered to Productivity Center
|-
| 1041
| 0411
| Design Labs
|-
| 1042
| 0412
| MCS
|-
| 1043
| 0413
| B. J. Freeman
|-
| 1044
| 0414
| Side Effects Inc.
|-
| 1045
| 0415
| Oklahoma Personal Comp.
|-
| 1046
| 0416
| Advanced Micro Innovations
|-
| 1047
| 0417
| Industrial Support Services
|-
| 1048
| 0418
| Technisoft
|-
| 1049
| 0419
| Prolific, Inc.
|-
| 1050
| 041A
| Softeam, Inc.
|-
| 1051
| 041B
| GRC Electronics
|-
| 1052
| 041C
| David Lai
|-
| 1053
| 041D
| Ameristar Technologies
|-
| 1054
| 041E
| Cline Refrigeration
|-
| 1055
| 041F
| Cardiac Pacemakers, Inc.
|-
| 1056
| 0420
| Supra Corp. (Creative Microsystems)
|-
| 1057
| 0421
| Wayne Diener
|-
| 1058
| 0422
| Computer Systems Associates (CSA)
|-
| 1059
| 0423
| Trionix, Inc.
|-
| 1060
| 0424
| David Lucas
|-
| 1061
| 0425
| Analog Precision
| Also assigned to D & L Distributing
|-
| 1267
| 04F3
| RBM Digitaltechnik
|-
| 1282
| 0502
| M-TEC Hardware Design
|-
| 1337
| 0539
| Thomas Stenzel (DaFR34K)
|-
| 1576
| 0628
| Boris Križma
|-
| 1761
| 06E1
| Great Valley Products
|-
| 1803
| 070B
| UAE Amiga Emulator
|-
| 2002
| 07D2
| Mimetics Corp.
|-
| 2003
| 07D3
| ACDA
|-
| 2004
| 07D4
| Finn R. Jacobsen
|-
| 2005
| 07D5
| Elthen Electronics
|-
| 2006
| 07D6
| Nine Tiles Computer Systems Ltd.
|-
| 2007
| 07D7
| Analog Electronics
|-
| 2008
| 07D8
| Bell & Howell
|-
| 2009
| 07D9
| Roland Kochler
|-
| 2010
| 07DA
| Byte Corp.
|-
| 2011
| 07DB
| Reserved
|-
| 2012
| 07DC
| DKB, Inc.
| Previously named Michigan Software
|-
| 2013
| 07DD
| Pacific Peripherals
|-
| 2014
| 07DE
| Sysaphus Software
|-
| 2015
| 07DF
| Digitronics
|-
| 2016
| 07E0
| Akron Systems
|-
| 2017
| 07E1
| Great Valley Products
|-
| 2018
| 07E2
| Calmos
|-
| 2019
| 07E3
| Dover Research
|-
| 2020
| 07E4
| David Krehbiel
|-
| 2021
| 07E5
| Synergy Peripheral Systems
| Also known as California Access
|-
| 2022
| 07E6
| Xetec
|-
| 2023
| 07E7
| Micron Technology
|-
| 2024
| 07E8
| CH Electronics
|-
| 2025
| 07E9
| American Liquid Light
|-
| 2026
| 07EA
| Progressive Peripherals & Software
| Also used by Ateo
|-
| 2027
| 07EB
| Wicat Systems
|-
| 2028
| 07EC
| Applied Systems & Peripherals
|-
| 2029
| 07ED
| Delaware Valley Software
|-
| 2030
| 07EE
| Palomax
|-
| 2031
| 07EF
| Incognito Software
|-
| 2032
| 07F0
| Jadesign
|-
| 2033
| 07F1
| BVR
|-
| 2034
| 07F2
| Spirit Technology
|-
| 2035
| 07F3
| Spirit Technology
|-
| 2036
| 07F4
| Atronic
|-
| 2037
| 07F5
| Scott Karlin
|-
| 2038
| 07F6
| Howitch
|-
| 2039
| 07F7
| Sullivan Brothers Visual Engineers
|-
| 2040
| 07F8
| G I T
|-
| 2041
| 07F9
| Amigo Business Computers
|-
| 2042
| 07FA
| Micro E Ab
|-
| 2043
| 07FB
| Ralph Kruse
|-
| 2044
| 07FC
| Clearpoint Research
|-
| 2045
| 07FD
| Kodiak
|-
| 2046
| 07FE
| BSC
| Originally registered to Phoenix Electronics
|-
| 2047
| 07FF
| No Name Shown
|-
| 2048
| 0800
| Commodore Braunschweig
|-
| 2049
| 0801
| BSC
| Originally registered to Elaborate Bytes
|-
| 2050
| 0802
| Kronos/C Ltd.
|-
| 2051
| 0803
| Spartanics
|-
| 2052
| 0804
| Jochheim Computer Tuning
|-
| 2053
| 0805
| Trans Data Systems
|-
| 2054
| 0806
| Applied Systems & Peripherals Ltd.
|-
| 2055
| 0807
| Checkpoint Technologies
| Originally registered to Amiga Solutions
|-
| 2056
| 0808
| Adept Development
|-
| 2057
| 0809
| Advanced Computer Design
|-
| 2058
| 080A
| Sir Netics
|-
| 2059
| 080B
| Expert Services
|-
| 2060
| 080C
| Digital Art Systems
|-
| 2061
| 080D
| Adept Development
|-
| 2062
| 080E
| Expansion Technologies (Expansion Systems)
|-
| 2063
| 080F
| Alphatech
|-
| 2064
| 0810
| Edotronik GmbH
|-
| 2065
| 0811
| California Access/Synergy
| Originally registered to Logical Design Works
|-
| 2066
| 0812
| Bowden, Williams, Full & Assoc.
|-
| 2067
| 0813
| NES, Inc.
|-
| 2068
| 0814
| Amdev
|-
| 2069
| 0815
| Big Brother Security Systems
|-
| 2070
| 0816
| Active Circuits Inc.
|-
| 2071
| 0817
| ICD, Inc.
|-
| 2072
| 0818
| Multi-Meg Electronique
|-
| 2073
| 0819
| Kupke Computertechnik GmbH
|-
| 2074
| 081A
| The Checkered Ball
|-
| 2075
| 081B
| Hi Tension Computer Services Ltd. (UK)
|-
| 2076
| 081C
| Alfa Data
| Originally assigned to Elmtech Research, Ltd. (UK)
|-
| 2077
| 081D
| Great Valley Products
| Originally registered to Clartscreen, Ltd. (UK)
|-
| 2078
| 081E
| Interworks
|-
| 2079
| 081F
| Galysh Enterprises
|-
| 2080
| 0820
| Hardital Synthesis
| Originally registered to Realtime Games Software Ltd.
|-
| 2081
| 0821
| GBS
|-
| 2082
| 0822
| Circum Design Inc.
|-
| 2083
| 0823
| Alberta Micro Electronic Center
|-
| 2084
| 0824
| Bestech
|-
| 2085
| 0825
| Lasar Fantasy
|-
| 2086
| 0826
| Pulsar
|-
| 2087
| 0827
| Ivis
|-
| 2088
| 0828
| Applied Engineering
|-
| 2089
| 0829
| Solid-State Design & Development
|-
| 2090
| 082A
| Vison Quest
|-
| 2091
| 082B
| Seaview Software
|-
| 2092
| 082C
| BSC
| Mistakenly used by ADS (Advanced Development Software)
|-
| 2093
| 082D
| Bernd Culenfeld
|-
| 2094
| 082E
| American Liquid Light
|-
| 2095
| 082F
| CEGITES
|-
| 2096
| 0830
| Quadlite Computers Ltd.
| Originally registered to EV Industries
|-
| 2097
| 0831
| Silicon Peace
|-
| 2098
| 0832
| Black Belt Systems
|-
| 2099
| 0833
| Village Tronic
| Originally registerd to Steve Yaeger
|-
| 2100
| 0834
| ReadySoft
|-
| 2101
| 0835
| Phoenix Micro Technologies
|-
| 2102
| 0836
| Advanced Systems & Software
| Orignally assigned to Preferred Technology
|-
| 2103
| 0837
| Rombo Productions
|-
| 2104
| 0838
| Impulse Inc.
|-
| 2105
| 0839
| Beta Unlimited
|-
| 2106
| 083A
| Memory Expansion System, Ltd.
|-
| 2107
| 083B
| Vortex Computer Systems GmbH
|-
| 2108
| 083C
| Platypus Systems
|-
| 2109
| 083D
| Gigatron OHG
|-
| 2110
| 083E
| PG Electronics
|-
| 2111
| 083F
| New Technologies Group
|-
| 2112
| 0840
| Interactive Video Systems (IVS)
| Pacific Peripherals
|-
| 2113
| 0841
| Vector
| Originally registered to H. K. Computer
|-
| 2114
| 0842
| Pacific Digital
| Originally registered to C. H. Helfrich Elektronik
|-
| 2115
| 0843
| Xanadu
|-
| 2116
| 0844
| Pacific Digital
| Originally registered to AMS
|-
| 2117
| 0845
| X-Pert
|-
| 2118
| 0846
| The Amiga Centre
|-
| 2119
| 0847
| Digital Pacific
|-
| 2120
| 0848
| Solid State Leisure
|-
| 2121
| 0849
| Hydra Systems
| Originally registered to Analog Electronics
|-
| 2122
| 084A
| Cumana
|-
| 2123
| 084B
| KAPS 2C Conception
|-
| 2124
| 084C
| Mike Mason
|-
| 2125
| 084D
| For Your Eyes
|-
| 2126
| 084E
| Volkmar Breitfeld Computersysteme
|-
| 2127
| 084F
| Sunrize Industries
|-
| 2128
| 0850
| Scott Advanced Micro Designs
|-
| 2129
| 0851
| Digital Micronics
|-
| 2130
| 0852
| Alfa-Laval
|-
| 2131
| 0853
| Multigros A/S
|-
| 2132
| 0854
| Archos
|-
| 2133
| 0855
| Icom Simulations
|-
| 2134
| 0856
| Commodore Test Engineering Group
|-
| 2135
| 0857
| Microcreations
|-
| 2136
| 0858
| Shoestring Productions
|-
| 2137
| 0859
| Faberushi
|-
| 2138
| 085A
| Evesham Micro Ltd.
|-
| 2139
| 085B
| Panagolin Laser Software
|-
| 2140
| 085C
| Thomas Rudloff
|-
| 2141
| 085D
| Daniel Hohabir
|-
| 2142
| 085E
| GfxBase, Inc.
|-
| 2143
| 085F
| Axellabs
|-
| 2144
| 0860
| Roctec Electronics Inc.
|-
| 2145
| 0861
| Omega Datentechnik
|-
| 2146
| 0862
| Atlantis
|-
| 2147
| 0863
| Skytec Computers
|-
| 2148
| 0864
| Protar Electronics
|-
| 2149
| 0865
| ACS
|-
| 2150
| 0866
| Software Results Enterprises
| Originally registered to University of Illinois
|-
| 2151
| 0867
| Infinity Systems Design Group
|-
| 2152
| 0868
| Trade It
|-
| 2153
| 0869
| Suntec, Inc.
|-
| 2154
| 086A
| DJW Micro Systems
| Originally registered to Tritec Marketing
|-
| 2155
| 086B
| Power Computing Ltd.
|-
| 2156
| 086C
| MacroSystems
|-
| 2157
| 086D
| Masoboshi GmbH (DCE)
|-
| 2158
| 086E
| HAL Software Hardware Handel
|-
| 2159
| 086F
| Mainhattan Data
| Originally registered to Michael Lamm Computersysteme
|-
| 2160
| 0870
| Digital Processing System
| Originally registered to bbdp Electronics
|-
| 2161
| 0871
| Blue Ribbon Soundworks
| Originally registered to Design Computer Systems
|-
| 2162
| 0872
| XPert
| Originally registered to The Station
|-
| 2163
| 0873
| DelaComp
| Originally registered to Bryan Williams
|-
| 2164
| 0874
| Superformance Computer Engineering GmbH
|-
| 2165
| 0875
| Overland Engineering
|-
| 2166
| 0876
| Thomas Hamren
|-
| 2167
| 0877
| Village Tronic
|-
| 2168
| 0878
| Toolbox Design
|-
| 2169
| 0879
| Digital Processing System
|-
| 2170
| 087A
| Superformance
|-
| 2171
| 087B
| Utilities Unlimited
|-
| 2172
| 087C
| phase 5
|-
| 2173
| 087D
| Juergen Kommos
|-
| 2174
| 087E
| Electronic Design
|-
| 2175
| 087F
| James Cook University of North Queensland
|-
| 2176
| 0880
| AmiTrix Development
|-
| 2177
| 0881
| Ferranti
|-
| 2178
| 0882
| Leviathan Development
|-
| 2179
| 0883
| United Video Inc.
|-
| 2180
| 0884
| GPSoft Pty. Ltd.
| Originally registered to Juergen Kommos
|-
| 2181
| 0885
| ArMAX
| Oliver Bausch
|-
| 2182
| 0886
| CP Computer
|-
| 2183
| 0887
| AMOK - Amiga Module & Oberon Klub
|-
| 2184
| 0888
| ITEK Neser & Sieber GbR
|-
| 2185
| 0889
| Phillip C. Lello
|-
| 2186
| 088A
| Cyborg Design Services
|-
| 2187
| 088B
| G2 Systems
|-
| 2188
| 088C
| Pro System Computersysteme
|-
| 2189
| 088D
| ZEUS Electronic
| Originally registered to MSPI (Markt & Technik)
|-
| 2190
| 088E
| Altatech
|-
| 2191
| 088F
| NewTek
|-
| 2192
| 0890
| M-TEC Hardware Design
| Originally registered to Hardware Design Udo Neuroth
|-
| 2193
| 0891
| Great Valley Products
| Originally registered to Viona Development
|-
| 2194
| 0892
| Amitek
| Originally assigned to Marpet Developments
|-
| 2195
| 0893
| Ingenieurbuero Helfrich
|-
| 2196
| 0894
| The Neo Group
|-
| 2197
| 0895
| Cyon
|-
| 2198
| 0896
| Bob Research Group
|-
| 2199
| 0897
| Richmond Sound Design Ltd.
|-
| 2200
| 0898
| US Cybernetics
|-
| 2201
| 0899
| Fulvio Ieva
|-
| 2202
| 089A
| Silicon Studio
|-
| 2203
| 089B
| MacroSystems (USA)
| Was named Micro System Devices
|-
| 2204
| 089C
| Conspector Entertainment
|-
| 2205
| 089D
| Laserforum
|-
| 2206
| 089E
| Elbox Computer
| Mistakenly used by Index Information Ltd.
|-
| 2207
| 089F
| Applied Magic Inc.
|-
| 2208
| 08A0
| SDL Ltd.
|-
| 2560
| 0A00
| Harms
|-
| 2588
| 0A1C
| A1K.org Community
|-
| 2640
| 0A50
| Micronik
|-
| 3084
| 0C0C
| Team 4
|-
| 3643
| 0E3B
| E3B
| Michael Boehmer
|-
| 3855
| 0F0F
| Micronik
|-
| 4096
| 1000
| MegaMicro
|-
| 4110
| 100E
| DigiFeX
|-
| 4136
| 1028
| Imtronics/Memphis
|-
| 4149
| 1035
| PROTAR
|-
| 4369
| 1111
| Frank Strauß Elektronik
| Also used by Kupke
|-
| 4626
| 1212
| Individual Computers
|-
| 4648
| 1228
| Flesch Hornemann Computer Elec.
|-
| 4680
| 1248
| Kupke Computertechnik GmbH
|-
| 4711
| 1267
| RBM digitaltechnik
|-
| 4754
| 1292
| MacroSystems
|-
| 5000
| 1388
| ITH
|-
| 5001
| 1389
| VMC
|-
| 5010
| 1392
| Ambience Creation Technology
|-
| 5011
| 1393
| Creative Development
|-
| 5012
| 1394
| Georg Braun
|-
| 5013
| 1395
| Swedish User Group of Amiga
|-
| 5014
| 1396
| Jakub Bednarski
|-
| 5015
| 1397
| KryoFlux, Ltd.
|-
| 5016
| 1398
| Igor Majstorovic
|-
| 5017
| 1399
| Alastair M. Robinson
|-
| 5018
| 139A
| Austex Software
|-
| 5019
| 139B
| Sören Gust
|-
| 5020
| 139C
| Rok Krajnc
|-
| 5030
| 13A6
| Tim Tashpulatov
|-
| 5040
| 13B0
| 7-bit
|-
| 5050
| 13BA
| Sakura IT
|-
| 5060
| 13C4
| FPGAArcade
|-
| 5070
| 13CE
| CancerSoft Inc.
|-
| 5080
| 13D8
| Stephen Leary
|-
| 5090
| 13E2
| DMA Softlab LLC
|-
| 5100
| 13EC
| Brookhouse Engineering
|-
| 5110
| 13F6
| Eduardo Arana
|-
| 5120
| 1400
| CS-LAB
|-
| 5130
| 140A
| Robert Miranda
|-
| 5140
| 1414
| RastPort
|-
| 5132
| 140C
| UAS Interface Ltd.
|-
| 5500
| 157C
| Inhouse Information
|-
| 5768
| 1688
| Bio Con
|-
| 6148
| 1804
| HK-Computer
|-
| 6502
| 1966
| Cloanto
|-
| 7777
| 1E61
| Rafal Gabriel Chyla
|-
| 8215
| 2017
| Vortex
|-
| 8244
| 2034
| Spirit Technology
|-
| 8290
| 2062
| Expansion Systems
|-
| 8448
| 2100
| ReadySoft
|-
| 8512
| 2140
| Phase 5 Digital Products
|-
| 8553
| 2169
| Digital Processing Systems Inc.
|-
| 8704
| 2200
| ACT Elektronik
|-
| 8738
| 2222
| ACT Elektronik
|-
| 9512
| 2528
| Tower Technologies
|-
| 10676
| 29B4
| Electronic Design
|-
| 14195
| 3773
| Media-net-Point
|-
| 14501
| 38A5
| Petsoff, Finland
|-
| 16375
| 3FF7
| Uwe Gerlach
|-
| 16707
| 4143
| Ateo Concepts
|-
| 16708
| 4144
| ALiENDESiGN
|-
| 16945
| 4231
| A.C.T.
|-
| 17740
| 454C
| HK-Computer (ELSAT)
|-
| 18260
| 4754
| MacroSystems (Germany)
|-
| 19796
| 4D54
| Markt & Technik
|-
| 22359
| 5757
| Markt & Technik
|-
| 26464
| 6760
| Combitec
|-
| 26470
| 6766
| Combitec
|-
| 28014
| 6D6E
| MNT Media and Technology UG
|-
| 32768
| 8000
| M.A.S.T.
|-
| 42240
| A500
| Aethreum Digital
|-
| 43437
| A9AD
| Reis-Ware
|-
| 43521
| AA01
| Cameron
|-
| 43537
| AA11
| Reis-Ware
|-
| 44359
| AD47
| Matay
|-
| 46504
| B5A8
| Phoenix
|-
| 49160
| C008
| Combitec
|-
| 61453
| F00D
| Forefront Technologies Inc.
|}

For any changes/additions to this registry please use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Amiga Hardware Manufacturer ID Registry

2018-04-30T04:00:00Z

Steven Solie: /* Registry */

__TOC__

= How to Obtain a Manufacturer Number =

Manufacturer's numbers are assigned by the AmigaOS development team. To obtain your unique manufacturer number use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Be sure and include your name, email and the type of expansion product you are developing.

= Your Manufacturer Number =

Attention hardware manufacturers. If you are developing a hardware expansion product for the Classic Amiga (e.g. 500, 2000, 3000) then you will need to obtain a special manufacturer ID number from the AmigaOS development team to identify your product. This manufacturer number is used by the Amiga to link your hardware with its driver software at boot time.

Your manufacturer number is part of the special protocol that the Amiga uses to automatically configure all expansion devices on the bus without the user having to cut jumpers or adjust dip switches. This is called auto-config.

At start-up time, the system first polls each board in the system and assigns the board its own address space. If it is a memory board, its RAM is linked into the memory free pool. Later in the boot sequence, after DOS is initialized, the binddrivers program is run. Binddrivers will search the directory SYS:Expansion for the drivers that go with the boards.

To do this binddrivers looks in the Tool Type field of all icon files in SYS:Expansion. If the first seven bytes of the Tool Type field are "PRODUCT", then this is an icon file for a driver.

Binddrivers will then attempt to match the drivers it has found with the boards that were found earlier. This is where your manufacturer number comes in.

Your manufacturer number goes in two places. First, it is burned in hex form into the PAL which is part of ALL auto-config expansion products. Second, it appears in ASCII in the Tool Type field of the icon file for your product's driver. By matching these two numbers, the Amiga can automatically configure your board and bind it's software driver into the system as well.

The manufacturer's number is a 16-bit ID which appears in PAL offsets $10-$17. There is also an 8-bit product number which you assign. The product number is for uniquely identifying different products from the same vendor. The product number will appear in PAL offsets $04-$07. This gives you a total of 24 bits to identify each of your products.

These 24 bits of information in the PAL which identify your product are matched against the information in the Tool Type field of all icon files in the SYS:Expansion drawer. For example, suppose you are manufacturer #1019. You have two products, #1 and #2 which both use the same driver. The icon for your driver for these two products would have a Tool Type set to "PRODUCT=1019/1|1019/2". This means: I am an icon for a driver that works with product number 1 or 2 from manufacturer 1019, now bind me. Spaces are not legal. Here are two other examples:

; PRODUCT=1208/11
: is the Tool Type for a driver for product 11 from manufacturer number 1208.

; PRODUCT=1017
: is the Tool Type for a driver for any product from manufacturer number 1017.

For an informal explanation of the auto-configuration process, see the chapter on Software Expansion Architecture from the 2nd Annual Amiga Developer's Conference Notes (available on ADCD 2.1). For the details of timing, power, the PAL equations and PAL address specifications and the expansion library documentation, see sections 3.1 to 3.3 of the A500/A2000 Technical Reference Manual. The original auto-config spec appears in the A1000 Schematics and Expansion Specification.

The auto-config process makes the addition of expansion products to the system very easy. All the user has to do is put the board in any slot and copy the driver from the release disk to his own SYS:Expansion drawer. Everything else is automatic. There are no jumpers or dip switches to set. Best of all, you will get a lot less support calls asking how to make your product work with the XYZ-Corp-battery-backed-clock.

= Notes =

Some notes on hardware manufacturer ID assignment.

* Manufacturer ID numbers are assigned free of charge.
* Please provide the following information when requesting an ID:
*# Name of the company or person
*# Postal address/contact address
*# Name of the contact person, with a corresponding e-mail address
*# A brief description of the kind of products you want to produce
* All ID numbers smaller than 5000 must be considered unsafe because no information exists on which numbers exactly were taken during the time Commodore, Inc. disintegrated.
* ID numbers in the range 8192 to 18841 must be considered unsafe because some hardware developers mistook the numbers assigned to them to be given in hexadecimal format. Hence 0x2000 = 8192 and 0x4999 = 18841.

= Example code =

<syntaxhighlight>
/*-----------------------------------------------*/
/* Here is a short program which will tell you */
/* about the expansion boards configured in your */
/* system without you opening up the machine. */
/* Code by Bill Koester of CATS */
/*-----------------------------------------------*/
#include <libraries/configvars.h>
#include <libraries/expansion.h>

struct ExpansionBase *ExpansionBase;

void cleanup();
void printdev();

int main()
{
struct ConfigDev *MyConfigDev;

/*----------------------------------*/
/* Open the expansion library, */
/* if there is a problem then exit */
/*----------------------------------*/

ExpansionBase =(struct ExpansionBase *) OpenLibrary(EXPANSIONNAME,0);
if(ExpansionBase==NULL)
{
printf("Error opening expansion library!!\n");
cleanup();
exit(0);
}

/*--------------------------------------------*/
/* Use FindConfigDev to get info on the first */
/* expansion board on the list maintained by */
/* Exec. If there are no expansion boards in */
/* the system then exit. */
/*--------------------------------------------*/

MyConfigDev = NULL;

/*--------------------------------------------------*/
/* FindConfigDev(oldConfigDev,manufacturer,product) */
/* oldConfigDev = NULL for the top of the list */
/* manufacturer = -1 for any manufacturer */
/* product = -1 for any product */
/*--------------------------------------------------*/

MyConfigDev = FindConfigDev(NULL,-1,-1);

if(MyConfigDev==NULL)
{
printf("No Configured Devices found!!\n");
cleanup();
exit(0);
}

printdev(MyConfigDev);

/*-----------------------------------*/
/* OK, there is at least one board, */
/* so loop and get the entire list */
/* printing as we go with printdev() */
/*-----------------------------------*/

while(MyConfigDev = FindConfigDev(MyConfigDev,-1,-1))
{
printdev(MyConfigDev);
}
cleanup();
return 0;
}

/*-------------------*/
/* Close up shop... */
/*-------------------*/
void cleanup()
{
if(ExpansionBase)
CloseLibrary(ExpansionBase);
}

/*----------------------------------*/
/* Print out the contents of the */
/* dev structure for this expansion */
/* product. */
/*----------------------------------*/

void printdev(dev)
struct ConfigDev *dev;
{
char buff[200];

printf("Flags = ");
if(dev->cd_Flags==NULL)
printf("NULL ");
if(dev->cd_Flags&CDF_SHUTUP)
printf("CDF_SHUTUP ");
if(dev->cd_Flags&CDF_CONFIGME)
printf("CDF_CONFIGME ");
printf("\n");
printf("Board Address = %x\n",dev->cd_BoardAddr);
printf("Board Size = %d bytes\n",dev->cd_BoardSize);
printf("Slot Address = %d\n",dev->cd_SlotAddr);
printf("Slot Size = %d\n",dev->cd_SlotSize);
printf("Driver code at %x\n",dev->cd_Driver);

printf("er_Type = %x\n",dev->cd_Rom.er_Type);
printf("er_Product = %x\n",dev->cd_Rom.er_Product);
printf("er_Flags = %x\n",dev->cd_Rom.er_Flags);
printf("er_Reserved03 = %x\n",dev->cd_Rom.er_Reserved03);
printf("er_Manufacturer = %x\n",dev->cd_Rom.er_Manufacturer);
printf("er_SerialNumber = %x\n",dev->cd_Rom.er_SerialNumber);
printf("er_InitDiagVec = %x\n",dev->cd_Rom.er_InitDiagVec);
printf("er_Reserved0c = %x\n",dev->cd_Rom.er_Reserved0c);
printf("er_Reserved0d = %x\n",dev->cd_Rom.er_Reserved0d);
printf("er_Reserved0e = %x\n",dev->cd_Rom.er_Reserved0e);
printf("er_Reserved0f = %x\n",dev->cd_Rom.er_Reserved0f);

printf("Hit Return to continue:\n");
gets(buff);
}
</syntaxhighlight>

= Registry =

{| class="wikitable"
! ID (decimal)
! ID (hexadecimal)
! Manufacturer
! Notes
|-
| 1
| 0001
| Micronik
|-
| 211
| 00D3
| Pacific Peripherals/Profex
|-
| 221
| 00DD
| Kupke Computertechnik GmbH
|-
| 256
| 0100
| Memphis
| Originally registered to MacroSystems US
|-
| 512
| 0200
| 3-State Computertechnik
|-
| 513
| 0201
| Commodore (Braunschweig)
|-
| 514
| 0202
| Commodore (West Chester)
|-
| 515
| 0203
| Commodore (West Chester)
| Originally registered to Combitech/Macrosystem
|-
| 756
| 02F4
| Progressive Peripherals & Software
|-
| 767
| 02FF
| Kolff Computer Supplies
|-
| 1001
| 03E9
| Tecmar
|-
| 1002
| 03EA
| Telesys
|-
| 1003
| 03EB
| The Micro-Forge
|-
| 1004
| 03EC
| Kronos/C Ltd.
| Originally registered to Card Co. (Supra)
|-
| 1005
| 03ED
| A-Squared
|-
| 1006
| 03EE
| Comspec Communications
|-
| 1007
| 03EF
| HT Electronics
|-
| 1008
| 03F0
| RDS Software
|-
| 1009
| 03F1
| Anakin Research
|-
| 1010
| 03F2
| MicroBotics
|-
| 1011
| 03F3
| Bob Krauth
|-
| 1012
| 03F4
| Access Associates (Alegra)
|-
| 1013
| 03F5
| Mini Comp Systems Ltd.
|-
| 1014
| 03F6
| Cypress Technology
|-
| 1015
| 03F7
| Fuller Computers
|-
| 1016
| 03F8
| Galaxy Computers
|-
| 1017
| 03F9
| ADA Research
|-
| 1018
| 03FA
| Computer Service Italia
|-
| 1019
| 03FB
| Amigo
|-
| 1020
| 03FC
| Micro-Solutions Inc.
|-
| 1021
| 03FD
| Stacar International
|-
| 1022
| 03FE
| Video Precisions
|-
| 1023
| 03FF
| ASDG, Inc.
|-
| 1025
| 0401
| Ing. Buero Kalawsky
|-
| 1026
| 0402
| Computer Tuning
|-
| 1027
| 0403
| Interplan Unternehmensberatung
|-
| 1028
| 0404
| Imtronics/Memphis
| Originally registered to Peter Ohlich
|-
| 1030
| 0406
| Commodore (Lowell University)
| Originally registered to Productivity Center
|-
| 1041
| 0411
| Design Labs
|-
| 1042
| 0412
| MCS
|-
| 1043
| 0413
| B. J. Freeman
|-
| 1044
| 0414
| Side Effects Inc.
|-
| 1045
| 0415
| Oklahoma Personal Comp.
|-
| 1046
| 0416
| Advanced Micro Innovations
|-
| 1047
| 0417
| Industrial Support Services
|-
| 1048
| 0418
| Technisoft
|-
| 1049
| 0419
| Prolific, Inc.
|-
| 1050
| 041A
| Softeam, Inc.
|-
| 1051
| 041B
| GRC Electronics
|-
| 1052
| 041C
| David Lai
|-
| 1053
| 041D
| Ameristar Technologies
|-
| 1054
| 041E
| Cline Refrigeration
|-
| 1055
| 041F
| Cardiac Pacemakers, Inc.
|-
| 1056
| 0420
| Supra Corp. (Creative Microsystems)
|-
| 1057
| 0421
| Wayne Diener
|-
| 1058
| 0422
| Computer Systems Associates (CSA)
|-
| 1059
| 0423
| Trionix, Inc.
|-
| 1060
| 0424
| David Lucas
|-
| 1061
| 0425
| Analog Precision
| Also assigned to D & L Distributing
|-
| 1267
| 04F3
| RBM Digitaltechnik
|-
| 1282
| 0502
| M-TEC Hardware Design
|-
| 1337
| 0539
| Thomas Stenzel (DaFR34K)
|-
| 1576
| 0628
| Boris Križma
|-
| 1761
| 06E1
| Great Valley Products
|-
| 1803
| 070B
| UAE Amiga Emulator
|-
| 2002
| 07D2
| Mimetics Corp.
|-
| 2003
| 07D3
| ACDA
|-
| 2004
| 07D4
| Finn R. Jacobsen
|-
| 2005
| 07D5
| Elthen Electronics
|-
| 2006
| 07D6
| Nine Tiles Computer Systems Ltd.
|-
| 2007
| 07D7
| Analog Electronics
|-
| 2008
| 07D8
| Bell & Howell
|-
| 2009
| 07D9
| Roland Kochler
|-
| 2010
| 07DA
| Byte Corp.
|-
| 2011
| 07DB
| Reserved
|-
| 2012
| 07DC
| DKB, Inc.
| Previously named Michigan Software
|-
| 2013
| 07DD
| Pacific Peripherals
|-
| 2014
| 07DE
| Sysaphus Software
|-
| 2015
| 07DF
| Digitronics
|-
| 2016
| 07E0
| Akron Systems
|-
| 2017
| 07E1
| Great Valley Products
|-
| 2018
| 07E2
| Calmos
|-
| 2019
| 07E3
| Dover Research
|-
| 2020
| 07E4
| David Krehbiel
|-
| 2021
| 07E5
| Synergy Peripheral Systems
| Also known as California Access
|-
| 2022
| 07E6
| Xetec
|-
| 2023
| 07E7
| Micron Technology
|-
| 2024
| 07E8
| CH Electronics
|-
| 2025
| 07E9
| American Liquid Light
|-
| 2026
| 07EA
| Progressive Peripherals & Software
| Also used by Ateo
|-
| 2027
| 07EB
| Wicat Systems
|-
| 2028
| 07EC
| Applied Systems & Peripherals
|-
| 2029
| 07ED
| Delaware Valley Software
|-
| 2030
| 07EE
| Palomax
|-
| 2031
| 07EF
| Incognito Software
|-
| 2032
| 07F0
| Jadesign
|-
| 2033
| 07F1
| BVR
|-
| 2034
| 07F2
| Spirit Technology
|-
| 2035
| 07F3
| Spirit Technology
|-
| 2036
| 07F4
| Atronic
|-
| 2037
| 07F5
| Scott Karlin
|-
| 2038
| 07F6
| Howitch
|-
| 2039
| 07F7
| Sullivan Brothers Visual Engineers
|-
| 2040
| 07F8
| G I T
|-
| 2041
| 07F9
| Amigo Business Computers
|-
| 2042
| 07FA
| Micro E Ab
|-
| 2043
| 07FB
| Ralph Kruse
|-
| 2044
| 07FC
| Clearpoint Research
|-
| 2045
| 07FD
| Kodiak
|-
| 2046
| 07FE
| BSC
| Originally registered to Phoenix Electronics
|-
| 2047
| 07FF
| No Name Shown
|-
| 2048
| 0800
| Commodore Braunschweig
|-
| 2049
| 0801
| BSC
| Originally registered to Elaborate Bytes
|-
| 2050
| 0802
| Kronos/C Ltd.
|-
| 2051
| 0803
| Spartanics
|-
| 2052
| 0804
| Jochheim Computer Tuning
|-
| 2053
| 0805
| Trans Data Systems
|-
| 2054
| 0806
| Applied Systems & Peripherals Ltd.
|-
| 2055
| 0807
| Checkpoint Technologies
| Originally registered to Amiga Solutions
|-
| 2056
| 0808
| Adept Development
|-
| 2057
| 0809
| Advanced Computer Design
|-
| 2058
| 080A
| Sir Netics
|-
| 2059
| 080B
| Expert Services
|-
| 2060
| 080C
| Digital Art Systems
|-
| 2061
| 080D
| Adept Development
|-
| 2062
| 080E
| Expansion Technologies (Expansion Systems)
|-
| 2063
| 080F
| Alphatech
|-
| 2064
| 0810
| Edotronik GmbH
|-
| 2065
| 0811
| California Access/Synergy
| Originally registered to Logical Design Works
|-
| 2066
| 0812
| Bowden, Williams, Full & Assoc.
|-
| 2067
| 0813
| NES, Inc.
|-
| 2068
| 0814
| Amdev
|-
| 2069
| 0815
| Big Brother Security Systems
|-
| 2070
| 0816
| Active Circuits Inc.
|-
| 2071
| 0817
| ICD, Inc.
|-
| 2072
| 0818
| Multi-Meg Electronique
|-
| 2073
| 0819
| Kupke Computertechnik GmbH
|-
| 2074
| 081A
| The Checkered Ball
|-
| 2075
| 081B
| Hi Tension Computer Services Ltd. (UK)
|-
| 2076
| 081C
| Alfa Data
| Originally assigned to Elmtech Research, Ltd. (UK)
|-
| 2077
| 081D
| Great Valley Products
| Originally registered to Clartscreen, Ltd. (UK)
|-
| 2078
| 081E
| Interworks
|-
| 2079
| 081F
| Galysh Enterprises
|-
| 2080
| 0820
| Hardital Synthesis
| Originally registered to Realtime Games Software Ltd.
|-
| 2081
| 0821
| GBS
|-
| 2082
| 0822
| Circum Design Inc.
|-
| 2083
| 0823
| Alberta Micro Electronic Center
|-
| 2084
| 0824
| Bestech
|-
| 2085
| 0825
| Lasar Fantasy
|-
| 2086
| 0826
| Pulsar
|-
| 2087
| 0827
| Ivis
|-
| 2088
| 0828
| Applied Engineering
|-
| 2089
| 0829
| Solid-State Design & Development
|-
| 2090
| 082A
| Vison Quest
|-
| 2091
| 082B
| Seaview Software
|-
| 2092
| 082C
| BSC
| Mistakenly used by ADS (Advanced Development Software)
|-
| 2093
| 082D
| Bernd Culenfeld
|-
| 2094
| 082E
| American Liquid Light
|-
| 2095
| 082F
| CEGITES
|-
| 2096
| 0830
| Quadlite Computers Ltd.
| Originally registered to EV Industries
|-
| 2097
| 0831
| Silicon Peace
|-
| 2098
| 0832
| Black Belt Systems
|-
| 2099
| 0833
| Village Tronic
| Originally registerd to Steve Yaeger
|-
| 2100
| 0834
| ReadySoft
|-
| 2101
| 0835
| Phoenix Micro Technologies
|-
| 2102
| 0836
| Advanced Systems & Software
| Orignally assigned to Preferred Technology
|-
| 2103
| 0837
| Rombo Productions
|-
| 2104
| 0838
| Impulse Inc.
|-
| 2105
| 0839
| Beta Unlimited
|-
| 2106
| 083A
| Memory Expansion System, Ltd.
|-
| 2107
| 083B
| Vortex Computer Systems GmbH
|-
| 2108
| 083C
| Platypus Systems
|-
| 2109
| 083D
| Gigatron OHG
|-
| 2110
| 083E
| PG Electronics
|-
| 2111
| 083F
| New Technologies Group
|-
| 2112
| 0840
| Interactive Video Systems (IVS)
| Pacific Peripherals
|-
| 2113
| 0841
| Vector
| Originally registered to H. K. Computer
|-
| 2114
| 0842
| Pacific Digital
| Originally registered to C. H. Helfrich Elektronik
|-
| 2115
| 0843
| Xanadu
|-
| 2116
| 0844
| Pacific Digital
| Originally registered to AMS
|-
| 2117
| 0845
| X-Pert
|-
| 2118
| 0846
| The Amiga Centre
|-
| 2119
| 0847
| Digital Pacific
|-
| 2120
| 0848
| Solid State Leisure
|-
| 2121
| 0849
| Hydra Systems
| Originally registered to Analog Electronics
|-
| 2122
| 084A
| Cumana
|-
| 2123
| 084B
| KAPS 2C Conception
|-
| 2124
| 084C
| Mike Mason
|-
| 2125
| 084D
| For Your Eyes
|-
| 2126
| 084E
| Volkmar Breitfeld Computersysteme
|-
| 2127
| 084F
| Sunrize Industries
|-
| 2128
| 0850
| Scott Advanced Micro Designs
|-
| 2129
| 0851
| Digital Micronics
|-
| 2130
| 0852
| Alfa-Laval
|-
| 2131
| 0853
| Multigros A/S
|-
| 2132
| 0854
| Archos
|-
| 2133
| 0855
| Icom Simulations
|-
| 2134
| 0856
| Commodore Test Engineering Group
|-
| 2135
| 0857
| Microcreations
|-
| 2136
| 0858
| Shoestring Productions
|-
| 2137
| 0859
| Faberushi
|-
| 2138
| 085A
| Evesham Micro Ltd.
|-
| 2139
| 085B
| Panagolin Laser Software
|-
| 2140
| 085C
| Thomas Rudloff
|-
| 2141
| 085D
| Daniel Hohabir
|-
| 2142
| 085E
| GfxBase, Inc.
|-
| 2143
| 085F
| Axellabs
|-
| 2144
| 0860
| Roctec Electronics Inc.
|-
| 2145
| 0861
| Omega Datentechnik
|-
| 2146
| 0862
| Atlantis
|-
| 2147
| 0863
| Skytec Computers
|-
| 2148
| 0864
| Protar Electronics
|-
| 2149
| 0865
| ACS
|-
| 2150
| 0866
| Software Results Enterprises
| Originally registered to University of Illinois
|-
| 2151
| 0867
| Infinity Systems Design Group
|-
| 2152
| 0868
| Trade It
|-
| 2153
| 0869
| Suntec, Inc.
|-
| 2154
| 086A
| DJW Micro Systems
| Originally registered to Tritec Marketing
|-
| 2155
| 086B
| Power Computing Ltd.
|-
| 2156
| 086C
| MacroSystems
|-
| 2157
| 086D
| Masoboshi GmbH (DCE)
|-
| 2158
| 086E
| HAL Software Hardware Handel
|-
| 2159
| 086F
| Mainhattan Data
| Originally registered to Michael Lamm Computersysteme
|-
| 2160
| 0870
| Digital Processing System
| Originally registered to bbdp Electronics
|-
| 2161
| 0871
| Blue Ribbon Soundworks
| Originally registered to Design Computer Systems
|-
| 2162
| 0872
| XPert
| Originally registered to The Station
|-
| 2163
| 0873
| DelaComp
| Originally registered to Bryan Williams
|-
| 2164
| 0874
| Superformance Computer Engineering GmbH
|-
| 2165
| 0875
| Overland Engineering
|-
| 2166
| 0876
| Thomas Hamren
|-
| 2167
| 0877
| Village Tronic
|-
| 2168
| 0878
| Toolbox Design
|-
| 2169
| 0879
| Digital Processing System
|-
| 2170
| 087A
| Superformance
|-
| 2171
| 087B
| Utilities Unlimited
|-
| 2172
| 087C
| phase 5
|-
| 2173
| 087D
| Juergen Kommos
|-
| 2174
| 087E
| Electronic Design
|-
| 2175
| 087F
| James Cook University of North Queensland
|-
| 2176
| 0880
| AmiTrix Development
|-
| 2177
| 0881
| Ferranti
|-
| 2178
| 0882
| Leviathan Development
|-
| 2179
| 0883
| United Video Inc.
|-
| 2180
| 0884
| GPSoft Pty. Ltd.
| Originally registered to Juergen Kommos
|-
| 2181
| 0885
| ArMAX
| Oliver Bausch
|-
| 2182
| 0886
| CP Computer
|-
| 2183
| 0887
| AMOK - Amiga Module & Oberon Klub
|-
| 2184
| 0888
| ITEK Neser & Sieber GbR
|-
| 2185
| 0889
| Phillip C. Lello
|-
| 2186
| 088A
| Cyborg Design Services
|-
| 2187
| 088B
| G2 Systems
|-
| 2188
| 088C
| Pro System Computersysteme
|-
| 2189
| 088D
| ZEUS Electronic
| Originally registered to MSPI (Markt & Technik)
|-
| 2190
| 088E
| Altatech
|-
| 2191
| 088F
| NewTek
|-
| 2192
| 0890
| M-TEC Hardware Design
| Originally registered to Hardware Design Udo Neuroth
|-
| 2193
| 0891
| Great Valley Products
| Originally registered to Viona Development
|-
| 2194
| 0892
| Amitek
| Originally assigned to Marpet Developments
|-
| 2195
| 0893
| Ingenieurbuero Helfrich
|-
| 2196
| 0894
| The Neo Group
|-
| 2197
| 0895
| Cyon
|-
| 2198
| 0896
| Bob Research Group
|-
| 2199
| 0897
| Richmond Sound Design Ltd.
|-
| 2200
| 0898
| US Cybernetics
|-
| 2201
| 0899
| Fulvio Ieva
|-
| 2202
| 089A
| Silicon Studio
|-
| 2203
| 089B
| MacroSystems (USA)
| Was named Micro System Devices
|-
| 2204
| 089C
| Conspector Entertainment
|-
| 2205
| 089D
| Laserforum
|-
| 2206
| 089E
| Elbox Computer
| Mistakenly used by Index Information Ltd.
|-
| 2207
| 089F
| Applied Magic Inc.
|-
| 2208
| 08A0
| SDL Ltd.
|-
| 2560
| 0A00
| Harms
|-
| 2588
| 0A1C
| A1K.org Community
|-
| 2640
| 0A50
| Micronik
|-
| 3084
| 0C0C
| Team 4
|-
| 3643
| 0E3B
| E3B
| Michael Boehmer
|-
| 3855
| 0F0F
| Micronik
|-
| 4096
| 1000
| MegaMicro
|-
| 4110
| 100E
| DigiFeX
|-
| 4136
| 1028
| Imtronics/Memphis
|-
| 4149
| 1035
| PROTAR
|-
| 4369
| 1111
| Frank Strauß Elektronik
| Also used by Kupke
|-
| 4626
| 1212
| Individual Computers
|-
| 4648
| 1228
| Flesch Hornemann Computer Elec.
|-
| 4680
| 1248
| Kupke Computertechnik GmbH
|-
| 4711
| 1267
| RBM digitaltechnik
|-
| 4754
| 1292
| MacroSystems
|-
| 5000
| 1388
| ITH
|-
| 5001
| 1389
| VMC
|-
| 5010
| 1392
| Ambience Creation Technology
|-
| 5011
| 1393
| Creative Development
|-
| 5012
| 1394
| Georg Braun
|-
| 5013
| 1395
| Swedish User Group of Amiga
|-
| 5014
| 1396
| Jakub Bednarski
|-
| 5015
| 1397
| KryoFlux, Ltd.
|-
| 5016
| 1398
| Igor Majstorovic
|-
| 5017
| 1399
| Alastair M. Robinson
|-
| 5018
| 139A
| Austex Software
|-
| 5019
| 139B
| Sören Gust
|-
| 5020
| 139C
| Rok Krajnc
|-
| 5030
| 13A6
| Tim Tashpulatov
|-
| 5040
| 13B0
| 7-bit
|-
| 5050
| 13BA
| Sakura IT
|-
| 5060
| 13C4
| FPGAArcade
|-
| 5070
| 13CE
| CancerSoft Inc.
|-
| 5080
| 13D8
| Stephen Leary
|-
| 5090
| 13E2
| DMA Softlab LLC
|-
| 5100
| 13EC
| Brookhouse Engineering
|-
| 5110
| 13F6
| Eduardo Arana
|-
| 5120
| 1400
| CS-LAB
|-
| 5130
| 140A
| Robert Miranda
|-
| 5132
| 140C
| UAS Interface Ltd.
|-
| 5500
| 157C
| Inhouse Information
|-
| 5768
| 1688
| Bio Con
|-
| 6148
| 1804
| HK-Computer
|-
| 6502
| 1966
| Cloanto
|-
| 7777
| 1E61
| Rafal Gabriel Chyla
|-
| 8215
| 2017
| Vortex
|-
| 8244
| 2034
| Spirit Technology
|-
| 8290
| 2062
| Expansion Systems
|-
| 8448
| 2100
| ReadySoft
|-
| 8512
| 2140
| Phase 5 Digital Products
|-
| 8553
| 2169
| Digital Processing Systems Inc.
|-
| 8704
| 2200
| ACT Elektronik
|-
| 8738
| 2222
| ACT Elektronik
|-
| 9512
| 2528
| Tower Technologies
|-
| 10676
| 29B4
| Electronic Design
|-
| 14195
| 3773
| Media-net-Point
|-
| 14501
| 38A5
| Petsoff, Finland
|-
| 16375
| 3FF7
| Uwe Gerlach
|-
| 16707
| 4143
| Ateo Concepts
|-
| 16708
| 4144
| ALiENDESiGN
|-
| 16945
| 4231
| A.C.T.
|-
| 17740
| 454C
| HK-Computer (ELSAT)
|-
| 18260
| 4754
| MacroSystems (Germany)
|-
| 19796
| 4D54
| Markt & Technik
|-
| 22359
| 5757
| Markt & Technik
|-
| 26464
| 6760
| Combitec
|-
| 26470
| 6766
| Combitec
|-
| 28014
| 6D6E
| MNT Media and Technology UG
|-
| 32768
| 8000
| M.A.S.T.
|-
| 42240
| A500
| Aethreum Digital
|-
| 43437
| A9AD
| Reis-Ware
|-
| 43521
| AA01
| Cameron
|-
| 43537
| AA11
| Reis-Ware
|-
| 44359
| AD47
| Matay
|-
| 46504
| B5A8
| Phoenix
|-
| 49160
| C008
| Combitec
|-
| 61453
| F00D
| Forefront Technologies Inc.
|}

For any changes/additions to this registry please use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Amiga Hardware Manufacturer ID Registry

2018-04-27T03:52:08Z

Steven Solie: /* Registry */

__TOC__

= How to Obtain a Manufacturer Number =

Manufacturer's numbers are assigned by the AmigaOS development team. To obtain your unique manufacturer number use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Be sure and include your name, email and the type of expansion product you are developing.

= Your Manufacturer Number =

Attention hardware manufacturers. If you are developing a hardware expansion product for the Classic Amiga (e.g. 500, 2000, 3000) then you will need to obtain a special manufacturer ID number from the AmigaOS development team to identify your product. This manufacturer number is used by the Amiga to link your hardware with its driver software at boot time.

Your manufacturer number is part of the special protocol that the Amiga uses to automatically configure all expansion devices on the bus without the user having to cut jumpers or adjust dip switches. This is called auto-config.

At start-up time, the system first polls each board in the system and assigns the board its own address space. If it is a memory board, its RAM is linked into the memory free pool. Later in the boot sequence, after DOS is initialized, the binddrivers program is run. Binddrivers will search the directory SYS:Expansion for the drivers that go with the boards.

To do this binddrivers looks in the Tool Type field of all icon files in SYS:Expansion. If the first seven bytes of the Tool Type field are "PRODUCT", then this is an icon file for a driver.

Binddrivers will then attempt to match the drivers it has found with the boards that were found earlier. This is where your manufacturer number comes in.

Your manufacturer number goes in two places. First, it is burned in hex form into the PAL which is part of ALL auto-config expansion products. Second, it appears in ASCII in the Tool Type field of the icon file for your product's driver. By matching these two numbers, the Amiga can automatically configure your board and bind it's software driver into the system as well.

The manufacturer's number is a 16-bit ID which appears in PAL offsets $10-$17. There is also an 8-bit product number which you assign. The product number is for uniquely identifying different products from the same vendor. The product number will appear in PAL offsets $04-$07. This gives you a total of 24 bits to identify each of your products.

These 24 bits of information in the PAL which identify your product are matched against the information in the Tool Type field of all icon files in the SYS:Expansion drawer. For example, suppose you are manufacturer #1019. You have two products, #1 and #2 which both use the same driver. The icon for your driver for these two products would have a Tool Type set to "PRODUCT=1019/1|1019/2". This means: I am an icon for a driver that works with product number 1 or 2 from manufacturer 1019, now bind me. Spaces are not legal. Here are two other examples:

; PRODUCT=1208/11
: is the Tool Type for a driver for product 11 from manufacturer number 1208.

; PRODUCT=1017
: is the Tool Type for a driver for any product from manufacturer number 1017.

For an informal explanation of the auto-configuration process, see the chapter on Software Expansion Architecture from the 2nd Annual Amiga Developer's Conference Notes (available on ADCD 2.1). For the details of timing, power, the PAL equations and PAL address specifications and the expansion library documentation, see sections 3.1 to 3.3 of the A500/A2000 Technical Reference Manual. The original auto-config spec appears in the A1000 Schematics and Expansion Specification.

The auto-config process makes the addition of expansion products to the system very easy. All the user has to do is put the board in any slot and copy the driver from the release disk to his own SYS:Expansion drawer. Everything else is automatic. There are no jumpers or dip switches to set. Best of all, you will get a lot less support calls asking how to make your product work with the XYZ-Corp-battery-backed-clock.

= Notes =

Some notes on hardware manufacturer ID assignment.

* Manufacturer ID numbers are assigned free of charge.
* Please provide the following information when requesting an ID:
*# Name of the company or person
*# Postal address/contact address
*# Name of the contact person, with a corresponding e-mail address
*# A brief description of the kind of products you want to produce
* All ID numbers smaller than 5000 must be considered unsafe because no information exists on which numbers exactly were taken during the time Commodore, Inc. disintegrated.
* ID numbers in the range 8192 to 18841 must be considered unsafe because some hardware developers mistook the numbers assigned to them to be given in hexadecimal format. Hence 0x2000 = 8192 and 0x4999 = 18841.

= Example code =

<syntaxhighlight>
/*-----------------------------------------------*/
/* Here is a short program which will tell you */
/* about the expansion boards configured in your */
/* system without you opening up the machine. */
/* Code by Bill Koester of CATS */
/*-----------------------------------------------*/
#include <libraries/configvars.h>
#include <libraries/expansion.h>

struct ExpansionBase *ExpansionBase;

void cleanup();
void printdev();

int main()
{
struct ConfigDev *MyConfigDev;

/*----------------------------------*/
/* Open the expansion library, */
/* if there is a problem then exit */
/*----------------------------------*/

ExpansionBase =(struct ExpansionBase *) OpenLibrary(EXPANSIONNAME,0);
if(ExpansionBase==NULL)
{
printf("Error opening expansion library!!\n");
cleanup();
exit(0);
}

/*--------------------------------------------*/
/* Use FindConfigDev to get info on the first */
/* expansion board on the list maintained by */
/* Exec. If there are no expansion boards in */
/* the system then exit. */
/*--------------------------------------------*/

MyConfigDev = NULL;

/*--------------------------------------------------*/
/* FindConfigDev(oldConfigDev,manufacturer,product) */
/* oldConfigDev = NULL for the top of the list */
/* manufacturer = -1 for any manufacturer */
/* product = -1 for any product */
/*--------------------------------------------------*/

MyConfigDev = FindConfigDev(NULL,-1,-1);

if(MyConfigDev==NULL)
{
printf("No Configured Devices found!!\n");
cleanup();
exit(0);
}

printdev(MyConfigDev);

/*-----------------------------------*/
/* OK, there is at least one board, */
/* so loop and get the entire list */
/* printing as we go with printdev() */
/*-----------------------------------*/

while(MyConfigDev = FindConfigDev(MyConfigDev,-1,-1))
{
printdev(MyConfigDev);
}
cleanup();
return 0;
}

/*-------------------*/
/* Close up shop... */
/*-------------------*/
void cleanup()
{
if(ExpansionBase)
CloseLibrary(ExpansionBase);
}

/*----------------------------------*/
/* Print out the contents of the */
/* dev structure for this expansion */
/* product. */
/*----------------------------------*/

void printdev(dev)
struct ConfigDev *dev;
{
char buff[200];

printf("Flags = ");
if(dev->cd_Flags==NULL)
printf("NULL ");
if(dev->cd_Flags&CDF_SHUTUP)
printf("CDF_SHUTUP ");
if(dev->cd_Flags&CDF_CONFIGME)
printf("CDF_CONFIGME ");
printf("\n");
printf("Board Address = %x\n",dev->cd_BoardAddr);
printf("Board Size = %d bytes\n",dev->cd_BoardSize);
printf("Slot Address = %d\n",dev->cd_SlotAddr);
printf("Slot Size = %d\n",dev->cd_SlotSize);
printf("Driver code at %x\n",dev->cd_Driver);

printf("er_Type = %x\n",dev->cd_Rom.er_Type);
printf("er_Product = %x\n",dev->cd_Rom.er_Product);
printf("er_Flags = %x\n",dev->cd_Rom.er_Flags);
printf("er_Reserved03 = %x\n",dev->cd_Rom.er_Reserved03);
printf("er_Manufacturer = %x\n",dev->cd_Rom.er_Manufacturer);
printf("er_SerialNumber = %x\n",dev->cd_Rom.er_SerialNumber);
printf("er_InitDiagVec = %x\n",dev->cd_Rom.er_InitDiagVec);
printf("er_Reserved0c = %x\n",dev->cd_Rom.er_Reserved0c);
printf("er_Reserved0d = %x\n",dev->cd_Rom.er_Reserved0d);
printf("er_Reserved0e = %x\n",dev->cd_Rom.er_Reserved0e);
printf("er_Reserved0f = %x\n",dev->cd_Rom.er_Reserved0f);

printf("Hit Return to continue:\n");
gets(buff);
}
</syntaxhighlight>

= Registry =

{| class="wikitable"
! ID (decimal)
! ID (hexadecimal)
! Manufacturer
! Notes
|-
| 1
| 0001
| Micronik
|-
| 211
| 00D3
| Pacific Peripherals/Profex
|-
| 221
| 00DD
| Kupke Computertechnik GmbH
|-
| 256
| 0100
| Memphis
| Originally registered to MacroSystems US
|-
| 512
| 0200
| 3-State Computertechnik
|-
| 513
| 0201
| Commodore (Braunschweig)
|-
| 514
| 0202
| Commodore (West Chester)
|-
| 515
| 0203
| Commodore (West Chester)
| Originally registered to Combitech/Macrosystem
|-
| 756
| 02F4
| Progressive Peripherals & Software
|-
| 767
| 02FF
| Kolff Computer Supplies
|-
| 1001
| 03E9
| Tecmar
|-
| 1002
| 03EA
| Telesys
|-
| 1003
| 03EB
| The Micro-Forge
|-
| 1004
| 03EC
| Kronos/C Ltd.
| Originally registered to Card Co. (Supra)
|-
| 1005
| 03ED
| A-Squared
|-
| 1006
| 03EE
| Comspec Communications
|-
| 1007
| 03EF
| HT Electronics
|-
| 1008
| 03F0
| RDS Software
|-
| 1009
| 03F1
| Anakin Research
|-
| 1010
| 03F2
| MicroBotics
|-
| 1011
| 03F3
| Bob Krauth
|-
| 1012
| 03F4
| Access Associates (Alegra)
|-
| 1013
| 03F5
| Mini Comp Systems Ltd.
|-
| 1014
| 03F6
| Cypress Technology
|-
| 1015
| 03F7
| Fuller Computers
|-
| 1016
| 03F8
| Galaxy Computers
|-
| 1017
| 03F9
| ADA Research
|-
| 1018
| 03FA
| Computer Service Italia
|-
| 1019
| 03FB
| Amigo
|-
| 1020
| 03FC
| Micro-Solutions Inc.
|-
| 1021
| 03FD
| Stacar International
|-
| 1022
| 03FE
| Video Precisions
|-
| 1023
| 03FF
| ASDG, Inc.
|-
| 1025
| 0401
| Ing. Buero Kalawsky
|-
| 1026
| 0402
| Computer Tuning
|-
| 1027
| 0403
| Interplan Unternehmensberatung
|-
| 1028
| 0404
| Imtronics/Memphis
| Originally registered to Peter Ohlich
|-
| 1030
| 0406
| Commodore (Lowell University)
| Originally registered to Productivity Center
|-
| 1041
| 0411
| Design Labs
|-
| 1042
| 0412
| MCS
|-
| 1043
| 0413
| B. J. Freeman
|-
| 1044
| 0414
| Side Effects Inc.
|-
| 1045
| 0415
| Oklahoma Personal Comp.
|-
| 1046
| 0416
| Advanced Micro Innovations
|-
| 1047
| 0417
| Industrial Support Services
|-
| 1048
| 0418
| Technisoft
|-
| 1049
| 0419
| Prolific, Inc.
|-
| 1050
| 041A
| Softeam, Inc.
|-
| 1051
| 041B
| GRC Electronics
|-
| 1052
| 041C
| David Lai
|-
| 1053
| 041D
| Ameristar Technologies
|-
| 1054
| 041E
| Cline Refrigeration
|-
| 1055
| 041F
| Cardiac Pacemakers, Inc.
|-
| 1056
| 0420
| Supra Corp. (Creative Microsystems)
|-
| 1057
| 0421
| Wayne Diener
|-
| 1058
| 0422
| Computer Systems Associates (CSA)
|-
| 1059
| 0423
| Trionix, Inc.
|-
| 1060
| 0424
| David Lucas
|-
| 1061
| 0425
| Analog Precision
| Also assigned to D & L Distributing
|-
| 1267
| 04F3
| RBM Digitaltechnik
|-
| 1282
| 0502
| M-TEC Hardware Design
|-
| 1337
| 0539
| Thomas Stenzel (DaFR34K)
|-
| 1576
| 0628
| Boris Križma
|-
| 1761
| 06E1
| Great Valley Products
|-
| 1803
| 070B
| UAE Amiga Emulator
|-
| 2002
| 07D2
| Mimetics Corp.
|-
| 2003
| 07D3
| ACDA
|-
| 2004
| 07D4
| Finn R. Jacobsen
|-
| 2005
| 07D5
| Elthen Electronics
|-
| 2006
| 07D6
| Nine Tiles Computer Systems Ltd.
|-
| 2007
| 07D7
| Analog Electronics
|-
| 2008
| 07D8
| Bell & Howell
|-
| 2009
| 07D9
| Roland Kochler
|-
| 2010
| 07DA
| Byte Corp.
|-
| 2011
| 07DB
| Reserved
|-
| 2012
| 07DC
| DKB, Inc.
| Previously named Michigan Software
|-
| 2013
| 07DD
| Pacific Peripherals
|-
| 2014
| 07DE
| Sysaphus Software
|-
| 2015
| 07DF
| Digitronics
|-
| 2016
| 07E0
| Akron Systems
|-
| 2017
| 07E1
| Great Valley Products
|-
| 2018
| 07E2
| Calmos
|-
| 2019
| 07E3
| Dover Research
|-
| 2020
| 07E4
| David Krehbiel
|-
| 2021
| 07E5
| Synergy Peripheral Systems
| Also known as California Access
|-
| 2022
| 07E6
| Xetec
|-
| 2023
| 07E7
| Micron Technology
|-
| 2024
| 07E8
| CH Electronics
|-
| 2025
| 07E9
| American Liquid Light
|-
| 2026
| 07EA
| Progressive Peripherals & Software
| Also used by Ateo
|-
| 2027
| 07EB
| Wicat Systems
|-
| 2028
| 07EC
| Applied Systems & Peripherals
|-
| 2029
| 07ED
| Delaware Valley Software
|-
| 2030
| 07EE
| Palomax
|-
| 2031
| 07EF
| Incognito Software
|-
| 2032
| 07F0
| Jadesign
|-
| 2033
| 07F1
| BVR
|-
| 2034
| 07F2
| Spirit Technology
|-
| 2035
| 07F3
| Spirit Technology
|-
| 2036
| 07F4
| Atronic
|-
| 2037
| 07F5
| Scott Karlin
|-
| 2038
| 07F6
| Howitch
|-
| 2039
| 07F7
| Sullivan Brothers Visual Engineers
|-
| 2040
| 07F8
| G I T
|-
| 2041
| 07F9
| Amigo Business Computers
|-
| 2042
| 07FA
| Micro E Ab
|-
| 2043
| 07FB
| Ralph Kruse
|-
| 2044
| 07FC
| Clearpoint Research
|-
| 2045
| 07FD
| Kodiak
|-
| 2046
| 07FE
| BSC
| Originally registered to Phoenix Electronics
|-
| 2047
| 07FF
| No Name Shown
|-
| 2048
| 0800
| Commodore Braunschweig
|-
| 2049
| 0801
| BSC
| Originally registered to Elaborate Bytes
|-
| 2050
| 0802
| Kronos/C Ltd.
|-
| 2051
| 0803
| Spartanics
|-
| 2052
| 0804
| Jochheim Computer Tuning
|-
| 2053
| 0805
| Trans Data Systems
|-
| 2054
| 0806
| Applied Systems & Peripherals Ltd.
|-
| 2055
| 0807
| Checkpoint Technologies
| Originally registered to Amiga Solutions
|-
| 2056
| 0808
| Adept Development
|-
| 2057
| 0809
| Advanced Computer Design
|-
| 2058
| 080A
| Sir Netics
|-
| 2059
| 080B
| Expert Services
|-
| 2060
| 080C
| Digital Art Systems
|-
| 2061
| 080D
| Adept Development
|-
| 2062
| 080E
| Expansion Technologies (Expansion Systems)
|-
| 2063
| 080F
| Alphatech
|-
| 2064
| 0810
| Edotronik GmbH
|-
| 2065
| 0811
| California Access/Synergy
| Originally registered to Logical Design Works
|-
| 2066
| 0812
| Bowden, Williams, Full & Assoc.
|-
| 2067
| 0813
| NES, Inc.
|-
| 2068
| 0814
| Amdev
|-
| 2069
| 0815
| Big Brother Security Systems
|-
| 2070
| 0816
| Active Circuits Inc.
|-
| 2071
| 0817
| ICD, Inc.
|-
| 2072
| 0818
| Multi-Meg Electronique
|-
| 2073
| 0819
| Kupke Computertechnik GmbH
|-
| 2074
| 081A
| The Checkered Ball
|-
| 2075
| 081B
| Hi Tension Computer Services Ltd. (UK)
|-
| 2076
| 081C
| Alfa Data
| Originally assigned to Elmtech Research, Ltd. (UK)
|-
| 2077
| 081D
| Great Valley Products
| Originally registered to Clartscreen, Ltd. (UK)
|-
| 2078
| 081E
| Interworks
|-
| 2079
| 081F
| Galysh Enterprises
|-
| 2080
| 0820
| Hardital Synthesis
| Originally registered to Realtime Games Software Ltd.
|-
| 2081
| 0821
| GBS
|-
| 2082
| 0822
| Circum Design Inc.
|-
| 2083
| 0823
| Alberta Micro Electronic Center
|-
| 2084
| 0824
| Bestech
|-
| 2085
| 0825
| Lasar Fantasy
|-
| 2086
| 0826
| Pulsar
|-
| 2087
| 0827
| Ivis
|-
| 2088
| 0828
| Applied Engineering
|-
| 2089
| 0829
| Solid-State Design & Development
|-
| 2090
| 082A
| Vison Quest
|-
| 2091
| 082B
| Seaview Software
|-
| 2092
| 082C
| BSC
| Mistakenly used by ADS (Advanced Development Software)
|-
| 2093
| 082D
| Bernd Culenfeld
|-
| 2094
| 082E
| American Liquid Light
|-
| 2095
| 082F
| CEGITES
|-
| 2096
| 0830
| Quadlite Computers Ltd.
| Originally registered to EV Industries
|-
| 2097
| 0831
| Silicon Peace
|-
| 2098
| 0832
| Black Belt Systems
|-
| 2099
| 0833
| Village Tronic
| Originally registerd to Steve Yaeger
|-
| 2100
| 0834
| ReadySoft
|-
| 2101
| 0835
| Phoenix Micro Technologies
|-
| 2102
| 0836
| Advanced Systems & Software
| Orignally assigned to Preferred Technology
|-
| 2103
| 0837
| Rombo Productions
|-
| 2104
| 0838
| Impulse Inc.
|-
| 2105
| 0839
| Beta Unlimited
|-
| 2106
| 083A
| Memory Expansion System, Ltd.
|-
| 2107
| 083B
| Vortex Computer Systems GmbH
|-
| 2108
| 083C
| Platypus Systems
|-
| 2109
| 083D
| Gigatron OHG
|-
| 2110
| 083E
| PG Electronics
|-
| 2111
| 083F
| New Technologies Group
|-
| 2112
| 0840
| Interactive Video Systems (IVS)
| Pacific Peripherals
|-
| 2113
| 0841
| Vector
| Originally registered to H. K. Computer
|-
| 2114
| 0842
| Pacific Digital
| Originally registered to C. H. Helfrich Elektronik
|-
| 2115
| 0843
| Xanadu
|-
| 2116
| 0844
| Pacific Digital
| Originally registered to AMS
|-
| 2117
| 0845
| X-Pert
|-
| 2118
| 0846
| The Amiga Centre
|-
| 2119
| 0847
| Digital Pacific
|-
| 2120
| 0848
| Solid State Leisure
|-
| 2121
| 0849
| Hydra Systems
| Originally registered to Analog Electronics
|-
| 2122
| 084A
| Cumana
|-
| 2123
| 084B
| KAPS 2C Conception
|-
| 2124
| 084C
| Mike Mason
|-
| 2125
| 084D
| For Your Eyes
|-
| 2126
| 084E
| Volkmar Breitfeld Computersysteme
|-
| 2127
| 084F
| Sunrize Industries
|-
| 2128
| 0850
| Scott Advanced Micro Designs
|-
| 2129
| 0851
| Digital Micronics
|-
| 2130
| 0852
| Alfa-Laval
|-
| 2131
| 0853
| Multigros A/S
|-
| 2132
| 0854
| Archos
|-
| 2133
| 0855
| Icom Simulations
|-
| 2134
| 0856
| Commodore Test Engineering Group
|-
| 2135
| 0857
| Microcreations
|-
| 2136
| 0858
| Shoestring Productions
|-
| 2137
| 0859
| Faberushi
|-
| 2138
| 085A
| Evesham Micro Ltd.
|-
| 2139
| 085B
| Panagolin Laser Software
|-
| 2140
| 085C
| Thomas Rudloff
|-
| 2141
| 085D
| Daniel Hohabir
|-
| 2142
| 085E
| GfxBase, Inc.
|-
| 2143
| 085F
| Axellabs
|-
| 2144
| 0860
| Roctec Electronics Inc.
|-
| 2145
| 0861
| Omega Datentechnik
|-
| 2146
| 0862
| Atlantis
|-
| 2147
| 0863
| Skytec Computers
|-
| 2148
| 0864
| Protar Electronics
|-
| 2149
| 0865
| ACS
|-
| 2150
| 0866
| Software Results Enterprises
| Originally registered to University of Illinois
|-
| 2151
| 0867
| Infinity Systems Design Group
|-
| 2152
| 0868
| Trade It
|-
| 2153
| 0869
| Suntec, Inc.
|-
| 2154
| 086A
| DJW Micro Systems
| Originally registered to Tritec Marketing
|-
| 2155
| 086B
| Power Computing Ltd.
|-
| 2156
| 086C
| MacroSystems
|-
| 2157
| 086D
| Masoboshi GmbH (DCE)
|-
| 2158
| 086E
| HAL Software Hardware Handel
|-
| 2159
| 086F
| Mainhattan Data
| Originally registered to Michael Lamm Computersysteme
|-
| 2160
| 0870
| Digital Processing System
| Originally registered to bbdp Electronics
|-
| 2161
| 0871
| Blue Ribbon Soundworks
| Originally registered to Design Computer Systems
|-
| 2162
| 0872
| XPert
| Originally registered to The Station
|-
| 2163
| 0873
| DelaComp
| Originally registered to Bryan Williams
|-
| 2164
| 0874
| Superformance Computer Engineering GmbH
|-
| 2165
| 0875
| Overland Engineering
|-
| 2166
| 0876
| Thomas Hamren
|-
| 2167
| 0877
| Village Tronic
|-
| 2168
| 0878
| Toolbox Design
|-
| 2169
| 0879
| Digital Processing System
|-
| 2170
| 087A
| Superformance
|-
| 2171
| 087B
| Utilities Unlimited
|-
| 2172
| 087C
| phase 5
|-
| 2173
| 087D
| Juergen Kommos
|-
| 2174
| 087E
| Electronic Design
|-
| 2175
| 087F
| James Cook University of North Queensland
|-
| 2176
| 0880
| AmiTrix Development
|-
| 2177
| 0881
| Ferranti
|-
| 2178
| 0882
| Leviathan Development
|-
| 2179
| 0883
| United Video Inc.
|-
| 2180
| 0884
| GPSoft Pty. Ltd.
| Originally registered to Juergen Kommos
|-
| 2181
| 0885
| ArMAX
| Oliver Bausch
|-
| 2182
| 0886
| CP Computer
|-
| 2183
| 0887
| AMOK - Amiga Module & Oberon Klub
|-
| 2184
| 0888
| ITEK Neser & Sieber GbR
|-
| 2185
| 0889
| Phillip C. Lello
|-
| 2186
| 088A
| Cyborg Design Services
|-
| 2187
| 088B
| G2 Systems
|-
| 2188
| 088C
| Pro System Computersysteme
|-
| 2189
| 088D
| ZEUS Electronic
| Originally registered to MSPI (Markt & Technik)
|-
| 2190
| 088E
| Altatech
|-
| 2191
| 088F
| NewTek
|-
| 2192
| 0890
| M-TEC Hardware Design
| Originally registered to Hardware Design Udo Neuroth
|-
| 2193
| 0891
| Great Valley Products
| Originally registered to Viona Development
|-
| 2194
| 0892
| Amitek
| Originally assigned to Marpet Developments
|-
| 2195
| 0893
| Ingenieurbuero Helfrich
|-
| 2196
| 0894
| The Neo Group
|-
| 2197
| 0895
| Cyon
|-
| 2198
| 0896
| Bob Research Group
|-
| 2199
| 0897
| Richmond Sound Design Ltd.
|-
| 2200
| 0898
| US Cybernetics
|-
| 2201
| 0899
| Fulvio Ieva
|-
| 2202
| 089A
| Silicon Studio
|-
| 2203
| 089B
| MacroSystems (USA)
| Was named Micro System Devices
|-
| 2204
| 089C
| Conspector Entertainment
|-
| 2205
| 089D
| Laserforum
|-
| 2206
| 089E
| Elbox Computer
| Mistakenly used by Index Information Ltd.
|-
| 2207
| 089F
| Applied Magic Inc.
|-
| 2208
| 08A0
| SDL Ltd.
|-
| 2560
| 0A00
| Harms
|-
| 2588
| 0A1C
| A1K.org Community
|-
| 2640
| 0A50
| Micronik
|-
| 3084
| 0C0C
| Team 4
|-
| 3643
| 0E3B
| E3B
| Michael Boehmer
|-
| 3855
| 0F0F
| Micronik
|-
| 4096
| 1000
| MegaMicro
|-
| 4110
| 100E
| DigiFeX
|-
| 4136
| 1028
| Imtronics/Memphis
|-
| 4149
| 1035
| PROTAR
|-
| 4369
| 1111
| Frank Strauß Elektronik
| Also used by Kupke
|-
| 4626
| 1212
| Individual Computers
|-
| 4648
| 1228
| Flesch Hornemann Computer Elec.
|-
| 4680
| 1248
| Kupke Computertechnik GmbH
|-
| 4711
| 1267
| RBM digitaltechnik
|-
| 4754
| 1292
| MacroSystems
|-
| 5000
| 1388
| ITH
|-
| 5001
| 1389
| VMC
|-
| 5010
| 1392
| Ambience Creation Technology
|-
| 5011
| 1393
| Creative Development
|-
| 5012
| 1394
| Georg Braun
|-
| 5013
| 1395
| Swedish User Group of Amiga
|-
| 5014
| 1396
| Jakub Bednarski
|-
| 5015
| 1397
| KryoFlux, Ltd.
|-
| 5016
| 1398
| Igor Majstorovic
|-
| 5017
| 1399
| Alastair M. Robinson
|-
| 5018
| 139A
| Austex Software
|-
| 5019
| 139B
| Sören Gust
|-
| 5020
| 139C
| Rok Krajnc
|-
| 5030
| 13A6
| Tim Tashpulatov
|-
| 5040
| 13B0
| 7-bit
|-
| 5050
| 13BA
| Sakura IT
|-
| 5060
| 13C4
| FPGAArcade
|-
| 5070
| 13CE
| CancerSoft Inc.
|-
| 5080
| 13D8
| Stephen Leary
|-
| 5090
| 13E2
| DMA Softlab LLC
|-
| 5100
| 13EC
| Brookhouse Engineering
|-
| 5110
| 13F6
| Eduardo Arana
|-
| 5120
| 1400
| CS-LAB
|-
| 5130
| 140A
| Robert Miranda
|-
| 5132
| 140C
| UAS Interface Ltd.
|-
| 5500
| 157C
| Inhouse Information
|-
| 5768
| 1688
| Bio Con
|-
| 6148
| 1804
| HK-Computer
|-
| 6502
| 1966
| Cloanto
|-
| 7777
| 1E61
| Rafal Gabriel Chyla
|-
| 8215
| 2017
| Vortex
|-
| 8244
| 2034
| Spirit Technology
|-
| 8290
| 2062
| Expansion Systems
|-
| 8448
| 2100
| ReadySoft
|-
| 8512
| 2140
| Phase 5 Digital Products
|-
| 8553
| 2169
| Digital Processing Systems Inc.
|-
| 8704
| 2200
| ACT Elektronik
|-
| 8738
| 2222
| ACT Elektronik
|-
| 9512
| 2528
| Tower Technologies
|-
| 10676
| 29B4
| Electronic Design
|-
| 14195
| 3773
| Media-net-Point
|-
| 14501
| 38A5
| Petsoff, Finland
|-
| 16375
| 3FF7
| Uwe Gerlach
|-
| 16707
| 4143
| Ateo Concepts
|-
| 16708
| 4144
| ALiENDESiGN
|-
| 16945
| 4231
| A.C.T.
|-
| 17740
| 454C
| HK-Computer (ELSAT)
|-
| 18260
| 4754
| MacroSystems (Germany)
|-
| 19796
| 4D54
| Markt & Technik
|-
| 22359
| 5757
| Markt & Technik
|-
| 26464
| 6760
| Combitec
|-
| 26470
| 6766
| Combitec
|-
| 28014
| 6D6E
| MNT Media and Technology UG
|-
| 32768
| 8000
| M.A.S.T.
|-
| 43437
| A9AD
| Reis-Ware
|-
| 43521
| AA01
| Cameron
|-
| 43537
| AA11
| Reis-Ware
|-
| 44359
| AD47
| Matay
|-
| 46504
| B5A8
| Phoenix
|-
| 49160
| C008
| Combitec
|-
| 61453
| F00D
| Forefront Technologies Inc.
|}

For any changes/additions to this registry please use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Amiga Hardware Manufacturer ID Registry

2018-04-27T03:45:07Z

Steven Solie: /* Registry */

__TOC__

= How to Obtain a Manufacturer Number =

Manufacturer's numbers are assigned by the AmigaOS development team. To obtain your unique manufacturer number use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Be sure and include your name, email and the type of expansion product you are developing.

= Your Manufacturer Number =

Attention hardware manufacturers. If you are developing a hardware expansion product for the Classic Amiga (e.g. 500, 2000, 3000) then you will need to obtain a special manufacturer ID number from the AmigaOS development team to identify your product. This manufacturer number is used by the Amiga to link your hardware with its driver software at boot time.

Your manufacturer number is part of the special protocol that the Amiga uses to automatically configure all expansion devices on the bus without the user having to cut jumpers or adjust dip switches. This is called auto-config.

At start-up time, the system first polls each board in the system and assigns the board its own address space. If it is a memory board, its RAM is linked into the memory free pool. Later in the boot sequence, after DOS is initialized, the binddrivers program is run. Binddrivers will search the directory SYS:Expansion for the drivers that go with the boards.

To do this binddrivers looks in the Tool Type field of all icon files in SYS:Expansion. If the first seven bytes of the Tool Type field are "PRODUCT", then this is an icon file for a driver.

Binddrivers will then attempt to match the drivers it has found with the boards that were found earlier. This is where your manufacturer number comes in.

Your manufacturer number goes in two places. First, it is burned in hex form into the PAL which is part of ALL auto-config expansion products. Second, it appears in ASCII in the Tool Type field of the icon file for your product's driver. By matching these two numbers, the Amiga can automatically configure your board and bind it's software driver into the system as well.

The manufacturer's number is a 16-bit ID which appears in PAL offsets $10-$17. There is also an 8-bit product number which you assign. The product number is for uniquely identifying different products from the same vendor. The product number will appear in PAL offsets $04-$07. This gives you a total of 24 bits to identify each of your products.

These 24 bits of information in the PAL which identify your product are matched against the information in the Tool Type field of all icon files in the SYS:Expansion drawer. For example, suppose you are manufacturer #1019. You have two products, #1 and #2 which both use the same driver. The icon for your driver for these two products would have a Tool Type set to "PRODUCT=1019/1|1019/2". This means: I am an icon for a driver that works with product number 1 or 2 from manufacturer 1019, now bind me. Spaces are not legal. Here are two other examples:

; PRODUCT=1208/11
: is the Tool Type for a driver for product 11 from manufacturer number 1208.

; PRODUCT=1017
: is the Tool Type for a driver for any product from manufacturer number 1017.

For an informal explanation of the auto-configuration process, see the chapter on Software Expansion Architecture from the 2nd Annual Amiga Developer's Conference Notes (available on ADCD 2.1). For the details of timing, power, the PAL equations and PAL address specifications and the expansion library documentation, see sections 3.1 to 3.3 of the A500/A2000 Technical Reference Manual. The original auto-config spec appears in the A1000 Schematics and Expansion Specification.

The auto-config process makes the addition of expansion products to the system very easy. All the user has to do is put the board in any slot and copy the driver from the release disk to his own SYS:Expansion drawer. Everything else is automatic. There are no jumpers or dip switches to set. Best of all, you will get a lot less support calls asking how to make your product work with the XYZ-Corp-battery-backed-clock.

= Notes =

Some notes on hardware manufacturer ID assignment.

* Manufacturer ID numbers are assigned free of charge.
* Please provide the following information when requesting an ID:
*# Name of the company or person
*# Postal address/contact address
*# Name of the contact person, with a corresponding e-mail address
*# A brief description of the kind of products you want to produce
* All ID numbers smaller than 5000 must be considered unsafe because no information exists on which numbers exactly were taken during the time Commodore, Inc. disintegrated.
* ID numbers in the range 8192 to 18841 must be considered unsafe because some hardware developers mistook the numbers assigned to them to be given in hexadecimal format. Hence 0x2000 = 8192 and 0x4999 = 18841.

= Example code =

<syntaxhighlight>
/*-----------------------------------------------*/
/* Here is a short program which will tell you */
/* about the expansion boards configured in your */
/* system without you opening up the machine. */
/* Code by Bill Koester of CATS */
/*-----------------------------------------------*/
#include <libraries/configvars.h>
#include <libraries/expansion.h>

struct ExpansionBase *ExpansionBase;

void cleanup();
void printdev();

int main()
{
struct ConfigDev *MyConfigDev;

/*----------------------------------*/
/* Open the expansion library, */
/* if there is a problem then exit */
/*----------------------------------*/

ExpansionBase =(struct ExpansionBase *) OpenLibrary(EXPANSIONNAME,0);
if(ExpansionBase==NULL)
{
printf("Error opening expansion library!!\n");
cleanup();
exit(0);
}

/*--------------------------------------------*/
/* Use FindConfigDev to get info on the first */
/* expansion board on the list maintained by */
/* Exec. If there are no expansion boards in */
/* the system then exit. */
/*--------------------------------------------*/

MyConfigDev = NULL;

/*--------------------------------------------------*/
/* FindConfigDev(oldConfigDev,manufacturer,product) */
/* oldConfigDev = NULL for the top of the list */
/* manufacturer = -1 for any manufacturer */
/* product = -1 for any product */
/*--------------------------------------------------*/

MyConfigDev = FindConfigDev(NULL,-1,-1);

if(MyConfigDev==NULL)
{
printf("No Configured Devices found!!\n");
cleanup();
exit(0);
}

printdev(MyConfigDev);

/*-----------------------------------*/
/* OK, there is at least one board, */
/* so loop and get the entire list */
/* printing as we go with printdev() */
/*-----------------------------------*/

while(MyConfigDev = FindConfigDev(MyConfigDev,-1,-1))
{
printdev(MyConfigDev);
}
cleanup();
return 0;
}

/*-------------------*/
/* Close up shop... */
/*-------------------*/
void cleanup()
{
if(ExpansionBase)
CloseLibrary(ExpansionBase);
}

/*----------------------------------*/
/* Print out the contents of the */
/* dev structure for this expansion */
/* product. */
/*----------------------------------*/

void printdev(dev)
struct ConfigDev *dev;
{
char buff[200];

printf("Flags = ");
if(dev->cd_Flags==NULL)
printf("NULL ");
if(dev->cd_Flags&CDF_SHUTUP)
printf("CDF_SHUTUP ");
if(dev->cd_Flags&CDF_CONFIGME)
printf("CDF_CONFIGME ");
printf("\n");
printf("Board Address = %x\n",dev->cd_BoardAddr);
printf("Board Size = %d bytes\n",dev->cd_BoardSize);
printf("Slot Address = %d\n",dev->cd_SlotAddr);
printf("Slot Size = %d\n",dev->cd_SlotSize);
printf("Driver code at %x\n",dev->cd_Driver);

printf("er_Type = %x\n",dev->cd_Rom.er_Type);
printf("er_Product = %x\n",dev->cd_Rom.er_Product);
printf("er_Flags = %x\n",dev->cd_Rom.er_Flags);
printf("er_Reserved03 = %x\n",dev->cd_Rom.er_Reserved03);
printf("er_Manufacturer = %x\n",dev->cd_Rom.er_Manufacturer);
printf("er_SerialNumber = %x\n",dev->cd_Rom.er_SerialNumber);
printf("er_InitDiagVec = %x\n",dev->cd_Rom.er_InitDiagVec);
printf("er_Reserved0c = %x\n",dev->cd_Rom.er_Reserved0c);
printf("er_Reserved0d = %x\n",dev->cd_Rom.er_Reserved0d);
printf("er_Reserved0e = %x\n",dev->cd_Rom.er_Reserved0e);
printf("er_Reserved0f = %x\n",dev->cd_Rom.er_Reserved0f);

printf("Hit Return to continue:\n");
gets(buff);
}
</syntaxhighlight>

= Registry =

{| class="wikitable"
! ID (decimal)
! ID (hexadecimal)
! Manufacturer
! Notes
|-
| 1
| 0001
| Micronik
|-
| 211
| 00D3
| Pacific Peripherals/Profex
|-
| 221
| 00DD
| Kupke Computertechnik GmbH
|-
| 256
| 0100
| Memphis
| Originally registered to MacroSystems US
|-
| 512
| 0200
| 3-State Computertechnik
|-
| 513
| 0201
| Commodore (Braunschweig)
|-
| 514
| 0202
| Commodore (West Chester)
|-
| 515
| 0203
| Commodore (West Chester)
| Originally registered to Combitech/Macrosystem
|-
| 756
| 02F4
| Progressive Peripherals & Software
|-
| 767
| 02FF
| Kolff Computer Supplies
|-
| 1001
| 03E9
| Tecmar
|-
| 1002
| 03EA
| Telesys
|-
| 1003
| 03EB
| The Micro-Forge
|-
| 1004
| 03EC
| Kronos/C Ltd.
| Originally registered to Card Co. (Supra)
|-
| 1005
| 03ED
| A-Squared
|-
| 1006
| 03EE
| Comspec Communications
|-
| 1007
| 03EF
| HT Electronics
|-
| 1008
| 03F0
| RDS Software
|-
| 1009
| 03F1
| Anakin Research
|-
| 1010
| 03F2
| MicroBotics
|-
| 1011
| 03F3
| Bob Krauth
|-
| 1012
| 03F4
| Access Associates (Alegra)
|-
| 1013
| 03F5
| Mini Comp Systems Ltd.
|-
| 1014
| 03F6
| Cypress Technology
|-
| 1015
| 03F7
| Fuller Computers
|-
| 1016
| 03F8
| Galaxy Computers
|-
| 1017
| 03F9
| ADA Research
|-
| 1018
| 03FA
| Computer Service Italia
|-
| 1019
| 03FB
| Amigo
|-
| 1020
| 03FC
| Micro-Solutions Inc.
|-
| 1021
| 03FD
| Stacar International
|-
| 1022
| 03FE
| Video Precisions
|-
| 1023
| 03FF
| ASDG, Inc.
|-
| 1025
| 0401
| Ing. Buero Kalawsky
|-
| 1026
| 0402
| Computer Tuning
|-
| 1027
| 0403
| Interplan Unternehmensberatung
|-
| 1028
| 0404
| Imtronics/Memphis
| Originally registered to Peter Ohlich
|-
| 1030
| 0406
| Commodore (Lowell University)
| Originally registered to Productivity Center
|-
| 1041
| 0411
| Design Labs
|-
| 1042
| 0412
| MCS
|-
| 1043
| 0413
| B. J. Freeman
|-
| 1044
| 0414
| Side Effects Inc.
|-
| 1045
| 0415
| Oklahoma Personal Comp.
|-
| 1046
| 0416
| Advanced Micro Innovations
|-
| 1047
| 0417
| Industrial Support Services
|-
| 1048
| 0418
| Technisoft
|-
| 1049
| 0419
| Prolific, Inc.
|-
| 1050
| 041A
| Softeam, Inc.
|-
| 1051
| 041B
| GRC Electronics
|-
| 1052
| 041C
| David Lai
|-
| 1053
| 041D
| Ameristar Technologies
|-
| 1054
| 041E
| Cline Refrigeration
|-
| 1055
| 041F
| Cardiac Pacemakers, Inc.
|-
| 1056
| 0420
| Supra Corp. (Creative Microsystems)
|-
| 1057
| 0421
| Wayne Diener
|-
| 1058
| 0422
| Computer Systems Associates (CSA)
|-
| 1059
| 0423
| Trionix, Inc.
|-
| 1060
| 0424
| David Lucas
|-
| 1061
| 0425
| Analog Precision
| Also assigned to D & L Distributing
|-
| 1267
| 04F3
| RBM Digitaltechnik
|-
| 1282
| 0502
| M-TEC Hardware Design
|-
| 1337
| 0539
| Thomas Stenzel (DaFR34K)
|-
| 1576
| 0628
| Boris Križma
|-
| 1761
| 06E1
| Great Valley Products
|-
| 1803
| 070B
| UAE Amiga Emulator
|-
| 2002
| 07D2
| Mimetics Corp.
|-
| 2003
| 07D3
| ACDA
|-
| 2004
| 07D4
| Finn R. Jacobsen
|-
| 2005
| 07D5
| Elthen Electronics
|-
| 2006
| 07D6
| Nine Tiles Computer Systems Ltd.
|-
| 2007
| 07D7
| Analog Electronics
|-
| 2008
| 07D8
| Bell & Howell
|-
| 2009
| 07D9
| Roland Kochler
|-
| 2010
| 07DA
| Byte Corp.
|-
| 2011
| 07DB
| Reserved
|-
| 2012
| 07DC
| DKB, Inc.
| Previously named Michigan Software
|-
| 2013
| 07DD
| Pacific Peripherals
|-
| 2014
| 07DE
| Sysaphus Software
|-
| 2015
| 07DF
| Digitronics
|-
| 2016
| 07E0
| Akron Systems
|-
| 2017
| 07E1
| Great Valley Products
|-
| 2018
| 07E2
| Calmos
|-
| 2019
| 07E3
| Dover Research
|-
| 2020
| 07E4
| David Krehbiel
|-
| 2021
| 07E5
| Synergy Peripheral Systems
| Also known as California Access
|-
| 2022
| 07E6
| Xetec
|-
| 2023
| 07E7
| Micron Technology
|-
| 2024
| 07E8
| CH Electronics
|-
| 2025
| 07E9
| American Liquid Light
|-
| 2026
| 07EA
| Progressive Peripherals & Software
| Also used by Ateo
|-
| 2027
| 07EB
| Wicat Systems
|-
| 2028
| 07EC
| Applied Systems & Peripherals
|-
| 2029
| 07ED
| Delaware Valley Software
|-
| 2030
| 07EE
| Palomax
|-
| 2031
| 07EF
| Incognito Software
|-
| 2032
| 07F0
| Jadesign
|-
| 2033
| 07F1
| BVR
|-
| 2034
| 07F2
| Spirit Technology
|-
| 2035
| 07F3
| Spirit Technology
|-
| 2036
| 07F4
| Atronic
|-
| 2037
| 07F5
| Scott Karlin
|-
| 2038
| 07F6
| Howitch
|-
| 2039
| 07F7
| Sullivan Brothers Visual Engineers
|-
| 2040
| 07F8
| G I T
|-
| 2041
| 07F9
| Amigo Business Computers
|-
| 2042
| 07FA
| Micro E Ab
|-
| 2043
| 07FB
| Ralph Kruse
|-
| 2044
| 07FC
| Clearpoint Research
|-
| 2045
| 07FD
| Kodiak
|-
| 2046
| 07FE
| BSC
| Originally registered to Phoenix Electronics
|-
| 2047
| 07FF
| No Name Shown
|-
| 2048
| 0800
| Commodore Braunschweig
|-
| 2049
| 0801
| BSC
| Originally registered to Elaborate Bytes
|-
| 2050
| 0802
| Kronos/C Ltd.
|-
| 2051
| 0803
| Spartanics
|-
| 2052
| 0804
| Jochheim Computer Tuning
|-
| 2053
| 0805
| Trans Data Systems
|-
| 2054
| 0806
| Applied Systems & Peripherals Ltd.
|-
| 2055
| 0807
| Checkpoint Technologies
| Originally registered to Amiga Solutions
|-
| 2056
| 0808
| Adept Development
|-
| 2057
| 0809
| Advanced Computer Design
|-
| 2058
| 080A
| Sir Netics
|-
| 2059
| 080B
| Expert Services
|-
| 2060
| 080C
| Digital Art Systems
|-
| 2061
| 080D
| Adept Development
|-
| 2062
| 080E
| Expansion Technologies (Expansion Systems)
|-
| 2063
| 080F
| Alphatech
|-
| 2064
| 0810
| Edotronik GmbH
|-
| 2065
| 0811
| California Access/Synergy
| Originally registered to Logical Design Works
|-
| 2066
| 0812
| Bowden, Williams, Full & Assoc.
|-
| 2067
| 0813
| NES, Inc.
|-
| 2068
| 0814
| Amdev
|-
| 2069
| 0815
| Big Brother Security Systems
|-
| 2070
| 0816
| Active Circuits Inc.
|-
| 2071
| 0817
| ICD, Inc.
|-
| 2072
| 0818
| Multi-Meg Electronique
|-
| 2073
| 0819
| Kupke Computertechnik GmbH
|-
| 2074
| 081A
| The Checkered Ball
|-
| 2075
| 081B
| Hi Tension Computer Services Ltd. (UK)
|-
| 2076
| 081C
| Alfa Data
| Originally assigned to Elmtech Research, Ltd. (UK)
|-
| 2077
| 081D
| Great Valley Products
| Originally registered to Clartscreen, Ltd. (UK)
|-
| 2078
| 081E
| Interworks
|-
| 2079
| 081F
| Galysh Enterprises
|-
| 2080
| 0820
| Hardital Synthesis
| Originally registered to Realtime Games Software Ltd.
|-
| 2081
| 0821
| GBS
|-
| 2082
| 0822
| Circum Design Inc.
|-
| 2083
| 0823
| Alberta Micro Electronic Center
|-
| 2084
| 0824
| Bestech
|-
| 2085
| 0825
| Lasar Fantasy
|-
| 2086
| 0826
| Pulsar
|-
| 2087
| 0827
| Ivis
|-
| 2088
| 0828
| Applied Engineering
|-
| 2089
| 0829
| Solid-State Design & Development
|-
| 2090
| 082A
| Vison Quest
|-
| 2091
| 082B
| Seaview Software
|-
| 2092
| 082C
| BSC
| Mistakenly used by ADS (Advanced Development Software)
|-
| 2093
| 082D
| Bernd Culenfeld
|-
| 2094
| 082E
| American Liquid Light
|-
| 2095
| 082F
| CEGITES
|-
| 2096
| 0830
| Quadlite Computers Ltd.
| Originally registered to EV Industries
|-
| 2097
| 0831
| Silicon Peace
|-
| 2098
| 0832
| Black Belt Systems
|-
| 2099
| 0833
| Village Tronic
| Originally registerd to Steve Yaeger
|-
| 2100
| 0834
| ReadySoft
|-
| 2101
| 0835
| Phoenix Micro Technologies
|-
| 2102
| 0836
| Advanced Systems & Software
| Orignally assigned to Preferred Technology
|-
| 2103
| 0837
| Rombo Productions
|-
| 2104
| 0838
| Impulse Inc.
|-
| 2105
| 0839
| Beta Unlimited
|-
| 2106
| 083A
| Memory Expansion System, Ltd.
|-
| 2107
| 083B
| Vortex Computer Systems GmbH
|-
| 2108
| 083C
| Platypus Systems
|-
| 2109
| 083D
| Gigatron OHG
|-
| 2110
| 083E
| PG Electronics
|-
| 2111
| 083F
| New Technologies Group
|-
| 2112
| 0840
| Interactive Video Systems (IVS)
| Pacific Peripherals
|-
| 2113
| 0841
| Vector
| Originally registered to H. K. Computer
|-
| 2114
| 0842
| Pacific Digital
| Originally registered to C. H. Helfrich Elektronik
|-
| 2115
| 0843
| Xanadu
|-
| 2116
| 0844
| Pacific Digital
| Originally registered to AMS
|-
| 2117
| 0845
| X-Pert
|-
| 2118
| 0846
| The Amiga Centre
|-
| 2119
| 0847
| Digital Pacific
|-
| 2120
| 0848
| Solid State Leisure
|-
| 2121
| 0849
| Hydra Systems
| Originally registered to Analog Electronics
|-
| 2122
| 084A
| Cumana
|-
| 2123
| 084B
| KAPS 2C Conception
|-
| 2124
| 084C
| Mike Mason
|-
| 2125
| 084D
| For Your Eyes
|-
| 2126
| 084E
| Volkmar Breitfeld Computersysteme
|-
| 2127
| 084F
| Sunrize Industries
|-
| 2128
| 0850
| Scott Advanced Micro Designs
|-
| 2129
| 0851
| Digital Micronics
|-
| 2130
| 0852
| Alfa-Laval
|-
| 2131
| 0853
| Multigros A/S
|-
| 2132
| 0854
| Archos
|-
| 2133
| 0855
| Icom Simulations
|-
| 2134
| 0856
| Commodore Test Engineering Group
|-
| 2135
| 0857
| Microcreations
|-
| 2136
| 0858
| Shoestring Productions
|-
| 2137
| 0859
| Faberushi
|-
| 2138
| 085A
| Evesham Micro Ltd.
|-
| 2139
| 085B
| Panagolin Laser Software
|-
| 2140
| 085C
| Thomas Rudloff
|-
| 2141
| 085D
| Daniel Hohabir
|-
| 2142
| 085E
| GfxBase, Inc.
|-
| 2143
| 085F
| Axellabs
|-
| 2144
| 0860
| Roctec Electronics Inc.
|-
| 2145
| 0861
| Omega Datentechnik
|-
| 2146
| 0862
| Atlantis
|-
| 2147
| 0863
| Skytec Computers
|-
| 2148
| 0864
| Protar Electronics
|-
| 2149
| 0865
| ACS
|-
| 2150
| 0866
| Software Results Enterprises
| Originally registered to University of Illinois
|-
| 2151
| 0867
| Infinity Systems Design Group
|-
| 2152
| 0868
| Trade It
|-
| 2153
| 0869
| Suntec, Inc.
|-
| 2154
| 086A
| DJW Micro Systems
| Originally registered to Tritec Marketing
|-
| 2155
| 086B
| Power Computing Ltd.
|-
| 2156
| 086C
| MacroSystems
|-
| 2157
| 086D
| Masoboshi GmbH (DCE)
|-
| 2158
| 086E
| HAL Software Hardware Handel
|-
| 2159
| 086F
| Mainhattan Data
| Originally registered to Michael Lamm Computersysteme
|-
| 2160
| 0870
| Digital Processing System
| Originally registered to bbdp Electronics
|-
| 2161
| 0871
| Blue Ribbon Soundworks
| Originally registered to Design Computer Systems
|-
| 2162
| 0872
| XPert
| Originally registered to The Station
|-
| 2163
| 0873
| DelaComp
| Originally registered to Bryan Williams
|-
| 2164
| 0874
| Superformance Computer Engineering GmbH
|-
| 2165
| 0875
| Overland Engineering
|-
| 2166
| 0876
| Thomas Hamren
|-
| 2167
| 0877
| Village Tronic
|-
| 2168
| 0878
| Toolbox Design
|-
| 2169
| 0879
| Digital Processing System
|-
| 2170
| 087A
| Superformance
|-
| 2171
| 087B
| Utilities Unlimited
|-
| 2172
| 087C
| phase 5
|-
| 2173
| 087D
| Juergen Kommos
|-
| 2174
| 087E
| Electronic Design
|-
| 2175
| 087F
| James Cook University of North Queensland
|-
| 2176
| 0880
| AmiTrix Development
|-
| 2177
| 0881
| Ferranti
|-
| 2178
| 0882
| Leviathan Development
|-
| 2179
| 0883
| United Video Inc.
|-
| 2180
| 0884
| GPSoft Pty. Ltd.
| Originally registered to Juergen Kommos
|-
| 2181
| 0885
| ArMAX
| Oliver Bausch
|-
| 2182
| 0886
| CP Computer
|-
| 2183
| 0887
| AMOK - Amiga Module & Oberon Klub
|-
| 2184
| 0888
| ITEK Neser & Sieber GbR
|-
| 2185
| 0889
| Phillip C. Lello
|-
| 2186
| 088A
| Cyborg Design Services
|-
| 2187
| 088B
| G2 Systems
|-
| 2188
| 088C
| Pro System Computersysteme
|-
| 2189
| 088D
| ZEUS Electronic
| Originally registered to MSPI (Markt & Technik)
|-
| 2190
| 088E
| Altatech
|-
| 2191
| 088F
| NewTek
|-
| 2192
| 0890
| M-TEC Hardware Design
| Originally registered to Hardware Design Udo Neuroth
|-
| 2193
| 0891
| Great Valley Products
| Originally registered to Viona Development
|-
| 2194
| 0892
| Amitek
| Originally assigned to Marpet Developments
|-
| 2195
| 0893
| Ingenieurbuero Helfrich
|-
| 2196
| 0894
| The Neo Group
|-
| 2197
| 0895
| Cyon
|-
| 2198
| 0896
| Bob Research Group
|-
| 2199
| 0897
| Richmond Sound Design Ltd.
|-
| 2200
| 0898
| US Cybernetics
|-
| 2201
| 0899
| Fulvio Ieva
|-
| 2202
| 089A
| Silicon Studio
|-
| 2203
| 089B
| MacroSystems (USA)
| Was named Micro System Devices
|-
| 2204
| 089C
| Conspector Entertainment
|-
| 2205
| 089D
| Laserforum
|-
| 2206
| 089E
| Elbox Computer
| Mistakenly used by Index Information Ltd.
|-
| 2207
| 089F
| Applied Magic Inc.
|-
| 2208
| 08A0
| SDL Ltd.
|-
| 2560
| 0A00
| Harms
|-
| 2588
| 0A1C
| A1K.org Community
|-
| 2640
| 0A50
| Micronik
|-
| 3084
| 0C0C
| Team 4
|-
| 3643
| 0E3B
| E3B
| Michael Boehmer
|-
| 3855
| 0F0F
| Micronik
|-
| 4096
| 1000
| MegaMicro
|-
| 4110
| 100E
| DigiFeX
|-
| 4136
| 1028
| Imtronics/Memphis
|-
| 4149
| 1035
| PROTAR
|-
| 4369
| 1111
| Frank Strauß Elektronik
| Also used by Kupke
|-
| 4626
| 1212
| Individual Computers
|-
| 4648
| 1228
| Flesch Hornemann Computer Elec.
|-
| 4680
| 1248
| Kupke Computertechnik GmbH
|-
| 4711
| 1267
| RBM digitaltechnik
|-
| 4754
| 1292
| MacroSystems
|-
| 5000
| 1388
| ITH
|-
| 5001
| 1389
| VMC
|-
| 5010
| 1392
| Ambience Creation Technology
|-
| 5011
| 1393
| Creative Development
|-
| 5012
| 1394
| Georg Braun
|-
| 5013
| 1395
| Swedish User Group of Amiga
|-
| 5014
| 1396
| Jakub Bednarski
|-
| 5015
| 1397
| KryoFlux, Ltd.
|-
| 5016
| 1398
| Igor Majstorovic
|-
| 5017
| 1399
| Alastair M. Robinson
|-
| 5018
| 139A
| Austex Software
|-
| 5019
| 139B
| Sören Gust
|-
| 5020
| 139C
| Rok Krajnc
|-
| 5030
| 13A6
| Tim Tashpulatov
|-
| 5040
| 13B0
| 7-bit
|-
| 5050
| 13BA
| Sakura IT
|-
| 5060
| 13C4
| FPGAArcade
|-
| 5070
| 13CE
| CancerSoft Inc.
|-
| 5080
| 13D8
| Stephen Leary
|-
| 5090
| 13E2
| DMA Softlab LLC
|-
| 5100
| 13EC
| Brookhouse Engineering
|-
| 5110
| 13F6
| Eduardo Arana
|-
| 5120
| 1400
| CS-LAB
|-
| 5132
| 140C
| UAS Interface Ltd.
|-
| 5500
| 157C
| Inhouse Information
|-
| 5768
| 1688
| Bio Con
|-
| 6148
| 1804
| HK-Computer
|-
| 6502
| 1966
| Cloanto
|-
| 7777
| 1E61
| Rafal Gabriel Chyla
|-
| 8215
| 2017
| Vortex
|-
| 8244
| 2034
| Spirit Technology
|-
| 8290
| 2062
| Expansion Systems
|-
| 8448
| 2100
| ReadySoft
|-
| 8512
| 2140
| Phase 5 Digital Products
|-
| 8553
| 2169
| Digital Processing Systems Inc.
|-
| 8704
| 2200
| ACT Elektronik
|-
| 8738
| 2222
| ACT Elektronik
|-
| 9512
| 2528
| Tower Technologies
|-
| 10676
| 29B4
| Electronic Design
|-
| 14195
| 3773
| Media-net-Point
|-
| 14501
| 38A5
| Petsoff, Finland
|-
| 16375
| 3FF7
| Uwe Gerlach
|-
| 16707
| 4143
| Ateo Concepts
|-
| 16708
| 4144
| ALiENDESiGN
|-
| 16945
| 4231
| A.C.T.
|-
| 17740
| 454C
| HK-Computer (ELSAT)
|-
| 18260
| 4754
| MacroSystems (Germany)
|-
| 19796
| 4D54
| Markt & Technik
|-
| 22359
| 5757
| Markt & Technik
|-
| 26464
| 6760
| Combitec
|-
| 26470
| 6766
| Combitec
|-
| 28014
| 6D6E
| MNT Media and Technology UG
|-
| 32768
| 8000
| M.A.S.T.
|-
| 43437
| A9AD
| Reis-Ware
|-
| 43521
| AA01
| Cameron
|-
| 43537
| AA11
| Reis-Ware
|-
| 44359
| AD47
| Matay
|-
| 46504
| B5A8
| Phoenix
|-
| 49160
| C008
| Combitec
|-
| 61453
| F00D
| Forefront Technologies Inc.
|}

For any changes/additions to this registry please use the [http://www.amigaos.net/contact AmigaOS web site contact form].

Window Display Preservation

2017-12-05T20:00:56Z

Steven Solie:

= Preserving the Window Display =

The layers library is what allows the display and manipulation of multiple overlapping rectangles, or ''layers''. Intuition uses the layers library to manage its windows, by associating a layer to each window.

Each window is a virtual display. When rendering, the application does not have to worry about the current size or position of its window, and what other windows might be partly or fully obscuring its window. The window's RastPort is the handle to the its virtual display space. Intuition and graphics library rendering calls will recognize that this RastPort belongs to a layer, and act accordingly.

As windows are moved, resized, rearranged, opened, or closed, the on-screen representation changes. When part of a window which was visible now needs to appear in a new location, the layers library will move that imagery without involving the application. However, when part of a window that was previously obscured is revealed, or when a window is made larger, the imagery for the newly-visible part of the window needs to be redrawn. Intuition, through layers, offers three choices for how this is managed, trading off speed, memory usage, and application complexity.

* The most basic type of window is called ''Simple Refresh''. When any graphics operation takes place in this kind of window, the visible parts are updated, but rendering to the obscured parts is discarded. When the window arrangement changes to reveal a previously obscured part of such a window, the application must refresh that area.

* Alternately, a window may be made ''Smart Refresh'', which means that when rendering occurs, the system will not only update the visible parts of the window, but it will maintain the obscured parts as well, by using off-screen buffers. This means that when an obscured part of the window is revealed, the system will restore the imagery that belongs there. The application needs only to refresh parts of the window that appear when the window is made bigger. Smart Refresh windows use more memory than Simple Refresh windows (for the storage of obscured areas), but they are faster.

* The third kind of window is called ''SuperBitMap''. In such a window, the system can refresh the window even when it is sized bigger. For this to work, the application must store a complete bitmap for the window's maximum size. Such a window is more work to manage, and uses yet more memory. SuperBitMap windows are used less often than the other two types.

Intuition helps your application manage window refresh. First, Intuition will take care of redrawing the window border and any system and application gadgets in the window. Your application never has to worry about that. Second, Intuition will notify your application when it needs to refresh its window (by sending the IDCMP_REFRESHWINDOW event). Third, Intuition provides functions that restrict your rendering to the newly-revealed (damaged) areas only, which speeds up your refresh rendering and makes it look cleaner.

The Intuition, layers, and graphics libraries work together to make rendering into and managing windows easy. You obtain your windows through Intuition, which uses the Layers library to manage the overlapping, resizing, and re-positioning of the window layers. The layers library is responsible for identifying the areas of each window that are visible, obscured but preserved off-screen, or obscured and not preserved. The rendering functions in the graphics library and Intuition library know how to render into the multiple areas that layers library establishes.

Note that you may not directly manipulate layers on an Intuition screen. You cannot create your own layers on an Intuition screen, nor can you use the layers movement, sizing, or arrangement functions on Intuition windows. Use the corresponding Intuition calls instead. Some other Layers library calls (such as the locking calls) are sometimes used on Intuition screens and windows.

= Damage Regions =

The layers library and Intuition maintain a ''damage region'' for each window, which is the part of the window whose imagery is in need of repair, or refreshing. Several things can add areas of the window to the damage region:

* Revealing an obscured part of a Simple Refresh window adds that area to the damage region
* Sizing a Simple or Smart Refresh window bigger along either axis adds the new area to the damage region
* Resizing a Simple or Smart Refresh window (smaller or bigger) adds the old and new border areas, and the areas occupied by certain gadgets (those whose position or size depend on window size) to the damage region.

= Refreshing Intuition Windows =

When the user or an application performs an Intuition operation which causes damage to a window, Intuition notifies that window's application. It does this by sending a message of the class IDCMP_REFRESHWINDOW to that window's IDCMP.

In response to this message, your application should update the damaged areas. Rendering proceeds faster and looks cleaner if it is restricted to the damaged areas only. The BeginRefresh()/EndRefresh() pair achieve that. The application should call BeginRefresh() for the window, and then do its rendering. Any rendering that would have gone into undamaged areas of the window is automatically discarded; only the area in need of repair is affected. Finally, the application should call EndRefresh(), which removes the restriction on rendering, and informs the system that the damage region has been dealt with. Even if your application intends to do no rendering, it must at least call BeginRefresh()/EndRefresh(), to inform the system that the damage region is no longer needed. If your application never needs to render in response to a refresh event, it can avoid having to call BeginRefresh()/EndRefresh() by setting the WFLG_NOCAREREFRESH flag or the WA_NoCareRefresh tag in the OpenWindowTagList() call.

Note that by the time that your application receives notification that refresh is needed, Intuition will have already refreshed your window's border and all gadgets in the window, as needed. Thus, it is unnecessary to use any of the gadget-refreshing functions in response to an IDCMP_REFRESHWINDOW event.

Operations performed between the BeginRefresh()/EndRefresh() pair should be restricted to simple rendering. All of the rendering functions in Intuition library and Graphics library are safe. Avoid RefreshGList() or RefreshGadgets(), or you risk deadlocking the computer. Avoid calls that may lock the LayerInfo or get complicated in Intuition, since BeginRefresh() leaves the window's layer or layers locked. Avoid AutoRequest() and EasyRequest(), and therefore all direct or indirect disk related DOS calls. See the [[Intuition_Gadgets|Intuition Gadgets]] section for more information on gadget restrictions with BeginRefresh() and EndRefresh().

== Simple Refresh ==

For a Simple Refresh window, only those pixels actually on-screen are maintained by the system. When part of a Simple Refresh window is obscured, the imagery that was there is lost. As well, any rendering into obscured portions of such a window is discarded.

When part of the window is newly revealed (either because the window was just made larger, or because that part used to be obscured by another window), the application must refresh any rendering it wishes to appear into that part. The application will learn that refresh is needed because Intuition sends an IDCMP_REFRESHWINDOW event.

== Smart Refresh ==

If a window is of the Smart Refresh type, then the system will not only preserve those pixels which are actually on-screen, but it will save all obscured pixels that are within the current window's size. The system will refresh those parts of the window revealed by changes in the overlapping with other windows on the screen, without involving the application. However, any part of the window revealed through the sizing of the window must be redrawn by the application. Again, Intuition will notify the application through the IDCMP_REFRESHWINDOW event.

Because the obscured areas are kept in off-screen buffers, Smart Refresh windows are refreshed faster than Simple Refresh windows are, and often without involving the application. Of course, for the same reason, they use more display memory.

== SuperBitMap Refresh ==

The SuperBitMap refresh type allows the application to provide and maintain bitmap memory for graphics in the window. The bitmap can be any size as long as the window sizing limits respect the maximum size of the bitmap.

SuperBitMap windows have their own memory for maintaining all obscured parts of the window up to the size of the defined bitmap, including those parts outside of the current window. Intuition will update all parts of the window that are revealed through changes in sizing and changes in window overlapping. The application never needs to redraw portions of the window that were revealed by sizing or positioning windows in the screen.

SuperBitMap windows require the application to allocate a bitmap for use as off-screen memory, instead of using Intuition managed buffers. This bitmap must be as large as, or larger than, the inner window's maximum dimensions (that is, the window's outside dimensions less the border sizes).

SuperBitMap windows are almost always WFLG_GIMMEZEROZERO, which renders the borders and system gadgets in a separate bitmap. If the application wishes to create a SuperBitMap window that is not GimmeZeroZero, it must make the window borderless with no system gadgets, so that no border imagery is rendered by Intuition into the application's bitmap.

= Intuition Refresh Events =

When using a Simple Refresh or a Smart Refresh windows, the program may receive refresh events, informing it to update the display. See the above discussion for information on when refresh events are sent.

A message of the class IDCMP_REFRESHWINDOW arrives at the IDCMP, informing the program of the need to update the display. The program must take some action when it receives a refresh event, even if it is just the acceptable minimum action described below.

On receiving a refresh event, BeginRefresh() must be called, then the program should redraw its display, and, finally, call EndRefresh(). The minimum required action is to call the BeginRefresh()/EndRefresh() pair. This allows Intuition and the Layers library keep things sorted and organized.

= Optimized Window Refreshing =

Bracketing the display updating in the BeginRefresh()/EndRefresh() pair automatically restricts all rendering to the "damaged" areas.

<syntaxhighlight>
VOID BeginRefresh( struct Window *window );
VOID EndRefresh ( struct Window *window, LONG complete );
</syntaxhighlight>

These functions makes sure that refreshing is done in the most efficient way, only redrawing those portions of the window that really need to be redrawn. The rest of the rendering commands are discarded.

Operations performed between the BeginRefresh()/EndRefresh() pair should be restricted to simple rendering. All of the rendering functions in Intuition library and Graphics library are safe. Calls to RefreshGadgets() are not permitted. Avoid calls that may lock the LayerInfo, or get complicated in Intuition, since BeginRefresh() leaves the window's layer or layers locked. Avoid AutoRequest(), and therefore all direct or indirect disk related DOS calls. See [[Intuition_Gadgets|Intuition Gadgets]] for more information on gadget restrictions with BeginRefresh()/EndRefresh().

Certain applications do not need to receive refresh events, and can avoid having to call BeginRefresh() and EndRefresh() by setting the WFLG_NOCAREREFRESH flag or the WA_NoCareRefresh tag in the OpenWindowTagList() call.

The EndRefresh() function takes a boolean value as an argument (complete in the prototype above). This value determines whether refreshing is completely finished. When set to FALSE, further refreshing may be performed between subsequent BeginRefresh()/ EndRefresh() pairs. Set the boolean to TRUE for the last call to EndRefresh().

It is critical that applications performing multiple BeginRefresh() and EndRefresh() pairs using EndRefresh(win,FALSE) hold layers locked through the entire process. The layer lock may only be released after the final call to EndRefresh(win,TRUE). See [[Layers_Library|Layers Library]] for more details.

The procedures outlined in this section take care of refreshing what is inside the window. Another function named RefreshWindowFrame() refreshes window borders, including the title region and gadgets:

<syntaxhighlight>
VOID RefreshWindowFrame( struct Window *window );
</syntaxhighlight>

Applications can use this function to update window borders after overwriting them with graphics.

= Setting up a SuperBitMap Window =

SuperBitMap windows are created by setting the WFLG_SUPER_BITMAP flag, or by specifying the WA_SuperBitMap tag in the OpenWindowTagList() call. A pointer to an allocated and initialized BitMap structure must be provided.

A SuperBitMap window requires the application to allocate and initialize its own bitmap. This entails allocating a BitMap structure, initializing the structure and allocating memory for the bit planes.

Allocate a BitMap structure with the Exec AllocMem() function. Then use the graphics function InitBitMap() to initialize the BitMap structure:

<syntaxhighlight>
VOID InitBitMap( struct BitMap *bitMap, LONG depth, LONG width, LONG height );
</syntaxhighlight>

InitBitMap() fills in fields in the BitMap structure describing how a linear memory area is organized as a series of one or more rectangular bit-planes.

Once you have allocated and initialized the BitMap structure, use the graphics library function AllocRaster() to allocate the memory space for all the bit planes.

<syntaxhighlight>
PLANEPTR AllocRaster( ULONG width, ULONG height );
</syntaxhighlight>

The example listed in the next section shows how to allocate a BitMap structure, initialize it with InitBitMap() and use AllocRaster() function to set up memory for the bitplanes.

= Graphics and Layers Functions for SuperBitMap Windows =

The portion of the bitmap showing within a SuperBitMap window is controlled by the application. Initially, the window shows the bitmap starting from its origin (0,0) and clipped to fit within the window layer. The visible portion of the bitmap can be scrolled around within the window using the layers library ScrollLayer() function:

<syntaxhighlight>
VOID ScrollLayer(LONG unused, struct Layer *layer, LONG dx, LONG dy)
</syntaxhighlight>

Pass this function a pointer to the window's layer in layer and the scroll offsets in dx and dy. (A pointer to the window's layer can be obtained from Window.RPort->Layer.)

When rendering operations are performed in a SuperBitMap window, any rendering that falls outside window boundaries is done in the application's bitmap. Rendering that falls within window bounds is done in the screen's bitmap. Before performing an operation such as a save on the application bitmap, the graphics library function SyncSBitMap() should be called:

<syntaxhighlight>
VOID SyncSBitMap(struct Layer *layer)
</syntaxhighlight>

Pass this function a pointer to the window's layer. SyncSBitMap() copies the window contents to the corresponding part of the application bitmap, bringing it up to date. (If no rendering operations have been performed this call is not necessary.)

Similarly, after making any changes to the application bitmap such as loading a new one, the window's layer should be locked and the CopySBitMap() function should be called.

<syntaxhighlight>
VOID CopySBitMap(struct Layer *)
</syntaxhighlight>

This function copies the new information in the appropriate area of the underlying bitmap to the window's layer.

For more information about bitmaps and layers, see the [[Graphics_Primitives|Graphics Primitives]] and [[Layers_Library|Layers Library]]. Also see the <graphics/clip.h>, <graphics/gfx.h>, <graphics/layers.h > files in the SDK.

== SuperBitMap Window Example ==

This example shows how to implement a superbitmap, and uses a host of Intuition facilities. Further reading of other Intuition, BOOPSI and graphics chapters may be required for a complete understanding of this example.

<syntaxhighlight>
/**
** lines.c -- Window SuperBitMap example.
**
** gcc -o lines lines.c
**
**/

#include <dos/dos.h>
#include <intuition/icclass.h>
#include <classes/window.h>
#include <gadgets/scroller.h>
#include <gadgets/layout.h>

#include <proto/intuition.h>
#include <proto/exec.h>
#include <proto/utility.h>
#include <proto/layers.h>
#include <proto/graphics.h>

#define WIDTH_SUPER (800)
#define HEIGHT_SUPER (600)
#define MINWIDTH (150)
#define MINHEIGHT (150)

#define LAYERXOFFSET(x) (x->RPort->Layer->Scroll_X)
#define LAYERYOFFSET(x) (x->RPort->Layer->Scroll_Y)

enum
{
WID_MAIN = 0,
WID_LAST
};

enum
{
OID_MAIN = 0,
OID_VPROP,
OID_HPROP,
OID_LAST
};

struct IntuitionIFace *IIntuition;
struct GraphicsIFace *IGraphics;
struct LayersIFace *ILayers;

static struct Window *windows[WID_LAST];
static Object *objects[OID_LAST];
static struct Hook idcmphook;

/* Prototypes for our functions */

void initBorderProps(struct Screen *screen);
void doNewSize();
void doDrawStuff();
void doMsgLoop();
void superWindow(struct Screen *screen);
void slideBitMap(struct Window *win, int16 dX, int16 dY);

int main()
{
struct Screen *screen;

struct Library *IntuitionBase = IExec->OpenLibrary("intuition.library", 50);
IIntuition = (struct IntuitionIFace *) IExec->GetInterface(IntuitionBase,
"main", 1, NULL);

struct Library *GfxBase = IExec->OpenLibrary("graphics.library", 50);
IGraphics = (struct GraphicsIFace *) IExec->GetInterface(GfxBase, "main", 1, NULL);

struct Library *LayersBase = IExec->OpenLibrary("layers.library", 50);
ILayers = (struct LayersIFace *) IExec->GetInterface(LayersBase, "main", 1, NULL);

if (IIntuition != NULL && IGraphics != NULL && ILayers != NULL) {
if ((screen = IIntuition->LockPubScreen(NULL)) != NULL) {
superWindow(screen);
IIntuition->UnlockPubScreen(NULL, screen);
}
}

IExec->DropInterface((struct Interface *) ILayers);
IExec->CloseLibrary(LayersBase);

IExec->DropInterface((struct Interface *) IGraphics);
IExec->CloseLibrary(GfxBase);

IExec->DropInterface((struct Interface *) IIntuition);
IExec->CloseLibrary(IntuitionBase);

return 0;
}

void IDCMPHook(struct Hook *hook, Object *object, struct IntuiMessage *msg)
{
if (msg->Class == IDCMP_IDCMPUPDATE) {
int16 dX = 0;
int16 dY = 0;
int32 pos;

struct Window *win = windows[WID_MAIN];
if (win != NULL) {
uint32 gadgetid = IUtility->GetTagData(GA_ID, 0, (struct TagItem *) msg->IAddress);
if (IIntuition->GetAttr(SCROLLER_Top, objects[gadgetid], (uint32 *) &pos)) {
switch (gadgetid) {
case OID_VPROP:
dY = pos - LAYERYOFFSET(win);
break;
case OID_HPROP:
dX = pos - LAYERXOFFSET(win);
break;
}
if (dX || dY) {
slideBitMap(win, dX, dY);
}
}
}
}
}

void superWindow(struct Screen *myscreen)
{
struct BitMap *bigBitMap = IGraphics->AllocBitMapTags(WIDTH_SUPER, HEIGHT_SUPER, myscreen->BitMap.Depth,
BMATags_Friend, myscreen->BitMap, BMATags_Displayable, TRUE, BMATags_Clear, 0, TAG_END);

if (bigBitMap != NULL) {
struct MsgPort *AppPort = IExec->AllocSysObjectTags(ASOT_PORT, TAG_DONE);

if ( AppPort != NULL )
{
idcmphook.h_Entry = (uint32 (*)())IDCMPHook;
idcmphook.h_SubEntry = NULL;

if ((objects[OID_MAIN] = IIntuition->NewObject(NULL, "window.class",
WA_ScreenTitle, "SuperBitmap",
WA_Title, "Lines",
WA_Activate, TRUE,
WA_DepthGadget, TRUE,
WA_DragBar, TRUE,
WA_CloseGadget, TRUE,
WA_SizeGadget, TRUE,
WA_Top, 10,
WA_Left, 10,
WA_MinWidth, MINWIDTH,
WA_MinHeight, MINHEIGHT,
WA_Width, MINWIDTH,
WA_Height, MINHEIGHT,
WA_IDCMP, IDCMP_NEWSIZE | IDCMP_IDCMPUPDATE,
WA_PubScreen, myscreen, WA_SuperBitMap, bigBitMap,
WA_NoCareRefresh, TRUE,
WA_GimmeZeroZero, TRUE,
WINDOW_IDCMPHook, &idcmphook,
WINDOW_IDCMPHookBits, IDCMP_IDCMPUPDATE,
WINDOW_HorizProp, 1,
WINDOW_VertProp, 1,
WINDOW_AppPort, AppPort, TAG_DONE)) != NULL) {
// Open the window.
if (windows[WID_MAIN] = (struct Window *) IIntuition->IDoMethod(objects[OID_MAIN], WM_OPEN)) {
/* adjust props to represent portion visible */
doNewSize();
doDrawStuff();
/* process the window, return on IDCMP_CLOSEWINDOW */
doMsgLoop();
}
IIntuition->DisposeObject(objects[OID_MAIN]);
}
IExec->FreeSysObject(ASOT_PORT, AppPort);
}
IGraphics->FreeBitMap(bigBitMap);
}
}

void slideBitMap(struct Window *win, int16 Dx, int16 Dy)
{
ILayers->ScrollLayer(0, win->RPort->Layer, Dx, Dy);
}

/*
** Update the prop gadgets and bitmap positioning when the size changes.
*/

void doNewSize()
{
struct Window *win = windows[WID_MAIN];
if (win != NULL) {
IIntuition->GetAttr(WINDOW_HorizObject, objects[OID_MAIN], (uint32 *) &objects[OID_HPROP]);
if (objects[OID_HPROP]) {
if (win->GZZWidth >= WIDTH_SUPER)
slideBitMap(win, -LAYERXOFFSET(win), 0);
IIntuition->RefreshSetGadgetAttrs((APTR) objects[OID_HPROP], win, NULL,
GA_ID, OID_HPROP,
SCROLLER_Top, LAYERXOFFSET(win),
SCROLLER_Total, WIDTH_SUPER,
SCROLLER_Visible, win->GZZWidth,
ICA_TARGET, ICTARGET_IDCMP,
TAG_DONE);
}

IIntuition->GetAttr(WINDOW_VertObject, objects[OID_MAIN], (uint32 *) &objects[OID_VPROP]);
if (objects[OID_VPROP]) {
if (win->GZZHeight >= HEIGHT_SUPER)
slideBitMap(win, 0, -LAYERYOFFSET(win));

IIntuition->RefreshSetGadgetAttrs((APTR) objects[OID_VPROP], win, NULL,
GA_ID, OID_VPROP,
SCROLLER_Top, LAYERYOFFSET(win),
SCROLLER_Total, HEIGHT_SUPER,
SCROLLER_Visible, win->GZZHeight,
ICA_TARGET, ICTARGET_IDCMP,
TAG_DONE);
}
}
}

int16 RangeRand(uint32 maxValue)
{
static struct RandomState range = {0xFFFF, 0};
return IUtility->Random(&range) % maxValue;
}

void doDrawStuff()
{
struct Window *win = windows[WID_MAIN];
if (win != NULL) {
/* clear the bitplanes */
IGraphics->SetRast(win->RPort, 0);
IGraphics->SetDrMd(win->RPort, JAM1);
int16 x1, y1, x2, y2;
int16 pen, ncolors, deltx, delty;
ncolors = 1 << win->WScreen->BitMap.Depth;
deltx = RangeRand(6) + 2;
delty = RangeRand(6) + 2;
pen = RangeRand(ncolors - 1) + 1;
IGraphics->SetAPen(win->RPort, pen);
for (x1 = 0, y1 = 0, x2 = WIDTH_SUPER - 1, y2 = HEIGHT_SUPER - 1;
x1 < WIDTH_SUPER; x1 += deltx, x2 -= deltx) {
IGraphics->Move(win->RPort, x1, y1);
IGraphics->Draw(win->RPort, x2, y2);
}

pen = RangeRand(ncolors - 1) + 1;
IGraphics->SetAPen(win->RPort, pen);
for (x1 = 0, y1 = 0, x2 = WIDTH_SUPER - 1, y2 = HEIGHT_SUPER - 1;
y1 < HEIGHT_SUPER; y1 += delty, y2 -= delty) {
IGraphics->Move(win->RPort, x1, y1);
IGraphics->Draw(win->RPort, x2, y2);
}
}
}

void doMsgLoop()
{
uint32 signal = 0;
BOOL done = FALSE;

// Obtain the window wait signal mask.
IIntuition->GetAttr(WINDOW_SigMask, objects[OID_MAIN], &signal);

// Input Event Loop
while (!done) {
uint32 wait = IExec->Wait(signal | SIGBREAKF_CTRL_C);
if ( wait & SIGBREAKF_CTRL_C ) {
done = TRUE;
break;
}

if ( wait & signal ) {
uint32 result = WMHI_LASTMSG;
int16 code = 0;
while ((result = IIntuition->IDoMethod(objects[OID_MAIN], WM_HANDLEINPUT, &code)) != WMHI_LASTMSG) {
switch (result & WMHI_CLASSMASK) {
case WMHI_NEWSIZE:
doNewSize();
doDrawStuff();
break;
case WMHI_CLOSEWINDOW:
windows[WID_MAIN] = NULL;
done = TRUE;
break;
case WMHI_ICONIFY:
IIntuition->IDoMethod(objects[OID_MAIN], WM_ICONIFY);
windows[WID_MAIN] = NULL;
break;
case WMHI_UNICONIFY:
windows[WID_MAIN] = (struct Window *) IIntuition->IDoMethod(objects[OID_MAIN], WM_OPEN);
doNewSize();
doDrawStuff();
break;
}
}
}
}
}
</syntaxhighlight>

File:ProcessTaskClassDiagram.png

2017-12-05T19:56:26Z

Steven Solie:

AmiWest Lesson 2

2017-12-05T19:56:08Z

Steven Solie: /* Tasks and Processes */

= AmiWest Lesson 2: Fundamentals =

== Basic Types ==

It is important to under at least the basic types when programming. The following table summarizes the basic types used in AmigaOS as compared to standard C and C++ types:

{| class="wikitable"
|+AmigaOS Types
! Type !! Deprecated Type(s) !! C !! C++
|-
| uint64 || none || uint64_t || uint64_t
|-
| int64 || none || int64_t || int64_t
|-
| uint32 || ULONG or LONGBITS or CPTR || uint32_t || uint32_t
|-
| int32 || LONG || int32_t || int32_t
|-
| uint16 || UWORD or WORDBITS or USHORT or UCOUNT or RPTR || uint16_t || uint16_t
|-
| int16 || WORD or SHORT or COUNT || int16_t || int16_t
|-
| uint8 || UBYTE or BYTEBITS || char or unsigned char || unsigned char
|-
| int8 || BYTE || signed char || signed char
|-
| STRPTR || none || char* || char*
|-
| CONST STRPTR || n/a || char* const x || char* const x
|-
| CONST_STRPTR || n/a || const char* || const char*
|-
| CONST CONST_STRPTR || n/a || const char* const || const char* const
|-
| APTR || none || void* || void*
|-
| CONST APTR || none || void* const x || void* const x
|-
| CONST_APTR || none || const void* || const void*
|-
| CONST CONST_APTR || none || const void* const || const void* const
|-
| float32 || FLOAT || float || float
|-
| float64 || DOUBLE || double || double
|-
| BOOL || none || int16 || int16
|-
| TEXT || none || char || char
|-
| NULL || none || 0L || (void*)0L
|-
| BPTR || none || int32_t || int32_t
|-
| BSTR || none || int32_t || int32_t
|-
| ZERO || none || (BPTR)0 || (BPTR)0
|}

== Static versus Dynamic Linking ==

The different between static and dynamic linking can best be explained with an example.

<syntaxhighlight>
#include <stdio.h>

int main()
{
printf("Hello, world\n");
return 0;
}
</syntaxhighlight>

Here is "hello" created using static linking:

gcc -mcrt=clib2 -N -o hello hello.c -Wl,--cref,-M,-Map=hello.map
strip hello

The "hello" executable is roughly 34964 bytes in size. The "hello.map" file contains the linker map which shows you exactly what pieces of code have been pulled in from where to create that executable.

Here is "hello" created using dynamic linking:

gcc -mcrt=newlib -N -o hello hello.c -Wl,--cref,-M,-Map=hello.map
strip hello

The "hello" executable is now 5488 bytes in size and the "hello.map" file is substantially simpler as well.

{{Note|The -N switch is used to work around a feature in the current GCC toolset. The problem has been fixed but a new compiler is not yet generally available. See [[The_Hacking_Way:_Part_1_-_First_Steps|Myth #2: AmigaOS binaries are fat]] for more details.}}

It is important to remember that each program is still essentially the same size. In fact, the dynamically linked program may even be larger. The reason is that the same amount of code is still used. The difference is that the dynamically linked executable is sharing code with other executables. The statically linked executable is not sharing code and thus occupies more disk space.

A statically linked program is a self-contained unit which generally has no extraneous external dependencies. Any dependency problems will show up when linking the executable.

A dynamically linked program requires external libraries in order to function. If any of those libraries are missing or the wrong version, your program will fail at runtime and not when you compile it.

For programmers, it is very important to know where your libraries are coming from and what their limitations are. Just assuming you can mix and match static and dynamic libraries at will is foolish. Always try to understand what each library does and what caveats apply to its usage.

== Libraries and Interfaces ==

AmigaOS provides hundreds of functions which are split up into different shared libraries. Each shared library is further split up into different interfaces. Much more detailed information about Libraries and Interfaces can be found in [[Exec_Libraries|Exec Libraries]]

=== Opening and Closing ===

The following code can be used to open interfaces:
<syntaxhighlight>
struct Interface* try_open_iface_name(CONST_STRPTR libname, uint32 libver, CONST_STRPTR ifacename)
{
struct Library* base = IExec->OpenLibrary(libname, libver);
if ( base != 0 ) {
struct Interface* iface = IExec->GetInterface(base, ifacename, 1, 0);

if ( iface != 0 ) {
return iface;
}

IExec->CloseLibrary(base);
}

return 0;
}

struct Interface* open_iface_name(CONST_STRPTR libname, uint32 libver, CONST_STRPTR ifacename)
{
struct Interface* iface = try_open_iface_name(libname, libver, ifacename);

if ( iface == 0 ) {
IDOS->Printf("Can't open %s version %lu interface %s\n", libname, libver, ifacename);
}

return iface;
}

struct Interface* open_iface(CONST_STRPTR libname, uint32 libver)
{
return open_iface_name(libname, libver, "main");
}
</syntaxhighlight>

The following code can be used to close an interface and the corresponding library:
<syntaxhighlight>
void close_iface(struct Interface* iface)
{
if ( iface != 0 ) {
struct Library* lib = iface->Data.LibBase;
IExec->DropInterface(iface);
IExec->CloseLibrary(lib);
}
}
</syntaxhighlight>

=== Special Syntax Support ===

Exec Interfaces are called using a special syntax supported by the GNU GCC compiler included with the SDK:

IExec->DebugPrintF("Hello, world\n");

Using a regular compiler this would translate into:

IExec->DebugPrintF(IExec, "Hello, world\n");

Notice how the first argument to the function call is 'hidden' when using the modified GNU GCC compiler. This becomes especially important when trying to understand error messages from the compiler. For example, the following code is invalid:
<syntaxhighlight>
#include <proto/exec.h>

int main()
{
IExec->DebugPrintF(42);
return 0;
}
</syntaxhighlight>

gcc -o args args.c
args.c: In function 'main':
args.c:5: warning: passing argument 2 of 'IExec->DebugPrintF' makes pointer from integer without a cast

Notice how the compiler is referring to "argument 2" even though there is only one argument in the call to IExec->DebugPrintF(). This is a side effect of the 'hidden' IExec argument referred to earlier.

== Tasks and Processes ==

AmigaOS has two basic threads of control: Tasks and Processes. The following class diagram illustrates their relationship to each other:

[[File:ProcessTaskClassDiagram.png|frame|center]]

Tasks are created by Exec (exec.library) while Processes are created by DOS (dos.library). A Process includes more overhead than a Task. This is primarily because a Process can access all the facilities offered by DOS such as file handling and input and output streams.

In general, you should always prefer to use a Process instead of a Task. Although a Process may include more overhead, a Process is also simpler to work with. Tasks are generally relegated to low level activities. I will be focusing on the use of Processes in this lesson.

To create a new Process, DOS provides the following function:
<syntaxhighlight>
struct Process *proc = CreateNewProcTags(uint32 Tag1, ...);
</syntaxhighlight>

There are many tags which can be used to customize the way in which the new Process is created which are fully explained in the dos.doc AutoDoc.

Library base pointers (struct Library*) may be global and shared between Processes. Interface pointers must not be shared between Processes unless this is explicitly allowed. The reason for this is because an Exec Interface may allocate resources which are bound to the context of the caller. That means if your parent Process calls GetInterface() then it allocates resources only for that Process. A child Process must call GetInterface() as well to allocate resources for that child Process.

=== Synchronization Primitives ===

When two or more Tasks and/or Processes want to share common data with each other then synchronization primitives are likely to be required.

* Signals are the most basic way for two processes to communicate with each other. A signal is a single bit which is either 1 or 0. There are 16 user signals available and many system signals. See [[Exec_Signals|Signals]] for more details.

* Message ports are used to transfer messages between two processes. The message can be sent one way or it can be sent and replied. Message data is always shared and not copied so it is critical that message passing protocols are followed. See [[Exec_Messages_and_Ports|Messages and Ports]] for more details.

* Semaphores provide a rich interface for sharing resources between processes. Sempahores can be shared so that multiple processes can wait on a single semaphore simultaneously. See [[Exec_Semaphores|Semaphores]] for more details.

* Mutexes provide a simple high speed interface for sharing resources between processes. Mutexes are exclusive and cannot be shared. Mutexes can also be recursive or not depending on the application. See [[Exec_Mutexes|Mutexes]] for more details.

{{Note|If you are sharing memory between two entities that memory must be marked as MEMF_SHARED. Failure to comply with this requirement will result in problems when AmigaOS starts to enforce MEMF_PRIVATE memory semantics.}}

== Shared Objects ==

Shared objects are an idea directly lifted from the Unix world. The main reason shared objects were added to AmigaOS is to enable much simpler porting of complex applications. For example, Amiga Python was implemented using shared objects which makes it very easy to maintain. It is up to each programmer to determine whether they want to use traditional Amiga shared libraries or shared objects for their particular project. For a discussion of the pros and cons see [[The_Right_Tool_for_the_Job_(Shared_Objects)|The Right Tool for the Job]].

File:DataTypesClassDiagram.png

2017-12-05T19:54:07Z

Steven Solie:

Datatypes Library

2017-12-05T19:53:51Z

Steven Solie: /* Classes, Objects and Methods */

= Introduction =

The purpose of the DataTypes Library is to provide tools for handling data in an object-oriented way. The object-oriented approach means that your application can work with numerous data file standards without having to worry about the complex details of each one. Instead you only need to understand the simple conventions of the library.

The DataTypes Library is built on Intuition's BOOPSI facility (BOOPSI is an acronym for Basic Object-Oriented Programming System for Intuition). Although not required, it is very helpful to know a little about [[BOOPSI_-_Object_Oriented_Intuition|how BOOPSI works]] before trying to use the DataTypes Library. Some familiarity with object-oriented theory and practice is also helpful, though not required.

Since the library uses the TagItem structure for passing parameters to functions, you will have to understand how TagItems work before you can call the library functions. For more information on TagItems refer to the [[Utility_Library|Utility Library]].

== Spelling Conventions ==

In software development, the term “datatype” or “data type” is often used in the general sense, whereas the AmigaOS DataTypes framework establishes a rather special context. In order to avoid possible confusion, this documentation uses capitalized spelling in reference to components and programming entities that are part of the said framework, such as: the DataTypes Library, a DataType subclass, a DataType object, Picture DataType, etc.

== Why Use DataTypes? ==

Here's a summary of main properties and features:

* Support for multiple file formats across various types of data (text, sound, image, animation etc.). Load data the easy way without having to write dedicated loader code!

* Simple and consistent handling of multiple data standards. Once you have learned how to manipulate one type of data with the DataTypes Library, you will find that the other types are handled in much the same way.

* Extensible. New data types can be added to those already supported.

* Clipboard support. The DataTypes Library provides a consistent and easy-to-use interface to the Amiga's [[Clipboard_Device|clipboard device]] to encourage data sharing between applications.

* Intuition gadget support. Because the DataTypes Library is implemented with BOOPSI, the data objects it handles can also be treated as gadgets. Gadget operations can be performed on data objects within Intuition's task context, the same as other BOOPSI gadgets.

* Automatic conversion from one format to another. Future versions of the DataTypes Library will support other types of data objects. Conversion from one format to another will be automatically handled by the library.

* Validation. For example, you can easily check to see if a file is a valid JPEG (AIFF, AmigaGuide etc.) or not.

= Classes, Objects and Methods =

The jargon used to describe the DataTypes Library may be a little confusing if you have never worked with object-oriented systems before. For instance, the kinds of data supported by the library are divided into ''classes'' and ''subclasses''. The term ''class'' is used here in a familiar way; the members of a class simply have a common set of properties. The members of a subclass have all the properties of the parent class (superclass) and additional properties specific to the subclass. (Each subclass can be further broken down into sub-subclasses and so on.)

{| class="wikitable"
| Class || Ungulate || Has hooves, can run.
|-
| Subclass || Cow || Has udder, can be milked (also has hooves and can run).
|-
| Object || Daisy || An instance of class Cow; can run and can be milked.
|}

An actual instance of a class or subclass is referred to as an ''object''. The term ''object'' is appropriate because in general we want to ignore the details of each individual case and concentrate instead on what we can do with an object based on its class. In the example above the Daisy object can run and can be milked. The operations that can be performed with an object are referred to as ''methods'' and the object is said to ''inherit'' the methods and other attributes of its parent class (which in turn inherits the methods and attributes of its parent class, if it has one).

The datatypes.library implements ''datatypesclass'' from which all other DataType classes inherit from. The following BOOPSI class diagram illustrates how the various DataTypes classes relate to each other.

[[File:DataTypesClassDiagram.png|frame|center|DataTypes Class Diagram]]

{| class="wikitable"
|+ DataTypes Library Object Classes
! Object Classes
! Autodoc File Showing the Methods Supported
! Type of Data Object
|-
| Picture class
| picture_dtc.doc
| IFF graphic image file
|-
| Sound class
| sound_dtc.doc
| IFF audio sample file
|-
| Text class
| text_dtc.doc
| ASCII characters
|-
| AmigaGuide class
| amigaguide_dtc.doc
| Hypertext databases
|-
| Animation class
| animation_dtc.doc
| Animations containing graphics and sound
|}

The examples programs listed below demonstrate how to perform some basic ''methods'' on ILBM and 8SVX class objects.

= DataTypes Class Attributes =

DataType classes have other attributes in addition to the methods (operations) that they support. For each attribute, there is a corresponding TagItem defined in the DataTypes Library that you can use to examine or set that attribute in a particular object. For example, picture objects have a display mode attribute. The tag that controls this attribute is named PDTA_ModeID and is described in the Autodoc file picture_dtc.doc. See the Autodoc files for each class (as shown in Table 1) for a complete list of all class attributes.

The class attribute descriptions in the include files also have a set of codes that indicate the ''applicability'' of the attribute. The codes are as follows:

{| class="wikitable"
| I - Initialize
| You can initialize the attribute when the object is created
|-
| S - Set
| You can set the attribute to a new value after the object is created
|-
| G - Get
| You can get the value of the attribute after the object is created
|-
| N - Notify
| Changing the attribute triggers the object to send notification
|-
| U - Update
| Attribute can be set using the object's OM_UPDATE method
|}

These codes may seem a little mysterious until you have actually tried using the DataTypes Library. The N and U codes in particular are for special applications that want to implement their own object classes, an advanced topic beyond the scope of this article.

= Basic Functions of the DataTypes Library =

If all these new concepts seem a little daunting, rest assured; the DataTypes Library uses conventional C language function calls to get the job done. The calls you will be using most often are listed below. Notice that for each of these basic functions of DataTypes Library there is an equivalent BOOPSI call in the Intuition Library.

{| class="wikitable"
! datatypes.library
! intuition.library
! Purpose
|-
| NewDTObject()
| NewObject()
| Create a DataType object in memory from a file or clip
|-
| DisposeDTObject()
| DisposeObject()
| Free an object created earlier with NewDTObject() (or NewObject() )
|-
| GetDTAttrs()
| GetAttr()
| Get attributes of a DataType object
|-
| SetDTAttrs()
| SetAttrs()
| Set attributes for a DataType object
|-
| DoDTMethod()
| IDoMethod()
| Perform the given method (operation) with a DataType object
|}

There are also additional functions used to access DataType objects.

{| class="wikitable"
! Function Name
! Purpose
|-
| AddDTObject() || Add a DataType object to a window.
|-
| RefreshDTObjectA() || Refresh the rendering of a DataType object.
|-
| RemoveDTObject() || Remove a DataType object from a window.
|-
| GetDTMethods() || Get a list of the methods that a DataTypes object supports. Write, Copy, and Select are examples of methods that an object may support.
|-
| GetDTTriggerMethods() || Get a list of the trigger methods that a DataType object supports. An action like Play, Pause, and Resume are examples of trigger methods that an object may support.
|-
| PrintDTObject() || Asynchronously print a DataType object.
|-
| GetDTString() || Get the localized text string for a DataTypes text id. Useful for obtaining localized error messages.
|}

In a typical application the sequence of calls might be performed
like this:

# Use NewDTObject() to create an object in memory from given data.
# Get (or perhaps set) attributes of the object using GetDTAttr() (or SetDTAttrs() ).
# Perform ''methods'' (operations) with the object using DoDTMethod().
# Free the object and any memory or other resources it was using with the DisposeDTObject() call.

= Basic Structures of the DataTypes Library =

There are a lot of structures used with DataTypes Library function calls; too many to summarize in this article. However, here's a listing of the relevant include files that contain the structure definitions of interest to class users.

{| class="wikitable"
| <datatypes/datatypes.h>
| Group IDs, error numbers plus library overhead
|-
| <datatypes/datatypesclass.h>
| Defines DataType methods and associated structures
|-
| <datatypes/picture.h>
| Structures specific to the picture class
|-
| <datatypes/sound.h>
| Structures specific to the sound class
|-
| <datatypes/text.h>
| Structures specific to the text class
|-
| <libraries/amigaguide.h>
| Structures and methods for AmigaGuide databases
|-
| <intuition/classusr.h>
| Defines general BOOPSI object methods
|-
| <intuition/gadgetclass.h>
| Defines gadget methods and associated structures
|}

The two most important definitions in these include files appear in <intuition/classusr.h>. The objects used with DataTypes Library functions (and the BOOPSI functions in Intuition) are defined as follows:

<syntaxhighlight>
typedef ULONG Object; /* abstract handle */
</syntaxhighlight>

Since we want to treat objects as black boxes and don't really care how they are implemented, this definition is very appropriate. When a method is performed with an object, the parameter used to identify the method is a Msg structure defined as follows:

<syntaxhighlight>
typedef struct {
ULONG MethodID;
/* method-specific data goes here */
} *Msg;
</syntaxhighlight>

Some methods require more information than just the method identifier. Such methods have a custom structure defined in the include files. All method structures, however, begin with a field that contains the method ID.

= Creating a DataType Object =

The DataTypes function NewDTObjectA() must be used to create a new DataType object.

<syntaxhighlight>
Object *dto = IDataTypes->NewDTObjectA (APTR name, struct TagItem *attrs);
</syntaxhighlight>

The pointer that NewDTObjectA() returns is a pointer to a BOOPSI object. Like other BOOPSI objects, DataType objects are "black boxes" and are not to be peeked and poked without using the provided interface.

To create a DataType object, NewDTObjectA() needs to know the where to obtain the data used to create the object. By default the name is treated as file name.

The attrs tag list is a list of tag/value pairs, each of which contains an initial value for an attribute. There are a number of attributes defined in <datatypes/datatypesclass.h> that can be used at creation time.

; DTA_SourceType
: Specify the type of the source data. The default is DTST_FILE.
:{| class="wikitable"
| DTST_RAM || Source data is in RAM.
|-
| DTST_FILE || Source data is a file. Name is the name of the file.
|-
| DTST_CLIPBOARD || Source data is in the clipboard. Name is the unit number. For example, (APTR)0, for clipboard unit zero.
|-
| DTST_HOTLINK || Reserved for future use.
|}

; DTA_Handle
: Can be used instead of the name field. If the source type is DTST_FILE then handle must be a valid BPTR file handle. If the source type is DTST_CLIPBOARD then handle must be a valid IFFHandle.

; DTA_DataType
: Can be used to specify the class for handling the data. Data must be a pointer to a valid DataType. This should only be used when attempting to create a new object that doesn't have source data, or could be handled by multiple classes (for example, could be used to force an object to be handled by the AmigaGuide class).

; DTA_GroupID
: If this tag is present, then the data must be of the specified type, or the object creation will fail with ERROR_OBJECT_WRONG_TYPE. This can be used by a Sound editor to ensure that only sounds can be loaded, for example.

There are additional attributes that can specified at creation time, but are dependant on the data type of the object being created. See the header files <datatypes/#?class.h> for more attributes.

The following attributes, which are defined in <intuition/gadgetclass.h>, are also valid.
{| class="wikitable"
! Tag !! Description
|-
| GA_Left || Specify the left edge of the gadget.
|-
| GA_RelRight || Specify the left edge of the gadget being relative to the right edge of the containing window.
|-
| GA_Top || Specify the top edge of the gadget.
|-
| GA_RelBottom || Specify the top edge of the gadget being relative to the bottom edge of the containing window.
|-
| GA_Width || Specify the width of the gadget.
|-
| GA_RelWidth || Specify the width of the gadget being relative to the width of the containing window.
|-
| GA_Height || Specify the heigh of the gadget.
|-
| GA_RelHeight || Specify the heigh of the gadget being relative to the height of the containing window.
|-
| GA_ID || Specify a ID associated with the gadget.
|-
| GA_UserData || Attach application data to the gadget.
|-
| GA_Immediate || Indicate that the application should be notified of gadget down events for this gadget.
|-
| GA_RelVerify || Indicate that the application should be notified of gadget up events for this gadget.
|-
| GA_Previous || For adding the gadget to a list of gadgets.
|-
| GA_DrawInfo || A pointer to a struct DrawInfo.
|}

In order for the application to receive information from the DataType object, it must set up a target for the notification attributes that the object sends out.

; ICA_TARGET
: Specify a target for the notification attributes that the DataType object sends out.

; ICA_MAP
: Specify an attribute mapping for the notification attributes that the DataType object sends out.

The usual method to obtain notification is to set up an ICA_TARGET of ICTARGET_IDCMP so that the application will receive the attributes via the IDCMP_IDCMPUPDATE Intuition message class. But it is also possible to set up another BOOPSI object as the receiver.

If NewDTObjectA() is successful, it returns a pointer to a DataType object. Otherwise it returns NULL and the reason for failure can be obtained using IoErr(). See the Autodocs for datatypes.library for more information.

= Obtaining Environment Information for a DataType =

In order to embed a DataType object in a window, it is neccessary to ask the object what its minimum environment is. For example, since the remap code doesn't handle remapping HAM pictures, they must be shown on a HAM screen, and therefore can't be added to a window that is on a non-HAM screen.

<syntaxhighlight>
ULONG modeid = INVALID_ID;
LONG nomwidth, nomheight;
BOOL useScreen = FALSE;
struct dtFrameBox dtf;
struct FrameInfo fri;

/* Get the attributes that we are interested in */
IDataTypes->GetDTAttrs(dto,
/* Get the mode ID */
PDTA_ModeID, &modeid,

/* Get the desired size */
DTA_NominalHoriz, &nomwidth,
DTA_NominalVert, &nomheight,

TAG_END);

/* Clear the structures */
IUtility->ClearMem(&dtf, sizeof (struct dtFrameBox));
IUtility->ClearMem(&fri, sizeof (struct FrameInfo));

/* Fill in the message */
dtf.MethodID = DTM_FRAMEBOX;
dtf.dtf_FrameInfo = &fri;
dtf.dtf_ContentsInfo = &fri;
dtf.dtf_SizeFrameInfo = sizeof (struct FrameInfo);

/* Perform the frame method */
if (IDataTypes->DoDTMethodA (dto, NULL, NULL, (Msg) &dtf))
{
/* Check to see if the object requires a HAM screen */
if (fri.fri_PropertyFlags & DIPF_IS_HAM)
{
IDOS->Printf ("HAM\n");
useScreen = TRUE;
}
/* Check to see if the object requires an ExtraHalfBrite screen */
else if (fri.fri_PropertyFlags & DIPF_IS_EXTRAHALFBRITE)
{
IDOS->Printf ("ExtraHalfBrite\n");
useScreen = TRUE;
}
/* A safety check to see if a screen is required */
else if ((fri.fri_PropertyFlags == 0) && (modeid & 0x800) && (modeid != INVALID_ID))
{
IDOS->Printf ("ModeID=0x%08lx\n", modeid);
useScreen = TRUE;
}
}
else
{
/* No special environment required, can be attached to any screen mode */
}
</syntaxhighlight>

= Adding a DataType Object to a Window =

A DataType object must be added to a window using the AddDTObject() function of DataTypes.

<syntaxhighlight>
LONG AddDTObject (struct Window *w, struct Requester *r, Object *dto, LONG pos)
</syntaxhighlight>

This function will add a DataTypes object to the existing gadget list for the specified window. The recommended value for pos is -1 which will cause the DataType object to be added to the end of the list.

DataType objects should not be added using the WA_Gadgets attribute to OpenWindowTagList() or by using the AddGList() function. There is special information that DataTypes requires that will not obtained if any method other than AddDTObject() is used.

When the DataType object is added to the window, the layout method for the object will be invoked. It is possible that the layout will take a while to perform, in that case the object will spawn a process to handle the layout asynchronously. In order to refresh the object's visual information, it is necessary to obtain IDCMP_IDCMPUPDATE messages from the object and refresh the object when a DTA_Sync attribute is received.

The following code fragment illustrates adding a DataType object to a window.

<syntaxhighlight>
Object *dto;

struct IntuiMessage *imsg;
struct Window *win;
ULONG sigr;

struct TagItem *tstate, *tags;
ULONG tidata;
ULONG errnum;

BOOL going = TRUE;

/* Set the pertinent attributes of the DataType object */
IDataTypes->SetDTAttrs (dto, NULL, NULL,

/* Set the dimensions of the object */
GA_Left, win->BorderLeft,
GA_Top, win->BorderTop,
GA_Width, win->Width - win->BorderLeft - win->BorderRight,
GA_Height, win->Height - win->BorderTop - win->BorderBottom,

/* Make sure we receive IDCMP_IDCMPUPDATE messages from
* the object */
ICA_TARGET, ICTARGET_IDCMP,
TAG_END);

/* Add the object to the window */
IDataTypes->AddDTObject (win, NULL, dto, -1);

/* Refresh the DataType object */
IDataTypes->RefreshDTObjects (dto, win, NULL, NULL);

/* Keep going until we're told to stop */
while (going)
{
/* Wait for an event */
sigr = IExec->Wait ((1L << win->UserPort->mp_SigBit) | SIGBREAKF_CTRL_C);

/* Did we get a break signal */
if (sigr & SIGBREAKF_CTRL_C)
going = FALSE;

/* Pull Intuition messages */
while (imsg = (struct IntuiMessage *) IExec->GetMsg (win->UserPort))
{
/* Handle each message */
switch (imsg->Class)
{
case IDCMP_IDCMPUPDATE:
/* Get a pointer to the attribute list */
tstate = tags = (struct TagItem *) imsg->IAddress;

/* Step through the attribute list */
while (tag = IUtility->NextTagItem (&tstate))
{
tidata = tag->ti_Data;
switch (tag->ti_Tag)
{
/* Change in busy state */
case DTA_Busy:
if (tidata)
IIntuition->SetWindowPointer (win, WA_BusyPointer, TRUE, TAG_END);
else
IIntuition->SetWindowPointer (win, WA_Pointer, NULL, TAG_END);
break;

/* Error message */
case DTA_ErrorLevel:
if (tidata)
{
errnum = IUtility->GetTagData (DTA_ErrorNumber, NULL, tags);
IDOS->PrintErrorMsg (errnum, (STRPTR) options[OPT_NAME]);
}
break;

/* Time to refresh */
case DTA_Sync:
/* Refresh the DataType object */
IDataTypes->RefreshDTObjects (dto, win, NULL, NULL);
break;
}
}
break;
}

/* Done with the message, so reply to it */
IExec->ReplyMsg ((struct Message *) imsg);
}
}
</syntaxhighlight>

= Removing a DataType Object from a Window =

A DataType object must be removed from the window using the RemoveDTObject() function.

<syntaxhighlight>
LONG RemoveDTObject (struct Window *w, Object *dto)
</syntaxhighlight>

This function removes the DataType object from the window's gadget list.

This is the only way that a DataType object should be removed from the window list. Using RemoveGList() is not supported, nor is removing the object manually.

= Setting an Existing DataType Object's Attributes =

An objects attributes are not necessarily static. An application can ask an object to set certain attributes using the SetDTAttrs() function.

<syntaxhighlight>
ULONG SetDTAttrsA (Object *dto, struct Window *w, struct Requester *r, struct TagItem *attrs)
</syntaxhighlight>

The return value is DataType object specific, but generally a non-zero value means that the object needs to be visually refreshed.

The following fragment illustrates how to set the current top values for a DataType object, using the VarArgs version of SetDTAttrsA().

<syntaxhighlight>
IDataTypes->SetDTAttrs(dto, window, NULL,
DTA_TopVert, 0,
DTA_TopHoriz, 0,
TAG_END);
</syntaxhighlight>

This will cause the DataType object to update its vertical and horizontal top values. If the object has been added to a window, then the display will be updated accordingly.

Note that it is not OK to call SetGadgetAttrs() or SetAttrs() on a DataType object.

= Getting a DataType Object's Attributes =

The DataTypes function GetDTAttrsA() is used to obtain the values for a list of attributes from a DataType object.

<syntaxhighlight>
ULONG GetDTAttrsA (Object *dto, struct TagItem *attrs)
</syntaxhighlight>

Where dto is a pointer to a DataType object returned by NewDTObjectA().

And attrs is a TAG_END terminated array of attributes. Where the data element of each pair contains the address of the storage variable for that attribute.

This function will return a number that indicates that number of attributes that it was able to obtain. For example if four attributes asked for and GetDTAttrs returns a four, then all the attributes were obtained.

The following code fragment illustrates how to get the current top values
for a DataTypes object using the VarArgs form of GetDTAttrsA().

<syntaxhighlight>
LONG topv, toph;

if (IDataTypes->GetDTAttrs (dto, DTA_TopVert, &topv, DTA_TopHoriz, &toph, TAG_END) == 2)
{
IDOS->Printf ("Top: vertical=%ld, horizontal=%ld\n", topv, toph);
}
else
{
IDOS->Printf ("couldn't obtain the top values\n");
}
</syntaxhighlight>

= A Simple DataTypes Example =

The example program listed here should clarify some of the concepts discussed so far. Suppose you have a communications program and want to add the capability of playing back a user-specified 8SVX sample file for the bell sound (Ctrl-G). The program below shows how to play a sound with the DataTypes Library.

In this program, objects are of class 8SVX (a subclass of the Sound DataType). The method performed with the object is named DTM_TRIGGER (described in the Autodoc file sound_dtc.doc). The DTM_TRIGGER method (with type set to STM_PLAY) causes a sampled sound to be played on the Amiga's audio hardware. Since the DTM_TRIGGER method requires other information in addition to the method ID, a dtTrigger structure is used. This structure is defined in <datatypes/datatypesclass.h>.

Note that if the Sound DataType is enhanced to support other types of sound files in a future version of AmigaOS, the code given here will automatically support the new type. This example expects the file name and path to a sound file.

<syntaxhighlight>
/* Run from CLI only. */

#include <exec/types.h>
#include <datatypes/datatypesclass.h> /* This includes other files we need */

#include <proto/exec.h> /* Prototypes for system functions */
#include <proto/intuition.h>
#include <proto/datatypes.h>
#include <proto/dos.h

struct IntuitionIFace *IIntuition = NULL;
struct DataTypesIFace *IDataTypes = NULL;

int main(int argc, char **argv)
{
APTR dtobject = NULL /* Pointer to a DataTypes object */
struct dtTrigger mydtt; /* A trigger structure for the DTM_TRIGGER method */

if(argc <= 1 ) /* CLI only, at least one argument please. */
{
IDOS->Printf("Give a file name too.\n");
return RETURN_FAIL;
}

struct Library *IntuitionBase = IExec->OpenLibrary("intuition.library", 50);
IIntuition = (struct IntuitionIFace*)IExec->GetInterface(IntuitionBase, "main", 1, NULL);

struct Library *DataTypesBase = IExec->OpenLibrary("datatypes.library", 50);
IDataTypes = (struct DataTypesIFace*)IExec->GetInterface(DataTypesBase, "main", 1, NULL);

if (IIntuition != NULL && IDataTypes != NULL)
{
/* Attempt to make an 8svx sound object from the file name the user */
/* specified in the command line. For a list of possible error */
/* returns, see the Autodocs for NewDTObjectA(). The group ID tag */
/* will allow only Sound DataType files to be accepted for the call.*/
if (dtobject = IDataTypes->NewDTObject(argv[1], DTA_GroupID, GID_SOUND,
TAG_END) )
{
mydtt.MethodID = DTM_TRIGGER; /* Fill in the dtTrigger struct */
mydtt.dtt_GInfo = NULL;
mydtt.dtt_Function = STM_PLAY;
mydtt.dtt_Data = NULL;

/* The return value of the DTM_TRIGGER method used with the 8svx */
/* Sound DataType is undefined in V39. This is likely to change */
/* in future versions of the Amiga operating system. */
uint32 dores = IDataTypes->DoDTMethodA(dtobject, NULL, NULL, &mydtt);

// Let the 8svx sound finish playing. Another way is to use
// SDTA_SignalTask and SDTA_SignalBit to find out when it is
// finished playing.
IExec->Wait(SIGBREAKF_CTRL_C);

IDataTypes->DisposeDTObject(dtobject);
}
else IDOS->Printf("Couldn't create new object or not a sound data file\n");
}
else IDOS->Printf("Can't open interfaces\n");

IExec->DropInterface((struct Interface*)IDataTypes);
IExec->CloseLibrary(DataTypesBase);

IExec->DropInterface((struct Interface*)IIntuition);
IExec->CloseLibrary(IntuitionBase);

return 0;
}
</syntaxhighlight>

In addition to playing back a sampled sound, the DataTypes Library allows sound objects to become gadgets (the library includes default imagery for a sound gadget). Since all DataTypes are implemented as a subclass of the BOOPSI ''gadgetclass'', they all support the methods of gadget objects as described in [[BOOPSI_-_Object_Oriented_Intuition|BOOPSI]].

= Embedding DataTypes =

Since DataTypes are a subclass of the Intuition ''gadgetclass'', DataType objects can be attached to an Intuition window in a similiar way that gadgets can be added to a window. DataTypes use a parallel set of functions because it requires additional information that the Intuition functions weren't able to provide.

Currently the handling of the data is limited to reading, writing, printing, viewing (audio or visual), and clipboard access. Utilities like MultiView or MultiViewer are examples of applications that can embed DataType objects.

= Determining Data Type =

One of the main features of the DataTypes system is its ability to determine the type of a block of data. This data block can reside in a file or the clipboard.

The following functions are used to determine the DataType of a data block:

{| class="wikitable"
| ObtainDataTypeA() || Obtain the DataType descriptor for a data block.
|-
| ReleaseDataType() || Release the DataType descriptor for a data block.
|}

The data type detection functions use the DataType structure.

<syntaxhighlight>
struct DataType
{
struct Node dtn_Node1;
struct Node dtn_Node2;
struct DataTypeHeader *dtn_Header;
struct List dtn_ToolList;
STRPTR dtn_FunctionName;
struct TagItem *dtn_AttrList;
ULONG dtn_Length;
};
</syntaxhighlight>

The DataType structure is read-only. The only pertinent field is the dtn_Header field, which points to a DataTypeHeader structure.

<syntaxhighlight>
struct DataTypeHeader
{
STRPTR dth_Name;
STRPTR dth_BaseName;
STRPTR dth_Pattern;
WORD *dth_Mask;
ULONG dth_GroupID;
ULONG dth_ID;
WORD dth_MaskLen;
WORD dth_Pad;
UWORD dth_Flags;
WORD dth_Priority;
};
</syntaxhighlight>

The DataTypeHeader structure fields are as follows:

; dth_Name
: Descriptive name of the data type. For example, the description for an ILBM data type could possibly be "Amiga BitMap Picture".

; dth_BaseName
: This is the base name for the data type and is used to obtain the class that handles this data type.

; dth_GroupID
: This identifies the general type of data that the object contains. Following are the possible values:
:{| class="wikitable"
| GID_SYSTEM || Fonts, Executables, Libraries, Devices, etc...
|-
| GID_TEXT || Formatted or unformatted text.
|-
| GID_DOCUMENT || Formatted text with embedded DataTypes (such as pictures).
|-
| GID_SOUND || Audio samples.
|-
| GID_INSTRUMENT || Audio samples used for playing music.
|-
| GID_MUSIC || Musical scores.
|-
| GID_PICTURE || Graphic picture or brush.
|-
| GID_ANIMATION || Moving picture or cartoon.
|-
| GID_MOVIE || Moving picture or cartoon with sound.
|}

; dth_ID
: This is an individual indentifier for the DataType. For IFF files it is the same as the FORM type, for example ILBM for an Amiga BitMap picture. For non-IFF files, it is the first four characters of dth_Name.

; dth_Flags
: The flags field contains, among other information, the coarse type of data. The type can be obtained by ANDing DTF_TYPE_MASK with this field.
:{| class="wikitable"
| DTF_IFF || Interchange File Format
|-
| DTF_BINARY || Non-readable characters
|-
| DTF_ASCII || Readable characters
|-
| DTF_MISC || Disks and drawers
|}

; dth_Pattern
; dth_Mask
; dth_MaskLen
; dth_Priority
: These fields are used by the detection code in datatypes.library for determining the data type. See the "Defining a DataType Descriptor" section for more information.

Following is a code fragment that shows how to determine the data type of a file. This fragment uses functions from the DataTypes Library, DOS Library, and IFFParse Library.

<syntaxhighlight>
STRPTR name = "somefilename";
BPTR lock;

struct DataTypeHeader *dth;
struct DataType *dtn;
UBYTE idesc[5];
STRPTR tdesc;
STRPTR gdesc;
UWORD ttype;

/* Obtain a lock on the file that we want information on */
if (lock = IDOS->Lock (name, ACCESS_READ))
{
/* Get a pointer to the appropriate DataType structure */
if (dtn = IDataTypes->ObtainDataTypeA (DTST_FILE, (APTR)lock, NULL))
{
/* Get a pointer to the DataTypeHeader structure */
dth = dtn->dtn_Header;

/* Get the coarse type */
ttype = dth->dth_Flags & DTF_TYPE_MASK;

/* Get a pointer to the text strings */
tdesc = IDataTypes->GetDTString (ttype + DTMSG_TYPE_OFFSET);
gdesc = IDataTypes->GetDTString (dth->dth_GroupID);

/* Convert the ID to a string. */
IIFFParse->IDtoStr (dth->dth_ID, idesc);

/* Display the information */
IDOS->Printf (" Description: %s\n", dth->dth_Name);
IDOS->Printf (" Base Name: %s\n", dth->dth_BaseName);
IDOS->Printf (" Type: %d - %s\n", ttype, tdesc);
IDOS->Printf (" Group: %s\n", gdesc);
IDOS->Printf (" ID: %s\n", idesc);

/* Release the DataType structure now that we are done with it */
IDataTypes->ReleaseDataType (dtn);
}

/* Release the DOS lock on the file */
IDOS->UnLock (lock);
}
</syntaxhighlight>

= A Picture Class Example =

Here is a second, more complex example showing how to use all the DataTypes Library functions described so far. In this example the objects used are of class ILBM, a subclass of the Picture DataType.

Two methods will be performed with the object, DTM_PROCLAYOUT and DTM_FRAMEBOX. Both these methods have associated structures (gpLayout and dtFrameBox respectively). DTM_PROCLAYOUT makes the object available within the context of your application task (as opposed to Intuition's). DTM_FRAMEBOX queries the display environment required by the picture.

Other attributes of the picture are obtained with a call to GetDTAttrs() and then a matching Intuition screen is created and the ILBM object is displayed. This example expects the file and path name of a picture file.

<syntaxhighlight>
/* Run from CLI only.
*/

#include <exec/types.h>
#include <datatypes/datatypes.h>
#include <datatypes/pictureclass.h>

#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/intuition.h>
#include <proto/datatypes.h>
#include <proto/graphics.h>

struct IntuitionIFace *IIntuition = NULL;
struct GraphicsIFace *IGraphics = NULL;
struct DataTypesIFace *IDataTypes = NULL;

int main(int argc, char **argv)
{
APTR dtobject=NULL; /* Pointer to a DataTypes object */
uint32 res; /* Variable for function return values */
struct dtFrameBox mydtFrameBox; /* Use this with DTM_FRAMEBOX method */
struct FrameInfo myFrameInfo; /* For info returned from DTM_FRAMEBOX */
struct gpLayout mygpLayout; /* Use this with DTM_PROCLAYOUT method */

uint32 modeID = INVALID_ID; /* Variables for storing the display */
struct Screen *myScreen=NULL; /* environment information obtained */
struct BitMap *bm = NULL; /* the DataType object. */
uint32 *cregs = NULL;
uint32 i,r,g,b,numcolors;

struct Library *IntuitionBase = IExec->OpenLibrary("intuition.library", 50);
struct Library *GfxBase = IExec->OpenLibrary("graphics.library", 50);
struct Library *DataTypesBase = IExec->OpenLibrary("datatypes.library", 50);

IIntuition = (struct IntuitionIFace*)IExec->GetInterface(IntuitionBase, "main", 1, NULL);
IGraphics = (struct GraphicsIFace*)IExec->GetInterface(GfxBase, "main", 1, NULL);
IDataTypes = (struct DataTypesIFace*)IExec->GetInterface(DataTypesBase, "main", 1, NULL);

if (IIntuition != NULL)
{
if (IGraphics != NULL)
{
if (IDataTypes != NULL)
{
if(argc > 1 ) /* CLI only, at least one argument please. */
{
/* Attempt to create a picture object in memory from the file */
/* name given by the user in the command line. If we wanted to */
/* show the picture in a screen set up ahead of time, we could */
/* set PDTA_Remap to TRUE and provide a pointer to the screen */
/* with the PDTA_Screen tag (datatypes.library handles the rest).*/
/* However in this case we want to first find out the attributes */
/* of the picture object and set up a matching screen and do the */
/* remapping later. Therefore PDTA_Remap is set to false. */
/* The group ID tag ensures that we get only a picture file type.*/
if (dtobject = IDataTypes->NewDTObject(argv[1], PDTA_Remap, FALSE,
DTA_GroupID, GID_PICTURE,
TAG_END) )
{
/* Here we want to find the display environment required by */
/* this picture. To do that, perform the DTM_FRAMEBOX method */
/* on the object. The DataTypes Library fills in the struct */
/* FrameBox you give it with the info on the display needed. */
mydtFrameBox.MethodID = DTM_FRAMEBOX;
mydtFrameBox.dtf_GInfo = NULL;
mydtFrameBox.dtf_ContentsInfo = NULL;
mydtFrameBox.dtf_FrameInfo = &myFrameInfo;
mydtFrameBox.dtf_SizeFrameInfo= sizeof (struct FrameInfo);
mydtFrameBox.dtf_FrameFlags = 0L;

/* The return value from DTM_FRAMEBOX is currently undefined */
res = IIntuition->IDoMethodA(dtobject, &mydtFrameBox);

/* OK, now do the layout (remap) of the object on our process */
mygpLayout.MethodID = DTM_PROCLAYOUT;
mygpLayout.gpl_GInfo = NULL;
mygpLayout.gpl_Initial= 1L;

/* The return value of DTM_PROCLAYOUT is non-zero for success */
if( res = IIntuition->IDoMethodA(dtobject, &mygpLayout) )
{
/* Get the attributes of this picture object. You could */
/* use a series of GetAttr() function calls here instead. */
res = IDataTypes->GetDTAttrs(dtobject, PDTA_ModeID, &modeID,
PDTA_CRegs, &cregs,
PDTA_BitMap, &bm,
TAG_END);

/* Did we get all threee attributes? */
if( (modeID!=INVALID_ID) && (cregs) && (bm) )
{
/* Open a screen that matches the picture object */
if( myScreen = IIntuition->OpenScreenTags( NULL,
SA_Width, myFrameInfo.fri_Dimensions.Width,
SA_Height, myFrameInfo.fri_Dimensions.Height,
SA_Depth, myFrameInfo.fri_Dimensions.Depth,
SA_DisplayID, modeID,
SA_BitMap, bm,
TAG_END) )
{
/* Now fill in the color registers for this screen */
numcolors = 2<<(myFrameInfo.fri_Dimensions.Depth-1);
for( i=0; i < numcolors; i++ )
{
r = cregs[i * 3 + 0];
g = cregs[i * 3 + 1];
b = cregs[i * 3 + 2];
IGraphics->SetRGB32(&myScreen->ViewPort, i, r, g, b);
}

IDOS->Printf("Ctrl-C in this window to quit\n");
/* Wait for the user to have a look... */
IExec->Wait(SIGBREAKF_CTRL_C);

IIntuition->CloseScreen(myScreen);
}
else IDOS->Printf("Couldn't open required screen\n");
}
else IDOS->Printf("Couldn't get picture attributes\n");

IDataTypes->DisposeDTObject(dtobject);
}
else IDOS->Printf("Couldn't perform PROC_LAYOUT\n");
}
else IDOS->Printf("Couldn't create new object or not a picture file\n");
}
else IDOS->Printf("Give a file name too.\n");
}
else IDOS->Printf("Can't open DataTypes Library\n");
}
else IDOS->Printf("Can't open Graphics Library\n");
}
else IDOS->Printf("Can't open Intuition Library\n");

IExec->DropInterface((struct Interface*)IDataTypes);
IExec->DropInterface((struct Interface*)IGraphics);
IExec->DropInterface((struct Interface*)IIntuition);

IExec->CloseLibrary(DataTypesBase);
IExec->CloseLibrary(GfxBase);
IExec->CloseLibrary(IntuitionBase);

return 0;
}
</syntaxhighlight>

As with 8SVX objects, the DataTypes Library allows ILBM objects to be treated as gadgets. Remember that all DataTypes are a subclass of the BOOPSI ''gadgetclass'' and therefore support the gadget methods described in [[BOOPSI Gadgets]].