4. PrettyOS Fehler-/Testthread

PrettyOS Fehler-/Testthread

  • E
    Mod

    @+gjm+: was genau würdest du ändern im assembler programm fat12.inc?
    Hier der von dir angesprochene Bereich, der nun versagt:

    ;******************************************************************************
; LoadFile ()
; ES:SI   File to load
; EBX:BP  Buffer to load file to
; AX      Return value: success 0, error -1
;******************************************************************************

LoadFile:
	xor	ecx, ecx					; size of file in sectors
	push ecx

.FIND_FILE:
	push bx						; BX=>BP points to buffer to write to; store it for later
	push bp
	call FindFile				; find our file. ES:SI contains our filename
	cmp	ax, -1
	jne	.LOAD_IMAGE_PRE
	pop	bp
	pop	bx
	pop	ecx
	mov	ax, -1
	ret

.LOAD_IMAGE_PRE:
	sub	edi, ROOT_OFFSET
	sub	eax, ROOT_OFFSET

	; get starting cluster
	push word ROOT_SEG				;root segment loc
	pop	es
	mov	dx, WORD [es:di + 0x001A]	; DI points to file entry in root directory table. Refrence the table...
	mov	WORD [cluster], dx			; file's first cluster
	pop	bx							; get location to write to so we dont screw up the stack
	pop	es
	push bx							; store location for later again
	push es
	call LoadFAT

.LOAD_IMAGE:
	; load the cluster
	mov	ax, WORD [cluster]		; cluster to read
	pop	es						; bx:bp=es:bx
	pop	bx
	call Convert_Cluster_to_LBA
	xor	cx, cx
	mov cl, BYTE [SecPerClus]
	call ReadSectors
	pop	ecx
	inc	ecx
	push ecx
	push bx
	push es
	mov	ax, FAT_SEG						;start reading from fat
	mov	es, ax
	xor	bx, bx

	; get next cluster
	mov ax, WORD [cluster]				; identify current cluster
	mov cx, ax							; copy current cluster
	mov dx, ax							; copy current cluster
	shr dx, 1   						; divide by two
	add cx, dx							; sum for (3/2)
	mov	bx, 0							;location of fat in memory
	add	bx, cx
	mov	dx, WORD [es:bx]
	test ax, 1						    ; test for odd or even cluster
	jnz	.ODD_CLUSTER

.EVEN_CLUSTER:
	and dx, 0000111111111111b	        ; take low 12 bits
	jmp	.DONE

.ODD_CLUSTER:
	shr	dx, 4				            ; take high 12 bits

.DONE:
	mov	WORD [cluster], dx
	cmp	dx, 0x0ff0				        ; test for EOF
	jb .LOAD_IMAGE

.SUCCESS:
	pop	es
	pop	bx
	pop	ecx
	xor	ax, ax
	ret

%endif
    0
  • ?

    Kurz gesagt, das Problem tritt genau hier auf:

    .LOAD_IMAGE:
 ; load the cluster
 mov ax, WORD [cluster]
 pop es
 pop bx
;-------genau hier-----
; falls bx == 0xFE00 dann bleibt ReadSectors hängen
;-------genau hier-----
 call Convert_Cluster_to_LBA
 xor  cx, cx
 mov  cl, BYTE [SecPerClus]
 call ReadSectors
(...)

    Wenn ReadSectors im "int 0x13" stecken bleibt, dann mag es sein, daß der Puffer [ES:BX] ungültig ist. Aber das kann ja nicht sein. 0xFE00 + 0x0200 (BytesPerSec) wäre dann genau die "Kante", also eigentlich ok. 😕

    Zumindest sitze ich grade dran. 🙂

    0
  • E
    Mod

    aktueller Kernel: 52.560 Bytes

    0
  • C

    aktueller Kernel (mit Mac erstellt): 52.432 Byte

    0
  • ?

    Die Sache ist schwieriger als gedacht. Einen Hotfix hätte ich schon, aber den poste ich lieber nicht weil der die Denkweise von angehenden Programmierern bis in alle Ewigkeit versauen würde. 🙂

    Probiert jetzt mal, falls Zeit und Spaß vorhanden, soviele Userprogramme wie möglich zu schreiben und bindet sie alle gleichzeitig mit ein. Die Userprogramme sollten möglichst "fett" und "verschwenderisch" sein, z.B. ein Menü, welches nur etwas anzeigt und sonst "nichts" macht.

    // makefile:

tools/CreateFloppyImage2 PrettyOS FloppyImage.bin (...) $(KERNELDIR)/KERNEL.BIN 
$(USERTEST)/HELLO.ELF $(USERTEST)/PROG01.ELF $(USERTEST)/PROG02.ELF (usw.)

    Möglicherweise gibt es noch ein "Folgeproblem" in der fat12.c.

    0
  • M

    ich hab jetzt mal 5 Progs eingebunden, je 4-7 Kb... Alles funktioniert noch.
    Worin sollte denn das Folgeproblem bestehen?

    EDIT: Einen Schönheitsfehler hab ich gefunden: Bei fdir verrutscht bei Dateinamen kleiner 3 Zeichen die Ausgabe...

    0
  • F

    Falls ihr das Problem noch nicht gelöst habt, es macht mehr Sinn bei einem Pointer ES:BX, BX immer "0" zu lassen und 0x20 (512bytes bei einem Segment-Register um 8 bits nach rechts geshiftet) auf es zu addieren, so umgeht ihr das 64kb Problem.

    Nur mal so als Denkanstoß!

    0
  • E
    Mod

    Programme in die kernel.bin einbinden läuft über initrd.exe und incbin ..., nicht via FloppyImage ( ist wie kopieren der elf-Files nach Laufwerk A: ).

    0
  • ?

    Das Hauptproblem beim Laden der KERNEL.BIN lag lustigerweise in der "boot2.asm". Dort wird der Stack bei Label "entry_point:" wieder auf 0000:FFFF gesetzt. Dadurch gerät er in Konflikt mit allem, was ab 0000:0500 bereits geladen wurde (und noch wird).

    In der "Fat12.inc" gibt es einen "Denkfehler". BP ist kein Segmentregister. [BP:BX] geht nicht, aber [BP+BX] geht.

    Hier die sehr grob "gefixten" Versionen der boot2.asm und der Fat12.inc, damit der Spaß beim Programmieren weitergehen kann.

    Änderungen sind mit "==HOTFIX==" gekennzeichnet. Zumindest sollte damit jetzt eine KERNEL.BIN > 57 KB problemlos geladen werden. 🙂

    0
  • E
    Mod

    Danke! Du hast uns vor raschem GRUB bewahrt. 🙂

    0
  • ?

    Wie gesagt, ist nur sehr grob gefixt. Ab ca. 118 KB ist der Spaß wieder vorbei. Offenbar kommt sich da noch mehr ins Gehege. Ist zu erwarten, daß in nächster Zeit die KERNEL.BIN 118 KB erreicht? Eigentlich wollte ich an meinem Userprogramm weiterbasteln. 🙂

    0
  • M

    Eig. ist das nicht zu erwarten... Zumindest nicht in den nächsten paar Wochen. (Wenn Du Zeit&Lust hättest wär es natürlich schon schön, wenn Du auch die 118KB-Grenze beheben könntest, aber das ist nicht so eilig 🙂 ).

    Mach ruhig erstmal an Deinem Userprog weiter. wir haben ja grad mal 52 KB erreicht.

    0
  • E
    Mod

    Erstmal dickes Dankeschön! 🙂

    0
  • ?

    Via Hotfix sind ca. 250 KB möglich. Unangenehmerweise enthält der Bootloader fest vergebene Adressen, die sich langsam ins Gehege kommen. Aber darum kann man sich auch später noch kümmern.

    Hier mal ein Screenshot von meinem Userprogramm. PrettyOS lernt grade, was eine "Festplatte" ist. 🙂

    Btw. der 08. März 2010 ist bei mir ein Montag.

    0
  • F

    Ohne mir den Source-Code jetzt angeguckt zu haben, werfe ich einfach mal UnrealMode ein (kann sein das ihr das schon nutzt).

    Wie ladet ihr denn den Kernel, wird er erst komplett geladen und dann an eine andere Position verschoben/kopiert, wenn ja, dann kann man das immer gleich machen braucht so nur nen Buffer der so groß ist wie ein Cluster und kann (UnrealMode vorausgesetzt) Dateien beliebiger Größe laden.

    0
  • M

    +gjm+: Dein Treiber sieht Klasse aus!

    0
  • ?

    Vielen Dank! 🙂

    Nun gibt es aber ein Problem in der "time.c" mit dem Wochentag. Der Grund dafür ist, einfach gesagt, daß es zwei verschiedene "Arten" vom CMOS gibt:

    1. Register 0x06 zählt von 1 bis 7,
    2. Register 0x06 zählt von 0 bis 6.

    Per Software kann man nicht herausfinden, ob Register 0x06 von 1 bis 7 oder von 0 bis 6 zählt. Deshalb wäre es besser wenn der Wochentag anhand des Datums ausgerechnet wird. Dazu muß man nur von einem bekannten Datum bis heute die Anzahl vergangener Tage ausrechnen und dann einfach modulo 7.

    Der 01.01.1900 ist immer eine gute Idee. Der ist zufälligerweise ein Montag.

    0
  • E
    Mod

    1. Register 0x06 zählt von 1 bis 7,
    2. Register 0x06 zählt von 0 bis 6.

    Wirklich bekloppt so was.

    0
  • M

    Theoretisch wär ja wohl sogar noch mehr Mist denkbar... Rückwärts zählen z.B. 😉

    0
  • ?

    Revision 210

    Bochs kommt mit folgendem "Fliesskomma-Ausdruck" nicht zurecht und rechnet "falsch":

    // time.c Revision 210
unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) {

 day += 6; //1.1.2000 was Saturday
 day += (year-2000)*365.25;          // <- hier 

(...)
}

    VB und VPC schlucken ihn aber und rechnen korrekt. Vielleicht könnte die Routine so umgeschrieben werden, daß man auf eine "365.25" verzichten kann? 🙂

    0
Anmelden zum Antworten