Quake In 276 KB Of RAM

Porting the original DOOM to various pieces of esoteric hardware is a rite of passage in some software circles. But in the modern world, we can get better performance than the 386 processor required to run the 1993 shooter for the cost of a dinner at a nice restaurant — with plenty of other embedded systems blowing these original minimum system requirements out of the water.

For a much tougher challenge, a group from Silicon Labs decided to port DOOM‘s successor, Quake, to the Arduino Nano Matter Board platform instead even though this platform has some pretty significant limitations for a game as advanced as Quake.

To begin work on the memory problem, the group began with a port of Quake originally designed for Windows, allowing them to use a modern Windows machine to whittle down the memory usage before moving over to hardware. They do have a flash memory module available as well, but there’s a speed penalty with this type of memory. To improve speed they did what any true gamer would do with their system: overclock the processor. This got them to around 10 frames per second, which is playable, but not particularly enjoyable. The further optimizations to improve the FPS required a much deeper dive which included generating lookup tables instead of relying on computation, optimizing some of the original C programming, coding some functions in assembly, and only refreshing certain sections of the screen when needed.

On a technical level, Quake was a dramatic improvement over DOOM, allowing for things like real-time 3D rendering, polygonal models instead of sprites, and much more intricate level design. As a result, ports of this game tend to rely on much more powerful processors than DOOM ports and this team shows real mastery of their hardware to pull off a build with a system with these limitations. Other Quake ports we’ve seen like this one running on an iPod Classic require a similar level of knowledge of the code and the ability to use assembly language to make optimizations.

Thanks to [Nicola] for the tip!

A black OLED screen with a happy face displayed upon it is situated at the top of a squarish calculator with a 5x6 grid of white calculator keys. It floats above a graphing calculator, Nintendo Switch, aigo numpad, and an Arduino Mega on a white table. A handful of differently-colored kalih choc switches are in various places around the table.

Mechanical Switch Sci-Calc Is Also A Macropad

Smartphones have replaced a desktop calculator for most folks these days, but sometimes that tactility is just what you need to get the mathematical juices flowing. Why not spruce up the scientific calculator of yore with the wonders of modern microcontrollers?

While you won’t be able to use Sci-Calc on a standardized test, this classy calculator will let you do some pretty cool things while clacking on its mechanical choc switches. Is it a calculator? Obviously. Is it an Arduboy-compatible device that can play simple games like your TI-84? Yes. Is it also a macropad and ESP32 dev board? Why not? If that isn’t enough, it’s also takes both standard and RPN inputs.

[Shao Duan] has really made this device clean and the menu system that rewrites main.bin based on the program selection is very clever. Escape writes main.bin back into the ROM from the SD card so you can select another application. A few classic games have already been ported, and the process looks fairly straightforward for any of your own favorites.

If you’re hankering for more mathy inputs, checkout the Mathboard or the MCM/70 from 1974.

Continue reading “Mechanical Switch Sci-Calc Is Also A Macropad”

Reverse Time Back To The Days Of RPN

While Texas Instruments maintains dominance in the calculator market (especially graphing calculators), there was a time when this wasn’t the case. HP famously built the first portable scientific calculator, the HP-35, although its reverse-Polish notation (RPN) might be a bit of a head-scratcher to those of us who came up in the TI world of the last three or four decades. Part of the reason TI is so dominant now is because they were the first to popularize infix notation, making the math on the calculator look much more like the math written on the page, especially when compared to the RPN used by HP calculators. But if you want to step into a time machine and see what that world was like without having to find a working HP-35, take a look at [Jeroen]’s DIY RPN calculator.

Since the calculator is going to be RPN-based, it needs to have a classic feel. For that, mechanical keyboard keys are used for the calculator buttons with a custom case to hold it all together. It uses two rows of seven-segment displays to show the current operation and the results. Programming the Arduino Nano to work as an RPN calculator involved a few tricks, though. [Jeroen] wanted a backspace button, but this disrupts the way that the Arduino handles the input and shows it on the display but it turns out there’s an Arudino library which solves some of these common problems with RPN builds like this.

One of the main reasons that RPN exists at all is that it is much easier for the processor in the calculator to understand the operations, even if it makes it a little bit harder for the human. This is because early calculators made much more overt use of a stack for performing operations in a similar way to Assembly language. Rather than learning Assembly, an RPN build like this can be a great introduction to this concept. If you want to get into the weeds of Assembly programming this is a great place to go to get started.

Learn GPU Programming With Simple Puzzles

Have you wanted to get into GPU programming with CUDA but found the usual textbooks and guides a bit too intense? Well, help is at hand in the form of a series of increasingly difficult programming ‘puzzles’ created by [Sasha Rush]. The first part of the simplification is to utilise the excellent NUMBA python JIT compiler to allow easy-to-understand code to be deployed as GPU machine code. Working on these puzzles is even easier if you use this linked Google Colab as your programming environment, launching you straight into a Jupyter notebook with the puzzles laid out. You can use your own GPU if you have one, but that’s not detailed.

The puzzles start, assuming you know nothing at all about GPU programming, which is totally the case for some of us! What’s really nice is the way the result of the program operation is displayed, showing graphically how data are read and written to the input and output arrays you’re working with. Each essential concept for CUDA programming is identified one at a time with a real programming example, making it a breeze to follow along. Just make sure you don’t watch the video below all the way through the first time, as in it [Sasha] explains all the solutions!

Confused about why you’d want to do this? Then perhaps check out our guide to CUDA first. We know what you’re thinking: how do we use non-nVIDIA hardware? Well, there’s SCALE for that! Finally, once you understand CUDA, why not have a play with WebGPU?

Continue reading “Learn GPU Programming With Simple Puzzles”

Get Your Lisp On With The Dune Shell

Lisp is one of those programming languages that seems to keep taunting us for not learning it properly. It is still used for teaching functional languages today. [Adam McDaniel] has an obvious fondness for this fifty-year-old language and has used it in several projects, including their own shell, Dune.

Dune is a shell designed for powerful scripting. Think of it as an unholy combination of bash and Lisp.

Dune is designed to be highly customisable, allowing you to create a super-optimised workstation for your admin and programming tasks. [Adam] describes the front end for Dune as having turned up the cosiness dial to eleven, and we can see that. A cosy home is personalised, and Dune lets you customise everything.

Dune is a useable functional programming environment with a reasonably complete standard library to back it up, which should simplify some of the more complicated sysadmin tasks. [Adam] says the language also supports a few metaprogramming concepts, such as a quote operator, operator overloading, and macro programming. It’s difficult to describe much more about what you can do with Dune, as it’s a general-purpose programming language wrapped in a shell. The possibilities are endless, and [Adam] is looking forward to seeing what you lot out there do with his project!

The shell can be personalised by editing the prelude file, which allows you to overload functions for the prompt text, the incomplete prompt text (so you can implement intelligent completion options), and a function that deals with the formatting of the command response text. [Adam] gives us his personal prelude file, which defines many helper functions displaying useful things such as the current weather, a calendar, and an ASCII art cat. You never know when that might come in handy. This file is written in Lisp, so we reckon that’s where many people will start as they come up the Lisp (re)learning curve before embarking on more involved automation. Dune was written in Rust, so you need that infrastructure to install it with Cargo.

As we said earlier, Lisp is not a new language. We found a hack for porting a Lisp interpreter to any old language and also running Lisp bare metal on a Lisp machine. Finally, [Al] takes a look at some alternative shells.

It’s Spreadsheets All The Way Down For This 80s Handheld

Unlike the today’s consumer computer market, the 1980s were the wild west in comparison. There were all kinds of different, incompatible operating systems, hardware, and programs, all competing against one another, and with essentially no networking to tie everything together. Some of these products were incredibly niche as well, only running one program or having a limited use case to keep costs down. Such was the Convergent WorkSlate, a computer that ran only a spreadsheet with any programs also needing to be built into a spreadsheet.

Upon booting the device, the user is presented with a fairly recognizable blank spreadsheet, albeit with a now-dated LCD display (lacking a backlight) and a bespoke keyboard and cursor that wouldn’t have allowed for easy touch typing. The spreadsheet itself is quite usable though, complete with formatting tools and the capability to use formulas like a modern spreadsheet program would. It also hosted a tape deck for audio and data storage, a modem for communicating with other devices, and an optional plotter-style printer. The modem port is how [Old VCR] eventually interfaces with the machine, although as one can imagine is quite a task for a piece of small-batch technology from the 80s like this. After learning how to send and receive information, a small game is programmed into the machine and then a Gopher interface is built to give the device limited Internet connectivity.

The investigation that [Old VCR] goes into on this project to get this obsolete yet unique piece of hardware running and programmed to do other tasks is impressive, and worth taking a look at especially because spreadsheets like this aren’t Turing-complete, leading to a few interesting phenomenon that most of us wouldn’t come across in the modern computing world. Since only around 60,000 units were ever made it’s difficult to come across these machines, but if you want to take a look at the spreadsheet world of the 80s without original hardware you can still run Lotus 1-2-3 natively in Linux today.

Thanks to [Cameron] for the tip!

Asteroids: Kessler Syndrome Edition

Asteroids, the late-70s arcade hit, was an immensely popular game. Often those with the simplest premise, while maintaining a fun, lighthearted gameplay have the most cultural impact and longest legacy. But, although it was popular, it doesn’t really meet the high bar of scientific fidelity that some gamers are looking for. That’s why [Attoparsec] built the Kessler Syndrome Edition of this classic arcade game.

The Kessler Syndrome is a condition where so much man-made debris piles up in low-Earth orbit that nothing can occupy this orbit without getting damaged or destroyed by the debris, and thus turning into more debris itself in a terrible positive feedback loop. [Attoparsec] brings this idea to Asteroids by reprogramming the game so that asteroids can be shot into smaller and smaller pieces but which never disappear, quickly turning the game into a runaway Kessler Syndrome where the chance of survival is extremely limited, and even a destroyed player’s ship turns into space junk as well.

To further the scientific accuracy and improve playability, though, he’s added a repulsor beam mechanism which can push the debris a bit and prolong the player’s life, and also added mass effect reactions so that even shooting bullets repels the player’s ship a bit. The build doesn’t stop with software, either. He also built a custom 70s-style arcade cabinet from the ground to host the game.

Asteroids is still a popular platform for unique builds like this. Take a look at a light-vector game using lasers to create the graphics, or this tiny version of the game that uses a real CRT.

Thanks to [smellsofbikes] for the tip!

Continue reading “Asteroids: Kessler Syndrome Edition”