[Alg] Hoe werkt een OS en hoe schrijf ik er zelf een?

[Oguz286]

*UNDER CONSTRUCTION*

Beste GoT'ters,

Dit topic gaat over hoe een OS in elkaar zit en we gaan er ook zelf een maken. Ik hoop dat er veel mensen geïntresseerd zijn in dit topic. Hierbij dank ik alle GoT'ters die me helpen oa PrisonerOfPain

Allereerst neem ik aan dat je x86 assembler kent.

Een paar tutorials:

The Art Of Assembly Raad ik ten strengste aan als je niet in asm kan programmeren.
Programmers Heaven

Verder heb je de Intel docs nodig om te leren hoe een x86-omgeveing werkt:

AsmHelp - Met alle opcodes en schema over de x86 processor famillie
IntelDocs
Articles

Verder heb je natuurlijk een assembler nodig. Wij gaan nasm gebruiken:

Nasm - officiele site

Een programma om je bootloader op diskette te zetten:

Rawrite Als je een referrer error krijgt moet je ff googlen

En natuurlijk een emulator, want we hebben geen zin om telkens de pc opnieuw op te starten wanneer we iets willen proberen :

Bochs

Als je alles hebt dan kunnen we aan de slag. Ik ga voortborduren op dit topic:
[rml][ tutorial] how to write your own OS[/rml]

We gaan dus een OS schrijven. Wat? Een Operating System, oftewel in plain dutch: besturingssysteem Voorbeelden zijn Dos, Windows, Linux, BeOS enz, enz...

(Er komen veel stukken uit het topic van JayTaph, ik heb zijn toestemming niet kunnen vragen want zijn mailadres werkt niet. Als je er bezwaar tegen hebt, mail me aub )

Bootstrapping:
--------------

Moeilijkheidsgraad: makkelijk
Voorkennis: matige i386 assembly
Referenties: zie links hierboven
Tools: bochs, rawrite, nasm


Bootstrapping is het process dat gestart wordt als je je computer hebt aangezet en nadat de BIOS zijn tests heeft uitgevoerd (de zogenaamde POST - power on self test). Je BIOS laadt vanaf de boot-drive 1 sector (512 bytes) in zijn geheugen en springt naar dat stukje code. Dat stukje code zorgt voor het laden van de rest van het OS (of voor andere dingen, zoals het verzorgen voor virussen of spelletjes als tetris). De sector van de schijf waarop dit stukje code staat heet de bootsector en staat per definitie op de eerste sector (sector 1) van de schijf.

Op een harddisk kun je meestal meerdere partities kwijt, met elk een eigen bootsector. Hierdoor kan de bootsector van partitie 2 nooit op de eerste sector van de schijf staan (omdat hier al de bootsector van partitie 1 staat). Om dit op te lossen staat op de eerste sector van een harddisk meestal geen bootsector, maar een master boot record (MBR). Dit is ook een stuk code dat wordt ingeladen door de bios, maar bevat extra informatie over de partities op de schijf (de partitie table). Dit moet ook allemaal in 512 bytes gebeuren, dus een MBR heeft minder ruimte voor programma-code dan een bootsector.

Een MBR en bootsector worden allebei beeindigd door 0xAA55 op plaats 510. Dit is de bootsector terminator en je bios *KAN* (maar hoeft niet altijd) kijken of dit bestaat. Als het niet bestaat, dan kan je bios zeggen dat er geen legale bootsector is en stoppen met booten. Dit moet er dus altijd instaan wil je je OS laten booten op verschillende computers (en BIOS'en).

Ook kunnen sommige file-systemen kunnen in de bios een header zetten waarin gegevens staan over de schijf (volume naam, fat-type etc). Hiermee gaan we pas in het volgend hoofdstuk aan de gang. Hierdoor is het mogelijk om bijvoorbeeld je OS en de benodigde files te kopieren naar een normale DOS-floppy.

In dit hoofdstuk gaan we een bootsector maken die geen OS inlaad, maar wat text laat zien op het beeldscherm. We gaan op dit moment nog geen enge en moeilijke dingen doen zoals het inladen van sectoren etc. Als je geen assembly kent, dan worden sommige dingen hieronder al best pittig, maar ik probeer zoveel mogelijk uitleg te geven in wat ik doe, en als je er dan nog niet uitkomt, dan heb je altijd nog the gathering...


Het eerste wat we moeten weten is dat de bootsector normale, ruwe code is zonder headers (zoals exe-files). We weten dat de laatste 2 bytes van de code 0xAA55 moet zijn, en dat de code precies 512 bytes lang moet zijn (we kunnen heel makkelijk de code uitvullen met 00'tjes of NOP'jes).

We weten dat de bootsector door de BIOS geladen word op positie 0000:7C00 of 07C0:0000. Alletwee zijn mogelijk, dus moeten wij er zelf voor zorgen dat dit op elk systeem gelijk is.

Wat ook handig is, is dat de BIOS in het DL-register het ID van de drive laad waarvan we booten. Floppy drives beginnen bij 0: 00 is de A:, 01 is de B:, en harde schijven (fixed disks) beginnen bij 0x80: 80 is de C:, 81 de D: etc etc..

Hou er rekening mee dat wanneer je in de bootsector zit, je niet alles kunt gebruiken wat je normaal wel kunt. Je kunt niet alle interrupts die je wilt aanspreken, en dingen zoals de muis werken nog niet. Je moet dus zo minimaal mogelijk gebruik maken van interrupts, en zoveel mogelijk zelf doen (zover dat dat kan).

Nu krijgen we een hele simpele bootloader:

code:

; HANG.ASM
    ; Een minimale bootstrap!

    hang:                   ; Hang!
          jmp hang

    times 510-($-$$) db 0   ; Vul het bestand met nullen
    dw 0AA55h               ; Eindig het bestand met AA55

We beginnen bij het begin:

Vaste regels zijn:

; is commentaar teken (alles wat hierachter staat wordt niet gecompiled)

Regel 1: De naam van het bestand
Regel 2: Beschrijving van het progje
Regel 3: Leeg
Regel 4: dit is een label, je kan een label maken door een naam te typen gevolgd door een dubbele punt :
Regel 5: Dit is de eerste instrucite in ons progje, jmp komt komt van jump en het springt naar een ander deel van het progje, in dit geval naar ons label hang:
Regel 6: Leeg
Regel 7: Aangezien een bootloader 512 bytes moet zijn vullen we de rest van onze 512 bytes op met nullen
Regel 8: En aan het eind op plaats 510 komt de waarde AA55h zodat het bootable wordt (lees de bios het kan laden)

Sla dit op in hang.asm
compile hem met nasm:

nasmw hang.asm -o hang.bin

Nu moet je nog met rawrite de bootloader op diskette zetten:

rawrite

RaWrite 1.2 - Write disk file to raw floppy diskette

Enter source file name: hang.bin
Enter destination drive: a

Plaats nu een geformatteerde diskette in je floppydrive en druk op enter. Et Voilá, je eerste boot loader Het enige wat het doet is in een oneindige loop zitten. In het volgende hoofdstuk gaan we daar verandering in brengen

Natuurlijk kan je hang.bin ook gebruiken met bochs zodat je je pc niet opnieuw hoeft te starten. Je moet dan even in de configuratiebestand van bochs deze regel aanpassen:

floppya: 1_44=a.bin, status=inserted

veranderen in:

floppya: 1_44=hang.bin, status=inserted

en bochs opstarten.

Dit wordt nog bijgewerkt, dus aub geen commentaar op mijn startpost want hij's nog lang niet af

Prisoner Of Pain heeft nog wat leuke links opgezocht

FAQ's
http://www.mega-tokyo.com/os/os-faq.html
http://www.overwhelmed.org/shawn/faq.html
http://www.linuxgazette.com/issue82/raghu.html
http://osdev.neopages.net/tutorials/gettingstarted.php
http://phantom.urbis.net.il/bphantom/pmode-l_FAQ.html
http://www.codeguru.com/forum/showthread.php?threadid=260686

Tutorial's
http://www.acm.uiuc.edu/sigops/roll_your_own/
http://www.cse.unl.edu/~jgompert/OS/TableOfContents.htm
http://www.linuxgazette.com/issue79/krishnakumar.html
http://nocturnalnetwork.com/os.htm
http://osdev.neopages.net.../tutorial_01.php?the_id=8
http://www.delorie.com/dj...errupts/inthandlers1.html
http://www.delorie.com/dj...errupts/inthandlers2.html
http://webster.cs.ucr.edu/Page_asm/ArtOfAsm.html
http://www.osjournal.hopt...tion=viewfile&file=14
http://x86.ddj.com/articles/pmbasics/tspec_a1_doc.htm
http://membres.lycos.fr/placr/pmode/tutor.html
http://my.execpc.com/CE/AC/geezer/osd/cons/
http://www.alumni.caltech.edu/~pje/iso9660.html
http://www.programmershea...5/articles/article157.htm
http://www.opengroup.org/onlinepubs/007904975/toc.htm
http://osdev.neopages.net/tutorials.php?cat=0&sort=1
http://osdev.neopages.net/docs.php?cat=0&sort=1
http://www.wikipedia.org/wiki/FAT
http://alexfru.chat.ru/eindex.html

Link List's
http://www.azillionmonkeys.com/qed/os.html
http://directory.google.c...amming/Operating_Systems/
http://www.geocities.com/SiliconValley/Park/9784/tut.html
http://www.osdev.org/links.jsp
http://my.execpc.com/~geezer/os/
http://aarongray.members....ks/operating-systems.html
http://akson.sgh.waw.pl/~bart/tinos-links.html
http://l4ka.org/publications/
http://aarongray.members.beeb.net/OSPrimer.html
http://www.cmcrossroads.com/bradapp/links/os-links.html

De Interrupt list
http://www.ctyme.com/rbrown.htm

Source voorbeelden
http://newos.sourceforge.net/download.php
http://my.execpc.com/~geezer/osd/boot/a20.asm
http://www.nondot.org/sabre/os/files/Booting/nasmBoot.txt
http://www.alumni.caltech.edu/~pje/rdcf2.txt
http://www.nondot.org/sabre/os/articles
http://my.execpc.com/CE/AC/geezer/osd/
http://my.execpc.com/CE/AC/geezer/os/


Linux
http://linux.ctyme.com/
http://www.kernelhacking.org/docs/kernelhacking-HOWTO/
http://www.kernel.org/pub/linux/kernel/v1.0/
http://members.lycos.nl/oguzdiary/linux-0.01.tar.bz2

Overige Os'en
http://www.cybertrails.com/~fys/fysos.htm
http://www.groovyweb.uklinux.net/index.php?page_name=easyos
http://ansanest.com/josh/
http://users.rcn.com/eaj.pizzi/pizzios/index.html
http://www.theosfiles.com/general/osf_other_sites.htm
http://alexfru.narod.ru/
http://tunes.org/Review/OSes.html
http://www.cse.ogi.edu/DISC/projects/synthetix/related.html
http://www.uw-pc.com/os.html
http://minnie.tuhs.org/UnixTree/

FAT
http://home.no.net/tkos/info/fat.html
http://www.microsoft.com/whdc/hwdev/hardware/fatgendown.mspx

EXT2
http://www.nongnu.org/ext2-doc/
http://uranus.it.swin.edu.au/~jn/explore2fs/es2fs.htm

Geschiedenis
http://www.dei.isep.ipp.pt/docs/unix.html
http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html

Intel Specs
http://x86.ddj.com/intel.doc/inteldocs.htm
http://x86.ddj.com/articles/articles.htm

Newsgroups
alt.os.development
comp.os.linux.development.system
linux.kernel

Als iemand dr meer heeft lijkt het me handig om ze dr gewoon bij te zetten, zodat het niet onoverzichtelijk wordt

[ Voor 233% gewijzigd door Oguz286 op 02-09-2003 18:56 ]

[curry684]

Oguz286 schreef op 31 August 2003 @ 13:36:
Ik wil even met een mod overleggen of ik hier een "Post hier je..." topic van kan maken. Ik denk dat er meerdere mensen hierbij baat zullen hebben.

Mail dan de volgende keer eerst even

Ik zie niet echt wat voor 'post hier je'-topic je hiervan zou willen maken. Als er hier een gezonde discussie losbarst over de inhoudelijke werking van mini-Linuxkernels, be my guest

Mocht je verder vragen hebben: mail me ff

[NeOTheMaTriXM]

http://www.kernel.org/pub/linux/kernel/v1.0/

Hierzo heb je zover ik weet de kleinste Linux kernel.
Mischien kan je nog iets vinden wat ouder is dan v1.0,

[[BoSS]]

Ik denk dan dat je het best de MINIX-kernel kan nemen, als je wilt beginnen met het doorgronden van de UNIX/Linux/etc kernel. Hierna kan je makkelijk overstappen naar de (veel grotere) Linux-kernel.

Hier kan je de source ervan downloaden: http://www.cs.vu.nl/pub/minix/2.0.0/src/

[ Voor 18% gewijzigd door [BoSS] op 31-08-2003 13:48 ]

[Oguz286]

curry684 schreef op 31 August 2003 @ 13:43:
[...]

Mail dan de volgende keer eerst even

Ik zie niet echt wat voor 'post hier je'-topic je hiervan zou willen maken. Als er hier een gezonde discussie losbarst over de inhoudelijke werking van mini-Linuxkernels, be my guest

Mocht je verder vragen hebben: mail me ff

Ja Sorry, ik ben net wakker

Ik heb Glimi net gemaild, en ja mijn doel is eigenlijk om hiervan een topic te maken over hoe de linux kern precies in elkaar zit (maar dan de oude kernels b.v. 0.1 ). En dit dan uit te bouwen tot hedendaagse kernels (alhoewel dat wel even kan duren
Om te leren hoe de pc nu echt werkt en om programmeerervaring op te doen...

[Oguz286]

NeOTheMaTriXM schreef op 31 August 2003 @ 13:46:
http://www.kernel.org/pub/linux/kernel/v1.0/

Hierzo heb je zover ik weet de kleinste Linux kernel.
Mischien kan je nog iets vinden wat ouder is dan v1.0,

Ik heb 0.1 nog ergens op een cd dacht ik. Ik gooi hem straks online...

[phreggle]

Ik denk dat je beter (om te beginnen) bijvoorbeeld het boek van Tanenbaum[1] kan doorlezen omdat: 1) je snel erg gaar wordt van puur oude source code bestuderen. 2) Het boek best leuk is om te lezen.

Verder bevat het boek de complete source code van Minix waar de linux kernel op is gebaseerd (toch? ).

[1] Operating Systems

edit:

Oude linux kernels kan je hier ook vinden:
ftp.nl.kernel.org:/pub/linux/kernel/Historic (inclusief de v0.01)

[ Voor 18% gewijzigd door phreggle op 31-08-2003 13:56 ]

[Oguz286]

phreggle schreef op 31 augustus 2003 @ 13:50:
Ik denk dat je beter (om te beginnen) bijvoorbeeld het boek van Tanenbaum[1] kan doorlezen omdat: 1) je snel erg gaar wordt van puur oude source code bestuderen. 2) Het boek best leuk is om te lezen.

Verder bevat het boek de complete source code van Minix waar de linux kernel op is gebaseerd (toch? ).

[1] Operating Systems

Dat is inderdaad een leuk boek, alleen ik wou er een algemene topic van maken omdat we er dan allemaal profijt van kunnen hebben. Niet iedereen kan €75 euro geven aan een boek (ik niet ), maar als we hier allemaal dingen gaan posten over hoe alles werkt dan kunnen meerdere mensen de wondere wereld van linux en programming meemaken.

En ja hoor... Eh hoe moet ik linken?

[Oguz286]

Oguz286 schreef op 31 August 2003 @ 13:56:
[...]


Dat is inderdaad een leuk boek, alleen ik wou er een algemene topic van maken omdat we er dan allemaal profijt van kunnen hebben. Niet iedereen kan €75 euro geven aan een boek (ik niet ), maar als we hier allemaal dingen gaan posten over hoe alles werkt dan kunnen meerdere mensen de wondere wereld van linux en programming meemaken.

En ja hoor... Eh hoe moet ik linken?

http://members.lycos.nl/oguzdiary/linux-0.01.tar.bz2

Edit: omg zit ik mezelf te quoten...

Ik heb de minix source al: CMD.TAZ en SYS.TAZ, hoe moet ik ze openen? Winrar kan ze niet openen.

Misschien kunnen we later zelfs een GoTuX maken

[ Voor 17% gewijzigd door Oguz286 op 31-08-2003 14:13 ]

[PrisonerOfPain]

phreggle schreef op 31 August 2003 @ 13:50:
Ik denk dat je beter (om te beginnen) bijvoorbeeld het boek van Tanenbaum[1] kan doorlezen omdat: 1) je snel erg gaar wordt van puur oude source code bestuderen. 2) Het boek best leuk is om te lezen.

Verder bevat het boek de complete source code van Minix waar de linux kernel op is gebaseerd (toch? ).

[1] Operating Systems

edit:

Oude linux kernels kan je hier ook vinden:
ftp.nl.kernel.org:/pub/linux/kernel/Historic (inclusief de v0.01)

Nope die source zit bij Design and Implantation, ook van Tanenbaum

[NeOTheMaTriXM]

http://www.zeh.com/theplot/winter97/plot9_taz.htm

Verhaaltje over TAZ files.
(Dit is zeer makenlijk vindbaar met google hoor )

[[BoSS]]

Volgens mij is dat gewoon een TAR/GZIP. Probeer dus eerst te decompressen met gzip en daarna met tar.

[Oguz286]

NeOTheMaTriXM schreef op 31 August 2003 @ 14:20:
http://www.zeh.com/theplot/winter97/plot9_taz.htm

Verhaaltje over TAZ files.
(Dit is zeer makenlijk vindbaar met google hoor )

B_O_S_S schreef op 31 August 2003 @ 14:21:
Volgens mij is dat gewoon een TAR/GZIP. Probeer dus eerst te decompressen met gzip en daarna met tar.

Sorrie, mijn fout. Het werkt al...

En nu komt wat ik bedoel, waar begint de pc mee als ie opstart, en welk bestand van minix wordt als eerst geladen, enz,enz... Daar moeten vragen en antwoorden over en op komen

[Spider.007]

Oguz286 schreef op 31 August 2003 @ 14:37:
[...]


[...]


Sorrie, mijn fout. Het werkt al...

En nu komt wat ik bedoel, waar begint de pc mee als ie opstart, en welk bestand van minix wordt als eerst geladen, enz,enz... Daar moeten vragen en antwoorden over en op komen

Ik wil niet vervelend overkomen; maar dit soort vragen lijken mij een beetje te basic om het topic uit te kunnen laten groeien tot een discussiedraad over de Linux Kernel (die naar mijn inzicht beter in NOS staat). Kun je je niet beter verdiepen in wat basic PC zaken zoals wat een PC precies doet bij het opstarten (BIOS / MBR ed.)

[Oguz286]

Spider.007 schreef op 31 augustus 2003 @ 15:10:
[...]


Ik wil niet vervelend overkomen; maar dit soort vragen lijken mij een beetje te basic om het topic uit te kunnen laten groeien tot een discussiedraad over de Linux Kernel (die naar mijn inzicht beter in NOS staat). Kun je je niet beter verdiepen in wat basic PC zaken zoals wat een PC precies doet bij het opstarten (BIOS / MBR ed.)

Ja, het zou juist leuk zijn om vanaf het begin te beginnen (maar je hebt gelijk, daar kan je beter een andere topic voor beginnen). Ik weet niet hoe de pc begint met opstarten (ja bios, maar hoe precies?) Als jullie daar wat links voor hebben zou dat wel fijn zijn (ga zelf ook zoeken)

Maar jullie begrijpen toch wel wat ik zo bedoel?

[ Voor 11% gewijzigd door Oguz286 op 31-08-2003 15:14 ]

[curry684]

Uit de oude doos: [rml][ tutorial] how to write your own OS[/rml]

Vanaf hier trouwens echt interessant: [rml]JayTaph in "[ tutorial] how to write your own OS"[/rml]

[ Voor 34% gewijzigd door curry684 op 31-08-2003 15:35 ]

[Oguz286]

curry684 schreef op 31 augustus 2003 @ 15:35:
Uit de oude doos: [rml][ tutorial] how to write your own OS[/rml]

Vanaf hier trouwens echt interessant: [rml]JayTaph in "[ tutorial] how to write your own OS"[/rml]

MIJN HELD

Ja zoiets dus maar dan met hulp van alle tweakers, zodat dit topic meer een tutorial wordt (das mijn visie )

[ Voor 15% gewijzigd door Oguz286 op 31-08-2003 15:41 ]

[_Squatt_]

De From-Power-Up-To-Bash-Prompt howto geeft ook aardig wat informatie.

This is a brief description of what happens in a Linux system, from the time that you turn on the power, to the time that you log in and get a bash prompt.

[phreggle]

PrisonerOfPain schreef op 31 August 2003 @ 14:20:
[...]


Nope die source zit bij Design and Implantation, ook van Tanenbaum

offtopic:
Oeps sorry nu je het zegt... Ik wist dat ik een boek in de kast had staan met de source erbij en ik dacht dat het die was. Alleen die boekenkast staat op het moment 10km verderop dus ik kon het niet controleren.

[PrisonerOfPain]

@ _Squat_, mischien even handig om de url te vermelden , k heb m nou zelf gevonden (http://axiom.anu.edu.au/~okeefe/p2b/)


Alle links staan nu in de startpost

[ Voor 255% gewijzigd door PrisonerOfPain op 02-09-2003 09:30 ]

[Oguz286]

PrisonerOfPain schreef op 31 August 2003 @ 16:30:
@ _Squat_, mischien even handig om de url te vermelden , k heb m nou zelf gevonden (http://axiom.anu.edu.au/~okeefe/p2b/)


ik heb nog wat leuke links opgezocht

FAQ's
http://www.mega-tokyo.com/os/os-faq.html
http://www.overwhelmed.org/shawn/faq.html
http://www.linuxgazette.com/issue82/raghu.html

Tutorial's
http://www.acm.uiuc.edu/sigops/roll_your_own/
http://www.cse.unl.edu/~jgompert/OS/TableOfContents.htm
http://www.linuxgazette.com/issue79/krishnakumar.html
http://nocturnalnetwork.com/os.htm

Link List's
http://www.azillionmonkeys.com/qed/os.html
http://directory.google.c...amming/Operating_Systems/

Als iemand dr meer heeft lijkt het me handig om ze dr gewoon bij te zetten, zodat het niet onoverzichtelijk wordt

WOW, dit forum zit echt vol helden
Ik ga mijn startpost morgen veranderen en zet alles wel netjes geordernd neer zodat mede tweakers er wat aan hebben.

Ik heb net mijn eerste bootstrap progje geschreven. Als jullie intresse hebben dan wil ik wel nog heel wat meer links en zelfs een tut schrijven over hoe je zoiets aanpakt. Bij belang, post maar of stuur een email naar [e-mail]

Een verzoek voor titelchange naar iets in de richting van hoe je een compleet os kan schrijven en hoe linux dat aanpakt (of minix)

[ Voor 6% gewijzigd door Oguz286 op 31-08-2003 22:21 ]

[PrisonerOfPain]

Ik heb wel interesse in z'n tutorial, k probeer me al een paar maanden er toe te zetten om een OS te schrijven, maar het wil maar niet lukken dus elke sta in die richting, is er een

[Glimi]

Oguz286 schreef op 31 August 2003 @ 13:47:
Ik heb Glimi net gemaild, en ja mijn doel is eigenlijk om hiervan een topic te maken over hoe de linux kern precies in elkaar zit (maar dan de oude kernels b.v. 0.1 ). En dit dan uit te bouwen tot hedendaagse kernels (alhoewel dat wel even kan duren
Om te leren hoe de pc nu echt werkt en om programmeerervaring op te doen...

Ik zag het ja
Op zich vind ik dat een leuk idee, maar dan moet het ook wel educatief worden. Als iemand code neergooit, dan moet er wel uitleg bij, wat het doet, waar het geplaatst moet worden enz. enz. Kortom als het maar flink informatief is, dan is het goed

[Oguz286]

OK DAN

Ik ga het vandaag ff goed aanpakken en alles zo basic mogelijk uitleggen zodat zelfs niet asm'ers het kunnen begrijpen (zo leer ik tenminste commentaar te gebruiken )

Ik moet nu naar school, dus als er iets nuttigs is wat jullie vinden, stuur maar een mailtje

[Oguz286]

De een zijn dood, de ander zijn brood...

He stomste wat kan gebeuren is net gebeurd. Ik ben mijn sleutels op school verloren en mijn ouders hebben het huis potdicht achtergelaten. Ik kan dus niet naar school, maar dat betekent dat ik aan mijn startpost ga werken

Glimi, you've got mail

[ Voor 7% gewijzigd door Oguz286 op 01-09-2003 09:43 ]

[PrisonerOfPain]

Oguz286 schreef op 31 augustus 2003 @ 13:36:

code:

; HANG.ASM
    ; Een minimale bootstrap!

    hang:                   ; Hang!
          jmp hang

    times 510-($-$$) db 0   ; Vul het bestand met nullen
    dw 0AA55h               ; Eindig het bestand met AA55

je kan hier beter

code:

; HANG_REV01.ASM
;een minimale bootstrap
cli; stop interupts die de CPU wakker maken
hlt;
times 510-($-$$) db 0; veel nullen
dw 0AA55h; eindig met AA55

van maken omdat jou code de CPU 100% stressed, wat nooit echt goed is voor een CPU, hlt daar in tegen stopt de CPU helemaal, wat zorgt voor een 0% stressed

edit:

ja dit was doorgestoken kaart , dom cli vergeten

[ Voor 9% gewijzigd door PrisonerOfPain op 01-09-2003 20:21 ]

[Oguz286]

PrisonerOfPain schreef op 01 September 2003 @ 19:25:
[...]


je kan hier beter

code:

; HANG_REV01.ASM
;een minimale bootstrap
hlt;
times 510-($-$$) db 0; veel nullen
dw 0AA55h; eindig met AA55

van maken omdat jou code de CPU 100% stressed, wat nooit echt goed is voor een CPU, hlt daar in tegen stopt de CPU helemaal, wat zorgt voor een 0% stressed

edit:

ja dit was doorgestoken kaart

Het gaat natuurlijk om de programmeer ervaring:

HLT komt van halt en stopt de processor... weer wat geleerd

[Oguz286]

Sorry lui dat deel 2 zich lang op zich laat wachten... Ik zit nu op school, maar binnenkort zal ik weer wat gaan posten. (PrisonerOfPain en ik zijn druk bezig alles uit te vogelen)

[Verwijderd]

Als je wat geld te besteden hebt, dan is "Understanding the Linux Kernel" van O'Reilly toch echt wel een interessant boek om aan te schaffen!!

[.oisyn]

Natuurlijk kom je met plain assembly niet echt ver. De bootloader schrijf je meestal in assembly, maar het is verstandig om na het switchen naar 32 bits protected mode gelijk naar C code te jumpen, dat maakt het geheel een stuk overzichtelijker

[alienfruit]

Uh. Gaan we alweer een OS maken??, vorige liep het project dood... Maar goed dat is ook al een hele tijd terug...

[Tux]

alienfruit schreef op 03 september 2003 @ 11:28:
Uh. Gaan we alweer een OS maken??, vorige liep het project dood... Maar goed dat is ook al een hele tijd terug...

We gaan niet met z'n allen een OS maken. Iedereen mag voor zichzelf leren hoe het moet

[alienfruit]

Ooh Ooh. Gelukkig

[ Voor 3% gewijzigd door alienfruit op 03-09-2003 11:48 ]

[Oguz286]

.oisyn schreef op 03 September 2003 @ 10:44:
Natuurlijk kom je met plain assembly niet echt ver. De bootloader schrijf je meestal in assembly, maar het is verstandig om na het switchen naar 32 bits protected mode gelijk naar C code te jumpen, dat maakt het geheel een stuk overzichtelijker

alienfruit schreef op 03 September 2003 @ 11:28:
Uh. Gaan we alweer een OS maken??, vorige liep het project dood... Maar goed dat is ook al een hele tijd terug...

Tux schreef op 03 September 2003 @ 11:31:
[...]
[...]
We gaan niet met z'n allen een OS maken. Iedereen mag voor zichzelf leren hoe het moet

Dit wordt een tutorial hoe je een OS moet schrijven, met linux-achtig os als uitgangspunt
En ja die andere liep dood en ik hoop dat dit het niet wordt want ik wil een os schrijven, maar als ik een tutorial maak hebben meer mensen er wat aan
Maar die tutorial ben ik nu aan het schrijven dus nog heel even geduld

[ Voor 59% gewijzigd door Oguz286 op 03-09-2003 14:58 ]

[Oguz286]

Ik heb een vraag voor de slimmeriken: waarom is 0x9000h een goede plaats voor een stack? Weet iemand waar ik de geheugenindeling van een pc kan vinden? Welke geheugenplaatsen zijn gereserveerd en welke niet (zodat ik ze kan gebruiken)?

BVD

[yrew]

Worden de gereserveerde plaatsen niet bepaald door het os?

[Oguz286]

yrew schreef op 03 september 2003 @ 15:56:
Worden de gereserveerde plaatsen niet bepaald door het os?

Ja alleen wij maken de OS Er staat in zo'n tutorial die ik had gevonden dit:

cli ; clear interrupts while we setup a stack
mov ax,0x9000 ; this seems to be the typical place for a stack
mov ss,ax
mov sp,0xffff ; let's use the whole segment. Why not? We can
sti ; put our interrupts back on

Ik wil een memorymap van de ibm compatible pc, zodat ik weet welke geheugenplaatsen ik kan gebruiken

[Verwijderd]

Zoiets?
1 Mb = 0x10000:0000


1 Mb-1 = 0xFFFF:000F End System BIOS area
960 Kb 0xF000:0000 | = 128 Kb
896 Kb 0xE000:0000 Start System BIOS area


896 Kb-1 = 0xDFFF:000F End Expansion card BIOS area
832 Kb 0xD000:0000 | = 128 Kb
768 Kb 0xC000:0000 Start Expansion card BIOS area


768 Kb-1 = 0xBFFF:000F End Video RAM
704 Kb 0xB000:0000 | = 128 Kb
640 Kb 0xA000:0000 Start Video RAM


640 Kb-1 = 0x9FFF:000F End DOS RAM
576 Kb 0x9000:0000 |
512 Kb 0x8000:0000 |
448 Kb 0x7000:0000 |
384 Kb 0x6000:0000 |
320 Kb 0x5000:0000 | = 640 Kb
256 Kb 0x4000:0000 |
192 Kb 0x3000:0000 |
128 Kb 0x2000:0000 |
64 Kb 0x1000:0000 |
0 Kb 0x0000:0000 Start DOS RAM
http://savage.net.au/Ron/html/hex-ram-tutorial.html

Ik ben hier helemaal niet in thuis maar...
Mss moet je eens proberen je pc in een rekenmachine om te toveren.
Dus eerst zelf je bootloader typen en dan in asm of c (mss c handiger) een rekenmachientje proggen, als test.

Zo kan je eens laten zien wat je kan en heb je direct een mooi voorbeeld als je hier een faq-achtigtopic wilt van maken.

[ Voor 21% gewijzigd door Verwijderd op 03-09-2003 20:11 . Reden: geniale inval! ]

[.oisyn]

Oguz286 schreef op 03 September 2003 @ 15:51:
Ik heb een vraag voor de slimmeriken: waarom is 0x9000h een goede plaats voor een stack? Weet iemand waar ik de geheugenindeling van een pc kan vinden? Welke geheugenplaatsen zijn gereserveerd en welke niet (zodat ik ze kan gebruiken)?

BVD

ik neem aan dat je nog in realmode zit? Let erop dat het dan adres 0x90000 wordt, en met de 0xffff van de offset erbij natuurlijk 0x9ffff.

Bij 0xa0000 begint het videogeheugen. Zo'n beetje van 0xa0000 tot 0xfffff bevindt zich alleen maar hardware (RAM en ROM)

op 0x9ffff en lager is dus vrij geheugen. Denk eraan dat de stack omlaag gaat: als je er een waarde op push'd, dan wordt de stackpointer verminderd. Let er trouwens op dat [ss:sp] wijst naar de waarde die gepop'd wordt. Als je er een 16 bits waarde op push'd, dan wordt eerst sp verlaagd met 2, en vervolgens wordt de nieuwe waarde op de nieuwe [ss:sp] geschreven. Omdat je 16 bits getallen het best kunt alignen op 2 bytes, kun je het adres beter laten beginnen bij 0x9fffe

Overigens hoef je de stack niet zover weg te zetten, je hoeft toch niet zoveel te pushen in de bootloader.


Als je overschakeld naar 32 bits protected mode, kun je de stack eigenlijk overal zetten, maar denk eraan dat de stack altijd omlaag gaat, dus een zo'n hoge mogelijke waarde is vrij zinnig. Bovendien is het verstandig om met paging te werken, dus je kunt je geheugen indelen zoals jij wilt.

In win32 is het als volgt geregeld: de onderste 2 gb van de address space (0x0 - 0x7fffffff) is voor het proces zelf. Die begint overigens bij 0x10000, zodat 16 bits waarden geen valide pointers zijn (dit kan nuttig zijn voor sommige dingen). Let erop dat je er goed aan doet om 0x0000 iig geen valide adres te laten zijn, zodat je programma crasht als je een null pointer probeert te dereferencen.

De range 2-3 gb (0x80000000 - 0xbfffffff) was in win9x gereserveerd voor systemwide shared resources, maar op winnt bakken kan dat overal zijn. De range 3-4 gb (0xc0000000 - 0xffffffff) is kernel space

[PrisonerOfPain]

.oisyn schreef op 03 September 2003 @ 20:20:
[...]

Overigens hoef je de stack niet zover weg te zetten, je hoeft toch niet zoveel te pushen in de bootloader.

En de kernel dan? gebruikt die dan weer een heel ander adres daarvoor?

In win32 is het als volgt geregeld: de onderste 2 gb van de address space (0x0 - 0x7fffffff) is voor het proces zelf. Die begint overigens bij 0x10000, zodat 16 bits waarden geen valide pointers zijn (dit kan nuttig zijn voor sommige dingen). Let erop dat je er goed aan doet om 0x0000 iig geen valide adres te laten zijn, zodat je programma crasht als je een null pointer probeert te dereferencen.

De range 2-3 gb (0x80000000 - 0xbfffffff) was in win9x gereserveerd voor systemwide shared resources, maar op winnt bakken kan dat overal zijn. De range 3-4 gb (0xc0000000 - 0xffffffff) is kernel space

gb??? als in gigabyte???

[.oisyn]

PrisonerOfPain schreef op 03 September 2003 @ 20:28:
[...]


En de kernel dan? gebruikt die dan weer een heel ander adres daarvoor?

je pushed toch niet de hele kernel op de stack, of wel soms?

gb??? als in gigabyte???

gigabyte idd. De 32 bits x86 processor heeft een 32 bits adreslijn, en kan dus 4 GB aan (virtueel) geheugen aanspreken

[PrisonerOfPain]

.oisyn schreef op 03 September 2003 @ 20:59:
[...]


je pushed toch niet de hele kernel op de stack, of wel soms?

Nou..................................

Nee, maar ik mag toch wel aannemen dat de kernel ook popt en pucht, naar een stack, het lijkt mij dat dat die dan (mmm veel woorden met een 'd') is?

[...]


gigabyte idd. De 32 bits x86 processor heeft een 32 bits adreslijn, en kan dus 4 GB aan (virtueel) geheugen aanspreken

Maar een pc heeft helemaal geen 4 GB aan geheugen, hoe wil je dit dan opdelen? 'Gewoon' alles percentueel gelijk houden, of op een andere manier? Swap-en bijvoorbeeld, lijkt mij sterk aangezien er in de tijd van de 2- 386 nog geen schijven waren voor thuisgebruik van die omvang

BTW waar heb jij al die informatie vandaan? Ik heb dat van 0x9000 + FFF niet in Moderne Operating Sytems zien staan

[Verwijderd]

Dat is inderdaad een leuk boek, alleen ik wou er een algemene topic van maken omdat we er dan allemaal profijt van kunnen hebben. Niet iedereen kan €75 euro geven aan een boek (ik niet ), maar als we hier allemaal dingen gaan posten over hoe alles werkt dan kunnen meerdere mensen de wondere wereld van linux en programming meemaken.

Op de HIO hebben wij over dit onderwerp een goed boek moeten kopen. Die heb ik nu dus wel voor je over. Het heet Operating System Design, de XINU approach. Mag je van mij hebben.. Ook het boek van tannebaum (operating systems) heb ik wel voor je over. Dus as je interesse hebt, mail staat in me sig. Komen die boeken ook weer iemand van pas..

_{Geen idee waarom mijn quote's niet werken trouwens...}

omdat je een prutser bent en [/qoute] als close tag gebruikte

[ Voor 20% gewijzigd door curry684 op 04-09-2003 22:12 . Reden: o.s. ipv comp arch ]

[.oisyn]

PrisonerOfPain schreef op 03 September 2003 @ 21:05:
Nee, maar ik mag toch wel aannemen dat de kernel ook popt en pucht, naar een stack, het lijkt mij dat dat die dan (mmm veel woorden met een 'd') is?

let erop dat je in de bootloader nog in 16 bits realmode zit. De kernel is, in het efficienste geval, 32 bits protected mode. Die stack op 0x9ffff is dus maar tijdelijk

Maar een pc heeft helemaal geen 4 GB aan geheugen, hoe wil je dit dan opdelen? 'Gewoon' alles percentueel gelijk houden, of op een andere manier? Swap-en bijvoorbeeld, lijkt mij sterk aangezien er in de tijd van de 2- 386 nog geen schijven waren voor thuisgebruik van die omvang

1 woord: paging
Je kunt met paging je hele fysieke geheugen mappen in de 4 GB adres ruimte (in pages, dus blokken van 4096 bytes, weliswaar). Vandaar ook de mogelijkheid van virtueel geheugen en het swappen. Als al je fysieke geheugen al gemapped is, maar een proces heeft meer nodig, dan geef je 'm gewoon meer zonder dat dat mapped naar echt geheugen. Als de applicatie dan toegang probeert te krijgen tot dat stukje geheugen, dan genereert de cpu een exceptie (een page fault), en kun je in de handler daarvan een andere page uit het geheugen laden, en de nieuwe activeren.

BTW waar heb jij al die informatie vandaan? Ik heb dat van 0x9000 + FFF niet in Moderne Operating Sytems zien staan

pff weet ik niet, ik hobby er al sinds het DOS tijdperk mee... Ik heb al die kennis in de loop der tijd vergaart Ik geloof dat ik het meeste uit een boek heb gehaald wat ik hier heb liggen, "200 utilities voor MS- en PC-DOS" heet het geloof ik. Daar stonden vooral veel asm-dingen in

[Oguz286]

[quote]Verwijderd schreef op 03 september 2003 @ 21:18:

Dat is inderdaad een leuk boek, alleen ik wou er een algemene topic van maken omdat we er dan allemaal profijt van kunnen hebben. Niet iedereen kan €75 euro geven aan een boek (ik niet ), maar als we hier allemaal dingen gaan posten over hoe alles werkt dan kunnen meerdere mensen de wondere wereld van linux en programming meemaken.
[/qoute]

Op de HIO hebben wij over dit onderwerp een goed boek moeten kopen. Die heb ik nu dus wel voor je over. Het heet Operating System Design, de XINU approach. Mag je van mij hebben.. Ook het boek van tannebaum (operating systems) heb ik wel voor je over. Dus as je interesse hebt, mail staat in me sig. Komen die boeken ook weer iemand van pas..

_{Geen idee waarom mijn quote's niet werken trouwens...}

Wow, daar zouden ik inderdaad (en indirect de tweakers) heel wat van kunnen leren van die boeken. Daar heb ik maar een woord voor:

[Oguz286]

.oisyn schreef op 03 September 2003 @ 20:20:
[...]


ik neem aan dat je nog in realmode zit? Let erop dat het dan adres 0x90000 wordt, en met de 0xffff van de offset erbij natuurlijk 0x9ffff.

Bij 0xa0000 begint het videogeheugen. Zo'n beetje van 0xa0000 tot 0xfffff bevindt zich alleen maar hardware (RAM en ROM)

op 0x9ffff en lager is dus vrij geheugen. Denk eraan dat de stack omlaag gaat: als je er een waarde op push'd, dan wordt de stackpointer verminderd. Let er trouwens op dat [ss:sp] wijst naar de waarde die gepop'd wordt. Als je er een 16 bits waarde op push'd, dan wordt eerst sp verlaagd met 2, en vervolgens wordt de nieuwe waarde op de nieuwe [ss:sp] geschreven. Omdat je 16 bits getallen het best kunt alignen op 2 bytes, kun je het adres beter laten beginnen bij 0x9fffe

Overigens hoef je de stack niet zover weg te zetten, je hoeft toch niet zoveel te pushen in de bootloader.


Als je overschakeld naar 32 bits protected mode, kun je de stack eigenlijk overal zetten, maar denk eraan dat de stack altijd omlaag gaat, dus een zo'n hoge mogelijke waarde is vrij zinnig. Bovendien is het verstandig om met paging te werken, dus je kunt je geheugen indelen zoals jij wilt.

In win32 is het als volgt geregeld: de onderste 2 gb van de address space (0x0 - 0x7fffffff) is voor het proces zelf. Die begint overigens bij 0x10000, zodat 16 bits waarden geen valide pointers zijn (dit kan nuttig zijn voor sommige dingen). Let erop dat je er goed aan doet om 0x0000 iig geen valide adres te laten zijn, zodat je programma crasht als je een null pointer probeert te dereferencen.

De range 2-3 gb (0x80000000 - 0xbfffffff) was in win9x gereserveerd voor systemwide shared resources, maar op winnt bakken kan dat overal zijn. De range 3-4 gb (0xc0000000 - 0xffffffff) is kernel space

Dit is een stukje code wat ik dus niet snap:

start:
mov ax,0x7c0 ; BIOS puts us at 0:07C00h, so set DS accordinly
mov ds,ax ; Therefore, we don't have to add 07C00h to all our
data

mov [bootdrv], dl ; quickly save what drive we booted from

cli ; clear interrupts while we setup a stack
mov ax, 0x9000 ; this seems to be the typical place for a stack
mov ss,ax
mov sp, 0xffff ; let's use the whole segment. Why not? We can
sti ; put our interrupts back on

; Interestingly enough, apparently the processor will disable
; interupts itself when you directly access the stack segment!
; Atleast it does in protected mode, I'm not sure about real mode.


Let op de dikgedrukte waarden. Waarom nou 0x9000? Jij zegt 0x90000 Dat wil ik weten En als ik dit zo zie...

Verwijderd schreef op 03 September 2003 @ 20:01:
Zoiets?
1 Mb = 0x10000:0000


1 Mb-1 = 0xFFFF:000F End System BIOS area
960 Kb 0xF000:0000 | = 128 Kb
896 Kb 0xE000:0000 Start System BIOS area


896 Kb-1 = 0xDFFF:000F End Expansion card BIOS area
832 Kb 0xD000:0000 | = 128 Kb
768 Kb 0xC000:0000 Start Expansion card BIOS area


768 Kb-1 = 0xBFFF:000F End Video RAM
704 Kb 0xB000:0000 | = 128 Kb
640 Kb 0xA000:0000 Start Video RAM


640 Kb-1 = 0x9FFF:000F End DOS RAM
576 Kb 0x9000:0000 |
512 Kb 0x8000:0000 |
448 Kb 0x7000:0000 |
384 Kb 0x6000:0000 |
320 Kb 0x5000:0000 | = 640 Kb
256 Kb 0x4000:0000 |
192 Kb 0x3000:0000 |
128 Kb 0x2000:0000 |
64 Kb 0x1000:0000 |
0 Kb 0x0000:0000 Start DOS RAM
http://savage.net.au/Ron/html/hex-ram-tutorial.html

Ik ben hier helemaal niet in thuis maar...
Mss moet je eens proberen je pc in een rekenmachine om te toveren.
Dus eerst zelf je bootloader typen en dan in asm of c (mss c handiger) een rekenmachientje proggen, als test.

Zo kan je eens laten zien wat je kan en heb je direct een mooi voorbeeld als je hier een faq-achtigtopic wilt van maken.

Let weer op de dikgedrukte waarden. Als ik dit lees dan snap ik dat ik helemaal bovenaan mijn 640k bereik zit en omdat de pointer juist omlaag gaat is dit goed uitgekozen. Maar klopt dit wat ik denk?

[_the_crow_]

Ik persoonlijk vind het vreemd om je stack op 0x9FFFF te zetten. Het is helemaal geen typical place trouwens. Ik had hem eerder lager gezet in je geheugen, maar goed...dat is mijn keuze. SS:SP point dus naar de top van de stack.
Je stack 'werkt' van boven naar beneden. Dus in principe in omgekeerde volgorde.

Stel dat de stack op 0x9000:0xFFFF begint. En je PUSHt 1 word op de stack dan wordt de waarde van SP met 2 bytes verlaagd.
SS:SP wordt dan 0x9000:0xFFFD. POP je dan weer een word van de stack af dan krijg je de waarde van het stack in een opgegeven register en wordt SP weer met 2 bytes verhoogd (als het een word (16-bit) betrof).

_{PUSH en POP zijn commando's in assembly om word/dwords resp. op stack te zetten en er vanaf te halen. (voor degene die dat niet snapte)}

Verder vind ik het een beetje vreemd om 1 MB te beschouwen als 0x10000:0x0000. Dit is onmogelijk omdat een segment-register maar 16 bit is en dus nooit de waarde 0x10000 kan bevatten. 1 MB zou dan 0xFFFF:0x0010 worden.

@Oguz286: Wat je dacht klopt dus.

@Mensen die dachten dat dit makkelijk was: Think again!

[ Voor 45% gewijzigd door _the_crow_ op 03-09-2003 22:40 ]

[Oguz286]

_the_crow_ schreef op 03 September 2003 @ 22:27:
Ik persoonlijk vind het vreemd om je stack op 0x9FFFF te zetten. Het is helemaal geen typical place trouwens. Ik had hem eerder lager gezet in je geheugen, maar goed...dat is mijn keuze. SS:SP point dus naar de top van de stack.
Je stack 'werkt' van boven naar beneden. Dus in principe in omgekeerde volgorde.

Stel dat de stack op 0x9000:0xFFFF begint. En je PUSHt 1 word op de stack dan wordt de waarde van SP met 2 bytes verlaagd.
SS:SP wordt dan 0x9000:0xFFFD. POP je dan weer een word van de stack af dan krijg je de waarde van het stack in een opgegeven register en wordt SP weer met 2 bytes verhoogd (als het een word (16-bit) betrof).

_{PUSH en POP zijn commando's in assembly om word/dwords resp. op stack te zetten en er vanaf te halen. (voor degene die dat niet snapte)}

Verder vind ik het een beetje vreemd om 1 MB te beschouwen als 0x10000:0x0000. Dit is onmogelijk omdat een segment-register maar 16 bit is en dus nooit de waarde 0x10000 kan bevatten. 1 MB zou dan 0xFFFF:0x0010 worden.

@Oguz286: Wat je dacht klopt dus.

@Mensen die dachten dat dit makkelijk was: Think again!

Dank je, weer wat geleerd
Ik snap niet hoe iedereen bij 0x90000 komt terwijl in de sourcecode 0x9000 staat Maarja nu is het wat duidelijker

BTW: Die altos =

[_the_crow_]

Ik wil ook nog even opmerken dat van offset 0x000 tot 0x400 de IVT (Interrupt Vector Table) staat. Hierin staan vectoren die verwijzen naar de interrupts gebruikt door het BIOS.
Dus niet dat mensen hier lukraak code neer gaan gooien.
Overigens is het ook zo dat je alleen de interrupts 0x0 tot 0x1F kan gebruiken, omdat alleen dat BIOS-interrupts zijn. De overigen (0x20-0xFF) zijn o.a. DOS-interrupts.

Oguz286 schreef op 03 September 2003 @ 22:41:
BTW: Die altos =

Hé hé hé niet schelden he....tis Atlos.
Maar het wordt idd wel aardig ja. Nog niets grafisch, maar dat komt nog wel in een volgende versie 0.0.2 ofzo.

[ Voor 27% gewijzigd door _the_crow_ op 03-09-2003 22:51 ]

[.oisyn]

Oguz286 schreef op 03 September 2003 @ 22:14:
Let op de dikgedrukte waarden. Waarom nou 0x9000? Jij zegt 0x90000 Dat wil ik weten En als ik dit zo zie...

segmet/offset pairs.
In real-mode adresseer je als segment:offset. Het eigenlijke adres in het fysieke geheugen is segment * 16 + offset, dus 0x9000 * 0x10 + 0xffff = 0x9ffff
Maar zoals ik al zei, denk aan de alignment! Je pushed steeds 2 bytes, dus align 'm ook op 2 bytes (en dus doe je 'm op 0x9fffe)

Let weer op de dikgedrukte waarden. Als ik dit lees dan snap ik dat ik helemaal bovenaan mijn 640k bereik zit en omdat de pointer juist omlaag gaat is dit goed uitgekozen. Maar klopt dit wat ik denk?

dat klopt helemaal

_the_crow_ schreef op 03 September 2003 @ 22:27:
Ik persoonlijk vind het vreemd om je stack op 0x9FFFF te zetten. Het is helemaal geen typical place trouwens. Ik had hem eerder lager gezet in je geheugen, maar goed...dat is mijn keuze.

Waarom? In principe moet je ervoor zorgen dat je heap je stack niet overschrijft (en andersom). Als je het hele geheugenbereik voor je beschikbaar hebt, dan is een typische indeling dat je programmacode in de onderste regionen zit, de data daarna, daarna volgt de heap die oploopt, en helemaal aan het eind de stack die afloopt.
Nou zou in een 16 bits programma de stack altijd maar max. 64 kb bedragen, en die kun je dan ook net zo goed in een ander segment zetten (want onder de 0x90000 komt ie nooit)

_{PUSH en POP zijn commando's in assembly om word/dwords resp. op stack te zetten en er vanaf te halen. (voor degene die dat niet snapte)}

push en pop zijn algemene woorden die worgen gebruikt bij stack structuren, de assembly instructies zijn daar weer vanaf geleid. Dus ook degene die wel bekend zijn met coden maar geen assembly kennen zullen het begrijpen

Verder vind ik het een beetje vreemd om 1 MB te beschouwen als 0x10000:0x0000. Dit is onmogelijk omdat een segment-register maar 16 bit is en dus nooit de waarde 0x10000 kan bevatten. 1 MB zou dan 0xFFFF:0x0010 worden.

En dat is dus weer heel fijn adres 0x0000:0x0000, aangezien de A20 address line standaard uit staat in real mode
(dat betekent dus dat de 20e baan op de geheugenbus, oftewel bit 20 van het adres, is gehardwired op 0, waardoor het niet mogelijk is om boven de 1 mb uit te komen.) Deze lijn is wel aan te zetten, waardoor je idd nog iets verder komt (een truuc dat DOS gebruikte om zich in het hoge geheugen te laden als ik me niet vergis)

@Mensen die dachten dat dit makkelijk was: Think again!

het is niet moeilijk, het komt vooral neer op kennis

[.oisyn]

_the_crow_ schreef op 03 September 2003 @ 22:49:
Ik wil ook nog even opmerken dat van offset 0x000 tot 0x400 de IVT (Interrupt Vector Table) staat. Hierin staan vectoren die verwijzen naar de interrupts gebruikt door het BIOS.
Dus niet dat mensen hier lukraak code neer gaan gooien.
Overigens is het ook zo dat je alleen de interrupts 0x0 tot 0x1F kan gebruiken, omdat alleen dat BIOS-interrupts zijn. De overigen (0x20-0xFF) zijn o.a. DOS-interrupts.

We zijn hier bezig met een eigen OS, en DOS is dus niet aanwezig
Overigens zijn interrupts 0 t/m 0x1f gereserveerd voor het systeem zelf (in de hogere regionen ook een paar overigens), vandaar dat DOS alleen 0x20 en hoger gebruikt.

[_the_crow_]

.oisyn schreef op 03 September 2003 @ 22:49:
Waarom? In principe moet je ervoor zorgen dat je heap je stack niet overschrijft (en andersom). Als je het hele geheugenbereik voor je beschikbaar hebt, dan is een typische indeling dat je programmacode in de onderste regionen zit, de data daarna, daarna volgt de heap die oploopt, en helemaal aan het eind de stack die afloopt.
Nou zou in een 16 bits programma de stack altijd maar max. 64 kb bedragen, en die kun je dan ook net zo goed in een ander segment zetten (want onder de 0x90000 komt ie nooit)

Ja das waar. Helemaal gelijk. Ik zit ff in Protected mode te denken. Dan is de stack niet beperkt door de 64k boundary.

Het is niet moeilijk, het komt vooral neer op kennis

Ik zou willen dat dat waar was. Ik heb genoeg knelpunten ontdekt om te weten dat het zeker niet makkelijk is. Maar dat is dan vooral in Protected-Mode als je eigen functies gaat maken. Maar dat is nog niet aan de orde hier.

.oisyn schreef op 03 September 2003 @ 22:53:
We zijn hier bezig met een eigen OS, en DOS is dus niet aanwezig
Overigens zijn interrupts 0 t/m 0x1f gereserveerd voor het systeem zelf (in de hogere regionen ook een paar overigens), vandaar dat DOS alleen 0x20 en hoger gebruikt.

Tuurlijk. DOS is niet standaard in het BIOS aanwezig, dus vanzelfsprekend de interrupts ook niet. Slechts de vectoren 0x00 tot 0x1F verwijzen dus naar interrupts.
En over die hogere regionen betreft. Daar staat de interrupt-code. 'Onderin' het geheugen staan slechts de vectoren die ernaar verwijzen.

[ Voor 30% gewijzigd door _the_crow_ op 03-09-2003 23:11 ]

[.oisyn]

Ik bedoelde hogere interrupt-vectoren, zoals interrupt 0x70 e.d.
(op 0x70 - 0x77 zit IRC8 t/m IRQ15)

[ Voor 22% gewijzigd door .oisyn op 03-09-2003 23:22 ]

[_the_crow_]

.oisyn schreef op 03 September 2003 @ 23:20:
Ik bedoelde hogere interrupt-vectoren, zoals interrupt 0x70 e.d.
(op 0x70 - 0x77 zit IRQ8 t/m IRQ15)

Idd...helemaal gelijk. Was ff in de ruimte aan het lullen as usual.

[curry684]

_{Topictitle gewijzigd op verzoek TS.}

[-=bas=-]

Is het misschien niet handiger om eerst eens te bepalen voor wat voor toepassingen je een OS gaat schrijven?
Het maakt nogal een aardig verschil of het voor een multiuser of single user systeem is. Ook het soort toepassingen heeft veel invloed op ontwerp keuzes.
Ga je voor een mini-OS met minimale functionaliteit of ga je voor een monsterOS met een spaghetti aan functionaliteit zoals Windoos.

Niet om je te ontmoedigen, maar assembly is echt niet de manier om een OS te ontwikkelen. Afgezien van specifieke stukken, spuwen huidige compilers best fatsoenlijke assembly uit en het voordeel van een hogere taal is dat je hem nog kan porten naar een ander platform.

[cobratbq]

Is het misschien niet slim om ipv direct ingewikkeld te praten, eerst een lijstje te maken van alle taken die gedaan moeten worden om een goede bootloader te maken. Zoals het aanmaken van de stack (ofzoiets).
Ik kan bijvoorbeeld ongeveer wel volgen wat er allemaal bedoeld wordt, maar ik zou niet weten wat ik daarna zou moeten doen. Als we een lijst hebben is het misschien makkelijker voor de rest om mee na te denken?

edit...
En het activeert de tweakers waarschijnlijk ook om over de verschillende dingen te gaan nadenken, omdat je een toekomstpad ziet liggen en iedereen heeft z'n eigen onderdeel wattie wel interessant of uitdagend vindt.

[ Voor 22% gewijzigd door cobratbq op 04-09-2003 00:53 ]

[downtime]

_bas_ schreef op 04 September 2003 @ 00:45:
Is het misschien niet handiger om eerst eens te bepalen voor wat voor toepassingen je een OS gaat schrijven?
Het maakt nogal een aardig verschil of het voor een multiuser of single user systeem is. Ook het soort toepassingen heeft veel invloed op ontwerp keuzes.
Ga je voor een mini-OS met minimale functionaliteit of ga je voor een monsterOS met een spaghetti aan functionaliteit zoals Windoos.

Ik denk niet dat het de bedoeling is om een volwaardig OS in elkaar te gaan knutselen. Dat is een klus waar je vele (tientallen?) manjaren voor nodig hebt. De nadruk ligt er, als ik goed heb opgelet, meer op om te leren hoe een eenvoudig OS is opgebouwd.

M.a.w. het gaat erom om iets te leren. Als iemand echt een OS zou willen bouwen kan hij beter gaan meewerken aan 1 van de tientallen andere projecten om een OS van de grond te krijgen.

Niet om je te ontmoedigen, maar assembly is echt niet de manier om een OS te ontwikkelen. Afgezien van specifieke stukken, spuwen huidige compilers best fatsoenlijke assembly uit en het voordeel van een hogere taal is dat je hem nog kan porten naar een ander platform.

ASM is nu eenmaal een vereiste om een simpele bootloader te bouwen. Verder zijn ze nog niet. Pas als de bootloader is geschreven kun je in C o.i.d. een kernel gaan bouwen.

[jurri@n]

Voor wie nog geen assembly kan: een Nederlandstalige cursus

[_the_crow_]

jurri@n schreef op 04 September 2003 @ 09:28:
Voor wie nog geen assembly kan: een Nederlandstalige cursus

Handige PDF. Legt o.a. ook uit hoe stack werkt. Verder staan in de bibliografie een paar boeken/sites die handig kunnen zijn bij het maken van een OS.

[Oguz286]

_the_crow_ schreef op 04 September 2003 @ 10:09:
[...]

Handige PDF. Legt o.a. ook uit hoe stack werkt. Verder staan in de bibliografie een paar boeken/sites die handig kunnen zijn bij het maken van een OS.

Ik krijg als het goed is van een hele lieve tweaker twee boeken
Dat boek van tanenbaum en nog een... Tweakers zijn LIEV

[JayTaph]

Dank je, weer wat geleerd
Ik snap niet hoe iedereen bij 0x90000 komt terwijl in de sourcecode 0x9000 staat Maarja nu is het wat duidelijker

0x90000 is het absolute adres dat je gebruikt. Je stopt namelijk in je SS register de waarde 0x9000. Dit register wordt vermenigvuldigd met 16 en daarbij wordt het SP register opgeteld.

0x9000 * 16 = 0x90000 (ok, hex en decimaal door elkaar )
0x90000 + 0xFFFF = 0x9FFFF

Dit is dus het einde van het vrij geheugen. 1 geheugenplaats verder (0xA0000) begint idd het videogeheugen en daar wil je in principe (nog) niet in werken.

De hoofdreden waarom dat de stack daar neer wordt gezet is omdat je dan zeeen van ruimte hebt om een kernel te laden, te schuiven met je geheugen (soms wil je de kernel inladen op plek 1 en daarna verplaatsen in blokken naar plekken 2 3 4 en 5), en dan is het fijn dat je een stack hebt die niet in de weg zit. Onderaan neerzetten gaat ook niet echt omdat je dan in de knoei komt met je BIOS en interrupt tabellen.

Zodra een kernel eenmaal overgaat naar paging en C-code dan worden de stacks toch opgeruimd en op andere plaatsen neergezet, dus die 0x9FFFF is een perfecte plaats naar mijns inzien (treating tannenbaum as god, does not make him necessarily right).

Owja.. mijn code kan je natuurlijk vrij gebruiken, daar is ie voor alleen volgens mij zijn er een aantal kleine(grote) foutjes ingeslopen waar ik nie echt nog naar gekeken heb of naar ga kijken.

Er zijn een aantal hele leuke topics op got over OS'en (er is nog ooit een leuke discussie geweest door mij aangezwengeld over het protecten van variabelen tegen buffer overflows).

[Oguz286]

JayTaph schreef op 04 September 2003 @ 11:40:
[...]

0x90000 is het absolute adres dat je gebruikt. Je stopt namelijk in je SS register de waarde 0x9000. Dit register wordt vermenigvuldigd met 16 en daarbij wordt het SP register opgeteld.

0x9000 * 16 = 0x90000 (ok, hex en decimaal door elkaar )
0x90000 + 0xFFFF = 0x9FFFF

Dit is dus het einde van het vrij geheugen. 1 geheugenplaats verder (0xA0000) begint idd het videogeheugen en daar wil je in principe (nog) niet in werken.

De hoofdreden waarom dat de stack daar neer wordt gezet is omdat je dan zeeen van ruimte hebt om een kernel te laden, te schuiven met je geheugen (soms wil je de kernel inladen op plek 1 en daarna verplaatsen in blokken naar plekken 2 3 4 en 5), en dan is het fijn dat je een stack hebt die niet in de weg zit. Onderaan neerzetten gaat ook niet echt omdat je dan in de knoei komt met je BIOS en interrupt tabellen.

Zodra een kernel eenmaal overgaat naar paging en C-code dan worden de stacks toch opgeruimd en op andere plaatsen neergezet, dus die 0x9FFFF is een perfecte plaats naar mijns inzien (treating tannenbaum as god, does not make him necessarily right).

Owja.. mijn code kan je natuurlijk vrij gebruiken, daar is ie voor alleen volgens mij zijn er een aantal kleine(grote) foutjes ingeslopen waar ik nie echt nog naar gekeken heb of naar ga kijken.

Er zijn een aantal hele leuke topics op got over OS'en (er is nog ooit een leuke discussie geweest door mij aangezwengeld over het protecten van variabelen tegen buffer overflows).

Dankje voor de goede uitleg
en fijn dat je in dit topic bent gekomen:

[Allochtoon]

Toevallig was ik naar kernel pruttel aant browsen:
http://www.tldp.org/LDP/Pocket-Linux-Guide/html/index.html
Heb je daar wat aan?

[JayTaph]

Oguz286 schreef op 04 september 2003 @ 11:42:
[...]


Dankje voor de goede uitleg
en fijn dat je in dit topic bent gekomen:

Nee hoor, want over 2 weken vertrek ik voor een jaar naar het buitenland

[Oguz286]

Allochtoon schreef op 04 September 2003 @ 12:02:
Toevallig was ik naar kernel pruttel aant browsen:
http://www.tldp.org/LDP/Pocket-Linux-Guide/html/index.html
Heb je daar wat aan?

Alle hulp is welkom

JayTaph schreef op 04 September 2003 @ 12:09:
[...]


Nee hoor, want over 2 weken vertrek ik voor een jaar naar het buitenland

Ah wat jammer nou (voor mij dan ) Dan moet ik je heel veel vragen stellen in 2 weken

[Verwijderd]

Oguz286 schreef op 04 September 2003 @ 11:39:
[...]


Ik krijg als het goed is van een hele lieve tweaker twee boeken
Dat boek van tanenbaum en nog een... Tweakers zijn LIEV

Moet je me nog wel ff mailen hoe je die boeken daar wilt krijgen...

JayTaph schreef op 04 September 2003 @ 12:09:
[...]


Nee hoor, want over 2 weken vertrek ik voor een jaar naar het buitenland

En??? Hebben ze daar geen internet ofzow...

.modbreak: die oneliners kunnen heus wel in dezelfde post

[ Voor 35% gewijzigd door .oisyn op 04-09-2003 19:27 ]

[Oguz286]

Verwijderd schreef op 04 September 2003 @ 18:57:
[...]


Moet je me nog wel ff mailen hoe je die boeken daar wilt krijgen...


[...]


En??? Hebben ze daar geen internet ofzow...

<span style="color:blue">.modbreak: die oneliners kunnen heus wel in dezelfde post :)</span>

1. Als jij ze opstuurt dan betaal ik de verzendkosten (duh! )
2. Ook al hebben ze daar internet, ik ga die man daar toch niet storen

[Oguz286]

Weet iemand hoe ik mijn bootloader op een fat12 floppy krijg, dus alleen de bootsector aanpassen, verder niets. Als ik dat met rawrite doe, dan kan ik mijn floppy niet meer lezen

[.oisyn]

http://www.xs4all.nl/~oisyn/files/frw.zip

raw lees en schrijf tooltjes + source, die had ik ooit eens gemaakt in DJGPP toen ik zelf aan het experimenteren was met operating systems

Als je met fwrite gewoon maar 512 bytes schrijft, dan blijft de rest ongewijzigd. Overigens, waarom moet de floppy intact blijven? FAT12 ondersteuning lijkt me nou niet echt iets wat nu meteen ondersteund moet worden. Je plakt gewoon je binary achter die 512 bytes, en schrijft ze naar floppy

[PrisonerOfPain]

.oisyn schreef op 04 September 2003 @ 20:03:
http://www.xs4all.nl/~oisyn/files/frw.zip

raw lees en schrijf tooltjes + source, die had ik ooit eens gemaakt in DJGPP toen ik zelf aan het experimenteren was met operating systems

Waarscheinlijk een handig tooltje maar zonder DJGPP zijn we nergens :\

Als je met fwrite gewoon maar 512 bytes schrijft, dan blijft de rest ongewijzigd. Overigens, waarom moet de floppy intact blijven? FAT12 ondersteuning lijkt me nou niet echt iets wat nu meteen ondersteund moet worden. Je plakt gewoon je binary achter die 512 bytes, en schrijft ze naar floppy

en als we eens willen overstappen op een ander medium (kans is niet groot, maar altijd aanwezig) lukt het dan ook nog op die manier??

[_the_crow_]

Het gaat NOG niet om het medium. Je moet eerst een beetje kloten (spreek uit: bekend worden) met de bootsector (bootloader). Daarvoor heb je nog geen filesystem nodig.

[.oisyn]

PrisonerOfPain schreef op 04 September 2003 @ 20:51:
Waarscheinlijk een handig tooltje maar zonder DJGPP zijn we nergens :\

uhm, heb je uberhaupt wel in de zip gekeken? Er staan executables in, die dus runnable zijn vanuit windows (voor dos heb je CWSDPMI nodig)

en als we eens willen overstappen op een ander medium (kans is niet groot, maar altijd aanwezig) lukt het dan ook nog op die manier??

als je wilt overstappen op een ander medium (harddisk, cdrom, usb device) is de kans groot dat het booten uberhaupt op een hele andere manier werkt

[PrisonerOfPain]

.oisyn schreef op 04 september 2003 @ 21:22:
[...]


uhm, heb je uberhaupt wel in de zip gekeken? Er staan executables in, die dus runnable zijn vanuit windows (voor dos heb je CWSDPMI nodig)

nee

edit:

nu wel

[ Voor 6% gewijzigd door PrisonerOfPain op 04-09-2003 21:55 ]

[Oguz286]

.oisyn schreef op 04 September 2003 @ 20:03:
http://www.xs4all.nl/~oisyn/files/frw.zip

raw lees en schrijf tooltjes + source, die had ik ooit eens gemaakt in DJGPP toen ik zelf aan het experimenteren was met operating systems

Als je met fwrite gewoon maar 512 bytes schrijft, dan blijft de rest ongewijzigd. Overigens, waarom moet de floppy intact blijven? FAT12 ondersteuning lijkt me nou niet echt iets wat nu meteen ondersteund moet worden. Je plakt gewoon je binary achter die 512 bytes, en schrijft ze naar floppy

Eh dat snap ik even niet. Aan de hand van deze tutorial wil ik mijn fat12 floppy bootable maken: http://gathering.tweakers.net/forum/view_message/13370629

We maken een bootable floppy met ons eigen bootloader maar kunnen hem ook benaderen onder windows (want het is een fat12 floppy). Als ik met rawrite mijn bootloader op een floppy zet dan kan ik hem niet meer aanspreken onder windows en volgens die tutorial moet dat kunnen (zodat we bijv. kernel.sys erop kunnen zetten)

JayTaph of iemand anders: wie kan me ff uitleggen wat ik moet doen?

[_the_crow_]

Je hebt waarschijnlijk in een lege image je bootloader geschreven en die vervolgens op je flop gezet. True?

[Oguz286]

_the_crow_ schreef op 04 September 2003 @ 22:03:
Je hebt waarschijnlijk in een lege image je bootloader geschreven en die vervolgens op je flop gezet. True?

Eh ik heb een bootloader geschreven, heb dan mijn floppy geformatteerd (NIET SNELFORMATTEREN) en heb daarna met rawrite mijn boot.bin bestand erop gezet.

BTW ik zeg het nogmaal: die atlos =

[ Voor 7% gewijzigd door Oguz286 op 04-09-2003 22:14 ]

[.oisyn]

wat doet rawrite precies? maakt ie de rest leeg, of schrijft ie alleen boot.bin? Anders moet je het even met mijn proggie proberen, daarvan weet ik zeker dat ie de rest intact laat.

Maar je boot.bin overschrijft natuurlijk wel de BPB die al op de disk staat. De BPB in boot.bin moet daarom ook overeen komen met de BPB op de floppy. Is de filesystem string wel "FAT12 "?

[Oguz286]

code:

[bits 16]   ;16 bits
org 0       ;beginnen op 0

jmp start   ;jumpen naar start

    OEMName         db  "tutOS "
    BytesPerSector      dw  0x0200
    SectorsPerCluster   db  0x01
    ReservedSectors     dw  0x01
    NumberOfFATs        db  0x02
    RootEntries     dw  224
    TotalSectors        dw  2880
    Media           db  0xF0
    SectorsPerFAT       dw  0x09
    SectorsPerTrack     dw  0x0012
    HeadsPerCylinder    dw  0x0002
    HiddenSectors       dd  0x00000000
    TotalSectorsBig     dd  0x00000000
    DriveNumber     db  0x00
                db  0x00
    ExtBootSignature    db  0x00
    SerialNumber        dd  0x12345678
    VolumeLabel     db  "PROBEERDISK"
    FileSystem      db  "FAT12   "
    
    bootdrv         db 0                            ;hierin gaat onze boot drive
    bootmsg         db 'tutOS bootloader :)',13,10,0            ;ons bootmessage :)
    restartBericht      db 'Druk op een toets om opnieuw op te starten',13,10,0 ;en hier ons reboot bericht :P
    msg         db 'Hallo bootsector. De volumenaam is: ',0     ;dit is voor het weergeven van de volumenaam
    A20Bericht      db "A20 aanzetten...", 13, 10, 0            ;Live van onze reporter bij de A20 een file van 4 gigabyte :+
    blank           db '', 13, 10, 0
start:              
    mov ax, 0x7c0           ;0x7c0 kopieren
    mov ds, ax          ;naar datasegment
    mov [bootdrv], dl       ;in dl staat de bootdrive, die moet naar bootdrv
    jmp 0x07C0:relocation
relocation:
    
    cli             ;interrupts uitzetten
    mov ax, 0x9000          ;ons stackje komt helemaal bovenaan de 640k boundry
    mov ss, ax          ;naar stacksegment kopieren
    mov sp, 0xffff          ;de pointer is ffff dus nu hebben we 0x9000:0xffff
    sti             ;interrupts aanzetten

    mov si, bootmsg         ;ons bootmessage op het scherm kwakken
    call Bericht            ;met de functie Bericht

.386                    ;nu kunnen we 386 instructies gebruiken :)
    
    mov si, msg         ; Print bericht
    mov cx, 0
    call Bericht

    mov si, VolumeLabel
    mov cx, 12
    call Bericht
    
    mov si, blank
    mov cx, 0
    call Bericht

    mov si, A20Bericht
    mov cx, 17
    call Bericht
    call A20
    
    call wachtToets
    
    call reboot
    
;Functions:

    Bericht:            ;Print de registers ds:si op het scherm
        cld
        lodsb           ;Stop de bytes ds:si in het register al
        or al,al        ;Check of er wel iets in al staat
        jz klaar        ;zoniet, ga naar klaar
        dec cx
        jz klaar
        mov ah,0Eh      ;zet het teken in het goede register
        mov bx,0007     ;de atributen
        int 0x10        ;roep de int aan
        jmp Bericht     ;jump naar bericht voor het volgende teken
    klaar:
        ret

    wachtToets:
        mov ah,0        ;wacht op een toets
        int 016h        ;de bios interupt
        ret

    reboot:
        mov si,restartBericht   ;stop het herstart bericht in het goede register (si)
        call Bericht        ;roep de bericht-op-scherm functie aan
        call wachtToets     ;en ff wachten maar

        db 0x0EA        ;REBOOT, jeweet wel, windows

        dw 0x0000       
        dw 0x0FFFF

    A20:

        in al,92h
        or ah,ah
        jne A201
        
                ; chipset bug: do NOT clear b1 if it's already clear
        test al,02h
        je A203
        and al,0FDh
        jmp short A202

    A201:
                ; chipset bug: do NOT set b1 if it's already set
        test al,02h
        jne A203
        or al,02h
    A202:
        out 92h,al
    A203:
        pop ax
        pop si          ; DEBUG
        ret
        times 510-($-$$) db 0
            dw 0xAA55

Dit is em, zit er soms een fout in?

Edit: sorry voor de vernacheling van de layout
Edit2: eh die A20 routine werkt niet, daar zijn we mee bezig

[ Voor 6% gewijzigd door Oguz286 op 04-09-2003 22:25 ]

[.oisyn]

uhm, jouw OEMNAME in de BPB is maar 6 bytes, terwijl dat 8 moet zijn

[_the_crow_]

.oisyn schreef op 04 September 2003 @ 22:34:
uhm, jouw OEMNAME in de BPB is maar 6 bytes, terwijl dat 8 moet zijn

Checkt windows de 0xAA55 signature?? Want dat zou dan de niet-leesbaarheid van de flop in windows moeten veroorzaken.

[ Voor 18% gewijzigd door _the_crow_ op 04-09-2003 22:38 ]

[Oguz286]

.oisyn schreef op 04 september 2003 @ 22:34:
uhm, jouw OEMNAME in de BPB is maar 6 bytes, terwijl dat 8 moet zijn

_the_crow_ schreef op 04 September 2003 @ 22:37:
[...]

Checkt windows de 0xAA55 signature?? Want dat zou dan de niet-leesbaarheid van de flop in windows moeten veroorzaken.

Ik kan jullie wel zoenen
Nee mallerd ik ben geen homo (niet da ik er wat tegen heb ofzo)

Het werkt perfect, ik heb die 6bytes oemname in 8 bytes veranderd en hij doet het

[.oisyn]

_the_crow_ schreef op 04 September 2003 @ 22:37:
[...]

Checkt windows de 0xAA55 signature?? Want dat zou dan de niet-leesbaarheid van de flop in windows moeten veroorzaken.

dat maakt niet uit, want die 0xAA55 staat altijd op offset 510 (door de times 510-($-$$) db 0 statement). Alleen de BPB klopt dan niet, waardoor windows de floppy niet snapt

[Oguz286]

_the_crow_ schreef op 04 September 2003 @ 22:37:
[...]

Checkt windows de 0xAA55 signature?? Want dat zou dan de niet-leesbaarheid van de flop in windows moeten veroorzaken.

Uh dat maakt toch geen hol uit Windows kijkt toch niet of het bootable is of niet?

En ik heb een probleem: Als ik mijn code uitvoer die de A20 lijn aanzet dan stopt hij daar met uitvoeren... Ondersteunt Bochs de A20 lijn niet ofzo?

[.oisyn]

Jawel hoor, mijn OS werkte ook prima... is je wachtloopje wel goed?

Dit was de code die ik had:

code:

    ; enable the a20 line
    call    a20wait
    mov     al,0xAD
    out     0x64,al

    call    a20wait
    mov     al,0xD0
    out     0x64,al

    call    a20wait2
    in      al,0x60
    push    eax

    call    a20wait
    mov     al,0xD1
    out     0x64,al

    call    a20wait
    pop     eax
    or      al,2
    out     0x60,al

    call    a20wait
    mov     al,0xAE
    out     0x64,al

    call    a20wait
    ; a20 line is now enabled


a20wait:
.l0:    mov     ecx,65536
.l1:    in      al,0x64
        test    al,2
        jz      .l2
        loop    .l1
        jmp     .l0
.l2:    ret


a20wait2:
.l0:    mov     ecx,65536
.l1:    in      al,0x64
        test    al,1
        jnz     .l2
        loop    .l1
        jmp     .l0
.l2:    ret

(let wel dat dit dus al in 32 bits protected mode was. Een werkende A20 heeft ook niet veel nut in realmode, behalve dat je boven de 1 mb grens uit kan komen )

[ Voor 6% gewijzigd door .oisyn op 05-09-2003 15:34 ]

[JayTaph]

Uh dat maakt toch geen hol uit Windows kijkt toch niet of het bootable is of niet?

Dat heeft geen hol met windows te maken. Het is je bios die de eerste sector (bootsector of mbr) in het geheugen laad... Sommige (let op: je las net: sommige, en dus niet alle) bios'en zullen het niet pikken als op offset 510 geen 0xAA55 staat en een melding geven dat er geen geldig bootsector gevonden is (of iets anders gaan doen).

Je kunt dus deze 2 bytes weglaten en eventueel gebruiken voor andere doeleinden (2 bytes extra in een bootsector is vrij waardevol als je geen 2nd stage loaders ed hebt ), maar besef wel dat niet elke bios je bootsector zal inladen

En ik heb een probleem: Als ik mijn code uitvoer die de A20 lijn aanzet dan stopt hij daar met uitvoeren... Ondersteunt Bochs de A20 lijn niet ofzo?

Bochs houd van de A20 lijn. je zult dus iets verkeerds doen. Zet even je complete debugging aan en zoek in de debugfile op de A20 line, hij moet iets roepen in de trand van: "a20 activated" ofzoiets..

[_the_crow_]

.oisyn schreef op 05 September 2003 @ 15:33:
Jawel hoor, mijn OS werkte ook prima... is je wachtloopje wel goed?

Dit was de code die ik had:

*knip* a20-code *knip*

(let wel dat dit dus al in 32 bits protected mode was. Een werkende A20 heeft ook niet veel nut in realmode, behalve dat je boven de 1 mb grens uit kan komen )

Je kan toch ook eerst de a20-line aanzetten en _dan_ pas naar Protected-mode switchen.

[JayTaph]

_the_crow_ schreef op 05 September 2003 @ 16:27:
[...]

Je kan toch ook eerst de a20-line aanzetten en _dan_ pas naar Protected-mode switchen.

Ja.. dat maakt niet zo veel uit. Het ligt een beetje aan de opzet van je os/bootloader. Soms doe je het later, omdat je anders in de knoei komt met je bootsector grootte, en soms doe je het eerder, omdat je anders in de knoei komt met paging endergelijke die je al in een heel vroeg stadia opzet...

tis dus geheel aan jezelf.. :-)

[_the_crow_]

JayTaph schreef op 05 September 2003 @ 16:29:
Ja.. dat maakt niet zo veel uit. Het ligt een beetje aan de opzet van je os/bootloader. Soms doe je het later, omdat je anders in de knoei komt met je bootsector grootte, en soms doe je het eerder, omdat je anders in de knoei komt met paging endergelijke die je al in een heel vroeg stadia opzet...

tis dus geheel aan jezelf.. :-)

Je kan in principe ook een file starten die de boot verder regelt voor je. Zo hoef je niet alles in die bootsector te proppen.

[JayTaph]

Idd...

een veelgebruikte techniek is een 2nd stage loader:

Je bootsector doet niets anders als zichzelf aan de kant schuiven, het inladen van een 2e sector (of sectoren) of eventueel een file op disk op de standaard bootsector plaats (0x7C000). Daarna wordt er naar deze plek gesprongen. Zodoende kun je dus een bootsector laden van meer dan 512 bytes en heb je meer ruimte om je werk op te knappen.

Ach, er zijn zoveel verschillende manieren om een bootloader te bouwen. :-)

[Oguz286]

JayTaph in [tutorial] how to write your own OS

Heb ik hier het gevoel alsof het niet af is

.modbreak: zie SoulTaker, een hele quote van enkele pagina's en dan 1 regel als reactie is een beetje overdreven

[ Voor 149% gewijzigd door .oisyn op 05-09-2003 20:39 ]

[Soultaker]

Oguz286 schreef op 05 September 2003 @ 20:09:
Heb ik hier het gevoel alsof het niet af is

Moest je nou echt die héle lap tekst quoten om er alleen die ene regel commentaar aan toe te voegen? Had je niet gewoon even de URL neer kunnen zetten?

Ik vind dit topic al geen schoolvoorbeeld van structuur en helderheid, maar op deze manier wordt het wel heel erg moeilijk om nog enigszins in de gaten te houden waar het over gaat.

[Oguz286]

Soultaker schreef op 05 September 2003 @ 20:31:
[...]

Moest je nou echt die héle lap tekst quoten om er alleen die ene regel commentaar aan toe te voegen? Had je niet gewoon even de URL neer kunnen zetten?

Ik vind dit topic al geen schoolvoorbeeld van structuur en helderheid, maar op deze manier wordt het wel heel erg moeilijk om nog enigszins in de gaten te houden waar het over gaat.

Je hebt gelijk, het spijt me. Ja inderdaad, ik moet die tweede tutorial nog posten want in dit topic zit inderdaad geen structuur. En zo'n grote quote... Nogmaals sorrie

[ Voor 3% gewijzigd door Oguz286 op 06-09-2003 12:08 ]

[Oguz286]

Bootstrapping: Deel 2
---------------------

Moeilijkheidsgraad: makkelijk
Voorkennis: Matige i386 assemnbly
Referenties: zie startpost
Tools: Bochs, rawrite, nasm

Ik heb besloten deze tutorial zelfs te schrijven (anders is dat wel zo asociaal om alleen JayTaph's tutorials letterlijk te kopieren Wel zal ik mijn info uit zijn tut's halen). We gaan nu iets verder, en gaan iets op het scherm printen. Meteen maar wat code:

code:

[bits 16]       ;16 bits code
[org 0]         ;we staan op 0
    
    jmp start
    
    bootdrv     db 0    ;hierin zetten we onze bootdrive (0 voor diskette, 80 voor harddisk) 
    msg     db 'Mijn bootloader',13,10,0
    restartBericht  db 'Druk op een toets om opnieuw te starten...',13,10,0
        
    start:
    
    ; We weten niet of we op 0000:7C00 of 07C0:0000 staan, daarom kiezen
    ; we er zelf een.

    mov ax, 0x7C0   ; Segment 07C0
    mov ds, ax      ; Data staat op 07C0:0000 ipv 0000:7C00

    cli         ; interrupts uitzetten
    mov ax, 0x9000  ; Stack Segment Goedzetten
    mov ss, ax      ; Stack Segment = 0x9000 nu
    mov sp, 0xFFFF  ; Stack Pointer = 0xFFFF nu
    sti         ; interrupts weer aanzetten

    mov si,msg      ;kopieer het bericht naar SI
    call Bericht        ;roep functie Bericht aan
    call Herstart

    ;-------Functie's----------------------

    ;-------Functie Bericht:---------------
    ;-------Plaats een string op het scherm
    
    Bericht:
        lodsb           ;Laad byte op locatie DS:SI naar AL
        or al,al        ;kijk of karakter een 0 (nul) is
        jz Klaar        ;zoja spring naar Klaar
        mov ah,0eh      ;plaats karakter
        mov bx,0007     ;attribuut
        int 0x10        ;roep biosfunctie aan
        jmp Bericht     ;ga verder met het volgende karakter
    Klaar:
        ret         ;keer terug

    ;-------Functie WachtToets:------------
    ;-------Wacht op een toets-------------

    WachtToets:
        mov ah,0               ;wacht op een toets
                int 016h        ;roep Biosfunctie aan
                ret         ;keer terug

    ;-------Functie Herstart:--------------
    ;-------Herstart de computer-----------
    
    Herstart:
        
        mov si,restartBericht   ;stop het herstart bericht in het goede register (si)
        call Bericht        ;roep de bericht-op-scherm functie aan
        call WachtToets     ;en ff wachten maar

        db 0x0EA        ;REBOOT, jeweet wel, windows
    
        dw 0000h
                dw 0FFFFh

        times 510-($-$$) db 0   ;vul tot byte 510 allemaal nullen (NOP)
            dw 0xAA55       ;en als laatst de bootsignature

Nu wat uitleg Eerst vertellen we de compiler dat we 16 bits code gebruiken. We weten niet of we op 0000:7C00 of 07C0:0000 staan, daarom kiezen we er zelf een. We kopieren de segment 07C0 naar ax, en dan naar DS zodat we op 07C0:0000 staan ipv 0000:7C00. Nu zetten we een stack op (ik neem aan dat je weet wat dat is, leer anders assembly ) Ik neem hier 0x9000, de boundry van je 640k bereik. Zo hebben we lekker veel ruimte. De pointer zetten we op 0xFFFF. Waarom? Omdat de pointer omlaag gaat ipv omhoog, dus elke keer wanneer we iets push'en op de stack dan gaat deze omlaag. In dl staat de bootdrive, die slaan we even op in de variabele bootdrv.

Nu willen we wat tekst op ons schermpje krijgen. We mov'en de string msg naar SI en roepen daarna de functie Bericht aan. Elke karakter in onze string die in msg staat is 1 byte lang. In de functie Bericht laden we eerst de byte die op DS:SI staat (dus de karakter die we willen printen) in al. Daarna kijken we of er een nul karakter in zit (want dat is het laatste teken). Is dit het geval dan keren we terug naar waar we gebleven waren. Is dit niet het geval dan roepen we Biosfunctie 10h aan. Kijk even op Ralf Brown's site en zoek op Int 10h. Daar staat alle info die je nodig hebt om die functie te gebruiken Hetzelfde geldt ook voor de functie WachtToets waar biosfunctie 16h wordt gebruikt. Deze moet je even uitzoeken anders ben ik morgen nog niet klaar En als laatst hebben we functie Herstart. Eerst plaatsen we het bericht restartBericht in SI, plaatsen we het bericht op het scherm en wachten op een toets.

En aangezien ons bootloadertje 512 bytes lang moet zijn, plaatsen we tot byte 510 allemaal nullen (NOP) en op 511 en 512 de bootsignature (0xAA55).

Ik hoop dat jullie het zullen begrijpen, dit is mijn eerste tutorial die ik helemaal zelf heb geschreven dus (ben nog 16)... Begrijp je iets niet stuur dan ff een mailtje

En mijn dank aan PrisonerOfPain

[ Voor 13% gewijzigd door Oguz286 op 06-09-2003 18:26 ]

[PrisonerOfPain]

Aangezien Oguz niet al te veel zin had om uit te leggen wat een stack is doe ik dat hier in het kort even.

Een stack in assebler niets meer als een rij met data die gesorteerd is met behulp van het FILO (First In Last Out) algoritme. Ja leuk, maar wat houd dat nou weer in?

Okey hier even een klein voorbeeldje, stel je hebt een buis (met dezelfde radius als de objecten die je erin wilt stoppen, in dit geval knikkers EN de buis is aan de onderkant dicht, anders kan je valsspelen ) en daar stop je 5 knikkers in de volgorde:

• Rood
• Geel
• Groen
• Blauw
• Paars

Je hebt dus paars er als eerst ingestopt, wil je die eruit halen, zal je eerst al de andere knikkers eruit moeten halen.

[ Voor 50% gewijzigd door PrisonerOfPain op 06-09-2003 19:47 ]

[Apollo_Futurae]

PrisonerOfPain schreef op 06 september 2003 @ 19:02:
Je hebt rood er het eerst in gestopt, dus komt hij er ook weer het eerste uit.

Leuk stukje, maar de crux van een stack is nu juist dat wat je er als eerste in stopt er als laatste uit komt .

[PrisonerOfPain]

Apollo_Futurae schreef op 06 September 2003 @ 19:41:
[...]
Leuk stukje, maar de crux van een stack is nu juist dat wat je er als eerste in stopt er als laatste uit komt .

Dus toch, zo was ie origineel, maar Oguz zij dat het anders was, ik zal het even aanpassen

[Oguz286]

PrisonerOfPain schreef op 06 September 2003 @ 19:44:
[...]


Dus toch, zo was ie origineel, maar Oguz zij dat het anders was, ik zal het even aanpassen

Dat is helaas niet waar.

Ik quote een stuk van een site:

The Stack:

-6 registers is limiting, so stack allows us to save and restore values
-like a stack of plates
-Last In First Out (LIFO)
-starts at high adress and grows downwards
-putting too much data on the stack will cause it to overflow

Dus klopt mijn verhaal toch wel

[_the_crow_]

PrisonerOfPain heeft gelijk. Hetgene wat er als eerst op gaat, gaat er als laatste af. Het knikkeridee in de buis, die aan 1 kant afgesloten is, is het beste voorbeeld daarvan.

[Soultaker]

Nederlands is een nuttige taal: stack is Engels voor stapel, en wat je bovenop een stapel legt, pak je er het eerste weer af.