Slashdot Mirror
Apple II DOS Source Code Released
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.'"
Whatever your complaints about your job, at least debugging your code doesn't involve stepping through assembly on a pencil and paper virtual machine.
It's being "made available" but it "may not be reproduced."
How does that work, again?
If you're a zombie and you know it, bite your friend!
You never know... I'm not sure how far back in time Microsoft goes to rip off Apple; they do always seem to be pretty late to the party.
Because it could be a competent competitor to current Apple products?
I know I want an Apple II smartphone that I could play Oregon Trail on and make phone calls back to the '70s with!
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
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.
Lately it has become common for companies that own copyright in decades-old video games to rerelease the games in an emulator that runs on a modern platform. If a video game for Apple II requires Apple DOS, the game's copyright owner has two options. It can license Apple DOS in order to distribute it as part of the game's disk image bundled with the emulator. Or it can change the emulator to use high-level emulation for the BASIC integration, file system, and RWTS (block device driver) that make up Apple DOS.
Ask and ye shall receive?
http://www.virtualapple.org/
Can someone please transcribe this into 6502 binary instructions and place it onto punch cards for easier reading?
", I just wish there was a popular 8-bit machine out there for the young'ns to get them started.
That's like saying people need to learn to drive on a model T.
My kids had no problem getting started on modern hardware.
The Kruger Dunning explains most post on
Whatever your complaints about your job, at least debugging your code doesn't involve stepping through assembly on a pencil and paper virtual machine.
Back then it was actually easier to read through large amounts of code, flipping between different sections, etc when it was on paper.
...
The listing wasn't used for paper and pencil emulation, we had quite nice integrated editors and debuggers to see what was going on (ex. the LISA 6502 assembler). The listings were for reading and understanding. These lists were used somewhat like tablets today. You can take the listing anywhere, flop down on the couch and start reading,
8 bits and popular, designed to get people started.
http://www.arduino.cc/
Some sort of virtual machine is the correct way to do legacy support. In some cases full virtualization is the answer, in others, a thinner layer that looks like the old OS to the application and like a modern app to the outer OS might be more appropriate.
The MS approach of keeping the severely broken APIs around forever is NOT the answer.
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. 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.
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.
Well, that was written before the line feed shortage. Things were different back then.
Do you even lift?
These aren't the 'roids you're looking for.
It's really not that bad, although 6502 assembly was (for me, anyway) more challenging than 68K because the 6502 didn't have many registers to work with. You just have to decompose the problem down another level, and as long as you're paying reasonable attention to detail, it's really not that much worse than writing something in C.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
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 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.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).