If you’re looking for a reminder of how powerful the tiny microcontrollers that run our everyday gadgets have become, check out the work impressive work [Audun Wilhelmsen] has done to get DOOM running on the Nordic Semiconductor nRF5340. This is the sort of Bluetooth SoC you’d expect to find in a headset or wireless keyboard, and yet it’s packing a 128 MHz processor that can go head to head with the Intel 486 that the iconic first person shooter recommended you have in your old beige box PC.
That said, porting the open source shooter over to the nRF5340 wasn’t exactly easy. The challenge was getting the game, which recommended your PC have 8 MB back in 1993, to run on a microcontroller with a paltry 512 KB of memory. Luckily, a lot of the data the game loads into RAM is static. While that might have been necessary when the game was running from a pokey IDE hard drive, the nearly instantaneous access times of solid state storage and the nRF5340’s execute in place (XIP) capability meant [Audun] could move all of that over to an SPI-connected 8 MB flash chip with some tweaks to the code.
In general, [Audun] explains that many of the design decisions made for the original DOOM engine were made with the assumption that the limiting factor would be CPU power rather than RAM. So that lead to things often getting pre-calculated and stored in memory for instant access. But with the extra horsepower of the nRF5340, it was often helpful to flip this dynamic over and reverse the optimizations made by the original developers.
On the hardware side, things are relatively straightforward. The 4.3″ 800×480 LCD display is connected over SPI, and an I2S DAC handles the sound. Bluetooth would have been the logical choice for the controls, but to keep things simple, [Audun] ended up using a BBC micro:bit that could communicate with the nRF5340 via Nordic’s own proprietary protocol. Though he does note that Bluetooth mouse and keyboard support is something he’d like to implement eventually.
If some of the software tricks employed by this hack sounded familiar, it’s because a very similar technique was used to get DOOM running on an IKEA TRÅDFRI light bulb a week or so back. Unfortunately it must have ruffled some feathers, as it was pulled from the Internet in short order. It sounds like [Audun] got the OK from his bosses at Nordic Semiconductor to go public with this project, so hopefully this one will stick around for awhile.
Article lost me at this nonsense: <>
C-M33 is Little endian. stopped reading there
my quote got deleted. here it is:
The data in the WAD files are stored in big-endian format, most likely due to the fact that Doom was developed on a NeXT computer, which happened to be big-endian. This is lucky for us, as the Cortex-M33 is big-endian as well.
Endian is a silicon option on most (all?) of the Cortex-M series. The nRF5340 is configred as little endian, per Nordic Semiconductor’s infocenter website on nRF53 Series.
mystery solved. WAD is not big-endian like on NeXT. It’s native endian: whatever endian the port it was built for is. x86 WAD files are little endian, I’m sure NeXT WAD files, if they can be found, are big endian.
If you look at the DOOM source code, it always reads the WADs as little-endian, regardless of the endianess of the CPU. The game was designed with modding in mind, and you really want WAD/PWADs to work regardless of the computer you’re running on.
WAD did indeed ship as big-endian for some architectures. If you’re looking at source, it must be modern DOOM source after it was GPL’d and not an earlier versions.
What I’ve been looking is the Linux doom 1.10 release from 1994(game)/1997(source). It’s possible that the endianness handling was added for the Linux port specifically, but considering that Linux was only ported to DEC Alpha/SPARC in 1995, that seems unlikely. Would be very obscure at that point. Seems more likely that the code was there to have a share code-base between NeXT and DOS version of Doom. It would be easier for them than having to choose whether to generate big or little endian version of the WADs.
There are signs of this from the original Doom Map editor as well:
https://github.com/fragglet/DoomEd/blob/master/Wadfile.m
And you can see the swapping in the DoomBsp program that was used to generate the WAD files:
https://www.doomworld.com/idgames/utils/level_edit/node_builders/doombsp
According to doomwiki, some ports used big endian WAD. But this seems to be for consoles, where you can’t load third party WADs anyway. The WAD would probably have to be heavily processed anyway for those platforms.
All I know is that Gameboy Advanced used big-endian WADs. I can’t comment on the reason behind it, but I can assert that little-endian wasn’t always used at least early in Doom’s history.
Thanks for the feedback, good catch. I’m not sure how I mixed up big/little there. C-M33 has configurable endianness, but as jonmayo points out, it’s little-endian in nRF5340. I removed the comment about NextCube, as it was indeed big-endian. The WAD is little-endian, probably to match x86 which was the first architecture Doom shipped on.
At this rate, in 25 years, we’ll have 3080 gpu systems in light bulbs/nrf modules because they are generic& cheap enough!
In 25 years we won’t need light bulbs because we’ll be able to see with our EyePhones.
In 25 years we won’t need light bulbs, because there will be no electric grid, as the surviving humans will revert to the hunter-gatherer life style.
“You’ll own nothing and you’ll be happy about it.”
Many of us will not comply with “The Great Reset”, which Mike is referring to.
BTW, awesome Doom port.