Hi all- we have a version of the app up at https://files.tinycircuits.com/TinyTVConverter1.0.1b.zip that was tested here on macOS 12.6.7 and 13.4, please let us know if it's working for you on 12.

@mynameisfuzzy Did you try to right-click/control-click on the app, then click open?

Thanks,
Ben

Yep, it's ffmpeg. Here's one of the commands the converter runs: ffmpeg -i "input.mp4" -r 24 -vf "scale=210:135,hqdn3d" -b:v 1500k -maxrate 1500k -bufsize 64k -c:v mjpeg -acodec pcm_u8 -ar 10000 -ac 1 output.avi"

Alternate scale options:

scale=210:135:force_original_aspect_ratio=increase,crop=210:135:exact=1,hqdn3d
scale=210:135:force_original_aspect_ratio=decrease,format=yuv444p,pad=210:135:(ow-iw)/2:(oh-ih)/2,format=yuv420p,hqdn3d

We'll try to get this documented in the near future- basically the expected format is MJPG with 8 bit 10KHz audio. Some input videos cause enough difference in output format/content to be incompatible with our firmware- we're still tracking down different examples of that and hope to get everything fixed on the firmware side.

Thanks,
Ben

Thanks for your support! The current behavior is supposed to be that all videos work that way. Starting from the beginning could be a fallback when there's something unexpected(to the firmware) in the video file. If some of these files are shorter/smaller and something you can share, could you try uploading some to some file sharing service? We can see if we get the same results here.

Thanks,
Ben

Sounds like it may be powered down all the way when you're testing this- have you tried plugging it into the computer while the TV is on and playing videos? Otherwise it sounds like you've tested thoroughly and the TV may have been damaged or was already defective in some way, send us an email at info@tinycircuits.com referencing this thread if it's still not working please.

I did just test on an M2 with 13.4 since this type of thing can break/unbreak version to version, the first time it's plugged in the Mass Storage screen appears for about a second- macOS shows an "allow USB device" type prompt, then the TinyTV needs to be unplugged/replugged. After that it seems to work normally.

Thanks,
Ben

Hi- yes, files will be pretty large for the low quality video due to the encoding. Modern high compression formats require a lot of processing power and memory, the TinyTV 2/Mini AVI format is just JPG frames and uncompressed audio which allows it to be decoded by the microcontroller inside the TVs.

I haven't really heard that feedback before. The app is a simple UI for FFmpeg, which is pretty widely used. Converting video requires a lot of processing power- it's CPU only and maybe only single threaded, so your processor might be at the highest frequency when running it. It's probably converting faster for you than other people with slower processors, but will definitely use a lot of processor time/create some heat. Not sure what we could do in this area, let me know if you have any thoughts.

Thanks,
Ben

Sorry about the problem(and requiring the update, I know that's annoying). Trying to narrow it down, does the TV screen switch away from the video and show a 'USB storage mode' screen?

Is this on an Apple Silicon processor? We had some additional issues with those(each USB device needs to be given permission) but I think those have been resolved on the macOS side.

Hi- thanks for posting over here, unfortunately I haven't been able to directly engage on the Discord channel due to time constraints. I agree this is a pretty good/public/searchable spot for this.

Glad the WDT register usage could be understood! I haven't reviewed everything but the changes all look like they're going in the right direction, we're long past due for a cleanup.. We're a little slow/conservative on changes to avoid breaking things obviously, but I don't see anything I'm too concerned about. I'll check with Jason when he's back in the office next week.

Thanks,
Ben

Best picture my phone could manage, which is probably the only way to get a good sense of how it looks!

@acedent- I thought that would be a quick answer! I've been playing around with a bunch of stuff in MicroPython for the last day or two, and I think the answer is that blits with the built in FrameBuffer object are just a bit slow. It's extremely general purpose and can handle tons of use cases outside of our simple 1bpp need. The arduboy2 font section looks like a very reasonable C/C++ implementation for 1bpp, I've written(adapted?) similar stuff for TinyScreen etc. After a while, I was able to do something similar in a MicroPython Viper code block, and it actually runs faster than the built in stuff for this very specific need.. I'll see if I can get something far enough along for other people to take a look at.

Very cool to see that you're able to work on this with the emulator!  I tested it on hardware quickly and it seems to work as intended, keep us updated if you do any more before you have hardware!

Hi- the answer for 'eventually' is definitely. We'd like 5x7 default, with maybe some smaller options. Right now we're testing out implementation in pure MicroPython, but it's pretty slow and we'll probably need to implement it within the firmware, so that will delay initial availability of it for testing etc- if anyone has input on that, let us know!

Thanks,
ben

Hi Kieron,

With how we plan to ship Thumby, the MicroPython interpreter will eat plenty of RAM as well as possibly some minimal assets leftover in memory from the main menu, however the menu essentially runs and then completely exits to the game(power off/soft reset to get back to the menu, for now).  I don't currently have a number for what's used- I've read things like 16-32KB for the interpreter. Let me know if you need a better answer.

I'll admit that during development of our little game examples, we haven't worried about memory, it's a lot more than we're used to!

Thanks,
Ben

Very cool! If you run it at 72x40 on your Arduboy, it will be pretty close to what you'd see on a Thumby, except about 25% larger pixels still! Keep us updated- not sure if the scaling is a mockup or functional, maybe we could test the code here?

Thanks,
Ben

Hi- the 2MB flash is a QSPI flash chip, the same one as used on the Raspberry Pi Pico. By default we plan to have the standard Pi Pico MicroPython interpreter loaded, which I believe is about half a MB, leaving about 1-1.5MB available.

There's 264KB RAM, no crpyto acceleration hardware that I'm aware of. Full specs at:

https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf

Thanks for the interest!
Ben

Meant to respond last week, sorry- yep, lib/thumby.py will get you most of what you need until we have things documented. Thumby works fine in the Arduino IDE equivalent to the Raspberry Pi Pico, so it should be pretty easy to adapt the Arduboy library functionality, aside from the tough part of adapting games to the lower resolution.

Thanks,
Ben