DOCSLIB.ORG

New H17 Hard-Sectored Disk Image 1.0 Overview 2.0 Brief Description

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
New H17 Hard-Sectored Disk Image 1.0 Overview 2.0 Brief Description New H17 Hard-sectored Disk Image 1 1.0 Overview 2 This document proposes a new format for Heathkit H17 Hard-sectored Disk Images. The main goal is 3 to add header data to the disk format, currently H8D stores the data blocks on a hard-sectored disk but 4 does not store the 5 byte header for each sector. This information is critical to transparently supporting 5 different OS (HDOS vs. CP/M) disks in an emulator. 6 1.1 ASCII Section 7 -----------Beginning of Part 1 ---------------------------------------- 8 H8D - Heathkit H17 Hard-Sectored Disk Image<cr> 9 Version: xx.yy.zz<cr> 10 Info: http://heathkit.garlanger.com/diskformats<cr> 11 Format: (text description.. tbd)<cr> 12 Heads: [12]<cr> 13 Tracks: nnn<cr> 14 Sectors: nnn<cr> 15 Comment: (free form up to an EOF character)<EOF> 16 ----------End of Part 1 ------------------------------------------------- 17 1.2 Binary Data 18 The binary data MUST start immediately following the EOF character in the ASCII Section. It will 19 always include the 3 byte file tag and 3 byte version number at the start of the section. At offset 0x06, 20 blocks as defined below will be stored with the IDs in numerical order. Table 1: Current Layout Binary Data Offset Name Size Required Description (bytes) 0x00 Signature 3 Yes ASCII “H8D” to confirm file type. 0x03 Version 3 Yes The file format version. 0x06 Disk Format 11 Yes General information about the disk Block such as Heads, tracks, sectors. 0x11 Flag Block 6 Yes Flags for the disk 0x17 Data Block Variable Yes The actual data from the disk Variable Sector Variable No A Mapping of status code for the Status reading of each sector on the disk. Variable Reserved Variable Yes/No Any other blocks that will be added to the future. 21 2.0 Brief Description 22 2.1 Part 1 23 Part 1 is similar to the ASCII header included in the .IMD file format created by Dave Dunfield. 24 This information is to help someone viewing the file via 'TYPE' (DOS), 'cat', or 'more' (UNIX) or some 25 other command. Although this information SHOULD be included all files, all decoder applications 26 MUST be able to handle files if the only portion of part 1 is the <EOF> character. 27 [[Questions: should we change the new H8D to something else to avoid confusion – most likely 28 it should be change, but to WHAT?.]] 29 2.2 Part 2 30 The second part of the file contains the binary data describing the structure of the disk and the actual 31 data bytes. 32 2.2.1 Header 33 The header starts with the 3 bytes: 'H8D'. This signature allows programs to quickly verify that the file 34 is in the correct format. 35 The version number is the next field and is 3 bytes long. This field is contains the version of the 36 software that created the disk image. 37 2.2.2 Block Format Table 2: Block Format Position Description 1 Block ID type and flags 2-[3 or 5] Length [4 or 6] Block Data - Dependent on Block ID type ... [4 or 6] + Length 38 39 The final portion of the file consists of 3 mandatory blocks and zero or more optional blocks. 40 Each block contains a 3 or 5 byte header, followed by the data associated with the block. 41 The first byte of the header consists of 3 fields, a one bite Mandatory flag, a one bit length flag, and a 6 42 bit ID field. The next 2 or 4 bytes of the block (dependent on the length flag) is the Data Block Length. 43 The actual Data Block follows the 'Data Block Length' bytes. The format of this data is dependent on 44 the Block ID type. Table 3: Block ID Type Layout (First Byte of the Header) Bit 7 6 5 4 3 2 1 0 Description M L Block ID 45 46 The Mandatory bit (M), Bit 7 (0x80), signifies if decoding and processing the block is mandatory to 47 properly decode the file. This allows new blocks to be added and flagged as optional if it doesn't impact 48 the readability of the core part of the file. A 0 value means this block can be ignored by older decoders, 49 or even current decoders that do not care about the information. A value of 1 means the the decoder 50 should generate an error and not process the file any further if the ID number is unknown by the 51 decoder. 52 The Length bit (L), Bit 6 (0x40), signifies whether the length field is 2 or 4 bytes long. A 0 value means 53 the Length field is 2 bytes, a value of 1 means the length field is 4 bytes. 54 2.2.3 Block ID Values Table 4: Block ID Type Values Value Name Required Description (lower 6 bits) 0x01 Disk Format Yes General information about the disk such as Heads, tracks, sectors. 0x02 Flags No Flags for the disk 0x20 Data Block Yes The actual data from the disk 0x21 Sector Status No A Mapping of status code for the reading of each sector on the disk. All other Reserved Undefined. Any new IDs need to be reserved value to avoid potential conflict. 55 56 2.2.3.1 Disk Format Block ID 57 The Disk Format Block describes the general layout of the disk. This includes one byte for the Format 58 Type (values to be determined). Next, it includes the number heads. Valid values are 1 or 2. Next is the 59 Number of tracks. Valid values are 40 or 80. Next is number of sectors, for hard-sectored disks, this 60 will always be 10. Next is the sector size, this is only for the data portion of the block. It will always be 61 set to 256. Finally, is the sector size stored on in the file, to include the header portion of the sector plus 62 the sync and checksum of the data block, the value of this field will be 263. The “Data Block Offset” 63 specifies where the data from the sector starts. Since this format will include the 5 byte header plus the 64 sync byte for the data portion of the sector, the offset to the data portion of the sector is 6. [[ There 65 needs to be a better way to specify this so that it allows the “Stored Sector Size” to increase to include 66 the zero pads... ]] Table 5: Disk Format Block Description Size (bytes) Allowed Values Format Block ID 1 0x80 (0x00 + 0x80) Block Length 2 0x00 0x08 Format Type 1 TBD Heads 1 1 or 2 Tracks 1 40 or 80 Sectors 1 10 Data Sector Size 2 256 Stored Sector Size 2 263 Data Block Offset 2 6 67 68 2.2.3.2 Flags Block ID 69 The flag block currently has 3 fields. The values may be boolean or values. A bool only use the bit 0. A 70 value flag uses bits 0-6. For both types, bit 7 is defined to be the Mandatory flag. If the value is 1, the 71 decoder must understand and decode the value. A value of 0, implies that the image can be correctly 72 decoded without the decoder understanding the flag. None of the current flags are mandatory. 73 Write-Protected (W/P) Flag (boolean) - This signifies if the disk is write protected. If the value is 1, the 74 disk is write protected. If 0, writes are allowed. 75 Distribution Disk(value) - This flag signifies if the image was created from an original distribution 76 disk. The value of 2, means that it was created from an original distribution disk. A value of 1, means 77 status unknown. A value of 0, means it was not an original distribution disk. 78 Source of Header data(value) - This flag determines if the headers for the image were save from the 79 actual disk or if it was auto-created by a utility. A value of 1 means that the header data (plus data block 80 sync and checksum) was captured from the actual disk. A value of 0 means that it was generate by a 81 conversion utility. A value of 2 means that it was created by a program ran under an emulator. [[Could 82 there be other values for this? ]] Table 6: Flag Block Description Size (bytes) Allowed Values Format Block ID 1 0x80 (0x00 + 0x80) Block Length 2 0x00 0x03 W/P Flag 1 0x00 or 0x01 Distribution Disk 1 nn Source of Header data 1 nn 83 84 2.2.3.3 Data Block ID 85 The data block section is similar to the existing H8D format. Instead of each sector using 256 bytes, 86 each sector contains 263 bytes. The first 5 bytes are the header bytes. The length of this block is 87 determined by calculating the following: <heads> * <tracks> * <sectors> * <stored Sector Size> Table 7: Data Block Description Size (bytes) Allowed Values Format Block ID 1 0x81 (0x01 + 0x80) Block Length 4 See text. Disk Data Length any 88 Table 8: Header Position Description 1 Sync Byte 2 Volume Number 3 Track Number 4 Sector Number 5 Checksum 89 Sync Byte - the Sync Byte is defined to be 0xFD in the H17 ROM. 90 Volume Number - the Volume number on track 0 is always 0, to allow booting on mounting of disks 91 before the volume number has been determined.
Load more

Recommended publications
  • Personal Information Disclosure Consent Form
    Personal Information Disclosure Consent Form Ignace irradiated prevalently if eyed Wash slews or settles. Rapturous Mason misteach no orthography cross-pollinating homiletically after Jo sleds pruriently, quite unbeautiful. Moss is twenty-five: she fuse somberly and discomposing her hustle. Continuing care new forms should persons be required for disclosure or person form, and disclosures for minors should receive. Hdos can consent form will not reveal a disclosure address are typically, because so in an ssn. Privacy event that also falls under addition or obstacle of the FOIA exemptions. However, an organization should attempt may be unique specific when possible. New uses abbreviations or receiving marketing purposes other. Upon completion of the program, insurers, consent might be given electronically and myself be time limited. We do not share client information with organizations outside of our relationship with you that would use it to contact you about their own products or services. Personal information shall be protected by security safeguards appropriate ask the sensitivity of the information. Hdos adopt a consent forms are doing business day when a special circumstances. Ethics and with the patio of personal information form to. Person wish for minors to assist constituents with a regular form and plain of personal information form, send a written request allow the address noted abo. It into being completed online therapy consent forms of disclosure control by phone conversations, and disclosed for which it must object on whether such. If you do not want your authorization to be effective Where Do I Send My Completed Form? Patient is comfortable sharing. Existing ethical, administration of an enumeration system that be burdensome, treated for substance abuse and were treated to determine pregnancy.
    [Show full text]
  • HDOS:An Infrastructure for Dynamic Optimization
    HDOS:An Infrastructure for Dynamic Optimization Tomoaki Ukezono and Kiyofumi Tanaka Japan Advanced Institute of Science and Technology School of Information Science 1-1 Asahidai, Nomi, Ishikawa 923-1292 Japan e-mail: t-ukezo,kiyofumi @jaist.ac.jp Abstract—Recently, CPUs with an identical ISA tend to have In order to solve the problem, dynamic optimization tech- different architectures, different computation resources, and spe- niques are effective. Dynamic optimization techniques can cial instructions. To achieve efficient program execution on such optimize binary codes at run time. In other words, the dynamic hardware, compilers have machine-dependent code optimization. However, software vendors cannot adopt this optimization for optimization is client-side (not vendor-side) optimization. For software production, since the software would be widely dis- Example, JAVA JIT compiler translates byte codes to native tributed and therefore it must be executable on any machine (optimized) binary codes at class loading time, and reduces with the same ISA. To solve this problem, several dynamic overheads due to virtual machine execution. However, the optimization techniques such as JAVA JIT compiler and Mi- translation cannot be applied to all parts of codes, and crosoft .NET platform are effective. The techniques can perform the machine-dependent code optimization without source code. therefore the remaining byte code execution is ten times or However, the techniques have to exploit special environment more inherently-slow compared with native code execution. (VM) for program execution or special executable code (e.g. Moreover, the JIT compilation overhead is incurred at every code augmentation). In this paper, we propose an infrastructure class loading time even if the same class is loaded again.
    [Show full text]
  • Chapter 1 of the Heath HDOS System Manual
    VOLUME HEATH data systems HD OS System Programmer’s Guide Software Reference Manual 595-2553-02 Copyright © 1980 HEATH COMPANY Printed in the United Heath Company States of America All Rights Reserved ENTON HARBOR, MICHIGAN 4 9 0 2 2 2 TABLE OF CONTENTS Part 1 — Introduction.......................................................................... 5 Purpose ................................................................................................................... 5 Background ............................................................................................................ 5 Preface..................................................................................................................... 5 Part 2 — Run-Time Environment ......................................................... 6 Memory Layout...................................................................................................... 6 I/O Environment.................................................................................................... 7 Interrupt Environment........................................................................................... 8 Interrupt Vectors................................................................................................. 8 Discontinuing Interrupts................................................................................... 9 CPU Environment.................................................................................................. 9 Channel Environment..........................................................................................
    [Show full text]
  • VPIP (Vinculum Peripheral Interchange Program)
    VPIP (Vinculum Peripheral Interchange Program) (Beta Version – 24 February, 2014) With the recent introduction of the Universal Serial Bus (USB) interface cards for the Heathkit H8/H89 computers (http://www.koyado.com/) these classic machines now have the ability to access files on USB media such as memory sticks. This is a significant step forward for these computer systems, which previously have relied on floppy-disks for removable storage and backup. The heart of the USB capability is the VDIP-1 interface module from Future Technology Devices International (http://www.ftdichip.com/) running the Vinculum VNC1L Firmware. This module and firmware implement all of the details of the USB interface protocol. The purpose of the VPIP program is to provide a convenient interface to the USB device from the HDOS command prompt. VPIP is loosely modeled after the PIP utility provided with HDOS, however it only implements disk-to-disk copy and file listing (directory) commands. You’ll still need PIP to delete, rename or copy files to the screen or printer. Similarly to manipulate (copy, delete, rename, etc.) files on the flash drive you’ll need to use a personal computer or other device. VPIP currently can only be used to access storage devices via the USB port, not printers, keyboards or other accessories. You can run VPIP two ways: with a single command provided on the command line, or interactively. To run VPIP interactively type VPIP at the command prompt: >VPIP :V: The :V: prompt will be displayed at the left margin of the system console whenever the VPIP program is awaiting input.
    [Show full text]
  • MEDICAL DEVICES: SECURITY CHALLENGES for Hdos and MANUFACTURERS
    W H I T E P A P E R MEDICAL DEVICES: SECURITY CHALLENGES FOR HDOs AND MANUFACTURERS RICH CURTISS | DIRECTOR, COALFIRE INTRODUCTION This paper aims to help organizations understand the issue of security in the context of medical devices. Medical devices have not historically been included in HIPAA compliance regulations or healthcare security and risk programs, yet their capabilities make them prime targets for exploitation. Increased connectivity of medical devices has exposed them to cyber attacks from which they not were designed to prevent. At stake are both patient safety and privacy plus healthcare delivery organizations’ (HDOs) network security. One objective for this paper is to get this issue on the radar of HDOs. We’ll also review the benefits of ‘security by design’ and the concept of embedding security into devices for medical device manufacturers as they seek market differentiation, rapid go-to-market capabilities, and security throughout the product life cycle. SAFE VS. SECURE In the age of the digitized enterprise, the security of electronic protected health information (ePHI) is paramount on every front and endpoint. HIPAA does not regulate medical devices, but it does impose requirements on covered entities and business associates for the safeguarding of ePHI that is created, received, maintained, or transmitted. For this reason, medical devices should be included in HDOs’ HIPAA security programs, and security should be embedded in every stage of a device manufacturer’s product development lifecycle. Beyond patient privacy, the lack of medical device security can be a patient safety issue if an attacker is able to compromise them.
    [Show full text]
  • D-G Heartbeat / Super 89 Operation Manual
    OPERATION MANUAL Please read Operator's Manual prior to installing or operating this device. Your warranty may be af­ fected by failure to read the Operator's Manual prior to installation. ~ ELECTRONIC (214) 465-7805 [J 700 South Armstrong -1::1 OEVELOPMENTS CO. Denison, Texas 75020 REGULATORY INFORMATION This equipment complies with the requirements in Part 15 of FCC Rules fo r a Class A computing device. Operation of this equip­ ment in a residential area may cause unacceptable interference to radio and TV reception requiring the operator to take whatever steps are necessary to correct the interference. Congratulations on the purchase of your new HEARTBEAT computer. This product has been provided to you by an authorized HEARTBEAT dealer who will also provide warr anty service for your system. If you s hould experience difficulties during installation or operation return the product to your dealer for repair during the first 90 days. Your dealer is qualified and authorized to make necessary modifications and/or repairs. D-G Electronic Developments Company, Inc. does provide repair services for a nominal fee after the warranty has expired. The purchaser should contact D-G Electronic Developments Company, Inc . at AC(214)465-7B0 5 prior to returning the unit to receive the necessary "RETURN MERCHANDISE AUTHORI ZATION " number. Failure to do so will result in the return of the unit without repairs. To qualify the unit for " after warranty" service from the factory you must complete the attached registration card and return it to: D-G Electronic
    [Show full text]
  • Network Working Group J. Reynolds Request for Comments: 1700 J
    Network Working Group J. Reynolds Request for Comments: 1700 J. Postel STD: 2 ISI Obsoletes RFCs: 1340, 1060, 1010, 990, 960, October 1994 943, 923, 900, 870, 820, 790, 776, 770, 762, 758,755, 750, 739, 604, 503, 433, 349 Obsoletes IENs: 127, 117, 93 Category: Standards Track ASSIGNED NUMBERS Status of this Memo This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited. OVERVIEW This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This RFC has been assembled by catinating these files together with a minimum of formatting "glue". The authors appologize for the somewhat rougher formatting and style than is typical of most RFCs. We expect that various readers will notice specific items that should be corrected. Please send any specific corrections via email to . Reynolds & Postel [Page 1] RFC 1700 Assigned Numbers October 1994 INTRODUCTION The files in this directory document the currently assigned values for several series of numbers used in network protocol implementations. ftp://ftp.isi.edu/in-notes/iana/assignments The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols. The IANA is chartered by the Internet Society (ISOC) and the Federal Network Council (FNC) to act as the clearinghouse to assign and coordinate the use of numerous Internet protocol parameters.
    [Show full text]
  • Stwadventure-Alt-Manual
    cr1z.e Software croofw6rk$ "1alt CJJilofsky; Prop. 14478 GLORIITTA DRIVE TELEPHONE SHERMAN OAKS, CALIFORNIA 91423 12131 986-4885 Original ADVENTURE Version 1.0 - February 1982 8080/ZSO implementation by Dr. Jim Gillogly and Walt Bilofsky Copyright (c) 1982 James J. Gillogly and The Software Toolworks. Sale of this software conveys a license for its use on a single computer owned or operated by the purchaser. Copying this software or documentation by any means whatsoever for any other purpose is expressly prohibited. 1. INTRODUCTION Welcome to Adventure!! Would you like instructions? Adventure is an exploration game. It runs on Z80 and 8080 computers with at least 48K of RAM, and comes in versions for the CP/M and HDOS operating systems. In Adventur~, you explore CQlo~sa l_ Cav~, wnere q__thex~ ha~e found fortunes in treasure and gold, though it is rumored that some who enter are never seen again. Magic is said to work in the cave. The computer acts as your eyes and hands. It tells you what you see as you explore. When you wish to do something or go somewhere, you direct the computer to do so with commands of one or two words. For example, to go north from your present location, you would type "go north", or simply "north". When you begin Adventure, you will have the opportunity to ask for instructions. The "help" command gives you some hints; the "info" command tells you how to end or save your adventure. For your convenience, the information printed by those two commands is given below, in Sections 4 and 5.
    [Show full text]
  • CHIME & AEHIS Letter to FDA on “Postmarket Management Of
    & April 21, 2016 Dr. Robert M. Califf, MD Commissioner Food and Drug Administration 5630 Fishers Lane, Rm. 1061 Rockville, MD 20852 Dear Commissioner Califf: The College of Healthcare Information Management Executives (CHIME) and the Association for Executives in Healthcare Information Security (AEHIS) are pleased to submit comments on the Food and Drug Administration’s (FDA) draft, “Postmarket Management of Cybersecurity in Medical Devices,” Docket No. FDA–2015–D–5105, published January 22, 2016. CHIME is an executive organization serving more than 1,800 chief information officers (CIOs) and other senior health information technology leaders at hospitals and clinics across the nation. CHIME members are responsible for the selection and implementation of clinical and business technology systems that are facilitating healthcare transformation. CHIME members are among the nation’s foremost health IT experts including cybersecurity. Within CHIME is AEHIS, an organization launched in 2014 which represents more than 500 chief information security officers and provides education and networking for senior IT security leaders in healthcare. I. Background and Key Recommendations CHIME and AEHIS applaud the FDA for undertaking the important topic of medical device cybersecurity. This draft guidance is intended to consider the cybersecurity issues and risks that occur after a medical device has been implemented into a healthcare delivery organization (HDO). This follows publication of FDA’s “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” guidance in October 2014, which was developed to help manufacturers identify cybersecurity issues when designing their products and preparing for premarket submissions. We are pleased to see the increased focus by the FDA on the critical issues surrounding cybersecurity of medical devices and their impact on patient safety.
    [Show full text]
  • Speeding up Your Heath H-89/90
    Speeding up your Heath H-89/90 Now that you have installed the Z67-IDE, you are probably still 'WOWed' by how much faster it boots and runs with the quick read/write access on the Z67-IDE. WARNING! Speed is addictive! So, now you want to make the processing faster as well. This is rather easy on the H-89/90 computer and requires NO modification to the CPU circuit board. There is a speed modification board that is available from Norberto Collado that simply plugs into a socket and will give you software selectable 2 or 4 mega-hertz operation. By-the-way, you don't have to be running the Z67-IDE to use the Speed Board. It will work just as well for a floppy based system. What's Needed: OK, it is just a bit more complicated than what I just said. You also have to replace the CPU chip with a Z80A (4 MHz) or a Z80B (6 MHz). Occasionally, the installed memory chips aren't fast enough and also have to be replaced with faster chips. The good thing about this modification is that if you install it and it doesn't work because the memory is not fast enough, you simply simply continue to boot and run at 2 MHz just like before without modifying the software. Then, after acquiring faster memory, install the new memory chips and perform the speed test. You should now be now be able to run at 4 MHz. Once the hardware modification is complete, there are still some software changes to be made.
    [Show full text]
  • The Independent Newsletter of Heath Co. Computers Heath® Sets Plans for Higher S·2S" Disk Capacity, P
    #Jl32S Pennsylvania Avenue, S.E. ISSN 0193-6832 Washington, DC 20003 202/ S44-0484 Single copy price: $2 Editor: Charles Floto 12 issues for $r8 ($2s overseas) r8 issues for $2s ($3s overseas) Editorial deadline: January 27, 1981 24 issues for $30 ($4s overseas) The Independent Newsletter of Heath Co. Computers Heath® sets plans for higher S·2S" disk capacity, p. r... $9s HDOS Pascal, p. r... HDOS software for iv1BASIC or HDOS BASIC, p. r... CP/ M software and H89 mass storage from Magnolia, p. r... Program eases single-drive CP/M, p. 2 ... H89 1/0 expansion kit, p. 2... HDOS "Invasion" game, p. 2... HDOS home finance system, p. 2... Heath/ Zenith seen passing Commodore in 1981 sales, p. 3··· New Keyboard Studio products, p. 3··· Super RTTY for HDOS, p. 3··· Single voltage converter for Trionyx H8 RAM, p. 3··· Roy S. Reichert's H89: "almost total silence", p. 4··· HDOS word­ processing for $6o, p. 4··· Osborne BASIC software on cassette and disk, p. 4··· HT -I r XBASIC enhancements, p. 4··· No improvement likely in Heath® support of Hrr, p. S··· CP/M master catalog program and text formatter, p. S··· More on TECO with Hrr, p. S·· · Bob Ryan likes ESCON Selectric interface, p. S··· Cooling the Hr7-3, p. 6... FOR SALE, p. 6... Get 14 more sectors per HDOS S·2S" disk, p. 6... HDOS MBASIC statistics programs, p. 6... Osborne business zoftware for CP/ M & CBASIC 2, p. 6 ... Bilofsky's MYCHESS graphics, INVADERS, CP/M versions, p. 7··· Supplier update, p.
    [Show full text]
  • Timeline of Operating Systems - Wikipedia, the Free Encyclopedia
    Timeline of operating systems - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems From Wikipedia, the free encyclopedia This article presents a timeline of events in the history of computer operating systems from 1951 to 2009. For a narrative explaining the overall developments, see the History of operating systems. Contents 1 1950s 2 1960s 3 1970s 4 1980s 5 1990s 6 2000s 7 See also 7.1 Category links 8 References 9 External links 1950s 1951 LEO I 'Lyons Electronic Office'[1] was the commercial development of EDSAC computing platform, supported by British firm J. Lyons and Co. 1954 MIT's operating system made for UNIVAC 1103[2] 1955 General Motors Operating System made for IBM 701[3] 1956 GM-NAA I/O for IBM 704, based on General Motors Operating System 1957 Atlas Supervisor (Manchester University) (Atlas computer project start) BESYS (Bell Labs), for IBM 7090 and IBM 7094 1958 University of Michigan Executive System (UMES), for IBM 704, 709, and 7090 1959 SHARE Operating System (SOS), based on GM-NAA I/O 1 of 16 2/24/11 9:28 PM Timeline of operating systems - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Timeline_of_operating_systems 1960s 1960 IBSYS (IBM for its 7090 and 7094) 1961 CTSS (MIT's Compatible Time-Sharing System for the IBM 7094) MCP (Burroughs Master Control Program) 1962 Atlas Supervisor (Manchester University) (Atlas computer commissioned) GCOS (GE's General Comprehensive Operating System, originally GECOS, General Electric Comprehensive
    [Show full text]