It’s certainly been a while. Let’s take a peek into the Wonderful toolchain.

There have not been many major changes or new additions since the last update. As such, this post will act more as a development summary.

Showcase

The past few months saw a few neat things released which used the Wonderful toolchain:

• Quark Panic, joe’s new free WS/WSC game! Trap the bouncing quarks before they cause havoc!
• TamagoSwan, a port of a first-gen Tamagotchi emulator.
• Demon Cat Snatchers, a demo of Laconic Software’s platformer for the WSC.

Personally, I spent this weekend implementing the Varvara virtual machine on the console.

Transitions

Alright. Let’s talk transitions. (No, not personal ones.)

Earlier this year, I have decided to move the toolchain from GitHub to Codeberg. I appreciate Codeberg’s values and governance structure - I feel it aligns closer with the values I want to encourage as part of Wonderful. I’m happy to report that the migration went quite smoothly on Codeberg’s side, though I admit I could have communicated it a little better for my own part.

I have also finished support for moving the toolchain - by yourself, from /opt/wonderful to another directory of your choice! This required some plumbing work in wf-pacman, as well as the introduction of patchelf - as, for portability reasons, the toolchain provides its own libc and dynamic linker under Linux. Although I had hoped this would enable Android support in combination with existing AArch64 support, that is unfortunately not yet the case.

WonderSwan improvements

There has been some minor maintenance work on the WS/WSC toolchain:

• Fixed third-party include paths to conform to Wonderful’s file system hierarchy.
• libc: Added strtol and strtoul function implementations, ported from PDCLIB.
• libws: Fixed WS_SCREEN_ATTR_TILE_EX define (thanks xdaniel).
• wf-wswantool: Fixed handling of .iramc and .iramC sections.

Other changes

psxavenc has received multiple updates. spicyjpeg contributed support for parsing loop point information from input audio files, while impiaaa fixed a memory initialization bug.

toolchain-gcc-arm-none-eabi saw some work as well. In pariticular, an incompatibility between Windows-produced and Linux-produced LTO objects has been resolved¹, and picolibc type definitions were adjusted to improve compatibility between the C++ standard library and the GBA/NDS targets.

wf-pacman has received fixes to its handling of SSL certificates. It should now work correctly on modern releases of Fedora and openSUSE, among other distributions.

More interestingly, there has also been initial work on bringing up a new platform, another handheld forgotten by time - the Aquaplus P/ECE:

• wf-piecetool has been added to the toolchain. It allows packing and unpacking .pex executable files used by the P/ECE’s operating system. Thanks to the use of libdeflate, it manages to achieve better compression ratios than the official tools. It also supports both .SRF and .ELF files.
• Speaking of .ELF files, EPSON’s binutils patches for the S1C33 CPU have been ported to binutils 2.45.1. This appears to work, but has not been thoroughly tested.
• I have begun writing additional documentation for the platform over on the ObscureDev Wiki, to cover things I ran into which are not well documented in English otherwise.

However, it is too early to give the P/ECE a target or even a proper spotlight. In particular, there is no functioning C compiler that builds on a Linux system released in the past decade - GCC 2.7 is a little old, while the port of GCC 3.3.2 has a different, incompatible calling convention… and is still old. To make such a target a reality, the S1C33 backend would have to be ported to a more modern GCC version and adapted to resolve the incompatibilities. Maybe sometime in the future.

Post scriptum - The elephant in the room

There is one more thing I would like to bring up which has been weighing on me personally.

Part of the Wonderful toolchain’s goal was always to experiment with cutting edge, optimized approaches to creating modern code for retro platforms. Those of you who have been following any social media feeds in the past few months are likely to be well aware that a certain technology in the field of programming has pivoted from a mere curiosity to feeling rather overbearing since the last blog post; toolchain development is certainly not exempt.

Of relevance to Wonderful, there are now multiple projects in the retro development space which are relying on proprietary cloud-based large language models to push development forward. These projects, based on benchmarks and personal observation, appear to be getting interesting results next to their non-LLM-assisted competitors. In particular, in the GB/GBC scene, an experimental port of LLVM in which generative AI played significant role in generating code has been successfully used to build Rust code for the Game Boy in the form of ported GBDK example ROMs. There are also noteworthy developments in the 6502 scene. This is, of course, on top of projects like upstream LLVM already welcoming LLM-assisted development.

I surmise that these leaps are primarily enabled by the expertise of the people working on these projects; my goal is absolutely not to knock on that. Nevertheless, as an individual disappointed with the ethics surrounding the training process of these language models, as well as concerned about the legality of their outputs and personally offended by the inefficient, opaque, subscription-based nature of these solutions, this puts me as the steward of the Wonderful toolchain in a tough position.

More specifically, I am concerned it will become infeasible to provide the best tooling to my users without involving the project in LLM-assisted development workflows more directly, which is something I remain uneasy about at this time. This puts the project’s broader ambitions, beyond providing homebrew development support for the WonderSwan, in jeopardy. I hope to do some soul searching and find answers by the next blog post. Until then, see you!