The Tsushin Booster – A PC Engine Modem Add-on With A Twist

November 2, 2024 by Dave Rowntree 4 Comments

Sometimes, hardware projects get cancelled before they have a chance to make an impact, often due to politics or poor economic judgment. The Tsushin Booster for the PC Engine is one such project, possibly the victim of vicious commercial games between the leading Japanese console manufacturers at the tail end of the 1980s. It seems like a rather unlikely product: a modem attachment for a games console with an added 32 KB of battery-backed SRAM. In addition to the bolt-on unit, a dedicated software suite was provided on an EPROM-based removable cartridge, complete with a BASIC interpreter and a collection of graphical editor tools for game creation.

Internally, the Tsushin booster holds no surprises, with the expected POTS interfacing components tied to an OKI M6826L modem chip, the SRAM device, and what looks like a custom ASIC for the bus interfacing.

It was, however, very slow, topping out at only 1200 Baud, which, even for the period, coupled with pay-by-minute telephone charges, would be a hard sell. The provided software was clearly intended to inspire would-be games programmers, with a complete-looking BASIC dialect, a comms program, a basic sprite editor with support for animation and even a map editor. We think inputting BASIC code via a gamepad would get old fast, but it would work a little better for graphical editing.

PC Engine hacks are thin pickings around these parts, but to understand a little more about the ‘console wars’ of the early 1990s, look no further than this in-depth architectural study. If you’d like to get into the modem scene but lack original hardware, your needs could be satisfied with openmodem. Of course, once you’ve got the hardware sorted, you need some to connect to. How about creating your very own dial-up ISP?

Quake In 276 KB Of RAM

October 5, 2024 by Bryan Cockfield 20 Comments

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

October 4, 2024 by Navarre Bartz 6 Comments

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

September 26, 2024 by Bryan Cockfield 68 Comments

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

September 25, 2024 by Dave Rowntree 9 Comments

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

September 20, 2024 by Dave Rowntree 10 Comments

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

September 5, 2024 by Bryan Cockfield 9 Comments

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!