Sourcecode Fortschritt
-
Version 46:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=46Die neuen Bezeichnungen boot2.bin und kernel.bin wurden überall eingebaut und der Fehler im Makefile behoben.
Der Kernel wird aber noch nicht gestartet!
-
Version 47:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=47Nun überall Großschrift in den asm für die Dateinamen (BL1, BL2)
Alles auf BIN gesetzt (nicht mehr SYS)
Fehler im makefile berichtigt: start.asm (user) wurde nicht assembliertNun gibt es einen ASSERTION Fehler:
ASSERTION FAILED((const void*)(header->entry) == USERCODE_VADDR) at kernel/elf.c
:153OPERATING SYSTEM HALTED
-
Sorry für die Verwirrung! Bin auch gerade online gegangen weil ich die Fehler bemerkt hatte, beim Übertragen auf den INet-Rechner ist wohl was schief gelaufen.
Die meisten Sachen hast du ja erfolgreich behoben, die start.asm aus dem User-Prozess muss noch mitkompiliert werden (ist irgendwie aus dem Makefile rausgeflutscht) und ein assert muss aus elf.c raus:
ASSERT( (const void*)(header->entry) == USERCODE_VADDR );
Das User-Programm startet nämlich nicht bei 0x01400000, sondern 0x200 Bytes später. Warum auch immer. Funktioniert aber trotzdem.
=> Version 48
-
Folgendes geht bei mir lokal:
- ASSERTION in Zeile 153 auskommentiert, damit die shell startet (Grund für diese Maßnahme momentan unklar)
- readelf und batch-Datei in User
- floppy_build.bat für direktes Starten des Build-Prozesses im ExplorersMomentan kann ich nicht committen wegen Konflikt
Super! Badestrand und ich haben das gleiche gemacht. Ich schieb mal meine Luxusklasse-Ausführung für faule Windows-Anwender hinterher:
Version 49
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=49In bochs bevorzuge ich übrigens
floppya: 1_44=a:, status=inserted
Vielleicht sollte man auf Dauer zwei verschiedene versionen anbieten.
-
Version 50:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=50Nun ist BOOT2.BIN und KERNEL.BIN im makefile groß geschrieben, damit es auch unter Linux problemlos läuft.
elf.c:
Zeile 129: ASSERT( header->phnum == 1 );
Zeile 152: ASSERT( (const void*)(ph->vaddr) == USERCODE_VADDR );
müssen evtl. unter Linux noch auskommentiert werden.In Windows klappt das mit dem Cross-Compiler auch mit den ASSERTs.
-
Version 51: (badestrand)
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=51
- Run the build.bat file with qemufloppy or qemuimage as parameter to start qemu.Version 52: (Erhard Henkes)
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=52
- Systemfrequenz auf 1000 Hz erhöht
- getCurrentMilliseconds() ergänzt (syscall)
- "Zug" bewegt sich alle 20 Millisekunden flüssig nach vorneEs war mir ein Bedürfnis den "Zug" (Beispielanwendung für das dreizeilige Laufband) zu :xmas1: Weihnachten :xmas2: betriebsbereit zu haben. Er läuft im User-Bereich (z.Z. noch in der Shell) lässt sich durch den neuen Millisekunden-Timer und die neue System-Frequenz von 1000 Hz ziemlich rasant über den Bildschirm bewegen. Leider ist er noch keine eigene Task. Daher kann man ihn z.B. mit langwierigen Aktionen wie 'fdir' ausstoppen.
Anstelle des Zuges könnte auch Ihre Werbung stehen.
-
Version 53:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=53- Folgendes auskommentiert in elf.c:
Zeile 11: static const void* USERCODE_VADDR = (void*)0x01400000;
Zeile 129: ASSERT( header->phnum == 1 );
Zeile 152: ASSERT( (const void*)(ph->vaddr) == USERCODE_VADDR );- Folgendes ergänzt:
Zu den CFLAGS noch "-m32" hinzufügen
In die Linkerscripte (kernel.ld, user.ld) "OUTPUT_ARCH(i386)" hinzufügenNun sollte es von Seiten Linux und 64-Bit keine Barrieren geben. Erste Tests bestätigen dies!
http://www.cyberciti.biz/tips/compile-32bit-application-using-gcc-64-bit-linux.html
-
Version 54:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=54- build.sh für Linux ergänzt
- tools/bochsrc ergänzt
- Zug auf vielfachen Wunsch etwas ausgebremst (40 Zeichen/sec) :xmas1:Der "Zug" steht nur stellvertretend für das zukünftige Informationsband, in dem Diagnosedaten angegeben werden. Wir wollen ja ein Lehr-OS schaffen.
-
Version 55:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=55
-fno-pic im makefile ergänzt
in userlib.c __asm__ anstelle asmScreenshot: http://www.henkessoft.de/OS_Dev/Bilder/Rev55.PNG
-
Version 56:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=56
- flpydsk_read_directory() nach fat12.c ausgelagert, da spezifisch für Dateisystem FAT12
in fat12.h/c sollen die FAT12-spezifischen Funktionen zur Dateiverwaltung auf Floppy Disk abgelegt werden.
-
Rev. 57:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=57- fat12.h/.c: Quickformat für die FloppyDisk implementiert ("fformat")
läuft noch nicht fehlerfrei (FAT2 wird nicht analog zu FAT1 geschrieben), funktioniert aber bereits. Kann auch mit FloppyImage.bin getestet werden. Als Hex-Editor empfehle ich für die echte Floppy den Hex-Editor Neo, da dieser direkt Volumes auslesen kann.Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/Rev57.PNG
Leider fehlte in dieser Version (vielleicht auch schon vorher in 56) die fat12.c!
-
Rev. 57a:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=58- fat12.h/.c: Quickformat für die FloppyDisk implementiert ("fformat")
läuft noch nicht fehlerfrei (FAT2 wird nicht analog zu FAT1 geschrieben), funktioniert aber bereits. Kann auch mit FloppyImage.bin getestet werden. Als Hex-Editor empfehle ich für die echte Floppy den Hex-Editor Neo, da dieser direkt Volumes auslesen kann.Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/Rev57.PNG
Diese Version sollte komplett sein.
-
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
