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 ( 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:

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.

Reviving a Turbo-XT

Posted by pulkomandy on Tue Aug 5 16:33:51 2014  •  Comments (0)  • 

How I got an XT motherboard

This week I got an old PC/XT clone motherboard back in working order.

I had this board on my parts bin for some years. My cousin had found a PC/XT on the sidewalk, probably some company threw it away when the power supply failed. Unfortunately, it came with no keyboard, monitor, or even floppy drive.

Inside the original box (a big desktop-style one) was the huge and heavy power supply, the motherboard, an Hercules compatible card, a floppy controller, an MFM hard disk and its controller card.

I had already tried replacing the power supply with a standard AT one (the connectors are similar enough) and I could hear the PC speaker beep, so I knew the POST test was passing, however, without the monitor and keyboard, I couldn't do much more. The hard drive would not spin up. I only kept the motherboard and the 3 expansion cards, and got rid of the hard drive, case and power supply.

The computer comes with an Hercules compatible video card. This is a monochrome display, but more importantly it uses the same refresh rates as MDA: 50Hz vertical and 18.6kHz horizontal. This does not match the 15.6kHz used by TVs and CGA, nor the 31.5kHz used by VGA. Attempts to use ISA VGA cards on this motherboard weren't very succesful. So I let the boards sleep for a few years in my parts bin.

Seeing it boot

Last month, the "8088 domination" demo was released. This got me thinking about this motherboard again and I decided to see if I could do something useful with it. I installed it in a baby-AT tower case which takes less space than the original and started researching a solution for using the MDA card. I first thought of connecting it to my CTM640, which is normally a 15kHz monitor, but can be adjusted a bit using a potentiometer. I had to build a sync mixer to merge the horizontal and vertical sync signals (I simply XORed them together using 74LSxx chips). I could get some garbage on screen but the sync didn't work, so it was just unreadable text. However I knoew the MDA card was worknig properly, as I could see some generated video and check the sync lines with an oscilloscope.

I started looking for scanrate converters, but it seems so far there is no cheap solution that officially supports MDA. It's possible to find some VGA to composite or VGA to HDMI converters, and I think some of these may be compatible. However, while researching those, I noticed they work pretty much like the input section of most modern LCD displays. This gave me the idea to test my LCD (which is actually a TV with SCART, VGA and HDMI outputs) to see which frequency range it would accept.

I booted Haiku and used the screenmode command to set a custom video mode using a modeline. I couldn't find the exact timings for the MDA/Hercules cards online, however they are fairly easy to compute from the CRTC settings, which I found on John Elliot's page about Hercules cards (you just multiply the character-based settings by the character horizontal or vertical size). It turns out this LCD will handle a 18kHz HSync just fine.

The next step was wiring an MDA to VGA connector adapter. The wiring is straightforward, I connected the "monochrome" output from the video card to the green channel, and the "intensity" to the red one. The VGA port should need a 0.7v signal, but it turns out my LCD accepts the 5V TTL just fine (it's a Linetech LF1912HD01, but that brand or model probably disappeared from stores already). So I could finally see the bootscreen!

User input needed

Ok, without a keyboard, being able to boot DOS isn't so useful. And as you should know, the PC and PC/XT use a different keyboard protocol from later models, so using a standard PS/2 keyboard directly is not possible.

This is a long-solved problem, with the guis at the Vintage Computer Forum having an adapter built around a small PIC12 chip. But I don't like PICs and prefer AVRs. There is an AVR version of the adapter, but the code is big and clumsy, where a small and simple one would do the job just as well.

So I designed my own keyboard adapter. The code is C and should be fairly readable. It uses the same PS/2 library I used earlier for my PCW and Amiga keyboard adapters. The lib had some problems and this was a good occasion to review it, clean it up, and do some more testing. On the XT side, things are rather simple as I just need to send the single byte keycodes with a standard clock signal. This is implemented on the XT side using a 74LS shift register, which is quite flexible on the timings.

So, I now have the adapter (named XTK) working, on two different boards I had lying around. One uses an ATMega8 or ATMega48, the other uses an ATTiny2313. You can find the code at the avrstuff repository. However, for the final version of this I plan to use an ATTiny13 and fit the whole adapter circuit inside the DIN connector. I want to get my prototyping boarsd back, and a small integrated circuit like this will be much less fragile.

While I was at it, I also replaced a burnt LED in my Olivetti keyboard. It has a nice yellow caps lock LED again. But I didn't update the PS/2 library so it controls the keyboard LEDs yet. That will come later.

Mass storage

Ok, I fitted a 5"1/4 floppy drive in the machine so I could boot DOS and test the keyboard at a prompt. This is working quite well, but swapping floppies gets annoying and I'd rather keep my other floppy drives for other projects. This PC originally came with an MFM or RLL hard disk, which was broken when I got my hands on it. Replacements are hard to find, and they are heavy and noisy. Instead, I plan to use a compact flash card. I could buy the amazing XT-CF or XT-IDE boards, but even if they are quite cheap, it's more money than I want to waste on this computer. So let's see if I can continue doing things with just my parts bin.

First, I need a way to connect the "XTIDE universal ROM" so I can access my CF card using the usual DOS interrupts. My motherboard has 6 ROMs slots on it like the original 5150 PC. Only one is used for the BIOS, the next 4 are for the IBM BASIC, and the last one is for an expansion ROM. I used this one for the XTIDE ROM. On this motherboard the ROMs have a standard pinout, so I could easily put the XTIDE universal ROM on a 27C256 chip (copied 4 times to make sure the system can see it). After some hacking on my EPROM programmer, I got it to reliably program this in the ROM. So that's one problem solved.

I also need to connect the compact flash card. It turns out I can use the IDE port on a sound card, and XTIDE can set the CF card to 8-bit mode to avoid the use of the 16-bit bus, which is of course not wired on my machine. This is the same trick I use on my CF adapter for CPC. (you need XTIDE version 2 to use this feature).

However, I need a non-PNP card with an IDE port for this to work. The BIOS doesn't know how to initialize PNP cards, and if I wanted to do it using the manufacturer provided drivers (assuming they can run on a 8088), I'd have to boot DOS first. Time to dig out that Sound Blaster 16 which is the only non-PNP card I have around. Mine comes with an IDE port which I set to address 1F0.

With the sound card and the CF adapter plugged, the XTIDE installation tool detected everything just fine and I could prepare the ROM file suitable for my machine. I saved this back to disc (my UVPROM can't be programmed on the fly on the motherboard like the flash chip on XTIDE would), got that file back to my other DOS PC where I could finally put it on the ROM. I seated that ROM in the XT and could see the XTIDE welcome message. Some FDISK later I could boot DOS from that compact flash, it works quite well and DOS boots in less than a second (but there aren't much drivers to load).

The software!

Well, now that the thing is running... what to do with it? I ran through my 5"1/4 floppies and found that a lot of the software there is meant to use with either CGA, Tandy PCJr, or some later video card. But there are some games for the Hercules card as well. Of course none of those use the Sound Blaster (even in AdLib mode), they all go for the PC speaker. I had more success with the tools such as QBasic and Turbo Pascal, but I'll probably cross compile things I want to run on the machine.

An obvious thing to do on a 8088 based machine is to run "8088 Corruption". I thought this required a CGA card, but MDA support is now available. However, and as pointed out by Trixter, I found that the Sound Blaster 16 wouldn't work on a 8088 based box because it needs some tools in the autoexec to initialize it. However, I found a workaround to this once again on the Vintage Computer forums. A simple DEBUG script can be used to initialize the card.

o 224 80
o 225 02
o 224 81
o 225 02

I added this to my autoexec.bat, and it worked! I can now use the card (as a Sound Blaster 2.0, the 16-bit DMA obviously won't work). The mixer volume is quite low, so I may have to extend this debug script or try to run one of the mixer tools if I can find one that runs on the 8088. Or I could get a Nec V20 which would run all this software fine.

Getting it on the network!

I tried using a 3Com Etherlink III as an extra extension ROM slot. That didn't work, but I stopped messing with it when I noticed that the motherboard already had a slot for XTIDE. Maybe I can add some ethernet connectivity to this machine with this card. However, 3COM tools to configure it don't seem to detect it. I may need an alternative driver that supports the 8088, just like for the sound card.


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.

Some projects

Posted by pulkomandy on Fri Nov 8 12:56:42 2013  •  Comments (0)  • 

Some time ago I set up a trac install on my server to put all my running stuff. As I ended up using the provided wiki for tech documents, there is nothing visible on this website. This article list all these projects so they are linked from somewhere, maybe this way Google will index them better.

Also, there's more on my github page, where I plan to migrate most of the stuff above, someday (because git is better, github is more visible, and Trac in fastCGI mode has a very annoying memory leak making it the first source of problems on my homeserver). There's also my Google Code Prject Hosting page, which I plan on not using anymore but there are some projects to migrate, still.

Reverse Engineering notes for ATJ227x

Posted by pulkomandy on Wed Oct 30 22:12:24 2013  •  Comments (0)  • 

This weekend I wanted to relax a bit and stop coding, so I decided to resume work on reverse engineering the ATJ227x gadgets.

You may remember I was involved in hacking with the older Actions Semiconductors MP3 players in the S1MP3 project. This never got anywhere, with more powerful hardware now being just as cheap and Rockbox being a more appropriate solution for it. Anyway, Actions Semi is not dead, and they still do some weird system-on-chip stuff. The new iteration is called G1000 and powers some cheap handheld consoles. I can name the JXD 3000, the Kulala K803, the KO W5000 and W6000, and the Juyou A320+ and S430. Never heard of them ? Well you should go buy one of those now. The cost around 30 euros, which is quite cheap, and they all share most of the same hardware: ATJ2279B system-on-chip, 480x272 LCD, USB (they act as mass storage devices), SD card connector audio out (and some of them even have video and HDMI), and a touchscreen.

As usual, besides the very cheap plastic (what did you expect at such a low price? they even added metal weights inside the case so it doesn't feel too light and crappy!), the problem with this devices is the low-quality firmware they are running. This time, instead of a completely homegrown system, Actions Semiconductor went with µC/OS II (no, this is not compatible with Linux nor Android). Anyway, when I got my Kulala K803, there was very few information available on these devices. Now they have spread out a bit more and, more importantly, Juyou made available the firmware update tool and their firmware files. I risked breaking my different console installing that, and, well, it worked. The Juyou firmware is much better than the Kulala one. I think I lost the radio support and maybe some other features in the process, but well, at least I have an useable user interface now (it's PSP-like). I can use this as a MP3 player (Ogg doesn't work with the Juyou firmware it seems), which is already a good thing, and the thing also runs GBA, SNES, Playstation games (slowly).

More important than that, I now have a firmware file to play with! Let's throw binwalk (don't use the Debian package, it's outdated) at it and see what it finds! Well... nothing. Some invalid gzip headers, no strings, no known compression format, just nothing. Not very good, but I know the firmware files for the older z80 devices from Actions were encrypted in some way. So let's try a different approach to this.

It turns out the firmware is encrypted, but fortunately still using the same system as the previous chips. Using the atjboottool done by the RockBox project allows to decode this. Binwalk is much more happy with the result, turns out is it an sqlite database. It stores some metadata, and more interesting, the firmware files. Good thing: I can spot the well-known ELF header in there. The combination of SQLite and ELF makes things much easier to understand. That's nice from Actions. It should also make it much easier to rebuild a firmware file for updating the device, should that be needed. I think it's better to look for the possibility of adding an homebrew loader like this one done for the JXD 3000. I heard the OS structure is different in each firmware version, but maybe there are some ideas I can reuse. It seems the trick to read libs from the mass storage on boot may be JXD-specific, as other consoles (at least the Juyou upgrade guide I've found) use the ADFU firmware upgrade tool over USB instead.

So let's run binwalk again on that interesting img file. Inside there seem to be a lot of ELF files, GIF and PNG pictures, as well as... another sqlite database. The "matrioshka" option in binwalk is starting to make sense. It's a plain FAT32 partition (mount on linux with -t vfat -o loop), however, the partition size is 90MB, yet the file is only 60MB. I can imagine this will create problems if you try to write to it. The structure is quite simple, there is an APP folder with the applications, and a LIB folder with the libs. The other sqlite database is actually for the english/chinese dictionnary app, so it's not very useful for us.

Each application is made of an "app" file which is actually just ELF. Some of them have resources (in res format), a stylesheet (.sty), and sometimes other resources (for example the boot logo app has two animated gif and a startup sound). The RES-file format may be similar to what Actions used on older console, so the code in s1res may be of some use. I have no idea about the STY files, however. There are also "desktop" files which are just lists of strings in different languages for the application name.

In the lib folder, there are only 4 files: applib, style, fusion, and commonui. They are all rather small (less than 500K). A quick look at "readelf -s" shows that there are some source file names information left there. I don't have a MIPS toolchain yet to look at the disassembly and start extracting actual function prototypes, however I can already tell you that fusion seems to be some 2D drawing framework (with rotations, blits, and all that stuff), applib is some kind of system lib (timers, watchdogs, ...), and style is for the UI theming, but seems to export some file I/O functions (fopen, lseek, ...). Commonui seems to be a mix of UI widgets, system stuff, and some of the emulator code (gba_* functions ?). So, no libc or other standard OS stuff here, it seems this is all linked into the apps statically.

The OS itself isn't part of that hidden image. It seems to be built from the other files in the SQLite database. init.exe seems to be interesting, and the best place to look for hooks where to insert the homebrew loader. It's an ELF file again, like all the .so (libs) and .ko (kernel modules). There are also some configuration files in there, which may allow to turn some features on or off (HDMI output, camera input, etc.). I suspect the config is used to pick the right kernel modules and leave the others out. The init.exe has no symbols, so readelf can't tell much about it. It has the usual sections for a C program built with gcc, however, but the complete lack of symbols is strange. I'd expect at least an entry point. That being said, there is a .init section which makes a good entry point as well. strings give a good indication of what it does: initializing low-level stuff (RTC, vram, ...), mounting disks, loading some libs and kernel modules, then running to run the actual application code. Interesting note: there is a kernel module loaded from /mnt/sdisk, this should be the SD card. Others are run from diska, which may be either the hidden system partition or internal memory. Running strings on the also gives a fairly good idea of what it does. mnt/sdisk is added to the path so dropping a custom app there may be enough to get it executed in place of the system ones. /mnt/remotedisk sounds useful for development, as well.

The syscfg.sys file is actually where the syscall handlers are. It's NOT an ELF file this time (this seems to be the actual kernel code?) but has helpful strings all over the place. Uli already did the work of analyzing this but he noticed JXD firmware he worked from had different numbers from the others, so I'll have to check if any of this matches mine, and else, find a way to generate the syscall file from any firmware.

If you want to play with this, I have setup a mirror of relevant files. This includes datasheets, Juyou firmware, and update tool (windows only), and I'll add more as I make progress.


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.

Amelie, a filesystem for 8-bit computers

Posted by pulkomandy on Sat Jun 8 23:23:19 2013  •  Comments (0)  • 

This is a project I've worked on and off for the past year. It all started with the MO5SD project by Daniel Coulom (French page). The idea of this is to use an SD card plugged to the tape port of the french Thomson MO5 computer, which happens to use TTL logic levels.

I reused the ideas from MO5SD to build a similar interface for the Amstrad CPC printer port. However, the Amstrad operating system has better capabilities than the MO5 one and is friendly to expansion ROMs. This makes it possible to run a full-blown filesystem rather than a simple bootloader like the MO5 version does.

Getting the SD card read/write code working was the easy part. After spending some time (with help from SyX and Cloudstrife) optimizing the z80 assembler code for SPI bit banging, I started looking for a suitable filesystem. The most common floppy disc ROMs for the CPC are AMSDOS (the one that shipped with the machine) and Parados, which improves support for dual side, 80 tracks floppy drives from PC. None of them easily allow to reroute disk access to anything else than the floppy controller. I heard that RODOS, a less known disk ROM, has such a capability, and that it also has directories, permissions, and some other nice features. However, close inspection of the RODOS ROM showed that there is actually no way to redirect disk access to anything else than the FDC (if you know a way...)

Moreover, the RODOS filesystem design looked like it would be slow. My bit-bang access to the SD card doesn't go very fast, and jumping around between several sectors isn't a good thing. I wanted to keep files without too much fragmentation so I could load them fast. RODOS is also limited to 20MB volumes, which sounded huge in the 1980s but felt ridiculous for my 4GB SD card. Finally, RODOS requires some RAM, and any ROM that does that on the CPC reduces compatibility with some software.

So, I decided to design my own filesystems. The goals are simple:

  • Use as few RAM as possible. AMSDOS allocates a 2K buffer, that should be the only space we are allowed to use (and some stack, of course).
  • Limit access to the storage medium whenever possible. Try to not read the same sector multiple times.
  • Allow the use of big drives. This requires directories, and also some other tricks.
  • Be z80-friendly. No 32-bit math is ever done.
I worked on a C++ version first. This allowed me to keep the code readable while I experimented with various things. I did all the testing on PC and will start converting the whole stuff to z80 code only when I'm fairly sure there won't be big changes to it again.

An SD card can hold up to 4GB of data. I decided to split this into 256 volumes that map to the CPC notion of "users". On an AMSDOS floppy, each file belongs to a single user and can't be seen by others. This limits each user to 16 megabytes of data. Since the files are allocated on 512-byte sectors, these can all be addressed with a 16-bit offset. I also limited the number of files and directories to fit them on a 16-bit counter.

The filesystem uses a block map with sector granularity (the 16 first sectors are used for that), and a file/directory list based on extents. When the filesystem is not fragmented, a directory will use just 16 bytes of space (including the 11 character name and up to 256 entries), and a file will use a 16 bytes header to store up to 128K of data. These entries can be extended, so directories have unlimited number of entries, and files have unlimited size.

You can read more about the data structures in the filesystem readme, and also check the source code. They are both available at CPCSDK. The C++ code makes use of some C++ features such as vector, but this could easily be converted into plain C. You will also find a WIP ROM code for the z80 version, mostly done by SyX. I'll start filling it with actual disk access code someday, for now it's just managing the patching of AMSDOS code and forwarding the access to floppy drives.

GuideML AmigaGuide converter for Haiku

Posted by pulkomandy on Tue May 28 18:22:36 2013  •  Comments (2)  • 

I'm currently porting some Amiga software (namely, the ACE CPC Emulator). As usual with Amiga software, the user documentations are written in AmigaGuide. I wanted to convert it to a more usual format for Haiku users. I found some tools, but they all run only on Amiga systems. Fortunately, one of them is written in C and open source.

You can get GuideML for Haiku sourcecode at my GitHub account.

The interesting part (development-wise) of this is that I used a set of wrapper header that convert the Amiga API calls into Haiku ones. The Amiga API is based on BCPL, which predates C and has differences such as using FPutC instead of fputc, it also has extra stuff such as support for lists, and a different way to allocate and free memory (where you have to tell FreeVec() the size of the block you're freeing).

This set of header allowed me to make very few changes to the core code of GuideML. I'm also using these headers for the port of ACE, where I could getthe emulator core running quite easily in a short time.

I'm still refining these headers to remove warnings, make them C++ safe (as my user interface for ACE is written in C++) and make them behave as close as possible to the original system. I even reused parts of AROS, an open source rewrite of the Amiga OS, which aims for source-level compatibility. Their ReadArgs implementation was not too hard to port to Haiku, and now my software can use just the same smart argument parsing as on Amiga. I still have to get something similar to icon tooltypes working, however, but that shouldn't be too hard as ReadArgs can parse strings from a file, instead of the command line.

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