Doom

[htmlgames]

Hi  AncientJames,
  Thanks for supplying the updates, I think your close to solving this now. BTW I'm currently working on a project so cannot test the above latest files just yet....

I've noticed on the newer thumby grayscale py needs a fix in general - even those from thumby arcade.

 I'm not sure your project uses the grayscale py files that the thumby arcade uses, but I will mention the fix to that file with the changes for more recent thumby (and what I believe the person above may have as both having similar issues).

 It looks like during screen init you need to have a small delay for it to work. I did this 'hack' by using playBlocking cmd for this.
Grayscale arcade games now run 100% from the arcade once I modify that file.
(Search for pf in the attached file if you're interested)

edit'; here's the tumbyGS.cfg file contents from mine.
gsV3,timing,107,oled,0

[henryg]

That worked! (The most recent doom_tiny.uf2). The sync needs tweaking, but I was able to play the game! What ended up being the problem and can I pull the updated code somewhere (didn't see it on GitHub)? Thank you so much for your effort troubleshooting this!

[htmlgames]

Cool and thanks for update henryg.

Also, would it be possible to have a v1.1 for the uf2 single install please?

[AncientJames]

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.

[henryg]

It actually was the spi rate!

here is the diff file of the only change I made and it started running. I messed around with some FRAME_PERIOD settings to find the best, one, but that will wait until after sleep. Prior to this change, no matter what I set FRAME_PERIOD or PARK_LINES to, it would not work. So I can now compile and mess with stuff on my own to get everything working as smoothly as possible for my devices.

I guess the only question I have left is if there there is an easy to way to build it into a single file with the whx, like the release on github?

Thank you sooo much for helping troubleshoot this even though you weren't able to replicate it.

--- ../src/pico/i_video.c.orig   2024-02-10 01:57:59.954548400 -0600
+++ ../src/pico/i_video.c   2024-02-10 02:43:46.964548400 -0600
@@ -438,7 +438,7 @@
 
     gpio_set_function(PICO_DEFAULT_SPI_SCK_PIN, GPIO_FUNC_SPI);
     gpio_set_function(PICO_DEFAULT_SPI_TX_PIN, GPIO_FUNC_SPI);
-    spi_init(spi0, 62500000);
+    spi_init(spi0, 62000000);
     spi_set_format(spi0, 8, SPI_CPOL_0, SPI_CPHA_0, SPI_MSB_FIRST);
 
     gpio_put(J_OLED_CS, 1);

[AncientJames]

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.

[henryg]

I see what you mean by shaky. I was able to throw something together using python (that could still use more work to be 'public release" quality) that calls the python version of uf2convert from https://github.com/microsoft/uf2/tree/master/utils . The main drawback is that you have to call it from the folder where the script resides and have uf2conv.py and uf2families.json in the same folder.

What it does is take the .bin file from the compiled output, pad it with zeros to the specific length needed, and then concat the whx file. After this I run it through uf2conv to create the final flashable file.

the script can be run like:

~/rp2040-doom/uf2conv$ ./single.py ../thumby-build/src/doom_tiny.bin ../doom1.whx doom.uf2

since the actual work of the script is fairly simple (and there is a c version of uf2conv), I'm sure it can be ported to be included in the workflow of the make files or however you want to handle it.

[Kyle7874]

Thanks for the amazing job on porting doom rp2040 to Thumby!

I had a blackscreen issue too, thanks for the fix above regarding lowering SPI clock, now it works.
Although there is still a problem with syncronization (not that stable like other greyscale thumby games) .
Also greytest.py doesn't work for me (I think because of the same SPI issue)

1. I have wondered is there a way to match thumbyGrayscale.py text params to the one in i_video.c?
My params which work fine for me: gsV3,timing,110,oled,1.
2. Is it a good idea to find more precise SPI clock setting? Now I am using 6000000

In attachment some compiled binaries for people with the same problem

[tdl20rounds]

Hey guys sorry if I'm breaking any rules posting here but I recently got my friend a thumby as a gag gift and I wanted to give him one with this port instead of the "Thoom" game included in the arcade page.

I don't have any experience editing things but I had the same problem with making it to the splash screen but it freezes there. How do I edit the SPI clock to get it working? As in what to download/install/use? I just need a nudge in the right direction.

[Niko0508]

This blog post was fantastic. Very informative. https://medium.com/@solar-power-systems/free-solar-panels-in-anniston-alabama-a3f3cc55a3ca