diff --git a/OS Project/Original Assignment.doc b/OS Project/Original Assignment.doc
deleted file mode 100644
index e86b3bb..0000000
Binary files a/OS Project/Original Assignment.doc and /dev/null differ
diff --git a/OS Project/Readme First.docx b/OS Project/Readme First.docx
new file mode 100644
index 0000000..6c864d7
Binary files /dev/null and b/OS Project/Readme First.docx differ
diff --git a/OS Project/app.config b/OS Project/app.config
index c4f2d93..36cb1b1 100644
--- a/OS Project/app.config	
+++ b/OS Project/app.config	
@@ -49,7 +49,7 @@
 		
 <!--
 
-		The Code Segement is the size of the code, rounded up to a page boundary
+		The Code Segment is the size of the code, rounded up to a page boundary
 		The Heap is the remainder of memory after the Data Segment, and before the Stack
 
 		It's important that the	values for datasize, stacksize and physical memory 
diff --git a/originalassignment.md b/originalassignment.md
new file mode 100644
index 0000000..b5a64be
--- /dev/null
+++ b/originalassignment.md
@@ -0,0 +1,299 @@
+# CST 352 Operating systems final project spec
+
+The goal of this project is to write a virtual operating system for an abstract machine to provide the following services. The details of the abstract machine will be provided below.
+
+- Load and unload programs.
+- Allocate and deallocate virtual memory.
+- Provide I/O services.
+  - These will just be standard I/o input.
+- Provide services for scheduling processes.
+  - Based on priority.
+  - Based on time cycles expiring.
+  - Based on resources.
+- Provide services for mutual exclusion and synchronization.
+  - Semaphores.
+  - Locks( mutexes ).
+  - Events.
+
+## Changes made on 4/8/2002
+
+The following features are mandatory. Mandatory implies these features must be implemented and fully functional. If some or all of the features are not working as specified, the grade is left to the instructor&#39;s subjective decisions. This feature set is called the BASE FEATURE SET in this document.
+
+- Process scheduling based on priority.
+  - Process scheduling based on time quantum expiration is optional.
+  - This implies that the current running process continues to run until it exits or tries to acquire a resource that is currently held by another process.
+  - The functionality for Sleep is mandatory.
+- Provide output services. (Print. This is used to verify the functionality of the program ).
+- Provide mutual exclusion facilities. Minimally locks must be implemented.
+- An idle process is required. This process continues to run until time elapses for another process to wake up.
+- On a process exit.
+  - All the memory that still belongs to the process MUST be clean deallocated and MUST be made available for other processes.
+  - All internal OS structures used for the process(PCB..) must be released as well.
+  - If the process holds locks when it exits, the lock MUST be marked as not acquired.
+    - This implies any process waiting for this lock MUST now be made eligible to run.
+- These  features, if implemented completely, account for 65% of the total grade for the class.
+
+## Changes made on 05/06/2002
+
+The following features may be implemented, in addition to the above, for an additional 35% grade. This implies that if the above mandatory features and these features are implemented completely and verified to be functionally complete, the student SHALL receive the full grade of 100% for the class. The mandatory features are the minimum set of features needed. Students are strongly advised to get their mandatory features working before even venturing into these features. Students MUST clearly indicate at the time of submission what features they implemented. This feature set is KNOWN AS THE EXTENDED FEATURE SET in this document.
+
+- Implement dynamic memory allocation features.
+  - Alloc and FreeMemory MUST be implemented.
+- Implement virtual memory using dynamic paging.
+  - Each process&#39;s memory is now classified as virtual memory.
+  - Each process has its own set of page tables that map its virtual memory to physical memory.
+  - A process may incur page faults when it tries to access memory it currently does not own or does not have in memory.
+  - Page size for the page tables can be set to 4 bytes or taken as an input to the OS command line arguments.
+  - Normal data files may be used to store the unused state of a process.
+  - Each process may have its own file for paging or may share a file.
+  - OS code must service page faults and handle them properly.
+  - Page tables can either grow in size or be restricted to a fixed size.
+    - The former is preferable although both will be considered as good.
+
+The following are the list of opcodes that are minimally needed for the above features. The instructor SHALL use only these opcodes in his sample programs in order to test students&#39; projects. It is left up to the students to choose additional opcodes to implement if they find them interesting.
+
+## Opcodes
+
+| Opcode | BASE FEATURE SET | EXTENDED FEATURE SET |
+| --- | --- | --- |
+| Incr | x | x |
+| Addi | x | x |
+| movmr | x | x |
+| movmm | x | x |
+| movrm | x | x |
+| printr | x | x |
+| printm | x | x |
+| AcquireLock | x | x |
+| ReleaseLock | x | x |
+| Alloc |   | x |
+| FreeMemory |   | x |
+| Sleep | x | x |
+| MemoryClear |   | x |
+| Exit | x | x |
+| movi | x | x |
+| movr | x | x |
+
+The project will implement a virtual operating system. The term virtual in this context implies an operating system that will run on top of a standard platform.
+
+- Either a standard PC with Windows or Linux platform is sufficient.
+- Any standard C/C++/Java compiler may be used to implement the operating system.
+- Since there is no real hardware here, the operating system provides the above services + executes the programs themselves.
+- In this sense, the operating system is both the system and the hardware , all in one. It interprets the programs by itself( similar to the Java virtual machine).
+
+## Definition of the abstract machine.
+
+The machine used for this project will be an abstract one. Abstract implies there is no real hardware (CPU+ chipset + hardwired logic) needed to implement this. Instead, it will be emulated in software. The machine has the following details. The abstract machine is a 32-bit machine which implies all addresses are 32-bits and registers are 32-bits as well.
+
+- It has 10 general purpose registers.
+  - Each register is 32-bits wide and can store any information.
+  - They are addressed as 1 through 10 in the opcodes for this machine.
+  - Register 10 is also the stack pointer register.
+    - Always contains the top of the stack.
+    - Grows towards lower addresses.
+    - Pushing decrements stack pointer. Popping increments it.
+    - Only 32-bit quantities may be pushed or popped.
+    - Only the full-registers may be addressed.
+      - This is unlike x86 where a 32-bit register may be addressed by its full 32-bit , 16-bit or 8-bit portions.
+- The abstract machine has 2 bit flag registers.
+  - SF is the sign flag. This is set when any comparison of 2 quantities results in a sign extension.
+  - ZF is the sign flag. This is set when any comparison of 2 quantities results in a zero( both quantities are equal ).
+- The instruction pointer register is special and is 32-bits wide.
+  - Not accessible to the programmer.
+  - Modified when the program executes.
+  - Must be saved by the operating system on function calls and context switches.
+  - Also known as eip in this document.
+- The abstract machine has the following opcodes. Since the intent of this project is to teach Operating system design and implementation, the machine is not complete in the sense that it does not provide a full repertoire of instructions (similar to x86 or other architectures). Each opcode is exactly 1 byte long and is of the following format.
+  - &lt;opcode&gt; &lt;argument 1&gt; &lt;argument 2&gt; ..
+  - All instructions are multiples of bytes.
+  - All instructions take exactly one clock cycle to execute, independent of the actual operation of the instruction.
+  - Context-switches only happen on instruction boundaries.
+  - Constants are indicated by the operator $ in front of them.
+  - Registers are indicated by r1 … r10.
+  - The stack pointer (register 10) has another name for it which is sp.
+
+| Opcode | Value(decimal) | Format |
+| --- | --- | --- |
+| Incr | 1 | incr r1(increment value of register 1 by 1 ). |
+| Addi | 2 | addi  r1,$1 is the same as incr r1 |
+| addr | 3 | Addr r1, r2( r1 &lt;= r1 + r2 ). |
+| Pushr | 4 | Pushr rx (pushes contents of register x onto stack. Decrements sp by 4 ). |
+| Pushi | 5 | Pushi $x . pushes the constant x onto stack. Sp is decremented by 4 after push. |
+| Movi | 6 | Movi rx, $y. rx &lt;= y |
+| Movr | 7 | Movr rx, ry ; rx &lt;= ry |
+| Movmr | 8 | Movmr rx, ry ; rx &lt;= [ry] |
+| Movrm | 9 | Movrm rx,ry; [rx] &lt;= ry |
+| Movmm | 10 | Movmm rx, ry [rx] &lt;= [ry] |
+| Printr | 11 | Printr r1 ; displays contents of register 1 |
+| Printm | 12 | Printm r1; displays contents of memory whose address is in register 1. |
+| Jmp | 13 | Jmp r1; control transfers to the instruction whose address is r1 bytes relative to the current instruction. R1 may be negative. |
+| Cmpi | 14 | Cmpi rx, $y;  subtract y from register rx. If rx &lt; y, set sign flag. If rx &gt; y, clear sign flag. If rx == y , set zero flag. |
+| Cmpr | 15 | The same as cmpi except now both operands are registers. |
+| Jlt | 16 | Jlt rx; if the sign flag is set, jump to the instruction whose offset is rx bytes from the current instruction. |
+| Jgt | 17 | Jgt rx; if the sign flag is clear, jump to the instruction whose offset is rx bytes from the current instruction |
+| Je | 18 | Je rx; if the zero flag is clear, jump to the instruction whose offset is rx bytes from the current instruction. |
+| Call | 19 | Call r1; call the procedure at offset r1 bytes from the current instruction. The address of the next instruction to execute after a return is pushed on the stack. |
+| Callm | 20 | Callm r1; call the procedure at offset [r1] bytes from the current instruction. The address of the next instruction to execute after a return is pushed on the stack. |
+| Ret | 21 | Pop the return address from the stack and transfer control to this instruction. |
+| Alloc | 22 | Alloc r1, r2; allocate memory of size equal to r1 bytes and return the address of the new memory in r2. If failed, r2 is cleared to 0. |
+| AcquireLock | 23 | AcquireLock r1; Acquire the operating system lock whose # is provided in the register r1. If the lock is invalid, the instruction is a no-op. |
+| ReleaseLock | 24 | Releaselock r1; release the operating system lock whose # is provided in the register r1; if the lock is not held by the current process, the instruction is a no-op. |
+| Sleep | 25 | Sleep r1; Sleep the # of clock cycles as indicated in r1. Another process or the idle process must be scheduled at this point. If the time to sleep is 0, the process sleeps infinitely. |
+| SetPriority | 26 | SetPriority r1; Set the priority of the current process to the value in register r1; See priorities discussion in Operating system design |
+| Exit | 27 | Exit. This opcode is executed by a process to exit and be unloaded. Another process or the idle process must now be scheduled. |
+| FreeMemory | 28 | FreeMemory r1; Free the memory allocated whose address is in r1. |
+| MapSharedMem | 29 | MapSharedMem r1, r2; Map the shared memory region identified by r1 and return the start address in r2. |
+| SignalEvent | 30 | SignalEvent r1; Signal the event indicated by the value in register r1. |
+| WaitEvent | 31 | WaitEvent r1; Wait for the event in register r1 to be triggered. This results in context-switches happening. |
+| Input | 32 | Input r1; read the next 32-bit value into register r1. |
+| MemoryClear | 33 | MemoryClear r1, r2; set the bytes starting at address r1 of length r2 bytes to zero. |
+| TerminateProcess | 34 | TerminateProcess r1; terminate the process whose id is in the register r1. |
+| Popr | 35 | pop the contents at the top of the stack into register rx which is the operand. Stack pointer is decremented by 4. |
+| popm | 36 | pop the contents at the top of the stack into the memory operand whose address is in the register which is the operand. Stack pointer is decremented by 4. |
+
+## Operating system design goals
+
+The operating system designed in this project must provide the following services to programs written for this operating system.
+
+- Provide virtual memory services.
+  - All processes will have page tables allocated by the operating system.
+  - OS will detect invalid memory accesses and terminate the processes.
+    - Terminating processes means the operating system will display an error message on the console and choose the next process to execute.
+  - Processes can allocate any amount of memory subject to the resources available.
+  - Processes only manipulate virtual addresses.
+- Provide inter-process synchronization mechanisms.
+  - OS provides mutexes for a process to lock out other processes while manipulating critical shared structures.
+  - For this project, the OS comes with (or is preconfigured with) 10 locks, each identified by the numbers 1 through 10.
+  - The OS does not provide any services for processes to allocate their own critical sections.
+  - The instructions AcquireLock and ReleaseLock allow a process to acquire and release the OS provided locks.
+  - The locks provided by the OS are meant for use by application processes to protect themselves while manipulating shared-critical structures.
+- Provide scheduling services.
+  - Each process is scheduled independently.
+  - Processes are single-threaded.
+  - Only one process is running at a time.
+  - A process once scheduled(means it starts running) continues to run until the following happens.
+    - It exits( by executing opcode Exit ).
+    - It sleeps for some time( by executing opcode Sleep ).
+    - It acquires a lock already acquired by someone else.
+    - It accesses an address which requires a page fault and there is not enough memory available. Once another process frees up some memory, this process is scheduled again.
+    - Waits on an event to be signaled by another process.
+    - Its time quantum runs out.
+      - Each process has a time quantum. A time quantum is the # of clock cycles it is allowed to run before it is scheduled out.
+- Provide memory-mapping services.
+  - This OS provides built-in or preconfigured shared memory regions of size 10000 bytes each for a total of 10 memory regions, each indexed by the number 1 thru 10 respectively.
+  - Processes may map any of them into their address spaces by using the opcode MapSharedMem and passing the # of the shared memory region.
+  - Processes may use this facility to share memory and perform inter-process communication.
+- Provide I/O services.
+  - Processes may use these I/O services to print out values to the console.
+  - Processes may use input services to read values from the console as well.
+
+## Project requirements
+
+Where the word MUST is used, the features are required in order for the student to receive full grade for the project. The word OS is used to describe the implementation of this operating system. Where the word MAY is used, the feature is optional.
+
+- Students MAY use C/C++ or Java to write the operating system.
+  - If C/C++, students MUST use Visual C++ 5.0 or 6.0.
+  - If Java, the code must be compilable using Sun&#39;s JDK 2.0 or greater.
+- The OS must be compilable without any errors.
+  - Any errors in compilation results in 0 grade.
+  - The students are responsible for providing any readme or any other documentation to the instruction in order to evaluate the project.
+  - The program must be compilable on windows platforms.
+  - Warnings MUST be minimized.
+  - If the operating system code crashes, the grade provided is based on the instructor&#39;s subjective decisions.
+  - The instructor will evaluate the project using sample files that he will provide later in the class.
+- The team ( of 2 students ) is graded as a whole for the project.
+  - Any differences between the team members( if any ) must be resolved by the members themselves.
+  - It is strongly advised that students team up for this project.
+
+## Project features
+
+- The OS must contain an interpreter that understands the above opcodes.
+- The OS must be invoked as follows.
+  - OS &lt;# of bytes&gt; &lt;program1.txt&gt; &lt;program2.txt&gt; …..
+  - Each programx.txt contains the code for the programs to be loaded and executed.
+  - The number of bytes for all programs that can be loaded(including code, data, heap and stack) must be provided in the first parameter.
+  - This # does not include the # of bytes the OS will itself need to keep track of information about each process such as process blocks.
+- The OS will provide the following services.
+  - Loader to load programs of the above type.
+    - The students may assume that the instructor will provide programs with correct opcodes.
+      - This is the not the same as rogue programs.
+  - Scheduler for scheduling programs.
+    - Maintain process context(using process context blocks or otherwise ).
+    - The time quantum a process is limited to running before it is scheduled out is 10 clock cycles.
+    - All process context (including all registers, page tables) MUST be stored in the process context block.
+    - An idle process must be provided that runs if no other process is eligible to run.
+      - The idle process will be provided in a separate file called idle.txt.
+      - The idle process just sits in a tight loop printing out the value 20.
+      - The idle process only has a quantum of 5 clock cycles.
+      - The idle process never exits.
+      - The scheduler always schedules the highest-priority process eligible to run.
+      - There are 32-priorities in the OS.
+      - Processes with higher priorities run until they give up control, exit or are terminated.
+      - The bigger the priority #, the higher the priority for the process.
+      - A process may adjust its own priority by invoking the opcode SetPriority.
+      - In addition to these queues, the scheduler MUST implement queues for blocking &amp; other types of processes.
+- Virtual memory manager.
+  - Each process MUST only access virtual addresses.
+  - When a process is loaded, the memory manager MUST construct its page tables in the appropriate fashion.
+    - Every memory access by each process goes through page tables and accesses the real memory.
+    - This is true for all addresses(code, data, stack and heap).
+    - The details of breaking down a virtual address to a physical address using page tables will be provided in the class.
+    - If a process accesses an address it does not own, the OS must print an error message with the values of the registers of the process at the time the problem occurred, terminate the process and schedule another one.
+  - Processes sharing memory.
+    - A process may map the OS provided shared memory region into its own address space using the MapSharedMem opcode.
+    - This allows 2 or more processes to share memory.
+    - The exact usage of these memory regions is left to the processes themselves.
+  - Process virtual memory.
+    - A process&#39;s memory map is divided into 4 regions.
+      - Code. This is the region containing the instructions with some combination of the above opcodes.
+      - Stack. This is the region where the program may store temporary variables. When a function is called, the interpreter stores the return address here as well.
+        - When a program is loaded, it is provided a stack of 4k bytes.
+        - The stack grows and shrinks depending on usage.
+      - Global data.
+        - When a program is loaded, it is provided a memory region called global data of size 4k bytes. The contents are initialized to 0. Please see &quot;process initial state&quot; for more information.
+      - Heap.
+        - Heap is the portion of the address space that the process can allocate dynamically using the Alloc and FreeMemory opcodes.
+  - Process initial state.
+    - A program becomes a process when it is loaded by the operating system.
+    - When a process is created, its registers have the following state.
+      - It is the responsibility of the operating system to set it up this way.
+      - R1 – r7 are undefined.
+      - Register r8 contains the id of the process.
+      - R9 contains the virtual address of the global data region( of length 4k bytes ).
+      - R10 (sp) is set to the top of the stack.
+        - Growing the stack implies it grows towards lower addresses.
+      -  The instruction pointer(eip) contains the value 0 essentially translating(via page tables) to the first instruction in the program to be executed.
+  - Process exiting.
+    - A process may exit due to any of the following reasons.
+      - It invokes the Exit opcode.
+      - It performs an illegal operation(it access a memory location it does not own).
+      - Another process kills this process using the TerminateProcess opcode.
+        - It is left to the individual processes to find the id of the other processes.
+        - Admittedly, the security is very weak(allowing any process to terminate any other process).
+    - When a process exits for whatever reason, your OS must perform the following.
+      - Display the # of page faults, the # of context switches it went through, the # of clock cycles it consumed.
+  - Process synchronization.
+    - The OS provides 10 mutexes or locks.
+    - The locks are numbered through 1 to 10.
+    - A process acquires the lock using AcquireLock.
+      - If another process already owns the lock, the current process is put to sleep on the wait queue.
+      - If a process X tries to acquire the same lock Y two or more times, it is a no-operation. In short, the process MUST not deadlock against itself.
+    - A processes releases a lock it is currently holding via ReleaseLock.
+      - This MUST make only one process(the highest priority process currently waiting) eligible to be scheduled.
+      - This implies that other processes also blocking for this lock will not be scheduled. Only the highest priority process will be scheduled(if any).
+      - The process releasing the lock might be scheduled out because the process now eligible to run may have a higher priority than the one releasing the lock.
+    - The OS must take into account priority inversion.
+      - It is possible that a higher-priority process is blocked for a resource that is currently owned by a lower-priority process.
+      - In this case, the OS must bump up the priority of the lower priority process to that of the blocked process and keep it this way until the lower-priority process releases the resources.
+    - If a process holding a lock exits or is terminated for whatever reason,
+      - The lock MUST be considered not held and another process waiting(if any) should be made eligible for scheduling.
+  - Events.
+    - Events, unlike locks, are provided for process synchronization.
+    - They allow one process to notify another process the occurrence of an event.
+      - The OS provides built-in events for a total of 10. They are numbered 1 to 10.
+      - Any event is in one of 2 states.
+        - Signaled. This implies any process waiting on it is eligible to run now.
+          - An event is set to signaled when a process invokes the SignalEvent opcode.
+        - Non-signaled.
+          - This is the initial state of all events when the OS boots up(so to speak).
+          - When a process that is waiting on it becomes eligible to run, the event becomes non-signaled allowing another process to wait on it.
+          - There is no concept of ownership of an event.
diff --git a/readme.md b/readme.md
new file mode 100644
index 0000000..495696b
--- /dev/null
+++ b/readme.md
@@ -0,0 +1,177 @@
+# Scott Hanselman's
+Tiny Virtual Operating System and Abstract Machine in C#
+
+## What is this?
+
+This was the final project for my CST352-Operating Systems class at [OIT](http://www.oit.edu) (Oregon Institute of Technology).  The requirements, exactly as they were given to me by the teacher, are in [originalassignment.md](originalassignment.md).  The goal of this project was to write a small _virtual_ operating system for an _abstract_ machine that provides a number of basic OS-like services like:
+
+- Virtual Memory, Demand Paging
+- Input/Output
+- Memory Protection, Shared Memory
+- Registers, Stack, Data, Heap, etc
+- Jump instructions for calling "Functions"
+- And so on…
+
+This is a cute, fun, interesting and _completely useless thing_.  So, don't get your hopes up that you'll get actual work done with it.  ­
+
+It's neat however, as it is a study on how I solved a particular problem (this assignment) given a 10 week semester.  I was the only student to use C#, and I finished it in 4 weeks, leaving 6 weeks to chill and watch the other students using Java and C++ do their thing.
+
+It's also ironic because I used a high-level OO language like C# to deal with a minute concept like an "Operating System" the might have 256 bytes (bytes, not Kbytes) of memory.
+
+During this process I exercised a good and interesting chunk of the C# language and the .NET Framework.  There are some very silly things like the OS's implementation of virtual memory swapping out memory pages as XML.  I might take an array of 4 bytes and make an XML file to help them.  I hope the irony isn't lost on you. I also commented all the C# with XML and built an [ndoc](http://ndoc.sf.net) MSDN style help file.  So, you might just use this as a learning tool and a pile of sample code.
+
+One Note: I'm an ok programmer, but understand that I whipped this out in several 3am coding sessions, as well as during lectures in class.  This is NOT fabulous code, and should be looked upon as interesting, not gospel.  I'm sure I've done some very clever things in it, and for each clever thing, there's _n_ stupid things.  I'll leave the repair of these stupid things as an exercise to the reader.
+
+Of course, you'll need the .NET Framework to run this, but to really have fun debugging it and stepping through the code you'll need VS.NET.  Go read the code and final\_project.doc and enjoy!
+
+Scott Hanselman
+
+[scott@hanselman.com](mailto:scott@hanselman.com)
+
+May 2002
+
+## What's the jist?
+
+I started out with some basic OO constructs, a static CPU object, an OS object, objects for Processes, Instructions, etc.  A lot of this information is in the Help (CHM) File.  Basically it's setup like this:
+
+- *CPU Object* – responsible for physical memory (which may be smaller than addressable memory) holding CPU registers and fetching program opcodes and translating them into SystemCalls in the OS, etc.
+- *OS Object* – Most of the work is here.  It has a MemoryManager object who is responsible for the translations between Addressable (Virtual) memory, Process memory and Physical Memory.  All Processes access memory from _their_ point of view…they never talk to "physical memory" (Which is just an array of bytes in the CPU object)
+The scheduler is in the OS object as well as locks, events, and all that good stuff.  Each of the 36 opcodes are implemented here and treated as C# delegates…well, now I'm telling you all the good stuff…read the code!
+- *Program Object* - represents a collection of instructions.  Responsible for parsing the files off disk and holding them.
+- *Process Object* – different than Program as it's an actual running process in the TinyOS.  There can be more than one instance of a Process for each Program. (You can run the same program twice, etc) It has a ProcessControlBlock containing Process specific registers, etc.
+- *EntryPoint Class* – Contains main() and "bootstraps" the whole thing.
+
+The OS is made up, the CPU is made up, the opCodes are made up.  This is an exercise to learn about Operating System concepts, and it's not meant to look or act like any specific OS or system.
+
+## What does a Program look like?
+
+Here's an example program, specifically the "idle" loop.  The idle loop is a process that never ends, it just prints out "20" over and over.  I use it to keep the clock running when all the other processes are sleeping.
+```
+6        r4, $0                ;move 0 into r4
+26       r4                    ;lower our priority TO 0
+6        r1, $20               ;move 20 into r1
+11       r1                    ;print the number 20
+6        r2, $-19              ;back up the ip 19 bytes
+13       r2                    ;loop forever (jump back 19)
+```
+Programs consist of:
+
+```
+Opcode, [optional param], [other optional param] ;optional comment
+```
+
+So, if we look at:
+
+```
+6        r4, $0                ;move 0 into r4
+```
+
+We see that it's operation 6, which is Movi or "Move Immediate."  It moves a constant value into one of our 10 registers.  The first param is r4, indicating register 4.  The second param is $0.  The "$" indicates a constant.  So we are the value 0 into register #4.  Just like x86 assembly – only not at all. 
+
+So if you look at the comments for this app you can see that it loops forever.
+
+## How do run Program(s)
+
+Usage:
+```
+OS membytes [files]
+```
+For example:
+```
+OS 1568 prog1.txt prog2.txt prog3.txt prog1.txt idle.txt
+```
+This command line would run the OS with 1568 bytes of virtual (addressable) memory and start up 5 processes.  Note that Prog1.txt is specified twice.  That means it will have two separate and independent running processes.  We also specified the forever running idle.txt.  Use CTRL-C to break.  The OS has operations for shared memory, locks, and events, so you can setup rudimentary inter-module communication.
+
+## Why should I care?
+
+There are 13 other sample apps you can play with.  The OS is most interesting when you run it with multiple apps.  You can mess with OS.config to setup the amount of memory available to each process, the whole system's physical memory, memory page size etc.
+
+It's interesting from an OS theory point of view if you think about the kinds of experiments you can do like lowering physical memory to something ridiculous like 32 bytes.  That will increase page faults and virtual memory swapping.  So, the OS can be tuned with the config file.
+
+## What are the options in OS.config?
+
+It is certainly possible to give the OS a bad config, like more physical memory than addressable, or a page size that is the same size as physical memory.  But, use common sense and play.  I've setup it up with reasonable defaults.
+
+Here's a sample OS.config file.  The Config has to be in the same directory as the OS.exe.  Take a look at the included OS.config, as it has additional XML comments explaining each option.
+```
+<configuration>
+        <appSettings>
+                <addkey="PhysicalMemory"value="384"/>
+                <addkey="ProcessMemory"value="384"/>
+                <addkey="DumpPhysicalMemory"value="true"/>
+                <addkey="DumpInstruction"value="true"/>
+                <addkey="DumpRegisters"value="true"/>
+                <addkey="DumpProgram"value="true"/>
+                <addkey="DumpContextSwitch"value="true"/>
+                <addkey="PauseOnExit"value="false"/>
+                <addkey="SharedMemoryRegionSize"value="16"/>
+                <addkey="NumOfSharedMemoryRegions"value="4"/>
+                <addkey="MemoryPageSize"value="16"/>
+                <addkey="StackSize"value="16"/>
+                <addkey="DataSize"value="16"/>
+        </appSettings>
+</configuration>
+```
+Of note are the Dumpxxx options.  With all of these options set to false, the OS only outputs the bare minimum debug information.  With them on (I like to have the all on) you'll be able to see the results of each instruction and how they affect registers, physical memory, etc.  You'll see physical memory pages swap to disk, memory fragmentation, the instruction pointer increment, and processes take turns on the CPU.
+
+Be sure to turn up the size of screen buffer (usually under "Layout" in the Properties Dialog of your command prompt) to something like 3000 or 9999. This way you'll be able to scroll back and look at the details of your run.
+```
+OS 512 prog1.txt > output.txt
+```
+You might also try something like this to create a log file, or modify the source to include logging!
+
+## What are the available OpCodes?
+
+These are also printed and explain in the Help File as well as Final\_Project.doc. When writing a program you use the value, not the text name of the opcode.  So, you'd say `2 r1, $1` and **NOT** `addi r1, $1`.
+
+| Opcode | Value(decimal) | Format |
+| --- | --- | --- |
+| Incr | 1 | incr r1(increment value of register 1 by 1 ). |
+| Addi | 2 | addi  r1,$1 is the same as incr r1 |
+| addr | 3 | Addr r1, r2( r1 <= r1 + r2 ). |
+| Pushr | 4 | Pushr rx (pushes contents of register x onto stack. Decrements sp by 4 ). |
+| Pushi | 5 | Pushi $x . pushes the constant x onto stack. Sp is decremented by 4 after push. |
+| Movi | 6 | Movi rx, $y. rx <= y |
+| Movr | 7 | Movr rx, ry ; rx <= ry |
+| Movmr | 8 | Movmr rx, ry ; rx <= [ry] |
+| Movrm | 9 | Movrm rx,ry; [rx] <= ry |
+| Movmm | 10 | Movmm rx, ry [rx] <= [ry] |
+| Printr | 11 | Printr r1 ; displays contents of register 1 |
+| Printm | 12 | Printm r1; displays contents of memory whose address is in register 1. |
+| Jmp | 13 | Jmp r1; control transfers to the instruction whose address is r1 bytes relative to the current instruction. R1 may be negative. |
+| Cmpi | 14 | Cmpi rx, $y;  subtract y from register rx. If rx < y, set sign flag. If rx > y, clear sign flag. If rx == y , set zero flag. |
+| Cmpr | 15 | The same as cmpi except now both operands are registers. |
+| Jlt | 16 | Jlt rx; if the sign flag is set, jump to the instruction whose offset is rx bytes from the current instruction. |
+| Jgt | 17 | Jgt rx; if the sign flag is clear, jump to the instruction whose offset is rx bytes from the current instruction |
+| Je | 18 | Je rx; if the zero flag is clear, jump to the instruction whose offset is rx bytes from the current instruction. |
+| Call | 19 | Call r1; call the procedure at offset r1 bytes from the current instruction. The address of the next instruction to execute after a return is pushed on the stack. |
+| Callm | 20 | Callm r1; call the procedure at offset [r1] bytes from the current instruction. The address of the next instruction to execute after a return is pushed on the stack. |
+| Ret | 21 | Pop the return address from the stack and transfer control to this instruction. |
+| Alloc | 22 | Alloc r1, r2; allocate memory of size equal to r1 bytes and return the address of the new memory in r2. If failed, r2 is cleared to 0. |
+| AcquireLock | 23 | AcquireLock r1; Acquire the operating system lock whose # is provided in the register r1. If the lock is invalid, the instruction is a no-op. |
+| ReleaseLock | 24 | Releaselock r1; release the operating system lock whose # is provided in the register r1; if the lock is not held by the current process, the instruction is a no-op. |
+| Sleep | 25 | Sleep r1; Sleep the # of clock cycles as indicated in r1. Another process or the idle process must be scheduled at this point. If the time to sleep is 0, the process sleeps infinitely. |
+| SetPriority | 26 | SetPriority r1; Set the priority of the current process to the value in register r1; See priorities discussion in Operating system design |
+| Exit | 27 | Exit. This opcode is executed by a process to exit and be unloaded. Another process or the idle process must now be scheduled. |
+| FreeMemory | 28 | FreeMemory r1; Free the memory allocated whose address is in r1. |
+| MapSharedMem | 29 | MapSharedMem r1, r2; Map the shared memory region identified by r1 and return the start address in r2. |
+| SignalEvent | 30 | SignalEvent r1; Signal the event indicated by the value in register r1. |
+| WaitEvent | 31 | WaitEvent r1; Wait for the event in register r1 to be triggered. This results in context-switches happening. |
+| Input | 32 | Input r1; read the next 32-bit value into register r1. |
+| MemoryClear | 33 | MemoryClear r1, r2; set the bytes starting at address r1 of length r2 bytes to zero. |
+| TerminateProcess | 34 | TerminateProcess r1; terminate the process whose id is in the register r1. |
+| Popr | 35 | pop the contents at the top of the stack into register rx which is the operand. Stack pointer is decremented by 4. |
+| popm | 36 | pop the contents at the top of the stack into the memory operand whose address is in the register which is the operand. Stack pointer is decremented by 4. |
+
+## Known Issues/Things to Know
+
+- The OS will look in the current directory for files if no directory is specified.
+- Processes will be loaded and executed in the order they are specified on the command line.
+- There are two idle processes included.  idle.txt will run with lowest priority and will print out 20.  It will run forever.  idle-n.txt will run for n loops (not cycles), specified in the code.  As shipped, idle-n will run for 100 loops.
+- Redirecting OS output to a file is convenient: OS 1024 prog1.txt prog2.txt prog3.txt > output.txt
+- OS.config contains many debug flags that can be included to provide insight into non-debug program execution.
+- OS.config contains many options for configuration of memory.  It IS possible to feed invalid values into this config file.  For example, it's not valid to have a physical memory size larger than addressable memory, or a page size larger than addressable memory, etc.  This behavior is appropriate, and is by design.
+- Setting DumpInstruction=true in OS.config will output the a debug print of the executing instruction and the current process id.
+- If an idle process (idle.txt, etc) isn't included, and all running processes sleep or block on a lock, the OS will spin forever looking for an eligible process to run, and will find none.  CTRL-C will exit at this point.  This behavior is per spec and by design.
+- The OS will create XML swap files in the current for each memory page swapped.  These are cleaned up at startup, rather than shutdown, for purposes of exploration.
+- Batch files for testing purposes are included in this directory.
\ No newline at end of file