RP2040 based Arcades appear slower than Arcades based off other architectures

[JakeAtKitronik]

RP2040 based Arcades appear to run much slower than Arcades based off the Nordic N3 or Atmel SAMD processors. This is especially noticeable when the Arcade is running a game that has a large number of sprites.

The Arcade is noticeably slower on the "jumpy platformer" demonstration.

When a few "enemy" sprites are present on screen, the arcade noticeably slows down.

This may be related to the CPU clock frequency that the RP2040 has been set to, or it could be a backend issue on compilation.

[hopse31c]

I agree with you. The device using RP 2040 in MakeCode Arcade will have a much lower FPS than other devices. Is it because it doesn't utilize the CPU, which is dual-core, well?

[JakeAtKitronik]

I'm not entirely sure what the exact issue is - it's likely to be either an issue with the standard bootloader that Microsoft provides, or with how the games are compiled.

Hopefully someone picks this ticket up!

[mmoskal]

We only use one core. This is pretty hard to change (maybe except for putting display driver on the other core). It is a less efficient M0+ core compared to M4 on other arcades, but I would think the higher clock would counteract that.

@tballmsft suggested it may be due to flash being slow - this is possible.

[JakeAtKitronik]

Thank you so much for the information, unfortunately, the flash is the same as on a Pico- so unfortunately I do not believe that is the issue.

[tballmsft]

@JakeAtKitronik - I don't understand then - the Pico is an RP2040. @mmoskal - I thought we treated all RP2040 boards the same - what could be the difference?

[tballmsft]

the only difference would be the configuration per https://arcade.makecode.com/hardware/adding

For RP2040, the application looks for CF2 section (see below) at 4kB before the end of 1MB, 2MB, 4MB, 8MB, 16MB, 32MB (that's megabytes) in the flash. It's recommended to place it at all these addresses (size of flash permitting). 
See [sample config UF2](https://github.com/microsoft/pxt-arcade/blob/master/libs/hw---rp2040/sample-config.uf2).
Manufacturers should provide a "factory reset" UF2 which contains all these config sections, and possibly a test game.
This file can be used to recover after the flash has been overwritten (eg by large files in the Micropython filesystem).

[tballmsft]

@JakeAtKitronik - can you please specify which arcade boards with the RP2040 show the difference and specify how they were configured? More information is required if we are going to chase this down.

[JakeAtKitronik]

Morning Tom! I feel there is a bit of crossed wires - there is only one RP2040 "Pico" based Arcade. My point regarding the flash chip is that we are using the same one that is found on the Pico - I feel I misread the point about the RP2040 being slowed down by the external flash, regardless of the part used. I'll ping you a private message for further clarification.

[tballmsft]

see here for some analysis of flash: https://www.bigmessowires.com/2022/02/18/first-look-at-the-rp2040-raspberry-pi-microcontroller/

Fetching a 32-bit value requires 20 SPI clocks, which is 80 system clocks using the RP2040’s default settings. A 32-bit value can hold two 16-bit Thumb instructions, so it looks like 40 system clocks per instruction, or 3.3 MIPS at 133 MHz. Slow.