I spotted these little colour screens on AliExpress and thought they looked suspiciously similar to the mono screen in the original Thumby. So I ordered a few...

Oh! I'd convinced myself that wasn't the problem after all. Thanks for that!
The way I packaged it up into a single UF2 was pretty shaky, and I'd love to learn of a better approach. What I did was to package the doom1.whx file into its own UF2 file using uf2conv, and then concatenate that with doom_tiny.uf2. From my understanding of the spec this should be a valid UF2 file, but the RP2040 bootloader refused to accept it. However, using uf2conv to convert the combined file to raw binary and then converting it back produced a file that did work.
I'll update the repo when I'm back on the relevant machine.

For that last one, I lowered the spi transfer rate and turned off the frame syncing (although I doubt the transfer rate was a factor here). It sounds as though your device would work just with different settings for PARK_LINES and FRAME_PERIOD. Failing that, getting the frame period approximately right and skipping the sync trick doesn't look too bad.

If you're able to build your own version that's probably the way to go, since I don't have the hardware to test on.

OK, try this one and see how far it gets.

I've built a version which puts the doom logo on screen for 2 seconds immediately on start, using conservative timings and no greyscale tricks. This might help establish where the problem is.
The uf2 file is attached here. It doesn't contain the whx data, but if you upload the 'single install' release first then this file, it should retain the data.

It should just be a matter of copying the single installer uf2 to the RP2 drive. I've just tried it on a second thumby, and it worked OK.

It might be worth trying the previous release, copying the .whx file separately. Looking at the instructions I gave on the release page from that, I see there's a typo - there's a period at the end of the line that shouldn't be there. (Clutching at straws, but it's worth a shot)

It does seem that the display is a red herring. Doing nothing at all on boot would be a symptom of not finding the data file. (And of many other possible problems)

There's no debug out from the build I made. It might be worth rebuilding it to make beeps at various points, to try to track down where it's stopping.

It's promising that the fireplace works. One could presumably copy the timings from that, and I'll add some configuration options if I do another update. It's a tough one to fix without access to the specific hardware though.

I'm surprised you're getting a blank screen - I would expect at least some flickery image.
One thing to try would be to go back to the thumby firmware, then load ugrey.mpy and greytest.py on it from https://github.com/AncientJames/uGrey - if you run greytest.py, that should establish whether it's some incompatibility with the greyscale driver. It's also a more convenient way to try out different refresh rates, rather than recompiling Doom each time.

I updated the release so it's now a single install file.

Put the Thumby in BOOTSEL mode and copy thumby-doom.uf2 to it.

My port of Doom for the Thumby is now available on github.



Installing it is a bit of an adventure, and it will overwrite the firmware & games on your device. There are two files in Releases that need to be installed; the game itself is a .uf2 file, but the data needs to be installed using picotool.

The port is based on RP2040 doom, but modifies it to work with the Thumby screen.