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”

Behold A First-Person 3D Maze, Vintage Atari Style

[Joe Musashi] was inspired by discussions about 3D engines and decided to create a first-person 3D maze of his own. The really neat part? It could have been done on vintage Atari hardware. Well, mostly.

He does admit he had to do a little cheating to make this work; he relies on code for the ARM processor in the modern Atari VCS do the ray casting work, and the 6507 chip just handles the display kernel. Still, running his demo on a vintage Atari 2600 console could be possible, but would definitely require a Melody or Harmony cartridge, which are special reprogrammable cartridges popular for development and homebrew.

Ray casting is a conceptually simple method of generating a 3D view from given perspective, and here’s a tutorial that will tell you all you need to know about how it works, and how to implement your own.

[Joe]’s demo is just a navigable 3D maze rather than a game, but it’s pretty wild to see what could in theory have run on such an old platform, even if a few modern cheats are needed to pull it off. And if you agree that it’s neat, then hold onto your hats because a full 3D ray casting game — complete with a micro physics engine — was perfectly doable on the Commodore PET, which even had the additional limitation of a monochrome character-based display.

Winamp Taken Down: Too Good For This Open Source World

If you picked today in your hackerspace’s sweepstake on when Winamp would pull their code repository, congratulations! You’re a winner! The source for the Windows version of the venerable music player was released on GitHub three weeks ago, and after some derision over its licence terms, a bunch of possible open source violations, and the inadvertent release of some proprietary third-party code, it’s been taken down. We’re sure that if you still have a burning desire to look at it then it won’t be too difficult to find a copy through your favorite search engine, leaving the question of what really just happened.

It’s fairly obvious that the owners of the code lacked some level of understanding of just what open source really is, based on their not-really-open licence and all those code leaks. They did back down on not allowing people to create forks, but it’s evident that they didn’t anticipate the reaction they got. So were they merely a bit clueless, or was it all just a publicity stunt involving a piece of software that’s now of more historical than practical interest? It’s possible we’ll never know, but the story has provided those of us sitting on the fence eating popcorn with some entertainment.

ANTIRTOS: No RTOS Needed

Embedded programming is a tricky task that looks straightforward to the uninitiated, but those with a few decades of experience know differently. Getting what you want to work predictably or even fit into the target can be challenging. When you get to a certain level of complexity, breaking code down into multiple tasks can become necessary, and then most of us will reach for a real-time operating system (RTOS), and the real fun begins. [Aleksei Tertychnyi] clearly understands such issues but instead came up with an alternative they call ANTIRTOS.

The idea behind the project is not to use an RTOS at all but to manage tasks deterministically by utilizing multiple queues of function pointers. The work results in an ultra-lightweight task management library targeting embedded platforms, whether Arduino-based or otherwise. It’s pure C++, so it generally doesn’t matter. The emphasis is on rapid interrupt response, which is, we know, critical to a good embedded design. Implemented as a single header file that is less than 350 lines long, it is not hard to understand (provided you know C++ templates!) and easy to extend to add needed features as they arise. A small code base also makes debugging easier. A vital point of the project is the management of delay routines. Instead of a plain delay(), you write a custom version that executes your short execution task queue, so no time is wasted. Of course, you have to plan how the tasks are grouped and scheduled and all the data flow issues, but that’s all the stuff you’d be doing anyway.

The GitHub project page has some clear examples and is the place to grab that header file to try it yourself. When you really need an RTOS, you have a lot of choices, mostly costing money, but here’s our guide to two popular open source projects: FreeRTOS and ChibiOS. Sometimes, an RTOS isn’t enough, so we design our own full OS from scratch — sort of.

A RISC-V LISP Compiler…Written In Lisp

Ah, Lisp, the archaic language that just keeps on giving. You either love or hate it, but you’ll never stop it. [David Johnson-Davies] is clearly in the love it camp and, to that end, has produced a fair number of tools wedging this language into all kinds of nooks and crannies. The particular nook in question is the RISC-V ISA, with their Lisp-to-RISC-V compiler. This project leads on from their RISC-V assembler by allowing a Lisp function to be compiled directly to assembly and then deployed as callable, provided you stick to the supported language subset, that is!

The fun thing is—you guessed it—it’s written in Lisp. In fact, both projects are pure Lisp and can be run on the uLisp core and deployed onto your microcontroller of choice. Because who wouldn’t want to compile Lisp on a Lisp machine? To add to the fun, [David] created a previous project targeting ARM, so you’ve got even fewer excuses for not being able to access this. If you’ve managed to get your paws on the new Raspberry Pi Pico-2, then you can take your pick and run Lisp on either core type and still compile to native.

The Lisp-Risc-V project can be found in this GitHub repo, with the other tools easy enough to locate.

We see a fair few Lisp projects on these pages. Here’s another bare metal Lisp implementation using AVR. And how many lines of code does it take to implement Lisp anyway? The answer is 42 200 lines of C, to be exact.

A stylized image of Haskell code from the article

Alphabet Soup: Haskell’s Single-Letter Naming Quirks

When you used punch cards or tape to write a computer program, brief variable names were the norm. Your compiler or assembler probably only allowed six letters, anyway. But times change, and people who, by habit, give array indices variable names like I, J, or K get a lot of grief. But [Jack Kelly] points out that for highly polymorphic languages like Haskell, you often don’t know what that variable represents anyway. So how are you supposed to name it? He provides a guide to one-letter variable names commonly used by Haskell developers and, sometimes, others.

Haskell’s conventions are particularly interesting, especially with i, j, and k, which are borrowed from mathematical tradition to signify indices or integers and passed on via Fortran. The article also highlights how m often refers to Monads and Monoidal values, while t can represent both traversables and text values. Perhaps more obscurely, p can denote profunctors and predicates, giving a glimpse into Haskell’s complex yet efficient type system. These naming conventions are not formal standards but have evolved into a grass-roots lexicon.

Of course, you can go too far. We see a lot of interesting and strange things written in Haskell, including this OpenSCAD competitor.

Supercon 2023: Thea Flowers Renders KiCad Projects On The Web

Last year’s Supercon, we’ve had the pleasure of hosting Thea [Stargirl] Flowers, who told us about her KiCanvas project, with its trials, its tribulations, and its triumphs. KiCanvas brings interactive display of KiCad boards and schematics into your browser, letting you embed your PCB’s information right into your blog post or online documentation.

Give the KiCanvas plugin a URL to your KiCad file, and it will render your file in the browser, fully on the fly. There’s no .jpg to update and re-upload, no jobs to re-run each time you find a mistake and update your board – your files are always up to date, and your audience is always able to check it out without launching KiCad.

Images are an intuitive representation for schematics and PCB files, but they’re letting hackers down massively. Thea’s KiCanvas project is about making our KiCad projects all that more accessible to newcomers, and it’s succeeded – nowadays, you can encounter KiCanvas schematic embeds in the wild on various hackers’ blogs. The Typescript code didn’t write itself, and neither was it easy – she’s brought a fair few war stories to the DesignLab stage.

A hacker’s passion to share can move mountains. Thea’s task was a formidable one, too – KiCad is a monumental project with a decades-long history. There are quite respectable reasons for someone to move this particular mountain – helping you share your projects quickly but extensively, and letting people learn about your projects without breaking a sweat.

Continue reading “Supercon 2023: Thea Flowers Renders KiCad Projects On The Web”