Für den Wiz gibt es nun die ersten quasi-komemrziellen Spiele auf sogenannten ND-Karten. Das sind SD-Karten mit einer DRM-Technologie. Um diese ND-Karten auch verwenden zu können, braucht der Wiz ein Firmwareupgrade auf die Firmwareversion 1.2.1 (Stand 14.2.2010)
Da ich mir natürlich für 17€ besagte Spielekarte bestellt habe (7 Spiele für 17€ ist günstig), wollte ich natürlich auch die neue Firmware aufspielen. Leider erwies sich das als nicht so einfach, wie man es gern hätte.
Problem: ich habe noch die originale Firmware drauf gehabt, bei der sich doch einiges getan hat. Von der alten Firmware kann man nicht direkt auf die 1.2.1 updaten, sondern muss erst die 1.1.0 Firmware einspielen.
Aber wie wird das Firmwareupgrade beim GP2X Wiz gemacht?
Vorgehensweise um die Firmware einzuspielen:
Inhalt vom NAND-Speicher des GP2X Wiz erstmal sichern
Die Firmware auf die SD-Karte entpacken. Sonst sollte nichts auf der SD-Karte sein.
R-Taste am Wiz gedrückt halten und mit der eingelegten SD-Karte den Wiz booten
Der Wiz sollte nun einen Screen “Firmware Upgrade…” zeigen und dann arbeiten
Den Wiz für ca. 15 Minuten laufen lassen, eine rote Fortschrittsanzeige zeigt alles an.
Wenn alles glatt lief, gibt es einen “Please reboot” Screen
Ausprobieren, ob alles geht und ob die Version stimmt (Settings -> Information im Wiz Menu)
Ich musste diesen Ablauf wie gesagt erst für die 1.1.0 Firmware durchführen und anschließend noch einmal für die 1.2.1 Firmware, aber danach lief es. Leider ist in der 1.2.1 immer noch nicht die aktualisierte Version der libSDL dabei, aber immerhin läuft ansonsten alles, was ich bisher ausprobiert habe. Hoffentlich dann auch besagte ND-Karte, auf die ich recht gespannt bin.
Beim Firmwareupgrade für meinen Wiz gab es durchaus Probleme mit der SD-Karte. Manchmal hilft es, wenn die SD-Karte standardgemäß initialisiert wird, und nicht mit einem Formatierungstool vom Betriebssystem malträtiert wird.
Für diesen Zweck kann man auf der Webseite des technischen SD Kartenstandards ein kleines Programm herunterladen und damit die SD Karten dann formatieren.
Ende November, Anfang Dezember habe ich AHCC entdeckt. AHCC steht für “A Home Cooked C Compiler” und ist ein frei verfügbarer ANSI C Compiler für Atari ST und Nachfolger. Der Compiler stellt eine unter Mint und MagiC multitaskingfähige Programmierumgebung zur Verfügung. Das Paket kommt komplett mit GEM-Shell, Make in TTP-Form, einer guten Dokumentation und mit allen nötigen Libraries.
AHCC (Atari ST Version)
Es gibt von AHCC zwei Versionen. Die normale Version benötigt eine 68020 oder bessere CPU, während es auch eine Atari ST Version für 68000 gibt. Letztere hat dann allerdings keinen Support für Floating Point Arithmetik, aber die brauche ich zumindest nicht.
Einmal erzeugte Objectfiles oder Biblitoheken bleiben dabei nach Aussage des AHCC Betreuers kompatibel. D.h. man kann mit der ST Version eine Bibliothek erzeugen und diese dann auf dem Falcon mit der 020 Version verwenden und dazu linken.
Der Compiler überzeugt mich vor allem mit den folgenden Punkten:
frei zu haben (Der Source des Compilers ist vorhanden und einsehbar)
ANSI C Unterstützung (freie C Compiler auf dem ST gibts afaik bis dato nur mir K&R C)
eingebauter Editor mit Syntaxhighlighting
TTP für Make und Compilieren funktioniert auch tatsächlich (hab ich mit Pure C nie hinbekommen)
Pure C kompatibel (bzgl. Objectfiles habe ich das noch nicht ausprobiert)
Objectfiles aus Assemblercode sind leicht zu integrieren
komplette TOSLib inklusive Calls für Mint
Floating Point Support ist optional
läuft vermutlich auf allen Ataris mit 2-3MB Speicher
Support über den Autor Henk Robbers ist super
Ein paar Schwachstellen hat AHCC allerdings auch:
kein Debugger dabei
Aufruf von einem Debugger oder dem Kompilat aus der GEM-Shell heraus ist nicht möglich (TOS Nutzer müssen also die Shell beenden und vom Desktop starten)
Die Codequalität des erzeugten Maschinencodes kommt an Pure C nicht heran.
Insgesamt bedeutet das für mich, ich werde für die Programmierung auf dem Atari ST vermutlich zu C wechseln.
Vorhin wollte ich die aktuelle Version von WordPress einspielen. Leider funktionierte es dann nicht. Die MySQL-Version auf dem Server meines Providers ist scheinbar ein paar Zehntelversionsstellen zu alt.
Erstmal galt für mich “PANIK!”, als ich den Hinweis sah, ihre SQL Version wird nicht unterstützt. Ich machte sofort den Downgrade auf die vorige Version. Zum Glück hatte ich den Tarball noch nicht gelöscht und jetzt scheint alles wieder zu funktionieren. Aber ganz glücklich bin ich darüber nicht.
Ich muss mal bei meinem Hoster nachfragen, ob und wann ein Upgrade von MySQL möglich wäre. So läuft mein Blog zwangsläufig ohne die gewissen Fixes.
Meine Displaypatches sind jetzt endlich soweit. Ich habe heute mein Spiel Quadromania zum ersten Mal auf dem GP2X Wiz zum Laufen gebracht. Es ist noch einiges nicht ganz 100%, insbesondere die Anzeige der Spielanleitung, aber das Problem liegt nicht am Wiz. Es funktionieren auch noch keine Tasten, nur der Touchscreen. Aber man kann das Spiel schonmal spielen.
Quadromania auf dem GP2X Wiz
Irgendwann die Woche gibt es dann noch einen Release dazu. Ansonsten sieht die Roadmap noch eine Highscoretabelle und Sound und Musik vor. Mal sehen wie weit es mein erster Homebrew für den Wiz noch bringen wird!
Ich schätze, illegales Material wid auch dort verboten sein, aber das ist ja nicht das Problem. Andere größere Sammlungen, z.B. PD Disketten und dgl., kann man da bestimmt problemlos ablegen.
Es läuft einfach über HTTP und kostet nichts, das nenn ich Vorteile. Ausserdem ist die Seite optisch nicht überladen, kein Flashbanner, kein bunter Jokus, nur ein funktionales Interface.
Vorhin habe ich an meinem Spieleprojekt für PC und GP2x Wiz, Quadromania, weiter gearbeitet. Nach und nach bereite ich gerade die Grafikroutinen darauf vor, flexibel zu blitten, in Abhängigkeit der geladenen Grafikressourcen.
Quadromania (Version vom 19.1.2010)
Der Plan besteht darin, das Spiel auflösungsunabhängig zu machen. Auf der Zielplattform müssen dann nur zur jeweiligen Displaygröße passende Grafikdateien bereitgestellt werden. Z.B. Grafiken für 320×240 für den Wiz, aber 640×480 auf dem PC.
Der Anfang dazu ist gelegt, aber ich bin noch lange nicht fertig. Sobald die auflösungsunabhängige Version steht, wird es eine neue Releaseversion geben. In der Spiellogik ist akut leider auch noch ein dicker Bug, der beim Umbau auf Konstanten reingekommen sein muss. Den muss ich auch noch tilgen.
Wenn alles glatt läuft, gibt es im Februar eine erste Testversion auch für den GP2X Wiz. Dort wird man das Spiel dann auf dem Touchscreen mit dem Griffel spielen können.
Ich habe am Sonntag begonnen, mein altes Spielprojekt Quadromania wiederzubeleben. Mittelfristiges Ziel ist es, eine Version für den GP2X Wiz bauen zu können.
Im Moment konzentriert sich die Arbeit auf die Modernisierung des alten Sourcecodes. Ich benutze dabei zur Zeit Eclipse mit dem C Plugin. Ausserdem habe ich mir lokal ein kleines Subversionrepository eingerichtet. Das Ziel dabei ist, halbwegs professionell zu entwickeln. Man lernt schließlich dazu.
Subclipse läuft recht ordentlich und eine IDE hat echte Vorteile. Beispielsweise hatte ich einen komischen Fehler wegen fehlender Funktionsprototypen in meinem Code. Eclipse zeigte mir im Header die falsche Kapselung des Includewächters an. In einem regulären Editor hätte ich danach vermutlich länger gesucht.
Eine Sache werde ich gegenüber der alten v0.2 allerdings rauswerfen: autoconf und automake. Das Projekt ist so schön klein und übersichtlich, so daß ich den Aufwand nich trechtfertigen kann. Zumal ich wenig Erfahrung mit diesen Tools habe. Damals habe ich das Framework mit der Anjuta IDE generiert, aber so 100% glücklich war ich schon damals nicht. Die neue Version wird jedenfalls klassisch aus Makefile und Configheader bestehen.
Im Sommer habe ich mal testweise Google Desktop installiert, eine Desktopsuchmaschine.
Im Prinzip stellt es eine erweiterte Suchfunktion für den eigenen Rechner bereit, eine sogenannte Desktopsuche. Im Hintergrund werden laufend die vorhandenen Dateien indiziert und katalogisiert. Über ein entsprechendes Utility kann man dann im eigenen Datenbestand suchen. Das ist zum Beispiel sinnvoll, wenn man gerade mal wieder vergessen hat, in welchem Verzeichnis man welche Information gelassen hat. Indiziert werden alle sinnvollen Dateiformate, über OpenOffice und Textdateien bis hin zu PDF wird alles sinnvolle durchsucht. Auch lokal abgelegte Emailarchive, z.B. MBOX Dateien von Evolution und co werden erfasst.
Google Desktop im Einsatz
Ich habe die Linuxversion für AMD64 ausprobiert, unter Windows hat das Programm vermutlich noch sehr viel mehr Features als die im folgenden beschriebenen Punkte.
Das DEB File lies sich auch unter meiner etwas veralteten Ubuntu Linux LTS 6.06 Installation verwenden. Nach der Installation hatte ich im KDE Startmenü einen neuen Eintrag, Google Desktop. Nach dem Start hat man ein Icon im Tasktray, vermutlich analog unter GNOME, ich benutze jedenfalls KDE.
Google Desktop im KDE Icontray
Der Indexmechanismus wird automatisch gestartet und ist erstaunlich freundlich mit der CPU Last. Während ich früher mal Beagle ausprobiert hatte, war damit 3D Spielen, z.B. Nexuiz, nicht möglich. Beagle frass im Hintergrund CPU Zeit weg. Google Desktop dagegen scheint das Problem nicht zu haben. Pluspunkt für Google Desktop.
Das Indizieren der Dateien nimmt allerdings Zeit in Anspruch, mehrere Tage um genau zu sein. Es empfiehlt sich daher, erst Google Desktop zu installieren und dann nach und nach Dateien hinzuzufügen oder zu erzeugen. Google Desktop scheint alles was direkt geöffnet wird, mit Priorität zu indizieren. Neueste Dateien sind daher potentiell eher in der Datenbank enthalten. Bis bei mir 2 Gigabyte gesammeletr Daten vol lerfasst waren hat es jedenfalls seine Zeit gedauert.
Durch Drücken von beiden STRG (oder auch Control) Tasten öffnet sich ein kleines Eingabefenster. Hier kann man seine Suchbegriffe eingeben und anschließend kann Google Desktop die Suchergebnisse gesammelt anzeigen. Dazu verwendet es den im System konfigurierten Webbrowser, unter KDE wie bei mir den Konqueror.
Beispielsuchergebnis mit Google Desktop unter KDE
Die Konfiguration von Google Desktop erfolgt ebenfalls im Browserfenster. Scheinbar installiert Google Desktop einen eigenen HTTP Dämon (Webserver), der die Abfragen alle managed.
Ein kleines Fazit
Es funktoniert und erfüllt seinen Zweck –
Binärpaket läuft zumindest hier unter Linux ohne Mucken
Keine unnötige CPU Last
Die Indexdatenbank kann sehr groß werden, z.B. hier akut über 500MB. Das liegt aber an der Menge der indizeirten Dateien.
Einbindung in die Desktopumgebung
Verzeichnisse können gezielt von der Suche ausgenommen
Defaultbrowser nur indirekt konfigurierbar
Ob es eine versteckte Ausspähfunktion gibt, konnte ich bislang nicht feststellen. Zumindest für die Windowsversion will ich eine solche nicht völlig ausschließen. Sensibele Daten sollten man damit nicht unbedingt durchsuchen lassen.
Insgesamt bin ich durchaus zufrieden, jedenfalls mehr als mit dem freien Beagle. Und wenn man über die Jahre (Seit Clausthal) Unmengen Dateien gesammelt hat, ist eine ordentliche Suchfunktion schon viel Wert!
Backup – der professionelle ITler weiss sofort, wie wichtig ein Backup von allen Daten ist. Sind von einem Tag auf den anderen sämtliche Kunden- und Auftragsdaten weg, kann das Geschäft nicht weitergeführt werden. Daher muss sichergestellt werden, daß die Daten jederzeit verfügbar sind und auch wiederhergestellt werden können, wenn sie defekt sind oder eine Datenbank ausfällt.
Aber wie ist das mit dem Backup daheim? Jeder von uns hat mehr oder weniger viele und wichtige Dateien auf seinem heimischen Rechner. Natürlichen wollen wir diese nicht verlieren, insbesondere nicht Sammlungen von Fotos, Musik oder die geliebte Sammlung von Kochrezepten. Auch die Diplom- oder Bachelorarbeit, an der man gerade arbeitet, soll natürlich nicht verloren gehen.
Ich habe selber schon einige Male wichtige Daten verloren, für über 15 Jahren waren es noch einzelne Disketten, die nicht mehr lesbar waren. Später waren es ganze Projekte und gesammelte Dateien. Akut ist Janina vom Problem der Datenrettung betroffen und natürlich möchte auch sie in Zukunft ihre Daten wieder einfach wiederherstellen können.
Ein Backup anlegen macht natürlich Arbeit, und diesen Aufwand möchte man für sich daheim möglichst gering halten. Im Laufe der Jahre habe ich eine einfache, aber wirksame Backupstrategie für daheim entwickelt. Diese möchte ich jetzt hier vorstellen.
Zunächst muss man sich darüber klar sein, welche Daten ins Backup wandern und welche nicht. Pauschal das Homeverzeichnis (Windowsbenutzer können im folgenden „Eigene Dateien“ für diesen Begriff substituieren.) archivieren oder nur Teile davon? Ist die Datenmenge nicht groß, kann man ein einziges Archiv erzeugen. Das geht schnell und effizient. Allerdings hat diese Methode einen Nachteil. Ist das Backup kaputt, d.h. das Archiv defekt, weil z.B. die CD-R verkratzt ist, so ist das ganze Backup wertlos. Spätestens bei 500MB Backup ist das extrem ärgerlich. Aus diesem Grund archiviere ich lieber thematisch sortierte Unterverzeichnisse wie OpenOffice Dokumente, Programmierprojekte, Fotos, Musik und Konfigurationsdateien (Shell, PGP) getrennt.
Der nächste Punkt ist das Backupmedium. Ein dezentrales Backup hat nur Vorteile, denn wenn die eigene Festplatte stirbt, ist es wertlos, nur auf dieser in einem anderen Unterverzeichnis das Backup liegen zu haben. Dumm gelaufen! Das Backup sollte lieber ein oder zweimal auf einem externen Speicher abgelegt werden, der auch nur dem Backupzweck dient und nicht andauernd bewegt wird. Daher ist das externe Datengrab, welches man immer mit zum Kumpel schleppt, nur bedingt geeignet. Eine solche Festplatte ist immer gestresst und entsprechend unsicher in der Datenhaltung. Daher schlage ich vor, eine externe Festplatte nur für Backupzwecke anzulegen. Die Platte wird nur angeschlossen, um ein Backup abzulegen oder abzurufen. Ferner ist es natürlich immer sinnvoll, das Backup auch auf einen Wechseldatenträger abzulegen, z.B. CD-R, DVD oder SD Karte.
Wie oft sollte das Backup denn erfolgen? Je nachdem wie viele Dateien sich ändern, kann das individuell erfolgen. Nicht zu oft, denn dann wird man dem Backup gleich überdrüssig. Zu selten ist schlecht im Fall der Datenwiederherstellung, denn dann fehlt zuviel. Am besten definiert man sich einen periodisch wiederkehrenden Backuptag und hält sich daran, als wäre es ein geschäftlicher Termin.
Als letztes möchte ich noch einen Vorschlag für die Benennung des Backups machen. Man möchte schnell und übersichtlich das Backup wiederfinden. Wenn der Datenträger schon explizit für das Backup gedacht ist, reicht es, das Backup in einem Unterverzeichnis abzulegen, welches mit dem Datum des Backuptages benannt wurde. Wenn mehrere Backups auf einem Datenträger abliegen, sollten es entsprechend mehrere Backupverzeichnisse sein.
Beispielhaftes Backup vom 1.Oktober.2009 auf externer Festplatte
Zusammengefasst sieht die Checkliste für das Backup wie folgt aus:
Zielordner mit aktuellem Datum als Namen anlegen
Individuelles Archivieren der Daten – am besten je Unterverzeichnis als ZIP-Archiv oder dgl. (Linuxer sollten tar nehmen, da so alle Attribute gesichert werden) ablegen
Wer auf Nummer Sicher gehen möchte, macht von jedem Archiv noch eine Prüfdatei, z.B. mit md5sum oder besser eine Dateisignatur mit PGP. Damit kann später die Integrität des Backups verifiziert werden, wenn es wiederhergestellt werden soll.
gefüllten Zielordner auf Backupfestplatte verschieben
ggfs. CD/DVD brennen oder auch auf eine SD-Karte kopieren
Frohes Backup in Zukunft – und wenn irgendwie möglich, kein Datenverlust mehr!
