Nachrichten

1061

Lowlevel-Coding / Arbeitsspeicher

« am: 26. April 2004, 14:17 »

Naja wenn man die A20 noch zu schaltet hat man auch im RM mehr;). Ich glaube aber es ging viel mehr darum zu ermitteln wie viel physikalischer Speicher in den Rechner eingebaut ist. Aber ansonsten ist im RM der verfügbare immer gleich(im allgemeinen, du tricks gilt das natürlich wieder nicht, man kann alles umgehn;))

1062

Offtopic / T-Sinus 154card unter Linux

« am: 26. April 2004, 13:01 »

Nur niemand ist gezwungen sich an die Standards zu halten;)

1063

OS-Design / Filesysteme

« am: 26. April 2004, 12:51 »

Man muss eigentlich garnicht wissen welches andere das lesen kann(M$ schert sich auch nicht drum;)) es geht eigentlich bei einem FS darum dass das OS in der Lage ist Dateien Organisiert und dauerthaft zu speichern und sie wieder lesen zu können. Wie ein anderes OS damit zurande kommt is in erster Linie dabei unerheblich. Ausserdem wart ihr vom Thema wirklich abgekommen. Denn Bestellungsprobleme bei Campusverionen haben nun wirklich garnix mit FS zu tun oder täusch ich mich?

1064

OS-Design / Filesysteme

« am: 25. April 2004, 21:30 »

Es geht um Filesysteme leutz;)

1065

Lowlevel-Coding / Bochs-emulator

« am: 25. April 2004, 17:33 »

also @coder: unter ata0 musst du als pfad irgendwie hda1 angeben und als boot: disk machen irgndwie so in der richtung müsste es gehen, hab ja auch ne image datei als festplatte angegeben, wenn man das durch ein reales ersetzt müsste es ja analog funzen.
und @cagavielleicht komtms ja von deinem OS aus das er das anzeigt:P ka wenn du sowas reingeproggt hast kann man nie wissen. ansonsten ist irgendne einstellung in deiner bochsrc falsch die müssteste dann mal posten oder so dann könnten wir vielleicht eher helfen

1066

OS-Design / Filesysteme

« am: 25. April 2004, 17:25 »

Also ich hab für euch grade mal ne Homepage zusammengeproggt und Online gestellt erreichen könnt ihrs über http://www.dieter-schumann.de/Roshl/Index.html da findet ihr dann meine FS-Spezifikationen. Die Seite ist noch im Bau weil grade erst gemacht also

1067

OS-Design / Filesysteme

« am: 25. April 2004, 14:41 »

Wie ich bereits sagte die ist in Arbeit, aber das ganze ist ein wenig umfangreich, hab mir halt viele Gedanken gemacht dazu und die letzten Gedanken werdens nicht gewesen sein. Da ich zur Zeit auch bisl Stress in der Schule hab kanns ein wenig dauern, also bitte ein wenig Geduld ist alles hier nur Hobby, das solltet ihr irgendwie berücksichtigen. Aber ich hab ein paar Posts weiter oben eine kleine Erläuterung gegeben die eine ungefähre Vorstellung geben soll. Wenn ich die entgültigen Spezifikationen fertig habe bekomt ihr sie schon rechtzeitig! Das ist wie mit dem nächsten LowLevel Mag;)

1068

OS-Design / Filesysteme

« am: 25. April 2004, 13:28 »

Man kann sie ja trotzdem durchgehend unterbringen;) meinetwegen legt man dazu noch ein Attribut irgendwo im StammOrg fest das bestimmt ob sie durchgehend oder zerhackt ist, es besteht aber die Möglichkeit das ganze zu verteilen! Also ext handhaben das glaub ich so das sie eine durchgehende Bitmap haben und die Infos über die Lage der Daten selbst in Inodes speichern, von daher ist meines recht ähnlich nur die Inodes sind in unterschiedliche Level geteilt und dadurch verkompliziert sich das ganze wieder, das hab ich wieder nicht. Auch kann die Orgstruktur zu den Datein und so ja in einem Durchgang untergebracht werden (bei Verzeichnissen gibts nur einen Org Block pro Verzeichnis und selbst damit können auf über 7000 Einträge zusammenkommen und das reicht erstmal aus). Ich hab mir dabei schon was gedacht, nur ich habs halt gern wenn Flexibilität drinsteckt und man sich aussuchen kann wie einem das lieber ist. Also: es kann verstreut sein, muss aber nicht! Und wenn wir das auf eine Diskette packen brauchen wir nur ein Block für die Bitmap und da is eh nix mit gross suchen;)
Ausserdem es kann auch Performencevorteile bringen das ganze zu zerhacken! Stell dir vor du bist irgendwo mitten auf deiner Festplatte und willst eine Datei anlegen, die Orgstruktur für die Bitmap hast du im Speicher( ein Orgblock für fast 8GB reicht ja) da kann ja ausgerechnet werden in welchem Bereich du hinwillst und anstatt ganz vorne auf die Platte zu düsen um ganz durchzuwurschteln wird nur der relevente teil gesucht, der wegen der Zerstückelung näher beim Lesekopf liegt, auch das wäre eine Möglichkeit, aber wie gesagt das soll ja die Flexibilität des FS erlauben, das ist ja der Sinn der Aktion.

1069

Lowlevel-Coding / Interrupt Vector Table

« am: 25. April 2004, 13:00 »

Sputlköppe:P also was ich lese und probiere versuche ich 3 wochen lang selbst erst wenns dann wirklich nich geht frag ich nach:P und TJ beschreibt schon recht gut das ganze...

1070

Lowlevel-Coding / Bochs-emulator

« am: 25. April 2004, 12:57 »

und inserted muss es trotzdem auch sein, glaub doch einem alten programmierhasen mal was:P *frech grinst*

1071

OS-Design / Filesysteme

« am: 25. April 2004, 12:55 »

Also das jedes FS sowas wie ne File Allocation Table braucht ist irgendwo klar, nur bei meinem ist es so das die nicht in einem Durchgang stehen muss, die Informationen dazu stehen halt bei jeder Datei selbst:D auch die Bitmap die besagt, welche Blöcke belegt sind können verteilt sein bis zum geht nicht mehr, und sind dazu noch extrem klein:D. Rechenbeispiel: Ein Block hat bei mir 1kB, also 1024 Byte, in jedem Byte stehen zu 8 Blöcken ob sie belegt sind oder nicht also 8192 Blöcke pro Block an Bitmap, das ganze mal 2 für die Sektoren, ein Sektor hat 512 Byte also mal 512, so dann das ganze in MB umrechnen und wir sehen das wir mit einem Block 8 MB verwalten können. Das würde heissen das auf einer Diskette das auch gut umsetzbar wäre, da dort ja ein Block dafür ausreicht. Also um mein FS auf eine Diskette(und jeder andere Datenträger, es wächst dann erst mit zunehmender Belegung des Datenträgers) zu packen sind grademal 4kb von Nöten: 1 Orgblock für das Stammverzeichnis, 1 Block für das Verzeichniss selbst, 1 Orgblock für die Bitmap und noch einen Block für die Bitmap selbst, ich finde schon das sich das sehen lassen kann:D erst wenn sehr viele kleine Dateien im FS sind fällt mehr an Overheaddaten an wie bei zb FAT, ansonsten ist es recht Platzsparend

1072

Offtopic / suchmaschinen

« am: 24. April 2004, 15:31 »

Ich hab auch DSL von 1&1 und ich hab keine Probleme aber probier mal www.google.com das nehm ich immer

1073

OS-Design / Filesysteme

« am: 24. April 2004, 15:29 »

Ich mach des mit dem HTML-File mal;) Ich mails dir denne mal wennu willst;)
Mit den langen Dateinamen hab ich auch schon überlegt aber bin auf keine Idee gekommen wie man des machen könnt..obwohl...hab da grad ne Idee:D
und von Grund auf neu is meins ja auch nicht, hab mich ja son bisl vom Inode System inspirieren lassen
Des mit der HTML-File kann aber noch dauern, weil is ja nich grad wenig^^ schon der erste Aspektpunkt hat ne relativ lange Tabelle zu erklärungen der einzelnen Bytes:S naja da ich heute Geburtstag hab und endlich 18 werd^^ geh ich jez erstmal feiern bis morgen leutz;)

1074

Lowlevel-Coding / Bochs-emulator

« am: 24. April 2004, 15:23 »

Ich denke mal du willst von der Floppy starten(dem Imagefile) dann ist der Fehler recht einfach:
boot: disk
floppya: 1_44="Cmos076.img", status=ejected

bei boot muss dann floppy stehn, und der status muss inserted sein
deien ips könnten auch höher sein aber daran dürfte es nit liegn;)
hoffe das hilft

1075

Das Wiki / Prozentanzeige

« am: 24. April 2004, 15:19 »

Das funzt nich:P Weil man das:
1. Nie genau sagen kann und
2. Es bereits fertig is und nur noch kompiliert werden muss und
3. Das dauert nun mal und ist schlecht abschätzbar

1076

OS-Design / Filesysteme

« am: 24. April 2004, 15:17 »

Meine Rede;) weil jeder seine eigenen Gedanken und Vorstellung hat glaub ich eher weniger dass es funzt wenn wir hier eins entwickeln das für alle sein soll. Da ich ja auch meine eignen Vorstellungen hab hab ich auch mein eigenes;) Aber mitmachen würde ich bei sowas vielleicht auch^^ mein "Treiber" für Festplatten funzt ja schon soweit ich könnte meins also schnell umsetzten, nur mein Tastaturtreiber will nich so recht deswegn liegt mein FS grad auf Eis, aber die Idee dazu ist fertig und die Algorythmen hab ich eigentlich auch im Kopf^^
Aber ich hätt nen kleinen Vorschlag für die, die ein gemeinsamen machen wollen:
Ich schreibe die Spezifikationen meines FS in eine HTML Datei und stell das dann irgendwo online, dann können wir das gemeinsam erweitern verbessern und umsetzten. Oder wer will meldet sich per ICQ:P (Irgendjemand muss ja mal ne Offensive starten sonst wird hier nix gemeinsames)

1077

Lowlevel-Coding / Bochs-emulator

« am: 23. April 2004, 18:37 »

Du kannst als Quelle für die floppy auch eine Datei angeben also statt a: oda sowas nimmst du OS.img, also die Datei die auch auf eine Diskette schreiben würdest als quelle nutzen

1078

Das Wiki / Neues Mag WANN?????

« am: 23. April 2004, 14:31 »

Sag ich doch:P /me is Profi:P

1079

OS-Design / Filesysteme

« am: 23. April 2004, 14:29 »

Ok ich versuche mal mein System kurz zu erläutern (falls später jemand weitergehendes Intresse hat kann er sich ja per ICQ melden:332061907)
Also aufgebaut ist mein FS 4 Elementen.
1. Etwas was ich Blockbitmap nenne, in dieser stehen welche Blöcke belegt sind (1Block=2Sektoren). Aber auch nur ob sie belegt sind, was sie sind steht da nicht. Wenn der erste Byte also 10010011 lautet heisst das, dass die Blöcke 1,4,7 und 8 belegt sind. Das wird verwendet um herrauszufinden wo wir zum Beispiel eine Datei hinspeichern können.
2. Ein Verzeichniss Org-Block, in diesem stehen diverse Informationen wie zum beispiel wieviele Sektoren es gibt und so weiter, von Interresse ist dieser Teil nur im Hauptblock also dem ersten der Partition, bei Unterverzeichnissen werden diese nicht gebraucht. Der zweite und wichtigere Teil besteht aus 4 Byte grossen Einträgen von denen jeder einen Zeiger auf einen weiteren Block darstellt. Alle dort aufgelisteten Blöcke beinhalten dann die Verzeichniseinträge also auf Unterverzeichnisse, Dateien usw.
3. Ein Dateien Org-Block hat mit dem Verzeichnis Org-Block Ähnlichkeit besitzt aber keine Informationsen am Anfang. Auch hier sind je 4 Byte ein Zeiger auf einen Block der Datei. Im Gegensatz zum Verzeichniss Org-Block steht in den letzten 4 Byte des Datei Org-Blocks welches der nächste Org-Block dieser Datei ist.
4. Die Verzeichnisseinträge die in den Verzeichniss Org-Blöcken stehen bestehen aus je 32 Byte. Der erste gibt an ob es eine Datei oder ein Verzeichniss ist, ob der Eintrag überhaupt belegt ist, welcher Typ von Datei(z.B. Systemdatei,ausführbar usw) dann ein paar Zeichen für den Namen, die letzen 4 geben die Dateilänge in Blöcken an, damit das verarbeitende Programm weiß wieviele es brauchen wird, und die 4 vor den letzten 4 also die Vorletzten 4(HÄ?) sagen uns in welchem Block sich der erste Datei Org-Block dieser Datei befinden.

So das wars ganz kurz:D wer Fragen hat wie gesagt bei mir melden^^

1080

Offtopic / Projektplattform

« am: 23. April 2004, 11:44 »

Es ist ja auch nocht nicht fertig:P