Development of a GUI widget For MACE Telescope Using Qt4 ...

A Project On

Development of a GUI widget For MACE Telescope Using Qt4®. &

Implementation of FAT Using C++ Under the supervision of Mr. T. S. Ananthkrishnan

For partial fulfillment of the Practice School 1 program

Qt is registered trademark of Trolltech

A Project On

Development of a GUI widget For MACE Telescope Using Qt4®. &

Implementation of FAT Using C++ Under the supervision of Mr. Sandeep Bharade

For partial fulfillment of the Practice School 1 program Prepared By Mayank Mohta 2006A7PS050 Dushyant Arora 2006A7PS083

Qt is registered trademark of Trolltech

3

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE, PILANI, PILANI CAMPUS PRACTICE SCHOOL DIVISION

Station: Bhabha Atomic Research Center, Trombay

Centre: Mumbai

Duration: From 22nd May, 2008 to 15th July, 2008 Date of submission: 14th July, 2008 Title of the Project: Development of a GUI widget for MACE telescope using Qt4 & Implementation of FAT using C++

Submitted by: Mayank Prakash Mohta Dushyant Arora

ID: 2006A7PS050 ID: 2006A7PS083

Name of the PS Faculty: Mr. Vijay Sharma Name and designation of experts: 1) Mr. Sandeep Bharade, Scientific Officer (E), BARC 2) Dr T.S. AnanthKrishnan, Scientific Officer (H), BARC Key Words: C++, Qt, MACE Telescope, FAT, boot sector, root directory Project Area: C++ GUI Programming with Qt, FAT Implementation using C++

Signature of Student

Signature of PS Faculty

Date:

Date:

ACKNOWLEDGEMENTS In the journey so far, we have been generously helped and guided by a number of individuals. Firstly we would like to thank our guide Mr. T.S. AnanthKrishnan, Head of Acceleration Control System Section, B.A.R.C. for giving us this great opportunity and his constant support and backing. Also we would like to thank Mr. Sandeep Bharade, Scientific Officer B.A.R.C. under whose supervision our project training was carried out. His inspiring words kept us motivated and made us give our best efforts. We would also like to thank Mr.Sudheer who provided us with the requisite study material and softwares, which we had a difficult time acquiring ourselves. We would like to thank our PS instructor, Mr. Vijay Sharma for infusing us with enthusiasm and helping us with the various administrative procedures. We would also like to thank Dean, PS Division BITS Pilani for this wonderfully structured, exposure oriented PS1 programme.

1

Abstract A MACE Telescope is being installed at Hanle, Leh, India. ‘MACE’ stands for Major Atmospheric Cerenkov Events. The aim of the telescope is to recognize the onset of cosmic events of interest using a predefined trigger configuration of the detectors and record the signal acquired by all the PMTs (Photo Multiplier Tube) for the registered trigger. Our first project at B.A.R.C. revolved around developing a GUI (Graphical User Interface) for the MACE Telescope console that replicates the arrangement of the PMTs on a widget and allows the operator to control the various parameters involved in the process. This report explains about the Qt toolkit, which was used for development of the aforementioned GUI. The report encompasses the building and integration process of the widget and finally talks about the future aspects of the project. Our next project involved implementation of FAT (File Allocation Table) for an ECG data acquisition and recording system has been developed at B.A.R.C. This system will record the patients ECG data and store it on an embedded device. This report explains about the Disk Organization in MS DOS, boot sector, root directory and the FAT tables which are the underlying concepts used in our project. Finally the report touches upon the operational features our program and gives a detailed explanation of their functionality. This report has a detailed description of the work done by us during the seven weeks of stay at B.A.R.C. We have tried to document and arrange our entire work and present it in an easy to comprehend manner.

2

Table of Contents Title 1.

Page Number

Introduction

7

PROJECT 1 2. 2.1 2.2 2.3 2.4 3.

About Qt

10

A Brief History of Qt Salient Features of Qt4 Applications built using Qt Sample Qt Application and the Compiling Process

10 11 12 12

About the MACE Telescope

14

3.1 Introduction 3.2 General requirements of CDACS

14 15

4.

Operational Features Required by the Widget

17

5.

Building Process of the Widget

17

5.1 Stage1 5.2 Stage2

17 18

5.3 Stage3

19

5.3.1 Model1 5.3.2 Model2 5.3.3 Model3

19 20 21

5.4 Integrating the widget with Qt designer 6.

Future Aspects

22 25

3

PROJECT 2 1.

The Boot Sector

28

2.

The File Allocation Table

32

3.

The Root Directory

33

4.

The Files Area

35

5.

Interpreting the File Allocation Table

37

6.

Implementation of Basic Functions of FAT File System

39

DIR Function READ File Function WRITE File Function RENAME File Function DELETE File Function MAKE DIR Function CHANGE DIR Function RENAME DIR Function DELETE DIR Function

41 42 43 44 45 46 47 47 48

7.

Future Aspects

49

8.

Conclusion

50

9.

Appendix

51

10.

Bibliography

53

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9

4

List Of Illustrations Figure

Page Number

1. Screenshot of Hello on Windows

13

2. MACE Telescope Prototype

14

3. Screenshot for stage 1 GUI

17

4. Screenshot for Stage 2 GUI

18

5. Screenshot for Stage 3 -Model 1 GUI

19

6. Screenshot for Stage 3 –Model 2 GUI

20

7. Screenshot for Stage 3 -Model 3 GUI

21

8. Screenshot of Qt designer with integrated telescope widget.

24

9. Map of a typical MS DOS logical volume

27

10. Screenshot of hex dump of the boot sector on DiskEdit

29

11. Extract from the root directory of an MS DOS disk, showing the entry for a sub-directory named Document

34

12. Hex dump of the first block of the directory Document. The directory has three entries . , .. and one file PS1.txt

36

13. Linking of files by FAT

38

14. Screenshot of the choice menu of our application

39

15. Screenshot of the output of Dir function. It shows 2 directories red and blue, 1 file README.TXT

42

16. Screenshot of the output of read file function

43

17. Screenshot of the output of write file function

44

5

18. Screenshot of the output of write file function using edit file option

44

19. Screenshot of the output of rename file function

45

20. Screenshot of the output of delete file function

45

21. Screenshot of the output of make directory function followed by call to dir function

46

22. Screenshot of the output of change directory function followed by call 47 to dir function 23. Screenshot of the output of rename directory function

48

24. Screenshot of the output of delete directory function

48

Table

Page Number

1. Fields in Boot Sector (Logical Sector 0) of FAT File System

28

2. BIOS Parameter Block and Extended BIOS Parameter Block Fields

30

3. Interpretation of FAT

32

4. Interpretation of the first byte of a directory entry

33

5. Format of a single entry in a disk directory. Total length is 32 bytes(20H bytes)

35

6. Mapping of the attribute byte of the directory entry

37

6

1. Introduction We started our practice school 1 on 22nd May, 2008 at Bhabha Atomic Research Centre (B.A.R.C.). We were allotted a project in the Electronics division of B.A.R.C. under Dr. T. S. Ananthkrishnan (Scientific Officer / H) on 26th of May, 2008. Two independent projects were done by us during our Practice School 1 program. The details of both the projects are as follows:

Project 1 Project Name:

Development of a Widget for MACE telescope using Qt 4.

Guide:

Mr. T. S. Ananthkrishnan

Purpose of the Project: A gamma ray telescope is being installed at Hanle, Leh. It requires a GUI interface. The GUI interface built should enable the users to view the desired data efficiently and quickly. Also, the GUI built should be platform independent, which is one of the major reasons of choosing Qt as our development tool.

Basic Project Information: The telescope contains a 2 – Dimensional arrangement of photo multiplier tubes. These photo multiplier tubes generate signals whose amplitude depends on light intensity and these signals are converted to integer values. Our widget replicates the arrangement of the photo multiplier tubes on a screen, each photo multiplier tube being displayed as a square cell, whose color depends on the value obtained from the actual tube. This provides a quick picture of the pattern of light falling on this set of photo multiplier tubes.

7

Project 2 Project Name:

Implementation of File Allocation System (FAT) using C++.

Guide:

Mr. T. S. Ananthkrishnan and Mr. Sandeep Bharade.

Purpose of the Project:

Small embedded systems often receive data and store it in raw form on

the data storage device (SD card, USB flash memory etc.). This Data if FAT formatted first and then stored can be directly used for viewing. Thus, our program, written in C++, is a module of a project that will help store and retrieve data in a systematic format in these storage devices associated with these embedded systems.

Basic Project Information: We basically assume that the hex dump of a storage device is available in an array. Now we implement functions like write, read, dir etc which manipulate this array. When a file is stored, it is stored using the FAT format. Similarly reading, deleting, renaming of files are all done using the norms of the basic disk organization.

8

PROJECT - 1

Development of a GUI widget for MACE Telescope using Qt4®.

9

2.

About Qt

Qt is a comprehensive C++ framework for developing cross-platform GUI applications using a "write once, compile anywhere" approach.

2.1 A Brief History of Qt: The Qt framework first became publicly available in May 1995. It was initially developed by Haavard Nord (Trolltech's CEO) and Eirik Chambe-Eng (Trolltech's president). In the summer of 1990, Haavard and Eirik were working together on a C++ database application for ultrasound images. The system needed to be able to run with a GUI on UNIX, Macintosh, and Windows. One day that summer, Haavard and Eirik went outside to enjoy the sunshine, and as they sat on a park bench, Haavard said, "We need an object-oriented display system." The resulting discussion laid the intellectual foundation for the object-oriented cross-platform GUI framework they would soon go on to build. In 1991, Haavard started writing the classes that eventually became Qt, collaborating with Eirik on the design. By 1993, Haavard and Eirik had developed Qt's first graphics kernel and were able to implement their own widgets. The year 1994 began inauspiciously with the two young programmers wanting to enter a well-established market, with no customers, an unfinished product, and no money. The letter 'Q' was chosen as the class prefix because the letter looked beautiful in Haavard's Emacs font. The 't' was added to stand for "toolkit", inspired by Xt, the X Toolkit. The company was incorporated on March 4, 1994, originally as Quasar Technologies, then as Troll Tech, and today as Trolltech. On May 20, 1995, Qt 0.90 was uploaded to sunsite.unc.edu. This was Qt's first public release. Qt could be used for both Windows and Unix development, offering the same API on both platforms. Qt was available under two licenses from day one: A commercial license was required for commercial development, and a free software edition was available for open source development. On September 24, 1996, Qt 1.0 came out. By the end of the year, Qt had reached version 1.1; eight customers, each in a different country, had bought 18 licenses between them. This year also saw the founding of the KDE project, led by Matthias Ettrich. Matthias Ettrich's decision to use Qt to build KDE helped Qt become the de facto standard for C++ GUI development on Linux.

10

Qt 2.0 was released in June 1999. By the end of 2000, Trolltech had established Trolltech Inc. (USA) and had released the first version of Qtopia, an application platform for mobile phones and PDAs. Qt 3.0 was released in 2001. Qt was now available on Windows, Mac OS X, UNIX, and Linux. In the summer of 2005, Qt 4.0 was released. Qt 4 is larger and richer than any previous version, and it has been split into several libraries so that developers only need to link against the parts of Qt that they need.

2.2 Salient Features of Qt4 •

Qt is a cross-platform, graphical application development toolkit that enables you to compile and run your applications on Windows, Mac OS X, Linux, and different brands of UNIX.

•

Qt4 has about 500 classes and more than 9000 functions.

•

In addition to Qt's hundreds of classes, there are add-ons that extend Qt's scope and power. Some of these products, like Qt Script for Applications (QSA) and the Qt Solutions components are available easily on Trolltech site.

•

Qt 4 is a huge advance on previous versions with improvements that include a completely new set of efficient and easy-to-use template containers, advanced model/view functionality, a fast and flexible 2D painting framework, and powerful Unicode text viewing and editing classes, not to mention thousands of smaller enhancements across the complete range of Qt classes.

•

Qt Designer is Trolltech's tool for designing and building graphical user interfaces (GUIs) from Qt components. It allows you to design and build widgets (a visual element in a user interface) and dialogs using on-screen forms using the same widgets that will be used in your application.

11

2.3 Applications Build using Qt Qt is the foundation on which the K Desktop Environment (KDE) and the many exciting applications like Opera web browser, Adobe Photoshop Album, Skype, Google Earth etc. have been built.

2.4 Sample Qt Application and the Compiling Process

Hello Qt Let's see a very simple Qt program. We will first study it line by line, and then we will see how to compile and run it. 1 #include 2 #include 3 int main(int argc, char *argv[]) 4{ 5

QApplication app(argc, argv);

6

QLabel *label = new QLabel("Hello Qt!");

7

label->show();

8

return app.exec();

9}

Lines 1 and 2 include the definitions of the QApplication and QLabel classes. For every Qt class, there is a header file with the same name (and capitalization) as the class that contains the class's definition. Line 5 creates a QApplication object to manage application-wide resources. The QApplication constructor requires argc and argv because Qt supports a few command-line arguments of its own. Line 6 creates a QLabel widget that displays "Hello Qt!". In Qt and Unix terminology, a widget is a visual element in a user interface. Buttons, menus, scroll bars, and frames are all examples of widgets. Widgets can contain other widgets; for example, an application window is usually a widget 12

that contains a QMenuBar, a few QToolBars, a QStatusBar, and some other widgets. Most applications use a QMainWindow or a QDialog as the application window, but Qt is so flexible that any widget can be a window. In this example, the QLabel widget is the application window. Line 7 makes the label visible. Widgets are always created hidden, so that we can customize them before showing them, thereby avoiding flicker. Line 8 passes control of the application on to Qt. At this point, the program enters the event loop. This is a kind of stand-by mode where the program waits for user actions such as mouse clicks and key presses. User actions generate events (also called "messages") to which the program can respond, usually by executing one or more functions. For example, when the user clicks a widget, a "mouse press" and a "mouse release" event are generated.

Figure1. Screenshot of Hello on Windows.

Now we will compile and run the application. We will assume that we have a correctly installed copy of Qt 4 and that Qt's bin directory is in your PATH environment variable. From a command prompt, change the directory to hello, then type qmake -project

to create a platform-independent project file (hello.pro), then type qmake hello.pro

to create a platform-specific makefile from the project file. Type make to build the program. Run it by typing hello on Windows, ./hello on Unix, and open hello.app on Mac OS X. To terminate the program, click the close button in the window's title bar. If we are using Microsoft C++, we will need to run nmake instead of make. Alternatively, we can create a Visual Studio project file from hello.pro by typing qmake -tp vc hello.pro

and then build the program in Visual Studio.

13

3.

About the MACE Telescope

Figure2. MACE Telescope prototype

3.1 Introduction: ApSD at Hanle is setting up a high-energy gamma-ray telescope. In the final stage, the telescope will deploy large area tracking light collectors separated by a distance of 70-100m for taking stereoscopic snapshots of the Atmospheric Cerenkov Events (ACE). Each element of the telescope will comprise a 17m diameter light collector with a photomultiplier based imaging camera at its focus. While the large area light collector will decrease the energy threshold of the telescope to the hitherto unexplored energy region of 30-300 GeV, the stereoscopic mode of operation will enhance its gamma/proton segregation capabilities. The imaging camera, which will use 960 photo-multiplier tubes, has a fine granulation of 0.10 in the central part and a 0.20 pixel size along the periphery. The 14

large number of detector channels required by the telescope has led to the evolution of a new design concept for the Camera Data Acquisition and Control System (CDACS). The features of the MACE telescope are as follows:


Location: Hanle, Leh, India.
Altitude: 4500 m ASL.
Size: 21 m telescope.
Resolution: 
Mirrors:

960 Pixel Camera. 576 (0.1 degree) and 324 (0.2 degree) PMTs. Square shaped spherical facet mirrors in Quasi Parabolic Structure.



4 facets per panel, 356 panels.



Size: 488 mm X 488 mm & 192 mm X 192 mm.


Energy Range: 30 GeV – 30 TeV.

3.2

General Requirements of CDACS

The aim of the telescope is to recognise the onset of cosmic events of interest using a predefined trigger configuration of the detectors and record the signal acquired by all the PMTs for the registered trigger. The system also needs to provide mass data storage and server facility for web access to preprocessed data for users world over and remote access to the CDACS so that it can be operated remotely from Trombay, Mumbai.

The location of the telescope (Hanle) makes it necessary that the telescope will be operated with minimum operational staff. Hence it is important that the complete electronics should work with minimum failure rate and minimum maintenance, making it necessary that certain level of redundancy has to be built in to the hardware. Also to ensure high availability of the entire telescope, the overall architecture should be such that in case of partial failure, the telescope should operate partially and data collected should be useful. Also the healthiness of the telescope will be checked at regular interval through self-diagnostics

15

These requirements on the CDACS can be enumerated as follows:


Sampling PMT signals
Recognising of cosmic event of interest from the PMT signals
Generating of trigger
Digitising PMT signal profile
Collecting the data to a central location
Applying further data reduction criterion
Downloading to a ground station
Setting and Monitoring of HV and anode current
Monitoring temperature and heating

16

4.

Operational Features Required by the Widget •

There are 1408 Photo Multiplier Tubes (PMT) in the telescope, each PMT in a unique group of 16. Depending on the intensity of light falling on each tube a voltage is generated and using ADC it is converted into a float value. These values will be available to us in a 2dimensional array (Assume the array to be PMT_values[][].

•

The user can make various intervals and assign a colour value to each interval.

•

Using the float values available in the array and the intervals made the widget should generate a pixmap colouring the cell[i][j] with the colour corresponding to interval in which PMT_values[i][j] lies.

•

The widget should also display the zoomed image of the group of 16 cells on which the user clicks.

5.

Building Process of the Widget

5.1 Stage 1

Figure 3. Screenshot for stage 1 GUI

17

Our first challenge was to create a representation of the Photo Multiplier Tubes. For the time being we generated floating point values using a random number generation function and fill the 2dimensional PMT_values[i][j] array. We assumed that intervals are 0-2, 2-4, 4-6, 6-8 and 8-10. Fixed colours were assigned to each interval. Using drawline() function of the QPainter class we made a grid of 40 x 40 , each cell representing a PMT. The function convert_to_color(int A[][], int i, int j) returned a QColor object corresponding to A[i][j]. Using this colour and fillrect() function of QPainter class each cell was filled. The telescope continuously takes pictures of the sky and the data in the array gets refreshed continuously. To ascertain whether the refresh rate of the widget is sufficient, we needed a simulation that would keep on changing the value of the PMT_values array after regular delays. To accomplish this we used the QTimer class object.

5.2 Stage 2

Figure4. Screenshot for Stage 2 GUI

18

Next we needed to provide the user the flexibility to assign colours to different intervals. We provided five buttons in the widget corresponding to the five ranges, which when clicked would display a colour dialog. The user can thus pick the colour of his choice for the respective interval. This was implemented using QColorDialog class. The zoomed image of the group of 16 cells is displayed when the user right clicks on it. This was implemented using QMouseEvent class, which captures the position of the point where the user has right clicked, and QPainter class which paints the zoomed image.

5.3 Stage 3 Next step in the widget development process was to provide the user the flexibility to change the ranges of the intervals. We developed 3 models each of which was a refinement from the previous one.

• Model 1:

Figure5. Screenshot for Stage 3 -Model 1 GUI

19

In this model we provided combo boxes for selecting the ranges. Qt Widgets emit signals to indicate that a user action or a change of state has occurred. A signal can be connected to a function (called a slot in that context), so that when the signal is emitted, the slot is automatically executed. Whenever the user changes the range a range_changed() signal is emitted. This is connected to a refresh() slot. This slot generates a paint event, which repaints the image according to the new values. The SIGNAL()

and SLOT() macros are part of the syntax in Qt.

connect(range_combo_box, SIGNAL(range_changed()), telescope_widget , SLOT(refesh()));

• Model 2: We realized that this model was not user friendly and lacked clarity as the user had to scroll down the combo-box each time he had to change the range. To eradicate this cumbersome process we decided to use a slider and a spinbox. We also grouped the colour button thus reducing the number push buttons.

Figure6. Screenshot for Stage 3 –Model 2 GUI

20

This model allows the user to choose the start and end values of each interval. Also the intervals need not be continuous unlike the previous models. Thus the current model provided more freedom to the user and was an improvement over the previous models. However it was still cumbersome to operate and the user did not get a clear picture of the ranges he has set. Therefore we had to work on a more visually descriptive and easily operable model.

Model 3: This is our final widget. The improvements of this widget over the previous models are that the actual arrangement of the PMTs on the telescope is replicated in our widget. A color band is provided whose boundary can be dragged using the mouse thus resizing the intervals. The current ranges of intervals are visible and get refreshed automatically when the colour bands are dragged.

Figure7. Screenshot for Stage 3 -Model 3 GUI

21

The colour band has been implemented using frames. The QMouseMoveEvent class detects the current cursor position. If it is on the any boundary then the mouse cursor changes indicating that the boundary can be dragged. On double clicking anywhere on the band, a colour dialog pops out which can be used to change the colour of the corresponding interval. The spin box shows the value corresponding to the position of mouse on the colour band. Also a Save Image button has been added which opens a Save File Dialog as shown in Figure6 which allows the operator to save the image in .bmp format for further usage. Thus, this widget encompasses all the functionalities of the previous models and provides a user friendly and efficient way to change the variables involved.

5.4

Integrating the widget with Qt designer After creating the widget with the necessary requirements, our next task was to integrate the

widget with the Qt designer so that it could be directly used in other projects. We created a new header file which consisted of a tel_plugin class. This class provided all the essential information required for the integration of the widget.

The plugin approach requires the creation of a plugin library that Qt Designer can load at run-time and use to create instances of the widget. The real widget is then used by Qt Designer when editing the form and for previewing, and thanks to Qt's meta-object system, Qt Designer can dynamically obtain the list of its properties. First, we must subclass QDesignerCustomWidgetInterface and reimplement some virtual functions.

The tel_plugin subclass is a factory class that encapsulates the tel widget. It inherits both QObject and QDesignerCustomWidgetIterface and uses the Q_INTERFACES() macro to tell moc that the second base class is a plugin interface. The functions are used by Qt Designer to create instances of the class and to obtain information about it.

22

Here is the class definition:

class QDesignerFormEditorInterface; class telplugin: public QObject, public QDesignerCustomWidgetInterface { Q_OBJECT Q_INTERFACES (QDesignerCustomWidgetInterface) public: telplugin(QObject *parent = 0); bool isContainer() const; bool isInitialized() const; QIcon icon() const; QString codeTemplate() const; QString domXml() const; QString group() const; QString includeFile() const; QString name() const; QString toolTip() const; QString whatsThis() const; QWidget *createWidget(QWidget *parent); void initialize(QDesignerFormEditorInterface *core); private: bool initialized; };

At the end of the source file that implements the plugin class, we must use the Q_EXPORT_PLUGIN2() macro to make the plugin available to Qt Designer. The first argument is the name we want to give the plugin; the second argument is the name of the class that implements it. The .pro file for building the plugin looks like this: TEMPLATE CONFIG HEADERS

= lib += designer plugin release = ../tel/tel.h \ telplugin.h 23

SOURCES

= ../tel/tel.cpp \ teplugin.cpp

RESOURCES

= telplugin.qrc

DESTDIR

= $(QTDIR)/plugins/designer

The .pro file assumes that the QtdIR environment variable is set to the directory where Qt is installed. When you type make or nmake to build the plugin, it will automatically install itself in Qt Designer's plugins directory. Once the plugin is built, the tel widget can be used in Qt Designer in the same way as any of Qt's built-in widgets.

Figure8. Screenshot of Qt designer with integrated telescope widget.

24

6.

FUTURE ASPECTS

•

The data acquisition presently is merely a simulation using random function. Integrating it with the database and acquiring data from database in real time is also a big challenge.

•

Feature of zoom on scrolling can be added for better analysis.

•

The number of intervals is 5 or less. Provision can be provided to change this number at runtime.

•

Stringent efficiency measurements and rigorous testing needs to be done before it can be actually used in the telescope console.

25

PROJECT - 2

Implementation of FAT Using C++

MOTIVATION FOR THE PROJECT An ECG data acquisition and recording system has been developed at B.A.R.C. This system will record the patients ECG data and store it on an embedded device. This embedded device will store this data on a SD card or a USB Flash Drive so that it can be viewed for analysis in the future. The doctors can simply plug the USB Drive/SD Card to a computer and view the patients ECG data. Our project was to develop a small module for the embedded device. The data received from the patient is in raw form and needs to be stored in an organized and systematic fashion onto the storing media. We have implemented the FAT format and disk organization norms for the same.

26

MS DOS Disks are organized according to a rather rigid scheme that is easily understood and therefore easily manipulated. From the application programmer’s viewpoint, MS-DOS presents disk devices as logical volumes that are associated with a drive code (A, B, C, and so on) and that have a volume name (optional), a root directory, and from zero to many additional directories and files. MS-DOS shields the programmer from the physical characteristics of the medium by providing a battery of disk services through Int 21H. Using these services, the programmer can create, open, read, write, close, and delete files in a uniform way,

Each MS-DOS logical volume is divided into several fixed-size control areas and a files area (Figure 9). The size of each control area depends on several factors-the size of the volume and the version of FORMAT used to initialize the volume, for example-but all of the information needed to interpret the structure of a particular logical volume can be found on the volume itself in the boot sector.

Figure9. Map of a typical MS DOS logical volume.

27

1. The Boot Sector Logical sector 0, known as the boot sector, contains all of the critical information regarding the disk medium characteristics (Table 2). The boot sector (logical sector 0) contains the OEM identification, BIOS parameter block (BPB), and disk bootstrap .The first byte in the sector is always an 80x86 jump instruction-either a normal intrasegment JMP (opcode 0E9H) followed by a 16-bit displacement or a “short” JMP (opcode 0EBH) followed by an 8-bit displacement and then by an NOP (opcode 90H). If neither of these two JMP opcodes is present, the disk has not been formatted or was not formatted for use with MS-DOS. (Of course, the presence of the JMP opcode does not in itself ensure that the disk has an MS-DOS format.) Following the initial JMP instruction is an 8-byte field that is reserved by Microsoft for OEM identification. The disk-formatting program, which is specialized for each brand of computer, disk controller, and medium, fills in this area with the name of the computer manufacturer and the manufacturer’s internal MS-DOS version number.

Byte Offset (in hex)

Field Length

Sample Value

Meaning

00

3 bytes

EB 3C 90

Jump instruction

03

8 bytes

MSDOS5.0

OEM Name in text

0B

25 bytes

BIOS Parameter Block

24

26 bytes

Extended BIOS Parameter Block

3E

448 bytes

Bootstrap code

1FE

2 bytes

0x55AA

End of sector marker

TABLE 1. Fields in Boot Sector (Logical Sector 0) of FAT File System.

The third major component of the boot sector is the BIOS parameter block (BPB) in bytes 0BH through 17H.

28

Figure10. Screenshot of hex dump of the boot sector on DiskEdit

This data structure describes the physical disk characteristics and allows the device driver to calculate the proper physical disk address for a given logical-sector number; it also contains information that is used by MS-DOS and various system utilities to calculate the address and size of each of the disk control areas (file allocation tables and root directory). The final element of the boot sector is the disk bootstrap routine. The disk bootstrap is usually read into memory by the ROM bootstrap, which is executed automatically when the computer is turned on.

29

Byte Offset

Field Length

Sample Value

Meaning

0x0B

WORD

0x0002

Bytes per Sector. The size of a hardware sector. For most disks in use, the value of this field is 512.

0x0D

BYTE

0x08

Sectors Per Cluster.The default cluster size for a volume depends on the volume size and the file system.

0x0E

WORD

0x0100

Reserved Sectors. The number of sectors from the Partition Boot Sector to the start of the first file allocation table, including the Partition Boot Sector. The minimum value is 1. If the value is greater than 1, it means that the bootstrap code is too long to fit completely in the Partition Boot Sector.

0x10

BYTE

0x02

Number of file allocation tables (FATs). The number of copies of the file allocation table on the volume. Typically, the value of this field is 2.

0x11

WORD

0x0002

Root Entries. The total number of file name entries that can be stored in the root folder of the volume. One entry is always used as a Volume Label. Files with long filenames use up multiple entries per file. Therefore, the largest number of files in the root folder is typically 511, but you will run out of entries sooner if you use long filenames.

0x13

WORD

0x0000

Small Sectors. The number of sectors on the volume if the number fits in 16 bits (65535). For volumes larger than 65536 sectors, this field has a value of 0 and the Large Sectors field is used instead.

0x15

BYTE

0xF8

Media Type. Provides information about the media being used. A value of 0xF8 indicates a hard disk.

30

0x16

WORD

0xC900

Sectors per file allocation table (FAT). Number of sectors occupied by each of the file allocation tables on the volume. By using this information, together with the Number of FATs and Reserved Sectors, you can compute where the root folder begins. By using the number of entries in the root folder, you can also compute where the user data area of the volume begins.

0x18

WORD

0x3F00

Sectors per Track. The apparent disk geometry in use when the disk was low-level formatted.

0x1A

WORD

0x1000

Number of Heads. The apparent disk geometry in use when the disk was low-level formatted.

0x1C

DWORD

3F 00 00 00

Hidden Sectors. Same as the Relative Sector field in the Partition Table.

0x20

DWORD

51 42 06 00

Large Sectors. If the Small Sectors field is zero, this field contains the total number of sectors in the volume. If Small Sectors is nonzero, this field contains zero..

0x24

BYTE

0x80

Physical Disk Number. This is related to the BIOS physical disk number. Floppy drives are numbered starting with 0x00 for the A disk. Physical hard disks are numbered starting with 0x80. The value is typically 0x80 for hard disks, regardless of how many physical disk drives exist, because the value is only relevant if the device is the startup disk.

0x25

BYTE

0x00

Current Head. Not used by the FAT file system.

0x26

BYTE

0x29

Signature. Must be either 0x28 or 0x29 in order to be recognized by Windows NT.

0x27

4 bytes

CE 13 46 30

Volume Serial Number. A unique number that is created when you format

31

the volume.

0x2B

11 bytes

NO NAME

Volume Label. This field was used to store the volume label, but the volume label is now stored as special file in the root directory.

0x36

8 bytes

FAT16

System ID. Either FAT12 or FAT16, depending on the format of the disk.

TABLE 2. BIOS Parameter Block and Extended BIOS Parameter Block Fields

2. The File Allocation Table When a file is created or extended, MS-DOS assigns it groups of disk sectors from the files area in powers of 2. These are known as allocation units or clusters. The number of sectors per cluster for a given medium is defined in the BPB and can be found at offset 0DH in the disk’s boot sector. The file allocation table (FAT) is divided into fields that correspond directly to the assignable clusters on the disk. These fields are 12 bits in MS-DOS versions 1 and 2 and may be either 12 bits or 16 bits in versions 3.0 and later, depending on the size of the medium (12 bits if the disk contains fewer than 4087 clusters, 16 bits otherwise). The first two fields in the FAT are always reserved. The remainder of the FAT entries describes the use of their corresponding disk clusters. The contents of the FAT fields are interpreted as follows:

Value

Meaning

(0)000H (F)FF0 – (F)FF6H (F)FF7H (F)FF8 – (F)FFFH (X)XXX

Cluster Available Reserved Cluster Bad Cluster Last Cluster of a File Next Cluster of the File TABLE 3: Interpretation of FAT

32

Each file’s entry in a directory contains the number of the first cluster assigned to that file, which is used as an entry point into the FAT. From the entry point on, each FAT slot contains the cluster number of the next cluster in the file, until a last-cluster mark is encountered. At the computer manufacturer’s option, MS-DOS can maintain two or more identical copies of the FAT on each volume. MS-DOS updates all copies simultaneously whenever files are extended or the directory is modified. If access to a sector in a FAT fails due to a read error, MS-DOS tries the other copies until a successful disk read is obtained or all copies are exhausted. Thus, if one copy of the FAT becomes unreadable due to wear or a software accident, the other copies may still make it possible to salvage the files on the disk. As part of its procedure for checking the integrity of a disk, the CHKDSK program compares the multiple copies (usually two) of the FAT to make sure they are all readable and consistent.

3. The Root Directory Following the file allocation tables is an area known in MS-DOS versions 2.0 and later as the root directory. The root directory contains 32-byte entries that describe files, other directories, and the optional volume label (Table 5). An entry beginning with the byte value E5H is available for reuse; it represents a file or directory that has been erased. An entry beginning with a null (zero) byte is the logical end-of directory; that entry and all subsequent entries have never been used.

Value

Meaning

00H

Directory entry has never been used; end of occupied portion of directory First Character of Filename is actually E5H Entry is an alias for the current or the parent directory. If the next byte is also 2EH, the cluster field contains the cluster number of the parent directory (zero if the parent directory is the root directory). File has been erased.

05H 2EH

E5H

TABLE 4 Interpretation of the first byte of a directory entry

33

The root directory has a number of special properties. Its size and position are fixed and are determined by the FORMAT program when a disk is initialized. This information can be obtained from the boot sector’s BPB. If the disk is bootable, the first two entries in the root directory always describe the files containing the MS-DOS BIOS and the MS-DOS kernel. The disk bootstrap routine uses these entries to bring the operating system into memory and start it up.

Figure11. Extract from the root directory of an MS DOS disk, showing the entry for a sub directory named Document

34

00H

Filename (8 bytes)

07H 08H Extension (3 bytes) 0AH 0BH 0CH

File Attribute (1 byte)

Reserved (10 bytes)

16H

Time created or last updated (2 bytes)

18H 19H 1AH

Date created or last updated (2 bytes) Starting Cluster (2 bytes)

1CH File Size (4 bytes) 1FH

Table 5. Format of a single entry in a disk directory. Total length is 32 bytes (20H bytes)

4. The Files Area The remainder of the volume after the root directory is known as the files area. MS-DOS views the sectors in this area as a pool of clusters, each containing one or more logical sectors, depending on the disk format. Each cluster has a corresponding entry in the FAT that describes its current use: available, reserved, assigned to a file, or unusable (because of defects in the medium). Because the 35

first two fields of the FAT are reserved, the first cluster in the files area is assigned the number 2. When a file is extended under versions 1 and 2, MS-DOS searches the FAT from the beginning until it finds a free cluster (designated by a zero FAT field); it then changes that FAT field to a last cluster mark and updates the previous last cluster of the file’s chain to point to the new last cluster. Under versions 3.0 and later, however, MS-DOS searches the FAT from the most recently allocated cluster; this reduces file fragmentation and improves overall access times. Directories other than the root directory are simply a special type of file. Their storage is allocated from the files area, and their contents are 32-byte entries-in the same format as those used in the root directory-that describe files or other directories. Directory entries that describe other directories contain an attribute byte with bit 4 set, zero in the file-length field, and the date and time that the directory was created . The first cluster field points, of course, to the first cluster in the files area that belongs to the directory. (The directory’s other clusters can be found only by tracing through the FAT.)

Figure12. Hex dump of the first block of the directory Document. The directory has three entries. , .. and one file PS1.txt

All directories except the root directory contain two special directory entries with the names. and ... MS-DOS puts these entries in place when it creates a directory, and they cannot be deleted. The . entry is an alias for the current directory; its cluster field points to the cluster in which it is found. The .. entry is an alias for the directory’s parent (the directory immediately above it in the tree structure); its cluster field points to the first cluster of the parent directory. If the parent is the root directory, the cluster field of the .. entry contains zero.

36

Value 0 1 2 3 4 5 6 7

Meaning Read-only; attempts to open file for write or to delete file will fail. Hidden File; excluded from normal searches. System File; excluded from normal searches. Volume label; can exist only in root directory Directory; excluded from normal searches. Archive bit; set whenever file is modified. Reserved. Reserved. TABLE 6. Mapping of the attribute byte of the directory entry

5. Interpreting the File Allocation Table Now that we understand how the disk is structured, we can use this knowledge to find a FAT position from a cluster number.

If the FAT has 12-bit entries, use the following procedure:

1. Use the directory entry to find the starting cluster of the file in question. 2. Multiply the cluster number by 1.5. 3. Use the integral part of the product as the offset into the FAT and move the word at that offset into a register. Remember that a FAT position can span a physical disk-sector boundary. 4. If the product is a whole number, AND the register with 0FFFH. 5. Otherwise, “logical shift” the register right 4 bits. 6. If the result is a value from 0FF8H through 0FFFH, the file has no more clusters. Otherwise, the result is the number of the next cluster in the file.

37

On disks with at least 4087 clusters formatted under MS-DOS version 3.0 or later, the FAT entries use 16 bits, and the extraction of a cluster number from the table is much simpler:

1. Use the directory entry to find the starting cluster of the file in question. 2. Multiply the cluster number by 2. 3. Use the product as the offset into the FAT and move the word at that offset into a register. 4. If the result is a value from 0FFF8H through 0FFFFH, the file has no more clusters. Otherwise, the result is the number of the next cluster in the file.

To convert cluster numbers to logical sectors, subtract 2, multiply the result by the number of sectors per cluster, and add the logical-sector number of the beginning of the data area (this can be calculated from the information in the BPB).

Figure 13. Linking of a file by FAT

The following figure shows the FAT file chain for three files viz. FILE1.TXT, FILE2.TXT and FILE3.TXT. FILE.TXT spans across 3 clusters in the Files Area (Cluster No. 2,3 & 4). Similarly FILE2.TXT spans across 3 clusters (Cluster No. 5, 6 & 8) and FILE3.TXT across 1 cluster (Cluster No. 7) in the Files Area.

38

6.

Implementation of Basic Functions of FAT File System

We assume that we have a disk image (raw hex dump) of a mass storage device in an array (DiskImage). This Disk Image is the copy of the raw data physically present on the Storage device (like a floppy /SD card/ USB flash drive etc.). All the functions manipulate the array DiskImage.

Figure14. Screenshot of the choice menu of our application

We have created a menu allowing the user to perform various actions on the DiskImage array. Corresponding to the user’s choice the appropriate function is called using a switch statement.

Let us assume that our storage device has the following directory structure as shown in the figure. The values in the bracket is the starting cluster number of the directory / file which is present in the 32 bit entry written in the parent directory i.e. the details of our_proj (its name, extension, attribute etc.) are present in the root directory whereas the details of End_sem is present in the sixth cluster of the files area (corresponding to the parent directory).

39

Root Directory

Our_proj (0002)

Learn_Qt .txt (0010)

FAT.txt (0012)

Student_ details.txt (0003)

PS Guide (0004)

Reports (0006)

End_Sem (0008)

Tel_Widget.txt (0018)

Marks.txt (0016)

Mid_sem.txt (0017)

student1.t xt (0013)

Emails.txt (0005)

Proj_review (0007)

student2.txt (0020) (0014)

student3.txt (0015)

FAT.txt (0019)

Now, we maintain an integer array through out our program called path and we also maintain a global variable called current_path. These two together will provide us with the directory in which we are currently in. The following example illustrates how:

Suppose that we are currently in the End_sem directory. So, the current path will contain all the starting numbers of directories in the path till the starting cluster number of End_sem. The current_path integer variable will contain 3. So, by simply calling path[current_path] we get the starting cluster number of the directory we are presently in. Now, when we change directory (jump to the parent directory or one of the child directories), we just renew the current_path and the path variables.

40

root

Root Directory cluster

Our_proj

End_sem

reports

Files_area_start Files_area_start Files_area_start 0 + 0002 + 0006 + 0008

0

1

2

3

path array

0

4

5

current_path x

The current_path is an integer array which keeps track of the starting cluster numbers of all the directories in the present path.

6.1 DIR Function DIR Function displays all the files and subdirectories present in the current directory. By default DIR function displays all root directory entries. It performs a scan operation on the root directory or the starting cluster of the parent directory in the files area and displays its contents. Each entry in the cluster is of 32 bytes. The function checks the starting byte of each entry. If it encounters 0x00 (signifying a null entry) as the starting byte it stops the scan as an entry beginning with a null byte is the logical end-of-directory. If it encounters 0xE5 (signifying an erased entry) it jumps over that entry and scans the next entry. For other entries it displays the filename (first 8 bytes in an entry) and extension (in case of files) and the directory name (in case of subdirectories). If the current_path = 0 (i.e. for root directory) we skip the first entry which is the volume label and perform the scan operation thereafter.

41

Figure15. Screenshot of the output of Dir function. It shows 2 directories red and blue, 1 file README.TXT

This screenshot shows all the files and directories present in the root directory which is the current parent directory. The dot after red and green signifies that they are directories.

6.2 READ File Function The read file function first performs a scan operation similar to the DIR Function and checks whether the user specified file exists or not. If the file does not exist it displays a File Not Found message. If the file exists the read function extracts the starting cluster number of the file and performs a cluster by cluster read operation until it encounters an end-of-file cluster in the FAT file chain of the given file. For interpreting the FAT two convenience functions evaluate_fat_12() & evaluate_fat_16() were created for 12 bit and 16 bit FAT respectively. Below is an illustration showing the output of read file function.

42

Figure16. Screenshot of the output of read file function.

6.3 WRITE File Function This function allows user to write files in the files area. First it separates the first name and extension from the filename provided by user. Then it performs a scan like in the read function on the current directory cluster. If the file already exists it allows user to append text to the existing file. If the file does not exist a new file is created after taking text input from user. The WRITE file function first finds a null entry in the current directory cluster and fills a 32 byte entry as specified in Table 5. Thereafter it starts filling the data provided by the user in Files area. It simultaneously keeps a record of the clusters used and fills the FAT table accordingly. After the data entry is complete it fills the end of file character ((F)FFF) in the last cluster of the FAT file chain. The WRITE File function makes call to two convenience functions - find_empty_cluster() for finding a new empty cluster, refresh_fat() and for updating the FAT file chain and fill_data() for writing the text provided by the user into the empty cluster .

43

Figure17. Screenshot of the output of write file function.

Here the user has created a file blue.txt with some text. User has to specify the end of his text with a ‘#’ character. We have used this character for end-of-file notification.

Figure18. Screenshot of the output of write file function using edit file option.

6.4 RENAME File Function RENAME File Function asks the user for the filename to be renamed. It then performs a simple scan on the current parent cluster and checks for the user specified file name. If found it asks for the new file name and changes the corresponding 32 bit entry. If the file name is not found it displays an appropriate message.

44

Figure19. Screenshot of the output of rename file function.

6.5 DELETE File Function DELETE File Function takes a filename as input from the user and deletes it. It first performs a scan like the previous functions and displays an appropriate message if the file is not found. If the file is found it performs three tasks1) Changes the first byte of the 32 byte entry to 0xE5 to mark the file as erased and also changes the other 31 entries to null character (See TABLE 4). 2) Frees the data clusters by overwriting it with null character. It uses a convenience function zero_cluster() for accomplishing this task. 3) It frees all the clusters in the FAT file chain, by marking them with 0x00-indicating empty cluster (See TABLE 3).

Figure20. Screenshot of the output of delete file function

45

6.6 MAKE DIR Function MAKE DIR Function is very similar to WRITE File function. It first scans the parent directory cluster for a null entry and then fills in the 32 byte data corresponding to the new directory. Directory name is taken as input from the user. The difference between a file and a directory is as follows1) The fifth bit of the attribute byte in a directory entry is set signifying that it is a directory (See TABLE 6). 2) The file size of a directory is 0 indicating that it contains no data. 3) A Directory does not have a extension. The extension bytes are null in a directory.

Figure21. Screenshot of the output of make directory function followed by call to dir function.

46

6.7 CHANGE DIR Function The change dir function allows the user to change the parent directory. It is very similar to the command prompt in MS DOS. The CHANGE Dir Function first performs a scan operation like the previous functions and if the user specified sub-directory is found it changes the path[] array and the current_path index, so that they now point to the sub directory. Like in MS DOS user can use . for specifying the current directory and .. for pointing to the parent directory of the current directory. An appropriate message is displayed if the user specified directory is not found.

Figure22. Screenshot of the output of change directory function followed by call to dir function.

6.8 RENAME DIR Function This function has the same implementation as the RENAME File Function.

47

Figure23. Screenshot of the output of rename directory function.

6.9 DELETE DIR Function This function also has the same implementation as the DELETE File Function.

Figure24. Screenshot of the output of delete directory function.

48

7.

Future Aspects

There are several improvements and additions that can be made to our project, which we were not able to accomplish due to lack of time. They are as follows: •

Currently the options are menu based. It will be much more user friendly if it is command based.

•

The user can write and append files but cannot edit them.

•

Presently, the write function takes input from users and stores it in text format. An extension can be made to write binary files.

•

Efficiency measurements and rigorous testing needs to be done before it can be actually used in embedded systems.

49

8.

Conclusion

We started our practice school 1 on 22nd May, 2008. Right from day 1, we have not only learned many tangible technical things but also gained invaluable intangible experiences which cannot be taught in a classroom.

We started off with refreshing and learning concepts of Object Oriented Programming in C++ which was essential for the understanding of Qt4, which is entirely made in C++. Learning Qt4, though an uphill task, was an exciting one too. We tried out various widgets during our learning process, a notepad widget (named BITSPad), a screenshot capturing widget and an icon editor widget to name a few. Widget building process was full of hurdles and revelations. We learned the importance of small things like taking regular back-ups, commenting the code, and organizing the files systematically. The FAT implementation system gave us insights of the basic organization of a storage disk and an experience of working at the lowest levels. While writing the code for FAT we realized the importance top down approach.

Getting stuck with a particular problem was very frustrating but getting over it was all the more satisfying. We worked brilliantly as a team, one egging forward the other that kept the project moving forward. Though due to lack of time, we may have been unsuccessful in perfecting a few things, but on the whole it was a great learning experience.

50

9.

APPENDIX Class Hierarchy of Qt4

51

52

10. 1. 2. 3. 4. 5. 6. 7.

BIBLIOGRAPHY C++ GUI Programming with Qt4 – Jasmin Blanchette & Mark Summerfield. Foundations of Qt Development – Johan Thelin Object Oriented Programming using C++ - E.Balagurusamy Qt Reference Documentation (Desktop Edition) by Trolltech Qt Online Forum – www.qtcentre.org/forum Qt Online Forum – www.qtforum.com Advanced MS DOS Programming – Ray Duncan

53