5.3.1 Dokumentation und Arbeitsentwicklung
Die 8 bit Game Abstraction layer oder 8GAL, ist eine vereinfachte Programmiersprache die wir entwickelt haben um das Programmieren verschiedene Spiele zu erleichtern. Bestimmte abstrakte konzepte, wie ein Board oder Objekte die sich im Raum je nach Input bewegen. Leider wegen des großen Aufwands, der mit die Implementation von 8GAL verbunden ist, ist es uns nicht gelungen, die Sprache zul¨assig zu benutzen. Jedoch, weil 8GAL zu den anderen Teilen der Konsole komplement¨ar ist, in dem sie die h¨ochste Abstraktionsniveau zu dem gesamten Aufbau der Konsole anbietet, ist sie immer noch von Bedeutung zu diesem Projekt.
8GAL basiert sich auf dem Syntax von VHDL, weil dies compiler-freundlich ist, obwohl sie l¨angere Syntax ben¨otigt als andere hohen Programmiersprachen wie Python. Damit k¨onnten wir den Com-piler ohne großen Aufwand implementieren. 8GAL beschreibt ein Spiel in dem es die Objekte die auf dem Bildschirm vorkommen beschreibt, und angibt wie sie sich auf bestimmten Ereignissen reagieren sollte. Die ereignisse sind z. B. wenn ein Timer abgelaufen ist, wenn eine Taste gedr¨uckt wird, oder wenn ein Objekt ein Anderes st¨oßt. Die Reaktion k¨onnte dann eine Bewegung oder eine r¨aumliche ¨Anderung von dem betroffenen Objekt. Ein 8GAL Datei ist in 3 Teile unterteilt.
In dem ersten Teil, werden die Objekte benannt und ihre Attribute beschrieben. Diese Attribute sind primitive Typen (int, char usw.) Danach werden alle m¨ogliche Zust¨ande der Objekten r¨aumlich beschrieben, also wie ein Objekt im Raum aussehen kann. Danach beschreibt der Programmierer die Funktionalit¨at jeder Objekttyp, also wie das Objekt sich auf ereignisse reagiert. Nachdem wird die Initialisierung des Spiels beschrieben. Ein Instanz beschreibt einen Objekttyp, ein Instanzname, Timerl¨ange, und wo auf dem Board das Objekt sich zum Anfang befinden sollte. Somit kann ein Spiel dann realisiert werden. Diese 8GAL code wird dann mit einem Compiler, den wir mit Java geschrieben haben in C-Code ¨ubersetzt. Diese C-Code inkludiert allgemeine Funktionen in einem anderen Datei die in den meisten F¨allen f¨ur ein Spiel ben¨otigt wird (z. B eine Funktion die bestimmt wann ein Stoß zwischen zwei Objekte aufgetreten ist.) Diese C-Datei enth¨alt eine Funktion mit dem Namen von dem Spiel, und kann danach in der Men¨u-C-Datei inkludiert werden, damit das Spiel aus dem Men¨u aufgerufen werden kann.
Etay Yacov
Die 8GAL konnte noch nicht fertig gef¨uhrt werden. Da ein live-Debugging auf dem LED oder GLCD unbehebbare Fehlern gezeigt hat. Es wurden zus¨atzlich 3 Spiele unabh¨angig von der 8GAL entworfen, (Pong, Spacewar und car race ) die als Absicherung dienen, f¨ur den Fall, dass die 8GAL zur Abschlusspr¨asentation noch nicht fertig ist.
F¨ur die Spiele programmieren unabh¨angig von der 8GAL werden vielen hilfreichen Methoden
Schritt-weise implementiert. Dies hat uns erm¨oglicht die Spiele besser zu entwerfen und unseren Code daraufhin auf dem GLCD anzuzeigen, sodass die Spiele im sp¨ateren Ablauf mittels SPI auf dem LED Dot Matrix angezeigt werden kann.
Spieleentwicklungsprinzip:
Hierf¨ur wird das Objektorientiertes Programmierung zum Einsatz aufgerufen, da das Spielfeld als eine Matrix betrachtet werden muss und die Zust¨ande zeitlich ver¨anderlich sind.
Aller erstes wurde die Matrix [i][j] definiert und den Wert 0 zugewiesen f¨ur jede Elemente i, j zwischen 0 und 64, so wird das Spiel Feld leer initialisiert. Dies erfolgt ¨uber die Methode Screen Inizialing().
Der n¨achste Schritt besteht daran die Objekte des Spiels bzw. deren Farbe und Vertikal – horizontal Size zu definieren und die im Matrix zu speichern mithilfe der Methode Write obstacle/car(). Das Verfahren unterscheidet sich zwischen GLCD und LED DOT Matrix nur in einem einzige Einzelheit, und zwar die Farbe da die GLCD nur zwei Farben anzeigen kann. F¨ur Weiß 0 und f¨ur Schwarz 1. Im Vergleich dazu wird die LED DOT Matrix bis zur 8 Farben anzeigen k¨onnen je nach Wunsch der Benutzer. Jeder Farbe kann Name mittels ihr Name aufgerufene wird, diese ist ein Zustand einer sukzessiven bin¨are Reihenfolge von 000 bis 111 die bereits im LED implementiert sind.
Abschließend wird die wichtige Methode zur Bewegung der Objekte betrachtet. Diese ist basiert auf zwei entscheidenden Kriterien ; die Benutzer Eingabe und die Erf¨ullung Bedingungen. Um die Benutzer Eingabe von Analog in die Digital umzuwandeln, wird eine Test Pin () Funktion imple-mentiert, die, falls eine Bet¨atigung der Knopf eine boolean Wert true zur¨uckgibt. Die Bewegung Bedingungen l¨asst sich vom Benutzer zur anderer unterscheiden je nach Spiel und Ziel. Dies muss nun in einem UND Logik Beziehung mit dem entsprechenden Pin legen. Wenn beide Kriterien erf¨ullt sind, kann sich die Matrix mit Hilfe ihre Anfangsoffset in X und Y-Richtung bewegen.
Einen Letzten wichtigen Aspekt, der Spiel Programmierung ist, wenn das Spiel zur Ende kommen muss, die sogenannte GAME OVER Funktion. Die Spiel Ende Bedingungen unterscheiden sich hier auch vom Benutzer zur einander aber das Ziel ist das selber. Die Spiel wird unterbrochen, in dem man die gesamte Matrix den Wert 0 zuweist und die Spiel Ende Anzeige in einer unendliche While Schleife implementiert.
Khaled Mejri
5.3.2 Zustandsdiagramm
Abbildung 7: Zustandsdiagramm: Softwareabstraktion [19]
5.3.3 Schaltplan
Abbildung 8: Schaltplan CPU [20]
5.3.4 Layout
Abbildung 9: CPU Layout [20]
5.3.5 Platine
Abbildung 10: CPU:Central processing unit Platine
• L¨ange: 160mm
• Breite: 98mm
Khaled Mejri
5.3.6 Zusammenfassung
Die Software-Gruppe besch¨aftigt sich mit Abstraktion der Spielprogrammierung und die Implemen-tation der Spiele auf Software Ebene. Außerdem k¨ummert sich diese Untergruppe um den Versand der Daten ¨uber SPI an die n¨achste Ebene. Wegen des Zeitmangels ist es uns nicht gelungen einen funktionierenden Compilor f¨ur 8GAL fehlerfrei zu produzieren. Um uns vor diesem m¨oglichem Sze-nario zu sch¨utzen, hat unsere Untergruppe als Ersatzplan, unabh¨angig von der 8GAL-Logik in einer nicht abstrakte Art und Weise 3 Spiele implementiert. Diese haben wir angewendet, damit das Projekt weiterlaufen kann. Die andere Aufgaben von unseren Gruppe, n¨amlich die Komunikation zwischen Master und Slave, haben wir implementiert.
Etay Yacov