Forgot your password?
typodupeerror
Open Source Operating Systems Programming Software Apple

Apple II DOS Source Code Released 211

Posted by Soulskill
from the half-the-size-of-the-itunes-EULA dept.
gbooch writes "The Computer History Museum in Mountain View, California, is not just a museum of hardware, but also of software. The Museum has made public such gems as the source code for MacPaint, Photoshop, and APL, and now code from the Apple II. As their site reports: 'With thanks to Paul Laughton, in collaboration with Dr. Bruce Damer, founder and curator of the Digibarn Computer Museum, and with the permission of Apple Inc., we are pleased to make available the 1978 source code of Apple II DOS for non-commercial use. This material is Copyright © 1978 Apple Inc., and may not be reproduced without permission from Apple.'"
This discussion has been archived. No new comments can be posted.

Apple II DOS Source Code Released

Comments Filter:
  • by crow (16139) on Tuesday November 12, 2013 @05:39PM (#45405733) Homepage Journal

    Back in the day, the source code for Atari DOS was included in a published book that explained exactly how it worked. That's one of the things that was great about that platform--so much information was readily available.

    It was all written in 6502 assembly. Anyone that cared would disassemble it themselves, so it's not like there were any big proprietary secrets to protect. I'm surprised that this wasn't published 30 years ago.

  • Re:Legacy Support (Score:5, Informative)

    by stewsters (1406737) on Tuesday November 12, 2013 @05:42PM (#45405763)
    Ask and ye shall receive?
    http://www.virtualapple.org/ [virtualapple.org]
  • by _merlin (160982) on Tuesday November 12, 2013 @05:43PM (#45405769) Homepage Journal

    Actually it does. That's how we track down compiler bugs, and also how we backtrack from crash location to look for the cause when we have a core from an optimised build.

  • Re:Contradictory? (Score:5, Informative)

    by pregister (443318) on Tuesday November 12, 2013 @05:46PM (#45405825)
    Non-commercial uses have permission. Commercial uses don't. You may not reproduce it without permission. Wheres the problem?
  • by viperidaenz (2515578) on Tuesday November 12, 2013 @06:17PM (#45406163)

    8 bits and popular, designed to get people started.
    http://www.arduino.cc/ [arduino.cc]

  • by Anonymous Coward on Tuesday November 12, 2013 @06:40PM (#45406419)

    One of Apple's cheap Macs (the "LC"?) had a single nubus slot that took a special card that allowed you to hook up an Apple 5.25 floppy -- and had a hardware/software Apple // emulator.

    These days, no mac supports any kind of floppy, even via USB -- you'd have to download disk image files to get to the software.

    It was a Processor Direct Slot (PDS), and most of the LC line supported it IIRC (up to at least the 68040-based LC 575 -- the original LC was built around the 68020). Had an Apple IIe SoC. http://apple2online.com/web_documents/apple_iie_card_owner__s_guide.pdf [apple2online.com]

    You can still use USB floppy drives with modern Macs; I recently retrieved some files off of 3.5" disks on my Core i5 MacBook Air (2013 edition, the one right before the current Haswell version)...

  • Disassembly (Score:5, Informative)

    by tepples (727027) <tepples@nOSpAM.gmail.com> on Tuesday November 12, 2013 @06:52PM (#45406559) Homepage Journal

    Have you considered the possibility that Apple simply wouldn't release the source code at all, if there were no copyright protection?

    To keep companies from "hoarding," as you put it, would require a sort of negative copyright, where they are forced to escrow their source code for public release

    I don't see why escrow would be so critical when someone with more time than money could just disassemble, document, and distribute a program. This already happens underground [romhacking.net]. Absent copyright enforcement, there would simply be no formal negative consequences for doing so.

    If you don't like it, you'll have to rely on trade secrecy instead.

    You'd have to keep the binary secret too in order to thwart a disassembly attack. Good luck keeping a binary secret from end users who who run it on hardware that they own. The sort of DRM seen in, say, game consoles has always failed within a few years.

  • Re:Legacy Support (Score:5, Informative)

    by tlhIngan (30335) <(ten.frow) (ta) (todhsals)> on Tuesday November 12, 2013 @07:15PM (#45406743)

    Meh... While I can see the value, this is exactly the problem that Windows is stuck in. Although they aren't completely backwards compatible, they try to be backwards compatible for a lot of stuff, which means they have to hold on to libraries which are poorly designed, and in some cases incorrect implementations because so much software depends on the incorrect implementation. MacOS is much cleaner because it has maintained less backwards compatibility. If you want to run old software, do it in a virtual machine, and allow the OS itself to evolve and drop the baggage of keeping the compatibility. Not to say that everything should be changed every OS iteration, but there needs to be a process for getting rid of the cruft.

    No what happens is that Windows has to work around everyone else's bugs - a lot of nasty developers don't do things the proper way and Windows suffers. It's why "C:\Documents and Settings" exists still on Windows Vista/7/8 - too many developers hard code that string (including the "C:\" part!) that not having that hard link means programs break.

    Apple decided to take the other method - basically dictating that if you do not use just the published APIs, your programs will probably break. Yes, you can use private APIs. But as per the warning, Apple has full right to change the private APIs as they see fit.

    Which is better? There's no consensus - Microsoft's means your programs still working, crappy coding and all, but you have to live with the fact that you still have a window named "Program Manager", that if you use a localized version of Windows, you'll eventually have a "Program Files" folder show up (yes, it's localized) because some program hard coded it, etc.

    Apple's means a leaner system because all these hacks don't need to exist - private APIs are not fixed in stone but can change and be updated as time goes on and deleted when necessary, rather than having to hang around because some app uses it.

  • by NormalVisual (565491) on Tuesday November 12, 2013 @07:24PM (#45406841)
    Seriously? 6502's and punched-cards together? What a wretched anachronism.

    FTA: “DOS was written on punch cards. I would actually hand-write the code on 80-column punch card sheets. A guy at Shepardson named Mike Peters would take those sheets and punch the cards. The punch cards would then be read into a National Semiconductor IMP-16 and assembled, and a paper tape produced. The paper tape was read into the Apple II by a plug-in card made by Wozniak, and I would proceed to debug it. As the project got further along and the code was all written, and it was debugging and updating, I would mark up a listing and give it to Mike Peters who would then change whatever was necessary and deliver me a paper tape and I’d start again.”
  • by Dogtanian (588974) on Tuesday November 12, 2013 @08:27PM (#45407505) Homepage

    Back in the day, the source code for Atari DOS was included in a published book that explained exactly how it worked. That's one of the things that was great about that platform--so much information was readily available.

    Yes, but possibly in spite of, rather then because of, Atari themselves. According to the book "Hackers" by Steven Levy, the Atari 800 was treated as a closed platform in the early days, and Atari wouldn't divulge documentation on its inner workings;

    Transferring his new assembly-language skills to the Atari was difficult. The Atari was a "closed machine". This meant that Atari sequestered the information concerning the specific results you got by using microprocessor assembly-language commands. It was as if Atari did not want you to be able to write on it. It was the antithesis of the Hacker Ethic. John would write Atari's people and even call them on the telephone with questions; the voices on the phone would be cold, bearing no help. John figured Atari was acting that way to suppress any competition to its own software division. This was not a good reason at all to close your machine. (Say what you would about Apple, the machine was "open", its secrets available to all and sundry). So John was left to ponder the Atari's mysteries, wondering why Atari technicians told him that the 800 gave you only four colors in the graphics mode, while on the software they released for it, games like "basketball" and "Super Breakout", there were clearly more than eight colors.

    Of course, it's true that all this stuff was *later* very well-documented, but how much Atari helped in that is open to question (*). It's certainly well-known that Atari were assholes in general in their late-70s/early-80s heyday, and they definitely tried to suppress third-party development of VCS games. So though I've heard enough people disputing aspects of "Hackers" not to take it as gospel, it does seem to tie in with what I've heard about Atari at the time.

    The Atari DOS [atariarchives.org] book doesn't appear to have been published by Atari themselves, and whether it was with their blessing, I don't know. "Mapping the Atari" wasn't an official publication either.

    While Atari released documentation, I suspect it was at the level *they* wanted people to be using the machine at. And for all their plus points, the 400 and 800 were clearly intended as more closed, consumer-oriented machines. The 800 did have some good expansion capabilities, but this was clearly meant to be done via its official ports and interfaces designed for that use. The lower-end version, the Atari 400 had far less official expansion capability, e.g. it was never originally designed to support RAM expansion- it was possible, but apparently required far less friendly hardware modifications and installation directly onto the motherboard.

    The 1200XL was notoriously even more closed (and flopped massively). FWIW, the BASIC "manual" that came with my 800XL was a paltry pamphlet, and the official DOS 3 manual was nicely-presented, but certainly not deep.

    Of course, it all worked out in the end, but I guess what I'm saying is that let's not romanticise the original intentions of companies like Atari back then, who'd have been happy to sit on those secrets and not release them to their users (who they viewed as potential competition).

    (*) Those early days (1979 onwards) were before my time- I got my 800XL in 1986, so I can't speak from personal experience.

In every non-trivial program there is at least one bug.

Working...