Issues with the VRC6 Implementation of the Everdrive N8

I'm a huge fan of the Everdrive series. After having bought the sd2snes to get to play some of the extremly rare SNES games (Rendering Ranger, Manfred Trenz for the win^^) I decided to also let the Everdrive N8 join the fun.

The shop said it even features expansion audio so the japanese release of Castlevania III namely akumajou densetsu can be played with the sound of the VRC6 which the american NES was not designed for.
First of all I'm from germany, I bought the card and put the ROM on the card and played it with my PAL NES. Well it didn't run quite well as the game couldn't handle 50 Hz. So i had the decision. Buy the Famicom or a US NES with an expansion audio mod.
I didn't liked the idea of having my controllers directly soldered to the console so i went for an american NES.
The game ran well but the audio was still quite strange as the mod was not yet performed.

So i opened the NES and connected pin 3 and pin 9 of the expansion port.
I don't know if this also goes for Famicom to NES converters but this is what the Everdrive needs.

I started the game and something was wrong. The sound was not quite right. Missing notes?
With an NSF player on my PC i listened to the 'reference' I was used to listen to. I heard a strong baselines on 'Beginning' and 'Aquarius'.
On the Everdrive however the baseline which is played by the Sawtooth channel of the VRC6 was incredibly quite.

I registered on the forum of krikzz the developer of the Everdrive and complained about this. Sadly no one was able to help me as this is a known issue.

I then contacted krikzz directly and wow I love you man. He has supplied me with the source code for the FPGA. I investigated and compared the design with the infos I've found on nesdev and found an issue with the internal mixing circuit that was putting the two pulse waves and the sawtooth together. Also the pulse waves did have exactly twice the volume they normaly should have.

I synthesized the design with my changes and there it was. The baseline of Beginning coming out of the Everdrive. I've added a poti to allow changing volumes while playing until I'm satisfied.

You can download my modified version here.
Replace 024.RBF inside EDFC/MAPS on your SD card with this version. But make yourself a backup first. Please keep in mind that this mod is not yet finished as further testing is needed for perfect accuracy. Also the LO/HI volume setting is ignored. I can archive quite good results at the moment with 77kOhm between pin 3 and pin 9.

I've tested it for a few minutes but be sure you are doing this at your own risk. If this mod damages your Everdrive N8 or your NES I can't help you.

Happy whipping some vampires!

Motorrad Navigation mit Sprachanweisungen und Routenplanung [German]

Welch ein stiefmütterlich behandeltes Thema.... hier meine Erfahrungen dazu:

Selbst in Deutschland kommt irgendwann mal wieder der Tag, wo die Sonne sich blicken lässt. Was also tun? Genau, mit dem stählernen Schlachtschiff auf die Straße natürlich!

Nun möchte man nicht immer einfach nur der Sonne entgegen fahren. Manchmal ist so ein Ziel gar nicht mal so schlecht. Wie aber nun einen schönen Weg von A nach B finden?

Mein erster Ansatz war relativ simpel: Google Maps auf dem Smartphone einschalten, Ziel eingeben, Autobahnen vermeiden, Knopf ins Ohr und los gehts. Die Sprachnavigation führt mich mit präzisen Anweisungen ans Ziel. Das Problem ist jedoch die gewählte Route. Stadt, Ampeln, bääh.
Eine andere Lösung musste her.

Wer sich mit Google Maps etwas genauer auseinander gesetzt hat, stellt fest, dass die Route mit der Maus gezogen werden kann. Sie ist also veränderbar. Perfekt, das ist genau das was ich brauche. Leider ist Google hier etwas bräsig, da dieses Feature nicht in der App zur Verfügung steht.
Auch ist es "offiziell" nicht möglich die gezogene Route zur App zu transferieren". (Inoffiziell klappt der Transfer. Aber die Navigation erfolgt dann nur zum ersten Zwischenziel....)

Nach einigem Suchen stellte ich fest, dass es Zeit war sich Google abzuwenden. Schließlich gibt es Navigationssoftware für Android in rauen Mengen. Gleichzeitig muss berücksichtigt werden, dass die geplante Route in diese importiert werden muss. Ich möchte nun auf einige Applikationen eingehen.

Routenplanung

Welche Software ist für das Planen der Routen einsetzbar?

Motoplaner
Der Motoplaner wirkt wie eine gepimpte Version von Google Maps. Es können Adressen eingegeben werden. Autobahnen können vermieden werden. Die Route kann wie bei Google Maps gezogen werden.
Erweitert wurde das ganze jedoch um Import und Exportfunktionen.
Die geplante Route kann in diversen Formaten gespeichert werden.
Direkt unterstützt werden z.B. GPX, Navigon und CoPilot. Die Liste ist jedoch riesig, weshalb ich hier nicht weiter darauf eingehen kann.

Das Programm funktioniert zuverlässig, das ziehen von Routen hat jedoch kein Echtzeit-Update der Route, wie dies beim offiziellen Maps der Fall ist.
Beim Motoplaner muss auf das Exportformat geachtet werden. Es können Routen und Tracks exportiert werden. Während Routen nur aus den Stützstellen bestehen, beinhalten Tracks die vollständige geplante Trajektorie und lassen der Navisoftware keine Wahl bei der Planung.

Google Maps + ITN Converter
Das aktuelle Google Maps erlaubt keinen Export in eine Datei. Stattdessen können Routen "geteilt" werden. Ausgegeben wird hier jedoch nur eine URL, welche bei erneuter Eingabe den aktuellen Zustand mit den Stützstellen und dem Ziel wiederherstellt.

Zwischendurch fand Ich den ITN Converter. Dieses Windows Tool, welches auch unter Linux + wine bestens arbeitet, kann Routen diverser Formate konvertieren. Man nehme die Google Maps URL, kopiere sie und füge sie einfach in den ITN Converter ein. Dieser erkennt die URL und setzt die Route um. Danach kann unter anderem nach GPX, Sygic, Navigon und CoPilot exportiert werden. 

Mir persönlich gefällt diese Art sehr gut, da das Google Maps Interface sehr angenehm zu bedienen ist.

Routenbasierte Navigation

Nun haben wir unsere Route. Aber wie kann ich diese abfahren?

OsmAnd
Osmand.... welch traumatische Erfahrung. Im Gegensatz zu allen anderen Navis in dieser Liste ist Osmand nicht nur in der Lage der Route zu folgen. Auch Tracks können verarbeitet werden. Leider ist die Sprachnavigation in diesem Fall sehr beschränkt. Mehr als ein "fahren sie links, fahren sie rechts" lässt sich dem Text-To-Speech nicht entlocken.
Was die Navigation mit Routen betrifft ist ein Chaos. Osmand stürzt regelmäßig ab oder verweigert sich mit "Startpunkt zu weit von Straße entfernt" einer Routenberechnung. Viele bezeichnen Osmand als einen heiligen Gral der Open Source Navigation. Selbst als Linux-Vollblüter kann ich dem irgendwie nicht zustimmen.

Sygic
Sygic (~24€) bietet eine 7 tägige Probeversion an. Das ist gut, da der Preis doch schon eine Hausnummer ist. Die Katze im Sack will hier niemand kaufen. Nach ein paar Teststunden dachte ich "Ja, das ist es".
Doch wirklich zufrieden war ich dann doch nicht. Die Autobahnnavigation mit Sprachführung ist katastrophal. Statt dem gewohnten "Nehmen sie die Ausfahrt auf die A40 Richtung Bochum" hört man nur ein "Nehmen sie Ausfahrt 15" (Die Zahl 15 dient hier nur als Beispiel ;-)). Da das Cruisen auf dem deutschen Highway aber natürlich nicht soo viel Spaß macht, war das nicht direkt ein Negativkriterium.
Wirklich penetrant wurden Stabilitätsprobleme beim TTS und schlechte Kartendaten mit dementsprechend irre führenden Sprachkommandos.
Nach jedem starten musste ich als Sprache zuerst Doris auswählen, danach TTS und erst danach funktionierte die Sprachnavigation. Wieso?
Dann der Akkuverbrauch. Selbst nach beendeter Navigation arbeitet die App obwohl in der Systemleiste kein Logo mehr vorhanden ist. Neu ein Neustart oder ein Prozesskill löste das Problem.
Zuletzt die Kartendaten. Nicht jeder wird dieses Problem erleben, da es von den aktuellen Lokalitäten abhängig ist:
 
Folgende Grafiken (Quelle: Google) zeigen einen Kreisverkehr, wie er in der Kleinstadt Bergkamen zu finden ist. Einmal die Satelliten Aufnahme und zusätzlich die Straßenkarte.

 

Nun nehmen wir an, wir kommen von Süden und laut Route geht es Richtung Norden weiter. Was erwarten wir von unserer Sprachnavigation?

"Nehmen Sie die 1. Ausfahrt im Kreisverkehr in Richtung Schulstr."

akzeptabel und durchaus logisch wäre auch

"Fahren Sie im Kreisverkehr geradeaus"

Nun die Frage, was macht Sygic?

"Nehmen Sie die 2. Ausfahrt"

Halt moment, dachte ich mir. Die Buchfinkenstr. ist nicht Teil der Route.
Da ich die Route ungefähr im Kopf hatte, machte ich eine Pause und sah mir die Route von Sygic an. Alles richtig aber ... Moment! Dieser winzige Fahrradweg, bei Google in Grau, wo natürlich kein Auto reinpasst.... nicht mal ein Fahrrad, da der Bordstein nicht abgesenkt war..... IST BEI SYGIC EINE AUSFAHRT!!!!

Bugs schön und gut aber da wurde es mir zu viel. Der Test war damit beendet.

Navigon
Ich hätte Navigon gerne getestet. Wirklich wirklich gerne.
Die App kostet 50€ und es gibt keine Testversion wie bei CoPilot oder Sygic.
Ernsthaft??
Wer gibt 50€ aus ohne es vorher getestet zu haben???


CoPilot GPS / CoPilot Premium
Ich hatte meine Suche verändert. Statt nach "navigation app follow route" zu suchen, habe ich mich in Richtung Apps für Motorradnavigation bewegt. Dadurch fand ich eine hübsche Website, die mir die Suche etwas erleichtern sollte. Basierend auf der Wertung habe ich mich dann CoPilot angenommen. Diese wird in Deutschland für 24€ verkauft und lässt, wie Sygic auch, eine 7 Tage Probezeit offen. Also ITN Converter angeschmissen und die Tracks als .trp Datei exportieren. Der Zielpfad für die Routen ist leider etwas unglücklich komplex gewählt und scheinbar abhängig von den Kartendaten.
In meinem Fall /sdcard/com.alk.copilot.eum/EU/save/.
Danach App starten, dementsprechend nach den Wünschen konfigurieren und die Route laden.

Ich hatte bisher keine Versuche unternommen GPX Tracks zu laden. Um die Software nicht zu überfordern bleibe ich jedoch bei Wegpunktbasierten Routen.
Als einzige Software die ich bisher getestet habe, bietet CoPilot die Möglichkeit die Route zu "ziehen". In etwa genauso wie es Google Maps online kann.
Die Sprachnavigation ist von ausserordentlicher Qualität und erinnert an die Aussagen von Google Maps. Falls man etwas taub auf den Ohren ist, kann die nächste Abbiegung in Distanzschritten mehrmals wiederholt werden, welches den Routing Erfolg natürlich steigert.

Relativ verstörende Resultate erhält man jedoch, wenn man bei der Routenplanung nicht aufgepasst hat. Ich hatte eine Stützstelle versehentlich auf einen Kreisverkehr platziert. Aus großer Entfernung nicht ersichtlich, wies mich CoPilot vor dem Kreisverkehr darauf hin, dass ich doch bitte "Ausfahrt nehmen sollte".
Nach einer Korrektur der Route ist dieses Phänomen jedoch nicht mehr aufgetreten.

Ein weiterer Bug von CoPilot ist das fehlende Feature eine Route umzudrehen. Es ist deshalb notwendig die Route 2 mal aus dem ITN Converter zu exportieren, welcher in der Lage ist diesen Part zu übernehmen. Dies ist jedoch ein vergleichsweise kleines Manko.

Fazit

Nachdem ich mich ein paar Wochen mit diesem Thema beschäftigt habe, kann ich sagen, dass sich die Kombination Google Maps + ITN Converter + CoPilot Premium für mich durchgesetzt hat. CoPilot ist in der Testphase nicht einmal abgestürzt, was traurigerweise ein postives Feature ist.
Die Sprachkommandos entsprechen meinen Anforderungen da dank TTS auch Straßennahmen wiedergegeben werden.

Suzuki Intruder M1800R - Zugkraftdiagramm / Gangdiagramm [German]

Bei sportlichen Motorrädern ist es in der Regel üblich, dass diverse Kennlinien die Eigenschaften des Motors und des Antriebstranges beschreiben.
Anfang 2015 war ich auf der Suche nach einem leistungsfähigen Cruiser (Widerspruch?) und musste feststellen, dass derartiges nicht für diesen Typ Motorrad angefertigt wird.
Als ich mich schlussendlich für eine Suzuki Intruder M1800R entschieden habe und letzte Woche ein bissle Lust hatte etwas in Java zu tippen entstand die Idee, diese Diagramme selbst zu erzeugen.

Meine Berechnungen basieren auf folgenden Annahmen, die in der Betriebsanleitung zu finden sind:

    final static double gearRatios[]={
        2.187,
        1.400,
        1.038,
        0.827,
        0.685};
   
    final static double primaryRatio=1.647;
    final static double secondaryRatio=2.823;
   
    final static double reifenDurchmesser=0.65; //m

Die Kennlinie selbst war leider etwas problematisch, da diese gemessen wird und sich deshalb Messfehler einschleichen können.
Für das Zugkraftdiagramm verwende ich für die blaue Kennlinie diesen Test und für die rote diesen. Beide Kurven unterscheiden sich deutlich und Ich zweifle deshalb etwas an der Glaubwürdigkeit. Da ich keine anderen Kennlinien finden konnte, muss ich das erstmal akzeptieren und zeige beide Varianten in einem Diagramm. Die grüne Linie visualisiert den Luftwiderstand. Die kleinen Zahlen repräsentieren die aktuelle Drehzahl.

Das Gangdiagramm zu ermitteln ist dagegen ein leichtes, da hierfür nur das Getriebe und der Reifendurchmesser notwendig sind.
Ich bin mir relativ sicher, dass hier kein Fehler unterlaufen ist, da einige Fixpunkte mit meinen Erfahrungen übereinstimmten.

The Adventure of running Linux on an Amiga 1200 in 2014

A few weeks ago I've googled a little bit for the keywords "amiga" and "linux" and discovered that the m68k port of Debian is still in development and maintenanced.
I remembered trying to install a Debian 2.0 inside a WinUAE enviroment a few years ago but it somehow failed as the kernel never really came up running. At this point it was only a small test and I just said myself that the kernel maybe needs a part of Hardware which only a real Amiga has.
Looking back I assume I've forgotten to enable the MMU emulation....

Being more experienced with linux now and also in the possession of an Amiga 1200 equipped with a 68030 (with MMU!!) and 64 MB of memory I finally decided to try it again. But this time without any old prebuilt solutions.
As it turned out the only part really maintained is the Debian Ports repository. New installation CDs are not available. But this shouldn't be an issue I thought. Experienced with the Debian multistrap tool for embedded systems I've built a root file system using this repository with nearly up-to-date packages.

The official Debian Wiki for M68k gives a few hints on the installation and also distributes prebuilt kernel images. I've tried one and guess what. It actually worked and my 1200 was running linux 3.2.x!
I just had to grin while the ridiculously slow configuration process was running.... time zone ... click click ..... keyboard layout .... click click ..... discoverying network hardware........ FAILED!!!

Source: http://www.gamesaktuell.de/screenshots/970x546/2012/04/FUUU_Guy.jpg

If you are not a linux user you might don't know this but having access to a network hardware is essential for Debian. Especially if you don't have any installation CD this is the only way to install software.
So what to do now? Looking into /lib/modules I could find some drivers but none for my 3COM Etherlink III which apparently has the chip 3c589. There is actually a list of some guy about supported PCMCIA network hardware for the Amiga. My card is also listed but as an unsupported one.

The kernel of the Debian Wiki offered only about 6 network drivers and I couldn't believe these were all. So I downloaded a vanilla 3.14.1 kernel wishing I could compile it with more modules. So the pain was about to begin...

What do you need to compile a kernel? A compiler might be a good starting point. If you want to compile linux software for the m68k a m68k-linux-gnu-gcc is the right thing. Debian offers the Emdebian repository which gives quite a few cross compilers. So while browsing the package manager I've found the right thing. So cool, huh? Well no! The m68k-gcc inside the official Emdebian Repository has an unresolved dependency and couldn't be installed. I couldn't believe it. So I started to compile binutils and the gcc manually. Somehow no success. I don't want to discuss the reasons here. Some missing headers or what......
As the process of making a toolchain seemed to be black magic i tried to use crosstool-ng, a software to auto-generating gcc toolchains. So cool, huh?
Well NO! crosstool-ng doesn't offer m68k support with the normal libC. Instead only µlibC. Arghh! No! Well, I dont' care. Just build the µlibC version It might work as well. And again a stone in my way. The elf2flt repository is down and crosstool-ng is unable to build anything. What a joke!
I also tried to use a prebuilt bare metal compiler using the target m68k-elf- as I thought it wouldn't matter for the kernel. It compiled well but It crashed at the point in head.S where the startup routine was about to enable the MMU. You can actually see it as the m68k port prints the alphabet on the Amiga's serial port before starting the true kernel code.
Kinda depressed about the bad shape of this part of the community I was about to stop this whole test.

But then I got one idea! I couldn't install the gcc compiler from Emdebian because the dependencies were unresolved. But not because the package was missing. It was a version mismatch between the gcc and the libgcc2. Well F*CK the dependecies I said myself and so I've force installed all needed packages and tried it again. I've compiled the kernel, installed it and then another try...... It worked......

I was proud as I've managed to get a 3.14.1 kernel running on my real Amiga. I've also selected a 3com driver and at this point I thought it was the right one. But ..... duuuh .... as I've loaded it the kernel said it couldn't find the card. I looked again in the kernel config and yes it was the wrong driver. It was for the 3c509 which is a character apart from my 3c589 and not a PCMCIA but instead an ISA card. :-(

I've filtered the kernel config for "5c589" and a driver was existing. I looked for dependencies and guess what.

Depends on: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_3COM [=y] && PCMCIA [=n]

I couldn't select the driver as PCMCIA was not enabled...... not enabled I thought??
I remembered activating "Amiga 1200/600 PCMCIA support" and here is the deal. It was handled seperatly as AMIGA_PCMCIA. I thought that this might be some configuration problem inside the kernel as I don't assume that the Amiga port was tested very well. I looked inside linux-3.14.1/drivers/net/ethernet/3com/Kconfig and changed the dependency to "PCMCIA || AMIGA_PCMCIA" and tried it again. This time the compilation failed as a few functions were not available. Looking at the source code of the PCMCIA implementation I've discovered the reason. The PCMCIA subsystem for the Amiga is quite old (I'm not even wondering) and also has a different interface compared to the normal one.

At this point I've compared both subsystems but couldn't help it. I'm not experienced enough to solve this issue and the motivation was about to drift away. I will still try it though and write about it here.

SlamyCopter Project - Part 1

I has been a while since the last serious stuff here. Since September 2013 I'm working on a quadrocopter from scratch (uuuh mainstream D:).

But a little story first. When I was 14 or 15 this thing here came out.

Source: http://sven.rc-madmen.com/wp-content/gallery/x-ufo/ufo02.jpg

This is the Silverlit X-Ufo and one of the first r/c quadrocopters you could buy for private use. I WANTED it ... and got it for christmas :3 lol. Compared to the models we have today the X-Ufo was kinda strange as it uses a mechanical gyroscope in the middle to detect the angle. It was simply awful as this was quite a limitation. After you start this thing up you had to wait for about 5 seconds until it was ready which is not that bad as todays gyroscopes also want to calibrate themselfs to have less drift. But bad is the limitation of the angle as .... if i remember correctly .... about 10 degrees are the maximum for every axis. And not only bad but quite frustrating is the tendency to failure. The mechanical gyro was deactivated if to much g-force was applied horizontally. This always happend if you move in one direction and then flipped the joystick in the other direction very fast. The resulting negative acceleration was to much for the little gyro which stopped rotating. Without any stability system the X-Ufo crashed to it's doom. I got a friend having also one. His died first. My only weeks later....

So the years were going and after seeing the Parrot ARDrone owned by another friend and, some DJI Phantoms in the r/c stores and some videos on YouTube about the famous MikroKopter I was hyped again. The last important question was: Buying or Building? As I'm quite experienced in soldering, pcb design and digital circuit design I decided to give it a go. Until this point I didn't knew how much blood, sweat and money I've to spend to reach my goal.

The first part I've built is the motor controller which is based loosely on the schematics found here on the microcontroller wiki. And I have to say that these look quite similar to those of the BL-Ctrl. You can see my inspiration^^. My controller is based on IR2104S FET drivers, an ATMega88 and IRFR1205 FETs. The prototype looked like this and was tested using an old broken harddrive.

  

After that multiple things were done simultaneously. I've bought my R/C the Spektrum DX6i together with an AR2610 receiver while I've layouted the circuit of the brushless controller using eagle so that I could send it to the pcb manufactory which takes quite some time. The mentioned wait time was used for other planings as a frame had to be constructed. I first thought about building it with balsawood which is quite light. But some forums said it wouldn't be the ideal material for a project like that..... so i sticked to 10mm aluminium profiles from the hardware store.... like everyone else. Some big inspiration was Thomas Pfeifer and his quadro project here.

Sadly I don't have any photos to show here from this time...

Also I needed a cental controller which contains the "intelligence". A friend of mine suggested using the STM32F4 Discovery which he had lying around at the moment. Normaly the NXP LPC guy i tried it out and it seemed to be a rather good board.... a little bit big but whatever. Besides the controller some sensory was needed. The quadro needs to know how angled it is as usual quadrocopters are self stabilizing. Through my work I've learnt about the MPU9150 which is a monolithic chip including an accelerometer, a gyroscope, a magnetometer and a DSP :-O. This thing is simply amazing as you don't have to do any data fusion to get the 3 sensors together. At least the manufacturer praises this.....

What is still missing? Right, the motors! I've used the MK2832-35. The inspiration coming from the MikroKopter isn't deniable. The motors are quite expensive but I'm hoping for good quality here. Bad motors tend to have some problems as this german review suggests. 

After soldering the brushless controller and building a cross out of aluminium I designed a power supply board which sticks under the STM32F4 discovery containing a step down to generate 5V for the discovery from the battery pack.

Speaking of batteries. The one I use is the Turnigy 4S 3000mAh 20 which gives me ~13 minutes of flight time. For charging I use a SkyRC IMAX B6 (the non fake version :3).

Then I put it all together and finally in december my first flight was possible.

At least I tried. The PID algorithm i used wasn't optimized yet. Again Thomas Pfeifer was my inspiration as I've built myself a wooden structure containing the quadro in a free rotating position at least for one axis. The videos below will explain more about it. After I've found a quite usable configuration it was time to fly.

There are still enhancements going on. GPS, a barometer, and FPV flight are the topics I'm working on at the very moment. I've prepared also a VideoBlog on YouTube. Check them out and stay tuned for more :3.

zprommer - Modifiction for 272001

As mentioned in a previous post I use an RR-Prommer to program my EPROMs. As the RR-Prommer is a copy of an very old EPROM Burner by Batronix I could use the linux tool zprommer which is made by zut. Please take a look here to see what it can do. It's a really cool tool if you still use EPROMs.

One problem with this tool is that it doesn't support the EPROM 272001. As my RR-Prommer mentioned support for this one I decided it must be a software issue. I modified the zprommer sources to get this to work and you can download them here.

VectrexRomPacker

As they was interest in my Vectrex Cartridge I decided to upload the sources for the program that is capable of arranging multiple vectrex roms in a big image that it suits the needs of the Cartridge adressing logic.

Please download it here.

It's a C program written on and for linux but it should be compilable under windows as well. You also get script files that tell you how to use it.