A Pocket-Sized Digital Fish Tank

The problem with trying to make a fish tank fit in your pocket is that you’ll either end up with water everywhere or a bunch of dead fish. Perhaps that’s why [StratoBuilds] pursued a digital solution instead.

The concept behind Pocket Tank is relatively simple—it’s a small device that displays a virtual tank with a bunch of little fish swimming around inside. It’s based on the Waveshare ESP32-S3-Touch-AMOLED-1.8, which, if you’re wondering, is an ESP32-S3 with a 1.8″ screen attached, all wrapped up in a convenient plastic housing.

Thanks to the powerful microcontroller, there’s plenty of grunt on tap to run and display a small simulated fish tank. [StratoBuilds] whipped up a system wherein fish movement and animations are handled by regular code running at 25-30 fps, while the fish’s decision making is handled by a custom large language model that was condensed down to run on the ESP32 itself. As the fish swim around the tank, the situation is observed by the LLM and the fish’s current goals are changed accordingly depending on what’s going on. Much like a Tamogotchi, there are regular maintenance tasks for the user to handle, too, like cleaning the tank and feeding the fish to keep them alive.

The blog post and YouTube video do a great job of explaining the project; files are on GitHub for those that wish to tinker more directly. It’s funny, because when we normally look at fish tanks, we’re talking about real ones.

Continue reading “A Pocket-Sized Digital Fish Tank” →

Abusing SQL To Play DOOM

Most laypeople who encounter SQL think of it purely as a tool for managing large datasets. While that is certainly what it was designed for, SQL is still a programming language at its core. It includes many of the features found in general-purpose languages like C or Python, and although it wasn’t built for general-purpose work, it can handle a surprising range of tasks that programmers might not expect to use it for. To demonstrate its capabilities, and perhaps to show off their skills with SQL, a group at CedarDB ported the original DOOM to this language.

The project stores the WAD data (essentially everything except the engine) in a series of tables, which was fairly straightforward compared to the rest of the project. Where it gets more complicated is managing the timing that ties the game to 35 fps, and of course rendering the images. Their rendering process takes up 1300 lines of SQL across 89 common table expressions (CTEs) which is certainly advanced for this language. The rest of the project is another 4000 lines of SQL, with a bit of Python to handle the keyboard inputs, timing, and display of the generated bitmap.

Perhaps counterintuitively, DOOM might be the perfect game to run on SQL. It was built in an era before dedicated graphics cards and isn’t truly 3D, meaning that the programmers had to do a lot of tricks to get it to look as if it is 3D. This results in a lot of data transformations uniquely suited to SQL. It’s almost like DOOM‘s original renderer was built by someone with extensive SQL knowledge in the first place. For those looking to try this out, the source code for the project is available on a GitHub page, and for some other unique implementations of DOOM there’s also this version built in regular expressions and this one in Microsoft Word.

FPGA For All — CERN Releases “colibri” VHDL Library

Since you’re reading Hackaday, we’re pretty sure CERN needs no introduction, so we’ll get right to it– they’re giving back again, this time with a VHDL library called “colibri” containing over 100 components, functions, and procedures to help jumpstart your next FPGA project.

Like a lot of what CERN gives away under its CERN Open Hardware Licence, this library and the functions in it were developed in house to make CERN run better– specifically to streamline the development of gateway devices. As you might imagine, with the prodigious amount of data CERN’s various experiments spit out, FPGAs have become a key part of many of them. The best part is that because the fine folks at CERN don’t want to get locked in, everything here is vendor-independent and has been tested on multiple platforms. Speaking of tested, you get self-checking testbenches in there to make sure everything’s working, and there’s even formal verification, at least for some things. We’ve seen formal verification in software compilers, but its not common in the FPGA world. The whole thing is on GitLab if you want to take a look.

While CERN’s library might not have much to help you make a ternary processor or bus controller with everyone’s favourite programmable silicon, much like software libraries you can save some time at least not implementing say, SPI or i2c– both of which are in colibri, along with a whole lot more.

Thanks to [Alberto Perro] for the tip!

A JavaScript OS For The ESP32

Given the incredible power of modern microcontrollers, we’ve seen quite a few attempts to turn them into more general purpose computers over the years. KryonOS from [Haris] is the latest, and it takes a slightly different path from the norm in that it’s a JavaScript based operating system for the ESP32.

It takes the form of an OS with a simple GUI and graphics library, and a built-in JavaScript runtime interpreter. It runs on a wide variety of ESP32 boards with screens, including the ubiquitous Cheap Yellow Display. It has full access to the SD card filesystem, and an API for using the hardware. Perhaps most interestingly it has an app store for downloadable software, which immediately reminds us of Europe’s Badge.Team. Their SHA2017 badge spawned a succession of devices that continues to this day, and offered a similar experience using Python.

We like this project, and think it has potential due to the ease of JavaScript development for so many people used to working with the web. There was a time when Python running on microcontrollers sounded pretty far fetched, and look where we are now.

CircuitPython Goes Turbo With Precompiled Functions

It would not be at all original to declare that Python is the new BASIC. Like BASIC, it has been the first programming language for a whole generation of coders, and its main advantage is that it’s quick and easy to write in. Like BASIC it is an interpreted language, and thus rather slow to execute.

Thus while CircuitPython can be very useful for beginners and quick projects, it hits the limitations of the hardware far sooner than it needs to — unless you can pre-compile critical parts of the code, which you now can, thanks to CircuitPython Turbo by [Mikey Sklar] with some help from Anthropic’s Claude LLM.

Now if that sounds a lot like MicroPython’s ‘Viper’ and machine-code compiler, that’s because it is. CircuitPython is a fork of MicroPython with some handy extras on Adafruit boards, but Viper wasn’t one of them until now. Before the Turbo version, CircuitPython only ran in interpreted mode.

Like MicroPython, using CircuitPython Turbo you can flag sections to run as ‘native’, where instructions are compiled but values stay as python objects, which gets you about a 3X speedup. A little more rewriting to declare your variables and pointers and you can use ‘viper’ mode, which can — depending on what you’re up to — result in a 20x to 70x speedup. In Adafruit’s documentation, they demonstrate a Metro RP2040 calculating the Mandelbrot set 3x faster in Native and 19.7 times faster with Viper than normal Python bytecode.

The one thing that we miss from BASIC that CircuitPython Turbo doesn’t give is inline assembly– though interestingly enough, that is in the upstream MicroPython implementation, so perhaps its day will come here too. Not every job is suited to the use of Python on microcontrollers, but we’ve seen it used for everything from e-bikes to a Winamp-inspired music player.

Hand-Coded ASM Powers Homebrew SNES Game

Nintendo has made many game consoles in its long history — one that famously overlaps that of the Ottoman Empire — but only one of them was ever Super. It’s that console, the Super Nintendo Entertainment System, that [Inkbox] has decided to delve deeply into as he crafts a game in assembly using all the hardware tricks he can.

Hardware tricks he’ll need, given he’s limited to the two 64 kB RAM banks and 3.58 MHz Ricoh 6502-based CPU. Even the 4 MB limit he sets for a historically-accurate homemade cartridge seems positively claustrophobic by modern standards. The game he’s after making is a top-down adventure game a la Zelda, and [Inkbox] gets right into the weeds explaining how the SNES works as he shows his work in this nearly hour long video. If you’re looking for a deep dive into the architecture, along with how it is meant to be used, you could certainly find worse sources. Everything from the different graphics modes to what registers handle sound are covered in this and the previous video in the series.

We can’t help but call out his dedication to open source — the SNES Sound Engine he has put up on GitHub looks like it could be a real asset to anyone else doing this kind of homebrew. The game itself is on itch.io and is pay-what-you-want.

[Inkbox] doesn’t just limit himself to the SNES’s 6502-esqe assembly — he’s done impressive work in x86 ASM, too. Continue reading “Hand-Coded ASM Powers Homebrew SNES Game” →

It’s GNU Radio Companion, But In The Browser

The progression of the web browser from a tool for simple static information browsing into a do-everything computing environment has been inexorable, with package after package making the jump. Today it’s the turn of GNU Radio Companion, lowering the barrier to software defined radio considerably. It’s the work of [Marc Lichtman], who’s name you may recall if you have ever used pysdr.org.

Loading it up gives you a very familiar window if you’re used to GNU Radio Companion, and it comes with a set of example flowgraphs that cover a large range of applications. It supports a collection of software-defined radios (SDRs) including the well-known RTL-SDR, and if that’s not enough it can also use your sound card. There is even a set of recorded off-air captures to experiment with.

We’ve spent a while here playing with it, and it does everything we’re used to from the version outside the browser. The only thing we’re told it won’t do is work with a networked SDR, but that’s no deal breaker.

Thanks [Marcus Müller] for the tip.