Assembly Year Final Project

Project Title: Boot Time terminal ( A Simple OS )

LecturerMs. Ismat Rahman

University of DhakaDept. of Computer Science & Engr.

Submitted To:

Roll No - 05Sayeed Mahmud

Exam Roll - 1716Batch - 15

Submitted By:

The Idea Behind “Boot Time Terminal” is somewhat simple

We boot from a USB pen drive where a primitive UNIX-like shell or a DOS-like Command Prompt will appear.

The users will enter commands and get result based on the commands they entered

11/13/14 2

So What’s the Big Idea ??

We also provide the user the flexibility to execute any raw-binary file, hence increasing the capability of the terminal.

We also provide a set of interrupts for the ease of programming.

We use existing FAT16 file system so that user can just copy and paste their programs in their pen-drive and also they can see their saved text files in other OS.

11/13/14 3

So What’s the Big Idea ?? cont…

11/13/14 4

So What’s the Big Idea ?? cont..

Using an existing file system allows keeping other user files along with the terminal files so the pen-drive don’t become unusable while our program resides in it.

We will allow programmers to write extension programs for our terminal.

11/13/14 5

So What has it become ??

Although we call it “Boot Time” terminal,

judging by the ideas we have, it actually has become somewhat like an Operating System.

As we don’t plan to switch it to protected mode, it remains a real mode OS.

So how we implement ??

After a x86 machine completes its POST (Power On System Test) code resided in ROM BIOS area searches for a bootable media according to the priority set in BIOS.

If it finds one, it looks for a boot partition in it. Through MBR the partition table is found and starting point of the

partitions are obtained. If the 0th sector of a partition contains the boot signature

(0xAA55) in the last 2 bytes it’s a bootable partition If it has found a boot partition, it takes the code from the

first sector.

The code is placed in the address 0x0000:7C00 in main memory (RAM)

The control is then transferred to the just loaded code in main memory

So a program written in raw binary can be executed before any OS has been loaded, and our idea can certainly work.

11/13/14 7

So how we implement ?? cont..

By writing proper code in the first sector (actually 0th).

Placing the boot signature in the last 2 bytes.

We are using an existing file system to keep compatibility with other OS, so we need a BPB (Boot Parameter Block).

11/13/14 8

And how we make a pen-drive bootable ??

BPB is a 59 Byte table consisting of various parameters related to file system like Bytes Per Sector, Sectors Per Cluster etc.

So with proper BPB for disk and code for locating kernel we assemble an asm file, in binary format.

We write the fie in the first sector with our BootSectorWrite program (self created source included).

11/13/14 9

And how we make a pen-drive bootable ?? cont..

So far we have made a pen drive bootable, but it hasn’t got much space left to do something big.

The boot loader file has a mandatory 2 byte jump code, 1 byte NOP, 59 Byte BPB and 2 Byte boot signature

So we have got only 512-(2+1+59+2) = 448 Bytes of useable space left for us.

448 Bytes of code can hardly do something big, so we have a problem.

11/13/14 10

Some obstacles here…

Luckily there is a solution, we can assemble another binary file (it can be as big as main memory) and copy paste it on the disk.

We can use the rest 448 Bytes of code to locate the file in the

disk, and load it in the memory (segment 0x5000). After the kernel is loaded we can perform a far jump and

transfer control to it, from then on we don’t have to worry about space.

Warning: Code for traversing a file system and reading disk can be lengthy, so we have to optimize as much as we can.

11/13/14 11

A Solution …

11/13/14 12

We are in Kernel…..

Now that we are in kernel, we can mind our own business.

We prompt for a command from user. After the user has given a command, we parse it

and separate the commands and parameters. Then we compare the commands with a set of

given command strings, to find a match. If a match is found then, we see the number of params and

params themselves are in the way they are supposed to be.

If the command format is OK then we perform the requested task.

If it is not OK (i.e. didn’t match with any of the built-in command strings) we give an error message.

With these, everything seems to be OK. But is it ?? There is a problem…..

11/13/14 13

We are in Kernel….. cont..

As we are searching for matching commands in our list of command strings that is built-in (or hard coded to be exact).

So our OS has limited capability. Each time we need to add an extra function we

have to re-compile the kernel. The command strings may take huge amount of

space. Clearly bad design policy….

11/13/14 14

The Problem

Why don’t we look at real examples ?? Linux Terminal executes executables directly from

/bin/ directory (like cat, vi these are actually executables)

Windows command prompt does the same, executes executables directly from c:\windows\system32\ directory

So why don’t we have our own directory, where we’ll be able to add binary files just by copy pasting ?? This way we will be able to add more features in future.

11/13/14 15

The Solution

When our command line evaluator won’t find a match from the list of command strings, it will look for a matching name in the BIN directory.

But every time we enter an executable’s name, we have to search the entire directory, which means more disk I/O and a directory contains more contents than just file name and entries.

So another problem… Its slow, but wait we can fetch in the entry in the main memory of that particular directory where we store all our extensions.

11/13/14 16

The Solution… cont…

That’s what we exactly do, we read the total BIN directory during initialization.

Then we store a 10 Byte entry (8 Byte file name and 2 Byte starting cluster) for each file in segment 0x2000

So when we don’t find a match in our hard coded command string table, we look for a match in segment 0x2000. If still not found, we give error message

So we have pretty much optimized things a bit. The only thing now left is how we execute the binary ??

11/13/14 17

The Solution… cont…

We loaded our kernel in segment 0x5000 We load our program in segment 0x6000 Handling control to a program in different segment is

simple in NASM. We perform a CALL 0x6000:0000 which means segment

offset pair after call instruction. Now when we transfer control back to OS we have to

perform RETF which stands for Return Far as it is inter-segment operation.

11/13/14 18

How we execute ??

So far we have been talking about the upper layer of our development process.

But we are booting from a USB drive and for DISK I/O we need to understand the file system properly.

The layout of a FAT16 drive is like this:

11/13/14 19

A touch of FAT16

FAT is actually a linked list. Each entry in FAT16 is 2 Byte in size and corresponds to a

cluster (i.e. FAT entry no 10 corresponds to cluster 10) Each entry in FAT contains the next cluster number in chain

(i.e. a file occupies 9, 12, 17th cluster. The FAT entry 9 will contain 12, 12 will contain 17 and 17 will contain 0xFFFF which means End of File)

The first 2 entries in FAT are reserved, so Data Clusters start from no. 2

There is an extra FAT table in case the First one gets corrupted.

11/13/14 20

FAT16 cont…

After the FATs comes the Root Directory, (size of which can be get from BPB) which contains entry for a file or folder in the root of a drive

Each Directory Entry is actually of 32 Byte and also says what is it’s contents’ starting cluster.

Obtaining that cluster we can read clusters ( a bunch of sectors ) from Data Area and get the files contents.

The contents of a folder data area are also Directory entries which in turn points to their contents starting cluster.

11/13/14 21

FAT16 cont…

11/13/14 22

Some formulas regarding FAT16

1. No of Root Sectors = No of Root Entries * 32 / Bytes Per Sector[No of Root Entries and Bytes per sector is in BPB]2. No of Fat Sectors = No of FATs * Sectors Per FAT[No of FATs and Sectors per FAT is in BPB]3. Root Directory Start = 1 + No of FAT Sectors[1 is for the boot sector]4. Data Area Start = Root Directory Start + No of Root Sectors[We found Both in earlier calculation]5. First Sector for a Cluster = Data Area Start + (Cluster No – 2) * Sectors Per Cluster[Cluster number is obtained from the directory entry]6. Nth entry of FAT = FAT Area Start + 2 * N[Fat start is simply 1, only boot sector lies before it]

DATE – shows date TIME – shows time VER – shows kernel version string CLS – clears the terminal CAT – shows the contents of a text file cat <file.txt> EDIT – creates a text file edit <file.txt> DEL – deletes a file del <file> DIR – shows contents of root directory LIST – shows all binary extensions HELP – helps the user by showing some text REBOOT – reboots the PC

11/13/14 23

Our Built-in Commands

An OS must have minimal set of Interrupts. We have 10 interrupt services (AH = 0x01 to 0x0A). To keep familiarity our interrupt is also numbered 0x21. We set up the IVT during initializations. The interrupt services do various things like Printing and

Input Integers directly.

11/13/14 24

Interrupts

We allow to enhance our OS by writing program in assembly and copy pasting it directly to BIN directly.

The format of the programs are BIN(raw binary image) We choose bin over windows exe and linux elf because:

exe contain PE headers, DOS MZ Header, IMAGE NT Header. ELF file contain ELF header. Both of them contain many section tables. Both of them may contain relocatable code, which is too much for us to

handle now. Any BIN file can be executed as long as they only use BIOS interrupts

and our own interrupts and begin with INT 0x21 AH = 0x01.

11/13/14 25

Writing Programs

For clearity any program for our os may follow the following format:

11/13/14 26

Writing Programs cont..

; This is the template for assembly programmers programming for ; Dumb OS; use only BIOS and Dubm OS interrupts[BITS 16]ProgramMain_:

; INITMOV AH, 0x01INT 0x21;;CODES;RETF ; return control to OS

OtherProcedures_:; CODESRET

OtherProcedures2_: ; CODES RET; ********* DATA NEEDED FOR PROGRAMS **************VAR DB 0

CPU – this is a CPU identification program EQUIP – performs basic IBM equipment check RAM – Shows free amount of RAM, the speciality of this is from

within real mode (which can’t address more than 1 MB) it can identify free spaces up to 4 GB.

SCRSAVER – this just shows dotted pixels on screen on VGA mode in an infinite loop, but the specialty is we show a shred of multitasking from within real mode, press any key, the program terminates

CLOCK – shows time continuously, also shows some multi-tasking SOUND – demonstrates how to generate beep using 8253 PIC and

memory mapped I/O.

11/13/14 27

Already Added Features

We didn’t switch to protected mode Can’t do pure multi-tasking Lots of redundant code, could have done it more efficiently Lack of features The DIR command sometimes print an extra new line. Edit command creates a file name even if same named file

exists (we intentionally made it this way) There might be undiscovered bugs

11/13/14 28

Drawbacks and Bugs

Add FAT32 and NTFS support Include a HDD driver Include an assembler Include data recovery program Add ethernet driver Add hex editor for debuggung purpose With these features included it could be the ultimate

hacking or debugging tool. For instance we could replace passwords of any other OS booting from USB if proper program is written.

11/13/14 29

Future scope of improvements

Thank You !!!!!