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.

Conclusion

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.

#!/bin/sh
# 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 (http://ports.haiku-files.org/wiki/Downloads) 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.

MesagEase Keyboard

Posted by pulkomandy on Sat Apr 1 13:28:43 2017  •  Comments (0)  • 

I recently gave up on using my old "phonebooth" dumb-phones and switched to… a 10 year old Galaxy S. What an upgrade!

I of course updated it to CyanogenMod, which runs quite well on this device and allows me to get a reasonably "recent" Android version (4.4, which is old, but still compatible with most apps).

Anyway, the main problem with that phone was the keyboard. I was never very good at typing with the numeric keyboard on old phones, but for some time I have been using a Nokia phone with a physical keyboard, which was quite nice. While the tocuhscreen-keyboard on Android makes place for a much larger display, which is a very good thing, it has awfully small keys and no feedback. It also tries to auto-correct me in a way that is sometimes useful, sometimes not correcting obvious mistakes, but also sometimes trying to correct where it really shouldn't or when I'm already trying to correct myself.

As you may know, the QWERTY layout was designed as a workaround for mechanical limitations of early typewriters. There is no reason at all to continue to use it today on physical keyboards, and even less on smartphone virtual ones. Surely, there had to be something better!

After some research, I found the MessagEase keyboard. It is, as expected, an input replacement for Android. The keyboard has just 9 keys, but each of them has 9 chars depending on the gesture you make. It is easy to learn (even if at first you have to do a bit of hunt and peck), and allows quite fast typing. It also has some interesting features, for example the keyboard can be made partially transparent, so you can still see a little of what's under it (not all applications put something under it, but some do). It is also very configurable (you can move characters around on the keyboard and change many other settings).

After a few days of training, I can type at a reasonable speed, and much less typos than with the normal keyboard. So this is something I would recommend to everyone using their phone display as a keyboard. Forget about QWERTY before it is too much hardwired into your muscle memory there!

Now, I need to compare this with Graffiti, which is now available on Android. I remember using that in the Palm days, but I didn't do a lot of writing with it, so I don't remember how fast it could go. Also, using it without a stylus will probably be quite different. But, I should give it a try and see what happens.

Bitbox laptop

Posted by pulkomandy on Tue Nov 24 22:20:55 2015  •  Comments (0)  • 

This article is about the bitbox. If you don't know about it yet, click the link and read about it.

I got my bitbox last year, and it quickly became quite annoying that each time I wanted to use it, I had to unplug the LCD from my PC, locate my gamepad, an USB cable to power it, remember which of the USB ports the gamepad must be plugged to, etc. I also always feared that while carrying the bitbox in my backpack, I would bend a pin on one of the connectors or something.

Well, I solved these issues. I could have gone with a 3D printed case and whatnot, but I went with the simpler solution: make a laptop-like case using some easily hackable devices!

the bitbox laptop!

You can easily build one yourself. You need the following parts (dx.com links included):

Assembply instructions:

  • Remove the backpanel from the TV so it is thin enough to fit the tablet support in the keyboard.
  • Cut some holes in the keyboard cover to make space for the bog capacitors on the TV PCB (easily done, the keyboard cover is only thick cardboard)
  • Locate the 5V regulator on the TV PCB and solder a wire there to power the bitbox
  • Plug the keyboard and TV to the bitbox (you need the VGA gender changer here), and glue the bitbox next to the display (they both fit)
  • Enjoy!

There is some room for improvement. The setup currently doesn't include a battery (I wanted to use an USB "power bank", but the LCD display needs 12V), and the VGA connector is needlessly bulky, especially with the gender changer. I could solder the wires directly to the bitbox and ignore the connector, but I like to be able to remove the bitbox from this. Maybe I should add an HE10 or some other connector for the display output.

So, what is it useful for? Well, you can run all the bitbox games and apps (as long as they can be used with a keyboard). The ZX works fine, but I would prefer a more friendly on-line development interface (Amstrad CPC emulation was suggested, but I think a better idea is a native BASIC/Lua/Forth/Squirrel/whatever). One can also run the chiptracker there, but that needs audio output, which the LCD I used unfortunately doesn't include.

Maybe someone can suggest a reasonably flat and small loudspeaker to fit into this? And what about the battery? There are some 12V batteries on dx but they will need some charge control. Or should I use my USB thing with a boost converter?

Gravis Interface Protocol

Posted by pulkomandy on Sun Nov 23 21:39:25 2014  •  Comments (0)  • 

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. Heer is what I could get : a textfile with some info 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:

011111
0SelectStartR2Blue
0L2GreenYellowRed
0L1R1DownUp
0RightLeft
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.

Développement rapide sur STM32

Posted by pulkomandy on Mon Nov 10 22:53:18 2014  •  Comments (0)  • 

Il y a quelques années de ça (déjà), j'ai fait partie du club robotique de l'ENSSAT. On utilisait pour nos robots des dsPIC30f4011. Afin de travailler rapidement, on utilisait un bootloader permettant de programmer le PIC via un port série, évitant ainsi d'avoir à brancher un PICkit à la moindre modification de code (vu que de toutes façons le lien UART était nécessaire pour tester le code sur le robot). On pouvait même utiliser un adaptateur bluetooth pour faire de l'UART sans fil, pratique pour tester un robot qui se déplace.

Le problème bien connu des bootloaders, c'est que c'est lent. Le lien série a une vitesse limitée et envoyer tout le code pour un PIC peut prendre un certain temps. ça se compte en secondes, mais quand on met au point un bout de code ou qu'on essaie de calibrer un asservissement, ça peut vite devenir très chiant. Notre bootloader était donc capable d'optimiser les transferts en ne reprogrammant que la partie modifiée de la flash. Pour cela le logiciel sur PC est résident, et se souvient du fichier chargé précédement. Ainsi il peut le comparer avec le nouveau et extraire les différences.

Le dit logiciel est d'ailleurs un logiciel libre, il s'agit de RBL. Il inclut également un terminal série pour communiquer avec la carte.

Aujourd'hui, je n'utilise plus de dsPIC30f4011. Par contre, je joue en ce moment avec un STM32f3 et j'utilise toujours un bootloader série. Et le confort de RBL me manque pour plein de petites raisons. J'ai donc essayé de retrouver un confort similaire mais en utilisant une solution plus générique, puisqu'elle repose sur Haiku plutôt que sur Qt ;).

Mon premier problème est de pouvoir partager le lien série entre le bootloader et le terminal. Dans RBL, tout est dans la même application donc il n'y a pas de problème. Le clic sur le bouton "programmer" débranche le terminal, lance le code du bootloader, puis rebranche le terminal.

J'avais commencé à adapter RBL pour l'utiliser avec un NXP LPC1746. Mais avant d'avoir pu finir, j'ai commencé à jouer avec plein d'autres microcontrôleurs, et pour la plupart il existe déjà des outils pour les programmer. Réécrire tous ces outils pour les intégrer à RBL est assez pénible et chronophage.

J'ai donc abordé le problème de façon différente. SerialConnect, le terminal série de Haiku, accepte des commandes de scripting. Cela signifie qu'on peut lui demander, de façon assez simple, de libérer et de reprendre le contrôle du port série (bon j'avoue, j'ai ajouté moi même le support du scripting dans SerialConnect). Concrètement ça donne ceci:

hey SerialConnect delete port
stm32flash ...
hey SerialConnect set port to usb0

Et voilà, on vient de demander à SerialConnect de libérer le port série, ensuite on a lancé stm32flash pour programmer le microcontrôleur, et enfin on prévient SerialConnect que c'est terminé et qu'il peut réouvrir son port.

Il reste un petit problème: stm32flash ne permet pas de redémarrer le CPU pour entrer en mode bootloader. Il faut donc penser à mettre un jumper sur la pin BOOT0 (pour démarrer dans le bootloader et pas la flash), et à appuyer sur le bouton reset. Beaucoup trop fatiguant. La solution est la même qu'on utilise dans RBL, un protocole convenu avec l'application qui permet de la redémarrer et de sauter directement dans le bootloader.

Le protocole est simple: dès que l'application reçoit le caractère 'U', elle se termine. Mon fichier de startup est prévu pour récupérer le contrôle et appeler le bootloader dans ce cas. Il ne reste plus qu'à demander à SerialConnect d'envoyer ce caractère avant de se déconnecter, et le tour est joué. Un simple "make flash" permet de recharger l'application sans avoir à toucher directement à SerialConnect.

Il manque encore l'optimisation de la reprogrammation, qui risque de nécessiter des modifications dans stm32flash. Mais on verra ça dans un autre article, quand mon firmware sera devenu assez gros pour que la différence soit visible.

J'allais oublier, le projet template pour STM32 est sur Github.

Récupérer un Atmel AVR avec FuseBit Doctor

Posted by pulkomandy on Sun Nov 9 23:03:36 2014  •  Comments (0)  • 

Cet été j'ai testé pour la première fois la programmation d'un microcontrôleur AVR8 sous Haiku avec un portage tout frais de la libusb. Malhereusement il restait encore quelques bugs, et je me suis retrouvé avec un AVR avec tous ses fusebits à 0. Impossible de le reprogrammer avec un programmeur ISP classique, soit que le port SPI soit désactivé, soit que l'AVR aie besoin d'une horloge externe que ma carte de développement ne fournit pas.

Fort hereusement une solution existe, il s'agit du Fuse Bit Doctor (attention, page en polonais). Il s'agit d'un montage assez simple à base d'ATMega8 (ou 88 ou 168). Il utilise le mode "high voltage" pour reprogrammer les puces en panne. L'utilisation est très simple: on met l'AVR à réparer dans le socket, on branche l'alimentation 12 volts, et on appuie sur le bouton. En moins d'une seconde la LED verte s'allume et l'AVR8 est restauré dans sa configuration d'usine et fonctionne de nouveau.

Le montage est également assez simple: à part un AVR8 "doctor" contenant le firmware, il comporte 2 boutons, 2 LEDs, 2 transistors, un régulateur, 3 condensateurs et deux douzaines de résistances. Je n'avais pas envie de commander un circuit imprimé ou de tenter d'en graver un, j'ai donc réalisé le montage sur une protoboard 7x9 centimètres. ça rentre juste et il y a la place pour les sockets 28, 40 et 20 pins pour les différents modèles d'AVR qui peuvent être réparés.

C'est donc un montage simple et bien pratique que tout le monde devrait avoir dans un coin en cas de problème. Hereusement que j'ai eu la bonne idée de garder mon dernier ATMega8 encore programmable pour ce montage. Maintenant je peux programmer les fusibles de mes AVR sans avoir peur de tout casser.

Radeon 7000 on Windows 7

Posted by pulkomandy on Mon Aug 18 22:02:04 2014  •  Comments (0)  • 

As you know, Windows XP is EOL now. However, I'm still using that machine I assembled in 2003 as my only Windows computer, and I don't plan to change that. So I went ahead ans upgraded it to Win7.

Everything works fine, except the video card. Windows will complain that it needs a DirectX9 card. I know such a thing can be found even for my old AGP motherboard, but that's more money than I want to spend.

AMD won't provide drivers for such an old card for the new windows (Vista and 7). You can force-install the XP driver, and it will mostly work, but the system will BSOD on shutdown. Not so nice.

The solution is simple, once you have found it. The drivers for Windows Server 2008 will work perfectly. In the case of my Radeon 7000, these can be downloaded from Dell's FTP.

Note that the installer won't work, but using the inf files provided with the driver will go fine. And I now have my PC running as it should again.

I should look into Windows Server drivers for more of my hardware. It looks much less bloatware-enabled than the mainstream versions and gets the job done.

Rome2Rio

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 212.37.186.188: 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.

Downtime

Posted by pulkomandy on Tue Sep 24 16:08:56 2013  •  Comments (0)  • 

The downtime is over, all services should now be running again. Ping me if something is broken.

Address change

Posted by pulkomandy on Tue May 10 22:42:41 2011  •  Comments (0)  • 

Following some problems with my router and DynDNS settings, the site is now available at http://pulkomandy.lexinfo.fr . Please update your bookmarks.

Hello World

Posted by pulkomandy on Fri Jun 26 17:42:56 2009  •  Comments (4)  • 

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

Everything is still work in progress, so please be patient.

Warning: this site looks simple, but it uses css3 features and some other things that require a modern browser. It was tested with Opera 10, Firefox 3, Internet Explorer 8 and Chrome 3. Anything older may not work. Don't complain, upgrade your browser or disable css.