More VTech hacking

Posted by pulkomandy on Sun Mar 28 21:53:57 2021  •  Comments (0)  • 

Oh wow, have I not made any progress on VTech things since 2017!?

Anyway, you may have read the previous article about this. I have mentionned this to a few people and eventually one of them contacted me, informing that there was more ongoing work on the V.Smile. Having other people to discuss things with has renewed my interest in these things.

This resulted in a 3 hour bike ride to get yet another V.Smile, including a complete set of controllers (dance mat, the two different available keyboards, and a graphics tablet. The seller asked me if I needed some games and who would be using the system. Their reaction when I told them that the console was for my own use and that I would program my own games for it was well worth the long bike ride as you can imagine.

For now this results in a new Wiki for V.Smile things and some progress in documenting the hardware there. This was a work of collecing info from old datasheets recovered from, cross-checking with the existing emulators, and a bit of guessing. I also finally started using my logic analyzer, and documented the protocol for the controllers (not all of them yet, because the graphic tablet need batteries and I don't have enough).

There is also some work in progress (not only by me, it's nice to be in a team) to write an assembler targetting the V.Smile CPU, and a development Smartridge is being worked on as well. So that should finally put V.Smile development within reach of more people.

I also contacted Bobzy again and learnt that he was working on the VTech IQ unlimited laptop (also known as the Equalizer in the US, apparently). It has 2MB of RAM, and a Motorola Dragonball EZ CPU. The display is a reasonable 480x272 pixels and support grayscales. So I found one on eBay and it will soon be delivered to me. Bobzy has been working on a Linux port, but I wonder if EmuTOS would work, to provide an alternative to Atari's own Stacy and ST Book laptops (which are either bulky and heavy or rare and impossible to find). Wouldn't it make a nice lovely little machine?

I thought this was the most powerful machine in the VTech lineup (excluding the boring modern things that run Android), but it turns out I had missed the VTech Helio PDA, which is faster and has more RAM, as well as an almost opensource OS (they published the source with a rather permissive license, except you are not allowed to use them for other hardware). I may keep looking for one of these as well (if I can find one at an acceptable price or with a flashy color plastic, not boring blue).

Considering all this new hardware made me remember that I had unexplored/undumped machines at home too. So I did some research on the CQFD Scientus, which I had come accross in a garage sale a few years ago. I thought I had broken something when disassembling it but iit turns out it was just a wire desoldered from the motherboard.

I was curious about the CQFD branding. The macine design looked somewhat similar to VTech things, and Internet knew nothing about this machine. And the motherboard has VTech chips. I discovered that CQFD is a second brand created by VTech France to position their machines more as toys (as if the existing machines didn't look enough like toys already). It apparently existed between 1998 and 2001.

Other than that the Scientus is not super interesting, I suspect it will be running a Z80 based system like many other VTech machines, but the display is just too small to do anything useful with it. Not to mention there are some empty columns, in a weird mix of text mode (where you would have 8x8 cells of pixels separated from each other) and graphics (where it would be a single continuous matrix).

I should dump the ROM still, to explore what's in it. Surprisingly it's an UV erasable EPROM, which I guess indicates that this machine was not produced in huge quantities (otherwise VTech would probably have made a proper mask ROM for it?).

Also while looking at it I found out that one chip used for sound generation is in common with the IQ Unlimited laptop. I saw a TI logo on it and now I suspect that it is only a volume control chip (as they have some in a similar package for which I found datasheets).

See you soon (well... sometimes in the next 4 years?) for more news about this!

Gravis Interface Protocol

Posted by pulkomandy on Wed Dec 2 18:47:36 2020  •  Comments (6)  • 

This article has been revised to include fixed and up to date information after I actually plugged the gamepad to an oscilloscope. Now it should be error-free.

Ever heard of the Gravis Gamepad Pro ? It's a gamepad using the old-fashioned PC gameport. It looks quite like the original Playstation controller and has a very solid build quality.

Those of you who know about the gameport limitations will quickly notice that there must be something non-standard about it: there are 10 buttons, while the gameport only allows 4. Even better, you can actually use 2 gamepads at the same time on a single port.

There are several modes accessible with a switch under the gamepad. These are 1-player, 2-player, and GrIP. In 1 player mode, you get 2 axis and 4 buttons. In 2 player mode, you get 2 axis and 2 buttons, and you can use 2 gamepads. In GrIP mode, each gamepad can use all 10 buttons, but this is not compatible with the games expecting a standard joystick.

I have some of these gamepads around, but my PC don't have a gameport anymore. Since I'm not very happy with replacement hardware (I tried the Logitech Precision USB gamepad, but it doesn't look as nice and colourful), and the USB version of the Gravis Gamepad is impossible to find (and less beautiful with the black plastic, I'm thinking about building an adapter for these gamepads to plug them on an USB port. Of course, without opening and rewiring them. Not only this would void the long expired warranty, but I may still want to plug these gamepads to the system they were intended for (my 1995 Pentium 166 MMX).

There is some information on the internet about the protocol, but it's not easy to find. Here is what I could get : a textfile with some info and (originally from, which is now offline) and the Linux driver for these joysticks. Since the textfile does not say everything the driver does, here are some notes that duplicate the text file and add the info from the driver.

I checked this with an oscilloscope, so I believe the information to be correct. But I may have missed something.

First, the gameport pinout. It's a SUB-E 15 connector. The following pins are relevant:

  • 1,8,9,15: 5V power (my gamepad accepted down to 3V, below that it stops generating the clock signal)
  • 4,5,12: GND
  • 2,7,10,14: buttons 0,1,2,3
(the other pins are axis 0, 1, 2, 3, they are not used in GrIP mode).

When you use only one gamepad, buttons 0 and 1 are used as data lines. Button 0 is a 20 to 25kHz clock. On each falling edge of this, you can read the state of button 1. Frames are 24 bits long and is formatted as follows:

The frame starts with a start bit, then 5 bits set high. Since the button data is split in 4-bit words with a 0 interleaved, there can't possibly be 5 set bits anywhere else, this makes it possible to detect the start of a frame.

Transmitting a full frame at 20KHz will take about 1.2ms (slightly more than 1.5ms on my test gamepad). This is more than fast enough. It's likely that Gravis drivers on windows only polled the gameport only 20 or 25 times per second (or even less), and waited up to 2ms for a frame start. This was the only way for them, because these gameport buttons are not triggering interrupts.

When there are 2 joysticks connected, the second one uses buttons 2 and 3 exactly the same way. The Gamepad Pro has a pass through connector that swaps buttons 2 and 3 with 0 and 1 for the second device, like any Y-doubler joystick cable does.

I'm planning to use an STM32f3 microcontroller to decode this. The protocol is close to SPI, unfortunately microcontrollers able to handle 24-bit SPI frames are not common. Moreover, the start of frame is hard to detect so synchronization could be a problem. Bit banging the protocol is a better solution, we just have to use the clock line as an external interrupt and read the bits in the interrupt handler.


Posted by pulkomandy on Fri Oct 23 16:18:11 2020  •  Comments (2)  • 

You can reach me in various ways :

  • Mail : pulkomandy@this server
  • XMPP :
  • IRC : PulkoMandy@ freenode, IRCNet
  • Twitter: @PulkoMandy


Posted by pulkomandy on Thu Jul 19 22:16:11 2018  •  Comments (1)  • 

Un programme d'entraînement au calcul mental. Le concept de départ est assez simple: le programme pose une opération, et vous avez dix secondes pour entrer la réponse (la bonne, de préférence). Au fil du temps, plusieurs fonctions se sont ajoutées, telles que la gestion de plusieurs élèves avec enregistrement de leurs scores et un calcul de statistiques, une protection par mot de passe pour certaines fonctions, et un module permettant également de réviser les comparaisons. On peut également configurer le programme pour réviser plus spécialement certaines tables plus difficiles que les autres.

Il s'agit de notre premier programme un peu sérieux. Nous étions encore au collège quand on l'a développé, soyez donc indulgents. Il nous a été bien utile, ainsi qu'aux petites sœurs et petit frère par la suite.

Certains bugs nous ont échappé, et il semble improbable qu'on prenne le temps de les corriger un jour (a-t-on même encore une sauvegarde du code source?)

Ce programme est gratuit, n'hésitez pas à l'utiliser et à le diffuser.

Téléchargement (723ko)

L'écran d'accueil La fenêtre de jeu Le choix du joueur Les options Les statistiques L'activité comparaisons


Posted by pulkomandy on Sat May 26 15:33:45 2018  •  Comments (0)  • 

Liens en vrac vers les amis, projets auxquels je participe, et d'autres trucs...

My world domination projects

  • GrafX2, un outil de dessin en pixelart multiplateforme. Je suis l'initiateur de ce projet de portage d'un vieux programme sous DOS.
  • CPC SDK, outils cross-dev pour Amstrad CPC sous linux. Je suis l'initiateur de ce projet, en ayant eu mare de récupérer des bouts de paths à droite à gauche.
  • Haiku, un système d'exploitation libre pour les gens normaux.
  • ENSSAT Robotique, le club robotique de mon école d'ingénieurs.


  • Le blog d'ASCII, un collègue étudiant à l'ENSSAT. Jeux de rôles, sites web, et plein d'autres trucs super!
  • Le musée de Sylvestre. De l'Amstrad, des gros pixels qui cligotent, et plein d'autres trucs super!
  • PauLLA, le LUG Palois.
  • Toulibre, des libristes à Toulouse.
  • Le blog d'Exocet, avec du pixelart dedans.

I like these guys!

  • Kevtris (NES, FPGA, Chiptunes, misk hacking and noodles)
  • Linus Akesson (Chiptunes, music, demomaking, atmega, C64 and pipe organs)

Hello World

Posted by pulkomandy on Sun Feb 18 16:30:21 2018  •  Comments (4)  • 

This is the new server of the PulkoTeam! Enjoy your stay here.

On this website you can find various stuff I work on, around the Haiku project, electronics, 8bit computers, and random things depending on the day mood.

Polypus reverse engineering

Posted by pulkomandy on Sun Jan 28 16:27:50 2018  •  Comments (0)  • 

Je me suis souvenu récemment d'un jeu auquel j'ai joué il y a fort longtemps. Il s'agit de Polypus, un shareware dont le principe est de conquérir un tableau hexagonal en y déployant son armée de poulpes (rouges ou bleus).

Il m'a pris l'envie d'y rejouer. Mauvaise idée, puisque le jeu avait presque complètement disparu d'Internet! J'ai retrouvé le site de l'auteur mais le jeu n'était plus mentionné.

Après avoir retourné plusieurs serveurs FTP, j'ai fini par retrouver un installeur (pour la version américaine, mais ça fera l'affaire). J'ai extrait les fichiers (7zip sait extraire les installeurs InstallShield ainsi que les fichiers cab contenus dedans) et récupéré l'exécutable du jeu. J'ai pu le lancer, mais je n'ai pu voir que l'écran d'accueil. Le jeu lui-même donne un écran complètement noir!

Il va falloir creuser pour trouver ce qu'il se passe!

Trouver les ressources

Le jeu est distribué sous forme d'un exécutable, sans aucun autre fichier. Les images et sons sont donc forcément directement dans le fichier. Mais une exploration avec binwalk ne révèle rien de très intéressant (pas d'en-tête d'images BMP ou GIF, par exemple). Ils sont donc dans un format inhabituel.

En creusant un peu, j'ai fini par utiliser Resource Tuner, qui permet d'accéder aux ressources du programme. On voit que celui-ci est écrit en delphi et qu'il y a des "forms" de près d'un 1Mo, ce qui est surprenant. En regardant de près on voit deux gros tableaux d'octets, "TDGCImage" et "TDGCSounds". Tiens tiens...

En cherchant "DGC Delphi", on trouve le Delphi Games Creator, une vieille bibliothèque pour faire du DirectX 3 (!) en Delphi. Il a plus ou moins disparu d'internet, mais un autre utilisateur de cette bibliothèque a pensé à en archiver une copie. On peut récupérer avec celle ci des éditeurs pour des bibliothèques de sons et d'images. Resource Tuner permet d'extraire les tableaux d'octets en fichiers, que l'on peut ensuite ouvrir avec ces éditeurs. Cela marche bien pour les images, mais l'éditeur de sons refuse de se lancer sous Windows 7!

Il va donc falloir creuser un peu pour extraire les sons (et les images aussi, car on peut les voir, mais pas les exporter dans un format normal depuis l'éditeur, et prendre une capture d'écran ferait perdre les informations sur les pixels transparents). Heureusement, on a le code source de la bibliothèque qui permet de charger ces images, donc on peut partir de là pour essayer de comprendre le format, qui de toutes façons n'est pas bien complexe.

à suivre...

Hacking VTech stuff

Posted by pulkomandy on Tue Dec 12 22:11:08 2017  •  Comments (0)  • 

This summer I bought more VTech hardware, namely a V.Smile pocket and a Genius TV Progress (known as Nitro Vision in the US). The latter is quite obscure even by VTech standards and nothing is known about it yet, it's also impossible to disassemble cleanly (case is glued together) so I will order a second one just for disassembling purposes. These are both from 2006, and apparently the last machines from VTech to have a keyboard (the V.Flash/V.Smile Pro does not have one, and later stuff is only tablets. What's the fun in these?)

I previously played around with the Genius PC, an older machine (1998-ish) from VTech based on a 68000 CPU, for which I dumpled the system ROMs. It eventually ended up emulated in MAME and there is ongoing work by other people to figure out the remaining parts of the hardware (mostly, sound output).

For now, let's focus on the V.Smile. It's a quite succesful console for children and thanks to the great work of the Hackmii team back in 2010, we do have some knowledge about the hardware. It apparently uses a Sunplus µ'nSP core, which is not very common but they managed to locate enough docs to get it more or less emulated in MESS.

They mention a GPL-violating version of GCC, but it turns out Sunplus actually does comply with the GPL and dropped the sources of their GCC fork on sourceforge. It is apparently based on gcc 2.95.2 (I can't complain about that, I'm an Haiku developer), and that makes it a little difficult to compile on… well, anything really. Also it is just a source drop without documentation nor compilation instructions.

It took me a while to figure out how to configure the thing, as the configure script does not mention support for the unsp architecture. It turns out, the gcc configure script has a feature for "local" CPUs which we need to use here. On Linux, the command line looks something like this:

linux32 ../unsp-gcc/configure --target=unsp-local --enable-languages=c,c++

The linux32 environment is needed because gcc2 configure script has no idea about x86_64. The enable-language is needed because the objective-C build is broken and I don't care about it anyway (enough obscure stuff already).

The build fails with a complaint from bison that $$ is not ok to use. This is because bison became more strict in some "recent" version. But we can patch the file according to the instructions in some random mailing list post or a more detailed patch from another compiler with the same problem.

There is some more bison-version-related hacking to do, but eventually we get past that with this patch.

Building the compiler on Haiku

As if this was not crazy enough, I also tried to build the compiler on Haiku. It didn't work.

On Haiku we hit a similar problem, but the "local" trick saves us as well:

../unsp-gcc/configure --host=i586-local --target=unsp-local

We get a Makefile in either case. The Linux build fails because Yacc is confused about use of $$. The Haiku build complains about a missing xmalloc.o. It looks like I have more work to do.

Printing on a Color StyleWriter

Posted by pulkomandy on Fri Jul 14 21:02:32 2017  •  Comments (0)  • 

Je suis l'heureux propriétaire d'une imprimante Apple Color StyleWriter 2400. Je l'ai récupérée il y a fort longtemps avec un lot de Macintosh qui partaient à la poubelle.

Cette imprimante date de 1994, elle a été vendue par Apple mais le matériel est conçu par Canon. On peut donc utiliser des cartouces de cette marque.

Et donc, après une dizaine d'année à traîner dans un coin de mon bazar, il était temps de remettre cette imprimante en service!

Étape 1: la brancher

Une particularité des imprimantes Apple de cette époque est d'utiliser un port série. En effet, les Macintosh n'avaient pas de port parallèle comme les PC. En plus de ça, pour gagner de la place sur la face arrière de ses machines, Apple a très vite laissé tombé le connecteur DE-9 pour utiliser à la place une mini-DIN. Rien de grave: on trouve le cablage par exemple ici. J'ai coupé un cable série Apple en 2 et j'y ai soudé un connecteur DE-9, et c'est parti!

Étape 2: les pilotes

Normalement, cette imprimante est sensée fonctionner avec un Macintosh de 1994. Évidement il n'y a pas de pilotes pour les systèmes plus récents. Mais, on a de la chance, quelqu'un a fait une grande partie du travail avec lpstyl. C'est pas vraiment un driver, plutôt un exécutable qui sait juste prendre une image dans un format bien précis, et l'imprimer. C'est prévu pour s'intégrer dans une chaîne d'impression UNIX, entre d'autres programmes qui vont convertir le fichier à imprimer en image, et le port série de l'ordinateur.

J'ai donc récupéré les sources et fait quelques ajustements pour que ça marche avec Haiku, mon système d'exploitation préféré. Et surtout, j'ai du ajouter quelques délais, car le code d'origine est trop rapide sur mon PC et n'arrive pas bien à se synchroniser avec l'imprimante. Bref, après quelques ajustements, l'imprimante prend une feuille de papier, le chariot se met en mouvement et… à la fin, j'ai une page blanche.

Étape 3: l'encre

Ben oui forcément, après 10 ans à dormir, la cartouche d'encre est toute sèche. Hereusement sur ce modèle, on peut remplacer le réservoir d'encre mais aussi la tête d'impression (qui est elle aussi pleine d'encre sèche et donc bonne à jeter). Par contre, Canon ne fabrique plus ces têtes d'impression (on trouve facilement les cartouches avec seulement le réservoir d'encre). J'ai fini par trouver un ensemble tête d'impression + cartouches noir et couleur pour pas trop cher chez un vendeur anglais. J'avais un peu peur que l'encre soit sèche après probablement 10 ans passés sur une étagère. Mais non, les cartouches sont vendues dans un emballage scellé sous pression, et avec un petit feuillet plastique de protection.

Du coup, j'ai juste eu besoin d'installer la nouvelle cartouche et j'ai enfin pu imprimer une page de test.

Étape 4: intégration avec Haiku

Bon, c'est bien joli d'imprimer une image de test, mais je peux toujours pas cliquer sur fichier/imprimer dans mes programmes et obtenir une sortie sur papier directement. Il va falloir intégrer ça proprement.

Ce sera l'occasion pour moi d'apprendre à écrire un driver d'imprimante pour Haiku, et probablement de débugger quelques petites choses dans le support de l'impression en général. De ce que j'ai vu, ça marche pas encore super bien.


Cette imprimante est plutôt solide et efficace, et elle fonctionnera sans doute encore de nombreuses années (tant que j'arrive à trouver des cartouches d'encre, en tout cas). Et autre bonne nouvelle, contrairement à la version Canon, il n'y a pas de compteur de pages qui met l'imprimante HS après un certain nombre de pages imprimées (soi-disant parce qu'il y a un réservoir d'encre usée qu'on ne peut pas vider dedans...).

J'ai donc économisé l'achat d'une imprimante neuve et qui aurait probablement duré moins longtemps.

Quick notes on building gcc

Posted by pulkomandy on Sat Apr 1 13:44:05 2017  •  Comments (0)  • 

This may not be up to date anymore. A complete GCC for AVR (and AMR) is now available as HaikuPorts recipes, which provide a more complete process, with a C library and everything. Refer to these recipes if you need to do it (even on other platforms, the recipes aren't all that hard to read and adjust)

As you may have noticed, I like to develop stuff for all kind of weird devices. For this, I usually need a C compiler, and most of the time it's gcc (not always).

gcc is a big piece of software and there are some tricks needed to build it. Also, I run the Haiku operating system, which is quite nonstandard, so additional workaround are needed.

Today I built gcc for avr. Here are notes on how to do it so I don't spent a month figuring it out next time.

# gcc compilation for gcc 4.4.5 (4.5.x needs more stuff. maybe later)
# Made by PulkoMandy in 2010
# Before you start :
# * Download gmp and mpfr from HaikuPorts ( and extract to /boot
# * Download gcc-core-4.4.5.tar.bz2 from gcc mirror and extract to work directory
mkdir obj && cd obj # This is the output folder. So you can keep the source area clean
setgcc gcc4 # We can't compile gcc4 with gcc2.
../gcc-4.4.5/configure --target=avr --enable-languages=c --prefix=/boot/common/ --with-mpfr=/boot/common/
	# Tell the target, then language we want, and where to install the result. Binaries will be called avr-* so don't care about overwriting other ones.
	# For some obscure reason mpfr isn't detected properly, so we force the prefix.
make all-gcc ; make install-gcc # This does compile only gcc, not libgcc; which failed to work for me.

There are other things to watch out : I had to remove a -lm somewhere as Haiku doesn't have a separate libmath.

Next : build a PlayStation development toolchain, including gcc MIPS target.

Projects I'm NOT coding

Posted by pulkomandy on Sat Apr 1 13:41:22 2017  •  Comments (0)  • 

SometimesI have ideas about software that could be interesting to write or useful to use; but I'm already contributing to a lot of projetcts and I'd rather not start all of the new ones.

Following a talk on #haiku irc channel, I decided to put the list online so other people can pick these projects up and start working on them.

Please let me know if you made (part of) one of them. So I can link to you here :)

PulkoMandy's ever growing TODO-list

Older items first.

  • Port the znax flash game to the Atari Lynx console.
  • Create a device that plug on the amiga clockport and can serve as a base for complicated projects. A DSP to decode OGG would be nice.
  • Build a mouse adapter, similar to AmiPS/2, but using the AMXmouse protocol for the CPC.
  • Compile the SDL version of Road Fighter for the GP2X
  • Port Rick Dangerous2, Prince of Persia 1 and 2, The Lost Vikings 1 and 2, and Jazz JackRabbit 2 to SDL or another lib and make them run on the GP2X.
  • Maplegochi : an electronic Maple tree for the Haiku desktop. You feed it with some water and you watch it grow day after day. The tree is built with random fractals so everyone gets an unique tree on its desktop. It changes over the seasons (depending on the system date and the locale). It is a replicant living on the desktop and acts as a living background,without being too disturbing.
  • Make the various usb to serial chips work on haiku with a simple terminal program.
  • Code a ROMDOS D1 filesystem add-on for Haiku to read/write floppies for Amstrad/Schneider CPC computers.
  • Network-shared whiteboard application for Haiku, allowing people to draw diagrams and see each other drawings. Likely use Playground as a base.


Posted by pulkomandy on Wed Jul 30 10:43:02 2014  •  Comments (0)  • 

Today I discovered Rome2Rio, which is a multi-modal travel search engine. I've been looking for such a tool for some time. Instead of searching only flights, it provides train and bus routes, and allows to mix and match all of these (and even ridesharing) to find the best way to go where you want. It also features door-to-door pricing, which means not just the cost of the flight, but also any shuttle you may need to use from the airport to city center.

They have their own dataset and don't do API queries to other operators. There is a risk of out of date data, but on the other hand, this makes the search super-fast. The trip is visualized on a map and you can easily see what's the best solution.

I can finally plan mixed train/bus/plane trips easily!

Rainloop webmail

Posted by pulkomandy on Thu Jan 30 16:14:57 2014  •  Comments (0)  • 

Pendant des années j'ai utilisé Roundcube comme webmail. Mais je n'en ai jamais été vraiement satisfait..

Et aujourd'hui, j'ai installé Rainloop sur mon serveur. C'est propre, c'est beau, c'est facile à installer, ça marche tout seul, et on a même pas besoin d'avoir les mails sur le même serveur car tout passe par de l'IMAP et du SMTP. Adopté!

Website mirroring

Posted by pulkomandy on Mon Nov 25 10:53:36 2013  •  Comments (0)  • 

Personnal message to whoever uses IP your mirroring of the website using WebReaper was using 100% CPU because most pages are dynamically generated. I have more useful things to do with my server, so WebReaper is now banned. If you want a mirror of the website, I can send you an archive.

You probably won't use everything I have online here, anyway, and you are wasting my internt bandwith. I host this server at home and use the internet connection for you know, web surfing and stuff.