PulkoMandy's homepage

I have a shelf of old CDs, both audio and games. Some are very common stuff and not so interesting. Others are quite a bit more obscure, for a variety of reasons:

• Audio CDs I bought at shows or from websites, that are not currently re-edited
• Various shareware compilations and tie-in discs
• Even for big well-known games, sometimes the French edition is not well archived even if the English one is

Anyway, it was one small worry in my life that if these discs would be damaged, lost, or stolen, I don't really have a backup plan. Actually, while archiving, I found some cases where the disc is missing (nothing impossible to replace, fortunately).

The other part of this problem is I had no remote backup. I used to do a "backup exchange" system with a few friends, where we would send our homeservers backups to each other. But people move on, servers go offline, and this is not available anymore. Related to that (and less so to the CDs archiving), I'd like to do more with my homeserver, but as long as there is no backup plan, and the server is a machine in my living room, the risk of data loss is just too high. So, I finally registered an account on iDrive so I can upload the stuff there. The server is now backed up, and I'm dumping the software and music there as well.

Due to copyright laws, this is a private archive for my own use. However, I will publicly list what I have. If it turns out some of this is not readily available, contact me and we'll figure out something.

I tried to do things "right", dumping ISO images where appropriate, all sound tracks as flac (both for the games and music CDs), as well as the extra content for Audio CDs. I also scanned the booklets and the disks themselves.

PC GAMES

• 8 jeux de casse-tête (Pointsoft collection of Tetris-like and other braintwister games)
• 3D Ultra Pinball - Le continent perdu
• Boston Bomb Club (edited by Pointsoft)
• Car Tycoon (French version, I remember this being unplayable due to too many bugs)
• Dungeon Keeper Gold (multilingual)
• Get Medieval (Microïds CD with Shogun, Rage of Mages, and Corsairs
• Gruntz
• Heroes of Might and Magic III (GOG.com edition)
• Hi-Octane
• Lemmings Revolution (a different print than the one available at WebArchive)
• Les fourmis - Les Guerres de l'Ouest
• Oddworld l'Exode d'Abe
• Pandemonium
• Pandemonium 2
• PC Mag hors série 21 (Shareware compilation)
• Pointsoft Jeux pour Windows (several games edited by Pointsoft: Jungle colors, Snowmanland, Lost In Time, Wizards). The games are clones of well known things (Puzzle Bobble, Dr Mario, ...), but they have decent pixel graphics and great music by then demoscene musician Traven
• Powerslide
• Q*Bert (version from 1999. My CD looks different from the ones already dumped at the web archive, I guess the French version got a different artwork?)
• Rising Lands (Microïds)
• RollerCoaster Tycoon
• RollerCoaster Tyconn: Loopings en Folie scenario disc
• Sim Tower (Maxis)
• Sim City 2000 édition spéciale Media Pocket (a low-cost re-release, including the DOS, WIN16 and WIN32 versions with SCURK and other extras. The CD includes PDF user manuals in french)
• Street Wars (Constructor 2) (Acclaim)
• The Dig
• Theme Hospital
• Traffic Giant (GOG.com edition)
• Les Super Maths (PC Junior CD #16) - A MAcromedia made game where You play X-Men characters in 4 minigames involving mathematical operations, graphs, triangles, and so on.
• Tomb Raider II
• Warcraft II Battle.net edition (in English)
• Warcraft II Beyond The Dark Portal
• Worms 2

Music

• Alternine: both the original EP and the 2.0 from the rebooted band
• André Minvielle et Lionel Suarez - Tandem
• Antoine Reneaut - En Plénitude
• Chorale Iroise - Couleurs Celtiques
• Daft Punk - Ton Legacy soundtrack
• Datarock - Datarock Datarock (EU version with extra tracks), also including the videoclips from the CD
• Datarock - RED
• Dr Wong - Heavy Metal Banania Unplugged, Tipiak, and covers of Zelda and Tetris
• Eiffel 65 and Bloom 06 - All albums, nothing very exciting here I think
• Eurovision Song Contest 2009 (CD1 only)
• Fabulous Trobadors - Ma ville est le plus beau park
• Flash (some Atari XL music)
• Flavien Berger - Léviathan and Contre-Temps
• François Hadji-Lazaro - Un recueil frais et disco (including DVD with videoclips)
• Les Frères Brothers - First 2 albums
• Guilhem Desq - Visions
• Harajuku - Just One Look (incomplete)
• La Tordue - All 6 albums
• La Patate - L'alboom (if you know French you may remember their flash animation "La chanson de la patate" but you probably didn't there is a full album)
• Les Escrocs - All 3 albums
• Les Wriggles - Justice avec des saucisses
• Malaussene - 2 albums and bonus tracks. They had these for free on their website
• Mélusine - Chansons à écouter au coin du feu (a tie-in music CD sold with a comic book. Not bad music at all from people whose main job is comic book scenario and drawing!)
• Mickey 3D - All 3 albums from a boxed set
• Paula Powered - Level Up
• Poison - The last legend
• Pomplamoose - Invisible People
• Hurricane on the Bayou (soundtrack from the movie/documentary of the same name
• Tribute to Arno (Putain, putain, une tribu pour Arno)

Playstation games

• SLES-00278-2107629 - Bust A Move - Arcade 2 Edition
• SLES-00838 - Oddworld - L'odyssée d'Abe
• SLES-01502 - Oddworld - L'exode d'Abe
• SLES-01893 - Bomberman

Software and drivers

• Akai LPD8 CD (Mac and Windows software and user manual)
• Altera Complete Design Suite 7.2 for Windows and UNIX/Linux, with Cyclone II starter kit CD
• ASUS Windows 7 Anytime Upgrade
• HP PSC1310 / OfficeJet4200 / OfficeJet 5500 printer drivers (Windows 98-XP, possibly also Mac)
• Klik and Play (French, Mac)
• La Bible PC - Programmation système - 5ème édition (sold with the book of the same name, including all examples from the book, and also a Micro Application software and book catalog with weird background music, and a low resolution version of the "Don't copy that floppy" rap clip that takes more space than everything else on the CD)
• Micrografx picture publisher 6.0 (also including ABC Media Manager, older 16bit versions of Picture Publisher, and demos of other Micrografx software)
• NetBurner support CD (this is a Motorola Coldfire development board with an Ethernet port)
• OfficeOne 7 - An office suite built from existing components (OpenOffice, Paint.net, Avast, ...) also including some games. Sold with an Asus computer back in 2008 or so
• USB to IDE driver CD (I don't remember what piece of hardware it goes with, includes drivers for various chips)
• USB 2.0 Digital HDTV Tuner
• Windows 7 Pro 64bit with Service Pack 1, French (ok you probably don't need this one...)

Wanted / Missing

Some things I couldn't archive in time... Some of this is probably easy to find, and just notes to myself to get it. Other things are more complicated.

• The Daft punk soundtrack is supposed to have some bonus on the disk. Unfortunateely, what's actually on the disk is an EXE file that will just send you to a now offline website. The web archive only has a backup of the landing page, because the actual content was behind a login wall. There were apparently 3 trailers for the movie, the videoclip for Derezzed, and a picture gallery. Did anyone doznload the pictures from the gallery or other stuff from that website?
• Complete "Just One Look" album by Harajuku
• My copy of Tomb Raider ("version longue"/extended edition) has only CD2. CD1 has been accidentally replaced by a CD of Tomb Raider II. Anyone has the matching Tomb Raider II case with CD1 of Tomb Raider 1 in it?
• Bénabar - Infréquentable, I have the case but the CD is not in it
• Petite Oreille by Boucherie Prod - A compilation CD released in 1996 with children songs by artists who don't usually do children songs. My CD is lost and this is long out of print, I'll have to locate a copy at acceptable price.

Long-winded and irrelevant introduction, like they do on cooking websites before you get to the recipe

I am the happy owner of a Fujitsu U7311 laptop. After several years of using used thinkpads, and not being happy with the new models designed by Lenovo, I had to switch to a new machine after my Thinkpad started developing some unexplained crashes, I suspect some kind of memory corruption.

I found that Fujitsu, not the most popular manufacturer, is actually still doing great machines. In fact, it was acquired by Lenovo a few years ago and it seems they took on the old Thinkpad spirit, or at least the parts that made it work for me.

Unfotunately, there is no equivalent of the thinkwiki for Fujitsu machines. This is pretty much the only downside. The customer support from Fujitsu is better than usual, with complete disassembly guides available from the support page (translated in several languages, and very well made with detailed pictures). There is also a support forum for specific questions (OK, maybe don't get TOO specific or you won't get an useful answer).

On the hardware side, I am happy with having basic IO (VGA (but the next generation U7312 removed that, oh well, I guess I could always use an adapter from HDMI or DVI?) and Ethernet ports) and I also got a docking station while I was at it (a proper one using a full docking connector under the machine, not one of these USB3 ones that I have no idea how they work). The magnesium chassis and case ensures I won't have bits of broken plastic everywhere after a few years. I also have a keyboard with a trackpoint (but you have to make a choice between that and a spill-resistant one, and I had to buy the keyboard separately and install it myself).

It is also interesting how the 13, 14 and 15 inch versions are largely identical, to the point that the BIOS image is the same for all 3. And the model numbering is also easy to follow, with one digit being the display size and the next two being the Intel CPU generation. So you easily know what you get, just from the model numbers.

Anyway, the BIOS update

The machine ships with an Insyde H2O BIOS, that is nothing unusual compared to other systems. I had two problems with the initial version shipped with the machine: boot was very slow (it took 10 seconds or so before even initializing the display), and it was not possible to switch between different displays after booting (the only way to use an external display for the BIOS was to boot with the lid closed, and then you can't use the keyboard).

The BIOS update is available from Fujitsu Support website and comes either as a "desk flash instant" or a "bios admin pack" version, but both of these contain Windows executables that won't run on my Haiku system. But it turns out that's not really a problem. The BIOS admin pack contains a file with a .bup file extension (I guess for "BIOS update package"). This can be extracted to the EFI system partition and it contains the executable that will perform the update.

So, extract the thing, copy it to the EFI partition and reboot to an EFI shell. From there, run the FJNB2E7.CAP file and let it run for a while (it takes a minute or so, be sure your battery is loaded and you are on mains power to avoid any chances of power loss during the update).

The first time I ran the executable, it did not flash anything, possibly because I had tried to run other things from the archive before (there's another executable but I'm not sure what it's for, and running it only resulted in an error message).

Anyway, run the thing, and when it's done, type "reset" to exit the EFI shell. That's it, your BIOS is updated! You can now remove the files from the EFI partition.

By the way, obviously do NOT try to install the BIOS from another machines or use tools from another manufacturer. This procedure worked for me but I take no responsibility if you break your machine, recovering from an erased BIOS is either very hard or impossible (I don't know which and I don't want to try).

Contiki is a small operating system originally developed by Adam Dunkels. Version 1.x became famous on the internets after he ported it to the Commodore 64. The system came with a small GUI and ran reasonably well. It is written in C and uses a few nice tricks to run efficiently on low memory systems.

Contiki became "big and professional", well, mostly profesionnal, and in version 2.x, the GUI was mostly removed and the fun 8 and 16 bit machine ports all abandoned. Now it is useful for actual projects, running on small sensor boards and the like.

The best place to find info about the old Contiki version is the Hitmen demogroup page. I was a bit annoyed about the Amstrad CPC port description there: "runs slowly, does not look nice, and could probably be improved. But still worth a look". Certainly the CPC deserves better. And so I started hacking. That was in 2014.

The CPC port was initially developped by Kevin Thacker, who got it running, and kind of stopped there. It was indeed very slow, but the main cause was the implementation of the "clear rectangle" function as a loop putting space characters all over the display. But I went on and changed quite a few things to get it to look better, be faster, and saved several kilobytes of RAM (partially thanks to improvements in SDCC, and partially through rewriting more of the UI code with small assembler parts, adding missing "const" in various places, etc).

I also simplified the build quite a bit, in particular I had to rework the generation of symbol definition files that are used to link the loadable PRG files to the Contiki kernel. On the CPC port, these files are generated from the SDCC generated mapping files, now using some SED scripts to convert them to the appropriate format. I also made several adjustments to use newer SDCC versions over the years.

Later on, I also ported Contiki to the Bitbox console as well as the VTech V.Smile. The V.Smile port is still unfinished and waiting for the development of a proper toolchain for its unusual CPU, more on that later in another article.

Anyway, this brings us to today where I finally decided to update the port to use the latest version of SDCC. The SDCC compiler changed their calling convention in version 4.2 and finally added a way to pass parameters to functions using CPU registers. Before that, they were pushing parameters to the stack, and making that more complicated by insisting on pusing only 1 byte, when there are no instructions on the z80 to do so (PUSH and POP always work on 16 bit register pairs).

This, of course, requires all functions written in assemby to be updated. But before I got to that, I had to fix a patch to SDCC. One specificity of Contiki is its ability to load programs at arbitrary addresses in RAM to execute them. On a modern machine, this would be handled either by using the MMU to provide a fixed memory layout to the program, or by compiling the code as "position independent". But none of these are available on the Z80 CPU (well, you could, with a lot of custom hardware, but not on an Amstrad CPC at least). So, Contiki has to "relocate" executable, that means, after loading them into RAM, patch every address referenced in the code to adjust it for where the program was loaded. Fortunately there is some support for this in SDCC and Kevin provided a patch to generate a relocation table that lists the places that need to be patched in the final binary of each program.

I have kept this patch up to date with the current version of SDCC over the years, and version 4.2 needed a new change. It internally represents addresses as 24 bit instead of 16, I guess to allow support for banking. This resulted in corruption in the generated .hex files, and a bit of confusion until I managed to convince SDCC buildsystem to generate binaries with debug info for the linker, so I could look at what it was doing. It took a bit more guessing due to Haiku debugger not showing the value for global variables yet, but eventually I figured it out.

The next step was fixing a segmentation fault in the compiler. Fortunately, I could locate an existing bugreport with a fix, and apply the changes to my version of SDCC to avoid the problem.

And finally I could get to the part where I have to adjust all the assembler code to the new convention. Several of the functions could be simplified or even removed completely (when the calling convention matches that of the CPC firmware, it's possible to call directly into the firmware).

Converting the functions was not too hard, despite me making some stupid mistakes (don't pop something into a register if you need the value that's already in that register...) and having to fix another place where a function corrupted the IX register while SDCC didn't expect that (since it's the frame pointer, it assumes all functions preserve it, including ones written manually in assembler).

In the end, Contiki is now running fine with SDCC 4.2! I then tried to turn the optimization level (max-allocs-per-node) way up to 20 million and let things compile for a very long time. But this failed, the compiler generates instructions that the assembler doesn't accept because they are undocumented opcodes (that exist in the z80 implementation, but were not mentionned in the official documentation and removed from later CPUs like the z180).

So for now I have turned that back down, and I will test again in SDCC 4.3 where support for undocumented opcodes will be official and toggleable with a command line switch.

In the end, this new version of SDCC allowed to raise the free space in RAM with Contiki running from 24 to 26K, which is not bad at all! And there would be ways to free even more, by moving the Contiki Kernel to a ROM or using the RAM banks of the CPC to not have the code and the framebuffer share the same 64K space.

... so a few days later I did just this. It took some bug hunting and some not so clean tricks to get the file generated the way I wanted, but Contiki is now a ROM. Which means the free space is now 37K out of a 41K "heap", when the desktop and the "memstat" apps are both running. This is possible because the ROM uses the same memory space as the framebuffer, and so, suddenly there is 16K more of address space to use.

I think I could also implement a proper GUI driver that is not restricted to simulating a GUI from textmode. It could be made to look quite a bit nicer with a smaller font, and not being restricted to 8x8 pixels character blocks with only 2 colors for everything, and also make it use an overscan display instead of just 320x200. That would require moving the apps to memory bank so most of the main memory can be used for the display. But I already planned that when I started working on Contiki 10 years ago, and I have not started it since. And I think it's time to move on to other projects.

I still had two bugs to fix: during startup, there were some things written to the framebuffer that shouln't be there, meaning the linker somehow put non-const data in the ROM. And, the icons on the desktop are not loading. These two were related, it tuns out I had added a "const" to the icons to workaround a problem with the generation of the DSC files (these are files with just the icon data, used to quickly show the icon directory in Contiki). And so they were in the ROM, but adding an icon to the desktop actually writes some things in the icon data structure... So I made my hack a bit more complicated and now it's working fine.

While investigating this, I also found that the borders for some windows did not stop drawing where they should, and continued all the way to the bottom of the screen. I'm not sure if it was a compiler bug or a mistake in the code, but I have rewritten the code in a slightly different way and it's working fine now.

So, it is time for a new release of Contiki after 5 years of doing nothing, and two weekends of hacking!

Download Contiki 1.4 for Amstrad CPC. You will need to flash the ROM to any ROM slot, and put the DSK in your disk drive. Then type |CONTIKI to start the OS. Enjoy!

Get the sourcecode using Git if you'd like to help with this project or have your own fun experiments with it. I don't know when I will look again into it!

I have also submitted the patches for Haiku support to the SDCC team, and we are discussing which of the changes are useful to merge on their side. Kevin's relocation patch has a known bug, that will need to be fixed before they accept it upstream. Unfortunately, fixing it requires some changes to the way the relocation info is encoded. I'll see what I can do about it.

I also found bugs in the ACE CPC emulator (setting the PC register from the Z80 editor window actually sets IX instead?). So that's another bug fixed in ACE and I should look into that as one of my next projects. I want to do a point release of it with a collection of bugfixes, and port and publish all the ACEpansions that are available for the MorphOS version now. Oh well, the TODO list never really goes down!

That's it. I'm off Twitter now.

I used it for 5 years. I now have archives of everything I posted there.

Now you can find me on Mastodon instead. See you there!

I made this as part of my work on porting ACE to Haiku. ACE originates from MorphOS, and so it uses "catalog" files for internationalization in the format used there. The format is based on the IFF container typical on Amiga originated software.

Since the Haiku version of ACE uses pretty much exactly the same strings as the MorphOS version, it would be silly to have to re-translate all the strings. So I made this add-on to Haiku locale kit to handle catalogs in the MorphOS format.

At the moment this is not useful to any other software than ACE. However, maybe someone will find it useful. The format is a bit different than what is done in Haiku. In the Haiku locale kit, the original (usually English) string is used as a key for translations. This requires hashing the whole string, which makes everything a bit slower. It isn't very noticeable on modern machines, but it is definitely part of what makes Haiku slower than BeOS. On the other hand, the format used on MorphOS assigns an integer to each string, which can be used to refer to it efficiently. It still provides fallback strings inside the executable, so if there is no catalog, things will still work.

Maybe we could use this format more on Haiku and get better performance. But it would require a lot of changes to the tooling built around the existing format. Maybe a project for later...

You can get the iffcatalog sourcecode:

• IFF catalog 0.4 source archive
• Browse git repository online

If you want to simply use it, the binaries are available in Haiku package manager.

Version history:

• 0.1 - 04/2015 - First public release
• 0.2 - 11/2017 - Skip '\0' in translated strings (used for keyboard shortcuts on MorphOS)
• 0.3 - 06/2020 - Fix catalog search directory
• 0.4 - 02/2022 - Add a python script to generate locale_strings.h from catalog definitions

This project started by breaking old hardware. A few years ago, I started experimenting with designing hardware expansions for the Amstrad PCW. I had some success previously with the Amstrad CPC, surely this couldn't be so different? And it's a kind of interesting machine, with lots of RAM (for an 8bit system) and a quite nicely designes ASIC which would make programming it relatively nice.

My hardware experiments, however, did not go so well. First I got just a motherboard, and I hacked up a way to connect it to an Amstrad CTM and hooked a floppy drive. It worked, but only for a few minutes. Some time later, I did this again, but I checked the machine service manual more carefully and found the explanation: the video output is straight from the ASIC, and is not designed to handle the load of a typical CRT display. The PCW internal display has a buffer, but it is not on the motherboard, for some reason it is on the CRT/power supply board. So I replicated this buffer in my custom computer, and all was well. But then it broke for some other reason.

I mentionned this on a CPC forum and explained that I didn't really want to get into PCW things anymore because of breaking so many of them. But someone really wanted me to do new hardware and sent me yet another one, this time a complete machine with floppy drives and CRT display. I started working on the hardware again, and the machine self-destructed the moment I tried to probe my hardware with an oscilloscope.

So, here I am with a dead motherboard in that machine. The CRT and power suppy are still working fine and I wanted to reuse them. So the idea became to design a new motherboard to fit in there, and interfacing at least with the display, and maybe with the keyboard and the floppy drives.

I started to look for suitable options. I thought it would be nice to do a board I could hand-solder myself, but I don't want to use obsolete, not in production anymore components (let's keep those for fixing existing computers). And it turns out it is not so easy to find modern hardware that can interface with floppy drives and 15KHz monochrome displays, who would have thought?

So I started looking for system-on-modules instead. The idea being that I could find a cheap one, and then design a baseboard for it that would fit inside the PCW.

My choice eventually landed on the Lichee Zero from Sipeed. It is based on the Allwinner V3s chip, which is in itself interesting because it is a QFP package and integrates DRAM in the chip, so you don't need much internal components. Well, it still has a pin spacing that a bit too low, and a bit too many pins, so I probably won't handsolder one myself, but it would be possible.

The Lichee Zero is a board with the CPU and the needed power supply circuits, and a minimal support: one LED, one micro SD slot, one USB port. Everything else is available on castellated holes all around the board with a 1.27mm pitch. It appears the initial idea was a 2.54mm pitch you could use on a breadboard but they included extra pins in half-steps in between.

Anyway, I ordered two of these and proceeded to let them sit on my desk for a few months. This weekend I finally decided to… start a completely different project with them!

The problem with this board is there is really not much you can do with the bare board. You don't have access to a serial port or video output (well, there's a connector for an LCD but I already gave the one compatible LCD I had to someone else who wanted to interface it with an FPGA). And so you really need a baseboard to get started.

So I started thinking about a simple board exposing most of the IOs in a convenient way. I found the schematics from Sipeed for the Lichee Zero and the baseboard they offer for it, and based my work on these. But I added a VGA port, which the original Lichee Zero desgner offered an adapter for, but there are no schematics for that and no one is selling it. I hope my version will be close enough, it is based on a similar adapter designed for the Raspberry Pi.

During my research I found that the Allwinner V3s chip used on this board is now obsolete, and has been replaced by te V3x. I think when I bought the boards, there was not much known about it. Or maybe I didn't know how to search for it. Now there seem to be a community of chinese hackers at the whycan.com forum working on custom boards using it, and having some success running Linux on it, including apparently a NES emulator with a 6502 CPU core written in hand optimized ARM assembler.

Anyway, in about a day I designed and routed my own baseboard. That would have been simpler if the Lichee Zero had a more standard connector for attaching to a baseboard, but apparently the Lichee Zero Plus, which would be exactly this, is not available. So I had to design my board with a weird shaped cutout in the middle and hope that the Lichee Zero will fit there and align with soldering pads.

I have included the follwing features:

• On board USB to UART
• Ethernet port
• VGA port, with the possibility to connect the DDC lines to the I2C bus on the V3s
• USB host port (for gamepad or keyboard or...)
• Audio jack output
• 4 keys connected to the KEYADC pin (I didn't know what to do with that pin anyways)
• Expansion connector with easy access to all the remaining pins

The SD card remains on the Lichee Zero module.

In the end the whole project is a bit silly: I started looking for a hand solderable chip, I didn't find one, I picked a system on module with a really strange motherboard attachment scheme, and one that still had a mostly-solderable chip on it even if that didn't matter. And I did not end up designing what I initially intended to do.

We'll see where to go from there. For the PCW project, I have now concluded that a system on module makes sense, because it avoids me doing all the tricky power supply part and also means I don't have to make a huge 4 layer board (it seems hard to route all the needed things for the chip, even the V3s or the V3x, on a 2 layer board). The chip is also strangely balanced, with a 1.2GHz core, but only 64MB of RAM. I don't know if Allwinner will continue doing these chips with a not-so-large amount of DRAM built-in. The new generations of "Lichee" boards from Sipeed appear to use the Allwinner D1, a RISC-V chip with an external 512MB DRAM, and also a somewhat more reasonable form factor (it connects to two side-by-side M2 slots, but of course not using them with the standard things you'd find on an M2 pinout. It also apparently has direct HDMI output, which is kind of nice. But then it's maybe not a thing I can design a baseboard for in just a day.

Probably as usual with these things, by the time I finally order PCBs, and fix all issues in the first batch, the Pi Zero will be all out of stock. Maybe I will never get to build more than 2 machines, and then no one will really write any serious software for it.

Oh well, another week-end where things didn't really go as planned. But I made things work in the end.

So, the goal for friday evening was to assemble and test the final version of the Amstrad PCW keyboard to HID adapter I designed. The first version had a stupid mistake (I put the DIN connector backwards) and so I had to order a new batc of PCBs. On the first one I assembled, I was not able to program the microcontroller. So I assembled a second one, and hit the same problem. I did not spot any obvious assembly mistake (chip in the wrong orientation, short cicuits, ...) so I started suspecting a PCB design error. But, triple checking my schematics revealed nothing.

I started probing around with my scope, and quickly found that the quartz that is supposed to clock the circuit wasn't getting any movement. This circuit uses the AT90USB162 microcontroller, which is a bit special because it comes pre-flashed with an USB bootloader. For this to work, it requires an external clock, and the chips should be pre-configured to use a 8MHz quartz (what I have on the board). But, it seems they didn't.

The problem is, the ISP programming usually used to program these chips require the chip to have a working clock. Without one, the chip won't answer. The "proper" way to program these chips would be with a high voltage parallel programmer, but I don't have one that can accept these TAFP chips (especially not after they are already soldered onto a final PCB).

Before and after reaching to this conclusion, I did various experiments, one which involved trying to update the firmware on my USBASP (that I don't use much anymore, since I have an STK500 board) because avrdude complained that it couldn't control the SCK speed. That USBASP is one from Jyetech, and I noticed that it uses an ATMega48p, which is not one of the officially supported chips for the USBASP firmware. I tried flashing it with the ATMega48 version of the firmware and that bricked it.

I also tried ressurecting my older USBASP, one that I built myself with a PCB that was engraved by a local electronics shop near my parents home (yes, surprisingly they live in a relatively small city that somehow has TWO electronics parts shop, one of which would do PCB engraving, ROM programming, and other stuff on-demand, which was hugely convenient to me as a teenager trying to do electronics).

I put an ATMega8 back into that old thing, and got it back to the state it was when I last stopped using it: the USB interfacing works, but it does not detect the target device for some reason I can't find. And, more annoyingly, despite having the latest firmware, avrdude still complained that it couldn't configure the SCK speed.

Anyway, I figured out I should stop messing with these things and stick with the STK500 (and since we are talking about all my AVR programming tools: I got this one when a company I used to work for moved to a new office, and decided to throw away a bunch of unused equipment and parts). I wouldn't pay the full price for it, but it has been extremely useful.

Anyway, so, it looked like the chips were not getting any clock. I could think of two explanations: my quartzs were not working, or the chip were misconfigured. The first idea was easier to test: I put one of the quartz in the STK500 quartz socket, and could quickly confirm that it was generating a perfect 8MHz signal. So the quartz seemed OK. That left only the second option. Thinking about it, the obvious way to have one of these chips not clocked is to configure it to use an external oscillator instead of a quartz. All other settings would result in some sign of life at least.

Looking at my test crystal on the STK500 board, and re-reading the jumper settings and manual for the board, I realized that this quartz circuit on the STK500 is there precisely to help getting out of that situation: the board normally sends a clock signal to the chip being programmed (on one of its onboard sockets), so, even if the chip is set to use an external clock, it will work.

I added a wire to connect the oscillator output to the quartz on my board, and that was enough to get things going. I could finally reconfigure the fuses to the normal setting.

I was not fully out of trouble, however: some confusion resulted from using the online AVR fuse calculator, which somehow has the incorrect default values for the fuse bits for this chip? That was apparently copied into one of my makefiles, and I ended up setting the chip into an invalid state again. This time, my software was running, the clock was running, but still I wasn't able to change the fuses! Finally I managed to get out of this by shorting the HWB and RESET pins to ground, forcing the chip to enter bootloader mode. From there, I could flash a working version of my code. But I still had the wrong bootloader.

See, the idea with these adapters is that they are small. For this reason, I didn't want to include the HWB and RESET buttons as you'd normally do. Instead, the controller detects if a PCW keyboard is present, if not, it goes to firmware upgrade mode. This means the bootloader can be entered without any extra buttons.

Eventually I figured out what was happening (I think?). The chip was running, but the CLKDIV8 fuse was set, meaning it was running quite slow. This is fine for my code, but the ISP programming needs to be adjusted. To do this, one has to use the -B option to avrdude to force a slower clock. Doing that, I was finally able to flash my modified bootloader and get the thing working as I wanted.

Conclusion

I bought these chips back in 2021, during the parts shortage. At the time, they were out of stock on the usual suppliers and so I turned to utsource. This had two consequences: I have no idea where the chips actually come from, and, since I had to pay more for shipping than parts, I ordered a relatively large number (20 or so, more than I needed at the time).

What happened to these chips before I got them? I don't know. From the chips in this batch, a few were fine (the first 5 or so I used didn't give any problems), several but not all had the clock fuse problem, and at least one has a persistent write error in the flash.

My guess would be that these were chips that didn't pass tests at the factory, but with the parts shortage, someone decided to sell them anyway?

It is not the first time I run into problems with parts from UTSource, last time it was some GALs that I was not able to program at all. These came with stickers on top, meaning they were already programmed with something, but I think the offer on UTSource correctly listed them as used and I kind of accepted the risk.

Anyway, a weekend wasted in rescuing these chips, but it mostly worked in the end!

You can reach me in various ways :

• Mail : pulkomandy@this server
• XMPP : pulkomandy@jabber.fr
• IRC : PulkoMandy@ OFTC, Libera chat, IRCNet
• Mastodon: @PulkoMandy@mastodon.tetaneutral.net

It is one of these weeks where nothing goes as planned.

Rabbit hole level 0: I wanted to write videogames

For some time now I've been part of a team trying to better document the VTech V.Smile console and make it easier to write games for it. They contacted me because I had some experience (and blog articles) about other VTech hardware.

The current efforts are documented in my VTech wiki. Most of the work was already done several years ago: datasheet and schematics were found, hardware was documented, games were dumped, emulators were written. But there was no documentation and no opensource tools to build new games, or at least, nothing quite production-ready. The only option would be the compiler suite provided by the CPU manufacturer (this is a custom CPU core, used in a few other game consoles).

So, after writing the documentation in the wiki, I started to experiment with writing an assembler and compiler. I initially started looking into vasm and vbcc, because my experience with these in the past had been rather good. The developers are helpful and the code is understandable by me and designed to make adding more CPU architectures easy.

Rabbit hole level 1: I need a C compiler

I quickly ran into problems with vasm, however. The CPU in the V.Smile is a purely 16-bit thing, which means it can't address individual bytes. While vasm has some support for this in the code, it was never used, and in fact, does not work. I discussed this with the vasm developers, and the solution they suggested is that all addresses in the assembler code should be prefixed with some special character, and the assembler frontend can multiply or divide them by two as needed.

I looked into that, but decided it would make writing assembler code more complicated and annoying than needed, as there is a risk of forgetting the marker and suddenly having your address all wrong.

On vbcc side, I did not have much problems, the porting guide is very complete and there is not too much work needed to get a basic version of the compiler running. But, without an assembler, it is not very useful. I did some experiments with Mikke Kohn's naken_asm, which has support for the UNSP CPU used in the V.Smile, but it is a simple assembler that can only directly generate a final binary. It has no support for temporary .o files and a linker. So in my tests I had to let the compiler generate assembler files and not assemble them, and also generate them in a way that they could be concatenated together at "link" stage before being assembled into a binary.

I got this to work for simple cases, but it is not great to work this way.

Rabbit hole level 2: I need an assembler and linker

I let the project sit for a while (I think it's been about a year?) hoping that someone else would do it(tm) or I would find a more suitable assembler somehow. I looked into ASXXXX, but this looks somewhat limited and not super easy to port.

So, eventually, I decided, if I'm going to port somethign not super easy, I may as well go for the Real Thing, and port GNU binutils. My research showed me that there is a porting guide, even if it's fairly short. And I think I have spent enough time doing low-level stuff (compilers, assemblers, wriing linker scripts, baremetal programming on AVR and ARM) that this should be within my reach. And so I cloned the git repository and started following the guide.

After just a few hours, I had something compiling and generating various executables: assembler, ar, objdump, etc for my architecture. I don't expect any of these to actually work, I started by just filling in empty functions and adjusting the buildsystem to get it to compile all things. The idea is then to run each of them, find what doesn't work, and add the missing functions as I go.

Binutils comes with a test suite, so I thought I would start by running that, look at all the failing tests, and fix them by adding bits of the code for my port, looking at how it's done for other CPUs.

Rabbit hole level 3: running the binutils test suite

This doesn't look too complicated: install the needed software, run "make check", investigate and fix bugs, and repeat.

So I went ahead and installed DejaGNU and expect which form the base of the testing framework. I then ran "make check" and… the testsuite immediately failed.

I had not heard of DejaGNU before, it seems to be a set of extensions to expect used to run tests on cross-development environments, typically, compile software on one computer, run it on another, and check that the results are as expected. I am not sure if anyone else uses it outside of binutils and gdb.

In any case, it is written in expect, which itself is written in TCL. And in the binutils case, it is also intertwined with the binutils build system which is written using autotools (and a specific version of it).

Rabbit hole level 4: learning to use expect

So my next step was trying to run a simple "expect" program. I quickly found that expect was completely broken, and it was a known problem with a bugreport opened at Haikuports since 2021. I have not mentionned that I am doing all this using the Haiku operating system, I would not run into these problems if I had chosen a more stable and finished operating system. But where would be the fun in that?

Anyway, so expect doesn't know how to open a PTY to communicate with another process (which is the main thing it is designed to do: spawn a process, read its output, match that with some regular expressions, and reply with some input according to a script).

A quick look at the code and buildsystem helped me find the problem: expect can handle many ways to open PTYs, and on Haiku, the preferred one was not picked because it requires linking an extra library that the expect configure script could not figure out. I quickly fixed that and… immediately hit another bug.

Rabbit hole level 5: coreutils

Now expect would correctly open a PTY, but it would fail to configure it. I once again dug into the sourcecode and found that it does this by running "stty sane" using the system() call. So I ran that same command in my shell, and indeed was greeted with the exact same error message.

Quick sidenote: I found the use of "stty sane" using strace and looking for calls to the exec system call. This almost didn't work: support for printing the command line of the executed command for exec in strace was added in Haiku by another developer just 3 weeks ago. So that's one rabbit hole jumped over, yay!

stty is a standard command provided by GNU coreutils (in Haiku at least, other operating systems may have their own version or one written by someone else under a different license or using a different programming language).

The expectation is that coreutils will detect and check a lot of things about the OS in their configure script while building, and compile the tools in a way that works for each system. But, they didn't handle the case where termios.h defined speed_t to be an unsigned char type. They are trying to set speed_t variables to -1 and later compare them equal to -1, and due to integer promotion rules in C, this is not the case. If someone is trying to tell you Javascript makes no sense, if you want them to go away, tell them about C integer promotion rules.

Anyway, I added the missing type cast, and stty started working. I thought I was finally ready to go one level up the rabbit hole towards the surface. I was wrong.

Rabbit hole level 4-and-a-half: expect again

I installed my newly built coreutils on my system, ran expect again, tried to run a child process, and this time, not only expect would start, but I managed to read the output from the launched program.

I then returned to the binutils test suite and ran 'make check' again. This time, it ran 2 tests, and the 3rd one made it stop waiting for something. I was a bit annoyed, not only because I had already fixed more bugs than I wanted to, but also because I was not too sure which part of the stack was wrong this time.

Eventually I found how to enable expect debug mode, and found which command it was running. I confirmed that the same command, ran standalone, returned immediately and with the correct results. So that wasn't a problem and I turned my attention to the test framework.

I studied the DejaGNU script for the failing test, and, while it took some time to peel all the layers, eventually I found that it was something quite simple: run 'ar' with some arguments, wait for the command to complete, and then check the output file. The failing part was 'wait for the command to complete'.

After some more experimentation with expect, I wrote a two line script that reproduces the issue. I ran it on Linux and confirmed that it has no problem there. Since that script is short, here is a copy of it:

spawn echo
expect eof

So basically, we start the 'echo' command and wait for it to terminate. And expect doesn't noticed that it terminates. 10 seconds later, there is a timeout (that doesn't happen in the coreutils tests because they set the timeout to 300 seconds instead of 10).

I turned to strace again, but I could not see a lot more. I also tried to follow the code in expect and in the tcl interpreter, but I quickly got lost. So I opened a support request on the expect bugtracker describing my problem, and went to sleep.

The next day, I had some answers from expect developers, mainly suggesting things that I had already tried but not included in my short ticket, so I shared the info (strace output) with them. And my fresher brain after a night of sleep also helped looking at things in more details. I know that expect uses a PTY to communicate with the spawned process, and so I decided to write a simple test program to do something similar with less "moving parts" involved: spawn a child process attached to a PTY, let it exit, and verify that the parent process waiting on the other side of the PTY is notified that the child is done.

Rabbit hole level 6: PTYs and poll

So I picked an example of PTY usage and started modifying it to my needs. And, I could easily reproduce the problem. Once again I made sure to run the program on Linux and Haiku to compare outputs. On Linux, when the child process exits, the PTY is closed and the poll in the parent process is notified. On Haiku, this does not seem to be the case, and so this program remains locked waiting forever. However, removing the poll call, a read call does not block, and properly returns an end of file. So it is just a problem of notifying the process waiting on poll that the file descriptor it is waiting on is now closed.

Now the next step is to fix that bug in Haiku. And, even if I do that, I don't know if it will also fix the problem in expect, as I was not able to find where in Tcl the waiting for file descriptors is handled.

So, as of now, I don't know if this rabbit hole has more rooms for me to explore, or if I will find my way up at least one level. Maybe I will lose interest in this and do other things for a few months before I get back to it. And probably I will uncover many more rabbit holes.

Conclusion

For people who think Haiku should not be in "beta" releases, I hope this helps you understand what we mean when we tell Haiku is not finished. It is not a safe ground to build any software on. Sure, a lot of commercial systems don't do any better, or didn't in the past, but still, the other options currently available aren't that bad nowadays. And not everyone is willing to get depp into these things like I do.

For people who wanted to use my C compiler to port games to the V.Smile: well, if you don't run Haiku, you can stay compfortably at level 1 or 2 of this rabbit hole and still be of help. If someone else was porting this assembler and compiler, I wouldn't need to run the binutils testsuite and all the deeper levels could be skipped. For now, at least.

For myself: sometimes it feels like I'm making no progress, but that's not true. It's just a lot of work in directions I didn't initially plan to go in. And such things are probably helpful for future projects as well. Also: I am surprised there were not more complaints about expect not working, and about PTYs being broken on Haiku. I thought these would be used a bit more often in typical UNIX toolchains?

Today I released version 1.0 of BGhostView, a postscript document viewer for Haiku.

This software started in the late 90s as a port of a postscript viewer from UNIX/Linux to BeOS. Back then, Ghostscript did not have a cross platform API, and the BeOS port had to work with a patched up version of the Windows GSDLL API, heavily modified to run on BeOS.

I started working on it because in my past attempt to port Haiku to SPARC machines, I found that a lot of the documentation for these was distributed as PS files instead of the now more typical PDF. At the time, no version of ghostscript was available for Haiku. So I started digging and found an old port of Ghostscript whic provided a starting point, and this viewer I could use it with. But it wasn't working very well.

I then found that Ghostscript now has a slighly better API, and I could make use of that instead. So now BGhostView is running with an up to date version of Ghostscript (thanks to other people who also have postscript interpretation needs on Haiku, this was not taken care entirely by me).

I had not touched BGhostview since 2019, but I got reports that it was crashing recently. So, this week I dug into the code again and made some fixes and updates and decided to make a 1.0.0 version for all to enjoy. It is certainly not yet perfect, but for the basic needs of viewing Postscript documents, it should be fine.

This is yet another one of these applications that is currently hosted by HaikuArchives on Github, meaning it is more or less open for many people to contribute to, but left without someone to really take care of it and move it forward. Well, I guess that can be me when there are bugs to fix, but I probably won't have time to manage the larger refactorings and cleanups that would be needed: converting the UI to Haiku layout system so that it can automatically scale for High DPI displays, reindenting and reformatting all the sourcecode (it's very inconsistent at the moment, I guess most of it was written without a proper code editor that would watch the indentation a bit?), and reviewing the Ghostscript integration code to make better use of the APIs available in modern versions. Postscript isn't exactly great for that kind of usage, just figuring out how many pages there are in a document turns out to be a somewhat tricky problem.

There's also the question of wether we want a separate viewer for each document format. Wouldn't it be nice if the same viewer could do both PDF and PostScript? And what about DVI and XPS and FOP? And maybe docx and opendocument while we're at it? Could we use translators for this, so we can write the GUI once and then have all formats added to it later on? That would certainly be a cool project, but I already have many other things on my TODO list, so, not for now...

Get the sourcecode here

If you just want to run BGhostView on Haiku you can simply install it from HaikuDepot as you'd usually do.

I wrote new software today! Well, sort of.

This does not happen very often. A lot of my software work is fixing and improving existing code, and not writing new things. Maybe because I'm a bit lazy and I find it easier to fix some bugs in existing code than having to start from a blank page. It provides easier reward for me (that may not be the case for everyone, digging into an existing codebase is a learnt skill).

Anyway, so, the story is, somewhat recently (ok, actually, it's already more than a year ago), I got a new laptop. This was an opportunity to do an install of Haiku from scratch, and while doing so, I decided to go with the 64bit version. The only limitation in the 64bit version of Haiku is that it can't run 32bit software, including several applications that were compiled two decades ago for BeOS, and for which the sourcecode isn't publicly available.

I didn't think I was needing any of these applications, as, over the years, a lot of them have either been open sourced (mainly thanks to the effort of the Haiku Archives project in collecting such software and reaching out to the original authors to get the sourcecode published and/or relicensed under opensource licenses), or has been replaced by newer software or rewriten.

It turns out, one piece of software I occasionally use had not been through this yet. And so I got to work on rewriting it.

The software in question is BeDC. No, not the Direct Connect client of that name, but the rewrite of the earlier "Developer Console" (I think? it is unclear how BeDC and Developer Console are related). The idea is quite simple: this application receives text messages from other applications and logs them in a window. I discovered this software while working on PadBlocker, an input filter add-on that disables the touchpad while the keyboard is being typed on. Because of the way input server add-ons work, it is not easy to grab their output in the common way (sending it to stdout) because they run inside of input_server, which normally does not have its stdout route to anywhere.

I thought the idea was interesting and started using the app in some of my other projects, mainly in WebKit, where it was useful to collect logs from the different processes started by a single web browser instance and clearly marking where each message comes from, and in Renga, an XMPP client, as a way to log incoming and outgoing XML messages for debugging.

So, of course, on my shiny new 64bit system I did not have access to this nice tool, until now. I have rewritten my own version of it. That was made quite simple thanks to the APIs available in Haiku: the whole thing fit in about 200 lines of code. It is fully compatible with existing apps that used to target the old BeDC app, but it looks a bit nicer, thanks to the modern UI classes in Haiku. For example, when logging a BMessage, it can be shown as a nice foldable structure instead of just a bunch of lines.

I have some future plans for this, mainly to make it more useful with Renga where having some formatting of the XML would be great. But I don't know when I'll get to that. Until then, you can find the sourcecode on my Gerrit.

Please do not mirror my whole website using wget mirroring mode, WebReaper, or other similar tools. It results in a lot of requests to my poor old server, too much memory and CPU use, and the server fan spins up and makes a lot of annoying noise. So I will ban your IP or IP range from accessing the website if you try this.

If you want a full copy of some parts of the website, please contact me so we can set up a better way to share the data (I can set up an ftp or sftp or rsync thing, for example)

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.