Fly Brain Connectome Used To Trade Stocks And Play Games

Recently researchers finished mapping the central nervous system (CNS) connectome of not just the female Drosophila melanogaster (i.e. fruit fly) brain, but also that of the male D. melanogaster for a comparative analysis. Here the sexually dimorphic changes turned out to induce specific mating behavior that ensures that there will only be smooching between genetically fit D. melanogaster males and females, while the rest of the connectome remained effectively the same.

Of course, with this connectome in hand it led some people to ask themselves what else one can do with this connectome graph of about 160,000 neurons other than make a fruit fly into a fruit fly. So far we have seen [Nftechie] turn this connectome into a crypto stock trader with the Stonkfly project that uses the connectome’s reward circuits to potentially make profitable trades, though [Nftechie] says that they haven’t verified yet how good a fruit fly is at trading stocks, only that it does said stonks.

Over at [PC Gamer] they summarized a number of things that people have also done, including trying to make the connectome control a game of DOOM and Beat Saber. Each game frame stimulates sensory neurons, with the generated outputs then mapped to game controls, with dopamine-producing reward circuits wired in for reinforcement learning.

Although the D. melanogaster brain is only the merest fraction of the size of the human brain, it does provide us with a glimpse of what actual artificial intelligence research may lead to, as we unravel how even a 160,000 neuron connectome is enough to make these terrors of rotting plant matter do their wonderful things.

Running DOOM On A Cheap 104-in-One Handheld

Taking a break from putting DOOM on devices that absolutely were never conceived for use as gaming devices, [Aaron Christophel] recently got enticed by some cheapo handheld gaming systems at his local Action budget store. One is a controller-shaped ‘mini game console’ with 104 games from the 1980s and 1990s, while the other is simply a Pac-Man handheld in a more typical rectangular form factor. Although this brings to mind basic blob chips and limited hacking potential, as it turns out they’re actually quite nice inside.

As also covered in the demonstration video, rather than said nasty blob chip, both handhelds turned out to use the same unmarked MCU in QFN48 packaging. Some prodding and poking confirmed that it’s a typical ARM core, specifically a Cortex-M33 compatible STAR-MC1 ARMv8-M from an unknown manufacturer. Without a datasheet to go by, its limitations had to be discovered experimentally.

Of those, the biggest were a clock speed of 62 MHz – instead of the typical 194 MHz – as well as a lack of sound. This latter issue might be fixable with a better understanding of what appears to be a quirky DMA-fed DAC. Beyond this you’re also dealing with limited memory and of course just 4 MB of flash, though the chip for this might be upgradable if the MCU can map more. You do get a 320×240 display and a lot of buttons, which is admittedly nice.

As for the price difference of around $8/€7 for the Pac-Man version, this appears to be due to it running an officially licensed Bandai Namco arcade emulator as firmware, while the 104-in-one unit runs FlyThings/ZKSWE with a NES emulator.

Continue reading “Running DOOM On A Cheap 104-in-One Handheld”

DOOM Using Regular Expressions

Regular expressions (regexes) are an amazingly powerful way to perform operations on collections of e.g. text. Regexss can also be considered to be a programming language, even a Turing complete one. Ergo it’s perfectly acceptable to thus design a way to use regexes to run and play a game of DOOM, as [Artem Lytkin] recently did.

The GitHub project page can be found here, containing the Python-based code that allows the demonstration to run, as well as the other components, including the C runtime and the 96.6 MB text string that defines a CPU’s registers, RAM, a framebuffer, the DOOM engine compiled to this custom CPU’s instruction set and the WAD file for the game itself.

The C-based driver applies the fixed, ordered list of find-and-replace rules to this string, which after more than ten-thousand of such substitutions later results in a single frame of the game. At about 80,000 substitutions per second on the given test system, that gets you to a sort-of playable framerate, even.

Naturally, the practical value of playing DOOM like this is pretty low, but as a demonstration of why regexes are awesome it’s hard to beat.

The Neo Geo Does Run DOOM After All

Demonstration of the DoomGeo port of Doom to the Neo Geo. (Credit: Sabino, GitHub)
Demonstration of the DoomGeo port of Doom to the Neo Geo. (Credit: Sabino, GitHub)

Perhaps the most ridiculous statement that anyone can make is that a computer system with clearly enough processing power ‘cannot run DOOM‘. This is why we accept the premise that a PDP-11 cannot run this game, but something on the order of a Neo Geo gaming console with its 68000 processor and for the time impressive GPU definitely ought to be able to.

The stated problem here is a lack of RAM for a framebuffer, with the CPU only having 64 kB to play with. This limitation now has seen two different approaches to try and circumvent it, as covered by [Modern Vintage Gamer].

The first project here is Doom64kB, which as the name suggests tries to somehow work with this system RAM limitation. It uses the Doom8088 port for the original IBM PC and similar Intel 8088-based systems. This had to massively reduce the feature list, including the lack of texture mapping for floors and ceiling, no saving or loading, and no music.

The other project is DoomGeo, which doesn’t try to bend the Neo Geo hardware to its will, but accepts the Neo Geo way of doing things: involving sprite strips, pre-baked graphics, fix-layer UI, and a minimum of runtime data. This of course drastically changes how the Doom game engine normally works, with its framebuffer-based rendering.

From this we can thus conclude that it’s not so much the processing power that limits where DOOM can run, but more of how framebuffer-friendly the system architecture is, yet with some ingenuity and a complete rewrite of the game engine even that is no major obstacle.

(Top image: Neo Geo AES console. Credit: Evan-Amos, Wikimedia)

Continue reading “The Neo Geo Does Run DOOM After All”

Porting DOOM To The Casio Loopy

Targeted towards refined female gamers unlike the savagery of the mainstream game consoles of the era, 1995’s Casio Loopy was a bit of an oddity of a game console. Despite being standard enough in its design and backed by the might of Casio, it saw only one year of active software development and hardware manufacturing ceased by the end of 1998. With only eleven titles released for the system, with none of them being Doom, this obviously terribly upset [Throaty Mumbo], who set out to right this egregious wrong.

For the two dozen people or so who have one of these systems, you can experience the fruits of his labor yourself via the GitHub repository and something like the FloopyDrive cartridge.. Despite the quite capable Hitachi SH-1 16 MHz CPU and 1 MB of RAM, the main limitation is probably the original 2 MB of ROM space that does not leave a lot of space for DOOM WADs, even after doubling it on the FloopyDrive. Correspondingly you only get a handful of levels out of it.

Overall game performance isn’t too bad, though in the port’s current unoptimized state the resolution is fairly low. That said, even the console’s built-in printer is supported and demonstrated in the video, which is a pretty nice touch. It’s not like Sega or Nintendo consoles allowed you to screenshot those glorious headshots.

Continue reading “Porting DOOM To The Casio Loopy”

Hacking The Mi Band 10 Smart Band And Its Bestechnic SoC

In between playing Doom on the most ergonomically challenged devices, [Aaron Christophel] likes to take a relaxing break with reverse-engineering Xiaomi Mi Band fitness trackers and writing custom firmware for them. Also so that he can play more Doom on those, natch. The latest subject comes in the form of the Mi Band 10, which features a BES2700iMP SoC, known internally at the manufacturer Bestechnic as the BEST1503. This is all documented on the GitHub project.

In the accompanying video we get some more details on this project, with the main challenge being that for this Mi Band 10 there’s no public SDK for its SoC. This was a major bummer until [Aaron] realized that the BEST1306 (BES2700IHC) is effectively the same SoC, but with a leaked SDK available via apparently audio-focused development kits. From there a BEST1503-compatible SDK could be assembled.

Naturally, to check that all of this was working correctly Doom was ported to the device courtesy of the GBADoom project. This mostly works aside from the display running in single-bit SPI mode instead of quad-SPI that it should be capable of, along with limited color depth. Despite burning all the tokens on the Claude, this provided little help, probably because the required information hasn’t leaked out of Bestechnic yet and ended up in the training data set.

Since the Mi Band 9 uses the same SoC, it’s expected that this reverse-engineered SDK will also work for that fitness band, though that hasn’t been tested yet.

Continue reading “Hacking The Mi Band 10 Smart Band And Its Bestechnic SoC”

Hacking A Video Walkie Talkie’s TXW818 MCU And Running DOOM

Recently cheapo video walkie-talkies popped up on everyone’s favorite online retailers, which naturally lured in the usual gaggle of reverse-engineering enthusiasts of cheap tat to see what’s inside these devices, as well as what more they can be made to do. Cue [Aaron Christophel] doing just that, with the typical DOOM demo as proof of concept.

Inside these cheerful little devices is a TXW818 MCU, made by TaiXin Semiconductor. It provides its own CK803 CPU core at 240 MHz with 272 kB of SRAM, as well as BLE and 2.4 GHz Wi-Fi support. For these walkie-talkies an additional 4 MB of PSRAM is provided as well as 2-4 MB of SPI Flash.

The display is a glorious 240×320 LCD, which actually fits rather well with a game like DOOM. As also explained on the GitHub project page, to build the project you simply have to fetch the CDK IDE and build the binary. After that it can be flashed with an STM32F103 ‘Blue Pill’ based board.

According to [Aaron] the SDK is rather convoluted and not that nice to work with, so it’s not a sleeper ESP32 alternative, but these cheap walkie-talkies could be nice to tinker with anyway. Other than playing games, of course, as the side buttons aren’t very conducive to gaming, and the limited Flash space required compressing the WAD game file.

Continue reading “Hacking A Video Walkie Talkie’s TXW818 MCU And Running DOOM