Der Assemblerlehrgang?
-
Nobuo T schrieb:
Dann wird also wohl DOS das richtige fuer dich sein.
Ich wuerde demnach vorschlagen, dass du dich mal in den Asm-FAQ nach Anfaengertutorials umschaust.
C/C++ Forum :: FAQ - Assembler :: ASM TUTORIALS unter "Intel Syntax Assembler Tutorials".
Wenn du das durch hast, kannst du dich ja mal in Ralf Browns Interrupt Liste (google) o.Ae. unter int 10h (fuer VGA-Grafik) oder int 16h (Tastatureingabe) umschauen und ein bissel damit rumprobieren.
Zum Thema Grafikausgabe findest du auch noch einen Thread in den FAQ.
Wenn's dann an's Schreiben eines Tastaturtreibers geht, solltest du dich mal bei den OS-Dev Links umsehen.
Schlussendlich gibt's in den FAQ auch noch einen Thread mit Infos zum Einbinden von Assembler-Code in C.Nix dos, da ich es auch auf PCs zocken will wo keine Festplatte drin ist! Also was will ich mit dos? dos ist scheisse!
-
Dann lass es halt bleiben. War ja nur ein Vorschlag.
Aber nur zu deiner Information: DOS (io.sys+command.com=~200-300Kb)
passt wunderbar neben dein Spiel auf eine Diskette und funktioniert sogar ganz ohne Festplatte. Und so eine Startdiskette laesst sich mit ein paar Klicks sogar unter Windows erstellen.
Aber wenn du dich stattdessen lieber mit grub rumschlagen und dein eigenes mini-OS fabrizieren willst, werde ich bestimmt nicht versuchen, dir das auszureden.
-
Nobuo T schrieb:
Aber wenn du dich stattdessen lieber mit grub rumschlagen und dein eigenes mini-OS fabrizieren willst, werde ich bestimmt nicht versuchen, dir das auszureden.
Danke, denn das Spiel soll sein eigenes OS sein, ich hasse GRUB (den Müll) seit ich damals Linux installiert habe.
Nun zur eigentlichen Frage:
WIE würdet ihr vorgehen bei sowas?
-
Hi,
@ ***:
wenn man dich so "reden hört", merkt man, dass du noch keinerlei
Ahnung von Assembler hast. Und meiner Meinung nach sind deine
Prioritäten ziemlich hoch gegriffen. Um einen Bootloader zu
schreiben bedarf es schon an etwas mehr Wissen als 3 Interrupts
und einem Turtorial, das du wahrscheinlich schon geblickt haben
willst, bevor du es überhaupt gesehen hast!
Aber trotzdem:
Anfangen würde ich mit nem DOS-Programm, welches ein Zeichen ausgibt
...dann kannst du immer mehr erweitern, bis du dann drin schreiben kannst
usw. Dann klappts auch vielleicht mal mit deinem Spiel, vorrausgesetzt
du willst viel viel Zeit investieren und dich ausgiebig damit befassen.
Wenn nicht, wirst du es allerspätestens beim Anblick des Quellcodes eines
Kernels aufgeben.
-
*** schrieb:
Nobuo T schrieb:
Aber wenn du dich stattdessen lieber mit grub rumschlagen und dein eigenes mini-OS fabrizieren willst, werde ich bestimmt nicht versuchen, dir das auszureden.
Danke, denn das Spiel soll sein eigenes OS sein, ich hasse GRUB (den Müll) seit ich damals Linux installiert habe.
Nun zur eigentlichen Frage:
WIE würdet ihr vorgehen bei sowas?gar nicht :p
-
Das Ganze ist doch einfach:
Nimm erstmal eine alte DOS-Diskette und lies den Bootsektor aus (Sektor 0). Kannst Du erstmal auch unter einem "richtigen" Betriebssystem programmieren. Unter GNU/Linux gibt es das Programm "dd" fuer sowas, unter Windows kannst Du unter NT/2000/XP mit CreateFile() (ggf. als Administrator) das Disketten-Geraet oeffnen und die Sektoren auslesen und in eine Datei schreiben. Anschliessend mit einem hexdump-Programm oder Disassembler auflisten.
Der Bootsektor macht nix anderes als einen BIOS-Call auszufuehren, der weitere Sektoren an die Adresse 002C (oder 002E, weiss nicht mehr) zu lesen. Such mal im Internet (vielleicht gibt's hier auf der Seite auch irgendwo einen Link) nach "BIOS call list", um eine Liste gaenger BIOS-Calls zu bekommen.
Ausserdem brauchst Du noch eine Liste gaengiger I/O Addressen (gibt's auch im Internet irgendwo).
Anschliessend geh auf die Intel-Webseite und lad dir die PDF-Files fuer die IA-32 Prozessorreihe runter. Da steht dann drin, wie Du z.B. in den Protected Mode schaltest.
Ueber die VGA oder VESA Standard-Schnittstelle (BIOS Calls oder Port-Adressen) kannst Du dann rausfinden, wie Du in den Grafikmodus schaltest, die Aufloesung umschaltest usw.
Ich kann Dir gleich sagen: Es ist eine ziemliche Sysiphus-Arbeit. Moeglicherweise musst Du auch noch Treiber fuer verschiedene Grafik- und Soundkarten programmieren.
Es hat schon einen Grund, warum es solche Boot-Spiele fuer den PC nicht gibt ...
Beim Amiga war das ja alles einfacher: Die Hardware war relativ genau definiert, jedenfalls im Low-End-Sektor, und das Betriebssystem war ja teilweise im ROM und konnte dadurch direkt nach dem Einschalten benutzt werden. Auch konnte man ja ueber Forbid() und Disable() den Rechner soweit lahmlegen, dass man in Ruhe die Custom Chips umkonfigurieren konnte, wenn man unbedingt die Hardware direkt benutzen wollte. Es ging ja auch anders: ueber Devices, Resources, und die Libraries. Fuer seine 256 K war das AmigaOS ziemlich fett im ROM, da ja die Hardware bekannt war und deshalb wenig Code gebraucht wurde.
Auf dem PC ist der Aufwand tausendmal hoeher, da ja die Hardware nicht so genau vorhersagbar ist. Wenn Du das Spiel nur fuer eine Hardwarekonfiguration schreiben willst (dann darfst Du aber auch nicht mehr die Karten im Rechner umstecken!! Nix 'expansion.library' wie beim Amiga, der Karten und Treiber automatisch beim Einschalten eingebunden hat!), dann kannst Du Dir auch die I/O-Adressen Deiner Mainboard-Konfiguration und Steckkarten besorgen und drauflos programmieren. Das Spiel laeuft dann aber nur auf Rechnern mit derselben Hardware.
Hoffe, das hilft!!
-
Damit das alles so halbwegs stimmt, muss man deinen Text aber schon mit einem ziemlich hohen Abstraktionslevel ueberfliegen.
-
Wieso? Is was verkehrt?
Kannst ruhig sagen, wuerd mich auch interessieren, wenn ich mich irre.
Hab schon lang nich mehr probiert aufm PC ohne Betriebssystem zu programmieren.
-
Hey, ***, guck mal hier:
http://www.nondot.org/sabre/os/articles
hab ich im Asm FAQ hier gefunden! Cool!
-
*sigh* Nagut, dann werde ich den Kleinkram mal aufdroeseln...
xyzxyzxyz schrieb:
Der Bootsektor macht nix anderes als einen BIOS-Call auszufuehren, der weitere Sektoren an die Adresse 002C (oder 002E, weiss nicht mehr) zu lesen.
Na etwas mehr laeuft da schon. Der DOS-Bootsektor auf Disketten enthaelt eine primitive unterstuetzung zum lesen des FAT12-Dateisystems. So laedt das Teil die Datei io.sys, die den DOS-Kernel enthaelt, teilweise nach 00700h. Auf Festplatten ist das Teil nochmal um einiges komplizierter.
xyzxyzxyz schrieb:
Anschliessend geh auf die Intel-Webseite und lad dir die PDF-Files fuer die IA-32 Prozessorreihe runter. Da steht dann drin, wie Du z.B. in den Protected Mode schaltest.
Ok... Bringt jemandem, der sich mit Assembler und erst recht dem PM nicht auskennt bestimmt furchtbar viel. Naja, whatever.
xyzxyzxyz schrieb:
Ueber die VGA oder VESA Standard-Schnittstelle (BIOS Calls oder Port-Adressen) kannst Du dann rausfinden, wie Du in den Grafikmodus schaltest, die Aufloesung umschaltest usw.
VGA+Ports geht vielleicht noch, VESA+Ports eher nicht. Und im Protected Mode ist das ja auch noch so eine Sache...
xyzxyzxyz schrieb:
Ich kann Dir gleich sagen: Es ist eine ziemliche Sysiphus-Arbeit. Moeglicherweise musst Du auch noch Treiber fuer verschiedene Grafik- und Soundkarten programmieren.
Die Grafikkarte bringt normalerweise ihre Treiber in ihrem BIOS mit (VGA/VESA), fuer Soundkarten wird aber sicher ein Treiber benoetigt.
xyzxyzxyz schrieb:
Es hat schon einen Grund, warum es solche Boot-Spiele fuer den PC nicht gibt ...
Ob es Bootspiele fuer PC gab oder nicht, weiss ich nicht (hab' nur 2Diskettengames uebrig... :D), auf jeden Fall gab es Diskettengames fuer DOS. Da brauchst du dann zwar keine Unterstuetzung fuer ein Dateisystem mehr basteln, ansonsten musst du aber immernoch fuer alles deine Treiber schreiben. Von daher waeren Spiele auf bootbaren Disketten fuer PC gar nicht so unwahrscheinlich gewesen. Die Hardware in aktuellen PC ist zwar um einiges komplizierter, im Grunde genommen aber zumeist noch irgendwie zu alter Hardware aus DOS-Zeiten kompatibel (zB. SBPro-kompatibilitaet bei AC97-Soundkarten).
xyzxyzxyz schrieb:
Auf dem PC ist der Aufwand tausendmal hoeher, da ja die Hardware nicht so genau vorhersagbar ist. Wenn Du das Spiel nur fuer eine Hardwarekonfiguration schreiben willst (dann darfst Du aber auch nicht mehr die Karten im Rechner umstecken!!
Naja... Einige Standardschnittstellen gibt es da ja zum Glueck auch heute noch Grafik/FDD/KeyBoard/Mouse(PS/2,COM - bei USB wird es IMHO uU. schwierig)/usw. lassen sich bisher auch noch auf jedem PC im Grunde genommen gleich ansprechen. Nur beim Sound koennte es Probleme geben, wenn die PCI-Hardware nicht SoundBlaster-kompatibel ist.
Da gibt es uebrigens auch Schnittstellen, ueber die sich die Konfiguration der PCI-Hardware sehr einfach auslesen laesst. Das jonglieren mit den Karten sollte also kein Problem machen. Das kommt erst, wenn Karten herausgenommen und durch andere Hardware ersetzt werden.Das war's eigentlich auch schon.
-
Danke!!
Wie ist es eigentlich mit den Timer-Bausteinen? Welche Maximalaufloesung kann man da erwarten? Gibt es einen Trick, Interrupts im Mikrosekundenbereich zu erzeugen?
Ich hab auch ab und zu Anfaelle, ein OS schreiben zu wollen, weil mir kein existierendes so richtig gefaellt.
Gibt's denn irgendein Projekt, das an einem Super-High-Speed-Betriebssystem fuer PC's arbeitet?
Ich bin's leid, dass auf diesen tollen Maschinen soviel Rechenzeit verschwendet wird.
Wieso kommen weder Linux noch Windows bei ihren Zeitscheiben nicht unter die 1-ms- Schwelle?
-
Ich hab grad in der PIT-Beschreibung gelesen, dass der alte PC-Timer schon eine Aufloesung ueber 1 MHz hatte, also sollte das mit den Interrupts im Mikrosekundenbereich eigentlich kein Problem sein, oder? Ich brauche nur den Timer mit dem Wert 1 zu laden, richtig? Oder ist das zu kurz?
Und, muss man bei einem Betriebssystem den BIOS-Interrupt-Handler ausfuehren?
-
Ich bin's leid, dass auf diesen tollen Maschinen soviel Rechenzeit verschwendet wird.
Je öfter du den Timer-Interrupt aufrufst, umso mehr Zeit wird verschwendet. Also widersprichst du dir irgendwie.
Und, muss man bei einem Betriebssystem den BIOS-Interrupt-Handler ausfuehren?
Was soll "der BIOS-Interrupt-Handler" sein?
-
Ringding schrieb:
Je öfter du den Timer-Interrupt aufrufst, umso mehr Zeit wird verschwendet. Also widersprichst du dir irgendwie.
Ach so, ja, ich meinte eher die Task-Switching-Zeitscheiben, je weniger ein Thread drankommt, um so langsamer scheint er zu laufen.
Den Effekt kann man sehr schoen beobachten, wenn man ein Uniprozessorsystem mit einem Multiprozessorsystem (oder eins mit Hyperthreading) vergleicht.
Ein fluessiges Multitasking ist manchmal Gold wert ...
Ringding schrieb:
Was soll "der BIOS-Interrupt-Handler" sein?Der Timer-Interrupt-Handler im BIOS, der in der PIT-Beschreibung erwaehnt wird, die ich gelesen habe.
Sorry falls ich mich unklar ausgedrueckt habe. Vielleicht liegt's daran, dass ich so doof bin ...
-
xyzxyzxyz schrieb:
Und, muss man bei einem Betriebssystem den BIOS-Interrupt-Handler ausfuehren?
Nein.
-
http://www.linuxgazette.com/issue77/krishnakumar.html
http://www.linuxgazette.com/issue79/krishnakumar.html
http://www.linuxgazette.com/issue82/raghu.html
-
Stark!! Danke!
-
kurz!