Turning a game like Super Mario World for SNES into a widescreen game is not a small task, but [Vitor Vilela] accomplished just that. [Vitor] has a long list of incredible patches such as optimizing code for better frame rates and adding code to take advantage of the SA-1 accelerator chip, so out of anyone he has the know-how to pull a widescreen mod off. This patch represents a true labor of love as many levels were designed with a specific screen width in mind. [Vitor] went through each of these single-screen width levels and expanded them by writing the extra assembly needed.
On a technical level, this hack was achieved by using the panning feature built into the game. The left and right shoulder buttons allowed a player to pan the camera to the left and right. The viewport is considered to be two times the screen resolution and so items will be rendered within the widescreen resolution. By taking away the panning feature and render a larger section of the viewport to the screen, you get a widescreen view. However, to save cycles, enemies and items don’t start moving until they get close to the screen edge. So how do you make a game widescreen without ruining the timing of every enemy that spawns? Suddenly the hours of muscle memory that fans have drilled in over the years is a disadvantage rather than a strength. The answer is a significant time investment and an eye for detail.
All the code is available on GitHub. A video of a playthrough of the mod is after the break.
Game developer and eternal learner [David Tucker] just posted a project where he’s making linear flexures on a 3D printer. Tinkerer [Tucker] wanted something that would be rigid in five of the six degrees of freedom, but would provide linear motion along one axis. In this case, it is for a pen or knife on a CNC flatbed device. [David]’s design combines the properties of a 1-dimensional flexure and a spring to give a constant downward force. Not only is this an interesting build in and of itself, but he gives a good explanation and examples of more traditional flexible constructs. He also points out this site by MIT Precision Compliant Systems Lab engineer [Marcel Thomas] which provides a wealth of information on flexures.
Let’s face it: pretty much everything about e-textiles is fiddly. If wearables were easy, more people would probably work in that space. But whereas most circuit prototyping is done in two dimensions, the prototyping of wearables requires thinking and planning in 3D. On top of that, you have to figure out how much conductive thread you need, and that stuff’s not cheap.
[alch_emist] has a method for arranging circuits in 3D space that addresses the harsh realities of trying to prototype wearables. There’s that whole gravity thing to deal with, and then of course there are no straight lines anywhere on the human body. So here’s how it works: [alch_emist] made a bunch of reusable tie points designed to work with an adhesive substrate such as felt. They laser-cut a set of acrylic squares and drilled a hole in each one to accommodate a neodymium magnet. On the back of each square is a small piece of the hook side of hook-and-loop tape, which makes the tie points stay put on the felt, but rearrange easily.
We love the idea of prototyping with felt because it’s such a cheap and versatile fabric, and because you can easily wrap it around your arm or leg and see how the circuit will move when you do.
If you’re looking for a reminder of how powerful the tiny microcontrollers that run our everyday gadgets have become, check out the work impressive work [Audun Wilhelmsen] has done to get DOOM running on the Nordic Semiconductor nRF5340. This is the sort of Bluetooth SoC you’d expect to find in a headset or wireless keyboard, and yet it’s packing a 128 MHz processor that can go head to head with the Intel 486 that the iconic first person shooter recommended you have in your old beige box PC.
That said, porting the open source shooter over to the nRF5340 wasn’t exactly easy. The challenge was getting the game, which recommended your PC have 8 MB back in 1993, to run on a microcontroller with a paltry 512 KB of memory. Luckily, a lot of the data the game loads into RAM is static. While that might have been necessary when the game was running from a pokey IDE hard drive, the nearly instantaneous access times of solid state storage and the nRF5340’s execute in place (XIP) capability meant [Audun] could move all of that over to an SPI-connected 8 MB flash chip with some tweaks to the code.
In general, [Audun] explains that many of the design decisions made for the original DOOM engine were made with the assumption that the limiting factor would be CPU power rather than RAM. So that lead to things often getting pre-calculated and stored in memory for instant access. But with the extra horsepower of the nRF5340, it was often helpful to flip this dynamic over and reverse the optimizations made by the original developers.
On the hardware side, things are relatively straightforward. The 4.3″ 800×480 LCD display is connected over SPI, and an I2S DAC handles the sound. Bluetooth would have been the logical choice for the controls, but to keep things simple, [Audun] ended up using a BBC micro:bit that could communicate with the nRF5340 via Nordic’s own proprietary protocol. Though he does note that Bluetooth mouse and keyboard support is something he’d like to implement eventually.
For a couple of years, embedded developer and Rust addict [Jonathan Pallant] aka [theJPster] has been working on a simple computer which he calls the Neotron. The idea is to make a computer that is not only easy to use but easy to understand as well. He describes it as a CP/M- or DOS-like operating system for small ARM microcontrollers. His most recent project is powered by a Raspberry Pi RP2040 Pico and built in the format of a microATX motherboard. This board packs a lot of features for a Pico-based design, including 12-bit color VGA and seven expansion slots. See his GitHub repository for a full list of specifications, and all the files needed to build your own — it is an Open Source project after all.
Besides the Neotron Pico itself, a couple of gems caught our eye in this well-documented project. [theJPster] was running out of I/O pins on the Pico, and didn’t have enough left over for all the peripherals’ chip selects. Check out how he uses an MCP23S17 SPI-bus I/O expander and a tri-state buffer to solve the problem.
On a more meta level, we are intrigued by his use of GitHub Actions. Per the standard concept of repositories, they shouldn’t contain the results of a build, be that an executable binary or Gerber files. Distribution of the build products is typically handled outside of GitHub, using something like GitHub’s Large File Storage service, or just ignoring convention altogether and putting them in the repo anyway. [theJPster] uses another method, employing GitHub Actions to generate the files needed for PCB fabrication, for example.
The Neotron Pico is the latest in a series of boards made to run Neotron OS. Previous boards include:
You don’t often turn on a light and think, “That power company is sure on the ball!” You generally only think of them when the lights go out without warning. I think the same is true of search. You don’t use Google or DuckDuckGo or any of the other search engines and think “Wow! How awesome it is to have this much information at your fingertips.” Well. Maybe a little, but it is hard to remember just how hard it was to get at information in the pre-search-engine age.
I were thinking about this the other day when I read that Ruth Freitag had died last year. Ruth had the unglamorous but very important title of reference librarian. But she wasn’t just an ordinary librarian. She worked for the Library of Congress and was famous in certain circles, counting among her admirers Isaac Asimov and Carl Sagan.
You might wonder why a reference librarian would have fans. Turns out, high-powered librarians do more than just find books on the shelves for you. They produced bibliographies. If you wanted to know about, say, Halley’s comet today, you’d just do a Google search. Even if you wanted to find physical books, there are plenty of places to search: Google Books, online bookstores, and so on. But in the 1970s your options were much more limited.
Turns out, Ruth had an interest and expertise in astronomy, but she also had a keen knowledge of science and technology in general. By assembling comprehensive annotated bibliographies she could point people like Asimov and Sagan to the books they needed just like we would use Google, today.
Our first thought was that having big fins coming out of your VR goggles might not look very cool. But then we realized if you are wearing VR goggles, that’s probably not your biggest concern. (Ba-doom, tss.) Seriously, though, high-intensity graphics can cause your phone or device to get pretty toasty up there pressed against your face, so [arfish] set out to make a heatsink.
The build isn’t very hard. Some 0.8 mm aluminum sheet is easy to shape and cut. Thermal pads from the PC world help with heat transfer.