The Amiga Operating System: Past and Present cs 450 1
Download 61.32 Kb.
|
- Navigate this page:
- Overview: In what environment is your O/S designed to work
- History of Amiga
- Processor Modes
- Data Structures
- Allowable Process States
- Memory management: memory model, and implementation details Exec
- Accomplishments and Today
|
The Amiga Operating System: Past and Present CS – 450 – 1 Fall 2003 Aaron Hensley Brad Campbell Greg Mathurin Kayla Zinn Joshua Benson
Overview 3 A Brief History 4 Processor Modes 5 Data Structures 6 Allowable Process States 6 Threading 7 Memory Management 7 ExecSG 8 File System 8 Scheduling 10 Deadlock 10 Conclusion 11 Overview: In what environment is your O/S designed to work? In the early 1980’s the Amiga operating system known as ‘workbench’ with the graphical user interface known as ‘Intuition’ was designed originally on a 16/32bit custom-built computer codenamed ‘Lorraine’. Lorraine was designed around the Motorola 68000 processor and had 3 custom chips that handled ports and audio/video. The 3 custom chips were the ‘Agnus’ which was the address generator, ‘Denise’ which was the display adapter, and ‘Paula’ which handled the ports and audio. In order to appeal to the public, the name of the computer was changed to ‘Amiga’ which is Spanish for ‘female friend’. (Donner, Gregory 2003) The first Amiga computer, the Amiga 1000 was released in 1985 at a price of $1295.00 and was marketed as a high-end multimedia personal computer. The Amiga 1000, capable of priority based multi-tasking, used the MC68000 processor with an internal 32bit bus, 16bit data bus, and was clocked at 7.16 MHz. The system included 256K RAM and was expandable to 512K internally, though externally, it was able to handle 8Mb fast RAM. The graphics portion had a pallet of 4096 colors in a time when the Macintosh was black and white and the IBM PC was using a 16 color CGA display. The sound processor was designed to handle 4 independent sound channels configured as two stereo channels. The computer system included a two-button mouse and an 89key keyboard. Of particular note was the keyboard itself which was hidden inside the Amiga 1000’s chassis and could be rolled out when needed. (Donner, Gregory 2003) The Amiga went through many different models with each adding new features and improving upon the operating system’s kernel and user interface. The Amiga 500, released in 1987, was cheaper and smaller than the Amiga 1000. It replaced the ZORRO expansion slots with DMA slots and the new Workbench 1.3 introduced the command-line interface. (Knight, Gareth 2003a) The Amiga 2000, released also in 1987, separated the customer-base by being geared towards the high-end as the Amiga 500 remained a favorite as a low-end system. The Amiga 2000 shipped with the same version Workbench as the 500 model but was built around a larger desktop chassis. It sported 5 100-pin ZORO II slots and 2 16bit ISA slots and came with 1MB of memory. (Donner, Gregory 2003) In 1990, the Amiga 3000 was sold as a very high-end system with strong graphics capability. The main processor was upgraded to the 68030 and came with ZORO III slots. Two operating systems were shipped with the Amiga 3000, the Unix System (SVR4) V, and the newly released Workbench 2.0. Until now, Kickstart was stored in a ROM chip, but with Workbench 2.0, Kickstart was booted from the hard drive. Workbench 2.0 came with a revised version of Intuition where a new gray 3d look was adopted over 1.3’s flat blue look and many other features were introduced. (Knight, Gareth 2003a) A new system geared towards the game console market was introduced in 1992. The Amiga 600 was a computer and keyboard in one. The numeric keypad had been removed, but a PCMCIA port was added. The PCMCIA port allowed many things to be added such as extra memory, expandable to 6MB, CD-ROM and other disk drives. Workbench 2.05 was preloaded and included the usual enhancements to Intuition and many bug fixes. The year 1992 also brought about the Amiga 4000 which was the most advanced yet. It came with the EC030 or EC040 process clocked at 25 MHz. It introduced the AGA chipset which allowed it to show 256,000 colors on the screen using a palette of 16.8 million colors. It shipped with 6MB of RAM, a 1.76mb High-Density disk drive and a hard drive. Workbench 3 was shipped with the Amiga 4000 which featured data types, new diagnostic tools built into the startup boot menu, color remapping, and support for the AGA chip set which was used in the Amiga 4000. (Knight, Gareth 2003a) In 1996, the Amiga 4000T was released but only in small numbers. The Amiga 4000T shipped with IDE & SCSI-2 Fast controllers, 2 video slots and came with the 68040 processor clocked at the same clock speed as the Amiga 4000 at 25 MHz. (Donner, Gregory 2003) History of Amiga The origins of the concept of the Amiga started back in 1982 with a company called Hi-Toro which was based in Santa Clara, California. After being hired on as CEO, Dave Morse started working on a plan for a system called ‘Lorraine’ codenamed after his wife which would be a monster game machine with a 3.5” floppy drive and a keyboard and an open architecture so 3rd party developers could create games for it. Later in 1982, Hi-Toro changed its name to Amiga Incorporated. (Knight, Gareth 2003d) For the video subsystem, a form of blitter technology used for graphics which was called HAM, or Hold and Modify was used to display 4096 colors on the screen by changing color registers. RJ Mical, a software engineer, created the graphical user interface called Intuition. The three custom chips, Agnus, Denise, and Paula were prototyped. After two years of development, a product was ready to show off, but without sufficient funds, an investor was needed to keep Amiga Inc. alive. Atari offered Amiga Inc. money but with some strings attached. Then, on August 15th 1984, a company called Commodore International Ltd decides to buy Amiga Inc. and pay off Amiga’s debts to Atari. Commodore puts its focus on the Lorraine project and with new resources, the once monster game machine was turned into a personal computer. Eventually, after more development, the Lorraine project turned into the Amiga 1000 which was released in July of 1985. (Knight, Gareth 2003d) Although Commodore sold an estimated 4,850,000 Amigas while in business, Commodore began to make one mistake after another which finally led to liquidation April 29th, 1994. Commodore’s first mistake was to price the Amiga 1000 too high even though it was more advanced than any other personal computer system at the time. Before the Amiga was released, Atari released the Atari ST which was a 16bit system designed with cheaper parts and sold for less than half the cost of the Amiga 1000. By 1987, the Atari ST, having more games written for it, continued to outsell the Amigas. Commodore’s second mistake came when Chairman Irving Gould, with reservations of the focus on America when 70% of the market was overseas, replaced Thomas Rattigan as head of Commodore. Gould then changed the North American operation from an independent operation to sales and marketing. He also cut the payroll from 4,700 to 3,100, and closed five plants. (Knight, Gareth 2003d) During 1988, games eventually started being written for the Amiga that simply couldn’t run on the Atari ST. Atari, in a last ditch effort, sued Commodore saying that they had paid for the research of the Amiga. Commodore won the law suit and Atari was no longer a threat. Commodore, having conquered its main competitor, then made its third mistake. They only released on major upgrade, the Amiga 3000 in 1990 but otherwise let the market stagnate. This let Apple and Microsoft to quickly gain market-share in the workplace and by mid 90’s to start overtaking the home-computer market. Commodore released the Amiga 4000T, but only actually sold an estimated 200 computers before going out of business. (Knight, Gareth 2003d) Processor Modes The Amiga OS is designed to work with Motorola processors. For example, the A1200 Model runs the 68EC020 processor and the A4000/030 models run with the 68EC030 processor. Both of these processors are crippled versions of Motorola’s 680X0 processors that are cheaper. The only difference with the 68EC020 and the 68020 is that the first can only address 16 Mb of memory, only allowing for 10 Mb of RAM. The 68EC30 is not so lucky. The 68030 has a memory management unit, MMU that its’ crippled brother does not have. The most important applications that depend on this MMU are a debugging utility called Enforcer, a virtual memory emulator called GigaMem and the current versions of UNIX. A way around this limitation is to install an additional processor card of the 68030, 68040, or 68060. The Motorola 68LC040 is also used in Amiga’s. This processor is a crippled 68040 that doesn’t have Floating Point Operations (FPU) (Kellerer, 1996). The Amiga also uses custom co-processors. Two such places in which these co-processors are used are the keyboard and the display. The display co-processor utilizes its ability to change the majority of the special purpose registers to synchronize with the video beam’s position. This allows for special effects such as mid-screen color pallet changes and splitting the screen into different horizontal slices which each have separate color depths and video resolution. For 68000 Models and above the specialized co-processor can trigger at the start or even during the blanking interval and while in the middle of lines. This ability to affect the custom chipset's registers frees up the main processor for the general tasks (Amiga Relm Smart Directory Service, 2000). These custom processors are set up as master and slave, but for the newest release of Amiga (4.0) Symmetric Multiprocessing (SMP) are planned (Wang, 1999). Also to help out the processor (available for 68000 and above) is the custom bit blitter. The blitter is used for fast data movement that can be needed for bitplane animation. A special mode of the blitter can draw patterned lines to memory regions organized rectangularly at speeds of approximately 1 million dots per second, efficiently handling area fill. The blitter can also acquire information from up to three data sources, use one out of a possible 256 ways to combine the data and use an optional destination area to store it. Even though the blitter does draw memory cycles to a DMA channel, it makes the job much more efficient (Amiga Relm Smart Directory Service, 2000). Data Structures One of the more common data structures used by Commodore in their Amiga OS is the RexxStack. This is an elaborately designed stack that has also been used in other operating systems like OS/2 and UNIX as not only the go-between for applications but also for going between the operating system, shell, and applications. It is said that “In UNIX speak, it is similar to a daemon able to funnel data between separate applications and perhaps the shell itself.” According to Ioannis Tambouras the RexxStack differs from a typical stack for these reasons. “(a) It contains buffers within the stack, and stack operations can be applied within a region of the stack, (b) It support multiple stacks in stack- within-stack fashion, (c) It supports both a Perlish and Rexx syntax -- the Rexx syntax is probably simpler. (d) The stack scope can be internal to the application (as usual), or the Stack can run as a daemon to enable sharing of data between network applications, or you could use both the internal plus the networking stacks at the same time. (Tambouras, 2003).”
There is barely any public information out about the process states on the Amiga operating system. The Amiga operating system keeps two separate queues, one for processes that are waiting and another for those that are currently running. Processes are referred to as states in Amiga. Therefore the waiting queue contains a list of tasks that are in a wait state because they have been blocked by an input/output request or something similar. Those tasks in the running queue are currently being switched in and out of the processor by the scheduler and have not yet been blocked. The function _TaskEnd will terminate a given task and remove it from any queue. Likewise the TaskStart function will create a new task and place it immediately into the running queue (Carter, 1995). Threading Amiga does not support threads in the standard sense of the definition. However, because Amiga is not memory protected and it supports both semaphores and a inter process message system, it is possible to achieve a similar effect. Amiga has the ability to lock resources and queue tasks that are waiting for the resource through its semaphore system and message system. Tasks may be exclusively locked or shared locked. The latter would be used in the instance that a space in memory needs to be read by multiple tasks and only written to by one. ObtainSemaphore() and ObtainSemaphoreShared() provide exclusive and shared locking respectively. A task may wait without being blocked by using Procure(). If the resource isn’t available at the time of Procures call then the task may continue to run or wait as necessary until it receives a bid Message at its reply port. A bid Message is sent when the last task to Procure() a resource calls Vacate(). Semaphores may be nested if a task calls ObtainSemaphore() or Procure() more than once. Using the message system tasks can be nearly synchronized. PutMsg() sends a reference rather than copying a Msg, which is much quicker than some systems found in today’s monolithic PC desktops (Windows). This is a product of Amiga’s lack of memory protection, which has the downside of low security. PutMsg() attaches a message to a MsgPort and a Msg may only be attached to one port at a time. However, because Msgs are passed by reference a Msg may be passed from the MsgPort of one task to the next very quickly resulting in near synchronization. Memory management: memory model, and implementation details Exec The original Amiga operating system started out in three parts. The first part was the multi-tasking kernel called ‘Exec’, then AmigaDOS proper which handled the high-level file system and command line interface, and finally, Intuition, which is the graphical user interface. Exec, written in 68K assembly (Amiga Inc, Hyperion 2002 ), is object oriented by design and by using inheritance extensively, is able to reduce redundancy. The memory management of Exec is based on a simple list of free memory space. The list itself, as with most lists in Exec, is based on doubly linked lists. Each node in the doubly linked list contains a miniNode which in turn contains a miniList. The miniList, like the main list is doubly linked, but it also uses dummy nodes at the head and tail of the list. The previous pointer of the head node points to the same NULL as the next pointer of the tail node. The free space list starts out as one single node representing all of the free memory available. Memory allocation starts out with the being scanned for the first node that represents a block that is the same size or larger than what is required. Once located, the node is taken and removed from the list. If the block of memory is larger than what was needed, then the left over free space is separated and returned into the list. There are two problems with the memory management design. One problem is that Exec does not have a list that keeps track of allocated memory and has no ability to return un-needed memory back to the free space list. This means that if a program does not de-allocate its memory using some form of cleanup method, then that part of memory is no longer accessible to the system until it is rebooted. The second problem is with fragmentation which is inherent with this type of design. As nodes are removed from the list and returned to the list, the list itself may become very large and may take a very long period of time to traverse. Again, the only way reset the fragmentation is to restart the computer. ExecSG ExecSG, which stands for ‘Exec Second Generation’, was designed to replace the original Exec in Amiga OS 4. For ExecSG, the original Exec was rewritten in C and many modern features were added. ExecSG introduced virtual addressing, page-based memory handling, priority sorted lists, virtual memory, and automatic stack enlargement. The size of the pages was kept at 64KB in order to reduce management overhead. This means, that ExecSG divides the entire 4GB address space into 65,536 separate pages. (Frieden, Thomas 2003) Instead of the simple list based system Exec used, ExecSG uses objects in a priority sorted list and each object controls an area of address space. The use of objects is a very powerful approach as the actual abilities of the objects can be more than simply allocating memory when requested. In fact, instead of only failing a request, an object can intercept that failure and implement what is called ‘delayed memory allocation’. This means that it will allocate the memory required virtually, but not physically. In this situation, a small amount of physical memory can then be allocated, enough to allow the access to work, and then return control back to the requesting program. (Frieden, Thomas 2003) When memory needs to be allocated, each object is queried in the list with size and requirements as parameters. If one object is unable to fulfill the requested parameters, the next object is queried. Once an object is able to fulfill the request, the request is executed, and the object informs ExecSG the memory area that has been allocated. Memory protection is one feature that has not been implemented in ExecSG yet, but using the object-based list design, the objects will simply have to be changed so that each object will represent a program and prevent each program from using the memory space of another. Some objects will be left to non-program specific purposes so that memory may be shared between several programs. (Frieden, Thomas 2003) File System The Amiga file system is primarily focused on the integrity of data rather than the speed of its access. The original file system used with the Amiga OS was created in 1985 and written using the BCPL language, a precursor to 'C.' This original file system ran only on floppy media, as hard disks were very expensive and uncommon at the time. The file system used a decentralized data structure to store all data and file system data structures. This decentralized approach would write different blocks of a piece of data to uncontinuous areas of the disk. The fragmentation of the files coupled with checksum data that was calculated for every block made the Amiga file system a reliable but very slow data source (Barthel, 2003). The current version of the file system is known as the Fast File System, FFS. This system is written exclusively in MC6800 assembly language. Because of this, it is completely importable to any other hardware. The addresses for data are all stored in a sixty four bit value, which means that 2^64 bytes can be addressed in physical storage. This was to fix a maximum disk size problem of four gigabytes in earlier versions of the file system. When writing to disk, the new FFS will write as many continuous blocks of data as possible (Barthel, 2003). This helps to reduce the amount of head movement required to read a piece of data and in turn greatly increases the speed at which the data can be read from the file system. Every entry within a directory and the directory itself use the same data structure to store information concerning their attributes. This data structure contains the following fields: the name of the item, the last known modification date, the permissions associated with access, the size, and a list of the block numbers that the data is actually written to. The list of block numbers is often only the first few blocks of a piece of data which are contained in a linked list of all the blocks for that particular piece of data (Barthel, 2003). This helps keep the size of the data structure smaller, since not all of the blocks are listed. Using this scheme, the only limitation to the number of files which a drive may contain is strictly based upon the storage capacity of the drive. There is no entry in the data structure that limits the file system to an upper bound of files. The size field within the data structure for each file is a thirty two bit signed integer value. This signed integer number represents the number of sectors that a file is using (Barthel, 2003). Since it is a thirty two bit signed value the maximum number of sectors that a file may use is two raised to the thirty first power. This translates to a file size of two gigabytes if your sector size is set to five hundred and twelve bytes in size like they are in the Amiga OS. Another addition to the original file system is directory caching. Directory caching was implemented in order to increase the response time of scanning a directory to learn its contents. A new data structure known as the directory list is now kept. The directory list contained information on all directories and all entries within each directory at a single location on the drive so that it would not be necessary to gather that information every time it is requested. In order to read the contents of a folder, the operating system only had to check the file's one or two blocks of data as opposed to possibly twenty or thirty for the entire drive. The directory list however made writing data to the drive slower due to the added overhead of maintaining this file in sync with the actually contents of the drive. In order to compensate for this drop in write efficiency, an option to set the allowable number of sectors allocated to each block was added. A user could now choose to allocate two, four, eight, or sixteen sectors to each block (Barthel, 2003). The increased number of sectors per block decreased the amount of head movement and overhead associated with checksums. The result was an decrease in write time comparable to the increase added by having the directory list. Scheduling Process scheduling is an important part of the Amiga system because it is known for being one of the best and most efficient multitasking operating systems around. Though Amiga is not currently a parallel CPU system, it uses a UNIX-like process scheduler that utilizes several process scheduling techniques. These place the most-needed processes on the processor while minimizing overhead and avoiding starvation (Mathews, 2000). The short-term scheduler uses preemptive, priority-controlled, round-robin scheduling to schedule processes. This is a single-level queuing system that uses the round-robin system with an 80 millisecond time quantum to run tasks, but allows the task priorities to govern how often the processor gets each one. Priorities are set from -127 to 127, with a higher number indicating a more important process. Like any other round-robin scheduling system, each process runs for its set time quantum, in this case 80 milliseconds, and is then is removed from the processor. However, instead of running processes sequentially, the priority of each process determines how soon a task returns to the processor after it is removed. A high priority process is scheduled to go again soon after its time quantum is used up, or even go several time quantums in a row (Mathews, 2000). The Amiga system also has the special feature of allowing the user to have some control over process scheduling. The user can change the priority of a process by changing its settings in the Amiga’s control panel, or by using the ChangeTaskPriority command. There is also a tool called the Executive which allows the user to dynamically change task priorities as they are running. All of these are useful both to boost the priority of an urgently-needed task, and to reduce the priority of a very CPU-intensive program so that other programs may run simultaneously while it is executing without becoming extremely sluggish (Mathews, 2000). In addition to efficiency from the scheduling techniques, Amiga consumes almost no time in passing memory addresses from one process to another. There is no memory protection in the Amiga OS, so running programs can pass memory addresses freely and directly from one to another. Of course the downside of this is that memory is left unprotected and sometimes becomes corrupted (Coughran, 2003). Deadlock Deadlock, the situation of having a circle of processes and resources each waiting for each other indefinitely, is a problem with the Amiga system. For the most part, this operating system simply ignores the problem of deadlocks, allowing them to take place and taking minimal action to prevent or avoid them, as well as providing few ways to recover from them once they occur. It then becomes the job of researchers and programmers working with the operating system to manually break the deadlocks as they occur. One reason for the frequent updates of Amiga is that certain commands and operating system states tend to incur deadlock and programmers must research ways to fix them. For example, in the Amiga research operating system AROS, researchers log all of the deadlocks they had to remove themselves. The ExamineAll() and ExtendFont() commands had to be taken out of deadlock, the LDDemon, which loads libraries from disk, had to be released. The removal of some unneeded variables in LDDemon reduced the frequency of deadlocks in RAM a great deal (Digulla, 2003a). There are, however, a few provisions made for deadlock avoidance and the find-and-repair technique. For instance, when a context becomes locked by LockContext(), no other processes may lock that context until the original is finished with it. If the context enters deadlock during this time, the OS switches back to the task which first locked the context (Digulla, 2003b). There is also an occasional semaphore added to protect commands from future locks. For example, one was added by the AROS researchers to the rendering of text to a bitmap after it was released from deadlock (Digulla, 2003a). Accomplishments and Today? Since the demise of Commodore, Amiga has all but disappeared as a serious platform. The intellectual property has been purchased and sold by companies such as Escom and Gateway 2000. None of who made any significant contributions to the Amiga community by either not having the funds to do so, or simply buying Amiga simply for the patents. Many current projects are underway. One is to port the Amiga OS to the Linux kernel. Another is to develop a fully functional emulator that allows the Amiga OS to run on an x86 or PowerPC based system. On the hardware side, no work has been done to fully update the old custom 68k solution, but rather to run the Amiga OS on standard PC. The Amiga computer and operating system were ahead of its time compared to similar personal computer systems when it was first introduced in 1984. Lists of accomplishments include the Amiga being used to produce the 3d graphics in the movies “Babylon 5”, “Max Headroom”, and “SeaQuest DSV”. It was also used to produce the graphics in numerous television shows such as “Alf” and "Amazing Stories". (Tiberio 2003) Amiga Inc, Hyperion (2002 ). “Amiga OS 4.0” URL: http://amiga.emugaming.com/amigaos40.html Amiga Relm Smart Directory Service (2000). “Components of the Amiga” URL: http://www.amigarealm.com/computing/knowledge/hardref/ch1.htm Barthel, Olaf, 2003. “Something old, something new: the Amiga Fast File System, past, present and future.” URL: http://os.amiga.com/cam/index.php?i=4&p=4 Carter, S.P., 1995. “Release 0.0.0.20 and Thoughts.” URL: http://lists.tunes.org/archives/tunes/1995-August/000742.html Coughran, David (2003). “Amiga Design” URL: http://www.moa.sonnet.com/drc/amiga-hw.html Digulla, Aaron. (2003a). “Miscellaneous” URL: http://www.aros.org/news/archive/2001.php Digulla, Aaron. (2003b). “MMU HIDD” URL: http://www.aros.org/documentation/developers/specifications/drafts/mmuhidd.php Donner, Gregory (2003). “Workbench Nostalgia” URL: http://www.gregdonner.org/workbench/ Frieden, Thomas (2003). “ExecSG in detail: Memory” URL: http://os.amiga.com/cam/index.php?i=7&p=7 Kellerer, Ignaz (1996). “Frequently asked questions (FAQ) concerning the Amiga.” URL: http://www.faqs.org/faqs/amiga/introduction/part1/ Knight, Gareth (2003a). “Amiga OS” URL: http://amiga.emugaming.com/amigaos-ng.html Knight, Gareth (2003b). “The ‘Classic Amiga' Range” URL: http://amiga.emugaming.com/comamiga.html Knight, Gareth (2003c). “Commodore-Amiga Sales Figures” URL: http://amiga.emugaming.com/sales.html Knight, Gareth (2003d). “The Twists and Turns of the Amiga Saga” URL: http://amiga.emugaming.com/ahistory.html Mathews, Dave S. (2000). “This Old Workbench Episode Nine” URL: http://www.amigau.com/amigarealm/thisoldworkbench/html/towb09.html Orup, Paul (2003). “Threads/Mutual Exclusion/Synchronization.” URL: http://os.amiga.com/forums/viewtopic.php?t=1948 OS3.5 - Developer CD v2.1“Includes and Autodocs 2.0” URL: http://amiga.nvg.org/amiga/reference/Includes_and_Autodocs_2._guide/node059D.html Park, Alfred (2002). “Multithreaded Programming.” URL: http://vergil.chemistry.gatech.edu/resources/programming/threads.html Tambouras, Ioannis(2003). “RexxStack - Introduction to RexxStack modules” URL: RexxStack - Introduction to RexxStack modules Tiberio, David (2003). “List of Famous Amiga Uses” URL: http://www.obh.snafu.de/~solon/TELEVISION.html Wang, Alf (1999). “Amiga Back for the Future – Software” URL: http://www.idi.ntnu.no/~alfw/future/software.html#os3 Work Breakdown Statement:
Processor modes, privileged instructions, uniprocessor/multiprocessor, SMP or master/slave Data structures used for process, memory, and file management
Aaron: Overview (workable environments, success, advantages/faults) Memory Management
Brad:
Allowable process states File management
Greg:
How is deadlock dealt with? Scheduling
Josh:
Threads (single or multi-thread? Types of threads?) Facilities for mutual exclusion and synchronization Four group meetings were scheduled, and each group member showed up to every meeting although sometimes late. Multiple Choice Questions: The Amiga Fast File System favors:
How many different task states are allowed in the Amiga Operating System?
The Amiga scheduler uses a _____________ system.
The kernel of the Amiga operating system is referred to as:
What is used to achieve a similar effect of threads?
Directory: abzugcx -> Public -> Student-Produced-Term-Projects -> Operating-Systems-2003-FALL Student-Produced-Term-Projects -> Use of the Overlay Technique in ms-dos to Circumvent the 640k conventional Memory Barrier Student-Produced-Term-Projects -> Spring 2004 Brett Casbeer, Adam Kenny, Chris Kopek, Nick Snead Student-Produced-Term-Projects -> Table of Contents page 1 Operating-Systems-2003-FALL -> Table of Contents page 1 Student-Produced-Term-Projects -> Mike Forster Download 61.32 Kb. Share with your friends:
|