Thema: Ein Drahthaufen und sein Betriebssystem... Fragen zum Aufbau des OS.

[Jonathan]

Nee, das kann sich nicht berühren - das Kabel ist an der Stelle komplett mit Lötzinn durchtränkt, das ist stocksteif. Berühren kann sich deshalb nichts. Und danke für den Respekt


Es funktioniert übrigens immer mehr:


Auf dem Screenshot sieht man folgendes: Der Kernel hat bereits die Hardware initialisiert (sogut das ohne Treiber eben geht *hust*) und startet testweise einen zweiten Prozess. Dann begibt sich der Kernel Task in eine Endlosschleife, wo er per RST 20h immer die CPU zurück ans Betriebssystem abgibt. Die Zeit, die der abgebende Prozess noch übrig hat, bekommt dann der nächste Prozess, der Zeit braucht, zugewiesen - in dem Fall der Test-Prozess. Dieser gibt dann einfach in einer Schleife mit Wartezeit immer wieder die ihm verbleibenden Zeitscheiben aus - 1, 2, 1, 2... Funktioniert also. Die maximal verfügbare Zeit wird übrigens auf 4 Zeitscheiben begrenzt, damit nicht ein Prozess alles blockiert, nachdem das System eine Zeit lang im Leerlauf lief.


Gruß
Jonathan

[Jonathan]

So, geb ich doch mal wieder ne Rückmeldung von mir.

Inzwischen hab ich mal alle Datenstrukturen, die der Kernel so braucht, testweise angelegt, um den Speicherverbrauch grob zu bestimmen. Wie schon gesagt, ich hab ja nur 16kB Platz.


Etwa 2,5kB hab ich noch Platz, da der Stack ja auch in den selben Speicher muss. Da rein müssen nur noch Funktionen für's Messagesystem und für's Treibersystem passen - wird in Assembler wohl gut hinhauen. Schwein gehabt. 

Läuft dann auf folgendes hinaus:
- Puffer von 8 Messages je Prozess
- Speicherpool für eine gesamte Pufferung von bis zu 255 Messages mit je 12 Bytes Daten
- Bis zu 255 registrierbare Treiber


Gruß
Jonathan

[Jonathan]

Lang ist's her, weiter geht's.

Message- und Treibersystem haben nun auch noch ihren Platz im knappen Kernelspeicher gefunden und funktionieren. Die Kommunikation zwischen Prozessen läuft über Messages an PID:Interface-Adressen. Jeder Prozess hat dabei bis zu 256 Interfaces, die er z.B. als einen Treiber registrieren kann. Somit kann ein einzelner Prozess nach außen hin mehrere Funktionen zur Verfügung stellen, was wegen meiner Hardware nötig ist.

Inzwischen habe ich mir - anders als geplant - einen C-Compiler für den Z80 gesucht und zum Laufen gebracht. Jetzt mache ich zuerst mal die IDE-Karte fertig und programmiere dann einen ersten kleinen Festplattentreiber.


Gruß
Jonathan

[Svenska]

Hallo,

welchen C-Compiler benutzt du denn? SDCC?
Hast du vor, das System selfhosting zu machen, oder bleibt es ein Cross-Development?

Gruß,
Svenska

[Jonathan]

Genau, ich nutze SDCC. Selfhosting ist noch nicht geplant, könnte aber (viel) später noch realisiert werden - wenn ich einen Assembler und einen Compiler für das System umschreiben bzw. neu schreiben kann, und man das System halbwegs komfortabel bedienen kann. Momentan funktioniert dafür aber noch viel zu wenig.


Gruß
Jonathan

[Jonathan]

Und weiter geht's: Da mich die Festplatte im Moment absolut nicht gern hat, und ich noch keine Ahnung habe, wieso das Ding das tut, geh ich solange erstmal die mangelnde Geschwindigkeit des Boards an: s/55ns-SRAM/10ns-SRAM/g. Ich konnte bei Kessler Electronic zwei Stück (sonst kaum zu bekommende) 512kB-10ns-SRAMs ergattern, die ich jetzt anstatt der momentan langsamsten Komponente (55ns-RAM) in mein Board einbaue. Vielleicht kann ich dann ja sogar wieder auf 32MHz hochtakten. Schön wär's. Lediglich das SOJ-SMD-Gehäuse der RAMs ist etwas blöd, aber auch nicht unlötbar.

EDIT: Falls es jemanden interessiert, bei meinem RAM handelt es sich um IS61C5128AL-10KLI.


Gruß
Jonathan

[Jonathan]

So, also, äh, *räusper*

Alle die, die gedacht haben, hier wär eh tot, muss ich wohl leider enttäuschen: Is' nich

Geht nämlich schon die ganze Zeit über weiter, diesmal mit komplett neuer Hardware... Das alte Ding wurde langsam echt nicht mehr brauchbar, die Schaltung funktionierte nach einigen Änderungen schlicht nicht mehr, und in dem Drahtverhau kann man keine Fehler suchen. Deshalb gibt's jetzt eine vollständig modulare zweite Version des Computers, bei der auch die CPU, das BIOS, die MMU usw. auf Steckkarten leicht austauschbar sind.

Die Hauptplatine an sich funktioniert schon mal (inklusive CPU-, MMU- und BIOS-Modul), und aus gegebenem Anlass poste ich mal ein Bild von der Grafikkarte, die gerade zum ersten mal ihren nicht initialisierten VRAM erfolgreich auf einen Monitor geworfen hat:


Die Karte kann 80x60 Text darstellen und nutzt die VGA-Auflösung 640x480 bei zwei Farben. Auf dem Character-ROM befindet sich Codepage 437, später wird die auch noch umschaltbar sein. Der VRAM fasst 256 Textzeilen zu je 80 Zeichen, außerdem kann die Karte Hardware-Scrolling, sodass man einen 60 Zeilen langen beliebig wählbaren Ausschnitt aus dem VRAM auf dem Monitor darstellen kann. Das dürfte wohl für Konsolen-Ausgabe ziemlich nützlich sein.


Gruß
Jonathan

[streetrunner]

Da es den anderen anscheinend die Sprache verschalgen hat:

Das sieht ja schon sehr vielversprechend aus was deine Grafikkarte da ausgibt. Kannst du ein wenig mehr über die Funktionsweise erklären? Leider erkennt man auf dem Bild nicht wirklich was.

Gruß,
Streetrunner

[Jonathan]

Klar, kann ich gern tun:

Inzwischen ist die Grafikkarte fertig und voll funktionsfähig. Sie unterstützt folgende Features:
- 640x480 VGA-Auflösung mit 2 Farben (S/W)
- 80x60 Textmodus (80 Spalten, 60 Zeilen)
- Codepage 437 aus einem ROM, später auch umschaltbare Codepages (bis zu 32 CPs)
- 8x8 Pixel pro Zeichen, DOS-Font
- 32kB VRAM
- 80x256 Textpuffer, unterstützt Hardware-Scrolling (es ist ein beliebiger 60 Textzeilen langer Bereich auswählbar, der dann auf den Bildschirm ausgegeben wird)
- Random Access, die CPU muss nicht während bestimmter Zeitpunkte (z.B. Sync) auf den VRAM zugreifen, sondern kann jederzeit unbeschränkt auf dem VRAM rumschreiben, ohne Bildstörungen zu verursachen. Dabei wird kein Dual-Port-RAM verwendet.


Die Karte selbst arbeitet intern recht kompliziert, und vorallem auf einem ziemlich schnellen Timing. Das gesamte Timing orientiert sich rund um einen Zyklus von 8 Pixeln, also einem Textzeichen.

Der Bus, über den die CPU die Karte (und auch alle anderen Hardware-Karten) ansteuern kann, ist bei der Grafikkarte an einer asynchronen Register-Logik angeschlossen. Diese besteht zur Zeit aus drei Registern: Dem Hardware-ID-Register (0x01 identifiziert die Standard-Grafikkarte), dem Scrolling-Positions-Register (hier kann man die Nummer der ersten Zeile reinschreiben, die auf dem Display dargestellt werden soll, um das Hardware-Scrolling zu steuern), und dem Zeilenauswahlregister für Schreibzugriffe (hier kann man eine Zeile im VRAM auswählen, welche zum Schreiben eingeblendet werden soll). Außerdem besitzt die Karte in der oberen Hälfte ihres Adressbereichs (die obersten 128 Bytes) etwas Logik, um dort Teile des VRAMs einzublenden. Dadurch kann die CPU auf eine durch ein Register ausgewählte Zeile direkt schreiben. Ein eventueller Schreibzugriff auf den VRAM wird von einem Puffer aufgenommen und kann dann von der Karte im richtigen Moment (wenn der VRAM gerade zum Schreiben verfügbar ist) ausgeführt werden.

Die VGA-Ausgabelogik der Karte nutzt Bus-Multiplexing. Hier werden zunächst durch zwei Zählerbausteine die Pixel der Zeile gezählt, und basierend darauf die Nummer des aktuell in der Zeile auszugebenden Zeichens berechnet. Nach 640 Pixeln wird die Schwarzschulter- und HSync-Logik aktiviert, und nach 800 Pixeln der Zähler zurückgesetzt und ein Signal zum Weiterschalten der Zeile erzeugt. Das Zählen der Zeilen wird von einem Mikrocontroller übernommen, der auch gleich das Hardware-Scrolling übernimmt, indem beim Start des Bildes der Wert im Scrolling-Register als Startwert des Zählers genommen wird. Der Controller generiert außerdem die vertikalen Schwarzschultern und das VSync-Signal.

Ein weiterer Mikrocontroller (ATTiny24 auf Pixeltakt 25,175MHz) generiert die Steuersignale für den internen 8-Pixel-Zyklus der Karte. Jedes Pixel dauert knapp 40ns. Während des ersten Pixels werden Bus-Treiber aktiviert, welche die Daten und die Adresse des VRAM-Schreib-Puffers an den VRAM anlegen. Sind gültige Daten vorhanden (das Data-Present-Flipflop gesetzt), wird dem VRAM beim zweiten Pixel ein Schreib-Befehl gegeben und die Daten geschrieben. Beim dritten Pixel wird das Data-Present-Flipflop wieder zurückgesetzt. Sobald das vierte Pixel beginnt, schaltet der Controller die Bustreiber für die interne Adresse an und die anderen Bustreiber wieder aus. Dadurch werden Zeilen- und Spaltennummer des aktuellen Zeichens als Adresse auf den VRAM gegeben. Dem VRAM wird ein Read-Befehl gegeben und der ASCII-Code des Zeichens ausgelesen. Dieser ASCII-Code wird noch im selben Zeitpunkt dann auf das Schriftart-ROM gegeben. Während dem 5. und 6. Pixel wartet die Karte darauf, dass das langsame Schriftart-ROM die Pixeldaten ausliest. Genau am Ende des 7. Pixels werden dann schließlich die neuen Pixeldaten (1 Byte, also 8 Pixel) in ein Schieberegister geladen und der Zugriff auf das VRAM beendet. Während das Schieberegister dann die 8 Pixel ausgibt, beginnt die Karte schonmal damit, im nächsten Zyklus die nächsten 8 Pixel zu laden.

Die Karte wurde mit 74HC-Gattern aufgebaut, also mit Logikgattern ohne besonders hohe Geschwindigkeit.


Und zum Abschluss noch ein paar Fotos von der funktionierenden Karte:

https://www.dropbox.com/s/9ou4emzv0mjy3g7/IMG_20140706_193439.jpg
https://www.dropbox.com/s/zick2o9gw7760hi/IMG_20140706_193255.jpg
https://www.dropbox.com/s/l4gy1vm6cdgneo0/IMG_20140707_220735.jpg
https://www.dropbox.com/s/kq521cfxrwchfqa/IMG_20140708_185714.jpg

1. Bild: Fertige Karte (Bestückungsseite)
2. Bild: Fertige Karte, eingesteckt in einen Slot des Eigenbau-Systems
3. Bild: CPU schreibt Testdaten in den VRAM, wird erfolgreich ausgegeben
4. Bild: Die holprigen Anfänge eines BIOS...


Gruß
Jonathan

[Jonathan]

Und weiter geht's...

Houston, wir haben einen Interruptcontroller:
https://www.dropbox.com/s/n59lf1t7f79w4fj/IMG_20140817_173718.jpg

Besteht aus 6 Chips (ATMega8515, 2x 74HCT563, 74HCT74, 74HCT32) und besitzt folgende Features:
- 8 Interrupts, pro angeschlossenem Gerät einer
- Priorisierung (fest vorgegeben)
- 300kHz max. Interruptfrequenz
- Integrierter programmierbarer Timer (40Hz bis 40kHz, höchste Interruptpriorität)
- Software Reset / Interrupt disable
- Config-Register zum Steuern des Interruptcontrollers / Timers

Und jetzt bastel ich mir als nächstes die serielle Schnittstelle ans System 


Gruß
Jonathan

[Jonathan]

Mal den Thread entstauben...

Inzwischen wurde mehrmals der ganze Kernel über den Haufen geworfen und neu gemacht. Wieso "Everything is a file" so praktisch ist und wieso ein gutes VFS so wichtig ist, habe ich inzwischen auch gelernt. 

Deshalb gibt's jetzt anstatt dem schwachsinnigen Mikrokernel einen modularen Monolithen mit anständigem VFS.




Viele Grüße
Jonathan

[gale]

Wurde auch mal Zeit...

[Jonathan]

Inzwischen ist das VFS so ziemlich fertig, das Ding lädt seine Treiber ohne zu meckern und auch ein bisschen Multitasking hab ich schon. Nur yield() wäre noch ganz nett.

Man kann sogar schon mit einer kleinen Shell sprechen und Dinge auf dem Dateisystem tun:


(Ja, ich weiß, "print" tut auf Unix eigentlich was anderes. Aber ein vollständiges "cat" wollte ich nicht, Redirection kann meine Shell noch nicht und ich brauchte irgendwie halt nen Namen.)

Läuft zwar alles noch über die serielle Schnittstelle, aber mit einem Tastatur- und Bildschirmtreiber wird sich das schnell ändern.


Viele Grüße
Jonathan

[Jonathan]

Einen halben Kilometer Draht und unzählige Lochrasterplatinen später: Das Projekt ist soweit abgeschlossen und vollständig lauffähig!

Kleiner Überblick über die Hardware:

• Z80-CPU (CMOS) mit 4MHz
• 1MB RAM (banked), maximal 4MB, 16kB-Pages
• 16kB Boot-ROM für den Kernel
• POST
• Programmierbarer Interruptcontroller, programmierbarer Timer
• Steckplätze für 4 Erweiterungsmodule (erweiterbar auf 252 Plätze...)
• ROM-Modul als Speicherort für ein ROFS (32kB)
• RS232-Interface
• VGA-Ausgang (80x60 Textmodus, Hardwarescrolling)
• PS/2-Tastaturcontroller (umfunktionierter x86-KBC)

Und die Software:

• Modularer monolithischer Eigenbau-Kernel (C/Z80-ASM, Toolchain: SDCC)
• POSIX-ähnliches VFS
• Nachladen von Treibern als Kernelmodule (zur Laufzeit)
• Mounten von Treibern/Geräten im VFS
• Bus-Scan und automatisches Laden der benötigten Treiber
• Laden und Ausführen von Executables vom VFS
• Präemptives Multitasking
• Minimalistische Shell (cd, ls, more, exit, Programme ausführen)
• BASIC-Interpreter/-Editor
• Ein paar weitere kleine Anwendungsprogramme

Ein beschreibbares Dateisystem wäre aber auch noch ganz nett... Und vielleicht ein paar mehr nützliche Programme, etc - da werde ich garantiert noch weiter dran basteln 

Vielleicht wäre es auch mal Zeit für eine Wiki-Seite, wer weiß?


Viele Grüße
Jonathan