Seven New Street Fighter 2 Arcade Rom Hacks

[Sebastian Mihai] is a prolific programmer and hacker with a particular focus on retrocomputing and period games, and this latest hack, adding new gameplay elements to Capcom’s Street Fighter II – Champion Edition, is another great one. [Sebastian] was careful to resist changing the game physics, as that’s part of what makes this game ‘feel’ the way it does, but added some fun extra elements, such as the ability to catch birds, lob barrels at the other player, and dodge fire.

The title screen was updated for each of the different versions, so there is no doubt about which was being played. This work was based on their previous hacks to Knights of the Round. Since both games shared the same Capcom CPS-1 hardware, the existing 68000 toolchain could be reused, reducing the overhead for this new series of hacks. Continue reading “Seven New Street Fighter 2 Arcade Rom Hacks”

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!

From High Level Language To Assembly

If you cut your teeth on Z-80 assembly and have dabbled in other assembly languages, you might not find much mystery in creating programs using the next best thing to machine code. However, if you have only used high level languages, assembly can be somewhat daunting. [Shikaan] has an introductory article aimed to get you started at the “hello world” level of x86-64 assembly language. The second part is already up, too, and covers control structures.

You can argue that you may not need to know assembly language these days, and we’ll admit it’s certainly not as important as it used to be. However, there are unusual cases where you really need either the performance or the small footprint, which is only possible in assembly language. What’s more, it is super useful to be able to read assembly from your high-level tools when something goes wrong.

Of course, one of the problems is that each assembly language is different. For example, knowing that the x86 assembly doesn’t completely transfer to ARM instructions. However, in most cases, the general concepts apply, and it is usually fairly easy to learn your second, third, or fourth instruction set.

We’ve had our own tutorials on this topic. You can also debate if you should learn assembly first or wait, although in this case, the audience is people who waited.

2024 Tiny Games Contest: A Flappy Seagull Game With Sound In Only 500 Bytes

It was probably a reasonable assumption that the “Tiny” in our recently concluded Tiny Games Contest mostly referred to the physical footprint of the game. And indeed, that’s the way most of the entries broke, which resulted in some pretty amazing efforts. [Anders Nielsen], however, took the challenge another way and managed to stuff a seagull-centric side-scroller into just 500 bytes of code.

That’s not to say that the size of [Anders]’s game is physically huge either. Flappy Larus, as he calls his game, runs on his popular 65uino platform, a 6502 microcontroller in the familiar Arduino Uno form factor. So it’s pretty small to begin with, and doesn’t even need any additional components other than the tiny OLED screen which has become more or less standard for the 65uino at this point. The only real add-on is a piezo speaker module, which when hooked up to the I2C data line happens to make reasonable approximations of a squawking seagull, all without adding a single byte of code. Check out a little game play in the video below.

Flappy Larus may be pretty simplistic, but as we recall, the game it’s based on was similarly minimalist and still managed to get people hooked. The 2024 Tiny Games contest is closed now, but if you’ve got an idea for a tiny game, we’d still love to feature it. Hit the tip line and we’ll take a look! Continue reading “2024 Tiny Games Contest: A Flappy Seagull Game With Sound In Only 500 Bytes”

A black device with a monochrome LCD sits on a wooden table. It's keyboard extends below the frame. On the screen is the "Level 29" BBS service login.

Internet Appliance To Portable Terminal

Few processors have found themselves in so many different devices as the venerable Z80. While it isn’t powerful by modern standards, you can still use devices like this Cidco MailStation as a terminal.

The MailStation was originally designed as an email machine for people who weren’t onboard with this whole computer fad, keeping things simple with just an adjustable monchrome LCD, a keyboard, and a few basic applications. [Joshua Stein] developed a terminal application, msTERM, for the MailStation thanks to work previously done on decoding this device and the wealth of documentation for Z80 assembly.

While [Stein] designed his program to access BBSes, we wonder if it might be a good way to do some distraction-free writing. If that wasn’t enough, he also designed the WiFiStation dongle which lets you communicate over a network without all that tedious mucking about with parallel ports.

If you’d like something designed specifically for writing, how about an AlphaSmart? Wanting to build your own Z80-based project? Why not start with an Altoids-sized Z80 SBC, but don’t wait forever since Z80 production finally ended in June.

Continue reading “Internet Appliance To Portable Terminal”

Baldur’s Gate III Comes To The TRS-80 Model 100

To say that Tandy’s TRS-80 Model 100 was an influential piece of computer hardware would be something of an understatement. While there’s some debate over which computer can historically be called the “first laptop”, the Model 100 was early enough that it helped influence our modern idea of portable computing. It was also one of the most successful of these early portables, due in part to how easy it was to write your own software for it using the built-in BASIC interpreter.

But as handy and capable as that integrated development environment might have been, it never produced anything as impressive as this Baldur’s Gate III “demake” created by [Alex Bowen]. Written in assembly, the game’s engine implements a subset of the Dungeons & Dragons Systems Reference Document (SRD), and is flexible enough that you could use it to produce your own ASCII art role-playing game that can run on either a Model 100 emulator like Virtual-T or on the real hardware.

Continue reading Baldur’s Gate III Comes To The TRS-80 Model 100″

50-Year-Old Program Gets Speed Boost

At first glance, getting a computer program to run faster than the first electronic computers might seem trivial. After all, most of us carry enormously powerful processors in our pockets every day as if that’s normal. But [Mark] isn’t trying to beat computers like the ENIAC with a mobile ARM processor or other modern device. He’s now programming with the successor to the original Intel integrated circuit processor, the 4040, but beating the ENIAC is still little more complicated than you might think with a processor from 1974.

For this project, the goal was to best the 70-hour time set by ENIAC for computing the first 2035 digits of pi. There are a number of algorithms for performing this calculation, but using a 4-bit processor and an extremely limited memory of only 1280 bytes makes a number of these methods impossible, especially with the self-imposed time limit. The limited instruction set is a potential bottleneck as well with these early processors. [Mark] decided to use [Fabrice Bellard]’s algorithm given these limitations. He goes into great detail about the mathematics behind this method before coding it in JavaScript. Generating assembly language from a working JavaScript was found to be fairly straightforward.

[Mark] is also doing a lot of work on the 4040 to get this program running as well, including upgrades to the 40xx tool stack, the compiler and linker, and an emulator he’s using to test his program before sending it to physical hardware. The project is remarkably well-documented, including all of the optimizations needed to get these antique processors running fast enough to beat the ENIAC. We won’t spoil the results for you, but as a hint to how it worked out, he started this project using the 4040 since his original attempt using a 4004 wasn’t quite fast enough.