Why AI Usage May Degrade Human Cognition And Blunt Critical Thinking Skills

February 13, 2025 by Maya Posch 94 Comments

Any statement regarding the potential benefits and/or hazards of AI tends to be automatically very divisive and controversial as the world tries to figure out what the technology means to them, and how to make the most money off it in the process. Either meaning Artificial Inference or Artificial Intelligence depending on who you ask, AI has seen itself used mostly as a way to ‘assist’ people. Whether in the form of a chat client to answer casual questions, or to generate articles, images and code, its proponents claim that it’ll make workers more efficient and remove tedium.

In a recent paper published by researchers at Microsoft and Carnegie Mellon University (CMU) the findings from a survey are however that the effect is mostly negative. The general conclusion is that by forcing people to rely on external tools for basic tasks, they become less capable and prepared of doing such things themselves, should the need arise. A related example is provided by Emanuel Maiberg in his commentary on this study when he notes how simple things like memorizing phone numbers and routes within a city are deemed irrelevant, but what if you end up without a working smartphone?

Does so-called generative AI (GAI) turn workers into monkeys who mindlessly regurgitate whatever falls out of the Magic Machine, or is there true potential for removing tedium and increasing productivity?

Continue reading “Why AI Usage May Degrade Human Cognition And Blunt Critical Thinking Skills” →

A Programming Language For Building NES Games

February 8, 2025 by Tom Nardi 27 Comments

Generally speaking, writing your own games for retro consoles starts with C code. You’ll need to feed that through a console-specific tool-chain, and there’s certainly going to be some hoops to jump through, but if everything goes as expected, you should end up with a ROM file that can be run in an emulator or played on real hardware if you’ve got the necessary gadgetry to load it.

But NESFab takes things in a slightly different direction. While the code might look like C, it’s actually a language specifically tailored for developing games on the Nintendo Entertainment System (NES). The documentation claims that this targeted language not only compiles into considerably faster 6502 assembly than plain C on GCC or LLVM, but is designed to work around the strengths (and weaknesses) of the NES hardware.

Looking deeper into the example programs and documentation, NESFab offers quite a few quality of life features that should make developing NES games easier. For one thing, there’s integrated asset loading which automatically converts your image files into something the console can understand. One just needs to drop the image file into the source directory, open it in the code with the file function, and the build system will take care of converting it on the fly as the ROM is built. The nuances of bank switching — the organization of code and assets so they fit onto the physical ROM chips on the NES cartridge — are similarly abstracted away.

The obvious downside of NESFab is that, as with something like GB Studio, you’re going to end up putting effort into learning a programming environment that works for just one system. So before you get started, you really need to decide what your goals are. If you’re a diehard NES fan that has no interest in working on other systems, learning a language and build environment specifically geared to that console might make a certain degree of sense. But if you’d like to see your masterpiece running on more than just one system, working in straight C is still going to be your best bet.

Using AI To Help With Assembly

November 7, 2024 by Bryan Cockfield 30 Comments

Although generative AI and large language models have been pushed as direct replacements for certain kinds of workers, plenty of businesses actually doing this have found that using this new technology can cause more problems than it solves when it is given free reign over tasks. While this might not be true indefinitely, the real use case for these tools right now is as a kind of assistant to certain kinds of work. For this they can be incredibly powerful as [Ricardo] demonstrates here, using Amazon Q to help with game development on the Commodore 64.

The first step here was to generate code that would show a sprite moving across the screen. The AI first generated code in all caps, as was the style at the time of the C64, but in [Ricardo]’s development environment this caused some major problems, so the code was converted to lowercase. A more impressive conversion was done in the next steps, as the program needed to take advantage of the optimizations found in the Assembly language. With the code converted to 6502 Assembly that can run on the virtual Commodore, [Ricardo] was eventually able to show four sprites moving across the screen after several iterations with the AI, as well as change the style of the sprites to arbitrary designs.

Although the post is a bit over-optimistic on Amazon Q as a tool specifically for developers, it might have some benefits over other generative AIs especially if it’s capable at the chore of programming in Assembly language. We’d love to hear anyone with real-world experience with this and whether it is truly worth the extra cost over something like Copilot or GPT 4. For any of these generative AI models, though, it’s probably worth trying them out while they’re in their early stages. Keep in mind that there’s a lot more than programming that can be done with some of them as well.

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

November 2, 2024 by Dave Rowntree 5 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.