TinyCircuits Forum
TinyCircuits Products => Thumby => Topic started by: AncientJames on October 04, 2023, 07:57:28 PM
-
My port of Doom for the Thumby is now available on github (https://github.com/AncientJames/rp2040-doom).
(https://img.youtube.com/vi/k7ztqNAVVsY/sddefault.jpg) (https://www.youtube.com/watch?v=k7ztqNAVVsY)
Installing it is a bit of an adventure, and it will overwrite the firmware & games on your device. There are two files in Releases (https://github.com/AncientJames/rp2040-doom/releases/tag/v1.0.0) 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.
-
This is absolutely amazing! Great work!!!!
Ken Burns
TinyCircuits
-
Wow!
-
I updated the release (https://github.com/AncientJames/rp2040-doom/releases/tag/v1.0.1) so it's now a single install file.
Put the Thumby in BOOTSEL mode and copy thumby-doom.uf2 to it.
-
I just got a thumby to put doom on, and am having trouble. I tried using the most recent one file release, and when turning it on, I get nothing on the display. I tried the older release and got the same thing, both with and without the whx file (tested without just in case I messed something up with loading that file). I then saw the note about setting FRAME_PERIOD, and so set that to 6400 (and PARK_LINES to 2), compiled it, and tried loading it onto my thumby, again with no change on the screen when turning it on. I have 2 thumbys and I am getting the same result on both. I can go into bootsel and load the factory firmware and get them working again with that.
Unfortunately I don't really know where to start with troubleshooting this, so was hoping you might have some ideas, or at least get something to display on the screen. Thank you!
-
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.
-
First, thanks for helping me out.
Ok, well I am having trouble getting that running as well, so that might be part of it. When running greytest on the thumby, it just looks like it restarts and reloads the main menu. Same thing happens when using the sample code in the readme for ugrey .
Trying it in the emulator on https://code.thumby.us/, doesn't seem to work either. After figuring out i needed to mark /lib/ugrey.mpy as emulatable, it seems to run without error (including not exiting), but nothing appears on the emulated screen. Also, adding print statements doesn't seem to work, even the simple program below doesn't print anything to the console and the program doesn't exit. Even if I put invalid code below 'import ugrey' it doesn't seem to be evaluated and give an error
import sys
import ugrey
print ('hello world')
sys.exit()
The version info I can find is MicroPython v1.19.1 on 2022-06-18
I did try https://github.com/TinyCircuits/TinyCircuits-Thumby-Games/tree/master/Fireplace and could calibrate the greyscale in that program (but I know it is using a different driver).
-
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.
-
After messing with it more, I got greytest to work (I didn't have the folder it was in named 'greytest'). This is making me hope I did something equally stupid getting Doom running. With greytest, I got noticable desync lines at 5500, but was still able to see the image. I still need to figure out the best frequency, but around 6100 seems to be it for me. But this makes me wonder why I am getting no image at all for doom. Is there a place I should start poking to see if I can just get a splash screen or something after flashing uf2 image?
Again, I'm really hoping I am simply missing something, but I am just booting into BOOTSEL and copying the uf2 file to the drive that pops up. When it is done copying, I unplug and restart the thumby and get no image.
Thank you again!
-
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.
-
This project is amazing fitting this into such a small memory for what doom wads need (I read the breakdown too).
So basically, I remove all files in the folder and replace with your single file and 'reboot' to run ?
Edit: fyi I get the black screen of doom too.
fireplace demo works ok ,will have to try 'old' way
-
Possibly the uf2 file download from git is the wrong size 4029 v 4096 not sure if uf2 file format needs to be byte aligned?
Edit: using win11
INFO_UF2.TXT
UF2 Bootloader v3.0
Model: Raspberry Pi RP2
Board-ID: RPI-RP2
Edit2: tried also in Linux bash term - same as win11.
I'm allowing a minute or two for the boot loader to flash, for the stock firmware that's working fine.
final mention that the thumby web ui shows 1.4mb as total memory available, thought we got 2mb ?
-
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.
-
I got the splash image!!! The screen just went black after, but it at least got that far.
-
OK, try this one and see how far it gets.
-
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
-
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!
-
Cool and thanks for update henryg.
Also, would it be possible to have a v1.1 for the uf2 single install please?
-
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.
-
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);
-
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.
-
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.