Cannot download to PYGAMER

I just tried using the link from your post, and it loads fine onto my PyGamer, though compilation took a bit longer than usual. Do other game downloads work for you?

The game looks great! Unfortunately I’m not very good at it:

Thanks for getting back to me on this. I can download other games. I was also able to download previous versions, so I was starting to think maybe there is a limitation to how big the game can be. Do you have any other modifications? Does the pygamer take an extra memory card? If so, do you happen to know what the maximum size might be? I read somewhere that you cannot load more than one Arcade game at a time, so I’m not sure what the memory card would be used for. Perhaps you can use it for other platforms that can load on to it. I have also tried so many different USB cables, but it doesn’t make any difference. I would als think so long as the computer sees the device on the computer, that even manually copying the file to the drive should work as well.

Which operating system do you have? Windows, Mac, etc.

BTW: I’m using Windows 10 Pro

Make sure the PyGamer is in bootloader mode. If the PyGamer is connected to a computer while being restarted, it should automatically switch to bootloader mode.

Stupid webcam not focusing. :confused: It should look something like that, the text shouldn’t matter.

EDIT: It should show up as a USB drive called PYGAMERBOOT

Oddly enough I was able to upload the game. In the game I removed all references to this code:

transformSprites.rotateSprite(aSprite322, 180)
transformSprites.rotateSprite(frogging, 0), etc

I am not sure whether this code is causing my issue, whether it is my computer/usb cable being the issue, but after I commented all references to the transformSprites extension, I could upload the game. I saw this issue: and thought maybe this might be the issue. I’m not convinced. I will keep trying with/without the code to see if it works.

I uploaded it from a Linux laptop, copying the arcade-Frogging-Fun-100.utf2 file onto the PYGAMERBOOT drive. The file size was 682.5 kB, and it surprised me that this worked since I thought there was a smaller size limit for Arcade games.

If I reboot the PyGamer, the PYGAMERBOOT drive shows CURRENT.UF2 with a file size of 1.0 MB.

According to MeowBit Sd Card Slot the SD card slot isn’t currently supported for storing games, and I don’t have an SD card installed in mine. If I understand it right, the issue with that seems to be that the PyGamer only provides very low-level access to the SD card controller, and since the protocol is quite complicated it would be challenging to provide a driver to make it usable in the Arcade environment.

In case it helps, here’s my INFO_UF2.TXT:

UF2 Bootloader v3.10.0 SFHWRO
Model: PyGamer
Board-ID: SAMD51J19A-PyGamer-M4

I haven’t made any modifications to the PyGamer beyond putting it into a 3D-printed case.

According to, the PyGamer has 512 kB of flash plus 8 MB of QSPI flash, and I’m not sure which is used for what.

Is it possible that it’s only actually storing 512 kB of the full 682.5 kB UF2 file, and that it may partially work depending on which bits of it are stored successfully?

I was able to upload the game, this time via MakeCode. There have been so many times when it hasn’t worked, but now it is working.

I have exactly the same bootloader version:
UF2 Bootloader v3.10.0 SFHWRO
Model: PyGamer
Board-ID: SAMD51J19A-PyGamer-M4

I suspect that either something is wrong with my computer, or USB cable, or my browser (i’ve used Microsoft Edge and Chrome), or maybe the capacity of the device:

The PyGamer is powered by our favorite chip, the ATSAMD51, with 512KB of flash and 192KB of RAM. We add 8 MB of QSPI flash for file storage, handy for images, fonts, sounds, or game assets.

Do know if there is a limitation of how big Arcade games can be when uploading to a adafruit PYGAMER? The version I was eventually able to upload is 708KB.

1 Like

There is a limit, you can check if you hit it by following these steps:

  1. Download your project (you’ll be going to JavaScript, so good to make a backup in case something goes wrong)
  2. Switch to JavaScript
  3. Click on the “explorer” below the simulator
  4. Expand the “built” section (bottom of the list)
  5. Click on binary.asm (if this doesn’t appear, you need to download to hardware)
  6. There should be a line near the top that looks likes this:
; total bytes: 292240 (55.7% of 512.0k flash with 232048 free)

Also, I should mention, the easiest way to accidentally hit the limit is with full screen images.

(160 * 120 pixels) * (4 bits per pixel) = 9.6 kilobytes

It’s fine to have a few, but be careful!

1 Like

Thanks for getting back to me on this. I will give this a try and let you know.

; Interface tables: 714/2128 (34%)
; Virtual methods: 70 / 320
; generated code sizes (bytes): 195676 (incl. 143196 user, 5028 helpers, 14808 vtables, 32644 lits); src size 39344
; assembly: 116940 lines; density: 33.35 bytes/stmt; (4294 stmts)
; total bytes: 378380 (72.2% of 512.0k flash with 145908 free)
; peep hole pass: 2415 instructions removed and 4378 updated
; peep hole pass: 1913 instructions removed and 10 updated
; peep hole pass: 3 instructions removed and 3 updated
; peep hole pass: 0 instructions removed and 0 updated

I studied assembly language back in my hay-day; I never did understand it, but now I realize I should have paid more attention in class. :blush:

1 Like

Looks like you should be fine! Are you using the filesystem to flash or webusb? webusb can be a little buggy

I am not aware of using a full screen image. Is there something in the code that suggests otherwise?

Also based on my previous reply, and the way I have coded the game, is there anything I should change? I know I have a lot of functions, probably too many, and have also defined many variables (sometimes just to make debugging the game easier). So if you have any suggestions, I would love to hear from you. I want to make the game ‘leaner’, and I know I can do with a few less sprites. I look forward to your advice.

I was doing both. I read at adafruit that Chrome works better (webusb). The weird thing is, is that it works now. The entire day, not at all. So maybe it’s a combination of things, I’m not sure.

We do tree shaking on the compiled code, so the only code included in the binary is code that is actually referenced. It’s possible that the extension references you mentioned removed from the code were bringing in a lot of code. Other than that, I dunno. If you have a version of the project that does not download I might be able to poke around when I have some free time.

I only have the .uf2 files, but I can’t upload them. I could share them if you like. I guess it’s not a problem now, but if it happens again, can I send you another post here?

I apologize for jumping to conclusions. It was after a commented out parts of the code using the image transform extension, that it worked again. Shortly after, I put the code back, and I was still able to upload the game. So I am completely out of wits what was causing the problem, except that it must be my computer, the usb cable or the Arcade gods playing tricks on me. Sorry.

I have a few thoughts, some related to the memory concerns raised, and some related to your specific issue.

Regarding the Rotate Sprites extension: I do not believe I have tested it on hardware, so I do not know how it performs. It takes for granted the amount of memory in a browser, so it may exceed the RAM available on the hardware platform.

Along those lines, static images that are included with your project do not occupy space in RAM. So, if you’re running into the memory limit, I’d create the images in blocks and store the images in arrays, and then select the appropriate image from the arrays as needed. As @richard mentioned, dynamic images can quickly use up the available RAM on these hardware devices.

Regarding your specific situation, if the device is generating an error code, some of them have been documented here:

I don’t have a hardware device on hand at the moment. I probably should have one on-hand here in my remote office, now that I’m spending more time here. Anyway, if you continue to have difficulties, let us know what error messages you are getting.

@AlexK I was talking about the code size, not the RAM usage. RAM usage is for sure the much more common issue but I have seen 1 or 2 games that hit the flash limit.

Like Alex mentioned, if you hit an issue with memory usage you’ll get an error code on the device

I wasn’t getting any error codes trying to upload the game or while playing it. I wasn’t able to upload the game via Makecode (webusb) or via the computer by dragging the .uf2 file. During the transfer the device showed the bootstrapping screen, it flickered blank for a second but showed the bootstrapper screen again. Eventually I did get it to work, but the problem is I don’t know what got it to work. I was just thinking that maybe the size of the game might have been the problem, but it may have just been my computer, the usb cable (as I kept trying different ones) or webusb finally working.
I thank you :two_hearts: all for helping out with this issue, as you can imagine I was devastated to finish part of the game and to not have it work on the pygamer, but it is working now. I’ll keep my fingers crossed each time I upload and hope that I don’t have any problems in the future.

1 Like