I searched for a collection I could browse, but couldn’t find what I was looking for. Eventually, that search became an attempt to recover the artwork from the game itself. That turned out to be a bigger task than I anticipated.
|
| Small screen, familiar faces: Soulcalibur’s 19 recovered VMU characters. |
To help with the search, I developed a tool called VMU Scout. The idea was to scan game data for patterns that might represent VMU graphics and display possible matches for inspection.
A possible match isn’t automatically a recovered image. Interpreting unrelated data as pixels can produce something that looks vaguely like a picture, and recognizable graphics still need to be checked and identified.
There also isn’t a single extraction method that can be assumed to work across every game. Although the screen has a fixed resolution, the artwork behind it can be stored in different ways: as complete images, compressed data, smaller pieces assembled during play, or graphics drawn by the game’s code. Finding it involves investigating how a particular game stores and uses its graphics, rather than simply opening a folder full of ready-made pictures.
Examining more games helped reveal recurring patterns, but also exceptions. An unsuccessful scan doesn’t necessarily mean a game has no VMU artwork; it may mean the data needs a different approach.
Soulcalibur provides a good example. Recovering its character pictures involved decoding compressed data using a routine identified in the game’s own program. The resulting collection contains 95 distinct frames across 19 characters, with five poses per character. Those are recovered game pixels, but displaying the poses in a looping GIF does not, by itself, reproduce their behavior during play. The collection’s previews use a chosen viewing speed, rather than verified in-game animation timings.
![]() |
| Five recovered poses for Mitsurugi. The archive’s animated previews use an illustrative speed, not verified in-game timing. |
But the project also raised questions about documentation. Which game and release did an image come from? Is it an individual frame or part of a sequence? When does it appear during play? Have we confirmed that use, or only located the graphic in the game’s data?
Recovering a picture and understanding its context are connected parts of the work. A graphic’s presence in the files does not prove that players encounter it, and a reconstructed screen should be identified as such. Keeping source details and explaining how an image was recovered makes the collection easier to check and build upon.
It also helps to distinguish the artwork displayed on the VMU’s own screen from related material, such as the color save-file icons shown in the Dreamcast’s file manager. These can belong in the wider archive, but they serve different purposes.
The preservation goal grew out of that process. Keeping game data available is valuable, and locating, identifying and presenting the artwork within it adds another way to explore those games.
I want Second Screen Archive to be useful to people who remember seeing these graphics on their own VMUs, as well as artists who might never have encountered them. A browsable collection makes it easier to study the artwork closely and compare the approaches taken by different games.
Building a more complete gallery will require both further scouting and recording the VMU display while games are running. An emulator such as Flycast processes the screen updates sent to the emulated VMU, providing a practical starting point for observing those graphics in context.
That work would involve playing through games systematically: exploring menus, selecting different characters, loading and saving, and reaching the situations that trigger particular displays. Recording the main game alongside the VMU would help establish what caused each image to appear, how long it remained visible and how it changed.
For more precise preservation, a future capture tool could record each VMU screen update directly, together with its timing, rather than relying only on video of the emulator window. This would help retain brief changes and clean pixel data. It would also capture displays assembled during play, which may never exist as a single finished image in the game’s files. Carrier’s health display, for example, includes a waveform drawn by the program.
Live recording would complement extraction, but it would not automatically establish completeness. Some graphics may depend on particular save data, rare events, multiplayer setups or regional differences. Standalone VMU minigames would also need an emulator capable of running the VMU’s own software. Where possible, comparisons with original hardware would help check that emulated behavior matches the real device.
The ambition is to work through the Dreamcast library systematically, keeping track of what has been extracted, what has been observed during play and what still needs investigation. That is a long-term goal, and the archive remains a work in progress.
![]() |
| A selection from the Shenmue gallery on Second Screen Archive, ready to explore and compare. |
The VMU is the starting point, but I’m working to expand the archive to cover the PocketStation and other companion devices, bringing their artwork together under the same roof.
For now, I’m continuing to build the Dreamcast collections and update the site weekly. What started as a search for a few Soulcalibur pictures has become a project about making this artwork easier to find, appreciate and document.
You can explore the growing collections at Second Screen Archive. If you remember a particular VMU graphic or know something about where it appears, I’d love to hear about it.

