Oprendszer írása.... hol kezdjem?

Egyéb: Assembly, Ada...

Sziasztok!

Hol találhatok olyan leírásokat, hogy hogyan tanulhatunk meg rendszerindítót írni (és azt az MBR-be írni), egér, billentyűzet kezelést, képernyőre tartalmat küldeni (videó-memóriába), primitív fájlrendszer létrehozása és fájlkezelést, programok futtatásának lehetőségét? Szóval egy oprendszert szeretnék írni, tanulás céljából. :) Gondolom bőven nem elég Agárdi Gábor Gyakorlati Assembly könyvének a bújása :) Annyi mindenki ír már manapság saját rendszert, hogy megelégeltem és én is akarok egyet :) Az iskola ilyenekre nem tanított meg :)

Köszi.

  • 13492 megtekintés

( sunmao v | 2010. 12. 18., szo – 22:39 )

Javaslom e rendszer tanulmányozását és a hozzá tartozó könyvet.

( uid_16401 | 2010. 12. 18., szo – 22:45 )

Azt javaslom mikrokernelt csinálj!

Egyiknek ez másiknak az az előnye (a monolit gyorsabb, a mikro pedig rugalmasabban használható). Szerintem pedig tanulás céljából jobban jár ha monolitot ír. Sokkal gyorsabban lehet vele haladni, és ha benézte a mikrokernel felépítésést, akkor íratja át az egészet.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( bambano | 2010. 12. 18., szo – 22:47 )

Keresd meg egy Douglas E. Comer nevű író Xinu-ról szóló könyveit.
nem, nem xenu, az egy másik műfaj:)

( florariz | 2010. 12. 18., szo – 23:03 )

esetleg

Horváth Gábor: Bepillantás az operációs rendszerek világába (LSI, 2000)

"dr. Kovács Magda: 32-bites mikroprocesszorok I-II LSI"

Na ez egy nagyon gagyi könyv, gyakorlatilag a lényegi része az Intel kézikönyv igénytelen fordítása és összeollózása. Nagyon sok hibát tartalmaz, és az LSI hibajegyzéket nem adott ki hozzá.
Ezek a könyvek még akkor készültek amikor a szerzőket mennyiségre (ívekre) fizették nem pedig minőséget követeltek meg. A szerző a Gábor Dénes legrosszabb hírű "főiskola" alapítója volt, nem volt igazán szakember már az életkora miatt sem. Amúgy sok szempontból már ósdi az architectúra amivel foglalkozik (i386). Az LSI könyvek általában a gagyi kategoriába tartoznak, elmesélő stílusú a nagyközönségnek szánt kilóra összeollózott könyvek.
Érdemes az eredeti Intel dokumentációkat beszerezni, és azokból dolgozni.

Na ez egy nagyon gagyi könyv, gyakorlatilag a lényegi része az Intel kézikönyv igénytelen fordítása és összeollózása.

+1

Én akkor tettem le, amikor az egyik (magyarul értelmetlen) félretükörfordított mondat értelmét sikeresen dekódoltam azzal a módszerrel, hogy a magyar mondatot visszatükörfordítottam angolra (kb. mit írhatott az eredeti író, amit erre tükörfordíhattak), majd immáron az angol eredeti mondatból megértettem, hogy mit is akarnak mondani.

( kikke | 2010. 12. 18., szo – 23:33 )

Írj WPA2 támogatást Haikuba, vagy javascript alapú flash plugint és király leszel. Nagyon dudva muhar.

( Fisher v | 2010. 12. 18., szo – 23:53 )

http://superfrink.net/athenaeum/OS-FAQ/os-faq.html

Szemre ez jó kiindulási alap (google: "how to write my own operating system", első találat, 0,15 sec), bár némely kérdésed - "hogyan tanulhatunk meg rendszerindítót írni" - nekem azt jelzi, hogy kissé nagy fába vágod a fejszédet.

( tomi66 | 2010. 12. 19., v – 00:32 )

Valóban nem elég az agárdi könyv. Kell mellé a Pethő féle és a Norton féle. Utána már csak gondolkodni kell. Ja, ha még a boot-on kívül mást is akarsz, akkor pár év olvasgatás kell és persze még pár tucat könyv. Előbb ess át az első három könyvön.

+1
Pethő Ádám IBM PC/XT sorozatát érdemes olvasgatni, főleg a "ROM BIOS és ami mögötte van" c. könyvet. Az Internet előtti időkben sokan csak bibliának tartották.

Peter Norton Assembly könyve sem kutya, főleg azzal a szerény indítással, hogy közvetlenül a memóriába beírat az emberrel egy rövidke hexdump-ot (DOS debug-ot használva), amiről később kiderül, hogy egy komplett futtatható program.

Erről jut eszembe, ha OS írás előtt nem árt egy kicsit real módú környezetben, pl. DOS-ban edzeni rá. Virtualizálás nélkül a legfincsibb, úgy érezni igazán, mint is jelent megfagyasztani a vasat egy félrecsúszott megszakításkezelővel.

( asch v | 2010. 12. 19., v – 04:12 )

Inkább definiálj egy virtuális gépet - mint a Java, vagy a .NET - , valósítsd meg mondjuk Linux felett, és írj arra oprendszert.

( kisbetu v | 2010. 12. 19., v – 09:25 )

"Annyi mindenki ír már manapság saját rendszert, hogy megelégeltem és én is akarok egyet :) Az iskola ilyenekre nem tanított meg :)"

Nem tudom, ki mindenki ír manapság salyát rendszert, remélem, nem az ubuntu-remasterekre gondolsz, mert ugyanis azokban egyetlen salyát "írás" nincsen.

Ellenben tegnap mindenki salyát honlapot csinált. Te is.
Ha ugyanilyen kitartó leszel az "oprendszereddel" is, akkor bele se vágj.

Ettől függetlenül egy egyszerű magyar szó leírása nehézségeket jelent ... lehet az 5 év, 8 év, akármennyi azért a "saját" az elég alap már meg ne haragudj.

--
When your mind is empty of prejudices you can see the Tao.
When your heart is empty of desires you can follow the Tao.

Látod, kapsz itt hideget is, meleget is. Hideget azért, mert végletekig naivan állsz a témához, ez az öregrókák számára már-már írritálóan nagyképűnek tűnhet. Meleget meg azért, mert ezek a rókák itt mit nem adnának azért, ha lenne pár évük csak arra, hogy saját oprendszert írjanak.

MysteryKe, a fönt említett Minix könyv elmondhatatlan örömöt okozott nekem évekkel ezelőtt. Azután a The Linux kernel book-ot faltam nagy élvezettel. Ilyeneket a neten is találsz, sőt, kifejezetten híres fejlesztőktől is elcsíphetsz néhány érdekes olvasnivalót: http://kernelbook.sourceforge.net/

Én ugyan oprendszert csak érteni akartam, írni nem, de kezdetnek a linux boot loadert piszkálgattam, képzeld, megsúgom, hogy a floppy.c-t még ki is nyomtattam, és filctollal bejelölgettem (csak hogy mosolyt csaljak most itt mindenki szemébe ;-). Nyilván semmi értelme se volt. De tudod mit MysteryKe, rohadt jól szórakoztam közben. Nem is tudod, micsoda kaland előtt állsz, komolyan.

Figyelj csak, ne tököld el itt az idődet hülye kérdésekkel, hanem húzzál gyorsan olvasni. ;-)

Szerk.: Úgy értem, ne gondolj bele, hogy mekkora fába vágod a fejszéd, hanem hajrá!

a "végletekig" kicsi túlzást, tudom, hogy hosszú-hosszú éveken át tartó kemény, verejtékes, sziklakemény tanulás szükséges eme tudáshoz. Valamennyi naívság szükséges is hozzá, hogy el tudja kezdeni az ember. Valahol meg el kell kezdeni :) én tényleg csak tanulás céljából szeretném ezeket megtanulni. Nem is 2 éve alatt szeretném ezt megvalósítani.

Köszi a könyveket, ma szinte nem is csináltam mást, mint Assembly könyvek után gugliztam.

Nekem úgy megy a legkönnyebben a "megértés", ha azt gyakorolni is tudom. Ezért szeretem jobban a gyakorlati órákat is a suliban. Szeretem a kalandokat, de ahhoz tényleg kell naívság. Ha az embert már előre elrettentik, nem igazán lesznek ambíciói. Tehát nem rettentem el :) Tudom, hogy "mi' fán terem" a PC :) (Nagyjából :) buszok, IRQ megszakítások, memória címzés (offset:szegmens), hardvercimzés, processzor utasítások, fájlrendszer létrehozása (sáv-, szektor- és cluster-kezelés)), illetve perifériák vezérlése.)
nem gondoltam semmilyen a "köz" által is használható rendszert készíteni (így pl. hálózatba nem is folynék bele.)
Ami talán a legnehezebb lenne, az a driver írása lenne. Pl.

Az én terveim szerint is az olvasás volt az első :)

szerk.: aztán majd ha lesz ezekről sejtésem, akkor biztos egy már meglévő és sokak által használt kernelre építeném a rendszeremet

> Ami talán a legnehezebb lenne, az a driver írása lenne. Pl.

Nem tudom pontosan milyen driverre gondoltál most, meg ez erősen függ a hardver ismeretétől, dokumentáltságától is, de egy meglévő oprendszerhez megírni egy drivert, általában az egyszerűbb feladatok közé tartozik.

( taxy | 2010. 12. 19., v – 10:25 )

Védett módú oprendszeres könyvek.
Grub+multiboot kompatibilitás+védett módba kapcsolás+deszkriptor táblák+megszakítások+privilégium szintek+amit csak akarsz.

( ironcat | 2010. 12. 19., v – 10:32 )

Röviden és tömören: Tanulmányoznám az oprendszerrel szemben támasztott követelményeket, a most létező operációs rendszerek felépítését, működését. Választanék egy szimpatikus utat, és nekiállnék a megvalósításnak. Ha egyik út sem nyerte meg a tetszésemet, akkor kitalálnék egy új felépítést.
Bármelyik úton indulsz el, tedd szabaddá magad az elkövetkező néhány évre. Ha nem akarsz ennyi időt rászánni, akkor nem érdemes belekezdeni. Ha olyat akarsz írni, amit mások is használnak, akkor inkább egy vagy több évtizedben gondolkodj.

-----
"Guglizni csak pontosan, szépen, ahogy a csillag megy az égen, úgy érdemes.""

( agolon | 2010. 12. 19., v – 10:42 )

Elsőre azt hittem fun rovat.
--
2e845cb4c3a5b5bd6508455b1739a8a2

( dajkap | 2010. 12. 19., v – 10:45 )

Előre szólok, hogy kicsit hosszú és szubjektív lesz a folytatás ;)

Pár évvel ezelőtt én is próbáltam oprendszert írni. Egészen addig jutottam, hogy bebootolt a "rendszer" és ment egy egyszerű kontext switch (3 kód futott egyszerre). Mindez több hónapot vitt el az életemből, és egy bizonyos fokú látásmód változáson túl semmilyen használható tudásra nem tettem szert :(
Az egész nem szólt másról, mint órákon át a doksikat bújni, neten megoldásokat keresni, majd begépelni 2 sort. Minimális programozói vénával bárki, akinek végtelen sok szabadideje van, tud oprendszert írni.

Megpróbálom pontokba szedni a tapasztalataimat a teljesség igénye nélkül:
- olvasnivalók:
* a legfontosabb az Intel Pentium saját kézikönyve, ahol teljes részletességgel leírja hardver programozását
* Tanenbaum-féle oprendszerek könyv (Minix forráskóddal)
* olyan ASM könyv ahol az utasítások, azok gépi kódja részletesen le van írva, a programozástechnika mellékes
* célszerű még egy-két magyar nyelvű ASM, Pentium procis könyv beszerzése (pl. Agárdi G. könyvek:)
* Linux kernel (nagyon tanulságos!)

- kell egy VM (én bochs-t használtam)
- 1. lépés: írj boot sectort, ami betölt egy további programkódot lemezről (nincs fájlrendszer)
- első lépésnek szerintem csak védett módba érdemes kapcsolni a procit, és az 1000 féle kiegészítést (MMX, anyámtyúkja funkciókat) hanyagolni.
- az első verzióban ne törekedj szép kódra, optimalizálásra, csak a működésre, mert később töredék idő alatt meg lehet oldani
- az intel processzorok 386 módban nem a legkifinomultabbak (a visszafelé kompatibilitás miatt furcsa "okosságok" vannak benne), az új, 64 bites módokhoz nem volt szerencsém
- az intel procik saját oprendszerrel való használati lehetősége eléggé korlátozott, ezért nagyon át kell gondolni, pontosan mit is szeretnél megvalósítani. Az én álmom pl. az volt, hogy egy minimál kernelt hozok létre amely rendszerhívás szinten támogatja a neurális hálókat és később ipari robotok vezérlésének irányába mozdítom el a dolgot. (ma már tudom, hogy ipari célokra jobb célhardverek vannak, mint a egy PC)
- a fájlrendszer+lemezkezelés maga kb. olyan bonyolult, mint a boot sector + alap kernel

- egyedül nem lehet kivitelezni egy ilyen projektet értelmes időn belül (mondjuk fél év napi 8 óra legyen még értelmes)
- a programozós és processzor tapasztalataim nagy részét elfelejtettem az elmúlt pár évben :)

- ha valami, mai szemmel nézve "értelmes oprendszerre" szeretném fordítani fölös energiámat, akkor semmiképp nem intel procit programoznék, hanem pl. PIC-et, és az intel proci bonyulult extráinak megtanulása helyett inkább az elektronikai tudásomat fejleszteném, hogy a PIC-re írt "oprendszer" (inkább csak program) pl. egy robotot irányítson. Kisebb energiabefektetés, nagyobb sikerélmény, és később még a tudás is használható
- ha mindenképp intel, akkor max linux kernel átírásában gondolkoznék, vagy egy most futó opr. projektbe szállnék be
- ha érdekelnek a robotok és van pénzed, nézd meg a Lego NXT-t!! (az idő pénz -> ez igencsak költséghatékony) 


title GoboLinux - Console (hda8)
kernel (hd0,7)/System/Kernel/Boot/kernel root=/dev/hda8 vga=0
Amint látszik a titokzatos (hd0,7) részen, a vessző utáni szám eggyel kisebb,
mint a partíció száma amire telepítettünk, - ez a titka az egésznek. Ez a Grub
progi valami hülyesége, nem tudom az okát, de így van. A hd utáni szám
pedig azt jelenti, hányas merevlemezről van szó.

A grub-ról például sokat tanulhatsz belőle. Ami egy nagyon kényelmes és praktikus eszköz saját minimál kernel betöltéséhez.

Szent hurkapálcika! Tényleg ilyen ez a könyv? Most már muszáj lesz elolvasnom :D Egyre kevesebbet van időm vígjátékokat nézni :D

"Ez a Grub progi valami hülyesége, nem tudom az okát, de így van."
Oszk-nál azért megnézhetnék, mit tesznek ki.... Könyvet írni úgy, hogy nem tudom, mi miért van? Kvák...

Mér ke' csodákozni ? :)
Én mikor be voltam öltözve, és oktatásra járunk a Fradi pálya mellé (jól tudom, hogy ott most egy kráter van, vagy már beépítették a helyét? :) ) híradó szakon, a rádiós kocsi berendezéseinek oktatása során az oktató alezredes szájából a következő hangzott el (adalék: mi rigók voltunk, azaz diploma utáni tartalékos parancsnoki képzést kaptunk, tisztként szereltünk stb.):

"... valamint egy 12/24-es DC/DC átalakító, ahol ez a DC valami rövidítés lehet, nem is tudom mi, de ez igazából nem is fontos..."

Mivel híradó szakra a műszaki végzettségűeket válogatták, ez kissé sokkolta a hallgatóságot :)

+1 érdemes nézegetni ezt is: http://www.osdever.net/

Meg érdemes átrágni magad néhány tutorialon is:
http://www.jamesmolloy.co.uk/tutorial_html/index.html
http://www.osdever.net/tutorials/view/brans-kernel-development-tutorial

Azonban vigyázz! Ezek a tutorialok és az osdev wikije is rengeteg hibát tartalmaz, egy-az-egyben nem használható, csak támpontot adnak! A copy-n-paste epic fail. Pl. szinte mindegyikben hibásan szerepel a GRUB Multiboot header. Hogy mi benne a hiba, azt nem árulom el, arra már magadtól kell rájönnöd :-)

( whitehawk v | 2010. 12. 19., v – 12:12 )

Milyen előképzettséged van? (annak megfelelően hátha tudok mondani valamit..)

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

(Pascal, C, C#)-ból van OKJ (tudom, hogy ettől még ott van a tojáshéj a fenekemen :) ) régen Basic egy commodore plus 4-en, meg tudtam 2 képernyőre kiírás példát az Agárdi-féle assembly könyvből, meg a PHP (tudom, hogy eredetileg csak szkript nyelv, de akkor is imádom :) )

Hát ha OS-t akarsz matatni, akkor szerintem mikrokontrolleren szórakozz FreeRTOSsal. A doku sajnos nincs ingyen. Minimális az OS kódja, és betekintést kapsz abba, hogy mi az a minimum amit egy OS csinál. Ráadásul szerintem könnyű sikert elérni vele. Írhatsz magadnak egy tucat drivert. Megy ARMon is. C-ben kell kódolni.

Én szem előtt tartanám, a tanulási utat, (vagy mire fordítják azt, hogy learning curve?) mert különben lehet, hogy el megy a kedved az egésztől egy idő után.

Aztán ha már a vécédeszkában is mikrokontroller zenél, akkor írj egy másik uC oprendszert, ha nem tetszik a FreeRTOS.

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

Szerintem amit tudsz, az édeskevés bármihez ezen a területen.

Az én véleményem szerint a következő minimum tudás kell ahhoz, hogy egyáltalán érdemes legyen nekiállni:

- nagyon stabil assembly és hozzá kapcsolódó HW tudás: a kiszemelt CPU architektúra alapos ismerete, privilégiumszintek, memóriaszervezés, cache kezelés, interruptok, trapek működése

- nagyon stabil HW chip-szintű tudás, a kiszemelt architektúrán előforduló alapvető chipek programozása: memóriavezérlő, interrupt vezérlő, DMA vezérlő, I/O vezérlők (soros port, USB port, printer port, billentyűzet interfész, videókártya, floppy/IDE/SATA/SCSI/CF/stb. vezérlők, akármi, ami van azon a platformon), modern gépek esetében PCI busz/slot kezelés

- nagyon stabil C tudás (azon a szinten, hogy a compiler az adott forrásból milyen assembly-t fog előállítani!)

Ez szerintem alsó hangon 5 év alatt szedhető össze napi rendszerességű ilyen témákban való foglalatossággal, onnantól, hogy elolvastad az első könyvet az adott nyelvről.

Ezen felül kell valami minimális tudás az operációs rendszerek működéséről (különben azt se fogod tudni, hogy mit kell csinálnia a programnak, amit írsz), de ha bármire szeretnéd is használni az eredményt, akkor minél több létező operációs rendszert fel kéne fedezni, hogy azokon mit hogyan csináltak meg, mert különben menet közben fogsz rájönni, hogy erre meg erre nem gondoltál, és az alapvető architekturális változtatásokhoz a fél rendszert írhatod újra. Ez szintén több év ismerkedés a világ eddigi dolgaival, ha ki is akarod őket próbálni, akkor még több.

Szerintem sem x86-tal érdemes kezdeni. Én ARM-ot vagy MIPS-et választanék, qemu jól támogatja, és vannak rájuk hasonló mini-OS-ek "ihlet" gyűjtéséhez.

De szerintem sokkal hasznosabb, ha az új OS megírása helyett megismeri tényleg mélyen a Linux kernelt egy nem x86 architektúrát célozva, ahol kevesebb az eszkimó és több alacsonszintű javítanivaló akad. Arról nem beszélve, hogy a Linux kernel ismerete konkrétan piacképes tudás, míg az "írtam egy bootoló OS-t" maximum egy plusszpontot jelent az interjún.

Üdv,
Gergely

Oszt az mér' jó? Mert nincs hozzá doksi? Szerintem az x86 tökéletes erre a célra, jól dokumentált, és rengeteg embertől tud kérdezni, ha elakad.
ARM specért keményen kell csengetni, MIPSet meg nem egyszerű szerezni. Merthogy éles vason is ki kell ám próbálni, hogy kizárhasd a vm bugokat (amiből van épp elég).

"Szerintem az egyetlen architektúra amire nem lenne érdemes fejleszteni az az x86."

Jehehehe... you made my day. Tudsz róla, hogy jelenleg a számítógépes piac döntő többsége x86...? Vagy ez új neked?

Egyébként meg messze a legjobban dokumentált. Nem értem mi bajod van vele. Vannak hülyeségei, no de melyiknek nincsenek? A lényeg, hogy INGYEN, regisztráció és licenszfeltételek NÉLKÜL letölthető minden hozzá.

Kár, hogy sem neked, sem tordus kollégának nem sikerült azonosulni a témával. Ugyanis a téma a arról szól, hogy jó lenne írni egy oprendszert _tanulás_ céljából, a témaindítót az alacsony szintű programozás érdekli.

Biztos, hogy én vagyok rossz helyen a szakmában, de eddig sohasem kellett x86-ra programot írnom assemblyben, ennek szerintem az lehet az oka, hogy erre az architektúrára rogyásig vannak már most is a használható oprendszerek, magas szintű programozási nyelvek, keretrendszerek, stb., egyszóval eszébe sem jut senkinek x86-ra assemblyben programot írni.

Ezzel ellentétben az ARM és MIPS architektúrák most vannak igazán elterjedőben a mostanában divatos mobil-kütyük miatt, mint pl. az android, bőven akad fejlesztési lehetőség ezekre az architektúrára. Emiatt én sokkal inkább azt mondanám, hogy ne az x86-ra fejlesszen, mert az ARM, MIPS jelenleg sokkal piacképesebb tudást jelent.

Anyira jól azért nem fizetnek.
Aki ARM-ra programoz, azt villamosmérnöknek tekintik, és úgy is fizetik meg.
Ezért lettem C++ programozó, kb. kétszer annyit kapok most, mint ARM-programozó koromban.

Természetesen van az a pénz, amiért értek az ARM-hoz, de az nem kevés, hiszen a szabadidőmet áldozom fel. Az pedig drága dolog, mert kevés van belőle.

Fuszenecker Róbert

Üdv,
Értem én hogy villanyvasút, de miért diesel mozdony hajtja?
Komolyabban megfogalmazva: Szép és jó dolog az ARM, de már beigazolta magát, hogy a RISC a személyi számítógépek vonalán nem túl effektív. Nem az architektúra hibája, hanem a fejlesztők lustasága miatt. Ezért vált az x86 is egyre inkább CISC vonalúvá, és ami kis RISC-t őriz, az csak kompatibilitás miatt. (persze tévedhetek, és lehet az x86 soha nem volt RISC jellegű, de nekem annak festett, csak konkrét infót nem találtam róla, minek számít :))
Az x86 vonal meg egyre inkább tovább fejlődik, megmutatja, mennyi mindent ki lehet belőle spórolni, hogy o'ccóban menjen, szóval, nem kell félteni. Inkább az a jövő útja, hogy a személyi számítógépek, illetve kommunikációs eszközök vonalán kihal az ARM és marad a spec. céleszközöknél. Még olcsóbb, energiatakarékosabb, de alacsonyabb teljesítménymutatójú is, mint a vele egy generációs x86-ok. Persze ez elsősorban annak köszönhető, hogy az utóbbiak néhány egyéb utasítás készletet is tartalmaznak, bár tény, az ARM se állt meg a fejlődésben :)
Nah, és most jön a klasszikus tévedhetek, de én ezt látom mondat, de inkább nem ismétlem magam, elég egyszer leírni. Viszont számomra tényleg úgy fest, hogy ez a jelenlegi haladási útvonal: x86 lassan leszórítja az ARM-t, vissza a saját szegmensébe, ahol egyeduralkodó, és az x86 labdába se rúghat, főleg amiatt, hogy ágyú lenne a verébre, mind árazás, mind képességek terén: specializált, valósidejű feladatok. Mert igaz, hogy az ARM nem gyors (szerintem) általános célra, de azért vannak feladatkörök, amikre ki lehet hegyezni, és az nem az OS futtatás :)
Üdv,
LuiseX
U.i.: Tévedés jogát fenntartom, meg std nálam a FIXME felirat;)

akkor tessék, fixed:
az x86 soha nem volt risc. mindig cisc volt. ha nagyon akarjuk a riscet erőltetni, akkor lehet azt mondani, hogy a cisc magon belül időnként felütötte a fejét riscre jellemző dolog, de ez kb. az a szint, hogy a gyümölcslé nyomokban gyümölcsöt tartalmazhat.

Amikor az amd megvette a nexgent az nx architektúráért, akkor volt valami kis risc beütés az x86-ban. hogy ebből mára mi maradt, nem tudom.

Üdv,
Akkor téged kérdeznélek, mert "rejtett kérdéseim" válasza nem jövend el:)
A suliban én csak annyit tanultam a két processzor architektúra elvről, hogy a RISC jellegzetessége a rövid és a lehetőségekhez mért utasítás végrehajtási idő (egy utasításra nézve pl. 1 utasítás 1 órajel...), illetve minnél kevesebb és egyszerűbb utasításra építkezik. Ebből kifolyólag persze a ráírt fordítónak kell intelligensnek lennie, hogy értelmesen, optimalizálva biztosítsa az utasítások sorrendjét, mert maga a cpu butus "számológép szintű"...
Ellenben a CISC összetett, bonyolult és változó végrehajtási idővel járó utasítás készletekre építkezik, minél több probléma megoldását hardveresen implementálva, így a fordító nem kell olyan mélységig ismerje a cpu képességeit, elég csak az utasításait ismerni az effektív müködéshez.
Ez persze lehet baromság, tekintve egy releváns doksit, könyvet, de még cikket sem találtam, ami ténylegesen kitér ezeknek az architektúrális elveknek valódi tartalmára :)
Szerény személyemnek maga az x86 inkább RISC-nek festett, kiegészítve CISC elvű utasításkészletekkel (MMX, SSE, 3DNow, stb), illetve CISC tárprocesszorokkal (GPU, SPU(vagy hogy hívják a hangkártyák prociját?), stb).
Lehet az egész "világnézetem" hibás, de akkor örülnék végre valami hiteles, és talán korszerűnek festő leírásról, mert míg a C64-hez találok jó doksikat, ZX-Spectrumokhoz is, de még a 8086-hoz is, addig a modernebb generációk elvi felépítéséről (és most nem a hw, vagy épp sw implementációról, hanem úgymond a design patternre gondolok) csak részekre szedett, egy-egy elemmel foglalkozó leírást lehet találni, amiből összeollózva a dolgokat vicces tévképzeteim származhatnak (ld. korábban :) ). Tehát, a kérdés adott: van elvi, implementációtól majdhogynem mentes vázlata korunk PC-jének valahol is, vagy, ad-hoc lehet az implementációból következtetni csak? :)
Üdv.,
LuiseX

Mondjuk ma mar annyi jelentosege van az egesz CISC-RISC dolognak, hogy az x86-s CPU-k visszafele kompatibilitas miatt nem valtottak utasitaskeszletet. Felszin alatt viszont ugyanugy bontjak sok kis apro egyszerubb muveletre a dolgokat AFAIK.

Ezt az utat ha jol tudom az AMD kezdte el, majd sok-sok ido utan az Intel is atvette a Core-ban.

----------------
Lvl86 Troll

Üdv,
Köszi, akkor a'sszem annyira mégsem álltam messze a valóságtól, csak 1-2 fényévnyire :) Abban a hitben lengedeztem, hogy az x86 jelenleg tiszta RISC, de a tévedés magva beárnyékolta tudásom eme hibáját:P
Azért, hogy őszinte legyek, jobbnak látom, hogy CISC felület mögött RISC van, minthogy tiszta RISC legyen. Így azért a hw tud optimalizálni hardwired módon, miközben a programozó kényelme is megmarad. Mondhatni, mindenki jól jár, és a lúd is kövér marad.
És, ez jobban hasonlít a programozói felületekre is :D Tudod, pár kattintás, pár mozdulat, meg 1-2 event lekódólása, és már kész a program (Izé, nincs bajom a RAD-al, csak azzal, hogy van aki egy-egy RAD környezet ismeretétől érzi magát programozónak:) ). Kb. ugyanez megy akkor CPU szinten is, csak interpretálva az ő környezetére :D
Üdv.,
LuiseX

Üdv,
Köszi, hasznos adalék, bár, sajnos nem újdonság :) Viszont, egész jó leírása :) Szóval, köszönöm;)
Üdv,
LuiseX
Szerk.:
Tévedtem, tanultam újat is: http://en.wikipedia.org/wiki/Microcode#The_reason_for_microprogramming
Köszi, így már világosabb a két fogalom, és nem valami ezoterikus, elborult design pattern a CISC;)

Érdekes. Engem átdob a login-ra, ha le akarom tölteni a devtools-t.
http://www.arm.com/support/university/tools.php
És ez az oldal sem úgy néz ki, mint amit szabadon felhasználhatnál:
http://www.arm.com/products/buying-guide/licensing/index.php

Persze nem kizárt, hogy vannak az internetnek eldugott bugyrai, ahonnan beszerezhető a doksi.

Nem teljesen értem, hogy az ingyenes regisztráció miért okoz leküzdhetetlen problémát. Hasonló nehézségekbe ütköznél egyébként a mips.com-on is, hiszen ott is, ha jól emlékszem, egy ingyenes regisztráción kell átesni, mielőtt letölthetnéd a specifikációkat.

Tehát a dokumentáció nem probléma.

Hardver:
1. MIPS: Bármely OpenWRT képes router megteszi, a jelentős részük MIPS architektúrájú chipsetet futtat, pl. Broadcomtól.
2. ARM: Beagleboard xM. 150 USD-ért kapsz egy teljes számítógépet 3D gyorsítóval, 1 Ghz CPU-val, DSP-vel (ahol tényleg van értelme az assemblynek), NEON-nal.

Ha ezekre megtanul assemblyben programozni, akkor másnap már válogathat az állásajánlatok közül, mi is keresünk ilyen fejlesztőt. x86-ra sokkal kevésbé jellemző, hogy assemblyben kell fejleszteni bármit is. (Nyilván vannak helyek, ahol igen.)

Segítségkérés: mind ARM, mind MIPS esetén jó community van, tehát ez sem probléma. (Nyilván angol nyelven)

Azt azért össze kéne vetni, hogy a világban hány x86 és hány ARM + MIPS rendszer működik. Én nem vagyok biztos abban, hogy számosságban a PC-k + szerverek lenyomják az embedded világot, de nem néztem utána.

Mindenesetre embedded assembly tudással a mai munkaerőpiacon könnyebben fog munkát találni, mint x86 assembly tudással. (Nyilván ez is a többi területen felmutatott képességektől függ.)

Üdv,
Gergely

Valóban igazad van, nem jól fogalmaztam. Nem ingyenesre, hanem szabadra gondoltam eredetileg, csak össze-vissza irogatok mindenféle hülyeséget. Ha regisztrálni kell meg licenszszerződést kötni, akkor az nálam már nem játszik.

Hardver: ebben abszolúte igazad van, visszavonom amit korábban gondoltam.

Segítségkérés: elhiszem, de x86-hoz nagyságrendekkel több doksi és tutorial van. Pl nem találok olyan leírást, ami arról szólna, hogy hogyan bootol be egy ARM processzor, ami elengedhetetlen lenne a kolléga számára.

Abban egyetértünk, hogyha az ARM+MIPS assembly vonalra fekszik rá, akkor esélyes, hogy abból többet profitál majd.

Pl nem találok olyan leírást, ami arról szólna, hogy hogyan bootol be egy ARM processzor

Persze hogy nem találsz, mert a bootolást nem az ARM mag intézi hanem a köré épített perifériák amelyek processzoronként változnak. Datasheet-eket és User Guide-okat tanulmányozd inkább. Ezek ingyenesek és sokszor regisztráció nélkül elérhetők.
-
J

Az ARM applikációs processzorok (ARM7, ARM9, ARM11, ARM Cortex-A*) a 0x00000000 címen levő utasítást kezdik végrehajtani (RESET vektor). Ez tipikusan egy branch utasítás.

A mikrovezérlők (ARM Cortex-M*) 0x00000000-n található címet betöltik a stack pointerbe.
A RESET vektor a 0x00000004 címen található, ez egy cím (!), nem pedig utasítás, a main() függvényed címe.

Mindezt onnan tudom, hogy elolvastam a leírásokat, amelyeket az ARM teljesen ingyen a rendelkezésünkre bocsát: http://infocenter.arm.com/

Fuszenecker Róbert
Magister Linucis et ARMis

Amiket felsoroltál, csak akkor érnek valamit, ha már van egy stabil tudása az operációs rendszerek elméletéből....addig lehet ő a legjobb assembly vagy c guru, nem fog oprendszert írni...multitaskosat pláne nem. Amíg nem tudja, hogy mi az időszelet vagy a time sharing, mi a lapozás lényege, milyen metodikák alapján végezhető, hogy oldják fel a konkurens taskok közötti versenyt az erőforrásokért erőforrástípusonként, addig max. MBR-be fog írni egy 512 byte-os valamit, ami egy hello world kiíró kódot behúz a tárba és rádobja a vezérlést. ...és még az operációs rendszerelmélet felszínét sem karcintottuk most meg.

Igen, MBR-be beleírt Hello World szokott az ember első (és általában utolsó) önálló bootolható "rendszere" lenni. De ha ezen valaki túllép és egy primitív lemezkezelőt is ír (mondjuk BIOS megszakítások használatával), akkor már messze tovább jutott ezen a téren, mint a programozók 99.999%-a. Szerintem egy PC DOS 1.0 szintű rendszer összedobásához nem kell valami nagy tudás, csak rengeteg idő. Aztán persze jöhet a multitasking, de addigra már edzett emberrel állunk szemben, aki képes lehet beszállni előrehaladottabb rendszerek továbbfejlesztésébe.

..... először meg kell néznem a Nagy Testvérben, hogy mi az a PIC :) de gondolom sok köze van az integrált áramkörökhöz. A mikrokontrollerekről meg egy BME-s haverom mesélt. Érdekel annak a programozása is. De előbb szeretnék több műszaki ismeretet hozzá.

De tényleg mindjárt megnézem, hogy mit jelent a PIC :)

szerk.: és tényleg :)
http://www.freeweb.hu/fairco/pic/main.html

(Pascal, C, C#)-ból van OKJ (tudom, hogy ettől még ott van a tojáshéj a fenekemen :) ) régen Basic egy commodore plus 4-en, meg tudtam 2 képernyőre kiírás példát az Agárdi-féle assembly könyvből, meg a PHP (tudom, hogy eredetileg csak szkript nyelv, de akkor is imádom :) )

ha nagyon magad ragaszkodsz mindenhez, akkor eloszor irj kisebb konyvtarakat, api-kat, amiket egyreszt jol kitesztelsz, masreszt amit kesobb bele tudsz tenni majd a kerneledbe. marmint a kisebb az idezojelben, erosen, ilyesmikre lehet gondolni mint:
- filerendszer (ro es rw, egyarant)
- halozati reteg
- terminal emulacio
- kozos api (unistd, fcntl, berkeley sockets, ...)
- sajat (m)alloc impliementacio
ezek megvannak, akar programozoi szinten is? ha nem, akkor par ev, tanuld meg hasznalni, majd utana kezdd el megirni (a fentiek egyikehez sem kell rootkent garazdalkodni, kis egyszeru emulacioval mindegyik kitesztelheto" valamilyen szinten). aztan majd utana johet a tobbi.

( bAndie9100 | 2010. 12. 19., v – 12:41 )

'BugOS, ezek a legutolsó képek róla, azóta senki se látta'
http://web.archive.org/web/20080528102231/http://bugos.nop.hu/

Ezen lehet tanulmányozni az op. rendszer minden szintjét.
Ha akarod feltöltöm egy kb. 2008-as kiadását (akkor nyúltam hozzá legutóbb), mert a hivatalos honlap hiányában nem találom letölteni sehol.

pascallal és assemblerrel készült
~~~~~~~~
De ezt az egy lépést ki nem tevé,
Az nem tett semmit, nem tud semmit is.

Természetesen van (vagyis volt), neten fellelhető pár verziója a BugOS.zip filenak. (Hja, verziózva nem volt.)

De egyébként a webarchive segítségével eljutottam a http://mc36.nop.hu/ oldalra (szerző oldala), és ott van contact is. Mondjuk el is lehetne tőle kérni a kódot. :)

--
Don't be an Ubuntard!

Én "ismerem" a srácot, egyszer voltam nála. Elképesztő, amit a BugOS-sal csinált, de tényleg. Mégis, szerintem ami igazán nagy benne, az a hálózatkezelés: hálókártyák, protokollok.

De mindenféle bántás nélkül igen komoly betegségei is voltak:
- rajta kívül gyakorlatilag senki sem tudta értelmesen használni;
- lassú volt;
- nem voltak hozzá tök alap programok, vagy ha igen, félkészek, nehezen használhatók;
- a Pascal fordítója elég rosszul értette a Pascal nyelvet és nagyon lassú kódot generált;

Persze mindezt egyedül érte el, nem csodálom, hogy mindent nem tudott fényesre csiszolni.

Én a DOS-os asm fejlesztéseimhez MC SASM fordítóját használtam, annál jobbat eddig senki sem adott nekem :)

Le a kalappal a srác előtt, de szerintem az ő példájából is látszik, milyen nehézségek vannak. Amúgy ő kb. bitszinten ismeri az x86-os procikat, mindig tudtam tőle tanulni valamit, akármit is kérdeztem.
--
http://www.open-st.eu

backup mindenképpen ajánlott,

a telepítésnél ki kell választani egy merevlemezt utána egy pertíciót rajta!
de el is lehet indítani a saját partícionalóját, hogy stílusosan létrehozzon egy 0xB0 tipusú Bug0S fájlrendszert :)

~~~~~~~~
De ezt az egy lépést ki nem tevé,
Az nem tett semmit, nem tud semmit is.

( gabek | 2010. 12. 19., v – 19:44 )

Már javasolták előttem: nézd meg az ast féle könyvet és oprendszert. Ezzel még sok energiád nem megy kárba, ez olyan tudás, ami amúgy is jól jön, ha programozol. Aztán, ha még ezek után is van kedved, szerintem akkor se csináld hajrá :)

( samu.ferenc | 2010. 12. 19., v – 22:31 )

Bocsi hogy negatív leszek, de ha nincs konkrét célod ezen a területen akkor időpazarlás. Kezdőkre jellemző, találjuk fel a meleg vizet. Nem kérdés, hogy sokat lehet belőle tanulni, de ha a tanultakat nem tudod hol/miben felhasználni akkor minek.

( kleinie | 2010. 12. 19., v – 23:06 )

Ha assembly megy, akkor ezt is érdemes lehet tanulmányozni: MenuetOS
Anno engem is érdekelt a téma, amolyan 'koca' programozóként. Addig assemblyben el is jutottam, hogy az 512 byte-os programom gombnyomásra kiírta, hogy 

Hello!

De ilyen irányú tanulmányok és képzettség hiányában abbamaradt a dolog. 'A suszter maradjon a kaptafánál.' Az én esetemben.
De neked sok sikert és még több kitartást!

( axt v | 2010. 12. 20., h – 00:23 )

Még asszem nem említette senki:

Horváth Gábor: Assembly Védett Módú Programozás

Kicsit homályosak az emlékeim, de van benne olyan, hogy: GDT, IDT, taskváltás a különböző privilegizálási(?)-szintek közt, lapozás, virtuális mód. Lehet hogy a fent említett Horváth Gábor könyvenek egy régebbi kiadása, azt nem ismerem ...

( Dacr (nem ellenőrzött) | 2010. 12. 20., h – 10:14 )

Oprendszert még nem írtam, valószínűleg azért, mert nem érzem a tudásom elég masszívnak hozzá, de a fentebb írt mikrovezérlős megoldásokon túl javaslom, nézd át pl.: hogyan lehet írni drivert linuxhoz. Ha az már megy, akkor gyanítom, lesz annyi hardware-közeli élményed és tapasztalatod, amivel tovább tudsz lépni.
Nem biztos, hogy jó a gondolatom, a nálam okosabbak majd pluszolnak, vagy minuszolnak :)

( turdus | 2010. 12. 20., h – 10:50 )

Jótanács: mielőtt nekivágnál, előbb tudd, hogy mit akarsz! Nincs oprendszerírás szent-grál, hiszen pont az a lényeg, hogy valamit máshogy akarsz megvalósítani, mint a mostani rendszerek (ha nem így lenne, nem lenne értelme megírni, ugye).

Pár dolog, amin érdemes elgondolkodnod:
1. hogy induljon? Saját boot loadert akarsz írni, vagy inkább használod a GRUB Multiboot-ot?
2. milyen kernelt akarsz? Micro, monolitikus, esetleg exo?
3. milyen fs-t akarsz? Megfelel valami létező, vagy speciális igényeid vannak?
4. milyen toolchainnel akarsz dolgozni? ELF vagy PE binárisokat akarsz futtatni, vagy netán sajátot?
5. ne akarj egyből GUI-t! Nagy eredmény, ha van egy egyszerű parancssorod, ami igazi taskként fut (és kommunikál a billentyűzet driverrel meg a tty screen driverrel).

Összefoglalva, ahonnan érdemes elindulni:
http://www.minix3.org/
http://wiki.osdev.org/
http://www.osdever.net/
http://superfrink.net/athenaeum/OS-FAQ/os-faq.html
http://www.ctyme.com/rbrown.htm (hamar megtanulod, mi az a RBIL, megkerülhetetlen :-)

a rendszer konkrét céljáról még nem gondolkodtam el, de mindenképp egy letisztult, speciális feladatra szánt rendszer lenne. (Főleg a TV-s szakmában használatos)

köszi, hogy felsoroltad a szempontokat, mert így már könnyebb terveznem is.
1. mindenképpen saját boot loadert szeretnék.
2. egyelőre monolitikus kernelben gondolkoznék.
3. egy könnyen kezelhető, kis sérülékenységű fájlrendszert használnék, ami könnyen kezelhető és támogatja az akár 13 GB-os fájlméretet is.
4. toolchain? ennek utána kell néznem, hogy az ami :) ELF binárisokról hallottam már. de ennek is utána kell néznem.
5. egyelőre én is GUI nélküliségben gondolkodom :)

TV-s szakmában alapvetően nem is az oprendszer-hiány, vagy azok nem jó működése a probléma, hanem az, hogy a jelenleg stabil rendszerekre nincs igazán szoftver, amit futtatnának. Videó vágás linux alatt jelenleg csak drága megoldásokkal lehetséges (pl.: Piranha), adásbonyolító szinte nincs is (van ugyan egy mlt-re épülő rendszer, de baromi nehézkes és felhasználó oldali megoldása elég gyermekcipő szintű). Ha szabad-szoftverben gondolkodsz, akkor az energiákat célszerűbbnek látnám meglévő videotechnikai szoftver-projectekbe szánni.

Ettől függetlenül ha a tanulás a célod, akkor ne szegje kedved hozzászólásom, vágj bele.

1. ez a szebb, de nehezebb út.
2. ez az egyszerűbb, és valószínűleg bőven meg fog felelni az igényeidnek
3. ez esetben egy már meglévő fs felé kacsintgatnék
4. toolchain: a fordításhoz szükséges programok. Általában egy linker, egy assembler meg egy cross-compiler, valamint egy projekt-managelő (gnu-make pl). Assemblerek közül sokan istenítik a nasm-mot, nekem a fasm jött be (http://flatassembler.net)
5. helyes :-)

Aztán, ha megvan odáig a dolog, hogy be tudod tölteni a kerneled, és el tudod indítani, akkor jön a a dolog oroszlánrésze: rengeteg elmélet és gyakorlati tudás kell a belső rendszer megtervezéséhez (minix könyv jó alap ehhez, olyanokra dongolok, mint éheztetés, kölcsönös kizárás, deadlock, spinlock, memória allokációs algoritmusok, bitmap, slab stb.) Ezekhez aztán végképp nem fogsz találni semmi útmutatót (külön-külön igen, de nem egyben), hisz ez a te rendszered, neked kell kitalálni, hogy hogyan álljön össze egy kerek egésszé.

( ezqgtouvszfgc | 2010. 12. 20., h – 13:34 )

Lehet először egy terminál emulátorral kezdeni [1], közben a programozást könnyítendő egy emacs-ot írni [2]. Ezalatt elég tapasztalat gyűlik [ez lenne a kerítésfestés].

Aztán jöhet a ,,From NAND to Tetris'' [3,4], VM-el, OS-el stb.

[1] http://linux.bihlman.com/tag/torvalds/
[2] lásd GNU Emacs (emacs), Micro-emacs (uemacs), Gosling Emacs (gmacs) stb.
[3] http://video.google.com/videoplay?docid=7654043762021156507
[4] http://www.idc.ac.il/tecs/

Egyébként nem tudok itthon hasonló színvonalú kurzusról/anyagról. Én nem tudok itthon olyan iskoláról, ami ilyenekre tanít meg :)

( tselmeci | 2010. 12. 20., h – 15:51 )

Én a helyedben ott kezdeném, hogy bele sem kezdenék.

Egyetemista koromban én is mindig OS-t akartam írni, pont olyan indokokkal, mint te, hogy sokat lehet tanulni belőle - ez igaz is. Viszont baromi sokat lehet tanulni másból is.

Nekem azért ennél lényegesen több tudásom volt, és mégsem álltam neki, mert az MBR kódot, bootloadert, kezdeti kódokat simán megírtam volna asm-ban, viszont onnantól kezdve már nem sok kedvem lett volna asm-ban fejleszteni, így kellett volna egy C fordító. Ránéztem a gcc-2.95 forrására, és azt mondtam, hogy ezt kösz nem. Azóta gondolom sokkal nagyobb lett a gcc is. Tehát ahhoz, hogy OS-t buherálj, legyen fordítód is, amit itt tényleg neked kell megcsinálnod, és ez ultrakemény szopás, puszta érdeklődéssel ezt nem tudod megcsinálni. Én itt tettem le róla, és nem bántam meg. (Persze ha a fordítód mindig csak keresztfordít az új OS-edre, akkor egy fokkal könnyebb, de számomra az volt a cél, hogy a saját OS-en legyen fordító).

Ha nagyon lelkes vagy, akkor javaslom, írj egy boot managert előszőr. Ahhoz elég az asm is, és látni fogod, hogy mennek a dolgok. Én anno írtam magamnak egyet, menüs volt, tudott secondary disk-ről is bootolni, kiírta a partíció méretét, nevét stb.

Írhatsz saját fájlrendszert is, ott a remek linux VFS, mintául lehet használni a linux FS driverek kódját is. Írhatsz saját ütemezőt is, piszkálhatod is, mint pl. Con Kolivas. Lecserélhetsz komplett alrendszereket a kernelben, iszonyat sokat lehet tanulni ezekből is.

Ne bántásnak vedd, de ha valaki nem tudja, hogyan kell MBR bootloadert írni, nem tudja mik a képernyőkezelés alapjai stb. az ne OS-t akarjon írni, hanem előszőr asm-ban mondjuk videó memória író programokat DOS alatt vagy akármit. Én sem tudok repülőt vezetni, és nem is egy F16-oson akarom elkezdeni.

Megírni egy (n + 1)-ik OS-t nincs értelme. Biztos írták itt többen is felettem, hogy jobban jársz, ha már egy létező OS-ben mélyedsz el, vagy akár szakértője leszel egyes területeknek, pl. OpenGL linuxon, profi hangkezelés, hálókártyákhoz driverírás, akármi. Itt is közel lehetsz az OS maghoz, és nem kell végigszívnod azt, amit mások már megszívtak előtted.

Az én véleményem az, hogy ma már minden célra van megfelelő OS. Pl. QNX, Linux, Windows stb. nincs értelme egymagad tákolni valamit. Most látom, amikor már kevesebb a szabadidőm, hogy olyanra kellett volna nekem is fordítanom, amivel most még előrébb lehetnék.
--
http://www.open-st.eu

( uid_15541 | 2010. 12. 20., h – 17:45 )

Ha érdekel, akkor van egy ősrégen (10+ éve) írt "programocskám", ami halom dolgot csinál onnantól, hogy az MBR-ből beindul. OS nélkül fut, tehát talán innen el tudsz indulni.
Magánban elküldöm, ha gondolod.

( endi123 v | 2010. 12. 26., v – 23:07 )

Ami be kell szerezni:
Telepítsd a VirtualBox-ot, vagy hasonlót. Telepítsd rá az MS-DOS-t. Ehhez tuti rengeteg dokumentációt találsz, de próbálkozhatsz FreeDOS-al is.

Tegyél föl valami egyszerü DOS C fordítót és assembly fordítót a friss virtuáls gépre.

DOS-os hexa-editor fog kelleni kesöbb.

Alap tudás:
Az oprendszer és a BIOS funkcióit (mint pl képernyőkezelés, filekezelés) interruptokon keresztül érheted el. Nézz utána hogyan lehet interruptot hívni C-ben vagy assembly-ben.

Legegyszerűbb oprendszer részletei:

Ha sikerült meghívni egypár DOS-os interruptot, nézd meg hogy lehet grafikus módra átváltani, és ott színes pixeleket kirakni. VESA szabványhoz keress rövid példa kódokat, az kell ide.
Vagy annyi is elég, ha a BIOSsal ki tudsz rakatni a szöveges képernyőre néhány karaktert. <- Inkább ezt javaslom, és mehetsz tovább.

Írj olyan "tömörítö" programot, ami nem tömörít, viszont egy fix méretü archívált fájlba bele tudjon pakolni fájlokat, illetve ki tudja onnan olvasni azokat. Ez a DOS-os program használhat C fájlkezelést az archívum megnyitására.
Legegyszerübb "just works": nincsenek könyvtárak, az archívum elején egy filenév-filehossz táblázat fix mérettel, utána fix méretü helyek az egyes fileok tartalmának.

Nézd meg a BIOS-on keresztül hogy tudsz írni-olvasni a merevlemezre. Irj belőle primitív fájlkezelést:
- read_whole_file(fajlnév, memoria kezdete)
- write_whole_file (filenév, memoria kezdete, hossza)
Teszteld DOS alatt.

Kösd össze ezeket:

Készíts egy olyan változatot az archiválóból, ami a DOS filekezelés helyett a BIOS hívásaiddal nyitja meg az archívumod. Ez lesz a filerendszer drivered.

A filerendszeredben legyen egy "init" nevű szöveges file. Ennek minden sora egy filenév lesz, amit végre kell hajtani. Az oprendszered annyit csináljon, hogy nyissa meg az init-et, töltse be a benne megjelölt fileokat, futtassa egyiket a másik után. A legeszerübb, erre a rendszerre irt programod irja ki hogy "hello world 2011".

Memoria kezelő OS rész:
A betöltött programok egy fix kezdetű, fix hosszúságú memoriacimre töltödnek. Ez a kódmemoria, ahol az épp futó alkalmazás kódja van.
A fix memoriacím fölötti területet korlátlanul használhatják az alkalmazások adatok tárolására, külön allokáció nem kell.
A fix memoriacím alatti területen az operációs rendszered számára fenntartott területet lesz.

Ez egy alap, olyan irányba fejleszted ami csak érdekel:
- a programjaidba fordított BIOS hivásos rutinok kerüljenek át az oprendszeredbe, ezek lesznek az op.rsz. funkciói
- bővítsd az oprendszered nyujtotta grafikus, stb funkciókat
- írhatsz egyszerű command interpretert
- net, usb driverek
- védett mód
- flexibilisebb filesystem
- egyszerü multitasking

PS:
Telepítéskor csinálj több partíciót. Elsőre mehet a DOS, másodikat nem kell formázni, ide kerül majd az új rendszer. DOS-ból az "archiváló"-val kényelmesen tudod majd írni, olvasni a saját rendszered fájljait.

köszi, akkor már el tudom képzelni, hogy hogyan képzeljem el egy fájlrendszer tervezését és működését :) tényleg nagyon hasznos volt számomra. amint vége az ünnepeknek és nem a barátnőmnél leszek, el is kezdek foglalkozni ezekkel :) BIOS hívásokban egyszerűbb elkezdenem gondolkodni rendszerszinten. aztán akarom majd elkezdeni megérteni a processzor arhitektúrákat és programozni azt.

( lx | 2010. 12. 27., h – 13:12 )

A 9-es alatt megtalálható 'o' billentyűvel (Shiftet lenyomva) érdemes kezdeni az írást.

( strogg v | 2010. 12. 27., h – 17:06 )

Ezt is tudom javasolni tanulmányozásra.
http://visopsys.org/

Ez egynagyon egyszerű OS, ami ráadásul teljesen egyedi, és "minden" fontos dologra találsz példát, hiszen betöltődik, vagy fs kezelés, vesa,ps2,lemezek,grafikus felület, stb....
Nagyon szemléletesnek tartom.
--
A hosszú élet titka, hogy csak F8 után nyomd meg az enter-t.

( Troppauer | 2010. 12. 28., k – 09:57 )

Elgurult a gyógyszered? :)

Ha ez komoly, akkor nezd meg a 0.1-es linux kernelt, Linus Torvalds pont ezert irta (i386 multitasking, stb)

--
"Windows... az mi?"