Publikálták az Apple II DOS forráskódját

Apple

A Computer History Museum (CHM) a napokban bejelentette, hogy együttműködésben a Digibarn Computer Museum intézménnyel, az eredeti szerzővel, Paul Laughton-nel és az Apple engedélyével publikálta az Apple II DOS eredeti, 1978-as forráskódját.

Az Apple II-nek kezdetben volt egy gyenge pontja: nem volt lemezmeghajtója. A programokat és adatokat szalagos meghajtón kellett tárolni, arról kellett betölteni. Ez elég lassú és megbízhatatlan megoldás volt. Az Apple problémája az volt, hogy a lemezek - akár a hajlékony lemezek (floppy-k) is - drága, és komplex vezérlőszoftverrel rendelkező meghajtókat igényeltek.

Steve Wozniak (Woz) megoldotta az egyik problémát. Egy hihetetlenül ügyes floppylemez-meghajtó vezérlést tervezett mindössze 8 integrált áramkör felhasználásával. Woz és Randy Wigginton egy kezdetleges vezérlőszoftvert is készített hozzá és az egészet bemutatták 1978. januárjában a Consumer Electronics Show-n.

Disk vezérlő

A kérdés az volt, hogy honnan szereznek majd olyan komolyabb vezérlőszoftvert, amellyel megfelelően tárolni és kezelni tudják majd a lemezen a programokat és adatokat. Abban az időben az Apple-nek mindössze kb. 15 alkalmazottja volt és egyiknek sem volt tudása, vagy ideje arra, hogy a szoftvert megírja.

A "varázsló", aki végül a problémát megoldotta, Paul Laughton volt, aki szerződéses programozóként dolgozott annál a Shepardson Microsystems-nél, amely ugyanabban a Cupertino-i irodaparkban volt helyileg, mint az Apple.

1978. április 10-én Bob Shepardson és Steve Jobs aláírtak egy 13 ezer dollárról szóló egyoldalas szerződést, amelynek értelmében az Apple egy fájlkezelőt, segédprogramokat és egy BASIC interpreter-t kap. A határidő május 15. volt, ami rettentő szorosnak látszott. Ennek ellenére 1978. júniusában az "Apple II DOS version 3.1" megjelent.

Apple II DOS

A forráskód felhasználható nem kereskedelmi céllal. Az anyag a "Copyright © 1978 Apple Inc." szerzői jogi megjegyzést viseli, azt az Apple engedélye nélkül nem lehet újra kiadni, kereskedelmileg felhasználni stb.

A részletek itt olvashatók.

( Zahy v | 2013. 11. 16., szo – 11:03 )

(Nem olvastam el az eredeti cikket.) Azért 13000 dollár '78-ban nem kevés pénz volt egy 1 (de fentiek alapján max 2) hónapos munkáért. Azt mondanám, Jobs abban a boldog tudatban írta alá, hogy ő mindent megtett, de ez a pénz "szerencsére" a zsebében marad. Szerencsére nem maradt.

Szerintem nem, ugyanis rossz oldalrol kozelited meg. '78-ban a szoftverek komplexitasa toredeke sem volt a mainak, igy egy-egy jobb programozo siman osszetudta hozni ennyi ido alatt azt a kodot, plane ha megfeleloen motivaltak. Mondjuk 13 ezer dollarral es egy jo kihivassal, Jobs valoszinuleg ezt felismerte es meglepte azert, h a sajat celjait elerje. Klasszikus win-win szituacio.

---
pontscho / fresh!mindworkz

Ez igy nem teljesen igaz. Ugyan nyilvan nem X gigabyte volt, amde altalaban full assembly, sokszor a celgepen kodolva (nem am kenyelmes IDE-kben ...). Az is szokott eljaras volt, hogy "kis" hiba eseten kozvetlenul binarisban patcheltek, meg hasonlo dolgok. De OK, irjal mar 65xx assemblyben egy BASIC interpretert csak ennyi ido alatt :) Raadasul a scope is mas volt: mai programozok koncentralhatnak arra, hogy "szepen" legyen megoldva a feladat, akkoriban az volt a cel, hogy elferjen az adott ROM-ban, disken, stb, es gyors legyen, akar olyan trukkoket is bevezetve (felaldozva kb barmi mas szempontot, nem lehetett azt mondani mint mai, hogy "4G memoria ma mar alap, ocsem" meg hasonlok), amit mai programozok nem is ismernek, vagy pedig felallna tole a szor a hatukon mindenesetre.

A mai software-ek komplexitasa sok esetben azert nagy, mert tul nagy az absztrakcios szint a programozo es az ISA kozott. :)

Nem lattam :) Csak arra reagaltam, hogy szerinted a software-ek komplexitasa akkor kisebb volt, ezert mindenkeppen joval egyszerubb volt anno a dolog, mint manapsag. En epp a forditottjat velem sokszor felfedezni, ma mar minden r=1 user is programozonak nevezi magat, aki PHP-ben leirt egy kacsacsort valaha is, anno azert ennel komolyabb hozzaallas volt szukseges :) Meg ha egy kepzett pl Java/akarki programozot nezel, sokszor neki sincs fogalma, mit csinal a processzor, mekkora lesz a kod, es hogy ezt akar ezredannyi eroforrassal is meg lehetne irni, csak ma mar nem erdemes (lasd; RAD, mai hw-k kepessegei stb). Anno meg 2 hetig azon ment a gondolkodas, hogy lehet X byte-al csokkenteni a kod meretet, vagy par orajelciklust megsporolni. A mai programozok tobbsege kegyetlenul elverezne ezeken a dolgokon erzesem szerint :)

Mindenestre hiaba latszik - most raneztem kozben - rovidnek a mellekelt forras (okulva barmi hasonlo anyag assembly forraskod/listing szintu meretbol), hidd el, hogy nem olyan trivialis ez. Azt hogy akar te is tudnal ilyet: OK, lassuk. Tenyleg erdekelne, mert azert irtam ezt-azt 6502 assemblyben, neha meg most is elofordul. Sot mintha maga Woz is ugy nyilatkozna, hogy minden elismerese, pedig megsaccolom, hogy nalad es nalam is jobban programozik/-ott 65xx assemblyben ...

Azt fontos azert latni, hogy pont az a szep ebben, hogy akar par byte-nyi gepi kodban is lehet akar tobb het (!) munka is extrem optimalizacios stb kitetelekben, lasd pl 256 byte introkat erdemes megnezni neha C64-re, de nyilvan 1K is erdekes. A mellekelt egyik pdf-t nezve ez kb 10K-nyi kod lehet leforditva (ok, adattal egyutt ami benne van) - ez ebben a mufajban mar nagyon komolynak szamit! -, szoval en siman elismerem hogy ezt nem lehetett egyszeru ennyi ido alatt megoldani.

Viszont, ha szerveznenk ujabb meetinget mint a "multkor" Aprinal, akkor errol is elbeszelgethetnenk ujra szemelyesen is, a stringkezelesi modszerekrol nem is szolva! :-)

Bár biztos képben vagy, nick és group név az aláírásban, de ettől a végleges program sorainak a száma nem biztos egyenes arányba állítható az idővel. Tehát ha megnézel egy végleges programlistát, nem biztos, hogy a fejlesztési idő ebből kikövetkeztethető. Gondolom esetedben sem egyenesen arányos a fejlesztési idő a kész program soraival.

"Belépés díjtalan, kilépés bizonytalan."

Ezek kozul egyiket sem allitottam. Hanem csak annyit, h leven a programok komplexitasa toredeke sem volt a mainak, igy realis esely volt megoldani a problemat a jelzett idokereten belul, csak megfelelo motivacio kerdese volt, ami 13k usd, egy deadline es egy megfelelo problema szemelyeben meg is erkezett.

Es igen, van kozvetlen tapasztalatom mindegyikkel kapcsolatban, ha ohajtod egyszer egy sor mellett elmeselem hogyan estem darabokra az elso 4k-m utan, mert kicsit szoros volt a deadline meg kozel 40 ora folyamatos kodolas utan is. i386 asm-ben, nem c-ben, nem letezett sem a crinkler, sem a ma hasznalt minimalista c env es az exe packerek minosege sem merheto a maiakkal. Mikepp jott ossze 900 byte-ban egy xm player es a hozza tartozo sample generator, a textura generatorok a kovetkezo nehany szaz bajtban, stbstb.

Amugy olyasmin vitatkoztok, ami ma mar tortenelem es a fenti cikkbol is kiderul, h a faszinak osszejott. Tehat Jobs jol merte fel a lehetosegeket.

---
pontscho / fresh!mindworkz

"Vitatkoztok?" Te emlitetted eloszor, hogy ez nem nagy szam, akar te is megcsinalnad (-tad volna) hasonlo korulmenyek kozott :) Erre irtam, hogy szerintem azert ez rosszul latod. Masreszt mar pl egy atlag 286-os PC is, assembly nyelven teljesen mas feeling mint egy 1MHz koruli 65xx CPU (tapasztalatbol is mondhatom persze x86 es 65xx kapcsan is). Nagyon sok szempontbol mas, de ez mar tenyleg messzire vezetne itt.

Nem is erdekes, igazabol a lenyeg csupan az, hogy nem ertek egyet azon kijelenteseddel hogy ezt kb barki megcsinalhatta volna az adott ido alatt, ha van motivacio. A komplexitas meg egy dolog, amennyivel "egyszerubb" lehetett egy sw (bar nehany esetben ez is kerdeses lehet akar ...), annyival nehezebb volt a fejlesztese es annak korulmenyei, ami atlagban SZVSZ meg at is billenti a merleg nyelvet sokszor ...

Öööö, a figyelemmel követés talán túlzás, inkább egy összkép alakult ki az évek folyamán, de amit láttam, arra viszont ÁLTALÁBAN igaz volt. Abban az értelemben biztosan felületes, hogy nem néztem végig az összes hozzászólásod a HUP-on.

"Belépés díjtalan, kilépés bizonytalan."

A programok komplexitása lehet töredéke sem volt a mainak, de ez minden másra is igaz volt (programozói környezet, gépek és tárolók sebessége, fejlettsége, hibakeresés lehetősége, stb.). Feltételezem ez mind befolyásolja a fejlesztés sebességét.

Magam is programoztam már assemblyben néhány architektúra alatt az általad említett környezetben, talán inkább hiányában, így bár kedves a felajánlás, de van saját tapasztalatom is, kösz. Sör ettől függetlenül még persze mehet, ha úgy hozza az élet.

Szerintem azon nem vitatkozunk, hogy összejött.

"Belépés díjtalan, kilépés bizonytalan."

Így van, sőt még lyukkártyán is - ezt írja a cikk:

"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."

Teljesen igazad van mindabban amit írtál! Tapasztalatból beszélek én is. 6510-es proci. Az öreg C-64, meg a floppy egysége... Na arra írtam én a néhányszor már emlegetett programnyelvemet/oprendszeremet (szerintem inkább programnyelv volt, de azon a masinán a kettő nem különült el élesen). Emlékszem, kb 14 K volt a mérete. A binárisnak. Forrás, na olyan meg nem is volt hozzá. Közvetlenül a memóriába pötyögtem, a RatMon64 nevű úgynevezett "monitorprogrammal". Persze nem a bináris kódot, hanem olyasféle mnemonikokat holgy mondjuk (csak a hasamra ütök):

lda $0002
tax
ldy #$00
lda ($fb),y
cmp $c800,x
bne $c120
inx
iny
cpy $fe
bne $c10e
rts

Itt az ugrási címeket hasból írtam, a $c120-nak szándékaim szerint az "rts" sor utánra illenék mutatni, a $c10e-nek pedig az lda ($fb),y sorra. E rész most írtam egy laza csuklómozdulattal fejből, poénból. Elvileg ez két memóriatartományt hasonlít össze bájtonként. Régi szép idők! Nosztalgiám van...

És igen, ott nemegyszer volt úgy, hogy igencsak gondolkodni kellett azon, hogyan tudnék mindössze akár 2 bájtot megspórolni valahol... Vagy ugye a sebesség kérdése. Pláne ha a megszakításrendszerre kötöttem egy rutint. Cseppet se volt mindegy, mennyi időt totojázik el minden másodpercben kb hatvanszor... De még ez is egész istenes volt ahhoz képest, amikor attól függött minden, az elektronsugár mennyi idő alatt ér el az adott sorhoz a monitoron, ez ugye adott volt, tehát muszáj volt belezsúfolni MINDEN tevékenységet abba a szűk idősávba amíg oda visszaér az elektronsugár!

És állítom nektek, AZOK voltak az igazi idők, az adta a szakma igazi szépségét, olyat, ami manapság már a legtöbb helyen kiveszett! A mai programozók többsége szerintem egyszerűen nem tud programozni. Mármint a "Nagy Öregekhez" képest... Behányja a kódot, aztán majd a compiler megcsócsálja és kiköp valamit. Ha fut, oké, le van szarva hány gigabájt meg milyen lassú! Vegyen hozzá a looser júzer nagyobb erőművet: még 64 processzormagot, 2 terás merevlemezt, fél terás RAM-ot... Úgyse tudja hogy beleférhetett volna az egész 2 megabájtba is!

Nem, a mai nemzedéknek fingja sincs arról, a kódja mivé fordul le végül. És nem is érdekli. Ez a legszomorúbb.
-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről
=== Sabayon disztró, DWM ablakkezelő ===

Amig a szoftvert mastol veszed mint a hardvert addig bizony igy van. Ha a szoftvert a hardverrel kapod akkor picit jobb a helyzet, mert meg lesz oldva, hogy az adott eszkozon elfogadhatoan mukodjon. Ha viszont a szoftvert attol veszed akitol a hardvert is, de mint kulon termeket, na akkor biztos, hogy ket frissites utan hardvert is kell majd bovitened. ;)

+1

Nagyon igazad van! Csak, sajnos, ez egy roppantmód szomorú igazság... :(

Bár, azért annyira nagyon engem szerencsére ez nem érint. Meg szinte senkit se aki CSAK Linuxot használ. Természetesen itt is baj hogy többnyire leszarják az optimalizációt a programozók, meg ugye van az is hogy egyes eszközök specifikációit a gyártók nem adják ki, s így a linuxos driverek hatékonysága nem akkora mint lehetne amúgy, de legalább arról sincs szó hogy fizetünk sokat a szar programokért.
-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről
=== Sabayon disztró, DWM ablakkezelő ===

( joco01 v | 2013. 11. 16., szo – 12:16 )

Annyira fájna a marketwatch-nak linkeket használnia?

--

( artifex | 2013. 11. 16., szo – 19:13 )

http://aurir.wordpress.com/2013/11/14/steve-wozniaks-response-to-the-op…

"The MOST AMAZING code of my life…I could never do anything close to this much ‘out of any box’ stuff ever again…it was as amazing to come up with it as it seems to be reading my code. In some places I put numbers like (5) meaning that 5 cycles would be taken by that instruction – I had to count them all so the loops always sent a byte to the controller every 32 microseconds exactly. And there is no way to explain the 5-bit and 7-bit stuff but it extended the data from 13 sectors to 16 sectors. The 13-sector version was running in Las Vegas. The improvement to this 16-sector code is the part that I worked on every night for a month, nearly finishing each night around 2 AM (Denny’s milkshake) but repeating the whole process the next day because I had to keep getting the entire huge framework in my head each day. Finally I stayed one night until 6:30 AM and got it totally done. Jobs had been asking me every day when it would be done and that morning I told him that it was! This part of the low-level disk code was not Randy’s but I am so thankful for the parts he did so well too that made higher level sense out of this. I consider this code to be more like hardware than software."

"Belépés díjtalan, kilépés bizonytalan."

( tordai_hasadek | 2013. 11. 16., szo – 22:44 )

En mondjuk e tudtam volna vinni 6 ic-re is a kapcsolast ranezesre, de latni kellene ahhoz a kapcsolasi rajzot minimum.
De a 7405 minimum szamuzheto lehetne.
Nem publikus valahol?

Szerintem azért látatlanba kicsit erős kijelentés.
A 7405-nek elég sokféle - nem elhagyható - szerepe lehet.
Pl lehet, vonalmeghajtó, vagy analóg jelből digitális jelszint regeneráló funkciója. Esetleg valami nagyon "igénytelen" időzítő, illetve oszcillátor is csinálható belőle, bár ahhoz inkább a schmitt-triggeres változat jó.
---
Régóta vágyok én, az androidok mezonkincsére már!

( Joejszaka v | 2013. 11. 17., v – 13:36 )

+1.
13K mai ertekert akarmit megirok 2 honap alatt.

( ricsip v | 2013. 11. 18., h – 10:17 )

Nosztalgián kívül van ennek bármi gyakorlati haszna ma 2013-ban, 35 évvel később? A technika (floppi dsizkek) már rég kifutott, az átlag mai hobbi-OSek is fényévekkel túlhaladták az akkori állapotokat.