Die Sourcen meines SNES2DB9 Projektes sind jetzt bei Github zu finden:
https://github.com/simonsunnyboy/SNES2DB9
Category: ANSI C & C99
SNES2DB9 Arduino Prototyp
Seit ein paar Wochen arbeite ich an einem kleinen Mikrocontrollerprojekt.
Zum letzten Summer Games in Atzenhofen hatte ich für Janina vergessen, ein passendes Gamepad zum C64 mitzubringen. Mit einem klassischen Joystick kann sie nicht so recht zocken und bevorzugt Gamepads. Die Sega Pads funktionieren nur wackelig und teilweise und am C64 teils garnicht.
Zunächst wollte ich nur eine neue Leiterplatte entwerfen, mit der man ein USB Joypad auf den DB9 Joystickanschluß von Atari anpassen konnte. Das erschien mir ein wenig zu ambitioniert, also entschied ich mich, einen aktiven Konverter auf mit Arduino als Basis zu entwerfen. Ich entschied mich für die SNES Controller mit Schieberegister, da dies leicht abzufragen ist und die Handhabung der SNES Controller bei meiner Zielgruppe bekannt sind.
Heute habe ich meinen Prototypen dann mal am Atari STE ausprobiert, und ich muss sagen, es läuft. Es fehlen noch ein paar Feinheiten, Autofeuer, Springen mit Feuerknopf statt hoch, aber prinzipiell liest der Arduino den SNES Controller korrekt und mit ca 60Hz aus und bedient die Signalleitungen zum DB9 Joystickport entsprechend. Die Schaltung ist auch ziemlich einfach, mehr oder minder direkt verdrahtet, wobei ich dem Latch und Clock zum SNES Controller noch Pulldown, bzw Pullupwiderstände verpasst habe. Auch lassen sich Arduino und SNES Controller komplett über die 5V vom Joystickport versorgen.
Eine komplette Version mit eigenständigen Controller auf Basis eines ATTiny mit 14 Pin ist in Planung.
Quellcodes und Dokumentation werde ich recht bald bei Github unter MIT Lizenz verfügbar machen.
ASM Software Unittest Framework
(c) 2016 by Matthias Arndt marndt@asmsoftware.de
The MIT License applies to this project. Please refer to the file COPYING for details.
The software is available on GitHub at https://github.com/simonsunnyboy/UnittestFramework
Abstract
This is a small framework to implement unittests for software written in C. There are existing projects that offer much more functionality, this one focuses on simple usability and textual output of statistics.
Main reason to implement this framework was that cunit was too complicated in usage and no other small free frameworks could be found.
System requirements
- Cmake to build the example project
- a C99 compliant C compiler but a C90 one will do if stdint.h and stdbool.h are supplied
- any operating system of your choice
Using the test framework
A test should be a subfunction or the main function of an appropriate test executable.
Use the macros defined in unittest.h and link your project with unittest.c
Wrap the Test with UT_BEGIN() and UT_END() macros for proper structuring. Most commands should describe themselves.
It is allowed to start another test for entirely different content with the UT_BEGIN() macro if the last test finished with the UT_END() macro.
Finite State Machine Generator for C
For quite a long time I’m thinking about simple code generating tools. I don’t want to use a special XML syntax or descriptive language but a simple Excel or OpenOffice sheet instead.
The aim is to generated C source code for small microcontroller applications or retrocomputing systems.
For the start I made a simple generator for finite state machines (Wikipedia entry)
It is also my first script written in Python and thus not really as tidy and neat as I prefer. But it is working for now.
It takes the sheet from an OpenOffice .ods table like this:
| @brief | autofire button statemachine | |
| @see | ||
| State | Event | Next State |
| INIT | KeyPressed | PULSE_ON |
| INIT | KeyNotPressed | AUTOFIRE_OFF |
| AUTOFIRE_OFF | KeyPressed | PULSE_ON |
| PULSE_ON | KeyNotPressed | AUTOFIRE_OFF |
| PULSE_ON | PulseTimeElapsed | PULSE_OFF |
| PULSE_OFF | KeyNotPressed | AUTOFIRE_OFF |
| PULSE_OFF | PulseTimeElapsed | PULSE_ON |
and generates a switch-case style state machine in C with callback functions for state and event handling.
A version with support for object oriented programming with pointers to statemachine objects is planned aswell. Check the github for functional updates.
The actual code can be found on Github: https://github.com/simonsunnyboy/gen-fsm
Debugging Ncurses applications with QT Creator
Today I stumbled over the problems while toying around with a small C project using the Ncurses library.
I recently discovered QT Creator as a decent IDE so I started to use it.
Problem 1 with running the application at all
The program builds fine and runs with ncurses if run in a seperate terminal window.
Upon run from within QT-Creator with checkmark “run in terminal” I got this error message: “Error opening terminal: unknown”
After quite some googling I found the solution as the environment passed to my application in this way does not define the TERM environment variable.
So I added the definition “TERM=xterm” to the list of passed environment variables. Now the Ncurses application runs in its own terminal window.
Problem 2 with debugging the application
Naturally I do not only want to run my application, I also want to debug it using gdb. QT creator handles this normally fine so I click on “Debug.”
I see the extra terminal window opening but I get a small notice “ptrace: Operation not permitted” and all collapses.
Some more googling and I discover that Ubuntu 10.04 and later deactivate the option to attach gdb to running processes. This is something QT Creator seems to try here when running the application inside the terminal window.
I simply used the directions found here at AskUbuntu and now it works. I have the application ruuning in a seperate terminal window and I can trace, singlestep and debug it with the gdb frontend from QT Creator.
What a mess!
But it only affects debugging Ncurses and maybe S-lang projects. Normal terminal output is fine and so should be SDL based stuff aswell. It is dirty and slight hacky, but all in all it is working.
Sourcecodeumzug für Quadromania nach GitHub
Da Google Code seine Pforten schliessen wird, habe ich die Sourcen für mein Spiel Quadromania nach GitHub umgezogen.Vielleicht arbeite ich ja mal am Projekt weiter, aktuell ist das aber eher unwahrscheinlich.
Projekt-URL zum Auschecken bei GitHub lautet: https://github.com/simonsunnyboy/quadromania
CMake Toolchaindefinition für GP2X Wiz
Ich hatte schon vor längerer Zeit eine Toolchaindefinition zur Verwendung des GP2X Wiz GNU Crosscompilers mit CMake geschrieben. Diese möchte ich natürlich öffentlich zugänglich machen.
Damit kann man Projekte, die CMake (Was ist CMake?) verwenden, einfacher für den GP2X Wiz übersetzen.
Verwendet wird die Toolchaindefinition mit CMake wie folgt:
cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-GP2XWiz.cmake ..
cmake -DCMAKE_TOOLCHAIN_FILE=Toolchain-GP2XWiz.cmake <Pfad zur CMakeLists.txt>
Quadromania Sourcecode now at Google Code
The sources for my opensource game Quadromania are now hosted at Google code:
http://code.google.com/p/quadromania/
Included is the complete history of my sofar local Subversion repository starting with the first public 2009 release.
How to configure PySVN to use Kdiff3 as the Diff tool
PySVN is a nice graphical client for Subversion. Unfortunately the builtin Diff tools are pretty awkward to use, esp. if the user (like me) is rather well known with Kdiff3.
I figured a bit with the settings and now PySVN diffs gracefully with Kdiff3 for me.
The settings are simple:
Set “External GUI Diff Command”, “Diff Tool” to kdiff3 and the “Tool Arguments” to -L1 %tl -L2 %tr %nl %nr
Happy Diffing!
Die Tücken der Spieleportierung
Gestern habe ich wegen dem stürmisch schlechten Wetter, bei dem man ja kaum vor die Tür wollte, am Nachmittag ein wenig programmiert. Ziel sollte es sein, das alte Spiel Megadash, ursprünglich für den Atari ST in GFABASIC geschrieben, auf PC bzw den GP2X Wiz zu portieren.
Ansich ging das ganz gut, binnen 2 Stunden hatte ich die meisten notwendigen Teilmodule in C neugeschrieben, eine Umgebung mit Code::Blocks aufgesetzt, meine ParadizeLib eingebunden und generell auch zum Laufen gebracht.
Am Ende des vorigen Nachmittags hatte ich dann das Spiel mit allen Mechaniken am Laufen, wie die Steine fallen, etc. Nur das Timing habe ich irgendwie nicht 100% abgebildet bekommen. Stellen, die im Originalspiel zwar mit Tücken bestückt waren, aber spielbar waren, funktionieren in meinem Port irgendwie nicht mehr. Die Steine erschlagen den Spieler an Stellen, wo man im Originalspiel erfolgreich “um sein Leben” rennen konnte.
Ich habe verschiedene Timingparameter angepasst, aber keinen zufriedenenstellenden Zustand gefunden. Entweder ist es immer noch zu schwer, oder viel zu leicht und auch da nicht immer nachvollziehbar.
Mal sehen, ob der Fehler noch gefunden wird. Im Moment liegt es jedenfalls als begonnenes Projekt auf der Platte.