diff --git a/ch.fat16.tex b/ch.fat16.tex
index 7c1642d..54cf63c 100644
--- a/ch.fat16.tex
+++ b/ch.fat16.tex
@@ -1,3 +1,195 @@
-\chapter{The FAT16 Filesystem and Its Emulation} \label{sec:fat16}
+\chapter{The FAT16 File System and Its Emulation} \label{sec:fat16}
+
+A file system (FS) is used by GEX to provide a comfortable access to the configuration files. By emulating a Mass Storage USB device, the module appears as a thumb drive on the host PC, and the user can edit its configuration using their preferred text editor. The FAT16 file system was selected for its simplicity and a good cross-platform support.
+
+Three variants of the FAT (File Allocation Table) file system exist: FAT12, FAT16, and FAT32. FAT12 was used on floppy disks and it is similar to FAT16, except for additional size constraints and a FAT entry packing scheme. FAT16 and FAT32 are FAT12's later developments from the time when hard disks became more common and the old addressing scheme couldn't support their larger capacity.
+
+This chapter will explain the structure of FAT16 and the challenges faced when trying to emulate it without a physical data storage.
+
+\section{The General Structure of the FAT File System}
+
+The storage medium is organized into \textit{sectors} (or \textit{blocks}), usually 512 bytes long. Those are the smallest addressing unit in the disk structure. The disk starts with a \textit{boot sector}, also called \textit{master boot record} (MBR). That is followed by optional reserved sectors, one or two copies of the file allocation table, and the root directory. All disk areas are aligned to a sector boundary:
+
+\begin{table}[h]
+ \centering
+ \begin{tabular}{ll}
+ \toprule
+ \textbf{Disk area} & \textbf{Size / Notes} \\
+ \midrule
+ Boot sector & 1 sector \\
+ Reserved sectors & optional \\
+ FAT 1 & 1 or more sectors, depends on disk size \\
+ FAT 2 & optional, a back-up copy of FAT 1 \\
+ Root directory & 1 or more sectors \\
+ Data area & Organized in \textit{clusters} \\
+ \bottomrule
+ \end{tabular}
+ \caption{\label{tab:fat16-disk-areas}Areas of a FAT-formatted disk}
+\end{table}
+
+\subsection{Boot Sector}
+
+This is a 1-sector structure which holds the OS bootstrap code for bootable disks. The first 3 bytes are a jump instruction to the actual bootstrap code located later in the sector. What matters to us when implementing the file system is that the boot sector also contains data fields describing how the disk is organized, what file system is used, who formatted it, etc. The size of the FAT and the root directory is defined here. The exact structure of the boot sector can be found in XXX\todo{add ref link} or in the attached GEX source code.
+
+\subsection{File Allocation Table}
+
+The data area of the disk is organized in clusters, logical allocation units composed of groups of sectors. The use of a larger allocation unit allows the system to use shorter addresses and thus support a larger disk capacity.
+
+The FAT acts as a look-up table combined with linked lists. In FAT16, it is organized in 16-bit fields, each corresponding to one cluster. The first two entries in the allocation table are reserved and hold special values set by the disk formatter and the host OS: a "media descriptor" 0xFFF8 and a "clean/dirty flag" 0xFFFF/0x3FFF.
+
+Files can span multiple clusters; each FAT entry either holds the address of the following file cluster, or a value with a special meaning:
+
+\begin{itemize}
+ \item 0x0000 - free cluster
+ \item 0xFFFF - last cluster of the file (still including file data!)
+ \item 0xFFF7 - bad cluster
+\end{itemize}
+
+The bad cluster mark, 0xFFF7, is used for clusters which are known to corrupt data due to a flaw in the storage medium, such us a bad memory cell.
+
+\subsection{Root Directory}
+
+The root directory has the same structure as any other directories, which reside in clusters the same way like ordinary files. The difference is that the root directory is allocated when the disk is formatted and it has a fixed and known position and size. Sub-directories are stored on the disk in a similar way to regular files, therefore they can span multiple sectors and their file count can be much larger than that of the root directory.
+
+\begin{table}
+ \centering
+ \begin{tabular}{lll}
+ \toprule
+ \textbf{Offset} & \textbf{Size (bytes)} & \textbf{Description}\\
+ \midrule
+ 0 & 8 & File name (padded with spaces) \\
+ 8 & 3 & File extension \\
+ 11 & 1 & File attributes \\
+ 12 & 10 & Reserved \\
+ 22 & 2 & Creation time \\
+ 24 & 2 & Creation date \\
+ 26 & 2 & Address of the first cluster \\
+ 28 & 4 & File size (bytes) \\
+ \bottomrule
+ \end{tabular}
+ \caption{\label{tab:fat16-dir-entry}Structure of a FAT16 directory entry}
+\end{table}
+
+A directory is organized in 32-byte entries representing individual files. Table \ref{tab:fat16-dir-entry} shows the structure of one such entry.
+
+The name and extension fields form together the well-known 8.3 filename format. Longer file names are encoded using a \textit{long file name} (LFN) scheme as special hidden entries stored in the directory table alongside the regular 8.3 entries, ensuring backward compatibility.
+
+The first byte of the file name has a special meaning:
+
+\begin{itemize}
+ \item 0x00 - indicates that there are no more files when searching the directory
+ \item 0xE5 - marks a free slot; this is used when a file is deleted
+ \item 0x05 - indicates that the first byte should actually be 0xE5, which was used in a Japanese character set.
+ \item Any other value, except 0x20 (space) and characters forbidden in a DOS file name, starts a valid file entry. Generally, only space, A-Z, 0-9, \verb|-| and \verb|_| should be used in file names for maximum compatibility.
+\end{itemize}
+
+The attributes field contains flags such as \textit{directory}, \textit{volume label}, \textit{read-only} and \textit{hidden}. Volume label is a special entry in the root directory, which defines the disk's label shown on the host PC. A file with the directory bit set is actually a pointer to a subdirectory, meaning that when we open the linked cluster, we'll find a new directory table.
+
+Figure \ref{fig:fat-example} shows a possible organization of the GEX file system with two INI files, one spanning two clusters, the other being entirely inside one. The clusters need not be used completely; an exact file size is stored in the directory entries.
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[scale=1.3] {img/fat-links.pdf}
+ \caption{\label{fig:fat-example}An example of the GEX virtual file system}
+\end{figure}
+
+
+\section{FAT16 Emulation}
+
+The FAT16 file system is relatively straightforward and easy to implement. This is the reason why an emulation driver for it was developed as part of the open-source ARM mbed DAPLink project. \todo{reference} It is used there for a drag-and-drop flashing of firmware images to the target microcontroller, taking advantage of it working well across different host platforms. ARM mbed uses a browser-based IDE and cloud build servers, thus the end user does not need to install or set up any software or drivers to program a compatible development kit. The GEX firmware adapts several parts of this code, optimizes its RAM usage and further expands its functionality to support our specific use case.
+
+It is not practical or even possible to keep the entire file system in memory, especially with a microcontroller like the STM32F072, which has only 16\,kB of RAM in total. This means that we have to generate and parse disk sectors and clusters on-demand, when the host reads or writes them. The STM32 USB Device library helpfully implements the Mass Storage USB class and provides API endpoints to which we connect our file system emulator. Specifically, those are requests to read and write a sector, and to read disk status and parameters, such as its size.
+
+As shown in table \ref{tab:fat16-disk-areas}, the disk consists of several areas. The boot sector is immutable and can be stored in Flash. The handling of the other areas (FAT, data area) depends on whether we're dealing with a read or write access:
+
+\subsection{Handling a Read Access}
+
+The user can only read files that already exist on the disk, in our case, \verb|UNITS.INI| and \verb|SYSTEM.INI|. Those files are generated from the binary settings storage, and conversely, parsed, line-by-line, without ever existing in their full form. This fact makes our task more challenging, as the files can't be easily measured and there's no obvious way to read a sector from the middle of a longer file. We solve this by implementing two additional functions in the INI file writer: a \textit{read window} and a \textit{dummy read mode}.
+
+A read window is a byte range which we wish to generate. The INI writer discards bytes before the start of the read window, writes those inside the window to our data buffer, and stops when its end is reached. This lets us extract a sector from anywhere in a file. The second function, dummy read, is tied to the window function: we set the start index so high that it's never reached (e.g. 0xFFFFFFFF), and have the writer count discarded characters. When the dummy file generation ends, this character counter holds its size.
+
+Now, just one problem remains: how to tell which sectors contain which part of our files? This is straightforward when we realize that the files change only when the user modifies the settings. After each such change, an algorithm is run which allocates clusters to the files and preserves this information in a holding structure. A subsequent read access simply requires a look into this structure and the corresponding chunk of a file may be served using the read window function. The FAT can be dynamically generated from this information as well.
+
+\subsection{Handling a Write Access}
+
+A file write access is more challenging to emulate than a read access, as the host OS tends to be somewhat unpredictable. In GEX's case we're interested only in the action of overwriting an already existing file, but it's interesting to also analyze other actions the host may perform.
+
+It must be noted that due to the nonexistence of a physical storage medium, it's not possible to read back a file the host has written. The OS may show the written file on the disk, but when the user tried to read it, it either fails, or shows a cached copy. In the DAPLink emulator this is worked around by temporarily reporting that the storage medium has been removed, forcing the host to re-load its contents. In GEX, the loaded INI file will be a newly generated copy, embedding possible error messages as comments.
+
+\subsubsection{File Deletion}
+
+A file is deleted by:
+
+\begin{enumerate}
+ \item Marking all sectors used by it as free in the FAT
+ \item Replacing the first character of its name in the directory table by 0xE5 to indicate the slot is free
+\end{enumerate}
+
+From the perspective of emulation, we can ignore the FAT access and only detect writes to the directory sectors. This is slightly more complicated when one considers that all disk access is performed in sectors: the emulator must compare the written data with the original bytes to detect what change has been performed. Alternatively, we could parse the written sector as a directory table and compare it with our knowledge of its original contents.
+
+\subsection{File Name Change}
+
+A file is renamed by modifying its directory entry. This can be be detected in a similar way to a file deletion. In the simple case of a short, 8.3 file name, this is a in-place modification of the file entry. Long file names, using the LFN extension, are a complication, as the number of dummy entries might change when the file name is shortened or made longer, and subsequently the following entries in the table may shift or be entirely re-arranged.
+
+\subsection{File Creation}
+
+A new file is created in three steps:
+
+\begin{enumerate}
+ \item Finding free clusters and chaining them by writing the following cluster addresses (or 0xFFFF for the last cluster) into the FAT
+ \item Finding and overwriting a free entry in the directory table
+ \item Writing the file content
+\end{enumerate}
+
+It can be expected the host OS first finds the free sectors and a free file entry before performing any write operations, to prevent a potential disk corruption.
+
+To properly handle such a file by the emulator, we could, in theory, find its name from the directory table, which has been updated, and then collect the data written to the corresponding clusters. In practice, confirmed by experiments with a real Linux host, those three steps may happen in any order, and often the content is written before the directory table is updated.
+
+The uncertain order of the written disk areas poses a problem when the file name has any significance, as we can't store the received file data while waiting for the name to be written. The DAPLink mbed flashing firmware solves this by analyzing the content of the first written sector of the file, which may contain the binary NVIC table, or an ASCII pattern typical for Intel hex files.
+
+\subsection{File Content Change}
+
+A change to a file's content is performed in a similar way to the creation of a new file, except instead of creating a new entry in the directory table, an existing one is updated with the new file size. The name of the file may be, again, unknown until the content is written, but we could detect the file by comparing the starting sector with those of all files known to the virtual file system.
+
+In the case of GEX, the detection of a file name is not important; We expect only INI files to be written, and the particular file may be detected by its first section marker, such as \verb|[UNITS]| or \verb|[SYSTEM]|. Should a non-INI file be written by accident, the INI parser will likely detect a syntax error and discard it.
+
+It should be noted that a file could be updated only partially, skipping the clusters which remain unchanged, and there's also no guarantee regarding the order in which the file's sectors are written. This is hard to detect and handle and the current firmware is not able to interpret it correctly, thus such a write operation will fail. Fortunately, this host behavior has not been conclusively observed in practice, but a write operation rarely fails for still unknown reasons and this could be a possible cause.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-...
\ No newline at end of file
diff --git a/ch.gex_units.tex b/ch.gex_units.tex
index e69de29..7700c25 100644
--- a/ch.gex_units.tex
+++ b/ch.gex_units.tex
@@ -0,0 +1,96 @@
+\chapter{Functional Blocks}
+
+This chapter describes all functional blocks (units) implemented in GEX at the time of publication of this work. Each unit supports a different set of binary commands and events. A complete specification of this API is attached in an electronic form. \todo{add the github docs repo as a ref}
+
+
+\section{Digital Output Unit}
+
+The digital output unit provides a write access to one or more pins of a GPIO port. The group of pins need not be contiguous (e.g. pin 0 and 6 can be accessed as a 2-bit output). All selected pins are accessed simultaneously using the port control registers.
+
+This unit additionally supports pulse generation on any of its pins. It is implemented in software with the timing derived from the system timebase, as the hardware timer outputs, otherwise used for PWM or pulse generation, are available only on several dedicated pins. Two pulse length resolutions are available, depending on the scale: microseconds for pulses shorter than 1\,ms, milliseconds for longer ones.
+
+\todo[inline]{Measure jitter and add it here}
+
+
+\section{Digital Input Unit}
+
+The digital input unit is the input counterpart of the digital output unit.
+
+In addition to reading the immediate digital levels of the selected pins, this unit can generate asynchronous events on a pin change. The state of the entire input port, together with a microsecond timestamp (as is the case for all asynchronous events), is reported to the host either on a rising, falling, or any pin change.
+
+The pin change event can be configured independently for each pin. In order to receive a pin change event, it must be armed first; The pin can be armed for a single event, or it may be re-armed automatically with a hold-off time. It's further possible to automatically arm selected pin triggers on start-up.
+
+
+\section{Shift Registers Driver Unit}
+
+The shift registers driver unit is designed for the loading of data into \textit{serial-in, parallel-out} (SIPO) shift registers, such as 74HC4094 or 74HC595. Those are commonly used to control segmented LED displays, LED matrices etc.
+
+This unit handles both the \textit{Shift} and \textit{Store} signals and is capable of loading multiple shift registers simultaneously, reducing visible glitches in the display. It's also possible to set the data lines to arbitrary level(s) before sending the Store pulse, which can be latched and used for some additional feature of the LED display, such as brightness control.
+
+
+\section{NeoPixel Unit}
+
+The NeoPixel unit implements the protocol needed to control a digital LED strip with WS2812, WS2811, or compatible LED driver chips. The protocol timing is implemented in software, therefore it is available on any GPIO pin of the module. The unit accepts sequences of RGB color values from the host and loads them into the LED strip.
+
+
+\section{SPI Unit}
+
+The SPI unit provides access to one of the microcontroller's SPI peripherals. It can be configured to use any of the different speeds, clock polarity and phase settings available in its control registers. The unit handles up to 16 slave select (NSS) signals.
+
+Both write-only and read-write (query) transactions are implemented.
+
+\todo[inline]{Query diagram}
+
+
+\section{I2C Unit}
+
+The I2C unit provides access to one of the microcontroller's I2C peripherals. It can be configured to use either of the three speeds (Standard, Fast and Fast+) and supports both 10-bit and 8-bit addressing.
+
+
+\section{USART Unit}
+
+The USART unit provides access to one of the microcontroller's USART peripherals. All USART parameters can be configured to match the application's needs.
+
+The clock output and hardware flow control may be enabled, as well as the Driver Enable (DE) output used by RS485 transceivers to switch between a reception and transmission mode.
+
+
+\section{1-Wire Unit}
+
+The 1-Wire unit implements the Dallas Semiconductor's 1-Wire protocol, most commonly used to interface smart thermometers (DS18x20). The protocol is explained in section \ref{sec:theory-1wire}. This unit implements the basic protocol, as well as the ROM Search algorithm used to recognizes all unique 1-Wire devices connected to the bus.
+
+
+\section{Frequency Capture Unit}
+
+The frequency capture unit implements both the frequency measurement methods explained in section \ref{sec:theory-fcap}: direct and reciprocal. It can be operated in an on-demand or continuous measurement mode. The unit can be switched to two other modes: pulse counter, and the measurement of a single pulse.
+
+
+\section{ADC Unit}
+
+The analog/digital converter unit is one of the most complicated units implemented in the project. The unit can measure the voltage on an input pin, either as its immediate value, or averaged with exponential forgetting. Isochronous sampling is available as well: It's possible to capture a fixed-length block of data on demand, or as a response to a triggering condition on any of the enabled input pins. The ADC must continuously sample the inputs to make the averaging and level based triggering possible; As a consequence, a pre-trigger buffer is available that can be read together with the block of samples following a trigger. The ADC unit can also be switched to a continuous streaming mode.
+
+It's possible to activate any number of the 16 analog inputs of the ADC peripheral simultaneously. The maximum continuous sampling frequency, which reaches 70\,ksps with one channel, lowers with an increasing number of enabled channels as the amount of data to transfer to the host increases.
+
+
+\section{DAC Unit}
+
+The digital/analog unit works with the two-channel DAC peripheral of the microcontroller. It can be used in two modes: DC output, and waveform generation.
+
+The waveform mode implements direct digital synthesis (explained in section \ref{sec:theory-dac-dds}) of a sine, rectangle, sawtooth or triangle wave. The generated frequency can be set with a sub-hertz precision up to the lower tens of kHz. The two outputs can use a different waveform shape, be synchronized, and their phase offset, as well as frequency, is dynamically adjustable.
+
+
+\section{PWM Unit}
+
+The PWM unit uses a timer/counter to generate a PWM signal. There are four outputs with a common frequency and phase, but independent duty cycles. Each channel can be individually enabled or disabled.
+
+This unit is intended for applications like light dimming, heater regulation, or the control of H-bridges.
+
+
+\section{Touch Sensing Unit}
+
+The touch sensing unit provides an access to the touch sensing controller. Its function is explained in section \ref{sec:theory-touch}. The unit configures the TSC and reads the output values of each enabled touch pad.
+
+
+
+
+
+
diff --git a/ch.hw_buses.tex b/ch.hw_buses.tex
index fa0285f..7dda2b0 100644
--- a/ch.hw_buses.tex
+++ b/ch.hw_buses.tex
@@ -2,7 +2,7 @@
Hardware buses implemented in GEX are presented in this chapter. The description of each bus is accompanied by several examples of devices that can be interfaced with it. The reader is advised to consult the official specifications and particular devices' datasheets for additional technical details.
-\section{UART and USART}
+\section{UART and USART} \label{sec:theory-usart}
The \textit{Universal Synchronous / Asynchronous Receiver Transmitter} has a long history and is still in widespread use today. It is the protocol used in RS-232, which was once a common way of connecting modems, printers, mice and other devices to personal computers. UART framing is also used in the industrial bus RS-485.
@@ -27,7 +27,7 @@ RS-232 uses the UART framing, but its logic levels are different: logical 1 is r
\item \textbf{MFRC522} - NFC MIFARE reader/writer IC (also supports other interfaces)
\end{itemize}
-\section{SPI}
+\section{SPI} \label{sec:theory-spi}
SPI (Serial Peripheral Interface) is a point-to-point or multi-drop master-slave interface based on shift registers. The SPI connection with multiple slave devices is depicted in figure \ref{fig:spi-multislave}. It uses at least 4 wires: SCK (Serial Clock), MOSI (Master Out Slave In), MISO (Master In Slave Out) and SS (Slave Select). SS is often marked CSB (Chip Select Bar) or NSS (Negated Slave Select) to indicate it's active low. Slave devices are addressed using their Slave Select input while the data connections are shared. A slave that's not addressed releases the MISO line to a high impedance state so it doesn't interfere in ongoing communication.
@@ -57,7 +57,7 @@ SPI devices often provide a number of control, configuration and status register
\item SPI-interfaced EEPROMs and Flash memories
\end{itemize}
-\section{I2C}
+\section{I2C} \label{sec:theory-i2c}
I2C is a two-wire (SDA--\textit{Serial Data}, SCL--\textit{Serial Clock}), open-drain bus that supports multi-master operation. The protocol was developed by Philips Semiconductor (now NXP Semiconductors) and until 2006 implementors were required to pay licensing fees, leading to the development of compatible implementations with different names, such as Atmel's Two Wire Interface (TWI) or Dallas Semiconductor's "Serial 2-wire Interface" (e.g. used in the DS1307 RTC chip). I2C is the basis of the SMBus and PMBus protocols which add additional constraints and rules for a more robust operation.
@@ -81,7 +81,7 @@ The bus supports multi-master operation, which leads to the problem of collision
\item Cameras with an SCCB port can be accessed through I2C
\end{itemize}
-\section{1-Wire}
+\section{1-Wire} \label{sec:theory-1wire}
The 1-Wire bus, developed by Dallas Semiconductor, uses a single bi-directional data line which can also power the slave devices, reducing the number of required wires to just two (compare with 3 in I2C and 5 in SPI, all including GND).
@@ -111,7 +111,7 @@ Since 1-Wire is a proprietary protocol, there is a much smaller choice of availa
\caption{\label{fig:1w-pulses}The 1-Wire DIO pulse timing (by \textit{Dallas Semiconductor})}
\end{figure}
-\section{NeoPixel}
+\section{NeoPixel} \label{sec:theory-neo}
NeoPixel is a marketing name of the \textbf{WS2811}, \textbf{WS2812} and compatible intelligent LED drivers that is commonly used in "addressable LED strips". Those chips include the control logic, PWM drivers and usually the LED diodes all in one miniature package.
diff --git a/ch.hw_functions.tex b/ch.hw_functions.tex
index 71e9199..1eda0c2 100644
--- a/ch.hw_functions.tex
+++ b/ch.hw_functions.tex
@@ -2,7 +2,7 @@
In addition to communication buses, described in chapter \ref{ch:hw_buses}, GEX implements several measurement and output functions that take advantage of the microcontroller's peripheral blocks, such as timers/counters and DAC. The more complicated ones are described here; simpler functions, such as the raw GPIO access, will be described later together with their control API.
-\section{Frequency Measurement}
+\section{Frequency Measurement} \label{sec:theory-fcap}
Applications like motor speed measurement and the reading of a VCO (voltage-controlled-oscillator) or VCO-based sensor's output demand a tool capable of measuring frequency. This can be done using a laboratory instrument such as the Agilent 53131A. A low cost solution is to use a timer/counter peripheral of a microcontroller, such as the STM32F072 used in GEX.
@@ -48,13 +48,19 @@ A good approach to a universal measurement, when we don't know the expected freq
The system clock's frequency, which we use to measure pulse lengths and to gate the pulse counter, will be affected by tolerances of the used components, the layout of the PCB, temperature effects etc., causing measurement errors. A higher accuracy could be achieved using a temperature-compensated oscillator (TCO), or, in the direct method, by using the synchronization pulse provided by a GPS receiver to time the measurement interval.
-\section{Waveform Generation}
+
+\section{Analog Signal Acquisition} \label{sec:theory-adc}
+
+\todo[inline]{Explain ADC operation and basic concepts / types}
+
+
+\section{Waveform Generation} \label{sec:theory-dac}
A waveform generator is a useful tool in many experiments and measurements. A sine stimulus is the basis of a lock-in amplifier; it can be used to measure impedance; with a frequency sweep, we can obtain the frequency response of an analog filter, etc. We can, of course, generate other waveforms, such as a triangle, ramp, or rectangle wave.
The DAC peripheral can produce a DC level on the output pin based on a control word. When we periodically change its digital input, it produces an analog waveform.
-\subsection{Waveform Generation with DMA and a Timer}
+\subsection{Waveform Generation with DMA and a Timer} \label{sec:theory-dac-simple}
A straightforward implementation of the waveform generator is illustrated in figure \ref{fig:wavegen-naive}. This approach has its advantages: it's simple and works entirely in the background, with no interrupt handling required. It could even be implemented entirely in software, using a loop periodically updating the DAC values, of course such approach is less flexible and we would run into problems with asynchronous interrupts.
@@ -68,7 +74,7 @@ The highest achievable output frequency largely depends on the size of our look-
A major disadvantage of this simple generation method is given by the limitations of the used timer, which defines the output frequency. Its output trigger fires when the internal counter reaches a pre-defined value, after which the counting register is reset. The counting speed is derived from the system clock frequency $f_\mathrm{c}$ using a prescaller $P$ and the set maximum value $N$. Only output frequencies that can be exactly expressed as $f=f_\mathrm{c}/(P\cdot N \cdot \mathrm{TableSize})$ can be accurately produced. Still, this simple and efficient method may be used where fine tuning is not required to take advantage of its fully asynchronous operation.
-\subsection{Direct Digital Synthesis}
+\subsection{Direct Digital Synthesis} \label{sec:theory-dac-dds}
There are situations where the simple waveform generation method is not sufficient, particularly when a fine tuning or on-line frequency and phase changes are required. Those are the strengths of a signal generation method called \textit{Direct Digital Synthesis} (DDS).
@@ -89,11 +95,35 @@ DDS may be implemented in hardware, including the look-up table, often together
\todo[inline]{screenshots of a real demo, also reference to all-about-direct-digital-synthesis.pdf}
+\section{Touch Sensing} \label{sec:theory-touch}
+The used microcontroller, STM32F072, includes a touch sensing controller (TSC) peripheral block. It can be accessed from GEX as a demonstration of capacitive touch sensing, and could possibly be used for simple touch sensors as well, such as measuring the level of water in a tank.
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=0.5\textwidth] {img/disco-touch.jpg}
+ \caption{\label{fig:disco-touch}The touch slider on a STM32F072 Discovery board}
+\end{figure}
+
+The TSC requires a specific topology with a sampling capacitor connected close to the microcontroller pin, which may not be possible on a universal GEX module; for this reason, the touch sensing feature is best demonstrated on the STM32F072 Discovery development kit, which includes a 4-segment touch slider shown in figure \ref{fig:disco-touch}.
+The principle of capacitive touch sensing is well explained in the microcontroller's reference manual \todo{ref}. A key part of the TSC is a set of analog switches, which can be combined to form several different signal paths between the external pins, Vdd, GND, and an analog comparator. Two input pins are needed for every touch sensing channel: the sensing pad connects to one, the other is connected through a sampling capacitor (47\,nF on the Discovery board) to GND.
+Capacitive sensing is a sequential process described in the following steps:
+\begin{enumerate}
+ \item The sensing capacitor is discharged by connecting its free end to GND.
+ \item The sensing pad is connected to Vdd and, acting as a capacitor, charged to 3.3\,V. It stores a small amount of charge, depending on its capacitance---this is the variable property we are trying to measure.
+ \item The free terminals of the two capacitors (the sensing pad and the sampling capacitor) are connected together and their voltages reach an equilibrium as a portion of the stored charge leaves the sensing pad and flows into the bigger capacitor.
+ \item The steps (2) and (3) are repeated the sampling capacitor's voltage exceeds a fixed threshold (set to a half of the supply voltage). The number of cycles needed to charge the sampling capacitor corresponds to the capacitance of the sensing pad.
+\end{enumerate}
+\begin{figure}
+ \centering
+ \includegraphics[width=.9\textwidth] {img/tsc-wfm-bw.png} \\
+ \vspace{5mm}
+ \includegraphics[width=.9\textwidth] {img/tsc-wfm2-bw.png}
+ \caption{\label{fig:tsc-wfm}A voltage waveform measured on the touch sensing pad. The bottom side of the envelope equals the sampling capacitor's voltage---this is the phase where both capacitors are connected. The detailed view (middle) shows the individual charging cycles. The bottom screenshot captures the entire waveform after the analog comparator was disabled.}
+\end{figure}
diff --git a/ch.tinyframe.tex b/ch.tinyframe.tex
index 729ea1f..ebdffdf 100644
--- a/ch.tinyframe.tex
+++ b/ch.tinyframe.tex
@@ -4,7 +4,7 @@ GEX can be controlled through a hardware UART, the USB or over a wireless link.
The communication is organized in transactions. A transaction consists of one or more messages going in either direction. Messages can be stand-alone, or chained with a response or a follow-up message using the transaction ID. Both peers, GEX and the client application running on the PC, are equal in the communication: either side can independently initiate a transaction at any time.
-GEX uses a framing library \textit{TinyFrame}, developed likewise by the author, but kept as a separate project for easier re-use in different applications. The library implements frame building and parsing, checksum calculation and a system of message listeners. An interested reader may find more technical details and the API in its documentation.
+GEX uses a framing library \textit{TinyFrame}, developed likewise by the author but kept as a separate project for easier re-use in different applications. The library implements frame building and parsing, checksum calculation and a system of message listeners.
\section{Frame Structure}
@@ -90,11 +90,19 @@ The following table lists all frame types used by GEX. It is divided into four l
\section{Bulk Read and Write Transactions}
-The bulk read and write transactions are generic, multi-message exchanges which are used to transfer the INI configuration files. They could possibly be used by some future unit requiring to transfer a large amount of data (e.g. to read image data from a camera).
+The bulk read and write transactions are generic, multi-message exchanges which are used to transfer the INI configuration files. They could additionally be used by some future unit requiring to transfer a large amount of data (e.g. to read image data from a camera).
-The reason for splitting a long file into multiple messages, rather than sending it all in one, lies in the hardware limitations of the platform, specifically its small amount of RAM (the STM32F072 has only 16\,kB). A message cannot be processed until its payload checksum is received and verified; however, the configuration file can have several kilobytes, owning to the numerous explanatory comments, which would require a prohibitively large buffer. Further, the GEX module may need some time to process a part of the message before it can receive more data, which is easily achieved by this multi-part transport where each chunk must be confirmed before proceeding to the next.
+The reason for splitting a long file into multiple messages, rather than sending it all in one, lies in the hardware limitations of the platform, specifically its small amount of RAM (the STM32F072 has only 16\,kB). A message cannot be processed until its payload checksum is received and verified; however, the configuration file can have several kilobytes, owning to the numerous explanatory comments, which would require a prohibitively large data buffer. The chunked transaction could, additionally, be extended to support message re-transmission on timeout without sending the entire file again.
-A read or write transaction can be aborted by a frame 0x08 (Bulk Abort) at any time, though aborting a write transaction may leave the configuration in a corrupt state. As hinted in the introduction of this chapter, a transaction is defined by sharing a common frame ID. Thus, all frames in a bulk transaction must have the same ID, otherwise the ID listeners won't be called and the transaction will fail.
+A read or write transaction can be aborted by a frame 0x08 (Bulk Abort) at any time, though aborting a write transaction may leave the configuration in a corrupted state. As hinted in the introduction of this chapter, a transaction is defined by sharing a common frame ID. Thus, all frames in a bulk transaction must have the same ID, otherwise the ID listeners won't be called for the subsequent messages, and the transaction will time out.
+
+Figure \ref{fig:bulk-rw} shows a diagram of the bulk read and write data flow.
+
+\begin{figure}
+ \centering
+ \includegraphics[scale=1.5]{img/bulk-read-write.pdf}
+ \caption{\label{fig:bulk-rw}A diagram of the bulk read and write transaction.}
+\end{figure}
\subsection{Bulk Read}
diff --git a/ch.wireless.tex b/ch.wireless.tex
index 39e31db..8a8e83f 100644
--- a/ch.wireless.tex
+++ b/ch.wireless.tex
@@ -1,14 +1,92 @@
\chapter{Wireless Interface}
-Four methods of a wireless connection have been considered: Bluetooth (e.g. with CC2541), WiFi with ESP8266, LoRA or GFSK-modulated 868\,MHz link with SX1276, and a 2.4\,GHz link with NRF24L01+. Bluetooth was dismissed early for its complexity and ESP8266 for its high consumption in continuous reception mode, although both solutions might be viable for certain applications and with more time for evaluation. The SX1276 and NRF24L01+ have both been tested using the first GEX prototype, confirming its usefulness as a hardware development tool.
+Four methods of a wireless connection have been considered: Bluetooth (e.g. with CC2541), WiFi with ESP8266, LoRA or GFSK-modulated 868\,MHz link with SX1276, and a 2.4\,GHz link with nRF24L01+. Bluetooth was dismissed early for its complexity and ESP8266 for its high consumption in continuous reception mode, although both solutions might be viable for certain applications and with more time for evaluation.
-\section{Comparing SX1276 vs. NRF24L01+}
+The Semtech SX1276 and Nordic Semiconductor nRF24L01+ transceivers have both been tested using the first GEX prototype, confirming its usefulness as a hardware development tool, and it's been confirmed they could fulfill the requirements of the application.
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=.7\textwidth]{img/nrf-testing.jpg}
+ \caption{Test setup with a GEX prototype controlling two nRF24L01+ modules}
+\end{figure}
+\section{Comparing SX1276 vs. nRF24L01+}
+The two transceivers are compared in table \ref{fig:nrf-sx-comparison}. It's apparent that each has its strengths and weaknesses.
+\begin{table}[h]
+ \centering
+ \begin{tabulary}{\textwidth}{lLL}
+ \toprule
+ \textbf{Parameter} & \textbf{SX1276} & \textbf{nRF24L01+} \\
+ \midrule
+ \textbf{Connection} & SPI (4 pins) + up to 6 IRQ & SPI (4 pins), CE, IRQ \\
+ \textbf{Frequency band} & 868\,MHz or 433\,MHz & 2.4\,GHz \\
+ \textbf{Data rate} & up to 300\,kbps & 250--2000\,kbps \\
+ \textbf{Modulation} & (G)FSK, (G)MSK, OOK, LoRa & GFSK \\
+ % \textbf{Bandwidth} & 7--500\,kHz per channel & 0.7--2\,MHz per channel \\
+ \textbf{Range (est.)} & 2\,km to 20\,km LOS & up to 1\,km LOS \\
+ \textbf{Consumption Rx} & 10.8--12\,mA & 12.6--13.5\,mA \\
+ \textbf{Consumption Tx} & 20--120\,mA & 7--11.3\,mA \\
+ \textbf{Idle power (max)} & 1\,$\mu$A sleep, 2\,mA stand-by & 0.9\,$\mu$A sleep, 320\,$\mu$A stand-by \\
+ \textbf{Max packet size} & 300 bytes & 32 bytes \\
+ \textbf{Reset} & NRESET pin & Vdd disconnect \\
+ \textbf{Extra} & LoRa FHSS, packet engine & ShockBurst protocol engine \\
+ \textbf{Price} & \$7.3 & \$1.6 \\
+ \bottomrule
+ \end{tabulary}
+ \caption[Comparison of the SX1276 and nRF24L01+ wireless transceivers]{\label{fig:nrf-sx-comparison}Comparison of the SX1276 and nRF24L01+ wireless transceivers (price from DigiKey @ 10 pieces, May 6th 2018)}
+\end{table}
+SX1276 supports additional modulation modes, including a proprietary LoRa scheme with a frequency-hopping spread spectrum modulation that can be received at a distance up to 20\,km in ideal conditions. The long-range capability is reflected in a higher consumption during transmission. However, its consumption in receiver mode is slightly lower than that of the nRF24L01+.
+
+nRF24L01+ provides higher data rates at short distances. Its power consumption is comparable or lower than that of the SX1276. It lacks a dedicated reset pin, but that can be easily worked around using an external transistor to momentarily disconnect its Vdd pin.
+
+Both devices implement some form of a packet engine with error checking; that of the nRF24L01+, called ShockBurst, is more advanced as it implements acknowledgment responses and automatic re-transmission, leading to a potentially more robust communication without an additional overhead on the side of the microcontroller.
+
+
+\section{Integration of the nRF24L01+ into GEX}
+
+The nRF24L01+ was selected to be integrated into GEX thanks to its inclusion of the ShockBurst engine, higher possible data rates and significantly lower price. The SX1276, nonetheless, remains an interesting option that could be used as an alternative in the future, should the need for a long range communication arise.
+
+A separate device, the \textit{GEX wireless gateway}, was developed to provide the PC connection to a nRF24L01+ module. It is based on the STM32F103 microcontroller in its smallest package (LQFP48), selected for it's low cost and good availability.
+
+\subsection{The Wireless Gateway Protocol}
+
+\begin{wrapfigure}[17]{r}{0.38\textwidth}
+ \vspace{-1em}
+ \centering
+ \includegraphics[scale=0.9]{img/rf-gw.pdf}
+ \caption{A block diagram of the wireless connection}
+\end{wrapfigure}
+
+The gateway presents itself to the host as a CDC/ACM device, much like the GEX modules themselves (here called \textit{nodes}) when connected over USB. It implements a simple protocol which encapsulates the binary data sent to or from a connected node. The wrapped GEX protocol (chapter \ref{sec:tinyframe}) remains unchanged.
+
+The gateway has a 4-byte network ID, a number derived from the microcontroller's unique ID. The network ID must be entered into all nodes that wish to communicate with it. Additionally, each module must be assigned a unique 1-byte number, which, together with the four network ID bytes, uniquely identifies the node. The gateway can connect to up to 6 nodes at once.
+
+All messages sent to or from the gateway are a multiple of 64 bytes long, padded with zeros if shorter. The message starts with a control byte, determining the message type (table \ref{fig:rf-dongle-commands}).
+
+\begin{table}[h]
+ \centering
+ \begin{tabulary}{\textwidth}{lL}
+ \toprule
+ \textbf{Function} & \textbf{Message structure} \\
+ \midrule
+ Send a message & 'm' (\verb|u8|)address (\verb|u16|)length (\verb|u8[]|)payload \\
+ Restart \& remove nodes & 'r' \\
+ Add nodes & 'n' (\verb|u8|)count (\verb|u8[]|)addresses \\
+ Get the network ID & 'i' \\
+ Response to 'i' & 0x01 (\verb|u8[4]|)net\_id \\
+ Received message & 0x02 (\verb|u8|)address (\verb|u8|)length (\verb|u8[]|)data \\
+ \bottomrule
+ \end{tabulary}
+ \caption[Wireless gateway commands and messages]{\label{fig:rf-dongle-commands}Wireless gateway commands and messages; control characters in the printable range are shown as ASCII}
+\end{table}
+
+The gateway may be restarted using the 'r' command when the PC application starts. Then it adds all node addresses with the 'n' command and can begin communication. The 'i' command, reading the network ID, can additionally be used as a ping command to verify the USB connection.
+
+\todo[inline]{Add additional commands. Also remove magic bytes form the real messages, they're useless}
diff --git a/ctuth-pkg.tex b/ctuth-pkg.tex
index 1607025..c72d02f 100755
--- a/ctuth-pkg.tex
+++ b/ctuth-pkg.tex
@@ -799,11 +799,17 @@
% Redefine the enumerate labels. The first two levels are boxed,
% the other two are not.
%\def\labelenumi{{\normalfont\itembox[ctubluedarkbg][white]{\bfseries\theenumi.}}}
+
+% CUSTOM XXX removed the enumi boxes
+\iffalse
+
\def\labelenumi{{\normalfont\itembox{\theenumi.}}}
\def\labelenumii{{\normalfont\itembox(0.1em)(0.1em){\theenumii.}}}
\def\labelenumiii{{\normalfont(\theenumiii)}}
\def\labelenumiv{{\normalfont(\theenumiv)}}
+\fi
+
\leftmargini22.2pt
\labelsep6pt
diff --git a/document_config.tex b/document_config.tex
index 405f771..ade799b 100755
--- a/document_config.tex
+++ b/document_config.tex
@@ -14,6 +14,8 @@
\usepackage{cprotect}
\usepackage{framed}
\usepackage{subcaption}
+\usepackage{tabularx}
+\usepackage{tabulary}
\usepackage{flafter} % ensures embeds won't go before their references
\usepackage{enumitem} % better list spacing
@@ -22,6 +24,9 @@
\usepackage{makecell}
+\newminted{ini}{frame=leftline,autogobble=true}
+
+
\newcommand{\uF}{\micro\farad}
\newcommand{\nF}{\nano\farad}
\newcommand{\cm}{\centi\metre}
diff --git a/img/bulk-read-write.pdf b/img/bulk-read-write.pdf
new file mode 100644
index 0000000..36ba2b4
Binary files /dev/null and b/img/bulk-read-write.pdf differ
diff --git a/img/disco-touch.jpg b/img/disco-touch.jpg
new file mode 100644
index 0000000..d129d2e
Binary files /dev/null and b/img/disco-touch.jpg differ
diff --git a/img/fat-links.pdf b/img/fat-links.pdf
new file mode 100644
index 0000000..a2ae7df
Binary files /dev/null and b/img/fat-links.pdf differ
diff --git a/img/nrf-testing.jpg b/img/nrf-testing.jpg
new file mode 100644
index 0000000..30a2b89
Binary files /dev/null and b/img/nrf-testing.jpg differ
diff --git a/img/rf-gw.pdf b/img/rf-gw.pdf
new file mode 100644
index 0000000..6ffcd86
Binary files /dev/null and b/img/rf-gw.pdf differ
diff --git a/img/tsc-wfm-bw.png b/img/tsc-wfm-bw.png
new file mode 100644
index 0000000..7e9eec3
Binary files /dev/null and b/img/tsc-wfm-bw.png differ
diff --git a/img/tsc-wfm.png b/img/tsc-wfm.png
new file mode 100644
index 0000000..262b44c
Binary files /dev/null and b/img/tsc-wfm.png differ
diff --git a/img/tsc-wfm2-bw.png b/img/tsc-wfm2-bw.png
new file mode 100644
index 0000000..66376db
Binary files /dev/null and b/img/tsc-wfm2-bw.png differ
diff --git a/img/tsc-wfm2.png b/img/tsc-wfm2.png
new file mode 100644
index 0000000..2da4ea0
Binary files /dev/null and b/img/tsc-wfm2.png differ
diff --git a/references/all-about-direct-digital-synthesis.pdf b/references/AD_all-about-direct-digital-synthesis.pdf
similarity index 100%
rename from references/all-about-direct-digital-synthesis.pdf
rename to references/AD_all-about-direct-digital-synthesis.pdf
diff --git a/references/FAT16/FAT12Description_www.dfists.ua.es_~gil.pdf b/references/FAT16/FAT12Description_www.dfists.ua.es_~gil.pdf
new file mode 100644
index 0000000..490126b
Binary files /dev/null and b/references/FAT16/FAT12Description_www.dfists.ua.es_~gil.pdf differ
diff --git a/references/FAT16/FAT16 Structure Information.html b/references/FAT16/FAT16 Structure Information.html
new file mode 100644
index 0000000..e094fbe
--- /dev/null
+++ b/references/FAT16/FAT16 Structure Information.html
@@ -0,0 +1,517 @@
+
+
+
+
+
+
+FAT16 Structure Information
+
+
+
+
+
FAT16 Structure Information - Written by Jack Dobiash
+
+
Updated : June 17th, 1999
+
+
Looking for FAT32 Info? Go here.
+Looking for Informaton on how to Read and Write to your Hard Drive? Go here.
+
+
I've written this page for anyone who wishes to write software that can do low-level
+reading and writing of a hard drive, and needs to know what the underlying structure of a
+FAT16 Drive is, in order to interpret the information properly. Basically I've
+searched all over the web, and have compiled this information in one spot.
+Hopefully it can be of use to someone. I don't guarantee that all of this
+information is correct or complete, but so far is seems to have been working for me.
+
+
+
A lot of the number references I've made in this document are in Hexadecimal. Any
+that are have an 'h' after them. Also, just in case my terminology may be different
+from yours; a 'WORD' is 2 Bytes and a 'DOUBLE WORD' is 4 Bytes.
+
+
+
+
Master Boot Record
+
+
+
The Master Boot Record is the same for pretty much all Operating Systems. It is
+ located on the first Sector of the Hard Drive, at Cylinder 0, Head 0, Sector 1. It
+ is the first piece of code that your computer runs after it has checked all of your
+ hardware (POST) and turned control of loading software over the hard drive. It also
+ contains the partition table, which defines the different sections of your hard
+ drive. Basically if anything happens to this little 512 byte section, your hard
+ drive is brain dead. Kinda scary, eh? :)
+
+
+
+
+
+
Offset
+
Description
+
Size
+
+
+
000h
+
Executable Code (Boots Computer)
+
446 Bytes
+
+
+
1BEh
+
1st Partition Entry (See Next Table)
+
16 Bytes
+
+
+
1CEh
+
2nd Partition Entry
+
16 Bytes
+
+
+
1DEh
+
3rd Partition Entry
+
16 Bytes
+
+
+
1EEh
+
4th Partition Entry
+
16 Bytes
+
+
+
1FEh
+
Executable Marker (55h AAh)
+
2 Bytes
+
+
+
+
+
+Partition Entry (Part of MBR)
+
+
+
+
+
Offset
+
Description
+
Size
+
+
+
00h
+
Current State of Partition (00h=Inactive, 80h=Active)
+
1 Byte
+
+
+
01h
+
Beginning of Partition - Head
+
1 Byte
+
+
+
02h
+
Beginning of Partition - Cylinder/Sector (See Below)
+
1 Word
+
+
+
04h
+
Type of Partition (See List Below)
+
1 Byte
+
+
+
05h
+
End of Partition - Head
+
1 Byte
+
+
+
06h
+
End of Partition - Cylinder/Sector
+
1 Word
+
+
+
08h
+
Number of Sectors Between the MBR and the First Sector in the
+ Partition
+
1 Double Word
+
+
+
0Ch
+
Number of Sectors in the Partition
+
1 Double Word
+
+
+
+
+
+Cylinder/Sector Encoding
+
+
+
I guess back in the days of 10MB hard drives and 8086's, code was at a premium.
+ So they did everything they could to preserve space. Unfortunately now we have to
+ live with it, but luckily they created new ways of translating the system so the 1024
+ Cylinder Limit (2^10) isn't too big of a problem, for newer computers, at least.
+ Older ones usually need some sort of Disk Overlay program to make them see the whole hard
+ drive.
+
Anyway, to get the Sector out of this, you need to apply an AND mask ($3F) to it.
+ To get the Cylinder, you take the high byte and OR it with the low byte that has
+ been AND masked with ($C0) and then Shifted Left Two. It's not very easy to explain,
+ so I'll just show you how I did it with two routines I made (In Pascal) for Encoding and
+ Decoding the Cylinder/Sector. Hopefully even if you don't know Pascal you'll be able
+ to read it.
+
Function CylSecEncode(Cylinder, Sector : Word) : Word;
+ Begin
+ CylSecEncode := (Lo(Cylinder) shl 8) or (Hi(Cylinder) shl 6) or Sector;
+ End;
+
+ Procedure CylSecDecode(Var Cylinder, Sector : Word; CylSec : Word);
+ Begin
+ Cylinder := Hi(CylSec) or ((Lo(CylSec) and $C0) shl 2);
+ Sector := (CylSec and $3F);
+ End;
+
+
+
+
+
+
+
15
+
14
+
13
+
12
+
11
+
10
+
9
+
8
+
7
+
6
+
5
+
4
+
3
+
2
+
1
+
0
+
+
+
Cylinder Bits 7 to 0
+
Cylinder Bits 9+8
+
Sector Bits 5 to 0
+
+
+
+
+
+Partition Type Listing
+
+
+
There are more than just these shown, but I've only included that ones relevant to MS
+ Operating Systems.
+
+
+
+
+
+
Value
+
Description
+
+
+
00h
+
Unknown or Nothing
+
+
+
01h
+
12-bit FAT
+
+
+
04h
+
16-bit FAT (Partition Smaller than 32MB)
+
+
+
05h
+
Extended MS-DOS Partition
+
+
+
06h
+
16-bit FAT (Partition Larger than 32MB)
+
+
+
0Bh
+
32-bit FAT (Partition Up to 2048GB)
+
+
+
0Ch
+
Same as 0BH, but uses LBA1 13h Extensions
+
+
+
0Eh
+
Same as 06H, but uses LBA1 13h Extensions
+
+
+
0Fh
+
Same as 05H, but uses LBA1 13h Extensions
+
+
+
+
+
+Reading Multiple Partitions
+
+
+
Since FAT16 is limited to 2GB per partition, drives that use it tend to have multiple
+ partitions. The first partition is the Primary Partition, and everything else is
+ stored in the Extended Partition. It's a little tricky when it comes to reading
+ those extra partitions though (not a lot, just a little). The first record in the
+ partition table shows where the Primary partition is (how big it is, where it starts, and
+ where it ends). The second entry in the partition table shows where the Entire
+ Extended Partition is (which may include more than just one partition). To read any
+ more partitions, you go to the where it says the Extended Partition starts, and read the
+ first sector. It acts just like the MBR. It'll have blank where the code is
+ supposed to be, and in the partition table it will have for it's first entry the next
+ Partition in the Drive, and if there are anymore, there will be another Extended
+ partition, just like before. However, all references to Sector Numbers are made
+ using the that new MBR point as the reference, making it a virtual drive. Just
+ incase this doesn't make much sense (and by the way I explain things I can understand if
+ it doesn't), let me show you how a drive with three partitions is setup.
+
MBR of Whole Drive
+
Entry #1 - Points to Partition #1
+ Entry #2 - Points to the Entire Extended Partition
+
You would read the first sector of that Extended Partition, and see another MBR
+ Structure.
+
MBR of Extended Partition
+
Entry #1 - Points to Partition #2
+ Entry #2 - Points to Rest of Extended Partition after Partition #2
+
Now, all references to Sector Numbers (most specifically the entry at Offset 08h) in
+ those Entries wouldn't be referenced from the start of the drive, but from the start of
+ the Extended Partition. However, the CHS (Cylinder, Head, Sector) numbers would
+ still be right.
+
Once again, you would read the first sector of that Extended Partition, and see the
+ next MBR.
+
MBR of Rest of Extended Partition
+
Entry #1 - Points to Partition #3
+ No Entry #2, since this was the Last Partition
+
If there were another partition, the pattern would continue just like before, until the
+ last one was reached.
+
+
+
+
+
+FAT16 Boot Record
+
+
+
This information is located in the first sector of every partition.
+
+
+
+
+
+
Offset
+
Description
+
Size
+
+
+
00h
+
Jump Code + NOP
+
3 Bytes
+
+
+
03h
+
OEM Name
+
8 Bytes
+
+
+
0Bh
+
Bytes Per Sector
+
1 Word
+
+
+
0Dh
+
Sectors Per Cluster
+
1 Byte
+
+
+
0Eh
+
Reserved Sectors
+
1 Word
+
+
+
10h
+
Number of Copies of FAT
+
1 Byte
+
+
+
11h
+
Maximum Root Directory Entries
+
1 Word
+
+
+
13h
+
Number of Sectors in Partition Smaller than 32MB
+
1 Word
+
+
+
15h
+
Media Descriptor (F8h for Hard Disks)
+
1 Byte
+
+
+
16h
+
Sectors Per FAT
+
1 Word
+
+
+
18h
+
Sectors Per Track
+
1 Word
+
+
+
1Ah
+
Number of Heads
+
1 Word
+
+
+
1Ch
+
Number of Hidden Sectors in Partition
+
1 Double Word
+
+
+
20h
+
Number of Sectors in Partition
+
1 Double Word
+
+
+
24h
+
Logical Drive Number of Partition
+
1 Word
+
+
+
26h
+
Extended Signature (29h)
+
1 Byte
+
+
+
27h
+
Serial Number of Partition
+
1 Double Word
+
+
+
2Bh
+
Volume Name of Partition
+
11 Bytes
+
+
+
36h
+
FAT Name (FAT16)
+
8 Bytes
+
+
+
3Eh
+
Executable Code
+
448 Bytes
+
+
+
1FEh
+
Executable Marker (55h AAh)
+
2 Bytes
+
+
+
+
+
+
+FAT16 Drive Layout
+
+
+
+
+
Offset
+
Description
+
+
+
Start of Partition
+
Boot Sector
+
+
+
Start + # of Reserved Sectors
+
Fat Tables
+
+
+
Start + # of Reserved + (# of Sectors Per FAT * 2)
+
Root Directory Entry
+
+
+
Start + # of Reserved + (# of Sectors Per FAT * 2) + ((Maximum
+ Root Directory Entries * 32) / Bytes per Sector)
+
Data Area (Starts with Cluster #2)
+
+
+
+
+
+
+
Cluster Meaning (FAT Table Entries)
+
+
+
A Cluster is a Group of Sectors on the Hard Drive that have information in them.
+ A 16K Cluster has 32 Sectors in it (512*32=16384). Each Cluster is given a spot in
+ the FAT Table. When you look at an Entry in the FAT, the number there tells you
+ whether or not that cluster has data in it, and if so, if it is the end of the data or
+ there is another cluster after it. All Data on a Partition starts with Cluster #2
+ (Right after Root Directory). If the FAT Entry is 0, then there is no data in
+ that cluster. If the FAT Entry is FFFFh, then it is the last entry in the
+ chain.
+
+
+
+
+
+
FAT Code Range
+
Meaning
+
+
+
0000h
+
Available Cluster
+
+
+
0002h-FFEFh
+
Used, Next Cluster in File
+
+
+
FFF0h-FFF6h
+
Reserved Cluster
+
+
+
FFF7h
+
BAD Cluster
+
+
+
FFF8h-FFFF
+
Used, Last Cluster in File
+
+
+
+
+
Directory Table
+
+
+
Another aspect when looking at a File System at Low Level is the Directory Table.
+ The Directory Table is what stores all of the File and Directory Entries.
+ Someone else has already written a good resource for this information on the net, so
+ go here to look at it. The
+ link doesn't work anymore, but luckily I saved the page a while back, so i'll just post it
+ on my site.
+
+
+
+
+
Footnotes
+
+
1 - LBA = Logical Block Addressing - Uses the Int 13h Extensions built into newer
+BIOS's to access data above the 8GB
+
+barrier, or to access strickly in LBA mode, instead of CHS (Cylinder, Head, Sector).
FAT32 Structure Information - Written by Jack Dobiash
+
+
Updated
+: December 4th, 2005
+
+
Looking for FAT16 info? Go here.
+Looking for Information on how to Read and Write to your Hard Drive? Go here.
+
+
Microsoft has Released Information on the FAT32 File System! Go here to get it!
+
+
I've written this page for anyone who wishes to write software that can do
+low-level reading and writing of a hard drive, and needs to know what the
+underlying structure of a FAT32 Drive is, in order to interpret the information
+properly. Basically I've searched all over the web, and have compiled
+this information in one spot. Hopefully it can be of use to
+someone. I don't guarantee that all of this information is correct or
+complete, but so far is seems to have been working for me.
+
+
A lot of the number references I've made in this document are in
+Hexadecimal. Any that are have an 'h' after them. Also, just in
+case my terminology may be different from yours; a 'WORD' is 2 Bytes and a
+'DOUBLE WORD' is 4 Bytes.
+
+
+
+
Master Boot Record
+
+
+
+
The Master Boot Record is the same for pretty much all Operating
+Systems. It is located on the first Sector of the Hard Drive, at Cylinder
+0, Head 0, Sector 1. It is the first piece of code that your computer
+runs after it has checked all of your hardware (POST) and turned control of
+loading software over the hard drive. It also contains the partition
+table, which defines the different sections of your hard drive. Basically
+if anything happens to this little 512 byte section, your hard drive is brain
+dead. Kinda scary, eh? :)
+
+
+
+
+
+
+
Offset
+
+
+
Description
+
+
+
Size
+
+
+
+
+
000h
+
+
+
Executable Code (Boots Computer)
+
+
+
446 Bytes
+
+
+
+
+
1BEh
+
+
+
1st Partition Entry (See Next Table)
+
+
+
16 Bytes
+
+
+
+
+
1CEh
+
+
+
2nd Partition Entry
+
+
+
16 Bytes
+
+
+
+
+
1DEh
+
+
+
3rd Partition Entry
+
+
+
16 Bytes
+
+
+
+
+
1EEh
+
+
+
4th Partition Entry
+
+
+
16 Bytes
+
+
+
+
+
1FEh
+
+
+
Boot Record Signature (55h AAh)
+
+
+
2 Bytes
+
+
+
+
+
+Partition Entry (Part of MBR)
+
+
+
+
+
Offset
+
+
+
Description
+
+
+
Size
+
+
+
+
+
00h
+
+
+
Current State of Partition (00h=Inactive, 80h=Active)
+
+
+
1 Byte
+
+
+
+
+
01h
+
+
+
Beginning of Partition - Head
+
+
+
1 Byte
+
+
+
+
+
02h
+
+
+
Beginning of Partition - Cylinder/Sector (See Below)
+
+
+
1 Word
+
+
+
+
+
04h
+
+
+
Type of Partition (See List Below)
+
+
+
1 Byte
+
+
+
+
+
05h
+
+
+
End of Partition - Head
+
+
+
1 Byte
+
+
+
+
+
06h
+
+
+
End of Partition - Cylinder/Sector
+
+
+
1 Word
+
+
+
+
+
08h
+
+
+
Number of Sectors Between the MBR and the First Sector in
+ the Partition
+
+
+
1 Double Word
+
+
+
+
+
0Ch
+
+
+
Number of Sectors in the Partition
+
+
+
1 Double Word
+
+
+
+
+
+Cylinder/Sector Encoding
+
+
+
+
I guess back in the days of 10MB hard drives and 8086's, code was at a
+premium. So they did everything they could to preserve space.
+Unfortunately now we have to live with it, but luckily they created new ways of
+translating the system so the 1024 Cylinder Limit (2^10) isn't too big of a
+problem, for newer computers, at least. Older ones usually need some
+sort of Disk Overlay program to make them see the whole hard drive.
+
+
+
Anyway, to get the Sector out of this, you need to apply an AND mask ($3F)
+to it. To get the Cylinder, you take the high byte and OR it with the
+low byte that has been AND masked with ($C0) and then Shifted Left Two.
+It's not very easy to explain, so I'll just show you how I did it with two
+routines I made (In Pascal) for Encoding and Decoding the
+Cylinder/Sector. Hopefully even if you don't know Pascal you'll be able
+to read it.
+
+
Function CylSecEncode(Cylinder, Sector : Word) : Word;
+Begin
+ CylSecEncode := (Lo(Cylinder) shl 8) or (Hi(Cylinder) shl 6)
+or Sector;
+End;
+
+Procedure CylSecDecode(Var Cylinder, Sector : Word; CylSec : Word);
+Begin
+ Cylinder := Hi(CylSec) or ((Lo(CylSec) and $C0) shl 2);
+ Sector := (CylSec and $3F);
+End;
+
+
+
+
+
+
+
15
+
+
+
14
+
+
+
13
+
+
+
12
+
+
+
11
+
+
+
10
+
+
+
9
+
+
+
8
+
+
+
7
+
+
+
6
+
+
+
5
+
+
+
4
+
+
+
3
+
+
+
2
+
+
+
1
+
+
+
0
+
+
+
+
+
Cylinder Bits 7 to 0
+
+
+
Cylinder Bits 9+8
+
+
+
Sector Bits 5 to 0
+
+
+
+
+
+Partition Type Listing
+
+
+
+
There are more than just these shown, but I've only included that ones
+relevant to MS Operating Systems.
+
+
+
+
+
+
+
Value
+
+
+
Description
+
+
+
+
+
00h
+
+
+
Unknown or Nothing
+
+
+
+
+
01h
+
+
+
12-bit FAT
+
+
+
+
+
04h
+
+
+
16-bit FAT (Partition Smaller than 32MB)
+
+
+
+
+
05h
+
+
+
Extended MS-DOS Partition
+
+
+
+
+
06h
+
+
+
16-bit FAT (Partition Larger than 32MB)
+
+
+
+
+
0Bh
+
+
+
32-bit FAT (Partition Up to 2048GB)
+
+
+
+
+
0Ch
+
+
+
Same as 0BH, but uses LBA1 13h Extensions
+
+
+
+
+
0Eh
+
+
+
Same as 06H, but uses LBA1 13h Extensions
+
+
+
+
+
0Fh
+
+
+
Same as 05H, but uses LBA1 13h Extensions
+
+
+
+
+
+Reading Multiple Partitions
+
+
+
+
Although having multiple partitions in FAT32 isn't as likely as in FAT16, it
+still works the same way. The first partition is the Primary Partition, and
+everything else is stored in the Extended Partition. It's a little tricky
+when it comes to reading those extra partitions though (not a lot, just a
+little). The first record in the partition table shows where the Primary
+partition is (how big it is, where it starts, and where it ends). The
+second entry in the partition table shows where the Entire Extended Partition
+is (which may include more than just one partition). To read any more
+partitions, you go to the where it says the Extended Partition starts, and read
+the first sector. It acts just like the MBR. It'll have blank where
+the code is supposed to be, and in the partition table it will have for it's
+first entry the next Partition in the Drive, and if there are anymore, there
+will be another Extended partition, just like before. However, all
+references to Sector Numbers are made using the that new MBR point as the
+reference, making it a virtual drive. Just incase this doesn't make much
+sense (and by the way I explain things I can understand if it doesn't), let me
+show you how a drive with three partitions is setup.
+
+
MBR of Whole Drive
+
+
Entry #1 - Points to Partition #1
+ Entry #2 - Points to the Entire Extended Partition
+
+
You would read the first sector of that Extended Partition, and see another
+MBR Structure.
+
+
MBR of Extended Partition
+
+
Entry #1 - Points to Partition #2
+ Entry #2 - Points to Rest of Extended Partition after
+Partition #2
+
+
Now, all references to Sector Numbers (most specifically the entry at Offset
+08h) in those Entries wouldn't be referenced from the start of the drive, but
+from the start of the Extended Partition. However, the CHS (Cylinder,
+Head, Sector) numbers would still be right.
+
+
Once again, you would read the first sector of that Extended Partition, and
+see the next MBR.
+
+
MBR of Rest of Extended Partition
+
+
Entry #1 - Points to Partition #3
+ No Entry #2, since this was the Last Partition
+
+
If there were another partition, the pattern would continue just like
+before, until the last one was reached.
+
+
+
+
+
+
+FAT32 Boot Record
+
+
+
+
This information is located in the first sector of every partition.
+
+
+
+
+
+
+
Offset
+
+
+
Description
+
+
+
Size
+
+
+
+
+
00h
+
+
+
Jump Code + NOP
+
+
+
3 Bytes
+
+
+
+
+
03h
+
+
+
OEM Name (Probably MSWIN4.1)
+
+
+
8 Bytes
+
+
+
+
+
0Bh
+
+
+
Bytes Per Sector
+
+
+
1 Word
+
+
+
+
+
0Dh
+
+
+
Sectors Per Cluster
+
+
+
1 Byte
+
+
+
+
+
0Eh
+
+
+
Reserved Sectors
+
+
+
1 Word
+
+
+
+
+
10h
+
+
+
Number of Copies of FAT
+
+
+
1 Byte
+
+
+
+
+
11h
+
+
+
Maximum Root Directory Entries (N/A for FAT32)
+
+
+
1 Word
+
+
+
+
+
13h
+
+
+
Number of Sectors in Partition Smaller than 32MB (N/A for
+ FAT32)
+
+
+
1 Word
+
+
+
+
+
15h
+
+
+
Media Descriptor (F8h for Hard Disks)
+
+
+
1 Byte
+
+
+
+
+
16h
+
+
+
Sectors Per FAT in Older FAT Systems (N/A for FAT32)
+
+
+
1 Word
+
+
+
+
+
18h
+
+
+
Sectors Per Track
+
+
+
1 Word
+
+
+
+
+
1Ah
+
+
+
Number of Heads
+
+
+
1 Word
+
+
+
+
+
1Ch
+
+
+
Number of Hidden Sectors in Partition
+
+
+
1 Double Word
+
+
+
+
+
20h
+
+
+
Number of Sectors in Partition
+
+
+
1 Double Word
+
+
+
+
+
24h
+
+
+
Number of Sectors Per FAT
+
+
+
1 Double Word
+
+
+
+
+
28h
+
+
+
Flags (Bits 0-4 Indicate Active FAT Copy) (Bit 7 Indicates
+ whether FAT Mirroring is Enabled or Disabled <Clear is Enabled>) (If
+ FAT Mirroring is Disabled, the FAT Information is only written to the copy
+ indicated by bits 0-4)
+
+
+
1 Word
+
+
+
+
+
2Ah
+
+
+
Version of FAT32 Drive (High Byte = Major Version, Low
+ Byte = Minor Version)
+
+
+
1 Word
+
+
+
+
+
2Ch
+
+
+
Cluster Number of the Start of the Root Directory
+
+
+
1 Double Word
+
+
+
+
+
30h
+
+
+
Sector Number of the File System Information Sector (See Structure
+ Below) (Referenced from the Start of the Partition)
+
+
+
1 Word
+
+
+
+
+
32h
+
+
+
Sector Number of the Backup Boot Sector (Referenced from
+ the Start of the Partition)
+
+
+
1 Word
+
+
+
+
+
34h
+
+
+
Reserved
+
+
+
12 Bytes
+
+
+
+
+
40h
+
+
+
Logical Drive Number of Partition
+
+
+
1 Byte
+
+
+
+
+
41h
+
+
+
Unused (Could be High Byte of Previous Entry)
+
+
+
1 Byte
+
+
+
+
+
42h
+
+
+
Extended Signature (29h)
+
+
+
1 Byte
+
+
+
+
+
43h
+
+
+
Serial Number of Partition
+
+
+
1 Double Word
+
+
+
+
+
47h
+
+
+
Volume Name of Partition
+
+
+
11 Bytes
+
+
+
+
+
52h
+
+
+
FAT Name (FAT32)
+
+
+
8 Bytes
+
+
+
+
+
5Ah
+
+
+
Executable Code
+
+
+
420 Bytes
+
+
+
+
+
1FEh
+
+
+
Boot Record Signature (55h AAh)
+
+
+
2 Bytes
+
+
+
+
+
+File System Information Sector
+
+
+
+
Usually this is the Second Sector of the partition, although since there is a
+reference in the Boot Sector to it, I'm assuming it can be moved around.
+I never got a complete picture of this one. Although I do know where the
+important fields are at.
+
+
+
+
+
+
+
Offset
+
+
+
Description
+
+
+
Size
+
+
+
+
+
00h
+
+
+
First Signature (52h 52h 61h 41h)
+
+
+
1 Double Word
+
+
+
+
+
04h
+
+
+
Unknown, Currently (Might just be Null)
+
+
+
480 Bytes
+
+
+
+
+
1E4h
+
+
+
Signature of FSInfo Sector (72h 72h 41h 61h)
+
+
+
1 Double Word
+
+
+
+
+
1E8h
+
+
+
Number of Free Clusters (Set to -1 if Unknown)
+
+
+
1 Double Word
+
+
+
+
+
1ECh
+
+
+
Cluster Number of Cluster that was Most Recently
+ Allocated.
+
+
+
1 Double Word
+
+
+
+
+
1F0h
+
+
+
Reserved
+
+
+
12 Bytes
+
+
+
+
+
1FCh
+
+
+
Unknown or Null
+
+
+
2 Bytes
+
+
+
+
+
1FEh
+
+
+
Boot Record Signature (55h AAh)
+
+
+
2 Bytes
+
+
+
+
+
+FAT32 Drive Layout
+
+
+
+
+
Offset
+
+
+
Description
+
+
+
+
+
Start of Partition
+
+
+
Boot Sector
+
+
+
+
+
Start + # of Reserved Sectors
+
+
+
Fat Tables
+
+
+
+
+
Start + # of Reserved + (# of Sectors Per FAT * 2)
+ <Assuming that FAT Mirroring is Enabled, I personally haven't seen a case where
+ it wasn't, but I guess there is always the possibility>
+
+
+
Data Area (Starts with Cluster #2)
+
+
+
+
+
+
+
Cluster Meaning
+
+
+
+
A Cluster is a Group of Sectors on the Hard Drive that have information in
+them. A 4K Cluster has 8 Sectors in it (512*8=4096). Each Cluster
+is given a spot in the FAT Table. When you look at an Entry in the FAT,
+the number there tells you whether or not that cluster has data in it, and if
+so, if it is the end of the data or there is another cluster after it.
+All Data on a Partition starts with Cluster #2. If the FAT Entry
+is 0, then there is no data in that cluster. If the FAT Entry is
+0FFFFFFFh, then it is the last entry in the chain.
+
+
This is one of my biggest holes in my information. I am unable to find
+anyplace that shows what numbers mean what when it comes to the FAT
+table. I was able to tell the end of the chain just by looking at a FAT32
+Drive, but I don't know what stands for a BAD Cluster or what the maximum valid
+number for showing data is.
+
+
For now, you can calculate the maximum valid cluster in a partition with
+this formula:
+
+
( (# of Sectors in Partition) - (# of Sectors per Fat * 2) - (# of Reserved
+Sectors) ) / (# of Sectors per Cluster)
+
+
If there is any remainder in the answer to that formula, it just means that
+there were a few extra clusters at the end of the partition (probably not
+enough to make another cluster), so you can just get rid of anything after the
+decimal point.
+
+
Thanks to Andrew Clausen for pointing this formula out to
+me.
+
+
+
+
+
+
Directory Table
+
+
+
+
Another aspect when looking at a File System at Low Level is the Directory
+Table. The Directory Table is what stores all of the File and Directory
+Entries. Basically there is only one difference between the Directory
+Table of FAT16 and FAT32, so go here to look at FAT16's
+Structure. The Difference is : the Reserved OS/2 Byte (Offset 20
+[14h]) in the Short Filename Structure is replaced with the High Word of the
+Cluster Number (since it's now 4 bytes instead of 2).
+
+
+
+
+
+
Footnotes
+
+
1 - LBA = Logical Block Addressing - Uses the Int 13h Extensions built into
+newer BIOS's to access data above the 8GB barrier, or to access strictly in LBA
+mode, instead of CHS (Cylinder, Head, Sector).
+fourth release
+First Release: November 18th, 1996
+Last Update: January 6th, 1998 (Document readability update)
+
+
+
+
Compatibility
+
+
Long filename (here on forth referred to as "LFN") design for Windows95 is
+designed to be 99% compatible with the old DOS 8.3 format. The 1% discripency comes in
+when old DOS programs can detect the presence of LFN (but unfortunately not the
+LFN itself), which in no way interferes with regular program operations except for perhaps
+low-level disk utility programs (such as disk error fixing programs, disk optimization
+programs, anti-virus program, etc.)
+
+
+
+
DOS 8.3 Filename Background
+
+
I trust that anyone who wish to know the details of LFN has at least a small knowledge
+in DOS 8.3 filename specification. In this document, however, I'll assume you know very
+little about the 8.3 filename specs, however. What you need to know in order to understand
+this documentation is that 8.3 filenames are stored in a place on the disk called the directory
+table. This place contains the list of filenames and other information associated
+with each file, such as the file date, time, size, attributes, etc. (Note: Contrary to
+some belief, the directory table is not the same as the FAT -- e-mail me if you
+wish to know what FAT is.)
+
+
The file attributes, mentioned above, play some big roles in LFN. It is important to
+note that a file's attributes are may consist of one or more of the following:
+
+
+
+
+
Archive
+
+
+
Read-Only
+
+
+
System
+
+
+
Hidden
+
+
+
Directory
+
+
+
Volume
+
+
+
+
+
Most programmers are aware of the Archive, Read-Only, System, and Hidden attrbiutes,
+but for those of you who don't know, please allow me to explain what each of these
+attributes is/does:
+
+
+
The Archive attribute tells that a file has been backed up (though most
+ programs just ignore this).
+
The Read-Only attribute keeps a file from accidentally getting overwritten;
+ note that any program can unset this attribute should it know how to detect this attribute
+ and unset it -- that's why it is used just to keep a file from accidentally
+ getting overwritten.
+
The System attribute tells that the file is used for some important operation
+ so it should not be messed with except by the program that created it; any file with this
+ attribute cannot be seen with the DIR command except with the /a or /as
+ arguments in DOS 5 and above.
+
The Hidden attribute tells that a file should normally be hidden from the
+ user's view. Any file with this attribute cannot be seen with DIR command
+ either, except with the /a or /ah arguments in DOS 5 and above.
+
+
+
And the explanation of the other attributes (the really important ones):
+
+
+
The Directory attribute is used to tell that a file is not actually a file
+ but a directory. This type of file contains a pointer to a part of the disk that contains
+ another directory table; this directory table that's pointed to is the subdirectory of the
+ directory that has the pointer. In another words, when you "CD" to that file,
+ you go into the directory table the file points to, making it look as though you are
+ "inside" that directory. In reality, you only switch the directory tables.
+
The volume attribute too is used to tell that a file is not actually a file.
+ This attribute is used to indicate the volume label of the drive (the name of the disk). A
+ file with this attribute can never be displayed with the DIR command.
+ Furthermore, there can be only one file with this attribute on the entire disk, and this
+ file must be in the root directory of the disk.
+ The volume attribute has a funny story attached to it -- There
+ not only exists a file with the volume attribute, but a copy of the volume label is also
+ located in the boot sector (the very beginning of the disk that has weird code and disk
+ info on it) as a readable text. But when you view a directory with the DIR
+ command, the one that actually gets displayed is the volume attributed file's name, not
+ the volume label in the boot sector. Furthermore, even though files with volume attribute
+ is hidden from the DIR command, programs, when retrieving filenames, can
+ retrieve volume labels. All these factors about volume attributes come into a big
+ factor when we look at Long Filenames.
+
+
+
As an addendum, it might be interesting to note that each 8.3 file entry is 32 bytes
+long but that not all 32 bytes are used to store data -- some of them are plainly left as
+blank bytes. In Windows95 version of the directory table, however, all 32 bytes are used.
+
+
+
+
General Specification
+
+
Just like DOS 8.3 filenames, Windows95 LFNs are also stored on directory tables,
+side-by-side with DOS 8.3 filenames. On top of that, to achieve compatibility with old DOS
+programs Microsoft designed LFN in a way so it resembles the old DOS 8.3 format.
+Furthermore, an 8.3 format version of LFN (tttttt~n.xxx) is also present next
+to each LFN entry for compatibility with non-LFN supporting programs.
+
+
+
+
Organization
+
+
From a low-level point-of-view, a normal directory table that only contains 8.3
+filenames look like this:
+
+
+
+
+
...
+
+
+
8.3 entry
+
+
+
8.3 entry
+
+
+
8.3 entry
+
+
+
8.3 entry
+
+
+
+
+
If you look at a directory table that contains LFN entries, however, this is what you
+will see:
+
+
+
+
+
...
+
+
+
LFN entry 3
+
+
+
LFN entry 2
+
+
+
LFN entry 1
+
+
+
8.3 entry (tttttt~n.xxx)
+
+
+
+
+
Notice that Long Filenames can be pretty long, so LFN entries in a 8.3 directory
+structure can take up several 8.3 directory entry spaces. This is why the above file entry
+has several LFN entries for a single 8.3 file entry.
+
+
Despite taking up 8.3 filename spaces, Long Filenames do not show up with the DIR
+command or with any other program, even the ones that do not recognize the LFN. How, then,
+do LFN entries get hidden from DOS? The answer is quite simple: By giving LFN entries
+"Read-only, System, Hidden, and Volume" attributes. (If you do not know details
+about file attributes, read the above text about DOS 8.3
+Filename Background.)
+
+
A special attention should be given to the fact that this combination of attributes --
+Read-only, System, Hidden, Volume -- is not possible to make under normal circumstances
+using common utilities found in the market place (special disk-editing programs, such as
+Norton Disk Editor, is an exception.)
+
+
This technique of setting Read-only, System, Hidden, Volume attributes works because
+most programs ignore files with volume attributes altogether, and even if they don't, they
+won't display any program that has system or hidden attributes set. And since the
+Read-only attribute is set, programs won't write anything over it. However, you can view
+"parts" of the LFN entries if any program is designed to show Volume attributed
+files.
previously) is stored
+"backwards", with the first entry toward the bottom and the last entry at the
+top, right above the new 8.3 filename entry.
+
+
Each LFN entry is stored as follows:
+
+
+
+
+
Offset
+
Length
+
Value
+
+
+
0
+
byte
+
Ordinal field (desc. below)
+
+
+
1
+
word
+
Unicode character 1 (desc. below)
+
+
+
3
+
word
+
Unicode character 2
+
+
+
5
+
word
+
Unicode character 3
+
+
+
7
+
word
+
Unicode character 4
+
+
+
9
+
word
+
Unicode character 5
+
+
+
11
+
byte
+
Attribute
+
+
+
12
+
byte
+
Type (reserved; always 0)
+
+
+
13
+
byte
+
Checksum (desc. below)
+
+
+
14
+
word
+
Unicode character 6
+
+
+
16
+
word
+
Unicode character 7
+
+
+
18
+
word
+
Unicode character 8
+
+
+
20
+
word
+
Unicode character 9
+
+
+
22
+
word
+
Unicode character 10
+
+
+
24
+
word
+
Unicode character 11
+
+
+
26
+
word
+
Cluster (unused; always 0)
+
+
+
28
+
word
+
Unicode character 12
+
+
+
30
+
word
+
Unicode character 13
+
+
+
+
+
Throughout this entry, you see "unicode characters". Unicode characters are
+2-byte long characters (as opposed to ASCII characters that are 1-byte long each) that
+support not only traditional latin alphabet characters and arabic numbers but they also
+support the languages of the rest of the world, including the CJK trio (Chinese, Japanese,
+Korean), Arabic, Hebrew, etc. Plus you have some space left over for more math and science
+symbols. Unicode characters are still going through revisions (on their second revision as
+I am writing, I believe) but Windows95 has left spaces to more fully support unicodes in
+the future. You can keep up with the Unicode development by visiting the Unicode webpage
+at www.unicode.org. Note that, in the 2-byte unicode
+character, the first byte is always the character and the second byte is always the blank,
+as opposed to having the first byte blank and the second byte blank. There is a perfectly
+logical explanation for this but it's kind of long to get into at the moment so e-mail me
+if you are curious. (If you have a computer dictionary, look up "little endian"
+and it'll explain everything.) For our purposes, though, just treat every other word as an
+ASCII character as long as the following byte is a blank character. Anyways, notice that,
+in order to maintain the compatibility with older programs, the attribute byte and the
+cluster word had to be kept. Because of this, each unicode character had to be scattered
+throughout the entry.
+
+
By now you probably noticed that there is no file information (size, date, etc.) stored
+in the LFN entry. Any information about the file itself is stored in the 8.3 filename,
+located below all the LFN entries (as mentioned before).
+
+
The checksum is created from the shortname data. The steps/equation used to calculate
+this checksum is as follows:
+
+
+
+
+
Step #
+
Task
+
+
+
1
+
Take the ASCII value of the first character. This is your
+ first sum.
+
+
+
2
+
Rotate all the bits of the sum rightward by one bit.
+
+
+
3
+
Add the ASCII value of the next character with the value
+ from above. This is your next sum.
+
+
+
4
+
Repeat steps 2 through 3 until you are all through with the
+ 11 characters in the 8.3 filename.
+
+
+
+
+
In C/C++, the above steps look like this:
+
+
+
+
+
+ for (sum = i = 0; i < 11; i++) {
+ sum = (((sum & 1) << 7) | ((sum & 0xfe)
+ >> 1)) + name[i];
+ }
+
+
+
+
+
This resulting checksum value is stored in each of the LFN entry to ensure that the
+short filename it points to indeed is the currently 8.3 entry it should be pointing to.
+
+
Also, note that any file with a name that does not fill up the 8.3 spaces completely
+leaves a trace of space characters (ASCII value 32) in the blank spaces. These blank
+spaces do go into the calculation of the checksum and does not get left out of the
+calculation.
+
+
I'm sure you're dying to know what the ordinal field is. This byte of information tells
+the order of the LFN entries (1st LFN entry, 2nd LFN entry, etc.) If it's out of order,
+something is wrong! How Windows95 would deal with LFN when such a thing happen is a
+mystery to me.
+ An example of how ordinal field work: The first LFN entry, located at the
+very bottom as we have seen before, has an ordinal field value
+1; the second entry (if any -- remember that a LFN doesn't always have to be tens of
+characters long), located just before the first entry, has an ordinal field value of 2;
+etc. As an added precaution, the last entry has a marking on the ordinal field that tells
+that it is the last entry. This marking is done by setting the 6th bit of the ordinal
+field.
+
+
That is basically all there is to long filenames. But before we end this conversation
+(while we're on the subject of LFN,) I think it would be interesting to note that, since
+any long filename can be up to 255 bytes long and each entry can hold up to 13 characters,
+there can only be up to 20 entries of LFN per file. That means it only needs 5 bits (0th
+bit to 4th bit) of the ordinal field. And with the 6th bit used to mark the last entry,
+two bits are left for open usage -- the 5th and the 7th bit. Whether or not Microsoft is
+going to do anything with these bits -- or why Microsoft used the 6th bit to indicate the
+last entry instead of 7th or 5th bit and limited the file length to 255 bits -- remains to
+be a mystery only Microsoft will keep to itself.
+
+
+
+
Credit
+
+
Much the information in this documentation has been gathered from
+Norton Utilities for Windows95 user's manual. Detailed researches were done using Norton
+Utilities Disk Edit. The checksum calculation was graciously donated by Jacob Verhoeks to comp.os.msdos.programmer
+Newsgroup as a reply to my request. Apparently the file Mr. Verhoeks used to get me the
+checksum code, vfat.txt, that comes with newer Linux operating systems have
+some good information on Windows95 LFN. BTW, I just (like, right now) found out that
+checksum algorithm is also in Ralf Brown's Interrupt List.
+This isn't a file system in itself, but a kind of sub file system, which can be placed over a FAT12, FAT16 or FAT32 file system. The VFAT system is a way of hiding long file names in the directory structure of the FAT file systems.
+
+The filenames are stored using unicode characters which are 16 bit long.
+
+
+
+
+
+
+
Coexistence with FAT12, FAT16 & FAT32
+Depending on the length of the long filename, the system will create a number of invalid 8.3 entries in the Directory Table, these are the LFN (Long Filename) entries. These LFN entries are stored with the with the last LFN entry topmost, and the first LFN entry just above a valid Directory Entry. So when looked upon from the top and down, the Directory Table looks something like this:
+
+
+
+
+ Directory Example
+
+
+
+
+
+
+
+
+
Entry Nr.
+
Without LFN Entries
+
With LFN Entries
+
+
+
+
...
...
...
+
n
Normal 1
Normal 1
+
n+1
Normal 2
LFN for Normal 2 - Part 3
+
n+2
Normal 3
LFN for Normal 2 - Part 2
+
n+3
Normal 4
LFN for Normal 2 - Part 1
+
n+4
Normal 5
Normal 2
+
n+5
Normal 6
Normal 3
+
...
...
...
+
+
+
+
+The LFN entries have the Volume Name, Hidden, System and the Read-Only flags set. So most programs won't display them because of the Volume Name flag (Volume entries are rarely displayed), and they won't be overwridden because of the Read-Only flag.
+
+
+
+
+
+
+
Directory Entries
+The VFAT Directory Format, can coexist on a normal FATxx system. The LFN entries are hidden from normal programs, and available to those who know how to read them. But in addition to the LFN entries the VFAT Directory Format enhances the original structure of the Directory Table as found in FAT16. The Directory Table can still be read by older applications, but all the unused space from the FAT16 format, is now used to store some additional information. This is the format of the VFAT Directory entries:
+
+
NT - Reserved for Windows NT - Should always be 0000h
+
0Dh
1 bytes
Creation Time - Millisecond
+
0Eh
2 bytes
Creation Time - Hour & Minute
+
10h
2 bytes
Created Date
+
12h
2 bytes
Last Accessed Data
+
14h
2 bytes
Starting cluster (High word) on FAT32 file systems, else 0000h
+
16h
2 bytes
Time
+
18h
2 bytes
Date
+
1Ah
2 bytes
Starting cluster (Low word)
+
1Ch
4 bytes
File size in bytes
+
+
+
+
+
+
+
+
Flag Byte
+The flag byte defines a set of flags which is set for directories, volume name, hidden files, system files, etc. These are the flags:
+
+
+
+
+ Flags in the flag byte
+
+
+
+
+
+
+
+
+
7
+
6
+
5
+
4
+
3
+
2
+
1
+
0
+
+
+
+
+
Unused
+
A
+
D
+
V
+
S
+
H
+
R
+
0000h
+
+
+
+
+
+
+
+
+
Achieved Flag
+The A flag is set by a backup program, so that the user/program knows which files that has been backed up. This flag is not used correctly by many user and perhaps also by many operating systems.
+
+
+
+
+
System
+This flag shows that the file/directory is important for the system, and shouldn't be manipulated.
+
+
+
+
+
Hidden
+This flag tell the system and programs that the file should be hidden for the user. But in a lot of programs this can be overwritten by the user.
+
+
+
+
+
Read Only
+The flag is used to prevent programs from not automatically overwriting or deleting this file/directory.
+
+
+
+
+
Directory
+This flag is set, when an entry in the directory table is not pointing to the beginning of a file, but to another directory table. A sub-directory. The sub-directory is placed in the cluster, where the Starting Cluster field points to. The format of this sub-directory table is identical to the root directory table.
+
+
+
+
+
Volume Name
+When this flag is set, the directory entry is not pointing to a file, but to nothing. The only information used from this entry is the filename (8 bytes) plus the filename extension (3 bytes). These bytes form an 11 bytes long volume label (without any .) There may be only one valid entry on the entire disk with this flag set. And preferably this entry should be among the first 3 entries in the root directory table, if not, then MS-DOS can have trouble displaying the right volume label. This volume name should be the same as the one in the boot sector. The latter one is infact rarely used.
+
+
+
+
+
+
+
LFN Entry
+The LFN entries are, as described, placed above the real directory entry, for which they contain the long filename. The first 13 letters are in the first entry, letters 14-26 are in the second LFN entry, letters 27-39 are in the third LFN entry, and so on until the filename has ended. The maximum length of a filename has been limited to 255, even though this scheme has the potential to make them 1664 bytes long, Microsoft - who designed FAT32 - decided not to. The structure of each LFN entry is as follows:
+
+
+
+Only the cluster word (offset 1Ah) and the flag byte (offset 0Bh), are required for compatibility reasons.
+
+
+
+
+
Ordinal Field
+The ordinal field is used to tell the system which number the LFN entry has, in the LFN string. The first LFN entry will have a value of 01h. The second LFN entry, if there is one, will have a value of 02h, and so on it continues. When a LFN entry contains the last character in the name the Last LFN bit is set (bit 6 in the Ordinal Field).
+
+
+
+
+ The Ordinal Field
+
+
+
+
+
+
+
+
+
7
+
6
+
5
+
4
+
3
+
2
+
1
+
0
+
+
+
+
+
Deleted LFN
+
Last LFN
+
LFN Number
+
0000h
+
+
+
+
+
+
+
+
+
Calculating the Checksum
+The Checksum byte in each LFN entry is there to make sure that the LFN entry points to the right file. The checksum value is calculated on the basis of the 8.3 filename, which is present in the valid Directory Table entry. Spaces (ASCII: 20h) are also calculated. The algorithm for calculating the checksum is:
+
+
+
The ASCII value of the first character is the base sum.
+
Rotate the sum bitwise one bit to the right.
+
Add the ASCII value of the next character to the sum.
+
Repeat step 2 and 3 until all 11 characters has been added.
+
+
+
+
+
+
Unicode Characters
+The Unicode characters in the specification is a 16 bit value, where the lower 8 bits represent the respective ASCII value and the upper 8 bits are clear. The means that the LFN names are just ASCII style names, with extra holes.
+
+
+
+
+
+
+
Conclusion
+The VFAT Directory Format is a very clever way to add long filename support to the older FAT file systems, while still maintaining compatibility. It is however strange why Microsoft (who designed FAT32) didn't implemented native support for long filenames in FAT32 when they created it a few years back.
+
+
Used: On machines with small harddrives running MS-DOS, Windows 95/98
+
+
+
+
+
Introduction
+This is the 16-bit version of the FAT file system. The 16-bit part describes the way units are allocated on the drive. The FAT16 file system uses a 16-bit number to identify each allocation unit (called cluster), and this gives it a total of 65.536 clusters. The size of each cluster is defined in the boot sector of the volume (volume = partition). The File System ID number usually associated with FAT16 volumes are 04h and 06h. The first is used on volumes with less than 65536 sectors (typical this is on drives less than 32 Mb in size), and the latter one is used on volumes with more than 65536 sectors. There is also another variant which is used with the LBA address mode, that variant has a File System ID of 0Eh. I do not know if the LBA variant is different from the CHS type. So far I don't se why anything should be changed to support LBA addresses.
+
+
+
+
+
Basic Structure
+The FAT16 file system structure contains the following regions:
+
+
+
+
+ FAT16 File System Structure
+
+
+
+
+
+
+
Region
+
+
+
+
Reserved Region (incl. Boot Sector)
+
File Allocation Table (FAT)
+
Root Directory
+
Data Region
+
+
+
+
+The first sector (boot sector) contain information which is used to calculate the sizes and locations of the other regions. The boot sector also contain code to boot the operating system installed on the volume. The data region is split up into logical blocks called clusters. Each of these clusters has an accompanying entry in the FAT region. The cluster specific entry can either contain a value of the next cluster which contain data from the file, or a so called End-of-file value which means that there are no more clusters which contain data from the file. The root directory and its sub-directories contain filename, dates, attribute flags and starting cluster information about the filesystem objects.
+
+
+
+
+
+
+
Boot Sector
+The first sector in the reserved region is the boot sector. Though this sector is typical 512 bytes in can be longer depending on the media. The boot sector typical start with a 3 byte jump instruction to where the bootstrap code is stored, followed by an 8 byte long string set by the creating operating system. This is followed by the BIOS Parameter Block, and then by an Extended BIOS Parameter Block. Finally the boot sector contain boot code and a signature.
+
+
+The BIOS Parameter Block contains basic information about the overall structure of the FAT file system. That is information such as sector and cluster size, location information of FAT copies, the root directory size etc..
+
+
+
+
Bytes Per Sector
+This value is the number of bytes in each physical sector. The allowed values are: 512, 1024, 2048 or 4096 bytes. A lot of code outthere are assuming 512 bytes per sectors, so any other values can give compatibility problems.
+
+
+
+
+
Sectors Per Cluster
+This is the number of sectors per cluster. The allowed values are: 1, 2, 4, 8, 16, 32 or 128. But de-facto is that most combinations of 'BytesPerCluster' * 'SectorsPerCluster' which gives a total value over 32 Kb per cluster, are not supported on many system.
+
+
+
+
+
Reserved Sectors
+Since the reserved region always contain the boot sector a zero value in this field is not allowed. The usual setting of this value is 1. The value is used to calculate the location for the first sector containing the FAT.
+
+
+
+
+
Number of FAT copies
+This is the number of FAT copies in the file system. The recommended value is 2 (and then have two FAT copies), but other values are validm though they may not be supported on some system. The usage of two copies are to prevent data loss if one or part of one FAT copy is corrupted.
+
+
+
+
+
Root Entries Count
+This value contain the number of entries in the root directory. Its recommended that the number of entries is an even multiple of the BytesPerSector values. The recommended value for FAT16 volumes is 512 entries (compatibility reasons).
+
+
+
+
+
Small Number of Sectors
+This field states the total number of sectors in the volume. That includes the number of sectors occupied by the four regions which the FAT16 file system consist of. For FAT16 volumes that use less than 65536 sectors this field is used. The File System Id in the MBR is then 04h. For FAT16 volumes that use more the 65535 sectors the Large Number of Sectors field is used and this one should be set to 0h.
+
+
+
+
+
Media Descriptor
+These are the possible media descriptors values in the FAT boot sector. This is the same value which must be in the low byte in the first entry of the FAT.
+
+
+
+
+ Media Descriptors
+
+
+
+
+
+
+
+
+
Hex Value
+
Capacity
+
Physical Format
+
+
+
+
F0
2.88 MB
3.5-inch, 2-sided, 36-sector
+
F0
1.44 MB
3.5-inch, 2-sided, 18-sector
+
F8
?
Fixed disk
+
F9
720 KB
3.5-inch, 2-sided, 9-sector
+
F9
1.2 MB
5.25-inch, 2-sided, 15-sector
+
FA
?
?
+
FB
?
?
+
FC
180 KB
5.25-inch, 1-sided, 9-sector
+
FD
360 KB
5.25-inch, 2-sided, 9-sector
+
FE
160 KB
5.25-inch, 1-sided, 8-sector
+
FF
320 KB
5.25-inch, 2-sided, 8-sector
+
+
+
+
+
+
+
+
+
Sectors Per FAT
+This is the number of sectors occupied by one copy of the FAT.
+
+
+
+
+
Sectors Per Track
+This value is used when the volume is on a media which have a geometry, that is when the LBA number is broken down into a Cylinder-Head-Sector address. This field represents the multiple of the max. Head and Sector value used when the volume was formatted. The field itself is used to check if the LBA to CHS translation has changed, since the formatting. And for calculating the correct Cylinder, Head and Sector values for the translation algorithm.
+
+
+
+
+
Number of Heads
+This value is used when the volume is on a media which have a geometry, that is when the LBA number is broken down into a Cylinder-Head-Sector address. This field represents the Head value used when the volume was formatted. The field itself is used to check if the LBA to CHS translation has changed, since the formatting. And for calculating the correct Cylinder, Head and Sector values for the translation algorithm.
+
+
+
+
+
Hidden Sectors
+When the volume is on a media that is partitioned, this value contains the number of sectors preceeding the first sector of the volume.
+
+
+
+
+
Large Number of Sectors
+This field states the total number of sectors in the volume. That includes the number of sectors occupied by the four regions which the FAT16 file system consist of. For FAT16 volumes that use more than 65535 sectors this field is used. The File System Id in the MBR is then 06h. For FAT16 volumes that use less than 65536 sectors the Small Number of Sectors field is used and this one should be set to 0h.
+
+
+
+
+
+
+
+
+
Extended BIOS Parameter Block
+The Extended BIOS Parameter Block contains information that is only used in the FAT16 file system.
+
+
+
+
Drive Number
+This is the int 13h drive number of the drive. The value 00h is used for the first floppy drive and the value 80h is used for the first harddrive. MS-DOS's bootstrap uses this value to find the correct drive.
+
+
+
+
+
Reserved
+Reserved byte. It was original used to store the cylinder on which the boot sector is located. But Windows NT uses this byte to store two flags. The lowest bit would indicates that a check disk should be run at boot time, and the second lowest flag indicates that a surface scan should be run.
+
+
+
+
+
Extended Boot Signature
+If this byte contain a value of 29h it indicates that the following three fields are available.
+
+
+
+
+
Volume Serial Number
+This value is a 32 bit random number, which, combined with the volume label, makes is possible to track removable media and check if the correct one is inserted.
+
+
+
+
+
Volume Label
+This 11 byte long string should match the volume label entry in the root directory. If no such entry is available this field should contain the string 'NO NAME ' (11 bytes long string). When updating the volume label, both, this field and the entry in the root directory should be updated.
+
+
+
+
+
File System Type
+This 8 byte long string should be used for informational display only. Thats because its sometime incorrectly set. The field should contain the string 'FAT16 ' (8 bytes long string).
+
+
+
+
+
+
+
+
+
Bootstrap Code
+The bootstrap code is different between operating system and versions which are intended to be loaded of this FAT16 volume. The responsability of the bootstrap code is to continue the boot sequence. If ex. MS-DOS is installed the bootstrap code will locate the file IO.SYS in the file system, load part of it into memory and then jump to a specific entrypoint in IO.SYS. What the bootstrap code does is vary between operating system.
+
+
+
+
+
+
+
Boot Sector Signature
+The word at offset 1FEh should contain the signature AA55h. This will indicate to the BIOS that the sector is executable. The signature is also used by other applications when validating that the correct sector has been loaded. No matter what the Bytes Per Sector value is this signature should always be at offset 1FEh.
+
+
+
+
+
+
+
File Allocation Table
+The FAT structure contain linked lists of files in the file system. Any file or directory entry in a (sub)directory list contain a cluster number for the first chunk of the file/directory. This cluster number also has an associated entry in the FAT. At this entry in the FAT a single word value either points to the next cluster/chunk or it contain an End-of-file value. These are the valid values:
+
+
+
+
+ Valid FAT16 values
+
+
+
+
+
+
+
+
Value
+
Description
+
+
+
+
0000h
Free cluster
+
0001h - 0002h
Not allowed
+
0003h - FFEFh
Number of the next cluster
+
FFF7h
One or more bad sectors in cluster
+
FFF8h - FFFFh
End-of-file
+
+
+
+
+Each FAT copy start with a value of FFxxh for the first cluster, where xx is equal to the Media Descriptor field in the BIOS Parameter Block. The FAT entry for the second cluster is set to the End-of-file value (FFFFh). The two highest bits of this value may be used for dirty volume flags in the following way.
+
+
+
+
+ FAT Entry Value for 2nd cluster
+
+
+
+
+
+
+
+
+
15
+
14
+
13
+
12
+
11
+
10
+
9
+
8
+
7
+
6
+
5
+
4
+
3
+
2
+
1
+
0
+
+
+
+
+
C
+
E
+
These bits must be set
+
0000h
+
+
+
+
+
+ C = If clear then the volume may be dirty because it was not cleanly dismounted. If the bit is set then the volume is clean.
+
+
+
+
+ E = If clear a read/write error was encountered during the last time the volume was mounted. If the bit is set then no read/write error was encountered.
+
+
+
+
+
+
+It should be noted that the last entry in the FAT should be calculated by taking the number of clusters in the data area, and not relying on the Sectors Per FAT field in the BIOS Parameter Block. This is because the number of entries in the FAT doesn't have to be an even multiple of the bytes per sector value.
+
+The maximum size of each FAT copy is 128 Kb (2 * 65536).
+
+
+
+
+
+
+
Directory Entry Structure
+Each of the entries in a directory list is 32 byte long. The only directory which is in a fixed location is the root directory. This is also the only directory which may contain an entry with the Volume Label attribute set. The size of the root directory is defined in the BIOS Parameter Block.
+
+Sub-directories are created by allocating a cluster which then are cleared so it doesn't contain any directory entries. Two default entries are then created: The '.' entry point to the directory itself, and the '..' entry points to the parent directory. If the contents of a sub-directory grows beyond what can be in the cluster a new cluster is allocated in the same way as for files.
+
+This is the format of the directory entries:
+
+
+The filename is 8 byte long. Shorter names must be trailing padded with space bytes (ASCII: 20h). The extension is 3 byte long and shorter names also have to be trailing padded. The characters allowed in the filename and extension are basicly the uppercase letters of the english alphabet, plus the digits 0 to 9.
+
+The first byte in the filename is treated special. The following rules apply:
+
+
A value of 00h is interpertated as 'stop the search, there is no more entries in this directory'.
+
A value of 05h is should be replaced with the ASCII character E5h. The character is used in Japan.
+
Must not contain the value 20h.
+
A value of E5h is interpertated as 'the entry is free'.
+
Any of the values mentioned below are allowed.
+
+
+The following characters are not allowed in the filename or its extension:
+
+
Any character below 20h, except the 05h character.
+
Any character in the following list: 22h ("), 2Ah (*), 2Bh (+), 2Ch (,), 2Eh (.), 2Fh (/), 3Ah (:), 3Bh (;), 3Ch (<), 3Dh (=), 3Eh (>), 3Fh (?), 5Bh ([), 5Ch (\), 5Dh (]), 7Ch (|).
+
+
+For compatibility reasons it is recommended to limit the characters to:
+
+
Any uppercase characters from A to Z.
+
Any digit from 0 to 1.
+
Any of the following characters: #, $, %, &, ', (, ), -, @
+
+
+
+
+
+
Attribute Byte
+The attribute byte defines a set of flags which can be set for directories, volume name, hidden files, system files, etc. These are the flags:
+
+
+
+
+ Flags in the Attribute byte
+
+
+
+
+
+
+
+
+
7
+
6
+
5
+
4
+
3
+
2
+
1
+
0
+
+
+
+
+
Reserved
+
A
+
D
+
V
+
S
+
H
+
R
+
0000h
+
+
+
+
+
+
+
+
+
Read Only
+This flag is used to prevent programs from not automatically overwriting or deleting this entry.
+
+
+
+
+
Hidden
+This flag indicates to the system that the file should be hidden when doing normal directory listings. But in a lot of programs this can be overwritten by the user.
+
+
+
+
+
System
+This flag indicates that the file/directory is important for the system, and shouldn't be manipulated without any concern.
+
+
+
+
+
Volume Name
+When this flag is set, the directory entry is not pointing to a file, but to nothing. Thus the the Starting cluster must point the cluster 0. The only information used from this entry is the filename (8 bytes) plus the filename extension (3 bytes). These bytes form an 11 byte long volume label (without any .) There may be only one valid entry in the entire volume with this flag set. This entry must be in the root directory and preferably among the first entries, if not, then MS-DOS can have trouble displaying the right volume label if there are long file names present. This volume name should be the same as the one in the boot sector.
+
+
+
+
Directory
+This flag is set, when an entry in the directory table is not pointing to the beginning of a file, but to another directory table. A sub-directory. The sub-directory is placed in the cluster, which the Starting Cluster field points to. The format of this sub-directory table is identical to the root directory table.
+
+
+
+
+
Achieve Flag
+This flag is used by backup utilities. The flag is set when ever a file is created, renamed or changed. Backup utilities can then use this flag to determine which files that has been modified since the last backup.
+
+
+
+
+
+
Reserved for Windows NT
+This byte is used by Windows NT. It set the value to 0 when the file is created and then never look at it again. For what purpose it uses it is unknown.
+
+
+
+
+
Creation Time - Millisecond
+Due to size limitations this field (1 byte) only contains the millisecond stamp in counts of 10 milliseconds. Therefore valid values are between 0 and 199 inclusive.
+
+
+
+
+
Creation Time & Date
+The 16 bit time field contain the time of day when this entry was created. The 16 bit date field contain the date when the entry was created. These two values never change. Both the time field and the date field are in a special format.
+
+
+
+
+
Last Access Date
+This 16 bit field contain the date when the entry was last read or written to. In case of writes this field of cause contain the same value as the Last Write Date field. The date field is the same special format as the other dates.
+
+
+
+
+
Reserved for FAT32
+This word is reserved for the FAT32 File System. When used in that file system it will contain the high word of the starting cluster. In the FAT16 File System this word should be set to 0.
+
+
+
+
+
Last Write Time
+This 16 bit field is set to the time when the last write occured. When the entry is create this field and the Creation Time field should contain the same values. In case the entry is a directory entry this field should change when the contents of the sub-directory changes.
+
+The field is in the special format described below:
+
+
+
+ Time Format
+
+
+
+
+
+
+
+
+
15
+
14
+
13
+
12
+
11
+
10
+
9
+
8
+
7
+
6
+
5
+
4
+
3
+
2
+
1
+
0
+
+
+
+
+
Hours (0-23)
+
Minutes (0-59)
+
Seconds (0-29)
+
0000h
+
+
+
+
+
Seconds are counted with 2 seconds interval, so a value of 29 in this field gives 58 seconds.
+
+
+
+
+
+
+
+
+
Last Write Date
+This 16 bit field is set to the date when the last write occured. When the entry is create this field and the Creation Date field should contain the same values. In case the entry is a directory entry this field should change when the contents of the sub-directory changes.
+
+The field is in the special format described below:
+
+
+
+ Date Format
+
+
+
+
+
+
+
+
+
15
+
14
+
13
+
12
+
11
+
10
+
9
+
8
+
7
+
6
+
5
+
4
+
3
+
2
+
1
+
0
+
+
+
+
+
Years from 1980 (0-127 -> 1980-2107)
+
Month of year (1-12)
+
Day of month (1-31)
+
0000h
+
+
+
+
+
+
+
+
+
+
+
+
+
+
First Cluster
+This 16-bit field points to the starting cluster number of entrys data. If the entry is a directory this entry point to the cluster which contain the beginning of the sub-directory. If the entry is a file then this entry point to the cluster holding the first chunk of data from the file.
+
+
+
+
+
File Size
+This 32-bit field count the total file size in bytes. For this reason the file system driver must not allow more than 4 Gb to be allocated to a file. For other entries than files then file size field should be set to 0.
+
+
+
+
+
+
+
+
+
Calculation Algorithms
+How to calculate the starting location of each region. The VolumeStart variable contain a LBA address of the first sector in the volume. On drives which are not partitioned the VolumeStart value is 0. On drives which are partitioned the VolumeStart variable contain the sector number at which the partition start.
+
+
+
+
+ How to calculate regions and their size (in sectors)
+
+ Previous calculated values which are used again, are marked with this color.
+
+
+
+
+
+
+
+
+
+
+
+
Special Notes
+When creating a FAT16 volume special care should be taken to ensure best compatibility. Following these rules ensure the best compatibility:
+
+
A FAT16 partition may not have less than 4085 clusters or more than 65524 clusters.
+
+
+
+
+
+
+
+
Conclusion
+The FAT family of file systems are relative simple file systems. The complexity can be enhanced by adding support for long file names, using the VFAT Long File Names. Also have a look at the 32 bit version of the FAT file system.
+
+This page is intended to provide an introduction to the original File
+Allocation Table (FAT) file system. This file system was used on all
+versions of MS-DOS and PC-DOS, and on early versions of Windows; it is
+still used on floppy disks formatted by Windows and some other systems.
+Modified versions are also still supported by Windows on hard disks, if
+required.
+
+
+The FAT file system is heavily based on the file map model in
+terms of its on-disk layout; that model was around for many years before
+Microsoft inherited the initial FAT file system from the original
+writers of DOS (Seattle Computer Products). It is a reasonably simple,
+reasonably robust file system.
+
+
+There are three basic variants of the FAT file system, which differ
+mainly in the construction of the actual file allocation table. Floppy
+disks and small hard disks usually use the 12-bit version,
+which was superseded by the 16-bit version as hard disks became
+bigger. This in turn was superseded by the 32-bit version as
+disks became bigger still. We shall concentrate on the 16-bit version,
+since the 12-bit version can be tricky for beginners, and the 32-bit
+version is more complex than needed for this tutorial.
+
+
+
Overview
+
+Any disk is made up of surfaces (one for each head),
+tracks and sectors. However, for simplicity, we can
+consider a disk as a simple storage area made up just of a number of
+sectors. Further, these sectors are considered to be numbered
+consecutively, the first being numbered 0, the second numbered 1, etc.;
+we will not worry about the physical location of any sector on the
+actual disk. Because we want to emphasise that the location of a sector is
+irrelevant to the actual disk structure, and because sectors have their
+own numbers within each track, we shall call these sectors
+blocks from now on; as previously stated, they form a linear,
+densely numbered list.
+
+
+All blocks are the same size, 512 bytes, on practically all FAT file
+systems. Howewer, large disks can have too many blocks for comfort, so
+blocks are sometimes grouped together in pairs (or fours, or eights,
+etc...); each such grouping is called an allocation unit. The
+FAT file system actually works in allocation units, not blocks, but for
+simplicity we shall assume in the description below that each allocation
+unit contains exactly one block, which means that we can use the terms
+interchangeably.
+
+
+
A note on numerical values
+
+Hexadecimal numbers are indicated using the convention commonly used in
+C; that is, a leading 0x. The decimal number
+17 would thus be written as 0x11 in
+hexadecimal notation here.
+
+
+Values in the FAT file system are either stored in bytes (8 bit
+values, 0-255 unsigned) or in words (pairs of bytes, 16 bit
+values, 0-65535 unsigned). Note that the first byte of a pair is the
+least significant byte, and the second byte of a pair is the most
+significant byte. For example, if the byte at position 3 has a value of
+0x15, and the byte at position 4 has a value of 0x74, they together make
+up a word with value 0x7415 (not 0x1574).
+
+
+There are occasional 32-bit values (doublewords), and these use
+a similar approach (in this case 4 bytes, with least significant byte
+stored first).
+
+
+Lastly, note that individual bits within a byte or word are numbered
+from the least significant end (right hand end), starting with bit 0.
+
+
+
The disk format
+
+This section describes the on-disk structure of a FAT file
+system; that is, how the various areas of the disk are laid out, and
+what is stored in them.
+
+
+
Basic layout
+
+All disks using the FAT file system are divided into several areas. The
+following table summarises the areas in the order that they appear on
+the disk, starting at block 0:
+
+The boot block occupies just the first block of the disk. It holds a
+special program (the bootstrap program) which is used for
+loading the operating system into memory. It would thus appear to be
+fairly irrelevant to this discussion.
+
+
+However, in the FAT file system it also contains several important data
+areas which help to describe the rest of the file system. Thus, to
+understand how a particular disk is laid out, it is necessary first to
+understand at least part of the contents of the boot block. The relevant
+areas are shown in the following table, together with their byte offsets
+from the start of the boot block. We will see, later, which of these are
+actually important to us.
+
+
+
+
Offset from start
+
Length
+
Description
+
+
+
0x00
+
3 bytes
+
Part of the bootstrap program.
+
+
+
0x03
+
8 bytes
+
Optional manufacturer description.
+
+
+
0x0b
+
2 bytes
+
Number of bytes per block (almost always 512).
+
+
+
0x0d
+
1 byte
+
Number of blocks per allocation unit.
+
+
+
0x0e
+
2 bytes
+
Number of reserved blocks. This is the number of blocks on the disk
+that are not actually part of the file system; in most cases this is
+exactly 1, being the allowance for the boot block.
Number of root directory entries
+(including unused ones).
+
+
+
0x13
+
2 bytes
+
Total number of blocks in the entire disk. If the disk size is
+larger than 65535 blocks (and thus will not fit in these two bytes),
+this value is set to zero, and the true size is stored at
+offset 0x20.
The number of blocks per track. This information is present
+primarily for the use of the bootstrap program, and need not concern us
+further here.
+
+
+
0x1a
+
2 bytes
+
The number of heads (disk surfaces). This information is present
+primarily for the use of the bootstrap program, and need not concern us
+further here.
+
+
+
0x1c
+
4 bytes
+
The number of hidden blocks. The use of this is largely
+historical, and it is nearly always set to 0; thus it can be
+ignored.
+
+
+
0x20
+
4 bytes
+
Total number of blocks in the entire disk (see also
+offset 0x13).
+
+
+
0x24
+
2 bytes
+
Physical drive number. This information is present primarily for the
+use of the bootstrap program, and need not concern us further here.
+
+
+
0x26
+
1 byte
+
Extended Boot Record Signature This information is present
+primarily for the use of the bootstrap program, and need not concern us
+further here.
+
+
+
0x27
+
4 bytes
+
Volume Serial Number. Unique number used for identification of a
+particular disk.
+
+
+
0x2b
+
11 bytes
+
Volume Label. This is a string of characters for human-readable
+identification of the disk (padded with spaces if shorter); it is
+selected when the disk is formatted.
+
+
+
0x36
+
8 bytes
+
File system identifier (padded at the end with spaces if
+shorter).
+
+
+
0x3e
+
0x1c0 bytes
+
The remainder of the bootstrap program.
+
+
+
0x1fe
+
2 bytes
+
Boot block 'signature' (0x55 followed by 0xaa).
+
+
+
+
The Media Descriptor
+
+Historically, the size and type of disk were difficult for the operating
+system to determine by hardware interrogation alone. A 'magic byte' was
+thus used to classify disks. This are still present, but rarely used,
+and its contents are known as the Media Descriptor. Generally, for hard
+disks, this is set to 0xf0.
+
+
The File Allocation Table (FAT)
+
+The FAT occupies one or more blocks immediately following the boot
+block. Commonly, part of its last block will remain unused, since it is
+unlikely that the required number of entries will exactly fill a
+complete number of blocks. If there is a second FAT, this immediately
+follows the first (but starting in a new block). This is repeated for
+any further FATs.
+
+
+Note that multiple FATs are used particularly on floppy disks, because
+of the higher likelihood of errors when reading the disk. If the FAT is
+unreadable, files cannot be accessed and another copy of the FAT must be
+used. On hard disks, there is often only one FAT.
+
+
+In the case of the 16-bit FAT file system, each entry in the FAT is two bytes in length
+(i.e. 16 bits). The disk data area is divided into clusters, which are the same thing
+as allocation units, but numbered differently (instead of being numbered from the start
+of the disk, they are numbered from the start of the disk data area). So, the cluster number
+is the allocation unit number, minus a constant value which is the size of the areas in between
+the start of the disk and the start of the data area.
+
+
+Well, almost. The clusters are numbered starting at 2, not 0! So the
+above calculation has to have 2 added to it to get the cluster number of
+a given allocation unit...and a cluster number is converted to an
+allocation unit number by subtracting 2...!
+
+
+So, how does the FAT work? Simply, there is one entry in the FAT for
+every cluster (data area block) on the disk. Entry N relates to cluster
+N. Clusters 0 and 1 don't exist (because of the 'fiddle by 2' above),
+and those FAT entries are special. The first byte of the first entry is
+a copy of the media descriptor byte, and
+the second byte is set to 0xff. Both bytes in the second entry are set to
+0xff.
+
+
+What does a normal FAT entry for a cluster contain? It contains the
+successor cluster number - that is, the number of the cluster
+that follows this one in the file to which the current cluster belongs.
+The last cluster of a file has the value 0xffff in its FAT entry to
+indicate that there are no more clusters.
+
+
+
The Root Directory
+
+The root directory contains an entry for each file whose name appears at
+the root (the top level) of the file system. Other directories
+can appear within the root directory; they are called
+subdirectories. The main difference between the two is that
+space for the root directory is allocated statically, when the disk is
+formatted; there is thus a finite upper limit on the number of files
+that can appear in the root directory.
+
+
+Subdirectories are just files with special data in them, so they can be
+as large or small as desired.
+
+
+The format of all directories is the same. Each entry is 32 bytes (0x20)
+in size, so a single block can contain 16 of them. The following table
+shows a summary of a single directory entry; note that the offset is
+merely from the start of that particular entry, not from the start of
+the block.
+
+The eight bytes from offset 0x00 to 0x07 represent the filename. The
+first byte of the filename indicates its status. Usually, it contains a
+normal filename character (e.g. 'A'), but there are some special values:
+
+
+
0x00
+
Filename never used.
+
0xe5
+
The filename has been used, but the file has been deleted.
+
0x05
+
The first character of the filename is actually 0xe5.
+
0x2e
+
The entry is for a directory, not a normal file. If the second byte
+is also 0x2e, the cluster field contains the cluster number of this
+directory's parent directory. If the parent directory is the root
+directory (which is statically allocated and doesn't have a cluster
+number), cluster number 0x0000 is specified here.
Any other
+character
+
This is the first character of a real filename.
+
+
+If a filename is fewer than eight characters in length, it is padded
+with space characters.
+
+
+
The Filename Extension
+
+The three bytes from offset 0x08 to 0x0a indicate the filename
+extension. There are no special characters. Note that the dot used to
+separate the filename and the filename extension is implied, and is not
+actually stored anywhere; it is just used when referring to the file.
+If the filename extension is fewer than three characters in length, it
+is padded with space characters.
+
+
+
The File Attributes
+
+The single byte at offset 0x0b contains flags that provide information
+about the file and its permissions, etc. The flags are single bits, and
+have meanings as follows. Each bit is given as its numerical value, and
+these are combined to give the actual attribute value:
+
+
+
0x01
+
Indicates that the file is read only.
+
0x02
+
Indicates a hidden file. Such files can be displayed
+if it is really required.
+
0x04
+
Indicates a system file. These are hidden as well.
+
0x08
+
Indicates a special entry containing the disk's volume label,
+instead of describing a file. This kind of entry appears only in the
+root directory.
+
0x10
+
The entry describes a subdirectory.
+
0x20
+
This is the archive flag. This can be set and cleared by the
+programmer or user, but is always set when the file is modified. It is
+used by backup programs.
+
0x40
+
Not used; must be set to 0.
+
0x80
+
Not used; must be set to 0.
+
+
+
The File Time
+
+The two bytes at offsets 0x16 and 0x17 are treated as a 16 bit value;
+remember that the least significant byte is at offset 0x16. They contain
+the time when the file was created or last updated. The time is mapped
+in the bits as follows; the first line indicates the byte's offset, the
+second line indicates (in decimal) individual bit numbers in the 16 bit
+value, and the third line indicates what is stored in each bit.
+
+
+<------- 0x17 --------> <------- 0x16 -------->
+15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
+h h h h h m m m m m m x x x x x
+
+
+where:
+
+
+
hhhhh
+
indicates the binary number of hours (0-23)
+
mmmmmm
+
indicates the binary number of minutes (0-59)
+
xxxxx
+
indicates the binary number of two-second periods (0-29),
+representing seconds 0 to 58.
+
+
+
+
The File Date
+
+The two bytes at offsets 0x18 and 0x19 are treated as a 16 bit value;
+remember that the least significant byte is at offset 0x18. They contain
+the date when the file was created or last updated. The date is mapped
+in the bits as follows; the first line indicates the byte's offset, the
+second line indicates (in decimal) individual bit numbers in the 16 bit
+value, and the third line indicates what is stored in each bit.
+
+
+<------- 0x19 --------> <------- 0x18 -------->
+15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
+y y y y y y y m m m m d d d d d
+
+
+where:
+
+
+
yyyyyyy
+
indicates the binary year offset from 1980 (0-119), representing the
+years 1980 to 2099
+
mmmm
+
indicates the binary month number (1-12)
+
ddddd
+
indicates the binary day number (1-31)
+
+
+
The Starting Cluster Number
+
+The two bytes at offsets 0x1a and 0x1b are treated as a 16 bit value;
+remember that the least significant byte is at offset 0x1a. The first
+cluster for data space on the disk is always numbered as 0x0002. This
+strange arrangement is because the first two entries in the FAT are
+reserved for other purposes.
+
+
+
The File Size
+
+The four bytes at offsets 0x1c to 0x1f are treated as a 32 bit value;
+remember that the least significant byte is at offset 0x1c. They hold
+the actual file size, in bytes.
+
+
+
Worked examples
+
+The best way to understand how to use the above information is to work
+though some simple examples.
+
+
Interpreting the contents of a block
+
+We assume that there is a tool available to display the contents of a
+block in both hexadecimal and as ASCII characters. Most such tools will
+display unusual ASCII characters (e.g. carriage return) as a dot. For
+example, here is a display of a typical boot block:
+
+
+
+
+
+As an illustration, one field in the boot block has been highlighted in
+red (the highlight appears twice, once for the hexadecimal
+representation and once for the ASCII representation). The numbers down
+the left hand side are the offsets (from the start of the block) of the
+first byte on that row, and the first row of digits along the top are
+the offset of each byte within the row. We can thus easily see that the
+highlighted area starts at offset 0x36.
+
+
+The area in question is (look back at the boot block layout) the file
+system type, in this case FAT16. To save us looking up each byte in a
+table of ASCII characters, we can simply consult the equivalent
+representation on the right hand side. 0x46 represents F, 0x41
+represents A, and so on.
+
+
+
Example 1 - find the root directory
+
+To find the root directory, we need to examine the file system data in
+the boot block. So, let's look again at the boot block of our example
+disk:
+
+
+
+
+
+We know that the root directory appears immediately after the last copy
+of the FAT. So what we need to find out is the size of the FAT, and how
+many copies there are. We also need to know the size of anything else
+that appears before the FAT(s); there is just the single block of the
+boot block. So, the number of blocks that appear before the root
+directory is given by:
+
+
+ (size of FAT)*(number of FATs) + 1
+
+
+All we need to do, then, is discover these values. First, we know that
+the number of FATs is stored at offset 0x10 (highlighted in green
+above); this tells us that there is just one FAT. Next, we need to know
+the size of a FAT; this is at offsets 0x16 and 0x17, where we find 0x14
+and 0x00 respectively (highlighted in red above). Remember that these
+two bytes together make up a 16 bit value, with the least significant
+byte stored first; in other words, the value is 0x0014 (in decimal, 20).
+So, the total number of blocks that precede the root directory is given
+by:
+
+
+ 0x0014*1 + 1 => 0x0015 (decimal 21)
+
+
+We should thus find the root directory in block 0x15, so let's look at
+it...
+
+
+
+
+
+It seems to have something occupying the first 0x20 bytes, and it's...a
+directory entry! We won't go into detail here, but detailed examination
+of those bytes would show that it's the special entry for the disk
+label. There don't appear to be any more entries in this directory.
+
+
+
Example 2 - find the attributes of a file
+
+In this example, the file FOOBAR.TXT has been created on the same disk,
+and it appears in the root directory. We wish to find out which
+attribute flags are set on the file.
+
+
+First, we need to find the root directory; we have already done this in
+example 1. Let's take a look at it after FOOBAR.TXT has been created:
+
+
+
+
+
+We can see fairly easily that the second directory entry (the one at
+offset 0x20) is that for FOOBAR.TXT. Remember that the dot between the
+filename and the filename extension is not actually stored, but is
+implied. We see the filename (highlighted in red) and the filename
+extension (highlighted in blue). We know that the attribute byte appears
+at offset 0x0b, and it is highlighted in green here.
+
+
+The value of the attribute byte is 0x21. We can express this in binary
+as:
+
+
+ 0 0 1 0 0 0 0 1
+
+
+Taking each of the bits separately, and making a hexadecimal number out
+of them, we get:
+
+Our table of attribute values shows that
+0x20 means that the 'archive flag' is set, and 0x01 indicates that the
+file is read-only.
+
+
+
Example 3 - find the date of a file
+
+Here, we want the date attached to a particular file (only one date is
+kept, which is the date of creation or last modification). The file in
+question is FOOBAR.TXT again.
+
+
+Let's look once more at the root directory; we have already done this in
+example 2, and indeed we already know that FOOBAR.TXT has a directory
+entry at offset 0x20:
+
+
+
+
+
+This time we are interested in the file date, and we know from our
+root directory layout that this is at
+offset 0x18 within each directory entry. Thus, the date for FOOBAR.TXT
+is at offset 0x20+0x18, or 0x38 (highlighted in red above). Once again,
+this is a 16 bit value with the least significant byte stored first. The
+bytes are 0x65 and 0x39 respectively, so reversing these and putting
+them together gives a value of 0x3965.
+
+
+Now all we have to do is analyse the components of this value. An easy
+way is first to convert it to binary, and this is even easier if we take
+it one hexadecimal digit at a time:
+
+
+ 3 9 6 5
+ | | | |
+ V V V V
+
+ 0 0 1 1 1 0 0 1 0 1 1 0 0 1 0 1
+
+
+Let's push all the digits together:
+
+
+ 0 0 1 1 1 0 0 1 0 1 1 0 0 1 0 1
+
+
+Now we can split them again on boundaries corresponding to the
+individual components of the date, as defined in the
+file date format. Then we convert each part
+back to decimal:
+
+Remember that the year is based at 1980, so if we add 1980 to 28, we get
+2008. The entire date is thus the 5th of November 2008.
+
+
+
Example 4 - find the data blocks for a file
+
+Here, we wish to find out the numbers of the blocks containing data for
+a particular file which has now been added to the disk. The name of the
+file is NETWORK.VRS.
+
+
+Once again, we find the root directory. Here are its latest contents,
+after NETWORK.VRS has been created:
+
+
+
+
+
+Note that the third directory entry (starting at offset 0x40) is that
+for NETWORK.VRS. We know that the starting cluster number for the file
+data occupies bytes at offsets 0x1a and 0x1b in a particular directory
+entry; thus the bytes we want are at offsets 0x5a and 0x5b (we just
+added 0x40, the offset of the start of the entry). These (highlighted in
+red) contain 0x4e and 0x0f respectively, and, remembering that the first
+byte is the least significant one, the number we want is 0x0f4e.
+Incidentally, the next four bytes (highlighted in blue) are the file
+size, again with the least significant byte first. These are 0x92, 0x06,
+0x00, 0x00 respectively, making a value of 0x00000692. This (in decimal)
+is 1682. So, this file is 1682 bytes long.
+
+
+Let's review what we know so far...
+
+
+
The starting cluster of the file is cluster 0x0f4e.
+
The root directory starts at block 0x15.
+
The first allocation unit starts at the first block after the root
+directory.
+
+
+What else do we need to know? We know where the root directory starts,
+but not where it ends. So we need the size of the root directory, in
+blocks. Let's look once again at the boot block:
+
+
+
+
+
+What we need to find this time is the maximum number of entries in the root
+directory; this is fixed when the disk is formatted. We know from the
+boot block layout that this appears in the two
+bytes starting at offset 0x11 in the boot block (these are highlighted
+in red above). These bytes contain 0x40 and 0x00 respectively, so
+(arranging as usual) this gives us a value of 0x0040 (64 in decimal). So
+there are 64 root directory entries. We know that one directory entry
+occupies 32 bytes, so the total space occupied by the root directory is
+64*32 bytes, or 2048 bytes. Each block is 512 bytes, so the number of
+blocks occupied by the root directory is 2048 divided by 512...that is,
+4.
+
+
+So, the root directory starts at block 0x15. Thus the first allocation
+unit starts at 0x15+4, or 0x19. So, to convert an allocation unit number
+to a block number, we need to add the constant value 0x19.
+And to convert a cluster number (which is what appears in the root
+directory) to a block number, we need to add 0x17, to allow for that
+strange offset of 2.
+
+
+We now know that the first data block of the file is at cluster
+number 0xf4e (see above). Adding the constant we have discovered, we
+find that this is block number 0xf4e+0x17, or 0xf65. Let's look at block
+0xf65:
+
+
+
+
+
+Well, that certainly looks like the start of a poem! Each line of the
+text is separated by a special character called newline, which
+has the code 0x0a (decimal 10). The first few of these are highlighted
+in red.
+
+
+We have nearly finished. There is obviously more of this file, and for us
+to find the rest of it, we need to consult the FAT. Recall that the
+starting cluster number of the file (the block we just looked
+at) is 0xf4e. Each entry in the FAT is two bytes in size, so we'll find
+the entry for that cluster at offset 0xf4e*2 in the FAT, which is offset
+0x1e9c (it's easier to add the value twice than attempt multiplication).
+We know that one disk block (and thus one block of the FAT) is 0x200
+bytes in size, so we just need to divide 0x1e9c by 0x200. This sounds
+hard, but it isn't. You can find tools for this, or do it yourself.
+Let's look at these two numbers in binary:
+
+The first number is a power of two, so to divide by it we simply shift
+the second number right - in this case by nine places:
+
+
+ 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 => 0x0f
+
+
+So the entry we want is in block 0x0f of the FAT. The remainder from our
+division is of course all the bits we lost when we shifted:
+
+
+ 0 1 0 0 1 1 1 0 0 => 0x9c
+
+
+so this is the byte offset of the entry within the FAT block.
+
+
+We need to find FAT block 0x0f. We know the FAT starts in block 1 of the
+disk (see earlier), so block 0x0f of the FAT will be in disk block
+0x0f+1, or block 0x10. Let's look at that block:
+
+
+
+
+
+We need to look at the FAT entry (two bytes) at offset 0x9c; this is
+highlighted in red above, and resolves to the 16 bit value 0x0f4f. This
+is actually the very next cluster, numerically, from the one we have
+just looked at (this will not always be the case), so we can apply a bit
+of common sense and deduce that the second data block of the file appears
+immediately after the first; thus, the first two blocks are at 0xf65 and
+0xf66. Here is block 0xf66:
+
+
+
+
+
+which certainly looks like the continuation of the poem. If we look at
+the FAT entry for this new cluster (which, since it's the next block,
+will also be the next cluster and thus in the next FAT entry), it is
+highlighted in blue above, and contains the value 0x0f50. This is the
+very next block and cluster:
+
+
+
+
+
+We continue this (again, it's the next block and cluster) and we find
+0x0f51 as the cluster number (highlighted in green above). Here is that block:
+
+
+
+
+
+Lastly, we look at the FAT entry for this block/cluster (highlighted in
+black). This time the entry is 0xffff, which indicates that there are no
+more blocks in the file. We have finished!
+
+
+
Conclusion
+
+If you've managed to get this far (and understood it all) you have a
+good working understanding of the 16-bit FAT file system. You should be
+able to analyse a disk, and see if it is corrupted. You may even be able
+to repair it!
+
+
+
+
+
+
+
+
+
+
+
+
+