The game is not running from RAM, it is running from Flash ROM. This means that code and static data can be placed on ROM rather than in RAM.
This is comparable to the GBA, which has 384KB of total RAM, and a ROM cartridge slot for storing the game code and data. But the GBA is only 16MHz, the EFR32MG24 system used for this project is overclocked to 136.5MHz.
The article says that even if you put all the static data to flash, you still have to fit about 1.5 MB of non static data, if you don't optimize it. Beside that, all graphics is loaded from the relatively slow external SPI flash, which tops at 17 MB/s with overclock. Yes, the GBA is much slower, but the access to cartridge data is faster than 17 MB/s (and also the random-read speed is in the 100 ns range, not 1-2 us range).
>This is comparable to the GBA, which has 384KB of total RAM
I assume you are thinking of the 32KiB of on-chip work RAM plus 256KiB of on-board work RAM plus 96KiB of video RAM. But pedantically there is also a 1KiB region of palette RAM and 1KiB of "object attribute memory", separate from the VRAM, making 386KiB total. (Not counting the I/O control registers, which one ordinarily wouldn't think of as "memory" but get a dedicated region of that address space.)
Aside from the ROM on a cartridge - up to 32MiB - there is 16KiB of BIOS ROM, and the system can address 64KiB of EEPROM for game save data.
Link to the video showing Quake running: https://www.youtube.com/watch?v=hVnfwzxTJ00
Impressive memory optimizations. Streaming out converted pixel values was a neat way of pulling off the "framebuffer" without having enough memory for storing all the 16 bit values. Solid engineering.
A great achievement, given the hardware.
Quake will probably run at 60 FPS on RP2350. Double buffered and with full sound quality. But it's nowhere near as hard to achieve it as on Arduino Nano Matter board. RP2350 got 520 kB RAM, dual core Cortex M33 and can run even at 300 MHz (150 MHz nominal).
what's with the website load time? like individual elements on this page taking multiple seconds to show. is it not 2024 yet?
Having a CDN doesn't help your performance when you tell it not to cache the page
bragr@<>:~$ dig +short community.silabs.com
community.silabs.com.00da0000000l2kimas.live.siteforce.com.
sdc.prod.communities.salesforce.cdn.edgekey.net.
e78038.dsca.akamaiedge.net.
173.223.234.17
173.223.234.11
bragr@<>:~$ curl -Is https://community.silabs.com/s/share/a5UVm000000Vi1ZMAS/quake-ported-to-arduino-nano-matter-and-sparkfun-thing-plus-matter-boards?language=en_US | grep -i cache
cache-control: no-cache,must-revalidate,max-age=0,no-store,private
x-origin-cache-control: no-cache,must-revalidate,max-age=0,no-store,private
When I've used a CDN, there were separate headers to control the CDN with the same semantics as cache-control... so you can serve the cache-control you want to browsers and control the CDN separately.
If it doesn't feel like it's cached, it probably isn't; but you can't assume the cache-control headers you see are controlling the CDN.
Depends on the Akamai property config which could be anything. IIRC by default it uses the standard cache headers and doesn't strip or rewrite them, although it definitely can.
ugh, old.reddit.com sends a no-store when signed in and its driving me mad because it breaks back/forward cache.
All “security” guidelines blindly suggest no-store. Also private with no-store makes no sense.
>individual elements on this page taking multiple seconds to show. is it not 2024 yet?
It's exactly what 2024 feels like. Future sucks.
Maybe it's running on an Arduino Nano Matter.
This is witchcraft...
The real hackery is the port for GBA mentioned in the article (running on 16.7MHz): https://www.xda-developers.com/how-quake-ported-game-boy-adv...
Yes that is really impressive.
Still it was done with 50% more memory, 1/3 of resolution and not implementing the whole game features.