Drivers explained

In AROS OS, drivers are integrated through the Amiga-like system structure, especially through drawers such as DEVS:, Libs:, Classes:, and sometimes Storage:. AROS does not usually use one single “driver manager” like Windows. Instead, drivers are stored as files in specific system locations and are loaded automatically during boot or when a device is mounted. 

Basic idea of drivers 

in AROS A driver is a piece of software that allows AROS to communicate with hardware or a virtual device. Drivers may be responsible for things such as:
hard disks and partitions
CD/DVD drives
USB devices
graphics output
sound cards
network adapters
printers
file systems
input devices such as mouse and keyboard

The basic idea is: 
Application or system component↓
AROS device/library/class↓
Driver↓
Hardware or virtual hardware 

For example, a program does not normally access a disk controller directly. It asks the operating system, and the operating system uses the correct driver to talk to the device. 

What does DEVS: mean? 

DEVS: is an important AROS assign. It points to the system drawer that contains device-related files. 

Usually it corresponds to something like: SYS:Devs But users and programs normally refer to it as: DEVS: This is because Amiga-like systems use assigns: logical names that point to real paths. A beginner can think of DEVS: as: the drawer where AROS keeps many device drivers and device descriptions. 

Typical contents of DEVS: 

Depending on the AROS distribution, DEVS: may contain items such as: 
device drivers
monitor/display drivers
DOS drivers
printer drivers
mount files
file system components
keymaps
datatypes-related device files
storage-related configuration

Typical subdrawers may include names like: 
DEVS:DOSDrivers
DEVS:Monitors
DEVS:Keymaps
DEVS:Printers
DEVS:Networks
DEVS:Storage 

The exact structure depends on the AROS version and distribution. 

What is Storage:? 

Some Amiga-like systems use a Storage: drawer for drivers or mount files that are available but not active automatically. 

A simple distinction is: LocationMeaning 
DEVS: Active device files used by the system Storage: Optional device files stored for later use For example, a DOS driver file may be kept in Storage:DOSDrivers if it should not be mounted automatically at boot. If the user wants it to become active automatically, it may be copied to DEVS:DOSDrivers. In simple words: DEVS: = active or system-used device setup
Storage: = optional or inactive device setup

What is a MountList? 

A MountList is a configuration file that describes how a device or volume should be mounted. 

It tells the system things such as: which device driver to use
which unit number to access
which file system to use
block size
buffers
volume name
startup options
whether the device is removable
other low-level disk or device settings

A MountList is especially important for disk-like devices and volumes. 

A simplified beginner example could look conceptually like this: 
Device = ata.device
Unit = 0
FileSystem = FastFileSystem
Volume = Work 

This is not meant as a complete working MountList. It only shows the kind of information such a file may contain. 

MountList versus DOSDriver 

On Amiga-like systems, the older term MountList often refers to one larger configuration file containing mount entries. A DOSDriver is often a more modern or more convenient form where each mountable device has its own file. 

For beginners: 
MountList A list of mount definitions 
DOSDriver A single mount definition stored as a separate file 
Mount The command/process that activates such a definition 

So instead of having one big MountList, the system may use individual files in: 
DEVS:DOSDrivers or: Storage:DOSDrivers 

How devices are mounted 

When AROS mounts a device, it reads the mount information and loads the needed driver. 

The process is roughly: 
Mount command or boot process↓
Reads DOSDriver or MountList entry↓
Finds the device driver↓
Loads file system if needed↓
Creates a volume or device name↓
The device becomes usable 

After that, the device may appear as a volume such as: 
Work:
CD0:
USB0: 

depending on the setup. 

Automatic mounting at boot 

Some drivers or devices become active automatically during boot. This can happen if their configuration files are placed in active system locations such as: 

DEVS:DOSDrivers 

During startup, AROS may scan this drawer and mount the devices listed there. 

If a file is stored instead in: 

Storage:DOSDrivers 

it may be available but not mounted automatically. This is useful because not every possible device should always be active. 9. Drivers, libraries, and classes Not every driver is stored only in DEVS:. AROS uses several system drawers. DEVS: Used for device drivers and device configuration. 

Typical examples: 
disk devices
monitor/display definitions
printer device files
DOS drivers
keymaps

Libs: 

Used for shared libraries. A library provides functions that programs or drivers can use. Example idea: LIBS:some.library If a program says a library is missing, it often means a required file is missing from Libs:. 

Classes: 

Used for class-based components, often related to BOOPSI, GUI objects, datatypes, or system components. Some applications need specific classes to display windows, buttons, images, or other objects. C: Used for command-line tools. Some driver packages include commands that must be copied to: C: Prefs: Used for preference programs. Some drivers include a configuration tool that belongs in: Prefs: 

How new drivers are installed 

The exact installation method depends on the driver package. 

There is no single universal method, but the usual process is: 
Read the driver’s documentation.
Copy the driver file to the correct drawer.
Copy related libraries, classes, or commands if needed.
Copy the DOSDriver or mount file if the device must be mounted.
Configure ToolTypes or preference settings if required.
Reboot or manually mount/load the device.
Test whether the device works.

Typical manual installation example 

A simple driver package may contain files like this: 
mydevice.device
MyDevicemydevice.library
mytool 

These might be copied like this: 
mydevice.device    → DEVS:
MyDevice           → DEVS:DOSDrivers
mydevice.library   → LIBS:
mytool             → C: 

After copying, the user may need to mount the DOS driver: Mount MyDevice Or reboot, if the file was placed in DEVS:DOSDrivers.

Installing a DOSDriver 

If a driver package includes a DOSDriver file, it is important where the file is placed. 

To make it available but not auto-start: 
Storage:DOSDrivers To make it mount automatically at boot: DEVS:DOSDrivers 
Some users first test a driver from Storage:DOSDrivers. 

If it works, they move or copy it to DEVS:DOSDrivers. This is safer because a bad mount file in DEVS:DOSDrivers may cause boot problems. 

Installing a monitor or graphics driver 

Graphics or monitor drivers may use: 
DEVS:Monitors 

A monitor file may define or enable certain screen modes. After installing it, the user may need to open: Prefs:ScreenMode Then they can select a new screen mode if the driver works. If the selected screen mode fails, the system may become unreadable, so beginners should test carefully. 

Installing a network driver 

Network drivers may require: 
a device driver
a network stack configuration
IP settings
DHCP setup
sometimes additional tools

The files may go into places such as: DEVS:DEVS:NetworksLibs:Prefs: The exact method depends strongly on the AROS distribution and the network stack used. In a VM, it is often easier to choose a virtual network card known to work with the AROS distribution.

Installing a printer driver 

Printer drivers may involve: 
DEVS:PrintersPrefs: 

After copying the driver, the user may need to open printer preferences and select: 
printer type
output port
paper size
print quality

In a VM, printing through the host system is often easier than direct printer driver setup in AROS. 16. Installing file system drivers A file system driver allows AROS to read or write a specific disk format. It may be placed in a location such as: L: or another system-specific location depending on the AROS setup. A DOSDriver or MountList entry may then refer to that file system. The relationship is: DOSDriver / MountList↓uses a device↓uses a file system↓mounts the volume 

Safe beginner workflow for new drivers 

A safe workflow is: 
Make a backup or VM snapshot first.
Read the included documentation.
Copy optional mount files first to Storage:DOSDrivers.
Test manually with Mount.
If the device works, copy the mount file to DEVS:DOSDrivers.
Reboot and check whether the system still starts correctly.
Keep notes about which files were copied where.

This is especially important for beginners because wrong drivers or wrong mount entries can prevent normal startup. 

Common problems after installing drivers 

Device does not appear Possible causes: 
wrong driver version
driver copied to the wrong drawer
missing library
missing class
wrong unit number
wrong DOSDriver or MountList settings

System hangs or slows during boot Possible causes: 
bad entry in DEVS:DOSDrivers
driver tries to access hardware that is not present
incompatible driver
wrong controller or unit number

Program says a library is missing Possible causes: 
required file not copied to Libs:
wrong version of the library
library name is case-sensitive or expected exactly
Screen mode disappears or becomes unusable Possible causes: wrong monitor driver
unsupported graphics mode
incompatible display setup

Important beginner warning 

Beginners should be careful when copying files directly into system drawers such as: 
DEVS:
Libs:
Classes:
C:
S: 

A wrong file in the wrong place can cause confusing errors. In a VM, it is best to create a snapshot before experimenting with drivers. 

Short summary 

Drivers in AROS are integrated through Amiga-like system drawers and assigns. DEVS: is the main place for device drivers and device-related configuration. A MountList or DOSDriver tells AROS how to mount a device or volume. Files in DEVS:DOSDrivers are usually active or mounted automatically, while files in Storage:DOSDrivers are often kept available but inactive. New drivers are usually installed by copying driver files, libraries, classes, commands, and mount files into the correct drawers, then testing them manually or after reboot.

Explaining Mountlist entry

A MountList entry in AROS is a small configuration block that tells the system how to make a device or volume available. It is used by the Mount command or by startup scripts to activate disks, partitions, CD drives, removable media, or other DOS-style devices.

Basic idea 

A MountList entry answers questions like:
What should the new volume/device be called?
Which hardware driver should be used?
Which unit of that driver should be accessed?
Which file system should read the data?
How large are the blocks?
How many buffers should be used?
Is the device removable?
What startup options are required?

In simple form: 

MountList entry↓
Mount command reads it↓
AROS loads the device driver↓
AROS loads the file system 
if needed↓A volume such as CD0:, Work:, or USB0: becomes usable 

Example of a typical MountList-style entry 

A simplified example may look like this: 
CD0:    Device      = cdrom.device    
Unit        = 0    
FileSystem  = L:CDFileSystem    
Flags       = 0    
Surfaces    = 1    
BlocksPerTrack = 1    
BlockSize   = 2048    
Reserved    = 0    
LowCyl      = 0    
HighCyl     = 0    
Buffers     = 20    
BufMemType  = 1    
StackSize   = 4096    
Priority    = 5    
GlobVec     = -1    
DosType     = 0x43443031    
Activate    = 1
# 

This is only an illustrative example. Real entries can differ depending on the AROS version, hardware, driver, and distribution. Line-by-line explanation 

CD0: 

This is the name of the device or volume that will appear in the system. For example: CD0: means the mounted device may be accessed as: CD0: Other examples could be: USB0: Work: PC0: 

#Device = cdrom.device 

This tells AROS which device driver to use. Examples: Device = ata.deviceDevice = cdrom.deviceDevice = trackdisk.device The device driver is usually stored somewhere in the system, often related to DEVS: or built into the system, depending on the driver.

Unit = 0 

The unit number selects which device on that driver should be used. For example: Unit = 0 usually means the first device handled by that driver. If the same driver controls several disks or drives, another entry might use: Unit = 1 or: Unit = 2 

FileSystem = L:CDFileSystem 

This tells AROS which file system handler should interpret the data. 

Examples: 
FileSystem = L:CDFileSystem
FileSystem = L:FastFileSystem

For a CD-ROM, a CD file system is needed.
For a hard disk partition, a disk file system is needed. 

Flags = 0 

Flags are low-level options passed to the device or file system. For beginners, this is usually left unchanged unless the documentation says otherwise. 

Surfaces, BlocksPerTrack, LowCyl, HighCyl 

These values describe disk geometry or a logical view of the device. They come from classic Amiga-style disk configuration. On modern or virtual systems, they may be less intuitive, but they can still appear in mount definitions. Surfaces describes disk sides/heads. BlocksPerTrack describes blocks per track. LowCyl and HighCyl define the cylinder range.

For beginners: do not change these unless you know exactly what the driver expects. BlockSize = 2048 This defines the size of one block in bytes. 

Typical examples: 
512 for many disk-style devices
2048 for CD-ROM sectors

Wrong block size can prevent the device from being read correctly. 

Reserved = 0 

This defines reserved blocks at the beginning of the device or partition. It is normally driver/file-system specific. 

Buffers = 20 

Buffers are memory areas used to cache disk data. More buffers can improve performance, but they also use more memory. For a beginner setup, the default value from the supplied DOSDriver or MountList should usually be kept. 

BufMemType = 1 

This defines what kind of memory should be used for buffers. On classic Amiga systems this could matter a lot because of different memory types. In AROS, it is still part of the Amiga-like configuration model. 

StackSize = 4096 This sets the stack size for the file system or handler process. If the stack is too small, a handler may crash or behave incorrectly. If unsure, keep the value provided by the driver or distribution. 

Priority = 5 

This sets the task priority of the handler. Higher priority means the handler may get CPU time sooner, but wrong values can affect system responsiveness. For beginners: keep the default. 

GlobVec = -1 

This is a compatibility-related value from AmigaOS-style system design. For most modern AROS use, beginners should not change it. 

DosType = 0x43443031 

DosType identifies the file system or disk type. For example, a CD file system may use a specific hexadecimal identifier. This helps the system understand what kind of volume it is dealing with. 

Activate = 1 

This tells the system whether the device should become active when mounted. If set to 1, it is normally activated automatically after mounting. 

# 

The hash symbol marks the end of the MountList entry. DOSDriver files versus MountList entries 

In many Amiga-like systems, a MountList can contain several entries in one file. A DOSDriver is often one mount entry stored as its own file. 

Example: DEVS:DOSDrivers/CD0 may contain one MountList-style entry for CD0:. 

The practical difference: FormMeaning 

MountList One file with one or more mount definitions
DOSDriver One file that usually defines one device 
DEVS:DOSDrivers Devices here may be mounted automatically at startup 
Storage:DOSDrivers Devices here are available but usually not auto-mounted 

How it is used 

To mount a DOSDriver manually, you may type: Mount CD0: or sometimes: Mount DEVS:DOSDrivers/CD0 
If the file is placed in: DEVS:DOSDrivers it may be mounted automatically during startup, often by a line such as: Mount DEVS:DOSDrivers/~(#?.info) This means: mount the DOSDriver files in that drawer, but ignore .info icon files. 

Beginner warning MountList entries are powerful but sensitive. 

A wrong value can cause: 
the device not appearing
read/write errors
long delays during boot
system freezes while trying to access missing hardware
wrong file system detection

For beginners, the safest workflow is: 
Keep the original DOSDriver or MountList as backup.
Test new entries from Storage:DOSDrivers first.
Mount manually with Mount.
If it works, copy it to DEVS:DOSDrivers.
In a VM, make a snapshot before experimenting.

Short summary A MountList entry in AROS is a device description. It tells AROS which device driver, unit, file system, block size, buffers, and options are needed to make a device available. Modern AROS setups often use separate DOSDriver files instead of one large MountList. Files in DEVS:DOSDrivers are usually active or mounted automatically, while files in Storage:DOSDrivers are kept available for manual use.