Many years ago I set up a disused Pentium 4 desktop with Debian as an emulator console connected to our TV. The system served well enough – I played through all of Chrono Trigger on it, at least – but it has a particular problem, which is that the motherboard is saddled with the pathetic i740-based “Intel 3D Graphics” system from 2001.. At the time when 1024×768 was a high-end gaming resolution, this machine cannot even reach 60fps at 1920×1080 of an HD panel – certainly CPU scaling is a dead end, and in my testing even a “full screen quad” (one 1920×1080 textured 3d polygon, the “accelerated” way to do hardware scaling these days) doesn’t hit the full framerate.

Yet somehow, both Snes9x’s X11 mode and the DOSBox in “Overlay” render mode can manage it. The secret is the “Xv” or “XVideo extension”, where graphics chips enabled a specific route for sending YUV streams to the card, and custom hardware managed scaling to fill almost any screen size. This was, obviously, for video – especially DVD, which is already YUV format, the hardware offload from DVD directly into graphics card into full-screen presentation saved a lot of CPU cycles back in the day. But you could use it with anything producing a YUV format image, including games or applications: Snes9x supports it directly in the unix port, while DOSBox’s SDL1-based system uses functions that ultimately map to this feature.

I’d like to add more emulators to the system, but finding any that use this is a major challenge. Most don’t use X11 direct programming at all, instead depending on a framework like SDL or GTK to provide cross-platform support. And SDL 1.2 was superseded by SDL 2.0 in 2013: the former no longer receives maintenance and is heavily discouraged for new developments. SDL2 dropped support for YUV overlays, a relic of a bygone era before GPUs could easily manage the task. My options seemed to be:

• Add code myself to each emulator to support Xv functions (nightmare)
• Replace the computer with something newer (but why? it’s close to working as is…)

A third option occurred to me though: many emulators also can be built as a “RetroArch core”, which means the emulation guts are contained in a library, and the I/O is supposed to be handled by the “frontend” application instead. The interface between these is something called “Libretro”. Since the emulators communicate in a standardized way, and I supply the video output, could I write a “frontend” that uses legacy SDL1 and displays the frames with its YUV overlay support?

Continue reading →

Hasbro’s Em@il Games Scrabble does not come with a dictionary. Instead, checking words for validity is done by the server, and only when a player challenges a play. This was probably for a few reasons – reducing the client download size, allowing Hasbro to update it as needed, and as a safeguard to keep the word list out of public circulation.

This means I need to provide my own dictionary for Hasbro PBEM Proxy to support the game. It seemed a simple enough problem: just get a word list from somewhere, and hook it up. But which one? I started by using CSW21, the latest (at the time) list of competitively accepted words. Yet this bothered me as it seems anachronistic: the game released on Feb. 5, 1999, so shouldn’t the word list be equally contemporary?

Thus begins another great (and probably foolish) journey into software archaeology. “What dictionary were people using in 1999?” turns out to be a complicated question, due to the fact that different lists were used for casual vs tournament play, US vs UK, short vs long words, etc. and unification of these was not really a priority at the time. Plus, some of the word lists remain unavailable unless you were a paying member of NASPA or another Scrabble professional organization. Besides, even if I had the word lists, is there any certainty that those were the ones backing the Em@il Games service?

I decided to try a different approach. Presumably, Hasbro had provided the dictionary to the developers that they wanted to be used. It makes sense that they would use the same dictionary in other branded Scrabble products at the time. In 1996 Random Games and Hasbro released a version of Scrabble on CD-ROM, helmed by lead developer Brian Sheppard (who had independently created a top performing shareware Scrabble AI called “Maven” two years before, and been hired by Hasbro to run this project — after discontinuing his own version, of course!) Three years later, “Scrabble Version 2.0” came out, with a complete redesign of the UI and a higher resolution gameplay. This version did not run well on Windows XP, so in 2002 Hasbro released “Scrabble Complete”, a slight rebuild of 2.0 with XP support and a few new background images.

As these products neatly bracket the release of Em@il Games Scrabble, I sought to get the word lists from each, and see how they stacked up to dictionaries in use.

Continue reading →

Discord Minesweeper is a Perl script I wrote that builds on one of my previous projects, WebService::Discord::Webhook. It generates Minesweeper boards and posts them to a Discord channel. Each square contains a bomb, number, or blank space, made using the Emoji images. Using Discord’s “spoiler” tag (wrapping text in double pipes, ||like this||), the squares can be individually uncovered, thus making a playable game without even leaving chat.

The code is available on GitHub here: https://github.com/greg-kennedy/Discord-Minesweeper

I ran this script for a few months, posting one board a night, but users eventually got sick of it and deleted the webhook… well, perhaps there are other games that could be done this way? I think a Blackjack simulation would work: you are dealt some face-up cards, optionally some more (covered) to flip, and once you’re finished you can reveal the dealer’s hand to see who won.

An exchange on Twitter led me into a trap that consumed a week of my time – the Sega Genesis / Mega Drive version of Back to the Future: Part III shipped with a bug that caused completely wrong colors to display. Evidently the programmer(s) were confused about the proper format of color data on the Genesis. While color values should be stored in two bytes as 0000bbb0 ggg0rrr0, this game instead uses the incorrect format 00000bbb 0ggg0rrr – all values shifted right by one bit. The end result is that the game displays at half brightness, and lower contrast.

I naively assumed this would be a simple fix: in fact, some prior discussion pointed out that color tables are stored plainly in the file, and even provided addresses to fix some of them. Of course, things are never as easy as they seem. Using a hex editor I changed some color palettes, then used the BlastEm emulator (its debugger is okay) to test, and made two discoveries:

• the list in the forum post is incomplete, and I needed to do further digging to uncover the rest of the palettes, and
• even with the palettes fixed, colors still didn’t display correctly. Any code that sets the palette (e.g. when fading to/from black) still used the old, wrong format. So while the data was correct, it still displayed wrong.

At this point I decided to see how Ghidra would fare on 68000 code. With the help from some scripts from zznop (to parse Genesis ROM headers, and to generate a new checksum after modification), I spent a couple days working at a disassembly of the ROM. Ghidra works well for this, but it has some quirks: it does not properly handle 24-bit addresses, it sometimes needs a kick with the “disassemble” key to force it to parse a block of obvious code, and the “address table” checkbox on Auto-Analysis causes far more pain than benefit – don’t use that!

In the end I produced a disassembly that was quite revealing. The game doesn’t have a lot of code re-use, it was apparently written in isolated stages and then combined together at the end. Functions for palette fades and “cutscene” display are duplicated in each segment. Finding palette setting code wasn’t too difficult once a palette were found, and usually looked something like this (taken from a “Fade To Palette” routine):

...
                         LAB_0000a264
    0000a264 3c 11           move.w     (A1),D6w
    0000a266 02 46 0f 00     andi.w     #0x700,D6w
    0000a26a 36 12           move.w     (A2)=>targetPalette64,D3w
    0000a26c 02 43 0f 00     andi.w     #0x700,D3w
    0000a270 b6 46           cmp.w      D6w,D3w
    0000a272 64 00 00 06     bcc.w      LAB_0000a27a
    0000a276 06 43 01 00     addi.w     #0x100,D3w
                         LAB_0000a27a
    0000a27a 3c 11           move.w     (A1),D6w
    0000a27c 02 46 00 f0     andi.w     #0x70,D6w
    0000a280 38 12           move.w     (A2)=>targetPalette64,D4w
    0000a282 02 44 00 f0     andi.w     #0x70,D4w
    0000a286 b8 46           cmp.w      D6w,D4w
    0000a288 64 00 00 06     bcc.w      LAB_0000a290
    0000a28c 06 44 00 10     addi.w     #0x10,D4w
                         LAB_0000a290
    0000a290 3c 11           move.w     (A1),D6w
    0000a292 02 46 00 0f     andi.w     #0x7,D6w
    0000a296 3a 12           move.w     (A2)=>targetPalette64,D5w
    0000a298 02 45 00 0f     andi.w     #0x7,D5w
    0000a29c ba 46           cmp.w      D6w,D5w
    0000a29e 64 00 00 04     bcc.w      LAB_0000a2a4
    0000a2a2 52 45           addq.w     #0x1,D5w
                         LAB_0000a2a4
    0000a2a4 86 44           or.w       D4w,D3w
    0000a2a6 86 45           or.w       D5w,D3w
    0000a2a8 3c 19           move.w     (A1)+,D6w
    0000a2aa 02 46 0f ff     andi.w     #0x777,D6w
    0000a2ae bc 43           cmp.w      D3w,D6w
    0000a2b0 66 00 00 04     bne.w      LAB_0000a2b6
    0000a2b4 52 41           addq.w     #0x1,D1w
                         LAB_0000a2b6
    0000a2b6 33 c3 00        move.w     D3w,(VDP_DATA).l
             c0 00 00
...

A bit hard to see maybe, but the important parts are that it’s processing the values in B, G, R order, by using “(component) and 0111“, and incrementing if less than the desired value. This is the wrong bitmask. Changing to 1111 (i.e. 0x7 to 0xf) allows fading through the full gamut, and everything now displays as intended. I was also able to reference the SEGA logo (at game boot), which DOES have proper colors, to double-check that I had this implemented correctly.

Finding the other places in the code where this happens is pretty trivial. A search for 0x0777 or andi.w 0x07 reveals the rest. With that fixed, I regenerated the checksum and wrote a new ROM, then used LunarIPS to make an IPS patch for distributing the fix.

The last step was to port the changes to the EU version of the game. Fortunately, the data is the same, and a Perl script with find-replace made locating the offsets easy. A new IPS patch, a README file, and we’re ready to ship.

Download the patch:

All told, this was actually a fun rabbit hole to get lost in, and I did pick up a lot about Ghidra and 68000 assembly that I had been wanting to learn anyway. If only it didn’t come right in the middle of NaNoGenMo… 🙂