240p GBA via Gamecube Game Boy Player on Unmodified Console

I recently bought a Game Boy Player without the start-up disc and went through this process with frustratingly little guidance available online, so I figured I'd lay it all out to save anyone else the pain and hassle:

The Game Boy Player add-on for Nintendo's Gamecube console requires a special launcher disc (Game Boy Player Start-up Disc) to function, normally, and it costs a fair bit (somewhere around $75 at the time of this writing) to get a complete package including the hardware and software disc. However, you can buy the hardware without the disc for substantially less (more like $25 at the time of this writing), since it's thought to be useless on its own. There is homebrew--known as Game Boy Interface (GBI)--that can replace the functionality of the launcher disc, but most of the ways to launch the homebrew are fairly costly ($30-50), require hardware modifications to the console itself and/or require a launcher disc of their own that can get scratched/damaged/lost and then you're SOL again.

However, there are a number of exploits available for common games, including Wind Waker, Twilight Princess and Smash Bros, among others, which allow you to launch homebrew on an unmodified console, and these are easy to utilize if you have a softmodded Wii. Just fire up GCMM (GameCube Memory Manager) on the Wii's Homebrew Channel and flash one of the exploits to your memory card. Then, perform the exploit on the Gamecube to launch an unsigned application named 'boot.dol' from the memory card. I have a copy of Smash Bros Melee, so I used the appropriate Home Bros exploit for my disc revision. Once it's loaded on the Gamecube memory card, I just start the game, go to 'VS Mode' and then choose 'Name Entry' and it loads the homebrew application.

OK, great so far. If I flash the default GBI application to my memory card, it fires right up and I can see the Game Boy Advance BIOS animation. There are some nice video options I can change, like zoom, etc. but it's stuck in nasty, flickery, line-doubled 480i. If you want the nicest, cleanest, most stable image, everybody knows you want "240p"/non-interlaced mode.

Now, this is where most of the other guides online stop being helpful. They typically expect you to have an SD card interface or modchip and they recommend using Swiss to change/set your video mode to 240p. This causes a couple of problems, though: 1.) only one homebrew application named boot.dol can live on your memory card at any time (i.e., so you can't have Swiss and GBI on the same card, typically), and 2.) even if you somehow get another homebrew application onto your memory card (more on this in a bit), Swiss can't launch another homebrew application from the memory card and then adjust the video mode on-the-fly the way it can with programs launched from disc, SD card, etc.

The simplest solution is to just use the speedrunning variant of GBI (known as GBI-SR; gbi-sr.gci in the GBI package), which forces 240p (yay!) but doesn't expose the other handy video options available with the standard GBI (booo!). This lets us drop Swiss entirely from the equation for this task, but you might/should still want to have it available in your homebrew toolkit for other purposes, and we can accomplish this with a little hex editing.

Just open the gbi-sr.gci in your hex editor and right at the top you'll see 2 instances of the word 'boot.dol' (you might have to scroll down a bit to see the second instance, depending on how many lines your hex editor shows). You can change that name to anything else--I changed mine to 'boob.dol' because it's a simple change that keeps the same length. Save and exit, and you should now be able to flash both Swiss and GBI-SR to your memory card without conflicts. Now, when you fire the exploit, it will boot into Swiss and you can choose your 'boob.dol' or whatever from Swiss' list of launchable content on the memory card to play GBA games in glorious, stable 240p or you can use any of Swiss' other awesome/handy features on your native Gamecube disc-based games.

Raspberry Pi 240p Composite Output

Big news for emulation on Raspberry Pis of any generation: a new firmware update has enabled 240p output through the composite video-out port (a dedicated port on older models and a combo 3.5 mm jack on newer models).

From Raspbian and its derivatives, you can run from a terminal:

sudo rpi-update

and it will automatically install the new firmware. For Lakka, the updated firmware will make its way into the main release at some point, but in the meantime, you'll need to mount your SD/microSD card on another machine and then find the 'boot' directory (for Lakka, this will be located in the ~500 MB partition that holds the system files rather than the bigger partition that holds your games) and make a backup in case anything goes wrong (not likely, but better safe than sorry).

Next, you'll need to download the new firmware files from github (here's a direct link to a zipped download) and copy them into the boot directory, overwriting what's already there. I believe you only really need a subset of the files (bootcode.bin, fixup.dat, fixup_cd.dat, fixup_db.dat, fixup_x.dat, start.elf, start_cd.elf, start_db.elf and start_x.elf), so if it acts strangely, maybe try cutting down to just those files.

In your config.txt, you can use the sdtv_mode directive to change to the new modes (either NTSC or PAL):

sdtv_mode=16    # progressive NTSC
sdtv_mode=0x10  # progressive NTSC (using hex notation)
sdtv_mode=18    # progressive PAL
sdtv_mode=0x12  # progressive PAL (using hex notation)

Also, make sure your config.txt isn't forcing HDMI output via hdmi_force_hotplug=1 (comment it out, if so) and you might want to force composite output, just to be sure, by adding hdmi_ignore_hotplug=1.

Raspbian and derivatives can now also change modes at runtime using the tvservice program:

$ tvservice -c "NTSC 4:3" ; fbset -depth 8 ; fbset -depth 32; tvservice -s 

Powering on SDTV with explicit settings (mode:0 aspect1)state 0x40001 [NTSC 4:3], 720x480 @ 60.00Hz, interlaced

for interlaced mode or:

$ tvservice -c "NTSC 4:3 P" ; fbset -depth 8 ; fbset -depth 32; tvservice -s 

Powering on SDTV with explicit settings (mode: 16 aspect:1)state 0x40001 [NTSC 4:3], 720x480 $ 60.00Hz, progressive

for 240-line non-interlaced mode.

Now, you'll notice that the above line still says 720x480 and applications will still see a 480-line resolution (that is, emulators will want to run at 2x scale). That's because the firmware still acts like normal 720x480 (or 576 lines for PAL) and the composite encoder just displays only half the lines.

This is actually to our benefit because it allows us to easily go back and forth at runtime and has the potential for on-the-fly switching (though RetroArch/Lakka doesn't support that and probably never will). It also allows emulators to show interlaced content without freaking out (that is, a "true" 240p resolution would cut off half of the picture, while this setup will just blank out every other line, which is much less obtrusive).

I have some pics here but, hilariously, the one from the new firmware turned out the worst:

RPi 240p Composite

Analogue Nt - RGB-PPU YPbPr

RPi 480i Composite

If you look closely, you can see that the RPi 240p shot has gaps between each scanline (easier to see on the green waves of the hill than on Luigi), while the 480i shot does not. What the still image can't show is that the 240p image is rock-solid stable, while the 480i image flickers sickeningly. Either way, the RPi composite output obviously does proper NTSC encoding, so blending of dithering and so on happens automatically without needing a shader, which is nice. EDIT: the NTSC encoding is (obviously, in retrospect) using the RPi's full 720 horizontal res timing rather than a console's native timing, so effects that depend on NTSC artifacting may or may not look like you would expect. For example, here's what the "tvpassfail" NTSC test ROM *should* look like:

NTSC Pass/Fail test ROM with maister's NTSC 256 px shader

But this is what the RPi's composite output actually shows:

NTSC Pass/Fail test ROM via RPi composite output

There's still crosstalk, of course, but it's spread across more pixels, which breaks the test. Perhaps unsurprisingly, it looks closer to the 320 px NTSC shader output:

NTSC Pass/Fail test ROM with maister's 320 px shader

With this new firmware, the RPi3 is now arguably the best/easiest/cheapest way to do proper 240p emulation on a typical NTSC standard-def television. Previously, a softmodded Wii was the undisputed champ in this area, as it was the only way to do 240p without putting a series of adapters and converters in the mix. The Wii still has an advantage insofar as it can output a high-quality YPbPr signal (i.e., comparable to the Analogue Nt shot above) but the RPi3 has the ability to emulate more consoles, including great Playstation 1 emulation via PCSX-ReARMed and decent N64 emulation via the core formerly known as GLupeN64 (now renamed to just Mupen64Plus-libretro). The Pi2SCART add-on from ArcadeForge can get a cleaner, "pixel perfect" output from emulators on the RPi, but at ~$50, it costs significantly more than the RPi itself, costs as much as a used Wii and requires adapters to work with standard NTSC televisions. So, in my opinion, RPi is the way to go for cheap/easy "240p" emulation on a regular ol' U.S. TV, while the Wii is a step up in visual quality but more of a hassle (and fewer games/consoles available to emulate). Pi2SCART wins in both respects but also adds significant cost.

NEC XM29 Plus Broadcast Monitor

I lucked into another broadcast monitor recently, this time the "holy grail" of retro gaming monitors, NEC's XM29 Plus. I won't rehash a whole bunch of info that's available elsewhere, but I will provide some answers to questions I had as I started using it:

Unlike the Sony PVM series, the XM29 Plus has no support for component inputs, but it supports almost everything else (Svideo, composite, RGBHV, VGA). You can get a YPbPr-to-VGA transcoder, like this thing, but most of them (including that one) don't support resolutions below 640x480, so they're not good for PS1 (which frequently jumps between 480i and "240p"), non-progressive PS2 games (admittedly, the vast majority of PS2 games are 480p-capable), or "240p"/doublestrike emulation via Wii homebrew, etc.

That said, I don't think component is a particularly useful on the XM29, which is a shame because that's what I had settled on for use with my PVM. Instead, it seems best to stick with RGB SCART, which is easily converted to RGBHV, as the XM29 has two of those inputs available. You will need a sync cleaner, though, so either get a sync strike or get a cable with a sync cleaner built-in, like this one.

There's a lot of uncertainty online about which resolutions work over SCART but I can answer definitively: 480p over RGB SCART totally works fine.

Other than that, there's not much else to say. Low-res non-interlaced content has extremely sharp scanlines with thick, black spaces between them, which some people don't care for. Likewise, interlaced content bobs very visibly when sitting close to the screen. Slight geometry issues are also apparently common on these monitors, and mine's no exception. However, it still looks great and many of the imperfections can be hidden with a teensy bit of overscan.

Here are some shots (click to embiggen):

240 noninterlaced full frame TATE

240 noninterlaced closeup TATE

480i

480p

Creating a Custom EDID for Arcade Monitor

Since I got my arcade cabinet up and running with my J-PAC-connected PC running RetroArch, the last finishing touch I wanted was to make it boot directly to the right resolution in a text-mode console and launch RetroArch in KMS mode, which provides the lowest latency and best experience. This ended up being easier than I expected, but it did require some steps I hadn't messed with in the past.

First thing you'll need is a working modeline. I created an ultra-wide 1920x240/60 modeline using this online calculator. Using a wide resolution like this leverages the natural blurriness of CRTs to hide fractional scaling artifacts on the horizontal axis, while the 240 vertical resolution allows perfect 1:1 scaling on the vertical axis. This provides a beautiful, "pixel-perfect" image for a large variety of games, including my favorites--Capcom's CPS-1/2.

This is the resulting modeline (negative sync options added by me):

Modeline "1920x240@60" 31.96 1920 1952 2072 2104 240 245 248 253 -HSync -VSync

I recommend testing your modeline out in a standard desktop environment using xrandr first, since it's pretty low-stakes. If something messes up, you just reboot and everything goes back to normal.

Once you've verified that your modeline works, you're ready to create your custom EDID. There are several good writeups about the process online, but I found this one most helpful. I won't rehash all the steps here, but you essentially just copy the appropriate files from the kernel tree and modify/rename one of the existing EDID source files (I used 1024x768.S) with the values from your modeline (I named mine 1920x240.S).

Here's the important part (i.e., license boilerplate removed for brevity; it's standard GPL2) from mine:

/* EDID */
#define VERSION 1
#define REVISION 3
/* Display */
#define CLOCK 31960 /* kHz */
#define XPIX 1920
#define YPIX 240
#define XY_RATIO XY_RATIO_4_3
#define XBLANK 184
#define YBLANK 13
#define XOFFSET 32
#define XPULSE 120
#define YOFFSET (63+5)
#define YPULSE (63+3)
#define DPI 72
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Ultrawide"
#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
#define HSYNC_POL 0
#define VSYNC_POL 0
#define CRC 0xf7
#include "edid.S"

Next, compile your source files, which should leave you with 1920x240.bin and 1920x240.bin.ihex (the *.ihex one is unneeded, AFAICT). Open 1920x240.bin with the edid-decode utility (available from the standard Ubuntu repos) and it should tell you something about the checksum being wrong (assuming you're making your own; mine already has the corrected checksum). Reopen your custom *.S and replace the existing, incorrect checksum where it says "#define CRC [whatever]" with the value it says it should have and then re-compile. It shouldn't complain this time.

Here's my compiled 1920x240.bin EDID, which should work for any standard-res 15 khz arcade monitor.

Once you have your shiny new EDID *.bin file, you'll need to create a new directory in /lib/firmware called 'edid,' which will require elevated privileges:

sudo mkdir /lib/firmware/edid

Then copy your *.bin file into it.

Next, you'll need to create a file named drm-kms-helper.conf, which contains only one line:

options drm_kms_helper edid_firmware=edid/1920x240.bin

and move it into your /etc/modprobe.d/ directory (again, needs elevated privs). Of course, you'll need to replace '1920x240.bin' with whatever you've named yours.

At this point, your custom EDID should be usable by your system, so a reboot will get you the desired resolution. If something goes wrong and you need to revert, just delete /etc/modprobe.d/drm-kms-helper.conf and it will put everything back the way it was.

If--like me--you'd like to go all the way and boot to a command line (instead of a standard GUI environment) that uses the new res, you'll want to edit your /etc/default/grub (needs elevated privs again) and replace the line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

with

GRUB_CMDLINE_LINUX_DEFAULT="text"

Then run 'sudo update-grub' to put it into effect. Now, on subsequent reboots, it won't try to load an X-Server and desktop environment and will instead go straight to console.

Finally, I don't plan on having a keyboard connected to my cabinet all the time (kinda kills the mood, y'know?), so I wanted it to login to my user account automatically. To do this, edit /etc/init/tty1.conf in a text editor and comment out the last line:

#exec /sbin/getty -8 38400 tty1

and add this below it instead:

exec /bin/login -f username < /dev/tty1 > /dev/tty1 2>&1

Replace 'username' with the name of the user account you want to login automatically. And, if you want to have it load a frontend--like RetroArch--as soon as it finishes logging in, you can add the launch command to the end of that user account's ~/.bashrc file.