You will have noticed that l have avoided the topic of disk formatting.  Mainly because I did formatting of CF cards using the VCC simulator. Now that my system is about to be independent this topic needs to be tackled.

Other than floppy disks hard disk tend to come pre-formatted and the process is mainly writing key sectors with file system data. Typically this is called Logic formatting whereas floppy disks usually require physical and logical formatting.  At the moment the driver can't do that and an upgrade is required. Here is some background info from the Microware System Programmer's Manual regarding the process of disk formatting.

Full detail in the Manual (pages 11-58..61 & 11-68..72). Various implementations of OS-9 have added further SS. parameters to the list. Here some details of interest:

As you may have noticed the IDEdrv (and all RBF drivers for that matter) have two useful routines accessible using the following system calls. At the moment these two routines are empty and just return to the caller. If we don't use physical formatting on the hard disk interface I don't expect we need to add anything. But for floppy disks it does require careful study. The actual number of different parameters for floppy disks is rather large with variations in track and sectors/track numbers, single/double sided, single/double density and 3 physical disk sizes.

Anyway, I am slowly entering the stage of preparing the floppy disk interface and will have to face doing the track formatting bit. I will start with the WD2797 controller which is fairly common and should be able to read all my old 5" disks.

The IDE interface has the same logic device as present on the CPU board and it features embedded RAM large enough to hold several sectors of data so I would like to structure the interface such that the CPU only has to give a read/write command to the WD2797 fill a buffer for writing, then go to sleep and let the logic chip collect/serve bytes from/to the on-chip RAM and generate an interrupt when the process is complete. That way the CPU is free to serve other tasks most efficiently.

Formatting disks

The format utility in the CMDS directory is not available in source form unfortunately. There is a commented disassembly file from the NitrOS9 community however, which is very helpful and helps with checking which SS. codes need implementation in the IDEdrv driver.

The GetStt/SetStt routines are wildcard calls used to get or set a device's operating parameters. It may be necessary to examine or change the register stack which contains the values of MPU registers at the time of the I$GetStt or I$SetStt service request. The address of the register stack may be found in PD.RGS, located in the path descriptor.

The calling convention is consistent across all SS. codes:

• Register A = Path number (the open path to the disk device, e.g. /d0)
• Register B = Function code (the SS. constant)
• Other registers depend on the specific function code

The SS. codes are defined in the OS9Defs equate file (part of the DEFS directory). They are passed in register B to both I$GetStt (SWI2 + $8D) and I$SetStt (SWI2 + $8E).

The Three Codes Used by format

Here is a detailed breakdown of each of the three status codes:

SS.Reset — Controller Reset / Drive Restore

• Code value: $00
• Direction: I$SetStt (SetStt — sends a command to the driver)
• Purpose: Issues a hardware reset/restore to the disk controller. In the context of format, this is used at the start to recalibrate the drive — stepping the head back to track 0. On floppy-based systems with the WD1793/1773 FDC chip, this causes a Restore command to be sent, which steps the head in until Track 0 is detected.
• Registers in: A = path number, B = SS.Reset ($00)
• Registers out: None meaningful (carry clear on success, set with error code in B on failure)

This is typically the very first hardware-level call format makes, ensuring the drive is in a known state before writing begins. 

SS.WTrk — Write Track (Format a Track)

• Code value: $03
• Direction: I$SetStt (SetStt)
• Purpose: This is the most critical call for formatting. It instructs the RBF device driver to format a single track on the disk — writing the full track of sector headers (ID fields) and data fields in one disk revolution. This is the raw "write track" command that maps directly to the WD1793/1773 FDC's Write Track command.
• Registers in:
  • A = path number
  • B = SS.WTrk ($03)
  • X = address of the track format buffer (the byte stream to write, including ID address marks, sector ID fields, data address marks, and fill data)
  • Y = length of the buffer
• Registers out: Carry clear on success

The format command builds the entire track image in memory — interleaved sectors, gap bytes, address marks, sector IDs — and hands the whole thing to the driver via this call. The driver passes it straight to the FDC's Write Track command. This is why format needs to understand the disk geometry (sectors per track, interleave, side count, density) before making this call — it must construct the buffer correctly.

On some implementations, SS.DSize can also be used as a SetStt to tell the driver what size to treat the disk as — useful when initialising a hard disk partition.

How These Fit Together in format

The typical sequence format follows using these calls is:

1. Open a path to the device (e.g. /d0) in write mode
2. SS.Reset — restore drive to track 0
3. For each track, build a track image buffer in memory (sector IDs, interleave, gap fills), then call SS.WTrk (SetStt) to physically format that track
4. After all tracks are written, write the LSN 0 identification sector with all the DD.* fields (total sectors, track size, allocation map size, etc.) and the allocation map at LSN 1
5. Create the root directory at LSN 2 onwards
6. Close the path

LSN 0 contains a description of the physical and logical characteristics of the disk. These characteristics are set by the format utility program when the disk is initialized.