Sourcecode Fortschritt
-
Rev. 59:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=59fat.c: FAT2 nun analog FAT1
- Noch eine Menge Optimierungspotential
- date/time fehlt noch
-
Rev. 60:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=60In fat12.c - testweise - noch ein "Preformat" eingefügt, das die ersten 32 Sektoren komplett auf eine Zahl (0xAA) setzt, bevor die eigentliche Fortmatierung startet.
Die Routine muss noch auf das Track-weise Schreiben (18 Sektoren auf einmal) angepasst werden.EDIT: das fformat ist bisher leider nur qemu-fähig. Auf echten PCs wird bisher nicht formatiert. Fehler wird durch Debuggen (ohne Preformat) gesucht. Die Funktion steigt bereits ganz vorne aus:
/// write bootsector retVal = flpydsk_write_boot_sector(&b); if(retVal != 0) { printformat("E_Disk - flpydsk_write_boot_sector"); return E_DISK; }Problem liegt hier (um timeout-Routine ergänzt für Fehlersuche):
int32_t flpydsk_write_sector_ia( int32_t i, void* a) { memcpy((void*)DMA_BUFFER, a , 0x200); uint32_t timeout = 2; // limit int32_t retVal = 0; while( flpydsk_write_sector(i) != 0 ) { retVal = -1; timeout--; printformat("error write_sector. left: %d\n",timeout); if(timeout<=0) { printformat("timeout\n"); break; } } if(retVal==0) { printformat("success write_sector.\n"); } return retVal; }Das Problem mit echter Hardware liegt also in flpydsk_write_sector(i).
qemu läuft anstandslos.Ich lade diese Version mit Fehlerroutine hoch. Vielleicht findet jemand die Lösung für flpydsk_write_sector(i).
Rev. 61:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=61
-
Rev. 62:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=62Der seek-Vorgang auf realer Hardware läuft nun so ab, dass man die Analyse des Schreibvorgangs auf realer Hardware starten kann (Meldungen sind noch merkwürdig).
Während auf qemu mit echter Floppy alles perfekt läuft, sieht das auf realer Hardware noch sehr verwirrend aus. Das Format-Ergebnis ist ebenfalls nicht ok.
Da stimmt noch etwas beim 'seek' nicht.
Siehe: http://www.c-plusplus.net/forum/viewtopic-var-t-is-253791-and-start-is-10.html
-
Rev. 63:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=63Noch einige Änderungen in flpydsk.c (seek, ...), allerdings läuft der Cylinder-Seek-Prozess auf echter Hardware beim Schreiben nicht ordnungsgemäß.
Hat jemand eine Idee?
-
Rev. 64:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=64In flpydsk.c wurde in das seek ein calibrate (setzen auf cyl. 0) eingeschoben. Nun funktioniert das Sektor-Schreiben auf Floppy Disk auch mit echter Hardware. Die Vorgänge müssen allerdings noch massiv bezüglich Effizienz (zu langsam, Motor on/off optimieren) und Effektivität (viele seltsame Zeichen bei fdir) optimiert werden. Aber der seek-Fehler ist nun hoffentlich behoben.
Rev. 65:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=65
calibrate ohne motor on/offRev. 66:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=66
motor on/off beim Schreiben in Format ausgeschaltet, dadurch verläuft die Formatierung deutlich schneller.
-
Rev 67:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=67
timeout in read_sector von 2 Sekunden auf 2 mal umgestellt (für langsame Rechner)Danke an Cuervo für die Tests mit dem "lahmen" Schulrechner.
-
Rev.68:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=68fformat: Änderung im Algorithmus von "sectorenweisem" Schreiben auf Schreiben von ganzen Tracks. Nun ist das Quickformat (Bootsector, FAT1 u. FAT2, RootDir) viel schneller. Bei manchen Disketten gibt es die Fehlermeldung: No ID address mark
Ursache bisher nicht klar (hat vielleicht etwas mit quickformat zu schaffen).
Frage: was muss man machen, damit die Diskette als brauchbar/lesbar akzeptiert wird (nur wichtig für Lesen mit Hex-Editor via Windows-Laufwerk a: )Links:
http://technet.microsoft.com/en-us/library/cc776720(WS.10).aspx
http://www.microsofttranslator.com/BV.aspx?ref=CSSKB&from=en&to=de&a=http://support.microsoft.com/kb/130627/en-us?fr=1When you quick format an unformatted floppy disk, correct data structures are placed; however, no media test and verification of cluster usability are performed.
Was ist der "media test"?
Wie wird die "verification of cluster usability" durchgeführt?
Vor allem: wie wird dies auf der Diskette dargestellt? (dies könnte man ja antäuschen.
Die normale Kennung für Format im Datenbereich seit MSDOS ist 0xF6.
-
Die Frage von erik.vikinger bezüglich Floppy vs USB wurde wegen der Grundsätzlichkeit für die weitere Entwicklung abgetrennt: http://www.c-plusplus.net/forum/viewtopic-var-t-is-260047.html
-
Rev. 69:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=69- Nur noch wichtige Meldungen beim Formatieren
- kleine Verbesserungen in fat12.c
-
Rev. 70:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=70Vor und nach dem Formatieren wird der Inhalt des Root Directories testweise gezeigt (jeweils 2 Sekunden Pause zwischen zwei Einträgen).
Anmerkung: Test von Funktionen als Vorbereitung auf den Ladevorgang.
-
Rev. 71:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=71Zwischenschritte:
- name.ext (8+3) in ROOT DIRECTORY finden (Bsp. 'KERNEL.BIN'), TODO: variabel via shell machen
- FAT1 parsen (TODO: durch motor on/off beim read_sector(...) noch zu langsam, dadurch aber sehr gut verfolgbar)
vgl. mit http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId839021
Der Einfachheit halber wurde dies als ///TEST ... ///TEST in 'fformat' vor dem eigentlichen Quickformatvorgang eingehängt.
-
Rev. 72:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=72Erkennung von Filename/extension stabilisiert (bei einigen Versuchen hatte es Probleme gegeben. strncpy ok?)
FAT parsen beschleunigt.
Später soll man z.B. 'kernel.bin' in der shell eingeben. Dann wird zunächst in der shell selbst nach dem Befehl gesucht und falls nicht vorhanden, das File auf der Floppy Disk gesucht und entweder geladen/ausgeführt (z.B. xxx.elf) oder nach dem Finden als nicht ausführbar dargestellt (z.B. bin oder sys oder ...).
-
Rev. 73:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=73Zwischenschritt: File wird probeweise mittels FirstCluster und zugehöriger FAT-Chain in einem Array file[...] aufgebaut.
Der Algorithmus ist allerdings nicht brauchbar, da der zweite Cluster via FAT-entry[i] gefunden wird (siehe Rev.74).
-
Rev. 74:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=74Zwischenschritt:
Algorithmus zum Auffinden der Cluster-Kette mittels 2nd_Cluster = FAT[1st_Cluster] als Start.- File 'program.elf' auf die Diskette kopieren, da dieses File gesucht wird
- Testet den Algo mittels 'fformat'
-
Rev. 75:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=75Zwischenschritt:
Suche nach 'kernel.bin' und "Laden" in ein Array file[...].
Noch immer in den fformat-Befehl eingebunden.Nächster Schritt: Auslagern in eigene Load-Funktion und Start via Eingabe des Filenamens in der Shell.
-
Rev. 76:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=76fdir: file ohne Extension nun auch ohne Punkt
makefile: rm -f .o
fat12.c: algorithmus korrigiert, FAT-Clusterkette wird zu langsam gelesenProblem: Unterschiedliche Inhalte in File-Array bei real PC (1./2. Cluster identisch eingelesen) und qemu (klappt gut). Lesevorgang? DMA?
Anmerkung:
noch bei 'fformat' testweise untergebracht, bis es richtig läuft, dann separate Load-Funktion mit Start durch die shell.
-
Rev. 77:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=77Meilenstein: (noch eingebettet in 'fformat')
Separate Load-Funktion: flpydsk_load(char* name, char* ext):
In dieser Version gelingt erstmalig das Laden und Ausführen einer Datei (hello.elf, 3 Cluster) von Floppy Disk! Screenshot:
http://www.henkessoft.de/OS_Dev/Bilder/Load_Process_from_Floppy.PNG
(Anmerkung: Der dritte Cluster besteht nicht nur aus lauter Nullen, sondern enthält genau ab Byte 21 Daten unterschieldich zu 0x00. Es werden allerdings jeweils die ersten 20 Byte eines Clusters zur Kontrolle angezeigt. Der beste Beweis, dass der Vorgang klappt, ist selbstverständlich, wenn ein Programm ordnungsgemäß startet.)
-
Rev. 78:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=78Nun kann man den Dateinamen, z.B. "hello.elf" oder einfach "hello", auch "hello." direkt in der Shell eingeben.
Läuft allerdings noch nicht völlig rund - Zeichendarstellung verschoben, ab und zu #PF(beim Ausführen des Programms?) - aber es ist unser Einstieg in die bunte Landschaft der User-Programme, mal abgesehen von der im Kernel mittels "incbin" mitgelieferten Shell.
Zur Zeit kann nur das elf-Format "seziert" werden. Ideen für kleine Programme sind bereits genügend vorhanden.
Die hoffentlich ausgeführte Datei befindet sich übrigens hier:
...\PrettyOS\trunk\Source\user\user_test_c\
Sourcecode:#include "userlib.h" int main() { settextcolor(12,0); puts("Hello, Pretty Operating System World!\n"); puts("This piece of software was loaded by PrettyOS from your floppy disk.\n"); settextcolor(15,0); return 0; }Nun können wir entsprechende User-Programmideen umsetzen (makefile und Umgebung muss noch entsprechend erweitert werden. Ich habe das Programm hello.elf einfach durch Substitution von program.c und anschließendem Rücktausch erzeugt, denn wir müssen ja start.asm und das passende Linkerskript beim Compilieren/Linken verwenden.). Damit lenkt sich der Blick auch auf die vorhandene und noch zu erweiternde API (syscalls) und die magere/fehlende C-Bibliothek im User-Bereich.
Vielleicht findet jemand die Gründe, warum es manchmal zu #PF kommt und warum echte Hardware in einigen Fällen (auf meinem Entwicklungsrechner von ca. 2004 funktioniert es) noch Lese-Probleme macht, während es dagegen mit qemu problemlos funktioniert.
Am besten mit qemu probieren (FloppyImage.bin wird ja mitgeliefert bzw. beim Compilieren erzeugt), da es auf echter Hardware noch eindeutig zu wenig performant abläuft (im 5-10 Minuten-Bereich).
-
Rev. 79:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=79Verbesserungen bei der Eingabe in der Shell
-
Rev. 80:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=80Verbesserungen in fat12.c
