NFG Games + GameSX

User Tools

Site Tools

Trace:
x68000:writing_drivers

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
x68000:writing_drivers [2014/07/11 00:04] – eidisx68000:writing_drivers [2019/08/27 20:45] (current) – external edit 127.0.0.1
Line 2: Line 2:
  
 The following information was kindly contributed by our forum member **Lydux**. The following information was kindly contributed by our forum member **Lydux**.
 +
 +Original thread can be found here:
 +http://nfggames.com/forum2/index.php?topic=5417.0
  
 So I've decided to share with you some of my study and work. So I've decided to share with you some of my study and work.
Line 13: Line 16:
  
 **Note :** the following contains very hard stuff ! I might be confusing sometimes, sorry in advance. Don't hesitate to ask for help if you do not understand something. Thank you. **Note :** the following contains very hard stuff ! I might be confusing sometimes, sorry in advance. Don't hesitate to ask for help if you do not understand something. Thank you.
- 
  
 **Terminology :** **Terminology :**
Line 21: Line 23:
   * Char : 1 character = 1 byte   * Char : 1 character = 1 byte
   * All data types are CPU specific : M68K family. So, byte ordering is always "Big Endian" and a pointer is 32 bits (long).   * All data types are CPU specific : M68K family. So, byte ordering is always "Big Endian" and a pointer is 32 bits (long).
- 
  
 ====== Compilation flags, libraries and startup code ====== ====== Compilation flags, libraries and startup code ======
Line 89: Line 90:
 **Command execution result flags :** **Command execution result flags :**
  
-This list contains all acceptable values to fill the result status flags in the request packet header. S_**** flags will display (or hide) the "A"bort, "R"etry and "I"gnore line, and E_**** will show an appropriate error message. "Result status" member can be any combination of S_**** flags (ORed together), but only one E_**** can be set.+This list contains all acceptable values to fill the result status flags in the request packet header. S_**** flags will display (or hide) the "A"bort, "R"etry and "I"gnore line, and E_**** will show an appropriate error message. 
 + 
 +"Result status" member can be any combination of S_**** flags (ORed together), but only one E_**** can be set.
  
   * 0x1000 - S_ABORT : "A"bort the whole request.   * 0x1000 - S_ABORT : "A"bort the whole request.
Line 140: Line 143:
 |  14  |  Long  |Pointer to the end of the used memory space. This memory space include every segment sizes used by the driver : TEXT, DATA, BSS, as well as eventual HEAP. A very important parameter ! Any wrong value written here will crash the kernel. Normally, my toolchain provides a symbol usable for this parameter : "_end". "_end" points to the last byte of the relocated BSS segment, so you can directly pass its address if you don't use HEAP, or pass "_end" address + the amount of memory you need for HEAP. See DDK samples for more infos.  | |  14  |  Long  |Pointer to the end of the used memory space. This memory space include every segment sizes used by the driver : TEXT, DATA, BSS, as well as eventual HEAP. A very important parameter ! Any wrong value written here will crash the kernel. Normally, my toolchain provides a symbol usable for this parameter : "_end". "_end" points to the last byte of the relocated BSS segment, so you can directly pass its address if you don't use HEAP, or pass "_end" address + the amount of memory you need for HEAP. See DDK samples for more infos.  |
 |  18  |  Long  |Block device driver only. Pointer to an array of BPB (Bios Parameter Block). Basically, a BPB describes the FAT volume on the physical disk, so determine the size of a partition or media. For more information about BPB, see wikipedia : http://en.wikipedia.org/wiki/BIOS_parameter_block Note that the X68000 BPB is slightly different than PC BPB. I will describe it later.  | |  18  |  Long  |Block device driver only. Pointer to an array of BPB (Bios Parameter Block). Basically, a BPB describes the FAT volume on the physical disk, so determine the size of a partition or media. For more information about BPB, see wikipedia : http://en.wikipedia.org/wiki/BIOS_parameter_block Note that the X68000 BPB is slightly different than PC BPB. I will describe it later.  |
-  
  
-  
 ===== 0x01 - Media Check ===== ===== 0x01 - Media Check =====
- 
  
 **Command ID :** 0x01 (C_MEDIACHK) **Command ID :** 0x01 (C_MEDIACHK)
Line 158: Line 158:
  
   
-Output parameters :+**Output parameters :**
  
 ^  Position  ^  Type  ^  Description  ^ ^  Position  ^  Type  ^  Description  ^
 |  14  |  Byte  |Media status. Possible values are :  | |  14  |  Byte  |Media status. Possible values are :  |
-|  |  |-1 - M_CHANGED : Media was changed  | +|  |  -1  |M_CHANGED : Media was changed  | 
-|  |  |0 - M_DONT_KNOW : Media state unknown  | +|  |  0  |M_DONT_KNOW : Media state unknown  | 
-|  |  |1 - M_NOT_CHANGED : Media still in and ready  |+|  |  1  |M_NOT_CHANGED : Media still in and ready  | 
 + 
 +**Human68K standard media type list :**
  
-Human68K standard media type list : 
 Note : this list isn't exhaustive ! A driver can provide its own set. So, a program or driver should never rely on these values to determine the media type. Note : this list isn't exhaustive ! A driver can provide its own set. So, a program or driver should never rely on these values to determine the media type.
 +
 I will not explain them, names pretty much speak for themselves. I will not explain them, names pretty much speak for themselves.
  
-    0xE0 - MD_2DD_10 +  * 0xE0 - MD_2DD_10 
-    0xE5 - MD_1D_9 +  * 0xE5 - MD_1D_9 
-    0xE6 - MD_2D_9 +  * 0xE6 - MD_2D_9 
-    0xE7 - MD_1D_8 +  * 0xE7 - MD_1D_8 
-    0xE8 - MD_2D_8 +  * 0xE8 - MD_2D_8 
-    0xEA - MD_2HT +  * 0xEA - MD_2HT 
-    0xEB - MD_2HS +  * 0xEB - MD_2HS 
-    0xEC - MD_2HDE +  * 0xEC - MD_2HDE 
-    0xEE - MD_1DD_9 +  * 0xEE - MD_1DD_9 
-    0xEF - MD_1DD_8 +  * 0xEF - MD_1DD_8 
-    0xF4 - MD_DAT +  * 0xF4 - MD_DAT 
-    0xF5 - MD_CDROM +  * 0xF5 - MD_CDROM 
-    0xF6 - MD_MO +  * 0xF6 - MD_MO 
-    0xF7 - MD_SCSIHD +  * 0xF7 - MD_SCSIHD 
-    0xF8 - MD_SASIHD +  * 0xF8 - MD_SASIHD 
-    0xF9 - MD_RAMDISK +  * 0xF9 - MD_RAMDISK 
-    0xFA - MD_2HQ +  * 0xFA - MD_2HQ 
-    0xFB - MD_2DD_8 +  * 0xFB - MD_2DD_8 
-    0xFC - MD_2DD_9 +  * 0xFC - MD_2DD_9 
-    0xFD - MD_2HC +  * 0xFD - MD_2HC 
-    0xFE - MD_2HD+  * 0xFE - MD_2HD
  
  
Line 196: Line 198:
  
  
-Command ID : 0x02 (C_BLDBPB) +**Command ID :** 0x02 (C_BLDBPB)
-Availability : Block +
-Description :This command is proceed when a media have previously been reported as "changed" by the "Media Check" command code. It's used to fetch the newer unit BPB. +
-Input parameters :none +
-Output parameters : +
-Position Type Description +
-18 Long Pointer to the requested unit BPB+
  
-0x03 - IOCTL input +**Availability :** Block 
-Command ID : 0x03 (C_IOCTLIN) + 
-Availability : Block/Character +**Description :** This command is proceed when a media have previously been reported as "changed" by the "Media Check" command code. It's used to fetch the newer unit BPB. 
-Description :Request the driver to read raw arbitrary datas from the specified unit. This request is initiated by an userspace application (IOCTL). + 
-Input parameters : +**Input parameters :** none 
-Position Type Description + 
-14 Long Pointer to a buffer that'll contain readed data from the unit. The driver is responsible of filling this buffer. +**Output parameters :** 
-18 Long Buffer size + 
-Output parameters :none+^  Position  ^  Type  ^  Description  ^ 
 +|  18  |  Long  |  Pointer to the requested unit BPB  | 
 +  
 + 
 +===== 0x03 - IOCTL input ===== 
 + 
 +**Command ID :** 0x03 (C_IOCTLIN) 
 + 
 +**Availability :** Block/Character 
 + 
 +**Description :** Request the driver to read raw arbitrary datas from the specified unit. This request is initiated by an userspace application (IOCTL). 
 + 
 +**Input parameters :** 
 + 
 +^  Position  ^  Type  ^  Description  ^ 
 +|  14  |  Long  |Pointer to a buffer that'll contain readed data from the unit. The driver is responsible of filling this buffer.  | 
 +|  18  |  Long  |Buffer size  | 
 +  
 +**Output parameters :** none 
 + 
 +===== 0x04 - Input (read) ===== 
 + 
 +**Command ID :** 0x04 (C_INPUT) 
 + 
 +**Availability :** Block/Character 
 + 
 +**Description :** Request the driver to read data from the specified unit. This request is initiated by the kernel. 
 + 
 +**Input parameters :** 
 + 
 +^  Position  ^  Type  ^  Description  ^ 
 +|  13  |  Byte  |Block device driver only. Media type.  |     
 +|  14  |  Long  |Pointer to a buffer that'll contain the readed data from the unit.The driver is responsible of filling this buffer.  | 
 +|  18  |  Long  |Block device driver : number of sector to read. A sector length is normally specified by the BPB.  | 
 +| | |Character device driver : Buffer size.  |  
 +|  22  |  Long  |Block device driver only : logical start sector to read from.  |
  
-0x04 - Input (read) +**Output parameters :** none
-Command ID : 0x04 (C_INPUT) +
-Availability : Block/Character +
-Description :Request the driver to read data from the specified unit. This request is initiated by the kernel. +
-Input parameters : +
-Position Type Description +
-13 Byte Block device driver only. Media type. +
-14 Long Pointer to a buffer that'll contain the readed data from the unit.The driver is responsible of filling this buffer. +
-18 Long Block device driver : number of sector to read. A sector length is normally specified by the BPB. +
-Character device driver : Buffer size. +
-22 Long Block device driver only : logical start sector to read from. +
-Output parameters :none+
  
 Note for block device driver : as the kernel is responsible for handling the FAT, you just have to seek to the specified start sector location and read the wanted amount of data from there according to the requested amount of sectors and the BPB. However, the driver is still responsible of the logical to physical partition translation ! So, seek correctly. Note for block device driver : as the kernel is responsible for handling the FAT, you just have to seek to the specified start sector location and read the wanted amount of data from there according to the requested amount of sectors and the BPB. However, the driver is still responsible of the logical to physical partition translation ! So, seek correctly.
  
-0x05 - Read no wait +===== 0x05 - Read no wait =====
-Command ID : 0x05 (C_NDREAD) +
-Availability : Character +
-Description :To check furthermore. A strange command code that allow a driver to send back a device prereaded byte. Maybe dedicated command to some simple interrupt driven device. +
-Input parameters :none +
-Output parameters : +
-Position Type Description +
-13 Byte Prereaded byte+
  
-0x05 - Drive control/Status packet +**Command ID :** 0x05 (C_NDREAD)
-Command ID : 0x05 (C_DRVCTL) +
-Availability : Block +
-Description : To check furthermore. This seems to be really X68000 specific floppy drive command, or some kind of kernel hack by Human68k developpers. It does some kind of IOCTL, but internally to the kernel to dis/allow and control of FDD ejection, LEDs or media write protection control...+
  
-0x06 - Input status +**Availability :** Character
-Command ID : 0x06 (C_ISTAT) +
-Availability : Character +
-Description :Kernel perform this command before the INPUT one to check if reading on the specified unit is actually possible or not. There is no parameter. Just fill the result flags in the request packet header accordingly. +
-Input parameters :none +
-Output parameters :none+
  
-0x07 - Input flush +**Description :** To check furthermore. A strange command code that allow a driver to send back a device prereaded byte. Maybe dedicated command to some simple interrupt driven device.
-Command ID : 0x07 (C_IFLUSH) +
-Availability : Character +
-Description :Request the driver to flush the specified unit input buffer. There is no parameter. Just fill the result flags in the request packet header accordingly. +
-Input parameters :none +
-Output parameters :none+
  
-0x08 - Output (write) +**Input parameters :** none 
-Command ID : 0x08 (C_OUTPUT) + 
-Availability : Block/Character +**Output parameters :** 
-Description :Request the driver to write data to a specified unit. This request is initiated by the kernel. + 
-Input parameters : +^  Position  ^  Type  ^  Description  ^ 
-Position Type Description +|  13  |  Byte  |Prereaded byte  | 
-14 Long Pointer to a buffer that contains data to write to the unit. + 
-18 Long Block device driver : number of sector to write. A sector length is normally specified by the BPB. +===== 0x05 - Drive control/Status packet ===== 
-Character device driver : Buffer size. + 
-22 Long Block device driver only : logical start sector to write to. +**Command ID :** 0x05 (C_DRVCTL) 
-Output parameters :none+ 
 +**Availability :** Block 
 + 
 +**Description :** //To check furthermore.// This seems to be really X68000 specific floppy drive command, or some kind of kernel hack by Human68k developpers. It does some kind of IOCTL, but internally to the kernel to dis/allow and control of FDD ejection, LEDs or media write protection control... 
 + 
 +===== 0x06 - Input status ===== 
 + 
 +**Command ID :** 0x06 (C_ISTAT) 
 + 
 +**Availability :** Character 
 + 
 +**Description :** Kernel perform this command before the INPUT one to check if reading on the specified unit is actually possible or not. There is no parameter. Just fill the result flags in the request packet header accordingly. 
 + 
 +**Input parameters :** none 
 + 
 +**Output parameters :** none 
 + 
 +===== 0x07 - Input flush ===== 
 + 
 +**Command ID :** 0x07 (C_IFLUSH) 
 + 
 +**Availability :** Character 
 + 
 +**Description :** Request the driver to flush the specified unit input buffer. There is no parameter. Just fill the result flags in the request packet header accordingly. 
 + 
 +**Input parameters :** none 
 + 
 +**Output parameters :** none 
 + 
 +===== 0x08 - Output (write) ===== 
 + 
 +**Command ID :** 0x08 (C_OUTPUT) 
 + 
 +**Availability :** Block/Character 
 + 
 +**Description :** Request the driver to write data to a specified unit. This request is initiated by the kernel. 
 + 
 +**Input parameters :** 
 + 
 +^  Position  ^  Type  ^  Description  ^ 
 +|  14  |  Long  |Pointer to a buffer that contains data to write to the unit.| 
 +|  18  |  Long  |Block device driver : number of sector to write. A sector length is normally specified by the BPB.  | 
 +| | |Character device driver : Buffer size.  |  
 +|  22  |  Long  |Block device driver only : logical start sector to write to.  |  
 + 
 +**Output parameters :** none
  
 Note for block device driver : as the kernel is responsible for handling the FAT, you just have to seek to the specified start sector location and read the wanted amount of data from there according to the requested amount of sectors and the BPB. However, the driver is still responsible of the logical to physical partition translation ! So, seek correctly. Note for block device driver : as the kernel is responsible for handling the FAT, you just have to seek to the specified start sector location and read the wanted amount of data from there according to the requested amount of sectors and the BPB. However, the driver is still responsible of the logical to physical partition translation ! So, seek correctly.
  
-0x09 - Output with verify +===== 0x09 - Output with verify =====
-Command ID : 0x09 (C_OUTVFY) +
-Availability : Block/Character +
-Description : Same as "0x08 - Output (write)", but the driver must also read the data buffer back to ensure the data as been correctly written. +
-Input parameters :same as the "0x08 - Output (write)"+
  
-0x0A - Output status +**Command ID :** 0x09 (C_OUTVFY)
-Command ID : 0x0A (C_OSTAT) +
-Availability : Character +
-Description :Kernel perform this command before the OUTPUT one to check if writing to the specified unit is actually possible or not. There is no parameter. Just fill the result flags in the request packet header accordingly. +
-Input parameters :none +
-Output parameters :none+
  
-0x0B - Output flush +**Availability :** Block/Character
-Command ID : 0x0B (C_OFLUSH) +
-Availability : Character +
-Description :Request the driver to flush the specified unit output buffer. There is no parameter. Just fill the result flags in the request packet header accordingly. +
-Input parameters :none +
-Output parameters :none+
  
-0x0C - IOCTL out +**Description :** Same as "0x08 - Output (write)", but the driver must also read the data buffer back to ensure the data as been correctly written.
-Command ID : 0x0C (C_IOCTLOUT) +
-Availability : Block/Character +
-Description :Request the driver to write raw arbitrary datas to the specified unit. This request is initiated by an userspace application (IOCTL). +
-Input parameters : +
-Position Type Description +
-14 Long Pointer to a buffer that'll contain data to write to the unit. The userspace program is responsible of filling this buffer. +
-18 Long Buffer size +
-Output parameters :none+
  
-0x13 - Generic IOCTL +**Input parameters :** same as the "0x08 - Output (write)"
-Command ID : 0x13 (C_GENIOCTL) +
-Availability : Block/Character +
-Description :Perform a IOCTL command understood only by the driver and an userspace program. +
-Input parameters : +
-Position Type Description +
-14 Long Optional pointer to a buffer. That buffer is totally specific to the IOCTL command ID. +
-18 Word IOCTL command ID. There is no restriction to this value. +
-Output parameters :none+
  
 +===== 0x0A - Output status =====
 +
 +**Command ID :** 0x0A (C_OSTAT)
 +
 +**Availability :** Character
 +
 +**Description :** Kernel perform this command before the OUTPUT one to check if writing to the specified unit is actually possible or not. There is no parameter. Just fill the result flags in the request packet header accordingly.
 +
 +**Input parameters :** none
 +
 +**Output parameters :** none
 +
 +===== 0x0B - Output flush =====
 +
 +**Command ID :** 0x0B (C_OFLUSH)
 +
 +**Availability :** Character
 +
 +**Description :** Request the driver to flush the specified unit output buffer. There is no parameter. Just fill the result flags in the request packet header accordingly.
 +
 +**Input parameters :** none
 +
 +**Output parameters :** none
 +
 +===== 0x0C - IOCTL out =====
 +
 +**Command ID :** 0x0C (C_IOCTLOUT)
 +
 +**Availability :** Block/Character
 +
 +**Description :** Request the driver to write raw arbitrary datas to the specified unit. This request is initiated by an userspace application (IOCTL).
 +
 +**Input parameters :**
 +
 +^  Position  ^  Type  ^  Description  ^
 +|  14  |  Long  |Pointer to a buffer that'll contain data to write to the unit. The userspace program is responsible of filling this buffer.  |
 +|  18  |  Long  |Buffer size  |
 +
 +**Output parameters :** none
 +
 +===== 0x13 - Generic IOCTL =====
 +
 +**Command ID :** 0x13 (C_GENIOCTL)
 +
 +**Availability :** Block/Character
 +
 +**Description :** Perform a IOCTL command understood only by the driver and an userspace program.
 +
 +**Input parameters :**
 +
 +^  Position  ^  Type  ^  Description  ^
 +|  14  |  Long  |Optional pointer to a buffer. That buffer is totally specific to the IOCTL command ID.  |
 +|  18  |  Word  |IOCTL command ID. There is no restriction to this value.  |
 +
 +**Output parameters :** none
 +
 +====== Extend command code ======
  
-Extend command code 
 These following request command codes are only performed when the driver header have the "attribute" flag set with the value 0x2000 (Remote device driver). These following request command codes are only performed when the driver header have the "attribute" flag set with the value 0x2000 (Remote device driver).
 +
 I actually do not know very much about them but they seems to be really filesystem level. I actually do not know very much about them but they seems to be really filesystem level.
 +
 Here is all known command ID : Here is all known command ID :
  
-    0x40 - CR_INIT +  * 0x40 - CR_INIT 
-    0x41 - CR_SEARCH_DIR +  * 0x41 - CR_SEARCH_DIR 
-    0x42 - CR_CREATE_DIR +  * 0x42 - CR_CREATE_DIR 
-    0x43 - CR_DELETE_DIR +  * 0x43 - CR_DELETE_DIR 
-    0x44 - CR_RENAME_FILE +  * 0x44 - CR_RENAME_FILE 
-    0x45 - CR_DELETE_FILE +  * 0x45 - CR_DELETE_FILE 
-    0x46 - CR_CHMOD +  * 0x46 - CR_CHMOD 
-    0x47 - CR_FILES +  * 0x47 - CR_FILES 
-    0x48 - CR_NFILES +  * 0x48 - CR_NFILES 
-    0x49 - CR_CREATE +  * 0x49 - CR_CREATE 
-    0x4A - CR_OPEN +  * 0x4A - CR_OPEN 
-    0x4B - CR_CLOS +  * 0x4B - CR_CLOS 
-    0x4C - CR_READ +  * 0x4C - CR_READ 
-    0x4D - CR_WRITE +  * 0x4D - CR_WRITE 
-    0x4E - CR_SEEK +  * 0x4E - CR_SEEK 
-    0x4F - CR_TIMEMOD +  * 0x4F - CR_TIMEMOD 
-    0x50 - CR_GETCAP +  * 0x50 - CR_GETCAP 
-    0x51 - CR_CONTROL +  * 0x51 - CR_CONTROL 
-    0x52 - CR_BUILD_BPB +  * 0x52 - CR_BUILD_BPB 
-    0x53 - CR_IOCTL_IN +  * 0x53 - CR_IOCTL_IN 
-    0x54 - CR_IOCTL_OUT +  * 0x54 - CR_IOCTL_OUT 
-    0x55 - CR_IOCTL_SPECIAL +  * 0x55 - CR_IOCTL_SPECIAL 
-    0x56 - CR_ABORT +  * 0x56 - CR_ABORT 
-    0x57 - CR_MEDIA_CHECK +  * 0x57 - CR_MEDIA_CHECK 
-    0x58 - CR_LOCK+  * 0x58 - CR_LOCK
  
 I do have parameters. I will write them later. I do have parameters. I will write them later.
  
  
-BIOS Parameter Block (BPB)+====== BIOS Parameter Block (BPB) ====== 
 I will not explain this structure as there is plenty of informations about it on the internet. I will not explain this structure as there is plenty of informations about it on the internet.
 +
 Starting from wikipedia : http://en.wikipedia.org/wiki/BIOS_parameter_block Starting from wikipedia : http://en.wikipedia.org/wiki/BIOS_parameter_block
 +
 Just read everything you can about FAT12 and FAT16. 95% of these also apply to Human68k. Just read everything you can about FAT12 and FAT16. 95% of these also apply to Human68k.
-Most of difference is the byte ordering, which is big endian instead of little endian. The structure is also a bit different. From my ddk.h file : 
-Code: [Select] 
  
 +Most of difference is the byte ordering, which is big endian instead of little endian. The structure is also a bit different.
 +
 +From my ddk.h file :
 +
 +<file>
 struct bpb { struct bpb {
   UWORD bpb_nbyte; /* Bytes per sector */   UWORD bpb_nbyte; /* Bytes per sector */
Line 364: Line 443:
   ULONG bpb_huge; /* Size in sectors if bpb_nsize == 0 (32 bits) */   ULONG bpb_huge; /* Size in sectors if bpb_nsize == 0 (32 bits) */
 }; };
 +</file>
  
 See ? Only the "number of FAT" and "number of reserved sectors" members are swapped. See ? Only the "number of FAT" and "number of reserved sectors" members are swapped.
  
x68000/writing_drivers.1405001093.txt.gz · Last modified: 2019/08/27 20:44 (external edit)