TechyMagThings

Targeted towards refined female gamers unlike the savagery of the mainstream game consoles of the era, 1995’s Casio Loopy was a bit of an oddity of a game console. Despite being standard enough in its design and backed by the might of Casio, it saw only one year of active software development and hardware manufacturing ceased by the end of 1998. With only eleven titles released for the system, with none of them being Doom, this obviously terribly upset [Throaty Mumbo], who set out to right this egregious wrong.

For the two dozen people or so who have one of these systems, you can experience the fruits of his labor yourself via the GitHub repository and something like the FloopyDrive cartridge.. Despite the quite capable Hitachi SH-1 16 MHz CPU and 1 MB of RAM, the main limitation is probably the original 2 MB of ROM space that does not leave a lot of space for DOOM WADs, even after doubling it on the FloopyDrive. Correspondingly you only get a handful of levels out of it.

Overall game performance isn’t too bad, though in the port’s current unoptimized state the resolution is fairly low. That said, even the console’s built-in printer is supported and demonstrated in the video, which is a pretty nice touch. It’s not like Sega or Nintendo consoles allowed you to screenshot those glorious headshots.

As unique the Nintendo Wii U Gamepad may appear to be, at its core it’s pretty much just a tablet with game controls stuck on it. Now that the communication between the Wii U and the Gamepad have been fully reverse-engineered and poured into easy to use software, this opens the possibility of using other tablets with suitable controls on them for Wii U Gamepad purposes, like the Windows-capable Samsung tablet that [Bringus Studios] decided to experiment on.

Originally designed to run Windows XP Tablet PC Edition, the Samsung Q1 series of ultra-mobile PCs (UMPC) was first released in 2007, featuring a 900 MHz Celeron M CPU. Amusingly [Bingus] mixes up mAh and mWh when comparing battery capacities, as the Li-ion battery pack for this UMPC is an 11.1V one, whereas a smartphone battery is 3.7V nominal.

To turn this UMPC into a Wii U Gamepad, first 32-bit Debian 12 is installed along with the Vanilla Wii U Gamepad project. The main challenge then is to find a Wi-Fi adapter that works for this purpose, as the connection uses a slightly non-standard handshake. Naturally the TP-Link USB WiFi adapter that [Bingus] used changed from its previous and better supported Mediatek chipset to a Realtek one with typical poor Linux support, requiring manual driver compiling.

After more troubleshooting, it’s unfortunately found that the 900 MHz Celeron M in this UMPC just isn’t up to the task, with the decoding of the compressed HDMI stream correspondingly pegging the CPU at 100% with all the frame dropping. It’s likely that this is due to a lack of h.264 hardware decoding support, as this would push this burden onto the CPU. The system uses the Intel 915GMS chipset with the GMA 900 iGPU, which appears to just provide hardware acceleration for MPEG 2.

Online publications sometimes work with sponsors. Over at the Autopian, they landed a sponsorship deal with eBay, but due to an unguarded comment, fulfilling the sponsor’s requirements turned out to be something of a handful. Build a brand-new, completely WW2-spec Jeep using only parts sourced from the auction site, and drive it to Moab for an event. [David Tracy] set to work, and the resulting write-up is a build of epic proportions.

Of course, many Jeeps have been built since the war, not least by Willys and its successors, but also by enthusiasts. You can even buy a modern-day visible derivative of the original made in America by the Indian company Mahindra, which has been licensed to build Jeeps since the 1940s. So his claim of making the first new WW2-spec Jeep since the war may be difficult to substantiate, but it’s certain that his attention to period detail is exceptional. For example, most people would either use a more modern engine or find a second-hand original. Instead, he sources a brand new block from France and builds a new engine from scratch. And is that the infamously flawed early Jeep steering system we spy? The vehicle uses second-hand parts for other major drive train components, but the chassis and body are made in the Philippines.

An early Jeep is a simple vehicle, but following his build, you realise the power of the manufacturing industry, as so many individual parts and assemblies must come together to make the finished machine. Some of us have had old cars in our lives, so we appreciate this very well. The moment of completion comes with very little testing time to spare, and he’s off on the long drive from LA to Moab. That in itself could make an epic write-up, and yet again, we recognise the combination of willpower and worry. All of this has made us idly want one of these wildly impractical but seductive vehicles, but we know it will pass. If you aren’t interested in authenticity, you can always meld a Jeep with a Prius.

MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their leage in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [FabianKuebler]’s port of MicroPython.

Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.

As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at  3.58 MHz, and after that you can watch some sprites be bounced at a blistering 0.8 fps on the simulated PPU. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port– if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.

Putting python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense– the kind of micros you run MicroPython on can emulate the SNES.

Thanks to [Fabian] for the tip!

We’re not exactly sure how old [SnailMail] is, but he’s probably a member of Generation Alpha considering that to our wizened eyes the lad looks only slightly older than a fetus– which makes it all the more impressive that he’s written his own text editor, from scratch, in C– on a 386. See, [SnailMail] tried to learn the modern way, with IDEs that have code completion and AI integration, but his thoughts couldn’t gel in the modern environment. So he went online and bought an old IBM-compatible complete with monochrome amber monitor, and a whole 4MB of RAM. Big spender that he is, [SnailMail] upgraded that to 8MB.

Rather than fall victim to the siren song of Wolfenstien 3D or SimCity, he set out to learn to code: C, specifically, since that language bridges four decades between [SnailMail] and his new PC. Even more specifically, he got ahold of disks for Borland Turbo C and Turbo C++, which brings back memories for some of us. Of course the lad also had to learn how to use a DOS PC at the same time, but a teen in the 80s with a fresh box would have climbed the same steep learning curve. Some of you probably remember doing so yourselves. Just like you–or the hypothetical teen in the 80s–[SnailMail] did it not by googling or begging Claude for answers, but by digging into books. Many books.

After all the reading, he started with a text editor, something we remember being a pretty big project not given to first year students. Video evidence suggests he pulled it off. He describes how his solution works from about 8:00 in the video, so you greybeards in the audience can judge his work for yourself.

If you’re a member of Gen Alpha reading this and looking to learn to program, we cannot recommend this technique highly enough– [SnailMail] is going to have a better understanding of the underlying logic of computer science than a lot of CS grads being frocked today. Especially when you consider he ends by promising to learn assembly, something we heartily endorse.

Having a pump in a remote location where you aren’t constantly monitoring it is a common scenario, which can be unfortunate when said pump runs into problems like a dry well, jammed impeller or power issues. This is where pump monitors like the older SymCom (now Littelfuse) PumpSaver Plus 233P will protect the pump if such conditions are detected. Of course, the infrared communication port on it uses an undocumented protocol that was meant to be used with a long-since discontinued handheld device. Ergo [Elizabeth Camporeale] saw fit to reverse-engineer this protocol.

In the installation manual for this device this Informer unit is briefly mentioned along with the information it will display on its screen, making it clear that it’s quite literally just there to act as a display for the information that’s constantly generated on this interface. Naturally, this is incredibly useful if you wish to tie the system into a wider monitoring and automation system.

Somewhat unusual, this IR interface on the used 233P-1.5 unit turned out to be use a 5,000 baud NRZ, MSB-first protocol, with the juicy details fully documented and a Python-based decoder implementation provided.

Naturally [Elizabeth] didn’t just reverse-engineer this for the fun of it, but also for ESPHome integration. This uses a setup as can be seen in the top image, with an ESP32-C6 module providing the processing power and Wi-Fi, with a standard phototransistor recording the data pumped out by the pump monitor.

If you’re not aware, there is such a thing as adorable little three digit LCD 7-segment displays. They come in a ten-pin DIP package and are just begging to be integrated into a project. The catch is they are just a tiny bit weird. Luckily for us all, [Nagy Krisztián] spells out exactly how to use them.

The first odd thing about these ten-pin LCD displays have a footprint that doesn’t quite mesh with standard 0.1 inch spacing, meaning they will not cleanly fit into a breadboard. Luckily, one can solve this with a bit of force. It’s a small part, and the pins don’t seem to mind.

The second odd thing is wrapping one’s head around the pin mapping. Figuring out which pins activate which segments in the digits is easier if one keeps in mind that each segment of each digit is the product of two different pins. For example, “2A” is digit two, segment A, and is the product of pins 3 and COM4.

That’s not all. Electrically speaking, driving this LCD isn’t nearly as straightforward as an LED.

With an LED display, the COM pins are either common anode or common cathode, which tells one whether lighting up a segment means holding the COM pin at GND with voltage applied to the segment pin, or the other way around. But in the case of this LCD display, the polarity applied is swapped every cycle. Oh, and inactive COM pins need to held at half-voltage. Neat!

[Nagy] drives the whole thing with little more than an ATtiny84 microcontroller and a few resistors. A switchable half-voltage signal is cleverly created by combining a simple voltage divider and taking advantage of the fact that the ATtiny84’s pins can be in one of three different states depending on how they are configured: high, low, or high-impedance (pin configured as an input). Each COM pin on the display gets connected to both an ATtiny84 pin, and to the supply voltage via two resistors forming a voltage divider. When the ATtiny drives the pin high, the LCD pin sees about 3 V. When the pin is driven LOW, the LCD pin sees 0 V. When the ATtiny configures the pin as an input, the LCD pin receives about 1.5 V.

The bulk of the software is defining which pins and states equal which digits, and cycling the LCD at a rate of vaguely 60 Hz which delivers flicker-free results.

We appreciate the clever combination of voltage divider with pin configuration to create three switchable voltage levels. If you liked that and want to see more serious leveraging of pin configuration on a microcontroller, check out how to drive seven LEDs with only two pins.