spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich persönlich würde ja statt dem ganzen Mikro-Controller-Kram lieber ein Programm unter dem OS schreiben, unter dem ich sonst auch arbeite. Sprich halt ein ganz normales Windows oder Linux-Programm. MASM und NASM sind super Assembler. Ich habe schon diverse Windows-Programme in Assembler mit MASM geschrieben. Unter DOS war das alles natürlich noch etwas freier als heute. Es gibt ja auch noch DOS-Box, da kann man noch etwas freier mit dem Speicher rumspielen und auch die direkten Grafik-Speicher-Zugriffe haben was sehr spaßiges an sich.

Zitat von »BlueCobold«

Ich persönlich würde ja statt dem ganzen Mikro-Controller-Kram lieber ein Programm unter dem OS schreiben, unter dem ich sonst auch arbeite. Sprich halt ein ganz normales Windows oder Linux-Programm. MASM und NASM sind super Assembler. Ich habe schon diverse Windows-Programme in Assembler mit MASM geschrieben. Unter DOS war das alles natürlich noch etwas freier als heute. Es gibt ja auch noch DOS-Box, da kann man noch etwas freier mit dem Speicher rumspielen und auch die direkten Grafik-Speicher-Zugriffe haben was sehr spaßiges an sich.

Der Vorteil ist, dass son Mikrocontroller halt auch mal im wahrsten Sinne des Wortes was zum "Anfassen" ist. Macht das sonst recht trockene Assembler halt gleich viel zugänglicher, in meinen Augen.

Naja, es gibt halt auch einige zusätzliche Hürden.
Je nach Typ des Mikrocontrollers sinf Programmer und Debugger teilweise recht kostenspielig. Am PC braucht man gar nichts zusätzlich. Trotzdem ist Debugging bei µCs meiner persönlichen Erfahrung nach häufig sehr aufwendig und weniger zuverlässig. Außerdem kann es immer an der aufgebauten Hardware liegen, das es nicht funktioniert. Die Dokumentation des µC und der Anzeige ist auch nicht ohne und eine Aufgabe für sich. Die Kommunikation ist zwar nicht wahnsinnig schwierig aber auch nicht total gerade einfach und benötigt Wissen aus dem Bereich der Elektronik. Ich fand damals das ganz hilfreich.

Zitat von »Timmyew«

Hallo alle zusammen

Ich wollte mal fragen wie man es auf die reihe bekommt die so zu sagen "Maschinensprache" Assembler zu lernen , ich weiss es gibt verschiedene arten von Assembler sprachen da nicht jeder Prozesor gleich aufgebaut ist aber wie und mit welchen mitteln kann ich Assembler lernen und herausfinden welche art von Assembler meinem Computer entspricht . Und meine grösste frage ist , wie funktioniert das wenn ich "ich nenne es mal so" Assembler programm "ich weiss jedes programm ist auf Maschinensprache übersetzt " zum laufen bekomme und unter windows starte ?

Und wenn etwas nicht Richtig sein sollte da ich schon gar keine Ahnung im bereich Assembler habe sagt es einfach ...

Assembler kann man lernen. Sogar relativ schnell wenn man die Grundlagen versteht. Ich habe vor kurzen den Versuch gestartet, eine eigene kleine Programmiersprache zu schreiben, die in Assembler kompiliert wird: [Alpha] Eine kleine Programmiersprache
Dabei benutze ich GNU Assembler, was IMO noch am "schönsten" zu schreiben ist. Jedes meiner Beispiele liegt einmal in Roh Form (also in Form meiner eigenen Sprache) vor, deren Syntax eig. unmissverständlich sein sollte, sowie jeweils einmal in kompilierten Assembler (Input/Output Ordner).

Man könnte den Code auch direkt vom Bios ausführen lassen.

1. einfach eine x86 ASM reference holen
   
2. mit einem Text Editor den Code schreiben
   
3. mit einem Tool denn Code in nullen und einsen übersätzen
   
4. einen Bootsector runterladen
   
5. zuerst den Bootsektor und dann denn code mit TotalCommand auf USB Stick bumpen(zumindestens geht das mit Diskette) und vom usb Stick booten
   

aber dafür wäre es nicht schlecht einen 2. PC zu haben, sonnst miss man immer solange warten bis der Rechner neustartet

Zitat von »@zimmer«

aber dafür wäre es nicht schlecht einen 2. PC zu haben, sonnst miss man immer solange warten bis der Rechner neustartet

Da tun es eigentlich auch VMs

Oder eben DOS-Box.

Wobei DOS inzwischen ein bisschen arg Alt ist.
Das müsste dann ja noch 16 Bit gewesen sein. Ich würde mich wenn dann eher mit was halbwegs Modernen beschäftigen.
Ich glaube nicht, dass man noch ernsthaft auf 16 Bit Anwendungen stoßen wird und DOSs gibt es auch praktisch nicht mehr.

DOS gibt es genauso auch in 32 Bit. Das dürfte wohl eh die gebräuchlichste Version sein, denn mit 80286er CPUs hat man auch zu DOS-Zeiten nicht lange gearbeitet. Aber darum geht es gar nicht. Es geht darum, dass man unter DOS mit Assembler eben viel mehr Freiheiten hatte, als man unter Windows und Linux hat. Speicher-Zugriffe, Segmentierung, Hardware, Interrupts, Grafik-Speicher. Das ist unter heutigen System ziemlich weit eingeschränkt. Ich sehe da kein Problem genau diese Sachen mal in DOS-Box zu machen. Man muss dabei ja nicht unbedingt DOS-Routinen verwenden. Die waren eh grauenvoll langsam.
Er darf sich natürlich auch hinsetzen und versuchen die x64-CPU-Befehle zu verstehen und sich wundern, warum er auf gewisse Dinge eben keinen Zugriff hat. Spaß macht das aber deutlich weniger als mal die Tastatur selbst abzufragen, den System-Timer für eigene Dinge zu verwenden und Grafik-Effekte direkt im VGA-Ram zu erzeugen.

Also MSDOS(Das ist ja wohl auch in der DosBox) ist soweit ich weiß ein reines 16 Bit System. Es gibt zwar wohl irgendwelche Verbiegungen um in den Protected Mode zu kommen, aber eigentlich nicht.

Prinzipiell bin ich auch der Meinung mit dem Speicherschutz und so weiter. Aber wieso sollte man dann auf ein uraltes DOS aufbauen? Da schreibt man doch noch besser gleich ein eigenes solides 32 oder inzwischen besser 64 Bit System. Dann hat man ALLE Möglichkeiten, Speicherschutz(In der Regel Paging ohne wirkliche Segmentierung) genau so weit wie man es selbst implementiert und die Erfahrungen die man damit macht, sind wenigstens heute noch relevant und nicht aus dem letzten Jahrtausend. Man nehme einen Emulator wie Bochs oder Qemu und schon geht es los. Direkt auf Hardwarelevel aber ohne alten DOS Zeug. Dann kann man nach Herzenslust alle Hardware direkt ansprechen. Das eigene OS wird zwar sicher nie Windows oder die diversen Unixe ablösen, aber es ist Zeitgemäß.