Eigenes OS?

abc.w

Erhard Henkes schrieb:

Könntest Du in der 106er bitte diese ergänzte Funktion in flpydsk.c einbauen, um heraus finden, wo es bei Dir mit der USB-Floppy aussteigt:
...

Kleiner Verbesserungsvorschlag zu Debug-Ausgaben: gcc kennt __FILE__ und __LINE__, z.B.:

printformat("%s: %u", __FILE__, __LINE__);
printformat("DEBUG %s: after irq_install_handler (line %u)", __FILE__, __LINE__);

abc.w

Erhard Henkes schrieb:

Könntest Du in der 106er bitte diese ergänzte Funktion in flpydsk.c einbauen, um heraus finden, wo es bei Dir mit der USB-Floppy aussteigt:
void flpydsk_install(int irq)
{
    irq_install_handler(irq, i86_flpy_irq);
    printformat("DEBUG flpydsk.c: after irq_install_handler");
    flpydsk_initialize_dma();
    printformat("DEBUG flpydsk.c: after flpydsk_initialize_dma");
    flpydsk_reset();
    printformat("DEBUG flpydsk.c: after flpydsk_reset");    
    flpydsk_drive_data(13, 1, 0xF, TRUE);
    printformat("DEBUG flpydsk.c: after flpydsk_drive_data");
}
Ich tippe auf "flpydsk_drive_data" als Hemmschuh.

Bekomme folgende Ausgabe:

DEBUG flpydsk.c: after irq_install_handler
DEBUG flpydsk.c: after flpydsk_initialize_dma

Erhard Henkes

Aha! Der Reset ist also schon das Problem.

// reset controller
void flpydsk_reset()
{
	ULONG st0, cyl;
	flpydsk_disable_controller();
	flpydsk_enable_controller();
	flpydsk_wait_irq();

	// send CHECK_INT/SENSE INTERRUPT command to all drives
	int i;
	for(i=0; i<4; ++i)
		flpydsk_check_int(&st0,&cyl);
	flpydsk_write_ccr(0);              // transfer speed 500kb/s
	flpydsk_drive_data(3,16,240,TRUE); // pass mechanical drive info: steprate=3ms, load time=16ms, unload time=240ms
	flpydsk_calibrate(_CurrentDrive);  // calibrate the disk
}

Ja, da ist bereits ein flpydsk_drive_data(...) drinnen, aber auch ein flpydsk_wait_irq(). Ganz schön verschachtelt der ganze Kram. Könntest Du bitte weiter suchen?

Aha! Vielleicht ist ja alles ganz trivial:

// flpydsk.c (version 105+106)

// die 240 hier
void flpydsk_reset()
{
(...)
 flpydsk_drive_data(3,16,240,TRUE); // pass mechanical drive info: steprate=3ms, load time=16ms, unload time=240ms
(...)
}

// hat auf "data" keinen Einfluß: (240 & 0xF) -> 0
void flpydsk_drive_data(ULONG stepr, ULONG loadt, ULONG unloadt, int dma )
{
(...)
 data = ((stepr & 0xf) << 4) | (unloadt & 0xf);
 flpydsk_send_command(data);
(...)
}

Erhard Henkes

@ +gjm+: Bootest Du auch mittels USB-Floppy?

Aha! Vielleicht ist ja alles ganz trivial

Hast Du einen konkreten Verbesserungsvorschlag? Mit einem klassisch angebundenen Floppy-LW läuft es (fast überall, einige störrische PCs gibt es leider immer).

http://www.isdaman.com/alsos/hardware/fdc/floppy.htm
siehe Abschnitt "Fix Drive Data (x3h)"
http://www.isdaman.com/alsos/hardware/fdc/floppy_files/FixData.gif
Ich denke, dass die ganze Funktion falsch aufgebaut ist, 240 daher ein Fehler und 15 (0xF) als "Head Unload Time Entry" richtig ist.
Passt ja auch zu: flpydsk_write_ccr(0); // transfer speed 500kb/s

Auf jeden Fall erkennt man hier, dass Floppy-Treiber und Bootloader momentan bei PrettyOS von einer gemeinsamen Gruppe bearbeitet werden müssen. Wir sind ja schon mitten drin.

Also folgendes probieren:

// reset controller
void flpydsk_reset()
{
	ULONG st0, cyl;
	flpydsk_disable_controller ();
	flpydsk_enable_controller ();
	flpydsk_wait_irq ();

	// send CHECK_INT/SENSE INTERRUPT command to all drives
	int i;
	for(i=0; i<4; ++i)
		flpydsk_check_int(&st0,&cyl);
	flpydsk_write_ccr(0);              // transfer speed 500kb/s
	flpydsk_drive_data(3,16,0xF,TRUE); // pass mechanical drive info: steprate=3ms, load time=16ms, unload time=240ms (entry: 0xF) //http://www.isdaman.com/alsos/hardware/fdc/floppy.htm //Fix Drive Data (x3h)
	flpydsk_calibrate(_CurrentDrive);  // calibrate the disk
}

0xF anstelle 240

Erhard Henkes schrieb:

@ +gjm+: Bootest Du auch mittels USB-Floppy?

Asche auf mein Haupt! Das hätte ich lieber mal von Anfang an sagen sollen: Stage 1 in seiner jetzigen Form funktioniert nur mit Floppy-Laufwerken. Das er (scheinbar) auch mit USB-Floppys oder USB-Sticks funktioniert, hat einen ganz trivialen Grund: Das BIOS emuliert! Aber spätestens nach Stage 2 ist der Prozessor im PM. Dann ist Feierabend mit dem BIOS und PrettyOS läuft nur noch solange nach Plan weiter, bis es zum ersten Zugriff im PM auf das Laufwerk kommt. Effektiv testen (was heißt über Stage 2 hinaus) kann man PrettyOS z.Zt. nur mit einem physikalisch vorhandenen Floppy-Laufwerk. (Oder indem der Quellcode gelesen wird). Aber technisch gesehen ist es nach wie vor möglich, PrettyOS von einem USB-Floppy oder einem "pen drive" zu starten. Die Frage ist eigentlich nur, ob man im PM auf das "Bootgerät" zugreifen will oder muß (oder wird). Deshalb gibt es in dem Sinne leider auch keine Verbesserungsvorschläge.

Erhard Henkes

@ +gjm+: Du meinst der Floppy-Treiber kann nichts ausrichten, weil er nicht mehr an den Floppy-Controller heran kommt? Ich kann es nicht testen, weil ich kein USB-Floppy-LW besitze.

Auf jeden Fall haben wir einen Fehler im Floppy-Treiber gefunden. Wenn man bei 500K Transfer Rate die 240 ms Head Unload Time haben will, muss man 0xF eingeben und nicht 240. Analog muss man auch noch die Head Load Time Eingabe überprüfen. Da macht das offensichtlich aber nur Faktor 2 aus.
http://www.isdaman.com/alsos/hardware/fdc/floppy.htm

taljeth

Auf den FDC zugreifen, bringt offensichtlich nichts, wenn das Laufwerk ein USB-Gerät ist. In dem Fall bräuchtest du USB-Treiber. Das BIOS bietet dir halt den passenden Treiber über int 13h an, deswegen funktioniert das, solange du das BIOS benutzt.

Erhard Henkes

Das wirft nun für die OS-Community Grundsatzfragen für das Design auf, denn die meisten User haben heutzutage kein klassisch angeschlossenes Floppy-LW mehr, lediglich die USB-Variante.
@ taljeth: hast Du einen Link auf ein Beispiel, wo jemand mit USB-Treiber auf eine Floppy zugreift? Auf der anderen Seite wäre dann der USB-Stick die bessere Variante. Also entweder klassische Floppy oder USB-Stick?

Mal nicht so schnell jetzt. Im Prinzip darf in der ckernel.c nur nicht "direkt" (was heißt per Name) auf "irgendwas" in der flpydsk.c zugegriffen werden. Das ist eigentlich schon alles was vielleicht geändert werden sollte. Irgendwann kommt eh noch eine pendrv.c hinzu.

Erhard Henkes

@ +gjm+: Wir sind noch zusammen.

http://www.usb-center.de/Externe_USB-Floppy_-_USB-Diskettenlaufwerk_USB-1901.html

Im Prinzip darf in der ckernel.c nur nicht "direkt" (was heißt per Name) auf "irgendwas" in der flpydsk.c zugegriffen werden.

Richtig, da muss eine Abstraktionsebene dazwischen.

Ehrlich gesagt habe ich die USB-Floppy eigentlich für einen Hoax gehalten. Wenn PrettyOS USB im PM unterstützt, dann werden gleichzeitig eine ganze Reihe von Geräten unterstützt. Darauf sollte PrettyOS durch "Abstraktion" langsam vorbeitet werden. Aber bevor die Geräteflut hereinbricht.

Erhard Henkes

Heute abend um 21.20 h treffen wir uns im Channel #PrettyOS.

Erhard Henkes schrieb:

Heute abend um 21.20 h treffen wir uns im Channel #PrettyOS.

^^ vielleich schau ich auch mal rein.

Erhard Henkes

^^ vielleich schau ich auch mal rein.

Ja, mache das! Wäre schön.

erhard:
http://www.usb.org/developers/docs/usb_20_052709.zip
http://www.compaq.com/productinfo/development/openhci.html

Erhard Henkes

Thx

Erhard Henkes

Dass dieser Thread mal die 50000er Lese-Marke knackt, hätte ich mir am 13.03.2009 nicht träumen lassen.

Mich würde mal interessieren, wer alleine oder mit anderen an einem eigenen OS entwickelt, zu welchem Zweck und in welcher Sprache (ASS, C oder C++)? Links?

Erhard Henkes schrieb:

Thx

kein problem, ist aber tatsächlich viel holz. wäre ein fulltime job für 1..2 monate (lernaufwand für PCI bussystem und hardware interrupt-handling auf pc-kisten nicht eingerechnet). aber nicht so, wie dieser trottel 'XanClic' erzählt. der scheint das ganze nur sabotieren zu wollen.

Einfach nur den Begriff "DOS" ignorieren:
http://www.frontiernet.net/~fys/usb.htm