Gravis GrIP to HID converter

Posted by pulkomandy on Wed Oct 27 17:51:10 2021  •  Comments (0)  • 

A few years ago (too many years to remember when I started this, in fact), I wrote down some notes about the Gravis Gamepad Pro and the protocol it uses to communicate with a computer over the simple joystick port.

Finally, I have completed the work on making an interface to use these gamepads with an USB port! The interface can handle up to 4 gamepads, and make them show as normal USB HID devices to the computer, which means no specific drivers are needed. Just plug and play!

It is based on an AT90USB162 microcontroller. I originally started experimenting with various other things, but it turns out, this old and simple microcontroller is good enough for this task, and writing the code wasn't so hard.

The schematics, PCB files and sourcecode can be found in my avrstuff repository.

It is also possible to buy boards from me if you want to, the cost is 15€ (that covers the components and PCB costs and the shipping). I made a first batch of 10 boards, but I could build more if there is enough demand for it. Just send me an email to order one. Please do not send me money without asking first, in case there is no stock available I don't want to be owing you money for months or years. If you want to order, remember to give details on where I should ship the thing (I need both your name and your physical address).

Some random thoughts about XMPP spaces

Posted by pulkomandy on Tue Aug 17 17:58:46 2021  •  Comments (0)  • 

You may or may not know I am involved in XMPP in a way or another for some time. Recently I have started work on Renga, an XMPP client for Haiku, and participated in an online meeting and discussion about why Discord is so succesful and what ideas XMPP could borrow from it. A part of the discussion revolved around the way Discord organizes multiple channels in a "server" and how that fits very well with their user base.

Today someone contacted me and shared a work in progress document about XMPP "spaces" which is an attempt to see how something similar could be made in XMPP. I was surprised to see the document dive straight into discussion about protocols and stuff like that, with the UI/UX part being "TODO write this later". I am not sure this is the right way to design the thing. I was asked my input on it, so here it is. I have not a lot of experience of the XMPP protocol, but as a user, I chat on various systems with various people and there are several instances where I can see an use for such things.

So, let's tackle this from the user experience point of view. I will completely ignore the "but how do we do that?" part and focus on what I think could work well. Let's start by going back to basics and define some use cases. Why do we want to do "Spaces" in the first place?

Use cases

Let's imagine that XMPP is a very popular protocol and everyone uses it. No other chat system exists anymore. Let's see what it did to become so succesful. I will take my own usage of various IM networks to see how this could look in that alternate (or future?) world.

Communicating with my family

My parents are doing ok with phones and computers, but still, let's keep things simple for them. A single chat channel and ability to send 1:1 messages will be enough. A media library archiving all the pictures and links we sent to each other could be nice. There will be almost no movement of users joining/leaving this space (maybe a new girlfriend/boyfriend joining the family or leaving after a breakup once every few years?), and everyone can be a moderator or it could be just one person.

I think that was the easy case which is already mostly covered by existing options

In the office

I am working remotely this year and in our company this meant reviewing and improving our chat system, which we now use a lot.

I work in a company that has in total about 800 employees, of which 150 in the local branch I work at. We are software engineers and developers. We work on many projects for different customers. Each team is typically 3 to 30 people (with sub-teams in the largest teams). We also have some people who need to do things for many teams at once (for example our sysadmins are taking care of services and tools deployed globally or specifically for a given team).

In our current chat system, we have one single space for the 150 persons in the local branch. Each project has one or more private channels, which are not listed anywhere in the UI. When people join a project, their account is invited to all the corresponding channels. This works quite nicely for us and there doesn't seem to be a reason to group channels together here.

What we would like to have, however, is a way to create temporary sub-channels for discussing specific issues. Something that would be similar to an e-mail thread. Slack and Zulip are examples of chat systems which allow this. Zulip is very close to the email way, having separate threads at the core of its UI. In Slack, it is done by picking a specific message in a channel and replying to it, which creates a sub-discussion. This would be great to organize our chats and more easily keep the info we need.

Other nice to have features are a way to search for old messages in a specific set of channels (but probably this doesn't need to have them formally tied together as a "space"), and a way to pin things (mainly URLs or file attachments) to be able to find them easily. I can imagine also more advanced features such as a shared calendar to place our meetings and days off work in.

Probably, larger companies will want a more segregated system, and I can imagine companies which have non-computer-inclined people (not software engineers) may need some more centralized admin roles to oversee who has access to what. So that probably means accounts tied to some LDAP server, not being able to list MUCs unless your account is added to the appropriate space, and not allowing people to leave a space on their own because they would be unable to re-join it.

Opensource projects

I contribute to a lot of projects, some large, some small.

I will not go on for very long about the small projects because the existing solution (just a single MUC) is just fine for me. So let's see about the larger ones which have a need to split their discussion into multiple aspects.

So, in this case, the main thing to think about is onboarding. If you don't care about onboarding, you will be just fine with a dozen independant channels which have no apparent relation to each other, except they are listed together on your website, and maybe they all have your project logo or some variation of it on them. If you care about onboarding, you want to make it easy for a newcomer to click on a single button/link and immediately join your Space and discover all the channels from inside there, in their favourite IM client.

You will probably want some kind of "backstage" channel for moderators to discuss ongoing issues. This should not be visible to regular users, of course. Which means multiple channels in a space can have different access rights. On the other hand, you may want to nominate moderators and automatically allow them to be moderators on all the channels. Speaking of moderation, you also want the ability to kick/ban someone from the whole space if they misbehave.

As an opensource project, you want to be transparent and have an archive of everything that was said and shared, possibly over the course of decades. This includes channels that are currently unused because the project was reorganized. Possibly you'll want to split the history of a space because one project was split into two separate parts. You may want to copy it to create a fork of the project while retaining the past history in both branches of the fork. And you may also want to merge the history from two projects together and form a single space, but probably I'm going a little crazy here.

You also want to preserve the privacy of your users. It should not be easily possible to identify that user A in space X is in fact the same person as user B in space Y, if they decided to use different nicknames in each place. On the other hand, you want to be really sure that if you talk to someone named "user A", it is really them, and not some other person using the same nickname.

Another aspect to think about here is notifications. For high traffic channels and projects, probably I won't read everything. I will have the chat client on my computer and read it when I have time or maybe if someone pings me. But I don't want this to ring my phone everytime something happens. It should be a distraction free thing that I can have running in the background. This mean I need easy configuration for which notifications I want on each of my clients. I think both for the whole space, and for specific channels (there may be some channels I have no interest at all in following, maybe because they are in languages I don't understand, maybe because the project is large and some topics are not interesting to me).

Chat with friends

One of my uses of IM currently is organizing board games sessions with friends (but whatever your hobby is, probably some of the same applies). Here, there isn't really a notion of a fixed "space". Some of my friends don't know each other or have met once during a board game afternoon and then never met again. Currently I have one rather large channel with a lot of people but I think I will just create and delete smaller groups as needed. In my case, a "space" is probably not useful here.

Gamer communities

I am a lot less familiar with this. I think a large part of the "opensource" section will also apply. Probably channels with restricted permissions (only a few people can talk) are needed. Also, some nice to have things: custom "stickers"/emojis specific to the server, ability to define and rename roles and assign them specific permissions, ... Just read the Discord documentation.

Chat with strangers

One place where IRC is still somewhat popular. There are chat services with various thematic or so channels (by age, location, or shared interests) all thrown together into a "space". People can join and talk with complete strangers. There are a lot of trolls and people with inappropriate behavior. Users of the service need an easy way to signal such things so a moderator can quickly intervene. If the space is big enough, there will be separate moderator staff for each channel, but probably still a common backstage channel for coordination

Thinking about the user interface

So, what do we need to put in our user interface? Here is an attempt to summarize it:

  • Single-button way to join a space
  • Ability to see a list of channels in a space you joined, with a description of what their purpose is
  • Media library with all pictures/links/? or pinned messages
  • Ability to see long term logs (multiple years) of all channels, including now inactive ones
  • Possibility for space moderators to archive a channel (only past logs available, no way to post new messages)
  • Manage permissions for a single channel and for the whole space (who can talk, who is a moderator, etc)
  • Ability to configure notifications, per-client, globally on a space and more specifically on each channel
  • Know who is joined in a space, ability to reliably ban people (in a way they can't avoid just by rejoining with a different nickname)
  • No way to identify that two users in two different spaces are in fact the same person
  • Multiple levels of administration: the owner of a space can nominate moderators for different channels, control which channels are visible to all users or to users with some specific role only, etc. Moderators can adjust some, but not all, settings of the channel they are moderating
  • Ability to join a space but only join some of the channels inside and not all

In terms of user interface, channels from the same space should of course be grouped together. There will probably be a LOT of channels so you probably won't get away with a single tree view, it will never fit everything on screen. Which means you need a first level with a list of all the spaces, showing which ones have ongoing activity. Then you can select one of the spaces and see the channels inside.

In the XMPP world, one thing to think about is how to handle things that are not in a space. Maybe they can just be put into a "default" space from the UI point of view?

If you know someone's real JID, and you start a chat with them from inside a MUC, it would be super annoying if that ended up being a separate chat history than if you contact them directly. Or maybe it's a feature to have separate discussions (let's say if you have a colleague and you talk work things, but they're also a friend and at other times you talk non-work things).

You will have some kind of management menu (maybe right click on the space icon/name) to decide if you want to leave a space, configure notifications, see who is a moderator or admin.

Obscure Soundchip Tuesday: The SGS M114

Posted by pulkomandy on Wed Jul 14 20:44:33 2021  •  Comments (0)  • 

(yes, I'm writing this article on a Monday. But the title sounded better this way. Whatever.)

As you may know, I'm interested in old computers and sound and music. Recently I was reminded by a youtube video about the Amstrad CKX100, a toy-synthetizer from 1988. I had already heard about it but never had an opportunity to disassemble one, so I didn't know how it was built. Well, this video did just that and got me curious about the soundchip used, the ST M114S. I had not heard about it before and was curious how it worked and if I could possibly connect it to a computer to play some music.

So, a few web searches later, I didn't find a lot, but I found what I was looking for: a datasheet and a research paper from the chip creators, both explaining in some detail how the chip operates.

The research paper is dated from 1985 and mentions that the chip was developped in cooperation with GEM, another synth keyboard manufacturer (who went on to use it in several of their keyboards). It was designed by SGS before merging in ST, so it was the opportunity for me to learn a little more about the Italian side of ST Microelectronics. Previously I had known them mostly for the EF9345 (used in the Matra Alice and the Minitel) and some of the chips used in the Thomson TO8 and MO6 machines, mainly the palette circuit that was developped for the TO9 but later became an off-the-shelf component in ST databooks.

The chip uses an 8KB ROM where sound samples are stored. The samples are in power of two sizes from 16 to 2048 bytes, and are played in a loop to sustain the sound. They use delta coding, which means they encode the derivative of the actual sound. An analogue integrator is used to turn this back into the original signal, which has the advantage of providing some level of smoothing of the output.

The chip does a bit more than just playing the table, however, it can smoothly transition from one sample to another by mixing them together. And it can also play the sample at various speeds by using only one out of two or one out of four bytes (but this risks having a not perfectly balanced signal, which will drive the integrator into saturation).

Moreover, it is indeed designed to be driven by a CPU. It is not a "keyboard-on-a-chip" system that would handle keyboard scanning directly and generate the sounds from there. Instead there is an interface for a normal CPU bus where you can send commands to trigger notes. The commands are made of 8 6-bit words. This may seem a bit strange, 6 8-bit words may have made more sense (especially as most of the values transmitted are indeed 8 bits), but I guess it allowed to save some pins and fit the thing in a 40 pin DIP package.

As a result, this chip was apparently used in some pinball and arcade machines. However, MAME doesn't have an emulation for it yet.

During my search for the Datasheet, I of course looked at ST databooks, and found that there is a larger version called M114A. This one has a 48 pin package, which allows to address 265K of memory instead of 8K. Surely this must allow for much more complex sounds.

Interestingly, the datasheet for the M114S shows a clever hack to increase the ROM space to 16K instead of 8. The chip has an "output enable" pin to signal the ROM when it wants to read a byte. This signal will always trigger twice within a short time since the chip will always read a byte from two samples (remember, it then mixes them together). So, they suggest connecting a flip-flop to this output and resetting it with an RC circuit tuned to a longer delay. The output is then used as an extra address bit, and as a result, the first sample will be from the first half of the ROM, and the second sample from the second half. This simulates the behavior of one of the pins of the M114A, which probably does the same without needing an RC circuit as it knows about the chip internal timing.

Of course I am interested in wiring the chip to RAM. The datasheet says it's possible, but some arbitration will be needed to make sure the M114 and CPU don't try to both access the RAM at the same time. Should I go with dual port RAM? Can I simply block the M114 from accessing the bus when the CPU wants to use it? Maybe I can do some fun tricks where the CPU manages to synchronize itself with the chip and feed it data without using the RAM at all? And, first of all, can I even get one of these chips? There seem to be someone selling them ("used") online, but will they be real chips, or will they be some random other chip being relabelled?

I'm also considering writing an emulator for this chip, just to hear how it could sound like. However, to do anything like that, I think I need ROM dumps from one or more of the original devices using it. At least to make sure my understanding of the storage format is correct. There is a dump from one of the pinball machines using it, but it is using mainly or only PCM samples, and not delta encoding.

Finally I am surprised that this chip was not more popular, for example in home computers. Ok, maybe needing a whole 8K of ROM may be the cause. But it sounds quite nicely, and it would have been interesting to see it alongside the AY3, the SID, and the various options from Yamaha, don't you think?

Programming notes

This information is directly from the datasheet, but here in easier to read HTML format.

All communication with the chip is made with 8 byte commands (only 6 bits in each byte). The bytes must be no more than 128us apart, otherwise the chip considers itself out of sync and the command is aborted.

The command layout is as follows:

2OutputT1 address MSBT2 address MSB
3T2 address LSB
4T1 address LSB
5T1 lengthMode
6InterpolationImmediateOctave Divider
7ChannelTuning LSB
7NoteTuning MSB
  • Attenuation: higher values for lower volume
  • Output: route the channel to one of the four outputs
  • Table addresses: bits A12-A4 of the ROM address to read from
  • Length: number of bytes in T1 sample, from 16 to 2048
  • Mode: various ways to access the two samples, see below
  • Interpolation: Mixing value K. The generated output is S1 * (K + 1)/16 + S2 * (15 - K)/16. A value of 15 plays only table 1, and lower values add more and more of the second sample to the mix.
  • Immediate: apply the new attenuation immediately (otherwise a ramp from the previous value is generated)
  • Octave divider: divide the frequency by two, to play an octave lower
  • Channel: channel on which the command must be run
  • Tuning: finetune the selected note, see below.
  • Note: from 0 to E, 15 possible notes a semitone apart, covering a bit more than an octave. F is reserved for special commands (See below)

The possible values for the tuning:

  • 0 to 5: detune by -6/12 to -1/12
  • 6: detune by -2/1000
  • 7: detune by -1/1000
  • 8: exact note
  • 9: detune by 1/1000
  • A: detune by 2/1000
  • B to F: detune by +1/12 to +5/12

The special commands are not related to a channel. They are globally applied

  • F8: ROM ID mode. The chip will generate addresses 0 to 8 in a loop and send them to the ROM.
  • F9: SSG, enable synchronous mode globally. In synchronous mode, frequency changes are delayed until the next loop point in the sample
  • FB: RSG, disable synchronous mode. Frequency changes happen immediately.
  • FA: RSS, invert the state of synchronous mode just for the next command.
  • FC: Keep the existing frequency from a previously played note.
  • FF: Immediately stop the channel playing.

TODO: SSG and RSG are swapped in another part of the datasheet. Check which one is correct.

And finally the modes affect how the waveforms are accessed:

ModeT1 speedT2 speedT2 length
000 /2 /2 =T1
001 1 1 =T1
010 /4 /4 =T1
011 1 1 max(T1/2, 16)
100 1 /2 T1/2
101 1 1 max(T1/4, 16)
110 1 /4 T1/4
111 1 1 max(T1/8, 16)


It turns out someone already wrote an emulator!

Next steps

I'm looking for ROM dumps of the Amstrad CKX100 (both the samples and the CPU code) so I can learn more about how it uses the chip. Anyone has one and is willing to dump the ROMs?

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 (3)  • 

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.


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.