Expansion Library - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:17:07Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:17, 26 January 2025
Line 22:		Line 22:
	The ConfigDev structure is defined in <libraries/configvars.h>:		The ConfigDev structure is defined in <libraries/configvars.h>:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct ConfigDev {		struct ConfigDev {
	struct Node cd_Node;		struct Node cd_Node;
Line 48:		Line 48:
	The ExpansionRom structure is defined in <libraries/configregs.h>:		The ExpansionRom structure is defined in <libraries/configregs.h>:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct ExpansionRom { /* First 16 bytes of the expansion ROM */		struct ExpansionRom { /* First 16 bytes of the expansion ROM */
	UBYTE er_Type; /* Board type, size and flags */		UBYTE er_Type; /* Board type, size and flags */
Line 272:		Line 272:
	After the board is configured, the er_Type field of its ExpansionRom structure is checked. The DIAGVALID bit set declares that there is a valid DiagArea (a ROM/diagnostic area) on this board. If there is a valid DiagArea, expansion next tests the er_InitDiagVec vector in its copy of the ExpansionRom structure. This offset is added to the base address of the configured board; the resulting address points to the start of this board's DiagArea.		After the board is configured, the er_Type field of its ExpansionRom structure is checked. The DIAGVALID bit set declares that there is a valid DiagArea (a ROM/diagnostic area) on this board. If there is a valid DiagArea, expansion next tests the er_InitDiagVec vector in its copy of the ExpansionRom structure. This offset is added to the base address of the configured board; the resulting address points to the start of this board's DiagArea.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct ExpansionRom		struct ExpansionRom
	{		{
Line 291:		Line 291:
	Now expansion knows that there is a DiagArea, and knows where it is.		Now expansion knows that there is a DiagArea, and knows where it is.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct DiagArea		struct DiagArea
	{		{

Janne Peräaho: Added code review request

2018-09-20T13:58:17Z

Added code review request

← Older revision		Revision as of 13:58, 20 September 2018
Line 1:		Line 1:
	{{NeedUpdate}}		{{NeedUpdate}}{{CodeReview}}
	== Expansion Library ==		== Expansion Library ==

Steven Solie: /* AUTOCONFIG */

2015-11-03T23:12:45Z

AUTOCONFIG

← Older revision		Revision as of 23:12, 3 November 2015
Line 8:		Line 8:
	The Amiga AUTOCONFIG protocol is designed to allow the dynamic assignment of available address space to expansion boards, eliminating the need for user configuration via jumpers. Such expansion boards include memory boards, hard disk controllers, network interfaces, and other special purpose expansion devices. Some expansion devices, such as RAM boards, require no special driver software. Other types of expansion devices may use a disk-loaded driver from the "DEVS:" or "SYS:Expansion drawer", or an on-board ROM driver (for example, a self-booting hard disk controller).		The Amiga AUTOCONFIG protocol is designed to allow the dynamic assignment of available address space to expansion boards, eliminating the need for user configuration via jumpers. Such expansion boards include memory boards, hard disk controllers, network interfaces, and other special purpose expansion devices. Some expansion devices, such as RAM boards, require no special driver software. Other types of expansion devices may use a disk-loaded driver from the "DEVS:" or "SYS:Expansion drawer", or an on-board ROM driver (for example, a self-booting hard disk controller).

	This ~~chapter~~ will concentrate on the software and driver side of Zorro expansion devices, using a Zorro-II device as an example. Zorro-III devices have additional identifying bits and memory size options which are described in the Zorro-III hardware documentation. For more information on Zorro-II and Zorro-III expansion hardware, see the "Zorro Expansion Bus" appendix of the ''Amiga Hardware Reference Manual, 3rd Edition''. For additional information specific to Zorro-II boards, see the ''A500/A2000 Technical Reference Manual''.		This article will concentrate on the software and driver side of Zorro expansion devices, using a Zorro-II device as an example. Zorro-III devices have additional identifying bits and memory size options which are described in the Zorro-III hardware documentation. For more information on Zorro-II and Zorro-III expansion hardware, see the "Zorro Expansion Bus" appendix of the ''Amiga Hardware Reference Manual, 3rd Edition''. For additional information specific to Zorro-II boards, see the ''A500/A2000 Technical Reference Manual''.

	AUTOCONFIG occurs whenever the Amiga is powered on or reset. During early system initialization, expansion.library identifies the expansion boards that are installed in the Amiga and dynamically assigns an appropriate address range for each board to reside at. During this AUTOCONFIG process, each expansion board first appears in turn at $E80000 (Zorro-II) or $FF000000 (Zorro-III), presenting readable identification information, generally in a PAL or a ROM, at the beginning of the board. The identification includes the size of the board, its address space preferences, type of board (memory or other), and a unique [[Amiga_Hardware_Manufacturer_ID_Registry\|Hardware Manufacturer Number]] assigned by the AmigaOS development team.		AUTOCONFIG occurs whenever the Amiga is powered on or reset. During early system initialization, expansion.library identifies the expansion boards that are installed in the Amiga and dynamically assigns an appropriate address range for each board to reside at. During this AUTOCONFIG process, each expansion board first appears in turn at $E80000 (Zorro-II) or $FF000000 (Zorro-III), presenting readable identification information, generally in a PAL or a ROM, at the beginning of the board. The identification includes the size of the board, its address space preferences, type of board (memory or other), and a unique [[Amiga_Hardware_Manufacturer_ID_Registry\|Hardware Manufacturer Number]] assigned by the AmigaOS development team.

Steven Solie: /* filesysres.h */

2015-10-02T19:01:00Z

filesysres.h

← Older revision		Revision as of 19:01, 2 October 2015
Line 1,237:		Line 1,237:
	No more entries need exist than those implied by fse_PatchFlags, so entries do not have a fixed size.		No more entries need exist than those implied by fse_PatchFlags, so entries do not have a fixed size.

	For additional information on initializing and booting a Rigid Disk Block ~~filesystem~~ device, see the [[SCSI_Device\|SCSI Device]]. Writers of drivers for expansion devices that perform their own DMA (direct memory access) should consult the Exec chapters and Autodocs for information on processor cache control functions including CachePreDMA() and CachePostDMA().		For additional information on initializing and booting a Rigid Disk Block file system device, see the [[SCSI_Device\|SCSI Device]]. Writers of drivers for expansion devices that perform their own DMA (direct memory access) should consult the Exec chapters and Autodocs for information on processor cache control functions including CachePreDMA() and CachePostDMA().

	See the following include files for additional notes and related structures: <libraries/configvers.h>, <libraries/configregs.h>, <devices/hardblocks.h>, <resources/filesysres.h> and <libraries/filehandler.h>.		See the following include files for additional notes and related structures: <libraries/configvers.h>, <libraries/configregs.h>, <devices/hardblocks.h>, <resources/filesysres.h> and <libraries/filehandler.h>.

Steven Solie: /* RigidDiskBlock and Alternate File Systems */

2015-10-02T18:36:10Z

RigidDiskBlock and Alternate File Systems

← Older revision		Revision as of 18:36, 2 October 2015
Line 760:		Line 760:
	=== RigidDiskBlock and Alternate File Systems ===		=== RigidDiskBlock and Alternate File Systems ===

	Through the use of RigidDiskBlock information and the FileSystem.resource, it is possible for an autoboot driver to have access to enough information to mount all of its device partitions and even load alternate ~~filesystems~~ for use with these partitions.		Through the use of RigidDiskBlock information and the FileSystem.resource, it is possible for an autoboot driver to have access to enough information to mount all of its device partitions and even load alternate file systems for use with these partitions.

	The RigidDiskBlock specification (also known as "hardblocks") defines blocks of data that exist on a hard disk to describe that disk. These blocks are created or modified with an installation utility (such as the hard drive ''Prep'' utility for the ''A2090A'' ST506/SCSI controller card) provided by the disk controller manufacturer, and they are read and used by the device driver ROM (or expansion) code. They are not generally accessible to the user as they do not appear on any DOS device. The blocks are tagged with a unique identifier, checksummed, and linked together.		The RigidDiskBlock specification (also known as "hardblocks") defines blocks of data that exist on a hard disk to describe that disk. These blocks are created or modified with an installation utility (such as the hard drive ''Prep'' utility for the ''A2090A'' ST506/SCSI controller card) provided by the disk controller manufacturer, and they are read and used by the device driver ROM (or expansion) code. They are not generally accessible to the user as they do not appear on any DOS device. The blocks are tagged with a unique identifier, checksummed, and linked together.
Line 786:		Line 786:
	The PartitionBlock entries contains most of the data necessary to add each partition to the system. They replace the Mount and "DEVS:MountList" mechanism for adding these partitions. The only items required by the expansion.library MakeDosNode() function which are not in this partition block are the Exec device name and unit, which is expected to be known by driver reading this information. The file system to be used is specified in the pb_Environment. If it is not the default file system (i.e., "DOS\0" or "DOS\1"), the node created by MakeDosNode() is modified as specified in a FileSystem.resource's FileSysEntry before adding it to the DOS list.		The PartitionBlock entries contains most of the data necessary to add each partition to the system. They replace the Mount and "DEVS:MountList" mechanism for adding these partitions. The only items required by the expansion.library MakeDosNode() function which are not in this partition block are the Exec device name and unit, which is expected to be known by driver reading this information. The file system to be used is specified in the pb_Environment. If it is not the default file system (i.e., "DOS\0" or "DOS\1"), the node created by MakeDosNode() is modified as specified in a FileSystem.resource's FileSysEntry before adding it to the DOS list.

	Only 512 byte blocks were supported by the pre-V36 file system, but this proposal was forward-looking by making the block size explicit, and by using only the first 256 bytes for all blocks but the LoadSeg and BadBlock data. Under the present ~~filesystem~~, this allows using drives formatted with sectors 256 bytes or larger (i.e., 256, 512, 1024, etc). LoadSeg and BadBlock data use whatever space is available in a sector.		Only 512 byte blocks were supported by the pre-V36 file system, but this proposal was forward-looking by making the block size explicit, and by using only the first 256 bytes for all blocks but the LoadSeg and BadBlock data. Under the present file system, this allows using drives formatted with sectors 256 bytes or larger (i.e., 256, 512, 1024, etc). LoadSeg and BadBlock data use whatever space is available in a sector.

	==== RigidDiskBlock ====		==== RigidDiskBlock ====
Line 809:		Line 809:
	: Size of disk blocks.		: Size of disk blocks.

	: Present ~~filesystem~~ supports 256, 512, 1024, etc.		: Present file system supports 256, 512, 1024, etc.

	; rdb_Flags		; rdb_Flags
Line 835:		Line 835:
	:: Drive supports scsi synchronous mode; '''can be dangerous to use if it doesn't!'''		:: Drive supports scsi synchronous mode; '''can be dangerous to use if it doesn't!'''

	These fields point to other blocks on the disk which are not a part of any ~~filesystem~~. All block pointers referred to are block numbers on the drive.		These fields point to other blocks on the disk which are not a part of any file system. All block pointers referred to are block numbers on the drive.

	; rdb_BadBlockList		; rdb_BadBlockList
Line 971:		Line 971:
	==== PartitionBlock ====		==== PartitionBlock ====

	This is the current specification for the PartitionBlock. Note that while reading these blocks you may encounter partitions that are not to be mounted because the pb_HostID does not match, or because the pb_DriveName is in use and no fallback strategy exists, or because PBFF_NOMOUNT is set, or because the proper ~~filesystem~~ cannot be found. Some partitions may be mounted but not be bootable because PBFF_BOOTABLE is not set.		This is the current specification for the PartitionBlock. Note that while reading these blocks you may encounter partitions that are not to be mounted because the pb_HostID does not match, or because the pb_DriveName is in use and no fallback strategy exists, or because PBFF_NOMOUNT is set, or because the proper file system cannot be found. Some partitions may be mounted but not be bootable because PBFF_BOOTABLE is not set.

	; pb_ID		; pb_ID
Line 1,010:		Line 1,010:
	: Filler to make 32 longwords so far.		: Filler to make 32 longwords so far.

	The specification of the location of the partition is one of the components of the environment, below. If possible, describe the partition in a manner that tells the DOS about the physical layout of the partition: specifically, where the cylinder boundaries are. This allows the ~~filesystem~~'s smart block allocation strategy to work.		The specification of the location of the partition is one of the components of the environment, below. If possible, describe the partition in a manner that tells the DOS about the physical layout of the partition: specifically, where the cylinder boundaries are. This allows the file system's smart block allocation strategy to work.

	; pb_Environment[17]		; pb_Environment[17]
Line 1,039:		Line 1,039:
	:; de_PreAlloc		:; de_PreAlloc
	:: DOS reserved blocks at end of partition.		:: DOS reserved blocks at end of partition.
	:: Valid only for ~~filesystem~~ type "DOS\1" (the fast file system). Zero otherwise.		:: Valid only for file system type "DOS\1" (the fast file system). Zero otherwise.

	:; de_Interleave		:; de_Interleave
	:: DOS interleave.		:: DOS interleave.
	:: Valid only for ~~filesystem~~ type "DOS\0" (the old file system). Zero otherwise.		:: Valid only for file system type "DOS\0" (the old file system). Zero otherwise.

	:; de_LowCyl		:; de_LowCyl
Line 1,070:		Line 1,070:

	:; de_DosType		:; de_DosType
	:: ASCII string showing ~~filesystem~~ type;		:: ASCII string showing fil esystem type;
	:: "DOS\0" ($444F5300) is old ~~filesystem~~		:: "DOS\0" ($444F5300) is old file system
	:: "DOS\1" ($444F5301) is fast file system		:: "DOS\1" ($444F5301) is fast file system
	:: "UNI(anything)" is a Unix partition		:: "UNI(anything)" is a Unix partition

Steven Solie: /* Expansion Drivers and DOS */

2015-10-02T18:35:07Z

Expansion Drivers and DOS

← Older revision		Revision as of 18:35, 2 October 2015
Line 247:		Line 247:
	ULONG de_Mask ; Address Mask to block out certain memory		ULONG de_Mask ; Address Mask to block out certain memory
	LONG de_BootPri ; Boot priority for autoboot		LONG de_BootPri ; Boot priority for autoboot
	ULONG de_DosType ; ASCII (HEX) string showing ~~filesystem~~ type;		ULONG de_DosType ; ASCII (HEX) string showing file system type;
	; 0X444F5300 is old ~~filesystem~~,		; 0X444F5300 is old file system,
	; 0X444F5301 is fast file system		; 0X444F5301 is fast file system
	ULONG de_Baud ; Baud rate for serial handler		ULONG de_Baud ; Baud rate for serial handler
	ULONG de_Control ; Control word for handler/~~filesystem~~		ULONG de_Control ; Control word for handler/file system
	; (used as ~~filesystem~~/handler desires)		; (used as file system/handler desires)
	ULONG de_BootBlocks ; Number of blocks containing boot code		ULONG de_BootBlocks ; Number of blocks containing boot code
	; (for non-AmigaDOS ~~filesystems~~)		; (for non-AmigaDOS file systems)
	LABEL DosEnvec_SIZEOF		LABEL DosEnvec_SIZEOF
	</pre>		</pre>

Steven Solie: /* Disk Based Drivers */

2014-04-25T15:21:03Z

Disk Based Drivers

← Older revision		Revision as of 15:21, 25 April 2014
Line 164:		Line 164:
	=== Disk Based Drivers ===		=== Disk Based Drivers ===

	Disk-based expansion board drivers and their icons are generally placed in the "SYS:Expansion" drawer of the user's "SYS:" disk or partition. The icon Tool Type field must contain the unique Hardware Manufacturer number, and the Product number of the expansion board(s) the driver is written for. (For more about icon Tool Type fields refer to [[~~Workbench_and_Icon_Library~~\|~~Workbench and~~ Icon Library]].)		Disk-based expansion board drivers and their icons are generally placed in the "SYS:Expansion" drawer of the user's "SYS:" disk or partition. The icon Tool Type field must contain the unique Hardware Manufacturer number, and the Product number of the expansion board(s) the driver is written for. (For more about icon Tool Type fields refer to [[Icon_Library\|Icon Library]].)

	The "BindDrivers" command issued during the disk startup-sequence attempts to match disk-based drivers with their expansion boards. To do this, "BindDrivers" looks in the Tool Types field of all icon files in "SYS:Expansion". If the Tool Type "PRODUCT" is found in the icon, then this is an icon file for a driver. "BindDrivers" will then attempt to match the manufacturer and product number in this PRODUCT Tool Type with those of a board that was configured at expansion time.		The "BindDrivers" command issued during the disk startup-sequence attempts to match disk-based drivers with their expansion boards. To do this, "BindDrivers" looks in the Tool Types field of all icon files in "SYS:Expansion". If the Tool Type "PRODUCT" is found in the icon, then this is an icon file for a driver. "BindDrivers" will then attempt to match the manufacturer and product number in this PRODUCT Tool Type with those of a board that was configured at expansion time.

Steven Solie: /* AUTOCONFIG */

2013-07-31T19:53:22Z

AUTOCONFIG

← Older revision		Revision as of 19:53, 31 July 2013
Line 10:		Line 10:
	This chapter will concentrate on the software and driver side of Zorro expansion devices, using a Zorro-II device as an example. Zorro-III devices have additional identifying bits and memory size options which are described in the Zorro-III hardware documentation. For more information on Zorro-II and Zorro-III expansion hardware, see the "Zorro Expansion Bus" appendix of the ''Amiga Hardware Reference Manual, 3rd Edition''. For additional information specific to Zorro-II boards, see the ''A500/A2000 Technical Reference Manual''.		This chapter will concentrate on the software and driver side of Zorro expansion devices, using a Zorro-II device as an example. Zorro-III devices have additional identifying bits and memory size options which are described in the Zorro-III hardware documentation. For more information on Zorro-II and Zorro-III expansion hardware, see the "Zorro Expansion Bus" appendix of the ''Amiga Hardware Reference Manual, 3rd Edition''. For additional information specific to Zorro-II boards, see the ''A500/A2000 Technical Reference Manual''.

	AUTOCONFIG occurs whenever the Amiga is powered on or reset. During early system initialization, expansion.library identifies the expansion boards that are installed in the Amiga and dynamically assigns an appropriate address range for each board to reside at. During this AUTOCONFIG process, each expansion board first appears in turn at $~~E8¬†0000~~ (Zorro-II) or $~~FF00¬†0000~~ (Zorro-III), presenting readable identification information, generally in a PAL or a ROM, at the beginning of the board. The identification includes the size of the board, its address space preferences, type of board (memory or other), and a unique Hardware Manufacturer Number assigned by the AmigaOS development team.		AUTOCONFIG occurs whenever the Amiga is powered on or reset. During early system initialization, expansion.library identifies the expansion boards that are installed in the Amiga and dynamically assigns an appropriate address range for each board to reside at. During this AUTOCONFIG process, each expansion board first appears in turn at $E80000 (Zorro-II) or $FF000000 (Zorro-III), presenting readable identification information, generally in a PAL or a ROM, at the beginning of the board. The identification includes the size of the board, its address space preferences, type of board (memory or other), and a unique [[Amiga_Hardware_Manufacturer_ID_Registry\|Hardware Manufacturer Number]] assigned by the AmigaOS development team.

	The unique Hardware Manufacturer number, in combination with a vendor-supplied product number, provides a way for boards to be identified and for disk-based drivers to be matched with expansion boards. All expansion boards for the Amiga must implement the AUTOCONFIG protocol.		The unique Hardware Manufacturer number, in combination with a vendor-supplied product number, provides a way for boards to be identified and for disk-based drivers to be matched with expansion boards. All expansion boards for the Amiga must implement the AUTOCONFIG protocol.

Steven Solie at 19:49, 31 July 2013

2013-07-31T19:49:50Z

← Older revision		Revision as of 19:49, 31 July 2013
Line 1,237:		Line 1,237:
	No more entries need exist than those implied by fse_PatchFlags, so entries do not have a fixed size.		No more entries need exist than those implied by fse_PatchFlags, so entries do not have a fixed size.

	For additional information on initializing and booting a Rigid Disk Block filesystem device, see the [[SCSI_Device\|SCSI Device]]. Writers of drivers for expansion devices that perform their own DMA (direct memory access) should consult the Exec chapters and Autodocs for information on ~~Release 2~~ processor cache control functions including CachePreDMA() and CachePostDMA().		For additional information on initializing and booting a Rigid Disk Block filesystem device, see the [[SCSI_Device\|SCSI Device]]. Writers of drivers for expansion devices that perform their own DMA (direct memory access) should consult the Exec chapters and Autodocs for information on processor cache control functions including CachePreDMA() and CachePostDMA().

	See the following include files for additional notes and related structures: <libraries/configvers.h>, <libraries/configregs.h>, <devices/hardblocks.h>, <resources/filesysres.h> and <libraries/filehandler.h>.		See the following include files for additional notes and related structures: <libraries/configvers.h>, <libraries/configregs.h>, <devices/hardblocks.h>, <resources/filesysres.h> and <libraries/filehandler.h>.

Steven Solie: /* ROM Based and Autoboot Drivers */

2013-07-31T19:48:31Z

ROM Based and Autoboot Drivers

Show changes