text:
Oberon/ETH Oberon/betadocu

Introduction to ETH Oberon / PC Native alpha and beta release Download by anonymous FTP from: ftp://ftp.ethoberon.ethz.ch/ETHOberon/Native/Update/

Introduction

File system concept

Comparison of the Oberon file systems

File systems in the beta version

Partition management with Oberon

Disk image file

Partitions viewed by Linux-based Oberon

Oberon file system and foreign file systems

Multiple Oberon partitions on a machine

Oberon installation and installation updating

Configuration strings

Reconfiguring Oberon on start up

Backup / Restore methods

Archives

Beta version specialities

Bibliography

Introduction This document is being revised as new versions of the PC Native Oberon system are being produced. The objective is to detail some of the important issues which can contribute to overcome possible installation problems encountered by new users and to explain how this operating system can coexist with other OSs. Contributions are always welcome. The installation procedure consists of a few interaction steps after booting the Oberon-0 boot diskette and need not be described in more details here. Many of the Oberon commands presented are effectively used during an Oberon installation but it is by no means indispensable to master the entire instrumentation to conduct a successful installation. The installation procedure makes use of only a small subset of all what is presented here.

Note 1: The first beta version appeared on 20.03.2000 and was updated on 25.04.2000, 26.05.2000 and finally on 08.12.2000. In addition, an alpha version, including several changes and extensions, was made available on 13.05.2001 and is being updated regularly since then. The respective Beta version and Alpha version change logs contain detailed chronological accounts of the modifications made up-to-now. This document places the accent on the alpha version, while the beta version specialities are relegated in separate sections. Readers using the beta version will notice a few major differences but will also get a preview of what the alpha version will bring, if they are tempted to upgrade from their current beta to alpha.

Note 2: To determine which version you are currently using, look at the date on the second line in the log, just after booting your system. If you have other Oberon partitions (type 76) on your machine, with an installed Oberon OS, look for the date in Kernel.Obj.

If you have further questions, read the FAQ dedicated to this alpha/beta version. To find out whether your machine can host Native Oberon or not, consult the Hardware Compatibility List.

This version of ETH Native Oberon introduces a new file system concept, a new generic driver concept, a number of new features and numerous improvements and corrections of the previous release. File system concept The new partition management applies to all kinds of mass storage devices: hard disks, storage devices with removable media like diskettes, ZIP disks and CD-ROMs, etc. This does not apply to ZIP drives attached to the parallel port. Most mass storage devices may host more than one partition, ZIP disks in principle too, but not diskettes. Oberon can produce ample information on all the existing partitions and free space in a computer system. All the devices will show up under the generic name "Disk" in displayed information as in this short example:

Disk: IDE0, 8063MB = 16514064 * 512, CHS: 16383*16*63, Maxtor 90845D4, mntcnt=1 IDE0#00         0  16514064  8063MB --- (Whole disk) IDE0#01        63    819252   400MB   6 * DOS FAT16 >= 32M IDE0#02    819315   4176900  2039MB   6 DOS FAT16 >= 32M ... Disk: Diskette0, 1440KB = 2880 * 512, removable, CHS: 80*2*18, mntcnt=1 Diskette0#00         0      2880   1.4MB --- (Whole disk) [mounted]

Each partition can host a file system of which there are more than operating systems. With its new generic file system support, an active Oberon has access to the data of co-resident partitions hosting a supported file system (FS). The supported file systems are listed in the OFS.Alias section of Oberon.Text. They are:

 * AosFS - the (new) FS of the alpha / beta version of Oberon
 * NatFS - the PC Native Oberon FS used in earlier releases; the last one was release 2.3.6. The name stemms from "Native File System".
 * RamFS - the Oberon internal RAM FS residing in main storage, thus outside of the device / partition hierarchy and which must not be formatted. It is provided as a user convenience for storing temporary data that will be purged when Oberon is terminated.
 * FatFS - the DOS and Windows FAT FSs; that is, FAT12, FAT16 and FAT32. With the support of the various kinds of classical FSs, it becomes possible to exchange files between those FSs and Oberon and to access and manipulate files directly in them, amounting to performing Windows tasks in Oberon. Long filenames are supported. Use quotes to specify filenames containing spaces or characters that are not valid in Oberon names.

CAUTION: As always, before testing a new FS implementation, make sure that you do not risk corrupting a critical FAT partition. Exchanging files with a FAT-formatted diskette is safer.

These file systems perform anonymous file garbage collection on-the-fly. Previously, file GC was performed only when Oberon was started.

 * FileFS - the FS of an Oberon hosted in a FatFS. The possibility to install an "Oberon in a file of a FatFS" was provided for those not wanting to create a partition for the sole purpose of trying out the Oberon system. A good example is the "Oberon for Dummies" included on the CD-ROM which comes with the book "Beginning Programming For Dummies, 2nd Edition". In the early days of Native Oberon, this was known as "DOSBased Native Oberon". An Oberon system installed in a dedicated partition can access another Oberon in a file.
 * ISOFS - the ISO 9660 FS found on CD-ROMs
 * LinuxFS - the Linux FS. This FS can be accessed only from a Linux-based Oberon

Access to a file system is obtained by mounting it with the OFSTools.Mount command described later. It is essential that the file system declared in the command parameter matches the file system residing on the partition.

Each file system is characterized by a number of states:

 * Boot: the FS was automatically mounted at boot time. State revealed by OFSTools.Watch and by Partitions.Show detail
 * Removable: the FS is hosted on a removable disk.State revealed by Partitions.Show
 * ReadOnly: only read access is allowed on the FS. Controlled by the OFSTools.Mount command. State revealed by OFSTools.Watch

Case sensitivity in AosFS filenames is consistent with case sensitivity in the Oberon language. The maximum file size is now 2 GB and the maximum volume and partition size have been increased to 282 GB.

[Top]

Comparison of the Oberon file systems The Oberon file system has only slightly evolved since its inception and the figures in the following tables essentially reflect the trend toward larger capacity media, both mass storage devices and RAM. The information given is extracted from "Project Oberon" (Chapter 7) [WG92] and adapted to the two Native Oberon file systems for which the exact figures were obtained from the source modules. We refer to the Project Oberon file system as CeresFS.

The implementation of files on a random-access store

The scheme chosen in Oberon favors short files (< 64KB) but to keep the on-disk structure small yet still allow large files, each file header conforms to the following schema:

 * the NatFS and CeresFS contain a sector table of 64 direct entries, each pointing to a data sector, and an extension table of 12 single indirect entries, each pointing to an index sector of direct data sector pointers.
 * the AosFS uses a sector table of 128 direct entries, each pointing to a data sector, and one double indirect entry pointing to a list of 1'024 index sectors, providing a total of 1'024 ^ 2 index entries.

   FS    Sector Sector Extens. Index  Header     Max. file size table  table    size     size          size (bytes) size   size           (bytes)      (bytes) AosFS   4'096    128     1  1'048'576    568  4'295'491'016 NatFS   2'048     64    12        512    352     12'713'632 CeresFS 1'024     64    12        256    352      3'210'912

The first data sector pointer points itself, the sector containing the header. The on-disk structure is similar to the internal organization of Unix files [Bac86].

Sector pointers are represented by sector numbers of type LONGINT. Actually, the numbers are multiplied by 29, the sector factor. This implies that any single-bit error leads to a number that is not a multiple of 29, and hence can easily be detected. The Scavenger program takes profit of this.

The file directory

The Oberon system uses a B-tree structure with the following characteristics for its file directory:

 * 1) In a B-tree of order N, each node (called page) contains m elements (pairs), where N <= m <= 2N, except the root, where 0 <= m <= 2N.
 * 2) A page with m elements has either 0 descendants, in which case it is called a leaf page, or m+1 descendants.
 * 3) All leaf pages are on the same (bottom) level.

On a page, space must be available for 2N elements and for N + 1 references to descendants. Hence N is immediately determined by the size of a page and the size of elements. In the case of Oberon, names are limited to 32 characters (bytes), and the object is a reference to the associated file (4 bytes). Each descendant pointer takes 4 bytes, and the page size is given by the sector size (SZ) minus the number of bytes needed to store m (2 bytes). Hence N = ((SZ - 2 - 4) DIV (32 + 4 + 4)) DIV 2

    FS       SZ     N   DirPgSize AosFS    4096   51      102 NatFS    2048   25       50 CeresFS  1024   12       24

The number of directory entries stored in the tree depends on the tree height. The maximum number is given by the expression: MaxElems = 2*N * SUM(i:=0..Height-1, (2*N+1)^i)

          Height   1        2         3         4 FS   AosFS          102    10'608 1'092'726  2.145 E+09 NatFS          50     2'600   132'650   6'765'200 CeresFS        24       624    15'624     390'624

Inside the directory page, a binary search among the elements is used (there are between N and 2*N elements in a page). Hence assuming you have more than 10608 files in an AosFS, the tree will have an height of 3 (3 directory pages are accessed in the worst case) and a maximum of 3 * 2LOG(102) = 20 comparisons are needed (this is small compared to the disk access time). Besides that, caching can make accesses faster (usually the root page of the file directory stays in the cache).

AosFS limit values

The maximum file size is 4.0GB because of its triple index structure, but its is effectively limited to 2.0GB because of the 31 bit value for Set and Pos parameters.

The maximum volume size or partition size is 282.48 GB, because BIOS imposes a limit of: 1'024 cylinders * 256 heads * 63 sectors = 16'515'072 physical sectors to divide by the sector factor (29) resulting in 569485 physical sectors of 512 bytes.

A typical workable Oberon partition for a full system starts at about 40MB. Cfr. ShowAosFSLimits

[Top]

File systems in the Beta version Users of a Beta version, dating back to 08.12.2000 or earlier, must be aware that some of the FSs have somewhat different characteristics and that file manipulations in these FSs are performed in a different manner. As one can imagine, the FSs of the Alpha version described in the previous section are more generic, and this should motivate an upgrade to the Alpha version (which will eventually become the next Beta version).

 * DosBasedFS - the FS of an Oberon in a file (in a FAT16 partition). The facility to install Oberon in a large file of an existing FAT partition was re-introduced (beta001208) after a period of absence. Not needed anymore in the Alpha version.
 * FileFS - the FS of an Oberon in a file copied to Oberon (from its FAT16 partition). This facility was introduced as a palliative while the DOSBasedFS was missing (in beta versions issued prior to 08.12.2000). Its interest is limited in the Beta version.

[Top] Partition management with Oberon The Partitions module offers a rather complete palette of partition management functions, so that it becomes possible to install a newer version using an existing Oberon system without the assistance of another operating system. Most commands addressing a partition can operate on a partition of an arbitrary type. A few operate only on Oberon partitions: Format, UpdateBootFile, GetConfig, SetConfig.

A partition is addressed as "dev#part" where dev is the physical device designator such as IDE0, IDE1, Diskette0 (for the A drive) or Diskette1 (for drive B), and part is the sequence number of a partition on the device. Oberon collects the partition information from the partition table located in the first sectors of a device. A summary of the disk partitioning is displayed by executing Partitions.Show.

Partitions.Show ["detail"] ~
 * Displays a summary of the partitioning of all the mass storage devices for which a driver is installed: hard disks and storage devices with removable media like diskettes, ZIP disks and CD-ROMs. By default, a minimum of information is displayed but details are added when the parameter detail is specified. The amount of free space is also displayed for use with Partitions.Create.

 * Example Partitions.Show detail ~:

 Disk: IDE0, 8063MB = 16514064 * 512, CHS: 16383*16*63, Maxtor 90845D4, mntcnt=1 IDE0#00         0  16514064  8063MB --- (Whole disk) IDE0#01        63    819252   400MB   6 * DOS FAT16 >= 32M IDE0#02    819315   4176900  2039MB   6 DOS FAT16 >= 32M IDE0#03   4996215    401625   196MB  79 Native Oberon or QNX Posix IDE0#04   5397840  11036655  5388MB   5 Extended IDE0#05   5397903    401562   196MB  76 |Native Oberon, Aos [mounted] IDE0#06   5799528   2056257  1004MB 131 |Linux fs     ...

Disk: Diskette0, 1440KB = 2880 * 512, removable, CHS: 80*2*18, mntcnt=1 Diskette0#00         0      2880   1.4MB --- (Whole disk) [mounted]

 * The first line describes the disk:

 * type (IDE, SCSI, Diskette, ...) and position on the controller, e.g. SCSI0.0

 * size in MB

 * CHS is followed by the numbers for cylinders*heads*sectors. For a drive using LBA, the report will be "CHS: unsupported". Most ATA and SCSI drives use LBA. Some ATA drives supported both forms of addressing.

 * manufacturer and model

 * the number of times mounted mntcnt

 * In the example, Partition 0 is a virtual partition that spans the whole disk. Devices that do not have a partition table, like a diskette or a CD, have only a partition 0. The disk name of the first diskette drive is "Diskette0" and the partition's name is "Diskette0#00". A ZIP disk can, in principle, have several partitions, as it can feature a partition table.

 * Each subsequent line informs on the location, size and type of a partition or free space. The data is, for a part, extracted from the partition table located in the MBR.

 * Each partition is assigned a partition type (see column 5 in the example) which identifies the file system contained in the partition. The partition type of the ETH Native Oberon is "76" (decimal) (partition hosting the new AosFS). More than one partition with partition type "76" may exist on a machine. That is not the case for the previous Native Oberon which uses partition type "79" and distinct other values for further partitions. The file system used there is named "NatFS".

 * An active partition (see Partitions.Activate), is marked with an "*".

 * Depending on the installed hardware, the partition table is displayed after an appreciable time lapse. As an indication, it may take up to 10 seconds to scan and collect the information for a ATA/IDE device. This delay is well noticeable on older computers.

Partitions.ChangeType dev#part from to ~
 * Changes the partition type of the specified partition from the current type (e.g. "6" for a DOS partition) to the new type (e.g. "76" for an AosFS). After that, a file system must be established with Partitions.Format . Use after creating a partition with another OS, or for reusing an existing free partition.

 * Note that changing the partition type makes it unaccessible to other operating systems! If you accidentally change the type of the wrong partition, you can always change it back, provided you have not made other changes to it in the mean time.

Partitions.Format dev#part [ AosFS | NatFS [ FSRes [ BootFile]]] ~

Partitions.Format ^
 * Writes an empty file system on the designated partition, destroying any other existing file system. However, if an Oberon FS is detected and the system is operating in SAFE mode, the command is aborted and a warning is issued. Execute Partitions.Unsafe ~ (it appears in the system log) to authorize formatting. The second parameter is the file system type that will be adopted for the partition. AosFS is used by default, which legitimates the second command form. A partition must be formatted before it can be mounted.

 * The BootFile is the "kernel" of Aos. The file contains a statically linked image of the basic modules of the active object runtime, the dynamic module loader, at least one file system and at least one disk driver. This makes the partition bootable. BootFile is "Native.Bin" by default. FSRes is the amount of space that must be reserved for hosting the data. By default, 512 KB are reserved. Later on, after the partition was created, if the boot loader must be updated without a need of formatting the partition, you must use the command Partitions.UpdateBootFile. Currently, Native.Bin is missing and a warning is issued informing that the partition is not bootable. Boot your machine using the Oberon0 diskette to perform a partial installation or an installation update to access Native.Bin.

 * If a diskette is to be used solely as backup medium, set FSRes to 1 (0 will not be accepted) since the default value would amputate most of the available space.

 * A Partitions.Check command is executed implicitly. If the partition has been checked before, the check process can be safely interrupted by pressing the spacebar. This will speed up the format operation.

Partitions.Safe ~

Partitions.Unsafe ~
 * Partitions.UnSafe enables unsafe commands and issues a warning "Now in UNSAFE mode!" in the System.Log. Partitions.Safe disables unsafe commands. Partitions.Format is unsafe. Unsafe commands are disabled by default.

Partitions.UpdateBootFile dev#part [ BootFile ] ~
 * Updates the boot loader in an existing Oberon partition. This is necessary if you re-install Oberon in the same partition, or if you move a partition, with one of the many commercial tools available for that purpose, or if you upgrade an existing partition. BootFile is "Native.Bin" by default.

Partitions.Check dev#part

Partitions.Check ^
 * Checks the sectors of the specified partition, of any type, for readability and reports the outcome in the System.Log. This long-running command can be safely interrupted by pressing the spacebar.

Partitions.GetConfig dev#part ~

Partitions.GetConfig ^

Partitions.SetConfig dev#part { str = "val" } ~
 * The execution of GetConfig displays in the System.Log a valid, executable Partitions.SetConfig command enumerating all the configuration strings defined for the specified Oberon partition, provided the partition is bootable. If necessary, the configuration can be immediately edited in the log and written back to disk (or diskette) by activating that command. There is practically no need to construct a SetConfig command from scratch. The parameters are far too numerous to detail. The amount of information will depend on the release used, as it is progressively improved and extended. Obviously, these commands may only address an Oberon partition, which is susceptible to contain configuration data. The partition was possibly booted from a diskette, in which case, the relevant information is obtained by executing: Partitions.GetConfig Diskette0#0 ~

 * The configuration strings are used when Oberon is started by the boot loader and they can be also modified at that time.

 * Limitation: This command can only be addressed to a partition on a device using 512-byte blocks. A CD-ROM uses 2'048-byte blocks for example and a TRAP would be induced. The config strings can be inspected and modified only at start time.

 * Practical hint: during an Oberon installation, one has interest to execute Config.BootPartition menu ~ always, even when a boot diskette is going to be created. In case the diskette gets lost or damaged, create a new diskette quickly, leaving out the configuration part, and to recover the configuration, execute Partitions.GetConfig dev#part followed by Partitions.SetConfig Diskette0#0. In certain circumstances, it may be difficult to decide which display driver was selected initially.

 * Technical hint: The configuration data is stored in sectors 4 to 7 of the partition - cfr. Partitions.ShowBlocks command below.

Partitions.FileToPartition dev#part filename [block blocks] ~
 * Block copies a disk image file to the specified partition, of any type. block is the starting block number in the partition (this offset value starts at 0). blocks is the number of blocks to copy. Execute Partitions.Show detail to obtain the latter value. When the parameters are omitted, the entire partition is restored. It is strongly recommended to roll back the image file to a partition of the same size as the original one.

 * In particular, Partitions.FileToPartition Diskette0#0 Oberon0.Dsk ~ is used during an Oberon installation to create an Oberon-0 boot diskette from the disk image file Oberon0.Dsk.

 * Note: In versions prior to 13.05.2001, the syntax was: Partitions.PartitionFileTo dev#part filename [blocks] ~ which meant: write the first blocks to the partition.

Partitions.PartitionToFile dev#part filename [block blocks] ~
 * Block copies the specified partition, of any type, to the named disk image file which is then saved for backup purpose. block is the starting block number in the partition (this offset value starts at 0). blocks is the number of blocks to copy. Execute Partitions.Show detail to obtain the latter value. If block # 0, a negative blocks value will cause the remaining number of blocks (blocks - block) to be copied. When the parameters are omitted, the entire partition is saved/backed up.

 * The MBR of a disk can be saved to a file (MBR.Bin) by executing Partitions.PartitionToFile dev#0 MBR.Bin 0 1 ~

 * Note: In versions prior to 13.05.2001, the syntax was: Partitions.PartitionToFile dev#part filename [blocks] ~ which meant: write the first blocks of the partition.

Partitions.WriteMBR dev#0 filename ~
 * Write the MBR to the specified disk (be careful). The MBR data is read from the named file and the program verifies that the data contains a valid MBR signature "55 AA" at the end. The MBR may have been previously saved, with Partitions.PartitionToFile for example. The data in the file is best examined with Hex.Open.

 * Hint: This command must be considered as a technical utility, also paired with Partitions.FileToPartition. It can be used with any operating system and is useful to remove or to write a LILO boot record for instance. This command is not equivalent to Partitions.FileToPartition dev#part filename 0 1 ~ !!!

 * It writes only the boot loader code, the first 446 bytes, in the MBR, leaving the partition table unchanged. It is the equivalent of the DOS command fdisk /mbr . On the contrary, Partitions.FileToPartition not only writes the boot loader in the MBR, it also writes the partition table, which can be harmful.

 * Cfr. How It Works - PartitionTables.

Partitions.ShowBlocks dev#part block [blocks] ~
 * Displays arbitrary disk blocks, of a partition of any type, in hex. E.g. Partitions.ShowBlocks IDE1#0 0 1 ~ displays the MBR on the primary IDE slave disk.

 * Troubleshooting a boot problem with this command

 * If your Oberon system does not start properly and simply stalls and displays "OBE", the Native boot loader does not find the second sector. Execute: Partitions.ShowBlocks IDE0#02 0 8 ~ to write the first 8 sectors of the partition. Sector 0 (the first sector) should have "OBERON" close to the start, and 2-byte signature "55 AA" at the end. Sector 1 must have two AA 55 bytes at the start. Example:

 IDE0#02 0 00000000 EB 29 90 4F 42 45 52 4F 4E 00 00 00 02 02 08 00 .).OBERON.......      00000010 04 E0 00 00 00 F0 09 00 3F 00 40 00 40 23 03 00 ........?.@.@#..       00000020 C0 90 0F 00 80 00 00 03 00 00 00 FA EA 31 00 C0 .............1..       ...       000001F0 72 72 6F 72 21 07 00 6F 62 65 72 6F 6E 00 55 AA rror!..oberon.U.       IDE0#02 1       00000000 AA 55 66 A1 1C 00 66 A3 06 07 BB 00 08 B9 04 00 .Uf...f.........

 * It is important that the four bytes at offset 1CH in sector 0 designate the sector number of the boot sector. In the example: 40 23 03 00 (reversed in little-endian order) -> 00032340H = 205632 decimal

 * The last value must match what appears in the first column for the partition after executing Partitions.Show detail ~

 IDE0#02    205632   1020096   498MB  79 Native Oberon or QNX Posix [mounted]

 * Another thing to check is that the byte at offset 24H is the boot drive number (80H in the example). This should be 0 for diskette A:, 80H for the first BIOS disk drive, 81H for the second BIOS disk drive, etc. In practice, the rule is relaxed since the software will accept either 81H or 80H.

 * Your configuration should be visible from sector 4 to 7 (or it could be all zero if you always boot via noboot.exe).

Partitions.Activate dev#part ~

Partitions.Activate ^

Partitions.Deactivate dev#part ~

Partitions.Deactivate ^
 * Activates / deactivates the specified partition, of any type; that is, sets/resets the "active" marker of a primary partition (see "partition entry" in the partition table). In the list obtained with Partitions.Show ~, an active partition is marked with an "*". When no boot manager is installed, the active partition located on the first disk drive is automatically booted. This is true provided the partition hosts an operating and, for Oberon in addition, that the configuration strings have been written in it, during the installation or later.

 * The "active" marker has no meaning when:
 * an Oberon partition is booted with a bootable diskette, created during the installation or later.
 * a boot manager is used.
 * In both cases, any partition, primary partition or logical drive in an extended partition can be booted.

 * Active partition on a disk drive other than the first one: It can be booted too if the machine System Setup allows to change the boot sequence.

 * More than one active partition: The normal case is to allow only one active partition on a disk. If more than one is active, as can easily be achieved, it is expected that the first one found in the physical order is booted, but that can depend on the MBR code. One boot manager (?) was observed which did present a menu with the active partitions.

Partitions.Create dev#part sizeMB
 * Creates an Oberon primary partition (type AosFS = 76) of the specified size which will remain unformatted, except for the first sector which is filled with 0F6X. It cannot create a logical drive in an extended partition. Execution is possible only under the condition that no partition is mounted on the host device; that is, using Oberon-0 or using an installed Oberon but on another device with no partition mounted. Cfr. OFSTools.Unmount: the FS which is automatically mounted at boot time cannot be unmounted. The program verifies that the MBR is valid, i.e. has a "55 AA" signature at the end. This is only important to remember when a low-level formatted empty disk is installed. A valid MBR must then be written first. (* Not in Beta *)

Partitions.Delete dev#part type
 * Deletes a primary partition of the specified type. It was decided to have the user specify this, as it is more robust. Execution is possible only under the condition that no partition is mounted on the host device; that is, using Oberon-0 or using an installed Oberon but on another device with no partition mounted. Warning: The partition is unrecoverable! (* Not in Beta *)

Partitions.ShowAosFSLimits ~
 * Displays the AosFS limits in the System.Log.

'''Partitions.Eject dev#part Partitions.Eject ^'''
 * Eject the media from the selected device. (* Not in Beta *)

[Top]

Disk image file Cloning is the process of duplicating an installed operating system from one reference computer to one or more other computers. It consists in backing up all the data stored on the partitions of the reference computer and in restoring that data on a target computer. Cloning is used extensively at the ETH for installing the computer laboratories.

Oberon implements a simple sector-based cloning method in a pair of commands Partitions.PartitionToFile and Partitions.FileToPartition for cloning a single partition. The sectors of a partitions are copied to and from the intermediate file without knowledge of the underlying file system structure. The intermediate file is usually called a disk image file, or simply disk image. The advantage of the method is that it can not only be used for an Oberon partition but also for any existing operating system.

Usually, a disk image will reside on a server. For example, Oberon0.Dsk is a disk image, more precisely a diskette image, which resides on the ETH ftp server ftp://ftp.ethoberon.ethz.ch/ETHOberon/Native/[expired].

Cloning is also useful for moving a partition to another on the same or another disk on the same computer. Keep in mind that a third partition must offer enough free space for storing the disk image. Given that an Oberon partition is normally no larger that 50MB, this kind of cloning can be considered realistic and practicable too because it is fast. Partitions of other OSs are usually much larger and finding enough free space is probably out of question. Cloning is not apt to resize a partition - cfr. command OFSTools.GenCopyFiles.

Oberon0.Dsk

This image file is at the base of the installation or update of each Oberon system. With it and with the Partitions.FileToPartition command, an Oberon-0 boot diskette is created. Booting from this diskette, starts Oberon-0 which is a small ramdisk-based system for configuring and installing a real, full-fledged Oberon system. This boot diskette is a good example of Oberon system on a diskette.

The image file is created by a process completely described in the section "Installation diskette" in Native.Tool.

Oberon utility diskette

The Oberon Utility Disk is another example of Oberon system on a diskette. The image file is created by a process completely described in the section "Utility diskette" in Native.Tool.

Disk image format

A disk image can also be processed by other popular disk image programs. For example, the Oberon-0 boot diskette can also be created with:

 * the DOS program rawrite.exe or the DOS version of the OS/2 loaddskf

 * the Linux, Unix or BeOS program dd

 * the OS/2 program loaddskf

[Top] Partitions viewed by Linux-based Oberon Linux-based Native Oberon is an emulation of Native Oberon for Linux. The goal is not a tight integration in the Linux environment but binary compatibility with Native Oberon. This implementation does not change the module interfaces but partitions are viewed differently. This is due to the fact that Linux Oberon is installed in a LinuxFS file.

Partitions.Show [detail]
 * Displays a table of virtual partitions. When a Linux-based Oberon is started, the hosting file (default name: oberon.dsk) is viewed as a mounted virtual partition. To access a real Native Oberon partition execute:

 * Linux.OpenDisk path
 * Gives access to a Native Oberon (AosFS or NatFS) partition. path is its Linux identifier, e.g. /dev/hdb1. The partition will be viewed as virtual and its file system can then be mounted.

 * Example Partitions.Show detail ~:

 Disk: oberon.dsk / 61438 * 512 = 29MB / GetCHS: unsupported / mntcnt=1 oberon.dsk#00         0     61438    29MB --- (Whole Disk) / mounted Disk: Diskette0 / removable / GetSize: no media / mntcnt=0

Partitions.Check path

Partitions.Check ^
 * Same meaning as for Native Oberon.

All the remaining Partitions commands are not applicable in that context. The configuration is not changed with Partitions.SetConfig but by editing oberon.cnf.

Like in Native Oberon, a file system must be mounted prior to accessing it. You can mount a LinuxFS or a Native Oberon partition accessed with Linux.OpenDisk.

[Top] Oberon file system and foreign file systems File names are prefixed with a name identifying a specific mounted file system, as for example SYS, the prefix of the file system from which the system is booted (default prefix).

Example: The full filename of Oberon.Text on a newly installed system is SYS:Oberon.Text.

A NamePlate gadget displays the filename at the beginning and the prefix (or directory) at the end, so that the filename is always visible. The prefix may be hidden when the filename is long. A MM click on a NamePlate causes the full name to be displayed in the System.Log.

An Oberon system can access not only the data of its own file system type AosFS but also data in other Oberon partitions and foreign file systems. Access to other file systems is controlled by the commands of the OFSTools module.

OFSTools.Mount prefix [hashSize] [cachesize] alias (dev#part [",R"] [",X"]] | params ~ | ^ ) ~
 * Mounts a file system. The first parameter is the prefix under which the file system must be mounted. The prefix is determined at mount time; that is, it is not permanent. After mount, the prefix part of a name is used to find the correct file system, and the part after the prefix is passed on to the file system to interpret. It is not possible to have the same prefix for different partitions/volumes. The order in which multiple file systems are mounted is the order in which they are searched. The order can be changed with OFSTools.SetDefault and is revealed by OFSTools.Watch.

 * Example: OFSTools.Mount AOS AosFS IDE2#5 ~

 * After execution, a file "My.Text" residing in IDE2#5, the fifth partition on device IDE2, will be accessible with the name "AOS:My.Text".

 * The second and the third parameters are cache specifications. No cache is installed by default. Cfr. OFSTools.InstallCache command.

 * The fourth parameter is the file system type expected on the partition (AosFS in the example). The valid types are listed in the OFS.Alias section of Oberon.Text . Although it is conceivably possible for the system to work out the correct file system type to use, deducing it from the dev#part value, it was decided to have the user specify this, as it is more robust.

 * dev#part in the 5th parameter specifies the device and the partition to mount. It hosts either an AosFS, a NatFS or a FatFS file system. A FatFS may be a DOS or Windows FAT FSs; that is, FAT12, FAT16 and FAT32. Files can be exchanged between these FSs and that of an Oberon system using the familiar System.CopyFiles command. System.RenameFiles, System.DeleteFiles and System.Directory may be used too and files can be opened directly as usual. Further, the FAT.Tool allows access to the extended capabilities of the FAT file system that Oberon does not support, i.e. directories, file attributes, and so on. Also a DOS-formatted diskette or a ZIP disk can be mounted.

 * The optional ",R" parameter gives read-only access to the FS. For example, during the installation of a new Oberon system, you are invited to execute:
 * OFSTools.Mount SRC NatFS Diskette0,R ~
 * This gives read-only access to the mounted Oberon-0 diskette containing an archive of the Oberon modules to install. The diskette may be write-protected or not. Do not attempt to mount a write-protected diskette without specifying the ",R" parameter. A TRAP will occur.

 * Mounting a diskette causes the diskette LED to light and to stay lit until an Unmount command is issued. This should draw your attention because you must unmount the diskette before changing the medium.

 * The optional ",X" parameter is only for use when mounting a FatFS. This option forces the FAT driver to ignore the clean shutdown flag of the partition and to mount the partition for read and write. If the shutdown flag is not set, the partition is mounted read-only to prevent possible data corruption. This situation is reported in the Kernel log.

 * About the clean shutdown flag: The flag indicates that a partition was properly unmounted. If Oberon crashes, the flag will not be set for a partition which was mounted. It is a good idea to run a disk repair utility program, such as the MS-DOS Scandisk, on a FatFS: if Scandisk fixes an error, it sets the clean shutdown flag. If no error is detected, Scandisk does not set the flag, although it should.

 * params in the 5th parameter depends of the FS specified in alias, as is described below.

 * Practical hint: If you want a file system to be mounted when you start the system, you can place a Mount command in the System.InitCommands section of Oberon.Text.

 * RamFS size sectorsize ~
 * Mounts a file system residing in main storage, thus outside of the device / partition hierarchy and which need not be formatted. The RamFS parameter is followed by the size in sectors, followed by the sector size in bytes. This file system is provided as a user convenience for storing temporary data that will be purged when Oberon is terminated.

 * FileFS filename ~
 * Mounts an existing Oberon hosted in a file specified in the next parameter. Prior to this, the hosting FatFS must be mounted. This command variant makes it possible to exploit legacy data in former DOS-based Oberon systems.

 * Example:
 * OFSTools.Mount FAT FatFS IDE2#5 ~
 * followed by:
 * OFSTools.Mount DFS FileFS FAT:Oberon.Dsk ~

 * LinuxFS path ~ (Linux-based Oberon only)
 * Mounts a Linux file system found along the specified path. Refer to the special Linux section below.

 * Accessing the file system of an earlier Native Oberon release

 * First, use Partitions.Show to list all partitions, locate the target partition and select it. Then, execute:    ::OFSTools.Mount NAT NatFS ^

 * Accessing a Linux file system from Linux-based Oberon

 * In Linux, determine the path to the file system. e.g. /home/userid
 * In Linux Oberon, mount the file system with: OFSTools.Mount prefix LinuxFS path

 * Accessing a Native Oberon sub-system from a Linux-based Oberon

 * In Linux, execute fdisk to determine the partition's identifier, e.g. /dev/hda5
 * In Linux Oberon, access the partition as a virtual disk with: Linux.OpenDisk /dev/hda5 and mount the file system (NatFS or AosFS) with: OFSTools.Mount prefix filesys /dev/hda5

OFSTools.Unmount prefix

OFSTools.Unmount ^
 * Unmount the partition mounted earlier under the named prefix. The file system on the media is updated and if it resides on a removable media, the media may be removed. Do not remove a media before it is cleanly updated! When you shut down the system cleanly with System.Reboot, System.Quit or Ctrl-Alt-Del, the mounted file systems are automatically unmounted first.

 * Also take care not to unmount a file system before all viewers displaying documents residing on that file system are closed, otherwise you will induce a series of TRAPs.

 * Important: The FS which is automatically mounted at boot time cannot be unmounted. The status (boot) is revealed by OFSTools.Watch.

OFSTools.SetDefault prefix

OFSTools.SetDefault ^
 * Set the FS with the named prefix as first FS to access by default. The remaining mounted FSs are left in their current order. The new complete path is displayed in the System.Log. Example: Path: WRK SYS

 * Later on, the order of the FSs can still be verified by executing OFSTools.Watch or System.Watch.

 * The order of the mounted partitions is important. In the example, WRK comes first, and then comes SYS. This means that when you load a file without specifying a prefix, the system will search through all the mounted FSs in their order, until the file is found. For example, if you load a file called "My.Text", and the WRK FS does not include such a file, then a file in SYS will eventually be opened, if it exists.

 * In contrast, when storing a file without an explicit prefix, the file is always stored on the first file system (WRK: in this case). To avoid confusion, it is best to always specify a prefix when creating a new file. The TextDocs gadget helps by always displaying the complete filename, including the prefix, in the NamePlate.

 * To direct the placement of files, as for instance when compiling new .Obj files, you may choose between:

This is not recommended, as it affects all newly created prefix-less files.
 * Instruct the compiler to use a prefix (recommended):
 * Compiler.Compile \PUSR: {files} ~
 * Change the default file system with OFSTools.SetDefault

 * To display all files on a specific file system, select the line in the System.Watch display and execute System.Directory ^.

OFSTools.Watch
 * Lists the mounted file systems in their order, with their prefix, alias, partition id, size and amount of free space. (boot) indicates a file system automatically mounted at boot time. Cache performance information is displayed, if installed. A little more details are given compared to what System.Watch shows, but the latter command displays heap information in addition.

 * If free space is low, remember that there exists no direct Oberon tool to resize an Oberon partition. Cfr. Partition backup.

 * To give another example, a RAM-based system installed immediately after booting from an installation diskette Oberon-0:

 RAM: GCN2KFS on RAM0 (boot) 1072KB of 2048KB free

 * A 2MB RAM disk is created by default by Oberon-0. That means at least 3MB are needed for the installation. If needed, Oberon can run in less than 3 MB memory.

OFSTools.InstallCache prefix hashSize cacheSize ~
 * Installs a cache, of cacheSize blocks, for the FS with named prefix. 100 blocks give a good cache performance and takes about 200KB of memory. Use OFSTools.Watch to look at the cache performance. This command my not be used with a FatFS, since it uses a built-in data cache optimized for FAT.

OFSTools.RemoveCache prefix
 * Removes the cache installed for the FS with the named prefix. Does not apply to FatFS.

OFSTools.CopyTo dst src ( &file | { file [=> file ] } ) ~
 * Copies a bulk of files from the file system src to another dst. If a file system is the default one, it may be abbreviated as "". The two first parameters are followed:
 * either by the names of the files to copy. Optionally, each file can optionally be assigned a new name specified after "=4".
 * or by a single name prefixed with "&" which denotes an indirect list. The names of the files to copy are contained in the named file.

OFSTools.GenCopyFiles rem add ( "mask" | &file | { file [=> file] } ) ~
 * Generates a System.CopyFiles command which you can execute, after possibly editing it. The first two parameters specify prefixes. The third (and subsequent) parameters specify a list of files or a mask for selecting filenames. Every filename in the list is taken as source filename. The destination filename is generated as follows: the first parameter is a string to be removed from the filename's head; the second parameter is a string to affix to the trailing part.

 * The syntax is not too intuitive but the command is really powerful and useful for preparing a batch of filenames. The easiest way to see how the command works is to try it out. This is safe, as it does not have any effect itself, other than generating a text that you can review and execute.

 * Copy or resize a partition

 * Assume that valuable data is stored in SYS: and that BACKUP: is a free partition on a system. The power of the command OFSTools.GenCopyFiles SYS: BACKUP: "SYS:*" ~ is particularly impressive in these two usually non-trivial applications:

 * Backup a partition: A copy file by file captures the state of the system at a particular moment. One can then roll back the original system in the event of malfunctions caused by new software or the installation of new hardware. This is a easy technique for rolling back the system to a point where it worked properly.
 * Resize a partition: The copy process reorganizes automatically the files thus offering the possibilty to move the data to a smaller size partition, though the prime use will usually be for increasing the size.
 * Cloning offers the advantage that the image file can be ported to another system.

[Top] Multiple Oberon partitions on a machine Oberon can be installed in a primary partition or in a logical drive. Hence, more than four Oberon partitions may coexist on a single hard disk. But Oberon can also be installed on different hard disks, even of different type (EIDE, SCSI, USB). During the installation, you are invited to select a driver for the controller of the hard disk on which Oberon must be installed. Later on, when you decide to install Oberon on another disk, you must execute the relevant disk driver install command:
 * for an ATA/EIDE disk controller, execute ATADisks.Install ~ (takes about 5 seconds)
 * for an Adaptec 7xxx SCSI disk controller, execute Adaptec7.Install ~ (takes about 15 seconds)
 * for an NCR 810 SCSI disk controller, execute NCR810Disks.Install ~ (takes about 15 seconds)
 * for an NCR 810 SCSI disk controller, execute NCR810Disks.Install ~ (takes about 15 seconds)

This may also be done in the System.InitCommands section of Oberon.Text

Afterwards you will see the new devices in the Partitions.Show display. To see trace information displayed by these drivers, use System.OpenKernelLog.

Additional file systems

To create a new file system, you first have to create a partition by executing a Partitions.Create or a Partitions.ChangeType command. The next step is to format the partition with AosFS by executing a Partitions.Format command. After formatting the partition, mount it with an OFSTools.Mount command, e.g. with the parameters USR AosFS dev#part. If you want the file system to be mounted when you start the system, you can place this command in the System.InitCommands section of Oberon.Text. You can now access files on the new file system using names like: "USR:SomeFile".

You can also create Oberon file systems on removable media like diskettes and ZIP disks (driver available). In the case of removable media, you have to be careful to unmount the file system before removing the media again, to cleanly update the file system on the media. This is done using the OFSTools.Unmount command.

Suggestion for assigning partition prefixes

One should use a small number of partitions. The problem with having too many partitions is that they have to be preallocated, and one has to live with a bad allocation. If the SYS partition is too small to install a new release, what do you do? If it is too big, space is wasted. The recommended partition size starts at 40 MB for a complete release, leaving approximately 40% of user free space, but users may also elect to set their files apart in a HOME partition, as is explained below.

The Shark network computers at the ETH had three:
 * SYS: for read-only shared system files

 * RAM: for a ram disk

 * HOME: for the user's own files

On a PC, a recommended number is two:
 * SYS: for the installation

 * HOME: for the user's own files

It is recommended to make HOME: the default file system by executing OFSTools.SetDefault HOME ~, at best when Oberon is started by adding it to the System.InitCommands section of Oberon.Text. To make this quite visible add System.Watch to that section too.

Files with identical names in different file systems

This may be the source of a serious problem, with .Obj files in particular. When a module X is loaded, the module loader simply tries to open file X.Obj (no prefix). The file system will search through the search path (in System.Watch order) until X.Obj is found, and module X will be loaded from that file system. If you have multiple copies of X.Obj on different file systems, the search path order determines which one is loaded. This can be to the least confusing and can also lead to a catastrophy with TRAPs and system lockup. The best is to name modules uniquely (by registering a prefix in the module registry on the Native home page), and to avoid duplicate .Obj files.

[Top] Oberon installation and installation updating The possibility to operate with multiple file systems simplifies the installation strategy. For the purpose of discussing various options, assume that an Oberon system is running on two file systems (SYS: and HOME:). Recall that when Oberon is already installed, no other OS is needed anymore for a further installation (except for creating another Oberon partition, as this beta version does not yet support this).

Installation of new release

To install a new release without impairing or destroying the working system, say for testing it, one creates an additional partition for the new release. Then, the current file system (SYS:), the new FS (also SYS:) and the user FS (HOME:) can be managed as two pairs: current + HOME and new + HOME. Obviously, with such a setup you do not risk to overwrite some of the SYS: files adjusted to your personal preference, but these particular files must also be customized in the new system. Modified files can easily be spotted by executing System.Directory SYS:*.Bak resulting in a list, which will probably contain some of these names:

 * EditKeys.Text

 * Mail.Panel

 * Mail.Sig.Text - (your mail signature)

 * MailMessages - (your mailbox)

 * News.Sig.Text - (your news signature)

 * Oberon.Text

 * System.Tool

 * System3.Tool

 * TextPopups.Text

and possibly a few more *.Tool file names that have been adjusted. Follow the installation instructions to install the new release and start it. Mount the old FS under a name of your choice, e.g. OLD. Most of the files listed above may be copied to the new FS, except Oberon.Text which must be merged with the new one, because some new settings may have been added in the new release. Open OLD:Oberon.Text and SYS:Oberon.Text and copy the old settings into the new text. It might be a good practice to highlight your private data in color.

A MailMessage.Bak file will only show up after having executed Mail.Collect or after having deleted 100 messages.

There remains to organize to start either system at will. Many alternatives are offered: make them bootable from diskette, from a boot manager or by activation. Whereas booting from diskette is always possible, the alternatives are conditioned by the boot manager or the partitions' position on the hard disk(s).

Upgrading an installed Oberon

If you re-install Oberon in the same partition or upgrade it, the risk of overwriting files exists in principle, but the install procedure takes care of creating a .Bak file for each file with suffix ".Text", ".Tool" or ".Mod". Only those files listed in the previous section are really 'critical' and could be lost by erroneous handling (*). The installation itself is simplified compared to a full installation. Indeed, a partition is already present, hopefully of a suitable size, and the FS is also present. Formatting the FS is thus not required. Instead, the boot loader must be replaced with Partitions.UpdateBootFile. After the installation, copy back the critical files from their .Bak version or from a special backup version. Do not simply copy Oberon.Text, because some new settings may have been added in the new release. Open Oberon.Text and Oberon.Text.Bak and copy the old settings into the new text. It might be a good practice to highlight your private data in color.

(*) E.g. by attempting another run of the installation before completing the current one. As a measure of precaution, you may thus backup them prior to the installation in any of the manners described in the next section.

[Top] Configuration strings Native Oberon uses configuration strings for setting low-level configuration options. These strings are ASCII string pairs (name, value) which are stored in a table on the boot device (diskette or hard disk). Permanent values for these strings are normally set during installation using the Install program in Oberon-0. The strings are read by low-level modules in the system using the Kernel.GetConfig procedure. Higher-level modules should use the more flexible Oberon.Text and the Oberon.OpenScanner procedure for accessing configuration information.

Cfr. Configuration strings

[Top] Reconfiguring Oberon on start up Sometimes it is necessary to temporarily override the setting of some config strings.The configuration of a starting Oberon system can be changed on-the-fly by holding down the Shift key or by activating Scroll Lock during booting. Within seconds the boot process is interrupted and the config strings with their name and current value are listed on the screen:  OBERON loading...    BootVol=IDE0#9 MT=PS2 ...    OBL>

Enter "h" (for help) to recall the rules for replying to the Oberon Boot Loader (OBL) prompt (terminate each reply with a carriage return):  name=val - set config string name=   - delete config string c       - continue booting w       - write config to boot device

Enter a config string pair and terminate with a carriage return. Since version 2.23 the name strings are no longer case sensitive. To make the changes permanent, enter "w" and the configuration will be written back to the boot device. To continue with booting, enter a final "c".

If noboot.exe is used to start Oberon (via DOS or MS-DOS mode in Windows 95/ 98 (not ME)), the boot process is also interrupted but the editor of choice determined by a SET Editor= command is called to edit the configuration stored in the Native.Par file. When the editor is exited, booting is resumed. If no editor is defined, booting proceeds normally without giving an opportunity to modify Native.Par.

Obviously, config strings can also be changed by editing Native.Par whenever required. Only the size of the file containing Oberon (in the Linux file system) can be changed in Linux-based Native Oberon.

[Top] Backup / Restore methods PC Native Oberon offers a number of methods for backing up sensitive data.

File backup/restore to a mountable file system

Backing up in another file system (AosFS, NatFS, FatFS) is made possible by the mounting / unmounting facility described in Oberon and foreign file systems. A batch of files is best copied from one file system to a another using OFSTools.CopyTo. The same command is used to restore the files. Alternatively, the backup / restore operation can be conducted by executing System.CopyFiles. The command with a list of filenames is conveniently created by an OFSTools.GenCopyFiles command.

In spite of their limited storage capacity, diskettes are still a favorite backup medium, given the small average file size of Oberon modules and object files. Diskettes are exploited in the same way as hard disks, except that they feature a single partition of very small size, containing a mountable file system. Note that the AosFS can waste space in comparison with the NatFS and the FatFS. The classical drive letters "A" and "B" are not used anymore in commands, except in the Backup.Tool commands described next.

Since Oberon operates with long filenames, storing files to a FatFS may run unexpectedly fast into a capacity problem. The root directory in the file allocation table can contain 512 entries at most. In other words, there can be at most 512 files and folders in the root directory. To store long filenames and folder names, and their associated 8.3 aliases, one can run out of directory entries with fewer than 512 files or folders in the root directory. The work around is to move a batch of files to a work folder in the root directory.

Backup.Tool

Files are copied from a partition to a diskette using Backup.WriteFiles, and are restored to the partition using Backup.ReadFiles. Backup.Tool provides the details. For doing that, a diskette does not need mounting. Filenames are limited to the 8.3 format.

DOSBackup diskette

Files backed up on Windows Oberon using the DOSBackup tool can be restored on Native Oberon executing a DOS.BackupDirectory "a:/" command. This will produce a DOS.Copy command with the relevant filenames ready for editing before execution. The restored files will recover their Oberon names instead of the 8+3 names enforced by a DOS.ReadFiles command.

Backup on server via FTP

Oberon is inherently fit for communication, FTP in particular. A graphical user interface is at hand for uploading / downloading files to a remote server but the NetSystem.Tool provides down to earth commands to achieve the same goal.

Partition backup

Copy the partition to another one and restore it.

Partition cloning

Copy the partition to a disk image file and restore it.

[Top] Archives Archive files play a major role for backup operations and transmission of large amount of data. Soon, a new archive type will be offered, in addition to the custom Oberon archives with the file extension "Arc". The new Zip archives are portable among all Oberon and many other platforms. They are based on the widely used Zlib Deflate compression technique, allowing to compress multiple files into a single zip archive and conversely to deflate the archive. The archiving tools included in this release are only enumerated here:

 * Zip tool - cfr. Zip.Tool (* not Beta *)
 * Compress tool - cfr. Compress.Tool and Chapter2.Text
 * AsciiCoder tool - cfr. AsciiCoder.Tool and Chapter2.Text
 * Base64 tool - cfr. Decoders.Tool and Chapter2.Text
 * UUDecoder tool - cfr. Decoders.Tool and Chapter2.Text
 * BinHex tool - cfr. Decoders.Tool and Chapter2.Text
 * QuotedPrintable tool - cfr. Decoders.Tool
 * Rot13 tool - cfr. Decoders.Tool
 * Tar - cfr. Decoders.Tool
 * TGZ tool - cfr. Decoders.Tool

The Unzip, OldFiles and FileUtils tools, documented in Chapter2.Text, have been removed.

[Top] Beta version specialities This version's Partitions tool can not create a partition, it can only change the type of an existing partition available for reuse. Eventually, you will have to create a partition using another OS (e.g. using Linux or PartitionMagic), and then change its type by executing a Partitions.ChangeType command.

Partitions.Show ["detail"] ~ The command tells which drive letter is associated with each DOS/Win partition. This information is unreliable since it depends on the version used, and moreover, it is foreign to Oberon. This non-facility was dropped in the alpha version which features a more versatile FatFS.

Example:  Disk: IDE0, 8063MB, Maxtor 90845D4 IDE0#00  8063MB --- (Whole disk) IDE0#01   400MB   6 * c:/ DOS FAT16 >= 32M

The drive letter is necessary for mounting a DOS-based Oberon and for managing files with the DOS.Tool commands.

OFSTools.Mount prefix DosBasedFS filename ~ Mounts the file system of an Oberon system residing in the file specified in the next parameter. The file is located in a FAT16 partition. E.g.
 * OFSTools.Mount DOS DosBasedFS c:/oberon.dsk ~

OFSTools.Mount prefix FileFS filename ~ Mounts a FileFS of an existing Oberon in a file specified in the next parameter. Prior to issuing the OFSTools.Mount command, the DOS-based file must be copied from its host FAT16 partition to the Oberon partition with DOS.Copy. E.g.
 * DOS.Copy c:/system3/native.dsk => native.dsk ~

This Mount command variant makes it possible to exploit legacy data in former DOS-based Oberon systems.

Accessing a FAT16 partition

Instead of mounting a DosBasedFS, one can exchange files between Oberon and a FAT16 file system using the DOS command collection documented in DOS.Tool, an external medium by means of Backup commands or a server accessed by ftp. Solved differently in the alpha version.

File backup to a FAT16 partition

A batch of files is written from one partition to another using DOS.CopyTo, and is restored to the partition using DOS.CopyFrom. DOS.Tool provides the details.

The same result can be achieved by executing DOS.Copy commands at the cost of more editing of the filenames. There are numerous cases where a DOS.Copy command is even required. Executing a DOS.Directory command directed to a FAT partition, shows a plethora of "~" embedded in filenames, names which are then obviously invalid as destination filename in Oberon, as in this example:

DOS.CopyFrom "E:/ofwmay/work/" "mailsi~1.tex" ~

but this works:

DOS.Copy "E:/ofwmay/work/mailsi~1.tex" => Mail.Sig.Text ~

File backup to a diskette

Files are copied from a partition to a diskette using Backup.WriteFiles, and are restored to the partition using Backup.ReadFiles. Backup.Tool provides the details. For doing that, a diskette does not need mounting. Filenames are limited to the 8+3 format.

A Backup diskette cannot be mounted. The Backup tool format is not compatible with either NatFS or AosFS.

[Top] Bibliography [Bac86] Maurice Bach - The Design of the Unix Operating System - Prentice Hall - ISBN 0-13-201757-1

[WG92] Niklaus Wirth and Jürg Gutknecht - Project Oberon - The Design of an Operating System and Compiler - Addison-Wesley, 1992.

[Top]

''5 Nov 2002 - Copyright © 2002 ETH Zürich. All rights reserved.''

E-Mail: oberon-web at inf.ethz.ch

Homepage: www.ethoberon.ethz.ch

title: Oberon/ETH Oberon/betadocu


text:
Oberon/ETH Oberon/usb

USB support

Summary Basic USB support was implemented for Native Oberon (starting Dec. 8, 2000) by Christian Plattner in a semester project. Thomas Frey ported the USB modules to Bluebottle = A2. The support is rather new and not much experience has been gained yet.

USB is a very comprehensive standard, and not all devices are automatically supported. Many devices also use proprietary protocols on top of the basic USB link layer, thus requiring an extension of the basic support.

See Usb.Tool for more information. For an exhaustive description of the subject, consult: usb.org and Wikipedia. How to install a USB driver If a USB controller is present (many modern computers feature an on-board USB controller), use the System Setup of your machine to enable it. Then, execute the following command:

UsbSystem.Start
 * Installs a USB system driver. After that, a USB mouse driver and a USB keyboard driver may be installed. Do not install the driver if the USB controller is not enabled or none is present.

Alternatively and preferably, edit the command in Oberon.Text as explained below.

Configure Oberon.Text - NetSystem.System.InitCommands

In a freshly installed Oberon, this section contains a commented UsbSystem.Start command already. Uncomment it and the USB driver will be automatically installed when Oberon is started.

[Top]

''22 Jul 2002 - Copyright © 2002 ETH Zürich. All rights reserved.''

E-Mail: oberon at lists.inf.ethz.ch

Homepage: http://www.ethoberon.ethz.ch/

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Oberon/ETH Oberon/usb


text:
Oberon/ETH Oberon/keyboard

Keyboard support

This page addresses hardware, configuration and functionality. A usage tutorial is also available. Summary Oberon uses a PS/2-style keyboard attached to a 6-pin DIN connector or a keyboard attached to a 4-pin USB connector. The numeric pad can take over the functions of the mouse, if need be. How to install a keyboard driver A freshly installed Oberon system is set up to operate with a PS/2-style, 101-key keyboard with US layout.

Currently, eleven other keyboard layouts are supported: Belgian, Canadian, Swiss German, German, Dvorak, French, Norwegian, Polish, Finnish, Turkish, UK English.

Each keyboard, except the US one, is defined by a keyboard map file and all of these can be listed by executing

A keyboard driver for a different keyboard layout is installed in these ways:
 * at startup, set the config string Keyboard = mapfilename
 * or execute the following command, which can be edited in the System section of Oberon.Text.

ConfigInput.Keyboard [ mapfilename | ^ ]

 * Sets up the keyboard driver to operate with a keyboard with the specified layout. A list of existing map filenames is obtained with System.Directory Key*.Bin\d ~. There exists no US file; omit the parameter to install a US keyboard.

Escape compatibility / Neutralize The Neutralize key is used to remove all marks on the display, including the caret, the marker and text selections. The F2 key is defined as Neutralize key for all the Oberon system implementations. In earlier implementations instead, the Esc key was assigned this function. Doing this has the negative consequence that the Esc character cannot be generated in certain applications needing it, e.g. terminal-emulation applications.

The Escape compatibility option is controlled at startup, by the config string EscCompat and lets the user define the meaning of the Esc key:

EscCompat = 0 (default) the Esc key retains its conventional meaning.

EscCompat = 1 the Esc key is also a Neutralize key. An Esc character must then be generated by F3.

In both cases, an Esc character can also be generated with Shift-Esc or Alt-27. Num Lock Num Lock is controlled at startup, by the config string NumLock

NumLock = 1 (default) activates the Num Lock mode

NumLock = 0 deactivates it How to install a USB keyboard driver

UsbKeyboard.Init
 * Installs a USB keyboard driver. The USB system must be active already.

How to support another keyboard If no keyboard map exists for your specific keyboard, the Keyboard.Mod is provided to help construct a keyboard table file. Instruction for using it are included in the source. Please submit your work to the developer team, for inclusion in a follow-up release. ASCII and Latin-1 (ISO 8859-1) character sets Oberon is based on the standard ASCII character set code points 00H to 7FH. The characters are produced with the respective labelled keys, including the use of Shift-key, on a US 101-key keyboard. For cross-platform portability, Oberon does not normally support all keys available on the keyboard.

The printable character or the function corresponding to a decimal code point can be generated by holding the Alt-key and keying the decimal value on the numeric keypad.

To find out a key's respective printable character and at the same time the decimal and the hexadecimal code point, execute EditKeys.GetKeyCode and follow the instructions in the System log. The command is documented in EditKeys.Tool.

Code points 00H to 1FH

Hex | Dec. Key    Ctrl          TTY |            stroke       symbol + 00 |   0         Ctrl-Shift-`   NUL 01 |  1         Ctrl-a         SOH 02 |  2         Ctrl-b         STX 03 |  3         Ctrl-c         ETX 04 |  4         Ctrl-d         EOT 05 |  5         Ctrl-e         ENQ 06 |  6         Ctrl-f         ACK 07 |  7         Ctrl-g         BEL 08 |  8         Ctrl-h         BS  09 |   9  Tab    Ctrl-i         HT  0A |  10         Ctrl-j         LF  0B |  11         Ctrl-k         VT  0C |  12         Ctrl-l         FF  0D |  13  Enter  Ctrl-m         CR  0E |  14         Ctrl-n         SO  0F |  15         Ctrl-o         SI  10 |  16         Ctrl-p         DLE 11 | 17         Ctrl-q         DC1 12 | 18         Ctrl-r         DC2 13 | 19         Ctrl-s         DC3 14 | 20         Ctrl-t         DC4 15 | 21         Ctrl-u         NAK 16 | 22         Ctrl-v         SYN 17 | 23         Ctrl-w         ETB 18 | 24         Ctrl-x         CAN 19 | 25         Ctrl-y         EM  1A |  26         Ctrl-z         SUB 1B | 27  Esc    Ctrl-[         ESC 1C | 28         Ctrl-\         FS  1D |  29         Ctrl-]         GS  1E |  30         Ctrl-Shift-6   RS  1F |  31         Ctrl-Shift--   US

Code points 20H to 7FH

All characters are printable except DEL.

Hex | .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F + 2. | SP ! " #  $  %  &  '    *  + ,  -  .  /  3. |  0  1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?  4. |  @  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  5. |  P  Q  R  S  T  U  V  W  X  Y  Z  [  \  ]  ^  _  6. |  `  a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  7. |  p  q  r  s  t  u  v  w  x  y  z  {  |  }  ~ DEL

Code points 80H to FFH

The assignment of special language characters to code points 80H to 95H is a property of the fonts delivered with Oberon. In HTML, any ISO Latin-1 character can be written as &#xxx;, where xxx is the decimal code point of the character, in place of the entity reference. Of the remaining code points, some are used by Oberon and others are unassigned. Latin-1 characters - ISO 8859-1, Latin script - can be produced on a US keyboard, as shown in the table below, using the Alt-key or a dead key stroke (the Shift key is implicitly required where A, O, U, " or ^ appear).

Hex | Dec. Key    Alt      Deadkey     Entity |            stroke    stroke     reference +-- 80 | 128   Ä     Alt-A    Alt-" + A   Ä  81 | 129   Ö     Alt-O    Alt-" + O   Ö 82 | 130  Ü     Alt-U    Alt-" + U   Ö  83 | 131   ä     Alt-a    Alt-" + a   ä 84 | 132  ö     Alt-o    Alt-" + o   ö  85 | 133   ü     Alt-u    Alt-" + u   ü 86 | 134  †              Alt-^ + a   â 87 | 135  ‡              Alt-^ + e   ê 88 | 136  ˆ              Alt-^ + i   î 89 | 137  ‰              Alt-^ + o   ô 8A | 138  Š              Alt-^ + u   û 8B | 139  à              Alt-` + a   à 8C | 140  è              Alt-` + e   è 8D | 141                 Alt-` + i   ì 8E | 142  ò              Alt-` + o   ò 8F | 143  ù              Alt-` + u   ù 90 | 144  é              Alt-' + e   é 91 | 145  ë     Alt-e    Alt-" + e   ë  92 | 146   ï     Alt-i    Alt-" + i   ï 93 | 147  “     Alt-c                ç 94 | 148  á              Alt-' + a   á 95 | 149  •     Alt-n                ñ 96 | 150  –     Alt-s                ß --- OType.Mod handles up to 9B --- 97 | 151                             £ 98 | 152                             ¶ 99 | 153                             Ç 9A | 154 9B | 155  › 9C to 9F --- not assigned A0 | 160 Insert A1 | 161 Delete A2 | 162 PageUp A3 | 163 PageDown A4 | 164 F1            Setup (in Oberon.Mod) A5 | 165 F2            Neutralise (in Oberon.Mod) A6 | 166 --- not assigned Scroll (in Draw ??) A7 | 167 F4            Scroll Lock (in Draw ??) A8 | 168 Home A9 | 169 End AA to C0 --- not assigned C1 | 193 Up arrow C2 | 194 Down arrow C3 | 195 Right arrow C4 | 196 Left arrow C5 to F4 --- not assigned F5 | 245 F5            Display off/on (in Oberon.Mod) F6 | 246 F6  F7 | 247  F7            Reset palette (in Oberon.Mod) F8 | 248 F8  F9 | 249  F9            Update display (in Oberon.Mod) FA | 250 F10 FB | 251 F11 FC | 252 F12 FD | 253 --- not assigned FE | 254 Esc FF | 255 Quit          Reboot  (in Oberon.Mod)

ASCIITab tool The ASCIITab.Tool offers an alternative to typing accented characters, and more generally any code point, as ALT-key combinations, provided the Gadgets-based GUI is installed. Executing  opens a text document viewer containing a table from where to pick characters for insertion in the text being edited in some other text viewer. The table of 8 rows by 32 columns contains the printable characters in Oberon10 font (the Oberon default font). Set the caret in the text, and in the table MM click the character to insert at the caret.

To change the font of the table, edit the font name in  as required, select the table (MR click) and execute the command. After this, deselect the table and proceed with editing. For a larger font, it is necessary to resize the table. Since the table is a gadget having ASCIITab.NewFrame as generator, it can also be inserted anywhere at the caret with. Writing Oberon in lower case only Persons affected by Repetitive Strain Injury (RSI) may wish to write Oberon in lower case characters only. Three ways to make this possible are described in the FAQ.

[Top]

''11 Jul 2002 - Copyright © 2002 ETH Zürich. All rights reserved.''

E-Mail: oberon at lists.inf.ethz.ch

Homepage: www.ethoberon.ethz.ch

title: Oberon/ETH Oberon/keyboard


text:
Oberon/ETH Oberon/mouse

Mouse support

This page addresses hardware, configuration and functionality. A usage tutorial is also available. Summary The Oberon TUI and GUI can be controlled at best with a 3-button mouse as originally designed. However, many potential Oberon users have systems fitted with 2-button mice and are not ready to acquire another mouse in spite of the low cost. The 2-button support is particularly welcomed by users liking track balls.

Oberon can be controlled:

 * 1) with a 3-button mouse as originally designed. The mouse buttons are, by convention, named from left to right ML, MM and MR.
 * 2) with a 2-button mouse (ML, MR), substituting the missing MM button by the keyboard Ctrl-key (left and right).
 * 3) with a 2-button mouse (ML, MR), replacing a MM click by a succession of two ML clicks. The first ML click sets the caret as is usual. The second ML click, at the same mouse focus, is interpreted like a MM click. The second click may occur any time after setting the caret, on the condition that the mouse focus is not changed. Or else, the caret is moved. This basic rule should be easily mastered by expert 3-button mouse users. Of course, this device was introduced at the cost of some loss of comfort as is documented in the subsequent tables.

When Oberon is started, it is ready to be controlled with a 2-button mouse according to 3., irrespective of the mouse type. If the mouse has effectively 2 buttons, hitting the F8-key switches the mode of operation to 2. But, if on hitting the F8-key Oberon recognizes the signals of a 3-button mouse, it will switch the mode of operation to 1. The change of mode is made apparent by the tiny double-arrow icon at the left of the NamePlate of open documents in the GUI and by an equivalent icon in the menu bar of documents in the TUI.

With a 3-button mouse installed, one can practice the modes 2. and 3. by simply ignoring the middle button, though the button retains its functionality and a mixed mode operation is always possible.

Note 1: Track balls are usually fitted with 2 buttons and it is becoming increasingly difficult to acquire a 3-button track ball. A 4-button track ball represents a mediocre alternative since it requires to use the index finger for the ML and MM clicks, which makes a ML + MM interclick difficult to execute.

Note 2: "+" denotes an interclick, as in MR + ML meaning: press MR, hold it down and press ML before releasing both buttons. "&" denotes the concatenation of ML clicks.

Note 3: A right-handed mouse is assumed, but a left-handed mouse is also supported (see below). How to install a mouse driver Oberon can support a wide range of mouse types of all commonly used brands. The most widespread is the PS/2-compatible mouse, or bus mouse, attached to a 6-pin miniature DIN connector. All others mice connect to serial ports, either built-in or on expansion cards. Each machine is allowed up 4 serial ports. How to select the correct mouse driver As from this version, a mouse can easily be replaced by another of a different type and with a different interface. More than one mouse may be connected to a machine: the system can detect them and the user can select the best one. The next three commands have been designed specifically to let the system sort out mice, instead of letting the user question which parameter is appropriate, as is required for the third command. Previously, the mouse driver was chosen interactively during the installation.

A mouse driver for a different is installed in these ways: To to select the correct mouse driver at each system start do:

 * at startup, set the config strings: MT, MP, MB (see below)
 * or execute one of the following command
 * or edit a line containing one of the following commands, in the System section of Oberon.Text.
 * ConfigInput.WatchMouse [ seconds | 5 ]

 * Lets the system watch a mouse movement for a number of seconds. If a mouse manifests itself, the mouse driver is configured to operate with it. If not, a system log message invites the user to configure the mouse driver. Moving a mouse may be enough to let the system recognize that mouse. Else, pressing Ctrl-Shift launches a SelectMouse command described next.
 * ConfigInput.SelectMouse

 * Lets the system attempt to configure a series of mice with different specifications on the available COM ports. The search ends when a mouse is effectively reacting as expected, else a PS/2-style mouse is configured as final default. A Mouse Configuration user interface is telling which mouse type the driver was configured successfully. By following the instructions in the menu it is still possible to choose a different mouse of a different type or attached to another port, or to accept the final choice which is displayed in the System log. This system service makes it easy to edit the correct command in Oberon.Text.
 * ConfigInput.Mouse mt [ mp [ mb ] ] ~

 * Sets up the mouse driver to operate a mouse of type mt, connected to the port mp, with mb buttons. One should preferably let the system select the correct mouse (cfr. previous command). Thoroughly choose a combination of parameters fitting the mouse characteristics, else mouse control will be lost. To remedy such a mishap, activate Scroll Lock to transfer the mouse control to the keyboard.

 * mt (respectively MT), the mouse type is:

           mt   Mouse description PS2  PS/2-style or built-in MSI  Microsoft IntelliMouse or new Logitech LM1  Logitech type 1 LM2  Logitech type 2 LM3  Logitech type 3 MS1  Mouse Systems type 1 MS2  Mouse Systems type 2 MS3  Mouse Systems type 3 MS4  Mouse Systems type 4 MSM  Microsoft 2-button

 * mp (respectively MP), the mouse port is 1 .. 4 for COM1 to COM4 for a mouse with a serial interface. 1 is the default value. Not applicable to a PS2 mouse; use 1.

 * mb (respectively MB), the number of buttons is:

           2   the keyboard Ctrl key emulates the MM buttom 3  the keyboard Ctrl key retains its usual function -2              -3   The default value. Switched to 3 as soon as a real MM button is found

 * Practical hint: Two such commands can be used in combination to switch mice on a laptop:

 * ConfigInput.SelectMouse PS2 1 -3 ~ to operate the stick (between G and H) and 2 buttons below the space bar

 * ConfigInput.SelectMouse LM1 2 -3 ~ to operate a serial 3-button mouse installed for working with Oberon

 * The mouse configuration selected at installation time is stored in the configuration data and reused when Oberon is started. This information can be modified on-the-fly at boot time or permanently stored. The mouse type is specified as MT= "", the port as MP="" and the number of buttons as MB="" and the values are chosen as described above.

Mouse commands in text (1) Delete the text stretch/gadget and paste what is then in a scratch pad back at the caret with Edit.Recall, TextDocs.Recall or with the [Recall] Iconizer in System3.Tool of the GUI.

(2) Implicit open - TUI: Edit Open / GUI: Desktops.OpenDoc

(3) The combination of Delete and Copy to corresponds to a cut-and-paste operation in other text editors but a pre-condition must hold true: no other selection may exist, else the selection will be copied. Mouse commands on the menu bar of a viewer (1) The menu bar can only be moved within the limits of adjacent menu bars or screen border.

(2) The document can be relocated in the adjacent track or in the same track above or below another document. If the menu bar is dragged on top of another, the document below it is closed.

Inside the NamePlate in the menu bar, mouse clicks have the following meaning: Mouse commands on the scroll bar of a viewer Mouse commands in the control area of a gadget Most visual gadgets are rectangular in shape, and for those gadgets the control area is a border a few pixels wide inside the edge of the gadget. Inside the gadget, but not in the control area, the gadget does whatever it is supposed to do (Buttons can be pushed, CheckBoxes checked, etc). In the control area, the gadget responds to the control mouse combinations listed in this table. How to replace the mouse by the keyboard The full functionality of the mouse can be transferred to the numeric pad of the keyboard by activating Scroll Lock. To return control to the mouse, deactivate Scroll Lock.
 * "5" - takes over the function of the MM key (activate)
 * "Ins" - takes over the function of the ML key (set caret)
 * "Del" - takes over the function of the MR key (select)
 * The 8 keys surrounding the "5" - move the mouse focus
 * The 8 keys surrounding the "5" - move the mouse focus

The Ctrl key is possibly also available as MM key.

How to define a left-handed mouse A left-handed mouse, with buttons arranged in reverse order [ MR, ML ], is defined by a config string "MM=digits" (Mouse Mapping). digits is exactly 3 digits, with each digit representing a mouse button: 0 = ML, 1 = MM, 2 = MR. It is convenient to use the Ctrl-key to the right of the keyboard in conjunction with a left-handed mouse.
 * MM = "012" - right-handed, assumed when Oberon is booted
 * MM = "210" - left-handed
 * MM = "021" - Logitech cordless mouse
 * MM = "021" - Logitech cordless mouse

How to install a USB mouse driver UsbMouse.Init

 * Installs a USB mouse driver. The USB system must be active already.

[Top]

''4 Aug 2001 - Copyright © 2001 ETH Zürich. All rights reserved.''

E-Mail: oberon at lists.inf.ethz.ch

Homepage: http://www.ethoberon.ethz.ch/

title: Oberon/ETH Oberon/mouse


text:
Cookbook:Mieliepap (South African Maize Porridge)

Ingredients

 * 2 cups maize meal
 * 2 cups water
 * 1 teaspoon salt

Process

 * 1) Add boiling water from the kettle to a pot, and bring to a boil again.
 * 2) Mix the maize meal and cold water in a separate bowl to form a thick mixture.
 * 3) Add the cold mixture and salt to the boiling pot of water, and stir until the soft porridge starts bubbling and is thick.
 * 4) Reduce the heat to low, and partially close the lid. Cook for 20 minutes.
 * 5) Serve with margarine, milk, and/or sugar if desired.


text:
User talk:Dr. Mohammed (usurped)

Usurpation requested
Hello,. A request has been made via Changing username/Usurpations (or SRUC) to usurp, or "take over", your username because another user would like to use it to edit. The changing username guideline allows a username that is not being actively used to be usurped if the user is given an opportunity to object and does not do so.

If you do not object to being renamed to a new username in order for another user to use the name you currently have, please log in and post a reply here saying so (you may also tell us what username you would like to be renamed to, or we will provide you with a generic one) or use Special:GlobalRenameRequest.

If you do nothing : the request may be filled shortly, and your account will be moved to a generic username. You may request that it be moved to a new username of your choice at any time.

If you object to being renamed : please log in and make an edit to this page clearly stating that you object to usurpation. Any objection on your part will prevent usurpation.

Please note that even if your current username is usurped, you can still edit and your data will not be lost; your preferences, watchlist, and other user settings will be transferred to a new username.

Thank you for your time.<! -- Template:Usurpation requested -- > }} --فيصل (discuss • contribs) 19:03, 28 April 2020 (UTC)

title: User talk:Dr. Mohammed (usurped)


text:
Oberon/ETH Oberon/disk

Disk support

Summary ETH Native Oberon supports mass storage devices attached to controllers of the types ATA/EIDE, Adaptec SCSI, NCR SCSI and USB, in a number conditioned by the machine hardware and the controller characteristics. A suitable driver must be installed first, as explained below. The attached devices may be hard disks or disk drives with removable media, such as CD-ROM, iomega ZIP (100 or 250MB) and Jaz disk drives. Use the System Setup program of your machine to configure the disk drives. Native Oberon can reside in a primary partition or in a logical drive of any EIDE disk attached to the first or the second controller as master or slave disk. Limitations are described in BIOS support.

Slim is in: Slimline 2.5in. drives fitted into the vast majority of notebooks can also be considered for installation on a conventional PC, as they use the same ATA/EIDE interface but have a 44-pin interface connector IDC44. A cheap adapter connector is enough for matching it with the 40-pin flat cable connector.

Any number of RAM disks can be defined for storing temporary data which is purged when Oberon is terminated.

Apart from conventional disks, Oberon can be installed on other miniaturized next-generation mass storage devices, eminently suitable for use in embedded systems:

 * CompactFlash. The ATADisks.Mod has been adapted in accordance to the "CF+ and CompactFlash Specification Version 1.4" of the CompactFlash Association.
 * Disk On Module - DOM, also called DOF or "flash disk"/"flash drive", currently featuring a capacity of 4MB to approx. 1.2GB, in a form factor of 3.5in. and 2.5in. They too have an ATA/EIDE interface using a 44-pin IDC44 interface connector. The specifications of some of the manufacturers assert "100% IDE compatible", hence there a good chance that a DOM can host Oberon as-is. Oberon could fit in 8 MB. DOMs are rather expensive and are about 300% faster than DOC (not supported - see below). Examples:
 * DOF from Acrosser. Product was investigated but not tested.
 * DOM 2000 from ADLink Technology, Inc. Product was investigated but not tested.
 * Toshiba MF6xyz flash drive.

Not supported How to install a disk driver during the installation The installation is initiated by booting the machine from an Oberon-0 boot diskette. Little later, Oberon-0, a small ramdisk-based system, takes control of the machine and presents the Install.Tool on the display. The user is prompted to install a suitable driver by executing a single one of the following commands:
 * CD-ROM with SCSI interface. Currently, only ATAPI CD-ROMs are supported and only the audio commands. We hope that someone will write drivers for different CD-ROMs. Some work has already been done in this direction.
 * recordable CD drive.
 * ZIP drive with a parallel interface.
 * Disk On Chip - DOC needs a driver, something equivalent to what is done in TrueFFS (True Flash File System) technology. Writing a driver should not be too difficult due to the presence of the generic Oberon File System (OFS) component. (Re-)Writing the Oberon Boot Loader (OBL) to support this HW is somewhat trickier. Currently, DOCs feature a capacity of 2 to approx. 288MB.

The ATA/EIDE driver supports up to four disks on standard address values: IRQ 14H, control port = 1F0H, register port = 3F6H IRQ 15H, control port = 170H, register port = 376H From now on, the installion of a complete disk-based system can proceed. Launch a Partitions.Show command to let the system display information on the disk drives recognized. The driver's identification is recorded in a configuration file which will be used each time the system is started. How to install a disk driver in a running Oberon system An additional driver is dynamically loaded (no reboot required) by executing the command corresponding to the hardware to control:
 * Config.Disk Standard ATA/EIDE
 * primary controller - master + slave disk
 * secondary controller - master + slave disk
 * Config.Disk Adaptec AIC7xxx SCSI
 * Config.Disk NCR 810 SCSI
 * Config.Disk Standard USB

Disk partitioning Partitioning considerations explains the purpose of dedicating a partition to ETH Oberon on any of the installed hard disk(s) and how it can even be avoided altogether. In addition, ways to start an ETH Oberon are presented in Bootstrapping an OS on an x86-based PC, with application to ETH Oberon and further documents linked to it.
 * for an ATA/EIDE controller, execute ATADisks.Install (takes about 5 sec)
 * for an Adaptec 7xxx SCSI controller, execute Adaptec7.Install (takes about 15 sec)
 * for an NCR 810 SCSI controller, execute NCR810Disks.Install (takes about 15 sec)
 * for an Usb controller, execute UsbStorage.Install (takes about ?? sec)

If disk partitioning is deemed necessary, it is performed using: Warning: These products are however not fit to format, resize or move an Oberon partition, as they do not even recognize it. Small selection of products frequently reviewed in a plethora of computer press publications: Further activities, such as formatting a partition (i.e. creating an empty file system), are dealt with in File system concept. Technical 1: Disk driver and file system config strings The config string IDE=irq, control port, register port must be specified if: More config strings in Configuration strings. Technical 2: Disks and controllers characteristics incl. jumper settings and utilities Consult: pc-disk. [expired] For developers: How to write a disk driver If all attempts to use one of offered drivers fail, you could volunteer to write a suitable one, using the Guidelines for writing a disk driver.
 * an installed Oberon. Oberon-0, the small ramdisk-based system used for the installation, is enough. Oberon's ability to perform partition management has some limitations.
 * any suitable commercial software product or other shareware/freeware, and there are plenty of them. Most of them offer reliable and comfortable facilities for redimensioning existing partitions in order to obtain free space.
 * Partition Magic 7.0 by Powerquest
 * OS Selector 5.0 by Acronis
 * Partition Manager 5.0 by Paragon
 * System Commander 2000 by V-Communications
 * Ranish Partition Manager
 * the disk controller is not located at the standard address or
 * if the disk hosting Oberon is attached to the secondary controller.

The FatFS driver (FAT16 / FAT32) was written using Microsoft documentation.

[Top]

''22 Jul 2002 - Copyright © 2002 ETH Zürich. All rights reserved.''

E-Mail: oberon-web at inf.ethz.ch

Homepage: www.ethoberon.ethz.ch [expired]

title: Oberon/ETH Oberon/disk