pokecomp - Building Tool

    • [Allgemeine Tools]

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • pokecomp - Building Tool

      pokecomp - Building Tool


      » Was?

      Dieses Tool soll einem die Kompilierung von C Code für den GBA erleichtern. Der Name ist zwar etwas misleading, mir ist aber auf die Schnelle nichts Besseres eingefallen. Es vereinfacht den Prozess des Kompilierens aller C files, des Linkens der Outputfiles sowie anschließend des Generierens des Maschinencodes und Schreiben von dessen in das ROM. Das Tool ist mithilfe des Qt C++ Frameworks geschrieben, mit dem man plattformübergreifende Userinterfaces erstellen kann.

      » Warum?

      Es gibt viele Python-Scripts im Netz, die versuchen, diesen Prozess zu automatisieren. Was sie aber alle nicht können, ist das dynamische und einfache Generieren eines Files, das dafür verantwortlich ist, den Code auf ein bestimmtes Offset im ROM auszulagern (Beispiel: Du hast im Code einen Pointer zu einer Struktur im Code selbst. Relativ geht hier nicht, also muss das Offset, bei dem der Code startet, genau definiert sein). Außerdem werden die Source-files rekursiv und relativ zu dem geöffneten Ordner gesucht und kompiliert, bei den Scripts musste man sonst immer eine Target-Datei erstellen. Kurzum: Irgendwann wird es unübersichtlich! Dieses Tool soll Abhilfe schaffen.

      Eines hatte ich noch vergessen zu erwähnen: Keiner der zurzeit existierenden Scripts kann wirklich genau kontrollieren, welche Funktion am Anfang des generierten Binaryblob steht, auch wenn sie "main" heißt! Aber das Tool hat auch hier ein Ass im Ärmel: Man kann eine Funktion (per Namen) auf den Anfang des Kompilats setzen und sie somit sofort per Script aufrufen, ohne sie zuerst suchen zu müssen.

      » Features

      • Einfache Kompilierung von C files in einem Ordner und seinen Sub-Ordnern
      • Automatisches Linken, Korrigieren der Offsets und Zuweisen der Funktionsoffsets
      • Direktes Einfügen ins ROM; bricht ab, falls nicht genug Freespace vorhanden ist
      • Zuweisen einer Startfunktion, die relativ zum Blob Offset 0x0 hat


      » Prärequisiten

      Ihr müsst euch das devkitPro herunterladen und installieren und den Pfad {devkitPro}/devkitARM/bin zu den Umgebungsvariablen hinzufügen. Den Downloadlink dazu wird es im Tool selbst geben.

      » Pokelib

      Später wird es, passend zu diesem Tool, eine Library geben, die euch die Arbeit mit Pokémon ROMs ansich extrem vereinfacht. Es wird Funktionen geben, die euch in einer Codezeile ein Objekt, einen Hintergrund, eine Palette, oder sonst etwas laden. Hintergründe können einfach gescrollt werden, Objekte in verschiedenen Arten modifiziert und Strings sowie Textboxen ausgegeben werden. Es wird später noch einen eigenen Thread zu "pokelib" mit all den Features geben.

      » Screenshot



      » Downloads

      Vorerst gibt es noch keinen Download. Das Tool ist zwar schon fertig, allerdings muss ich es noch auf Bugs überprüfen und der Schreibevorgang für das ROM muss auch noch fertiggestellt werden. Es wird aber in Bälde (für Windows und Linux) released werden!


      ~Laz0r

    • Ich will dir ja deinen Erfolg nicht kaputt machen, oder das irgendeiner Weise diffamieren, aber es gibt Bereits armips , welches genau das sehr zuverlässig und sinnvoll unterstützt. Einfach in Kombination mit der Toolchain in ein Makefile, und man kann neben C und ASM-Code auch Musik und Grafiken (über GRIT aus devkitpro) "kinderleicht" ins ROM integrieren.


      Aber auf jeden Fall ne coole Idee, sowas hatte ich mir auch schonmal überlegt und dann Armips (dank Sturmvogel) gefunden.
      Wo war Gondor, als meine Klausurenphase begann?
    • Wie Wodka schon sagte, gibt es dafür bereits Lösungen, auch wenn diese im Allgemeinen Fall vllt. etwas komplizierter aussehen. Man hat halt leider, sobald man Tools verwendet, die einem den Build Prozess abnehmen (Und nicht auf make basieren) einen Verlust von Kontrolle. Mit einem makefile kann man entsprechend auch spezifizieren wie data Elemente, also z.b. Bilder, Musik und Text, behandelt werden sollen.

      Für Anfänger ist das sicher nicht schlecht, aber man muss sich halt bewusst sein, was man dadurch verliert. Auch ein bisschen störend, dass man keine Compilerflags angeben kann, und man so z.b. keinen Zugriff auf Debug Information [gcc -g] oder Optimierung [gcc -OX] hat, das solltest du den User, zumindest optional, entscheiden lassen, mein Code braucht z.b. unbedingt die -g Flag und auch ein paar Flags, damit der Code richtig kompiliert.

      Warum muss man eigentlich einen Entrypoint angeben können? Der bleibt in einem ROM im Regelfall doch ohnehin 0x08000000.

      ~Sturmvogel
      Wandering on Horizon Road
    • Danke für die Anregungen!


      Sturmvogel schrieb:

      Warum muss man eigentlich einen Entrypoint angeben können? Der bleibt in einem ROM im Regelfall doch ohnehin 0x08000000.
      Darum geht es nicht. Es geht darum, dass sich eine Funktion in der Binary an der Position 0x0 befindet. Wenn du beispielsweise gegen libgcc linkst, weil du spezielle arithmetische Funktionen benötigst, wird die Initialisierung für libgcc vor allen anderen Funktionen und Daten geschrieben. Um das zu umgehen, muss man die Funktion nach vorne setzen. Anderes Szenario: Du hast zwei Funktionen, eine heißt "minispielMain" und die andere "miniSpielTask". Woher soll der Linker wissen, welche von den zwei Funktionen sich nun genau am Insertierungsoffset von 0x08XXYYZZ befinden soll? Wenn du im Tool die Funktion "minispielMain" als Startfunktion definierst, kannst du sicherstellen, dass sie sich genau am offset 0xXXYYZZ befindet und du sie in einem Script beispielsweise via "callasm 0xXXYYZZ+1" direkt aufrufen kannst, ohne dich im eigentlichen Bytechaos zu verirren.

      Für das Tool hatte ich noch Integration mit GRIT geplant und sogar einen eigenen Preprocessor für Pokémon-Text. Der codiert dann 'const char *text = "Hallo!"' zum GF-Äquivalent 'const unsigned char *text = { ... }'. Das kann besonders nützlich sein, wenn du große Strukturen inline-initialisierst. Das brauche ich persönlich für meinen PokéGear, den ich gerade code.

      Das mit den Bearbeitungsmöglichkeiten bzgl. Flags und anderen Dingen nehme ich mir mal zu Herzen :-).

      ~Laz0r
    • Nun gut, wenn man davon ausgeht ein statisches Offset haben zu wollen braucht man das natürlich, allerdings kann man das umgehen und sich ggf. callasm commands in ein special auslegen oder Scripts über den Makro Preprozessor auflösen, was mmn. ein Vorteil gegenüber deiner Implementierung ist, weil man nicht an statische Offsets gebunden ist. Hat natürlich den "Nachteil", allgemein nicht mehr vorhersehen zu können wo der Code steht, wenn man nicht irgendwelche Section Hacks verwendet, allerdings wüsste ich auch keine Anwendung dafür.
      Strings würde ich wenn dann extern auflösen, z.b. aus einer txt Datei mit einer eigenen Syntax, allerdings nicht über den Präprozessor, da man sonst kein ASCII Encoding mehr verwenden kann, was man ja durchaus wollen kann.

      Wenn wir schon bei einem dev Prozess sind, noch ein kleiner Vorschlag von mir, der auch von armips unterstützt wird, keine Ahnung ob du sowas auch schon geplant hast: Code direkt an ein statisches Offset im ROM schreiben, i.e. "Hooks legen" zu dem Code, den man kompilieren lässt. Das muss sonst nat. per Hand getan werden, was ggf. sehr nervig ist, wenn man mehr Code hat und nur ein Offset statisch setzen kann.

      ~Sturmvogel
      Wandering on Horizon Road