4. Ein kleines Demo-16Bit-OS

Ein kleines Demo-16Bit-OS

  • ?

    Das ist eine gute Frage! Ich habe keine Ahnung, wie das mit Bochs funzt, da ich es nicht nutze! Ich habe noch nie ein OS mit Bochs booten können, daher interessiere ich mich auch nicht dafür.

    0
  • W

    Soweit ich weiß muss man da erst ein ellenlanges Configfile für Bochs schreiben, damit der das Image laden kann. Habe es selber auch noch nie geschafft ein OS unter Bochs zu laufen zu bekommen. Ich habe immer nach dem ersten oder zweiten Versuch das Handtuch geworfen.

    0
  • N

    Hi.

    Das Beispiel-Configfile von Bochs wirkt so erstmal ziemlich erschlagend. 😃
    Da muss man sich dann halt einfach mal zusammenreissen und das Ding komplett durchgehen. Wenn man da mal scharf drauf guckt, erklaert sich das eigentlich alles von selbst.
    So viel ist das dann letztendlich naemlich auch nicht.

    Wenn ich das in der .bat-Datei richtig gesehen habe, werden Boot.bin und Kernel.bin schon zu MyOS.bin zusammengepackt.
    Damit hat man dann eigentlich schonmal das DiskettenImmage, das dann nur noch Bochs schmackhaft gemacht werden muss. 😃
    Dann sollte das auch ohne Probleme unter Windows laufen, und man hat sich nicht nur den Aerger mit dem Reboot etc. gespart, sondern praktisch auch einer Diskette ihr Leben verlaengert. 😉

    0
  • W

    Also ich hab mir jetzt das Configfile so umgeschrieben (Kommentare aus Platzgründen rausgenommen):

    config_interface: textconfig
display_library: win32
romimage: file=BIOS-bochs-latest, address=0xf0000
megs: 32
vgaromimage: VGABIOS-elpin-2.40
floppya: 1_44=myos.bin, status=inserted
ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14
ata1: enabled=0, ioaddr1=0x170, ioaddr2=0x370, irq=15
ata2: enabled=0, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11
ata3: enabled=0, ioaddr1=0x168, ioaddr2=0x360, irq=9
boot: floppy
ips: 1000000
floppy_bootsig_check: disabled=0
log: bochsout.txt
panic: action=ask
error: action=report
info: action=report
debug: action=ignore
debugger_log: -
parport1: enabled=1, file="parport.out"
log=sb16.log, dmatimer=600000
vga_update_interval: 300000
keyboard_serial_delay: 250
keyboard_paste_delay: 100000
floppy_command_delay: 500
mouse: enabled=0
private_colormap: enabled=0
script=SCRIPT
script=./tunconfig
keyboard_mapping: enabled=0, map=
initrd=../initrd.img
usb1: enabled=1, ioaddr=0xFF80, irq=10

    Allerdings startet Bochs zwar richtig, aber dann blinkt nur noch folgende Schrift auf...

    Bochs Bios (usw.)

Booting from floppy...

    Woran könnte sowas liegen?

    0
  • ?

    Genau das passierte bei mir auch. Was macht Bochs eigentlich? Simuliert es ein BIOS, dass den Bootsektor (und damit den Bootloader) nach 0x07C0:0 lädt, oder übernimmt Bochs vielleicht schon die Aufgabe des Bootloaders und erwartet einen Kernel als Image?!
    Wie gesagt, ich kenne mich nicht mit aus! Ich kann es mir nur so erklären, dass er versucht das System zuladen und an zu jumpen, dabei aber in die Wallachei springt, und so den "Reboot" auslöst (darum das Blinken).

    0
  • W

    Also soweit ich weiß emuliert Bochs die ganze Maschine.

    0
  • T

    MaSTaH schrieb:

    Also soweit ich weiß emuliert Bochs die ganze Maschine.

    Ack, so ist es. Sprich lädt auch nur wie ein BIOS an 0x7c00 und sprignt dorthin.

    0
  • W

    Es muss aber an dem myOS liegen, weil mit der selben Konfiguration konnte ich z.B. eben ein auf Floppyformat abgespecktes FreeBSD laden.

    0
  • T

    Vielelichtauf irgendwas implementation-dependent nicht beachtet. So wie dass nicht immer an 0:7c00 gesprungen wird, sondern manchmal auch 07c0:0 (genau das hat mich mit Bochs mal einige Zeit gekostet *G*)

    0
  • C

    So wie dass nicht immer an 0:7c00 gesprungen wird, sondern manchmal auch 07c0:0 (genau das hat mich mit Bochs mal einige Zeit gekostet *G*)

    ist doch das gleiche... 0h:7c00h = 07c00h = 07c0h:0 = 07c00h ich sehe da kein Problem 🙂 Außerdem hat Bochs ja noch diese schöne Menueconfig!

    MFG

    LordHoto

    0
  • T

    CrazyLinux schrieb:

    ist doch das gleiche... 0h:7c00h = 07c00h = 07c0h:0 = 07c00h ich sehe da kein Problem 🙂 Außerdem hat Bochs ja noch diese schöne Menueconfig!

    Jein, wenn man Adressen im Bootsektor benutzt (für Strings z.B.) ists garnicht mehr so das gleiche, wenn man real bei 0:0x7c00 ist, aber davon ausgeht, dass der Bootsektor bei Offset 0 anfängt 🙂

    0
  • ?

    Was würde das für den Code bedeuten? Wie müsste ich die Zeile ändern?

    mov ax, 0x07C0	   ; init stack
    0
  • C

    TriPhoenix schrieb:

    CrazyLinux schrieb:

    ist doch das gleiche... 0h:7c00h = 07c00h = 07c0h:0 = 07c00h ich sehe da kein Problem 🙂 Außerdem hat Bochs ja noch diese schöne Menueconfig!

    Jein, wenn man Adressen im Bootsektor benutzt (für Strings z.B.) ists garnicht mehr so das gleiche, wenn man real bei 0:0x7c00 ist, aber davon ausgeht, dass der Bootsektor bei Offset 0 anfängt 🙂

    jmp 0x7c00:init <-- so kann man das auch lösen 😉

    MFG

    LordHoto

    0
  • N

    Auf die einfachste Loesung scheinen die OS-Bastler irgendwie immer als letztes zu kommen genauso wie sich krampfhaft dieses wiederliche cli/sti beim initialisieren des Stacks haelt. 🙄
    Setzt doch die Segmentregister nicht nach cs, sondern schiebt einen fixen Wert rein. 😉

    0
  • S

    Komisch,

    hab den quellcode neu assmebbliert.kommen immer fehler.
    warum?

    0
  • S

    Hat sich erledigt!

    0
  • ?

    hi!
    hast du schonmal probiert mit C weiterzucoden?kannst dann TurboC verwenden, is kostenlos, ich selber arbeite grad an meinem 32bit os.

    0
  • ?

    Also von weiterarbeiten kann keine rede sein, da ich den kernel komplett neuschreiben dürfte, um ihn 32bit arbeitend zu bekommen.
    Aber nur mal so ne frage: Wieso TurboC? Ich habe Version 3.1 und der compiliert zu 16bit. Ich habe zwar schon versucht mit dem weiterzumachen, aber irgendwie definiert der das COFF-Format anders als der Flatassembler: Ich kann nicht linken.

    0
Anmelden zum Antworten