TechyMagThings

COBOL is not the first language anyone would ever think of when writing a First Person Shooter– after all , it’s the Common Business Oriented Language, not the Common Game Oriented Language. For Youtube-based hacker [icitry] though, that’s the point. The only way to determine if COBOL would be enough to write an FPS game was to do it.

Sure, you could rest on your laurels knowing that the language is Turing complete and therefore capable by definition, but what’s the fun in that? Now the pipeline for this game is as hacky as anything– COBOL doesn’t exactly have a robust graphics stack or a lot of libraries for pushing pixles, so he’s outputting each frame of the game as raw bitmap to STDOUT, and letting ffplay assemble the images. Control enters the same way, with the terminal set to raw input and the COBOL program reading STDIN.

As for what the images consist of, he’s going for a standard Wolfenstien-inspired raycasting shooter. [icitr] provides a decent explanation of the raycasting algorithm, along with why implementing in COBOL is a silly thing to try. That’s a theme here; he’s able to implement sprites and the logic to move and attack enemies, while constantly complaining about COBOL. If that wasn’t enough, he adds variable-height sectors to bring this much closer to a true DOOM clone. By the end, there’s a full game. It’s all up on GitHub on an Apache license.

While this video is not the most gentle introduction to COBOL, it does show you can hack the business-specific language to do whatever you’d like.

Although cryocoolers are capable of pretty impressive cooling, for many of them the underlying working principle is simple enough that you do not need any special skills or a big budget to make your own version. Take the Gifford-McMahon cryocooler for example, which works using nothing more than some kind of coolant gas and a piston in a cylinder that you can even 3D print, as demonstrated by [Hyperspace Pirate] in a recent video.

The lowest temperature reached across the two prototypes was only -84°C, but this was mostly due to some sub-optimal design choices, such as the use of regular air and a clear acrylic tube to get a good glimpse at the inner workings. The trickiest part of this type of cryocooler is probably that you need to move the piston containing the regenerator between both ends of the cylinder to get a cool and a hot side.

That particular problem was solved by using magnets to move the piston externally, which worked beautifully until the problem of using regular compressed air from the shop compressor caused massive ice formation that jammed up the piston. Obviously this was not an unexpected issue, and for the next step the coolant gas will be replaced by helium, as making that gas freeze up requires quite a bit more effort.

A good demo, like [Linus Akesson]’s Sum Ergo Demonstrato, looks like magic to the average hacker. To normies who don’t know the limitations of the RP2350, they don’t see the big deal. To anyone who has spent any time with the chip, though, it’s a series of tricks you cannot help but be amazed by. Fortuanately for us, [Linus] isn’t actually a magician, because while a magician never reveals his tricks, [Linus] has an hour-long video explaining exactly how his demo was accomplished. We’ve embedded both the demo and the explanation below.

Even if you aren’t into YouTube, you should check out the demo video, and again– remember this is all on a Pi Pico with only the extra passives required for video-out. Then you can watch [Linus] explain how he did it, which is really best heard in his own words. There are a couple of bleeding-edge tricks on the RISC V core and peripherals that we would hate to misrepresent– especially the clever hack with the interpolator that he uses for 3D acceleration.

If this sounds a bit familiar, it’s because we were equally impressed by his Kaleidoscopico demo last year. From demos like this to 3D engines on the ESP32, its amazing what you can do on modern micros if you’re willing to hit the limits of the hardware.

Thanks to [Stephen Walters] for the tip!

The Demo:

Technical video:

If you’ve ever worked with I2C, you know its one of those things that makes working with modern microcontrollers such a pleasure. With a few wires and not many more lines of code, you can communicate with all sorts of hardware such as sensors, displays, and input devices. There are even I2C keyboards out there, although they tend to be a bit pokey — and not in the good way as it pertains to keyboards.

But the bt2i2c project from [Roberto Alsina] promises to improve things. With his firmware flashed to a Pi Pico W, you can establish a connection with any standard Bluetooth keyboard and have the keystrokes sent over the wire via I2C. As far as your project is concerned, the input will appear to be coming from a BlackBerry BBQ20/BBQ10 keyboard using the address 0x1F, which means that there’s already plenty of code out there to work with. While [Roberto] explains its not strictly necessary, connecting a ST7789 display to the Pi Pico over SPI will give you some visual feedback on connection status.

As microcontrollers become increasingly powerful and capable of the sort of thing we would once have done on a “real” computer, a project like this has some fascinating potential. We’ve seen a number of “writerdeck” projects running on chips like the ESP32, and it’s not hard to see the appeal of being able to easily pair your favorite Bluetooth keyboard up to one of them.

Back in 1996 the 3D gaming market on PC was beginning to heat up, with hot new titles like Tomb Raider coming out that year and requiring much more graphics power than what was needed for old titles like Doom and Duke Nukem 3D to experience good graphics. Thus you had to pick some kind of 3D accelerator card to buy. Here a common joke was that of the available options, the S3 Virge GPU was so bad that it was actually worse than running in software rendering, but was this true? Cue [Bits und Bolts]’s investigation to finally put this myth to rest.

On software rendering mode a zippy Pentium 166 would struggle to render at 640×480 resolution, so if you wanted more than 320×240, or really knock down graphical fidelity, you had to get that 3D accelerator card. After combining a P166 with an S3 Virge/DX – a minor update to the original Virge – the Tomb Raider game was first compared while running in 512×384 resolution, which the game offers you with an S3 card installed along with bilinear filtering.

After hitting a capped 30 FPS on that first test, 640×480 was tried and hit a solid 15 FPS with bilinear filtering enabled, but the conclusion is basically that the special 512×384 resolution mode is pretty good. Perhaps the main causes of the myth was the wide variability in quality of the various GPUs using the S3 Virge chip, as well as trying to run at anything other than this special resolution which appears to target the card’s strengths.

Unlike resin printers where you generally just pour the fresh resin into the easily accessible vat, FDM printers need to squirrel away at least one spool and its requisite holder somewhere. For bed slingers this generally means a top-mounted spool holder, while for CoreXY enclosed printers they can appear on the sides, top or – inexplicably – on the back. While a side-mounted spool is often convenient, access to the side can still be blocked, in which case you do what [3D Maker Noob] did and over-engineer a fancy top-mounted spool holder.

The problem started after converting a Prusa Mk4S to a Core One using the conversion kit, which changes the position of the spool, forcing him to work around not having access to the right side of the machine where the default position is. After a first version using many of the left-over parts of the original Mk4S to create a fancy box-shaped spool holder, he proceeded to upgrade it as detailed in the video. All project files and instructions are available on Printables.

The result is a box you stack on top of the printer somewhat like a multi-spool box, just flatter and with a flippy lid on the front from which a rail slides out with the magnetically attached spool holder. A spool holder which you naturally can further customize to fit different spools. Even if over-engineered, you can’t deny that it would fit in confined spaces and looks pretty good while doing its job.

It’s become an accepted truth amongst tapeheads that there’s no point looking at new hardware, because there’s only one tape mechanism being made anywhere in the world anymore, and that it sucks. [VWestlife] may enjoy German automobiles, based on the name, but he’s also a tapehead– and he took the time to demonstrate on YouTube that the accepted truth just ain’t so.

The supposed One Mechanism to Rule Them All in Lo-Fi is designed or made by Chinese company Tanishin. Certainly Tanishin does make a tape mechanism, but as [VWestlife] demonstrates with a few teardowns, there’s absolutely more than one on the market. That doesn’t mean any of the new offerings will out-compete your vintage Sony Walkman, but it does mean there are differences worth considering if you were to buy new.

Note that it is handhelds like the Walkman being talked about– it must be, since there are both slot-loading and flip-loading decks still being made, and even if you’re not a tapehead you should be able to tell that those won’t share the same part on the BOM.

With a few teardowns, he finds three separate mechanisms, followed by a deep-dive into the Tanishin. If you’re looking to buy a new walkman– or perhaps use its guts to build a mass storage device-– you might want to watch the whole thing to help you pick. On the other hand, the mechanism doesn’t matter that much, as he points out. It brings the tape over the head, but that’s not difficult. Everything else– from the motor that needs to draw the tape out evenly, to the pickup and the preamps and amplifiers–is where noise and poor quality sound tends to creep in, especially when something’s built to a budget.

Overall, [VWestlife] takes pains to point out that these ‘crappy’ new players aren’t any worse than the original Sony Walkman– we’ve just been spoiled by decades of better media than the humble compact cassette. That’s no slight against the cassette– people are still pushing its limits to this day, like this insanely fast vacuum-driven mechanism we featured.

Thanks to [Stephen Walters] for the tip!