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

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

[PrisonerOfPain]

_the_crow_ schreef op 06 September 2003 @ 20:39:
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.

Eigendunk++;

-List In First Out (LIFO)

de spelfout komt niet echt profi over

maar laten we nou niet van een mug een olifant gaan maken, want daar schieten we niets mee op

offtopic:
wieeeeeeeee 100 posts

@Oguz: ik denk niet dat iemand hier dit topic volgt

[ Voor 6% gewijzigd door PrisonerOfPain op 06-09-2003 21:38 ]

[Oguz286]

PrisonerOfPain schreef op 06 September 2003 @ 21:32:
[...]


Eigendunk++;



[...]


de spelfout komt niet echt profecioneel over

maar laten we nou niet van een mug een olifant gaan maken, want daar schieten we niets mee op

offtopic:
wieeeeeeeee 100 posts

Nee klopt

BTW tutorial 3 komt er morgen aan (voor de mensen die dit topic volgen)
We gaan dan een msdos-compatible floppy maken zodat we het in windows/dos/linux/etc kunnen lezen en onze kernel erop kunnen zetten

offtopic:
Nee, denk het ook niet Volgens mij is een eigen os maken niet meer zo in...

[ Voor 37% gewijzigd door Oguz286 op 06-09-2003 21:42 ]

[alienfruit]

Trouwens, kun je ook VMWare gebruiken ipv. Bochs?
VMWare is bij mijn weten een volledige x86 emulator, dus in principe zou het dan wel moeten kunnen.

[ Voor 51% gewijzigd door alienfruit op 06-09-2003 21:51 ]

[Oguz286]

alienfruit schreef op 06 September 2003 @ 21:51:
Trouwens, kun je ook VMWare gebruiken ipv. Bochs?
VMWare is bij mijn weten een volledige x86 emulator, dus in principe zou het dan wel moeten kunnen.

Geen flauw idee, ik ga het wel uitproberen...
Post morgen wel (zelfs ik moet slapen )

* Oguz286 vraagt zich af of dat wel zo is...

[ Voor 8% gewijzigd door Oguz286 op 06-09-2003 22:07 ]

[PrisonerOfPain]

alienfruit schreef op 06 september 2003 @ 21:51:
Trouwens, kun je ook VMWare gebruiken ipv. Bochs?
VMWare is bij mijn weten een volledige x86 emulator, dus in principe zou het dan wel moeten kunnen.

VMWare zou ook moeten, maar is bij mijn weten nogsteed geen freeware, waar Bochs dat wel is (speach, beer )

[_the_crow_]

Hier stond iets doms. Nu niet meer.
Sorry Alien.

[ Voor 99% gewijzigd door _the_crow_ op 06-09-2003 22:50 ]

[alienfruit]

_the_crow_, dat weet ik daarom merkte ik ook dat VMWare dat óók is

[Oguz286]

Ik heb geen flauw idee waar jullie het over hebben/hadden, maar ik wou ff zeggen dat ik nu probeer VMWare te gebruiken...

Ben zo terug...

EDIT: Ja hoor perfect!

EDIT2: Nee dus, ik kan mijn A20 lijn niet enablen, terwijl het in bochs perfect werkt Weet iemand hoe dit en kan en misschien een oplossing?

EDIT3: Nee, sorrie, je moet natuurlijk wel keyboard input gebruiken hè als je op een toets moet drukken Oftewel, ja het kan ook met VMWare (alleen kost dat geld...)

[ Voor 67% gewijzigd door Oguz286 op 06-09-2003 23:23 ]

[PrisonerOfPain]

Zeg Oguz, je hebt nog een half uur, dan is het al morgen

edit:

tsja nu is het echt 12 uur geweest dusuh, k ben aan het wachten op de volgende tutorial

[ Voor 49% gewijzigd door PrisonerOfPain op 07-09-2003 00:00 ]

[Verwijderd]

alienfruit:

VMWare is *geen* x86 emulator, Bochs wel. VMWare creeert wel een virtuele machine, net als Bochs, maar laat executie van code aan de CPU over; Bochs emuleert elke instructie.

Het verschil zit 'm daarmee vooral in het feit dat je met Bochs wel je OSje op een Sun/HP/etc bak kan testen, en met VMWare niet.

Overigens, VMWare ondersteunt niet elk OS (zoals bv Minix, OS/2, BeOS, QNX ), dus het kan goed zijn dattie je eigen OS ook niet wil booten. Mja de enige manier om daarachter te komen is proberen

[MissingDog]

yeah...mijn bootstrapje werkt...was er al aan begonnen voor deze hele serie tutorials die ik vandeweek tegenkwam op zoek naar de A20 line helpjes....best een kick om 'm de eerste keer (en alle keren daarna) op 't scherm te zien komen.
Sta nu op 't punt om 't laden van een kernel (ASM, eerst realmode, dan PM) van schijf te gaan implementeren...eens ff kijken hoe ik dat ga aanpakken...heb nog aardig wat ruimte in de bootsector, dus kan nog aardig wat spelen, misschien eerst eens een 2nd stage loader bouwen zodat ik ruimte heb voor wat grafisch gespeel in mode 13h....doet me denken aan m'n TurboPascal gamecoding tijd, al die inline ASM die ik toen gebruikte.
Moet ook m'n code eens gaan opschonen...beetje rommeltje nog...routines/macro's die niet op alfabet staan enzo.

[_the_crow_]

MissingDog schreef op 07 september 2003 @ 17:32:
yeah...mijn bootstrapje werkt...was er al aan begonnen voor deze hele serie tutorials die ik vandeweek tegenkwam op zoek naar de A20 line helpjes....best een kick om 'm de eerste keer (en alle keren daarna) op 't scherm te zien komen.
Sta nu op 't punt om 't laden van een kernel (ASM, eerst realmode, dan PM) van schijf te gaan implementeren...eens ff kijken hoe ik dat ga aanpakken...heb nog aardig wat ruimte in de bootsector, dus kan nog aardig wat spelen, misschien eerst eens een 2nd stage loader bouwen zodat ik ruimte heb voor wat grafisch gespeel in mode 13h....doet me denken aan m'n TurboPascal gamecoding tijd, al die inline ASM die ik toen gebruikte.
Moet ook m'n code eens gaan opschonen...beetje rommeltje nog...routines/macro's die niet op alfabet staan enzo.

Als ik een kleine tip mag geven.
Een 2nd stage bootloader is handig. Maar ik denk dat PM al genoeg gezeik met zich meebrengt, dus ik zou niet meteen de grafische modus in gaan.
Als je PM in gaat, zoek ff op de keywords GDT/IDT/LDT. Dat zijn namelijk essentiële tabelletjes om PM in te gaan.

[ Voor 5% gewijzigd door _the_crow_ op 07-09-2003 17:36 ]

[MissingDog]

_the_crow_ schreef op 07 September 2003 @ 17:35:
[...]

Als ik een kleine tip mag geven.
Een 2nd stage bootloader is handig. Maar ik denk dat PM al genoeg gezeik met zich meebrengt, dus ik zou niet meteen de grafische modus in gaan.
Als je PM in gaat, zoek ff op de keywords GDT/IDT/LDT. Dat zijn namelijk essentiële tabelletjes om PM in te gaan.

Ik weet 't....fijne tabelletjes, ben daar ook al naar aan 't graven...maar misschien doe 'k 't grafische gespeel wel in een andere versie...realmode-only...beetje oldschool demotjes erin coden ofzo
Weet in elk geval dat 'k nog ff moet doorspeuren, hoop toch wel over 4 weken m'n eerste C-kernel te kunnen draaien...wordt nog flink coden voor die tijd. Moet ook m'n documentatie bij gaan werken en beetje gaan nadenken over driver-architectuur enzo

[PrisonerOfPain]

Links naar documentatie is altijd welkom he

[_the_crow_]

Om alleen lay-outs van bepaalde tabellen te bekijken is Sandpile wel handig. Je moet hier overigens niet heen gaan om uitgebreide uitleg te krijgen.

Verder kan je altijd googelen.

Ook kan je zoeken op de nieuwsgroepen alt.os.development en alt.os.assembly.

[ Voor 18% gewijzigd door _the_crow_ op 07-09-2003 18:02 ]

[Oguz286]

MissingDog schreef op 07 September 2003 @ 17:32:
yeah...mijn bootstrapje werkt...was er al aan begonnen voor deze hele serie tutorials die ik vandeweek tegenkwam op zoek naar de A20 line helpjes....best een kick om 'm de eerste keer (en alle keren daarna) op 't scherm te zien komen.
Sta nu op 't punt om 't laden van een kernel (ASM, eerst realmode, dan PM) van schijf te gaan implementeren...eens ff kijken hoe ik dat ga aanpakken...heb nog aardig wat ruimte in de bootsector, dus kan nog aardig wat spelen, misschien eerst eens een 2nd stage loader bouwen zodat ik ruimte heb voor wat grafisch gespeel in mode 13h....doet me denken aan m'n TurboPascal gamecoding tijd, al die inline ASM die ik toen gebruikte.
Moet ook m'n code eens gaan opschonen...beetje rommeltje nog...routines/macro's die niet op alfabet staan enzo.

Als je ons zou willen helpen zou dat geweldig zijn (daar zijn we ongeveer ook beland)

Mail me anders ff

[MissingDog]

Oguz286 schreef op 07 September 2003 @ 18:03:
[...]


Als je ons zou willen helpen zou dat geweldig zijn (daar zijn we ongeveer ook beland)

Mail me anders ff

Alles wat ik bereik, vind etc en hier nog niet gepost is wil ik zeker wel met jullie delen. Ik ben nu eerst bezig alles weer op te frissen, heb 6 jaar geen asm meer gecode...en da's behoorlijk lang voor mijn doen en sowieso is een OS coden wel iets anders dan game-code, maar ik zal m'n best doen.

[.oisyn]

Verwijderd schreef op 07 September 2003 @ 16:17:
alienfruit:

VMWare is *geen* x86 emulator, Bochs wel. VMWare creeert wel een virtuele machine, net als Bochs, maar laat executie van code aan de CPU over; Bochs emuleert elke instructie.

VMWare emuleert ook. Moet wel, want je moet instructies kunnen uitvoeren waar het VMWare proces op de host pc geen rechten toe heeft. Denk bijvoorbeeld aan het laden van de GDT e.d.

VMWare is dus * wel * een emulator, alleen een slimme die grote delen code op de CPU zelf uit laat voeren. Maar voor hij dat moet doen moet hij die code wel eerst analyseren, omdat die instructies erin kunnen zitten waar hij geen rechten toe heeft

Overigens, VMWare ondersteunt niet elk OS (zoals bv Minix, OS/2, BeOS, QNX ), dus het kan goed zijn dattie je eigen OS ook niet wil booten. Mja de enige manier om daarachter te komen is proberen

Bochs overigens ook niet, maar wat is de echte reden dat VMWare dat niet ondersteunt? (serieuze vraag). Volgens mij levert het devteam van VMWare geen 'support' voor die OS'en, maar draaien ze wel gewoon onder VMware

[JayTaph]

Alsjeblieft, een donatie van een snapshot van een oud os'je wat ik voor de fun heb geschreven. Ik zag em toevallig op een ouwe backup staan dus dump ik em maar bij jullie neer.

Ik heb geen FLAUW idee wat werkt en wat niet, aangezien het een snapshot is, dus ga er maar vanuit dat je er veel aan moet gaan doen.

Voordeel wel is dat het een werkende bootloader heeft, en dat het een C-kernel heeft met een eigen stdlib die (volgens mij) werkt. Het geraamte van het OS is dus al klaar en je kunt em mooi gebruiken als naslagwerk..

Als je vragen over het os hebt mag je proberen om ze te sturen, maar ik beloof niet dat ik nog weet wat alles precies doet

download het hier: http://www.goldenrose.org/cvs-cybos-150401.tgz


have fun...

[Oguz286]

JayTaph schreef op 07 September 2003 @ 23:23:
Alsjeblieft, een donatie van een snapshot van een oud os'je wat ik voor de fun heb geschreven. Ik zag em toevallig op een ouwe backup staan dus dump ik em maar bij jullie neer.

Ik heb geen FLAUW idee wat werkt en wat niet, aangezien het een snapshot is, dus ga er maar vanuit dat je er veel aan moet gaan doen.

Voordeel wel is dat het een werkende bootloader heeft, en dat het een C-kernel heeft met een eigen stdlib die (volgens mij) werkt. Het geraamte van het OS is dus al klaar en je kunt em mooi gebruiken als naslagwerk..

Als je vragen over het os hebt mag je proberen om ze te sturen, maar ik beloof niet dat ik nog weet wat alles precies doet

download het hier: http://www.goldenrose.org/cvs-cybos-150401.tgz


have fun...

Mijn held:
Ik ga het even doornemen DANKJEWEL

[Oguz286]

Oguz286 schreef op 08 september 2003 @ 15:51:
[...]


Mijn held:
Ik ga het even doornemen DANKJEWEL

EDIT: hoe compile ik dit in hemelsnaam

OMG HEB IK MEZELF GEQUOTE
Sorrie Modjes...

[ Voor 12% gewijzigd door Oguz286 op 08-09-2003 15:54 ]

[Oguz286]

Niemand? Weet niemand hoe ik die source van JayTaph moet compilen? (ik heb geen tijd om dat uit te vogelen, omdat ik met persoonlijke dingen te druk ben )

Ik krijg allemaal .v bestanden
Moet ik dat in linux compilen ofzo ?

[.oisyn]

Oguz286 schreef op 09 September 2003 @ 16:00:
(ik heb geen tijd om dat uit te vogelen, omdat ik met persoonlijke dingen te druk ben )

ja sorry hoor, maar dat gaan wij natuurlijk niet voor jou doen. Als jij er geen tijd voor hebt dan heb je natuurlijk gewoon pech gehad

[Oguz286]

.oisyn schreef op 09 September 2003 @ 16:06:
[...]


ja sorry hoor, maar dat gaan wij natuurlijk niet voor jou doen. Als jij er geen tijd voor hebt dan heb je natuurlijk gewoon pech gehad

Ik vraag jullie niet of jullie het voor me willen compilen
Ik wou alleen weten hoe?

[Soultaker]

Het is een CVS repository dump. Je moet de hele zut dus ergens uitpakken, daarna je CVS root instellen op de locatie waarin je de boel hebt uitgepakt, en met je favoriete CVS tooltje de boel uitchecken.

Details zoek je maar op in de CVS handleiding. Onder de meeste Linux/UNIX-achtige systemen is wel een CVS systeem geinstalleerd; voor Windows vind ik TortoiseCVS wel prettig (maar WinCVS wordt ook wel gebruikt).

edit:
Ik ben even vriendelijk geweest en heb 'm voor je uitgecheckt (niet geheel zonder eigenbelang ).
• cybos-150401.tar.gz

[ Voor 24% gewijzigd door Soultaker op 10-09-2003 00:45 . Reden: URL fix0rt ]

[Oguz286]

dankjewel alleen werkt die link niet

[Reptile209]

Deze doet het wel. Miste een U in de URL.

[JayTaph]

euh, cvs idd.. as said, tis een ouwe backup.

Ik ben er zelf weer ffkes mee bezig geweest (er zijn her en der dingetjes die gewoon niet werken) en vanuit een dos-port omgezet naar een linux port (wat aanpassingen in de makefiles voornamelijk).

Ik heb hier een werkende versie in bochs draaien met een kernel-interpreter (basicer dan basic) en 2 tasks die afzonderlijk van elkaar draaien..

Helaas gaan de virtuele consoles (ctrl-tab) nog niet helemaal lekker (niet alle chars komen op de goeie console terecht), en dat probleem is ooit opgelost geweest.. grote vraag alleen is: wat was het ook alweer (jammer )


tis geen code geschikt voor een coding-keurmerk, maar het is redelijk te begrijpen wat er allemaal staat en ik zal dan mijn (nieuwe) tarfile die wel werkt straks ffkes online gooien.


maar aan sich geeft de source een goed (en redelijk eenvoudig) inzicht in hoe je vanuit een bootloader naar een C-source gaat, hoe multitasking werkt etc... maar het is en blijft vrij basic dus misschien een leuke start...

[JayTaph]

ok, de ouwe cvs-file is weg (gereplaced door een symlink naar onderstaand).


http://www.goldenrose.org/jayos-090903.tgz


Ik heb de naam wat aangepast, (jeeej), gezorgd dat de code (althans, bij mij) compiled en draait, wat aanpassingen gedaan aan de makefiles en wat code die niet werkte gekicked.

[Oguz286]

JayTaph schreef op 09 september 2003 @ 19:58:
ok, de ouwe cvs-file is weg (gereplaced door een symlink naar onderstaand).


http://www.goldenrose.org/jayos-090903.tgz


Ik heb de naam wat aangepast, (jeeej), gezorgd dat de code (althans, bij mij) compiled en draait, wat aanpassingen gedaan aan de makefiles en wat code die niet werkte gekicked.

OK ik ga er naar kijken
Mag ik er stukken uit gebruiken voor een tutorial?

TnX

[_the_crow_]

@Jaytaph: Heb jij de Protected-Mode INT-handlers opnieuw gemaakt?? Of gebruik je de 16-bit routines uit RM?

[JayTaph]

Wat bedoel je met opnieuw maken? Zodra het systeem eenmaal in pmode draait maak ik geen gebruik meer van bestaande interrupts.

In idt_init (idt.c) maak ik een IDT aan met 256 default handlers (uit israsm.S en deze doet niets) en hang ik aan de irq functies de handle_irqX routines uit israsm.S).
Deze routines zetten een stackje op, springen naar de do_irqX functies van idt.c.

De meeste van deze irq-handlers doen niets, maar een aantal zijn belangrijk, bijvoorbeeld do_irq0, waar de scheduler/timer op zit, do_irq1 waar de keyboard handler aan hangt en do_irq13 waarmee je general protection faults kunt afvangen.

Verder kun je nog een systemlibrary hangen aan een int (zoiets als een DOS 21h of linux 0x80). Persoonlijk vind ik dit een lelijke manier van werken maar da's ook weer ieder voor zich.

[_the_crow_]

En als je iets van je hd/fd wil lezen dan? Dan lijkt me dat je INT 13h wil gebruiken. Of doe je dat dan via aparte functies?

[JayTaph]

Dat gaat straks via aparte functies, eventueel kun je er trap/gates voor gebruiken en terugschakelen naar realmode als het echt moet.

Maar op dit moment zijn die nog niet van belang dus zitten ze er nog niet in.

[johnwoo]

JayTaph schreef op 11 September 2003 @ 14:04:
Wat bedoel je met opnieuw maken? Zodra het systeem eenmaal in pmode draait maak ik geen gebruik meer van bestaande interrupts.

In idt_init (idt.c) maak ik een IDT aan met 256 default handlers (uit israsm.S en deze doet niets) en hang ik aan de irq functies de handle_irqX routines uit israsm.S).
Deze routines zetten een stackje op, springen naar de do_irqX functies van idt.c.

De meeste van deze irq-handlers doen niets, maar een aantal zijn belangrijk, bijvoorbeeld do_irq0, waar de scheduler/timer op zit, do_irq1 waar de keyboard handler aan hangt en do_irq13 waarmee je general protection faults kunt afvangen.

Verder kun je nog een systemlibrary hangen aan een int (zoiets als een DOS 21h of linux 0x80). Persoonlijk vind ik dit een lelijke manier van werken maar da's ook weer ieder voor zich.

Hoe doe je system calls dan? Ik zie in stdlib/os dat je een SYSCALL_INT gebruikt voor os_write, maar ik kan die verder niet terugvinden in de interrupt routines Hoe maak je je kernel duidelijk dat-ie iets moet doen?

Overigens wel bere-interessant om door te lezen, de principes snap ik allemaal wel, alleen de implementatiedetails zijn me nog onduidelijk (waarom bepaalde getalletjes op bepaalde plaatsen), maar daar helpt je OSje me weer een eindje verder mee

Ik ben als oefening aan het proberen om er kernel waits in te bouwen, zodat ik een task kan laten sleepen Ik hou in de kernel een aantal waitable 'objecten' bij, om het maar even op de Windows manier te zeggen Tot nu toe heb ik twee typen 'objecten': een countdown timer (de scheduler geeft de task vrij zodra de timer op 0 komt; hiermee kan je sleepen) en een flag (de scheduler geeft de task vrij zodra een andere task de flag omgooit; hiermee kan je taken synchroniseren). In de JAYOS_TASK struct prop ik een extra byte waarin de index van een van die waitables staat. Kijken of dit me gaat lukken _{Alleen moet ik dus nog zien uit te vissen hoe ik vanuit een task, een syscall kan doen...}

[.oisyn]

johnwoo schreef op 11 september 2003 @ 19:57:
[...]

Hoe doe je system calls dan? Ik zie in stdlib/os dat je een SYSCALL_INT gebruikt voor os_write, maar ik kan die verder niet terugvinden in de interrupt routines Hoe maak je je kernel duidelijk dat-ie iets moet doen?

een callgate (nee niet de tandpasta ) is daarvoor het handigst. Bij een callgate kun je specificeren dat de cpu een aantal bytes die op dat moment op de stack staan moet kopieren naar de stack van de kernel zelf, zodat je voor de ring0 en de ring3 aparte stacks kunt houden. Ideaal dus, aangezien het doorgeven van functieargumenten over het algemeen via de stack gebeurd. Niet alles past tenslotte in registers

[johnwoo]

.oisyn schreef op 11 September 2003 @ 21:25:
[...]


een callgate (nee niet de tandpasta ) is daarvoor het handigst. Bij een callgate kun je specificeren dat de cpu een aantal bytes die op dat moment op de stack staan moet kopieren naar de stack van de kernel zelf, zodat je voor de ring0 en de ring3 aparte stacks kunt houden. Ideaal dus, aangezien het doorgeven van functieargumenten over het algemeen via de stack gebeurd. Niet alles past tenslotte in registers

Klinkt handig idd, maar toch nog enkele vraagjes
Je kan de CPU dus die stack data laten kopieren naar je kernel stack... Is dat een bepaalde IA32 instructie, of hoe gaat dat in z'n werk? En dan, wat gebeurt er nadat die data gekopieerd is? Dan moet de kernel daar iets mee doen. Als eerste moet de CPU dus je kernel code gaan uitvoeren. De task die het gebeuren in gang zette kan verder toch niets nuttigs meer doen voordat de kernel de request afgehandeld heeft. Hoe krijg je die CPU dan zover dat ie (zonder interrupt voor zover ik begrijp) automagisch naar je kernel switcht? En de data die gekopieerd is kan vanalles zijn, hoe weet je kernel wat ie precies met die nieuwe data op z'n stack aanmoet? Bepaal je daar zelf een format voor, of is er hardware mee gemoeid?

* johnwoo interessante materie vindt *

[.oisyn]

Nou ja dit staat natuurlijk allemaal beschreven in de intel docs, ik ga niet uitleggen wat nou precies de werking is.

Maar in grote lijnen is een callgate gedefinieerd in de descriptor table. Je roept een call gate routine aan door simpelweg een FAR call te doen naar de betreffende selector, het offset gedeelte van de FAR pointer wordt genegeerd. De callgate descriptor beschrijft de code selector, de offset, privilege level en het aantal parameters dat gekopieerd moet worden. De stack registers voor de privilege level waar je naartoe springt worden uit het huidige task register gehaald

[ Voor 6% gewijzigd door .oisyn op 11-09-2003 23:07 ]

[johnwoo]

.oisyn schreef op 11 September 2003 @ 23:06:
Nou ja dit staat natuurlijk allemaal beschreven in de intel docs, ik ga niet uitleggen wat nou precies de werking is.

Maar in grote lijnen is een callgate gedefinieerd in de descriptor table. Je roept een call gate routine aan door simpelweg een FAR call te doen naar de betreffende selector, het offset gedeelte van de FAR pointer wordt genegeerd. De callgate descriptor beschrijft de code selector, de offset, privilege level en het aantal parameters dat gekopieerd moet worden. De stack registers voor de privilege level waar je naartoe springt worden uit het huidige task register gehaald

Ja, maar de Intel docs hebben een hogere drempel. Jij legt het in wat makkelijker te snappen bewoordingen uit En ik hoef zeker niet alles voorgekauwd te hebben, maar wat je dus postte (de principiele werking, niet de droge specs) is precies wat ik graag wil weten Dus tnx

[JayTaph]

johnwoo schreef op 11 September 2003 @ 19:57:
[...]

Hoe doe je system calls dan? Ik zie in stdlib/os dat je een SYSCALL_INT gebruikt voor os_write, maar ik kan die verder niet terugvinden in de interrupt routines Hoe maak je je kernel duidelijk dat-ie iets moet doen?

Overigens wel bere-interessant om door te lezen, de principes snap ik allemaal wel, alleen de implementatiedetails zijn me nog onduidelijk (waarom bepaalde getalletjes op bepaalde plaatsen), maar daar helpt je OSje me weer een eindje verder mee

Ik ben als oefening aan het proberen om er kernel waits in te bouwen, zodat ik een task kan laten sleepen Ik hou in de kernel een aantal waitable 'objecten' bij, om het maar even op de Windows manier te zeggen Tot nu toe heb ik twee typen 'objecten': een countdown timer (de scheduler geeft de task vrij zodra de timer op 0 komt; hiermee kan je sleepen) en een flag (de scheduler geeft de task vrij zodra een andere task de flag omgooit; hiermee kan je taken synchroniseren). In de JAYOS_TASK struct prop ik een extra byte waarin de index van een van die waitables staat. Kijken of dit me gaat lukken _{Alleen moet ik dus nog zien uit te vissen hoe ik vanuit een task, een syscall kan doen...}

Dat klopt, er zitten callgates in die niet geimplementeerd zijn. De stdlib stamt af van een anders os die ik toendertijd gebruikt heb omdat ik weinig zin had om een complete stdlib voor mezelf te schrijven. De meeste van die routines zijn dus niet door mijzelf geschreven en sommige werken ook gewoon niet goed samen. de write-functies en dergelijke werken niet, omdat ze een unsupported interrupt gebruiken.

Mijn huidige printf() functies maken onderhands gebruik van de conio_* functies. Een beetje vooruitziende blik vertelt ons dat je dus flink in de knoei gaat komen zodra je op een andere ring gaat werken..

aan de andere kant: ik heb ook nooit gezegd dat dit een goed doordacht, laat staan fucntioneel, os is dat sommige dingen gewoonweg niet kloppen of wanneer je denkt dat het gewoonweg niet gaat werken,.. dan zul je eens best gelijk kunnen hebben :-)

maar een beetje alles uitbreiden op het bestaande is wel een goed idee om wat ervaring op te bouwen.. vastlopen ga je vanzelf en vanaf dat punt zul je waarschijnlijk ondertussen de ervaring hebben om een goed OS duidelijk vanaf de grond op te bouwen

[.oisyn]

Het jammerlijke van een eigen OS bouwen is dat je op een gegeven moment gewoonweg niet verder komt... je moet drivers gaan schrijven voor je hardware om er wat leuks mee te doen. En bovendien kun je er verder niets mee.

Het was voor mijzelf erg leuk om ermee bezig te zijn, maar daarna had ik het ook wel weer gezien. Niet unlike een van mijn andere projectjes overigens, maar die hebben tenminste nog de potentie om af te komen

[JayTaph]

.oisyn schreef op 12 September 2003 @ 01:11:
Het jammerlijke van een eigen OS bouwen is dat je op een gegeven moment gewoonweg niet verder komt... je moet drivers gaan schrijven voor je hardware om er wat leuks mee te doen. En bovendien kun je er verder niets mee.

Gelukkig dat een zekere meneer Torvalds niet hetzelfde dacht..

Het was voor mijzelf erg leuk om ermee bezig te zijn, maar daarna had ik het ook wel weer gezien. Niet unlike een van mijn andere projectjes overigens, maar die hebben tenminste nog de potentie om af te komen

Niemand heeft ooit gezegd dat een project het algemeen nut moet dienen. Bijna alle projecten zijn van mij zijn ter leringh ende vermaeck. Als ik ga denken over "what's the use of this" dan zal ik weinig achter me computer doen..

"I code because I can"