CPC Guide - Track format and MFM recordingPHYSICAL TRACK DATA STRUCTURE This document explains how the data is stored by the Floppy Disk Controller on a disk. It is probably only of interest to Amiga owners, since the Amiga will read raw MFM from a disk in it's encoded form and PC cannot do this. Introduction This information is useful if you wish to write a program to read CPC format disks. The PC has a Floppy Disk Controller which is similar to the FDC used in the CPC, so reading track data and sector data is very easy. The Amiga doesnt have a FDC. It has a very flexible disk controller chip which can DMA an entire track into memory in MFM encoded form. Then the data can be MFM decoded and sectors can be picked out. This means that almost any disk can be read using the Amiga. I am writing this with the Amiga in mind, although any computer which can read a track in this way could read a CPC disk. In this document the "FDC" means the Floppy Disk controller (uPD765-A or INTEL 8272) of the Amstrad CPC computer. The CPC uses Double-Density MFM disks. The CPC cannot read single Density FM disks because the FDC has not been wired up in the CPC to handle this. TRACK DATA All data is stored on the track in MFM recording format using the IBM System 3 Double Density format recording standard. This standard defines how the data is arranged on the track. It describes the data form, such as how the sectors are arranged and identified. The FDC can only read data stored using this standard data structure. It is not capable of reading disks written with other recording standards. The FDC takes each byte and MFM encodes it before writing it to the track. When decoding, a word is read from the disc and this is MFM decoded to give a byte. The MFM encoded data is a word in size for each byte. The MFM encoding makes sure that there are not two 1's in succession or there is not more than 3 zero's in succession. The exact track data structure is defined by the FDC when the track is formatted. The extra data is calculated by the FDC from data given by the user and written to the track so that the FDC can identify sectors and check that the data has been written correctly. The track data structure is shown at the end. FORMATTING A TRACK When a track is formatted the FDC initialises the track to store data. It writes a special data structure. The data structure allows the FDC to identify where the data the user wants to store is to be written. The data is also used for error checking to ensure the data is correct. When a format command is issued, the user provides information such as the number of sectors per track and the size of each sector. Then in the execution phase, the user provides the sector ID information for each sector. The FDC waits until the INDEX pulse occurs, and then it starts to write the data structure using the user information, and then puts the sector IDs in. The data structure has the following information: - synchronisation data This is needed so that the FDC can make sure the data is in the correct form, and is always the same when the data is read. It looks for this data to make sure that the bits read always come in the same order. - identification marks - sector ID information The ID information is used to uniquely identify the sector on the track. The FDC uses this information to find the correct sector. - sector data area This information is needed so the FDC knows where the data is stored for the sector described by the sector ID information which comes before it. - gaps There are gaps between the INDEX pulse from the disk drive and the first sector, and a gap between each sector, and finally a gap at the end of the track until the INDEX pulse occurs again. The user is only aware of the sector data and sector ID. They are not aware of the data structure because this is handled automatically by the FDC so there is no need for them to know about it. READING DATA When the FDC wants to read data from a track it has to do the following. Data is read as a series of 1 and 0 bits as the disk rotates in the drive. 1) Synchronise reading with the INDEX pulse from the disk drive. The INDEX is used to identify the start and end of each track. The first INDEX pulse tells the FDC to start reading data, and the second INDEX pulse tells the FDC when the track has finished. IF the FDC reaches the second INDEX pulse before it can find the start of a track it will report an error. This could mean that the track has not been formatted. There are two methods of extracting the data the FDC requires from the data stream being read. The FDC can read the entire track into it's own memory, or search for special identification values for the start of each sector. In the first method, the entire track is read in and the data may or may not be decoded. It is quite easy to check for a particular word in the data or check for a byte. In the second method, the FDC looks for a particular bit pattern as the data is being read in, and when it gets to the data it wants it will transfer this into it's buffer. MFM decoding may or may not be performed. The only time when MFM decoding is necessary is when the ID data (when a READ ID command) is performed, or when the data is being transfered from a sector. This data is the only data which is shown to the user. Each sector is marked. This is followed by the ID information and then the sector data. Before the data is used, it is checked to make sure it is correct. There are CRC values (like a checksum) for the ID information and sector data so that the FDC knows the data in those fields is correct. If there is an error the FDC will report this. If there is not an error, the FDC identifys which sector it wants to read data from by comparing the ID information on the track with the ID information provided by the user. If the information matches, it will transfer the data from the sector to the user. It does this for each sector required by the user. WRITING DATA In this case, the FDC has to identify where the data is to be written, and then convert the data being sent by the user into MFM encoded data and write it into the track. This has three stages - read the track to identify if it has been formatted - locate the sector the user wants to write data to - write the data into the sector "IBM System 34" Double Density Disk Format (MFM) Track data structure (in decoded MFM form): 60 bytes '4E' {the following is repeated for each sector:- 12 bytes '00' { { ID Field: 3 bytes 'A1' <- synchronisation byte ID 'FE' <- ID field identification byte Track # (C value) <- sector ID information Side # (H value) Sector # (R value) Length # (N value) CRC 1 <- CRC checksum of ID Field CRC 2 } 22 bytes '4E' 12 bytes '00' Data Field: 3 bytes 'A1' <- synchronisation ID 'FB' or 'FE' <- data field identification byte (FB for Data Address Mark, FE for Deleted Data address mark) Sector data (256/512/1024 bytes - depends on size specified) CRC 1 <- CRC checksum for Data Field CRC 2 24 bytes '4E' } rest of track filled with '4E' MFM is a method of encoding data written to a track. When the FDC writes the data it sends out the data in a serial form. The data is encoded so that no two 1's are adjacent, and there are no more than 3 consecutive 0's. The data written is actually twice the size of the data provided. In between each bit written is a "clock" bit and this depends on the values of the two bits. 0 c 0 -> 0 1 0 0 c 1 -> 0 0 1 1 c 0 -> 1 0 0 1 c 1 -> 1 0 1