Hackaday-feed 🤖

@Hackaday-feed

Hardware hacking blog

hackaday.com/

Presented as a Cohost Page by @RSS-feeds bot

(Btw, ppl who like this page may also like @twostopbits-feed)

Hackaday-feed 🤖@Hackaday-feed9/10/2024, 3:06 AM

DOOM on a Volumetric Display

Hackaday comments

Hackaday tags: classic hacks, Games, 3d, doom, volumetric, volumetric display

There’s something magical about volumetric displays. They really need to be perceived in person, and no amount of static or video photography will ever do them justice. [AncientJames] has built a few, and we’re reporting on his progress, mostly because he got it to run a playable port of DOOM.

Base view of an earlier version showing the motor drive and PSU

As we’ve seen before, DOOM is very much a 3D game viewed on a 2D display using all manner of clever tricks and optimizations. The background visual gives a 3D effect, but the game’s sprites are definitely very solidly in 2D land. As we’ll see, that wasn’t good enough for [James].

The basic concept relies on a pair of 128 x 64 LED display matrix modules sitting atop a rotating platform. The 3D printed platform holds the displays vertically, with the LEDs lined up with the diameter, meaning the electronics hang off the back, creating some imbalance.

Lead, in the form of the type used for traditional window leading, was used as a counterbalance. A Raspberry Pi 4 with a modified version of this LED driver HAT is rotating with the displays. The Pi and both displays are fed power from individual Mini560 buck modules, taking their input from a 12 V 100 W Mean-Well power supply via a car alternator slip ring setup. (Part numbers ABH6004S and ASL9009 for those interested.) Finally, to synchronise the setup, a simple IR photo interrupter signals the Pi via an interrupt.

The second version running Doom

The base contains a DC motor driving the platform with a 224:20 reduction ratio using a GT2 timing belt to help reduce noise. [James] reports that running at 700 RPM was the limit for the current version, giving an acceptable update frame rate. Too high, and the vibration and chassis flex was excessive. The base does little else other than house that power supply and support a 400 mm acrylic garden light dome. We wouldn’t want to run this without such protection, which might not even be enough.

There are quite a few details to consider in such a build. One is the need to reduce the angle of perception of the LED display using a 3D printed slat-type collimator in front of each unit. You only want to perceive the LEDs head-on, or the POV effect is ruined. However, most of the details are in the software.

To that end, [James] took the entire game logic of the ‘Doom Generic’ port, removing the code that renders the 3D parts of the scene. The 2D menus and in-game panels are rendered by projecting the image onto a cylinder. That was easy. [James] took a minimalist path for the room scenes, as fully solid walls looked too busy. The viewport automatically zooms into any ongoing battles, so monsters zoom into focus if nearby, but objects behind closed doors and too far around corners are discarded. No spoiler alerts! The models were lifted from Chello’s Voxel Doom mod, giving a fitting 3D upgrade to gameplay. This is an ongoing project, so we’ll keep track and report back!

We’ve reported on a few volumetric displays over the years, like this tiny one based on an OLED display. Even a volumetric CCTV system. But they can’t run DOOM. Speaking of which, here’s what it looks like ray-traced.

Thanks to [Keith] for the tip!

Hackaday-feed 🤖@Hackaday-feed9/9/2024, 11:57 PM

PC Floppy Copy Protection: Softguard Superlok

Hackaday comments

Hackaday tags: Retrocomputing, Reverse Engineering, copy protection, reverse engineering

Many have sought the holy grail of making commercial media both readable and copy-proof, especially once everyone began to copy those floppies. One of these attempts to make floppies copy-proof was Softguard’s Superlok. This in-depth look at this copy protection system by [GloriousCow] comes on the heels of a part 1 that covers Formaster’s Copy-Lock. Interestingly, Sierra switched from Copy-Lock to Superlok for their DOS version of games like King’s Quest, following the industry’s quest in search of this holy grail.

The way that Superlok works is that it loads a (hidden) executable called CPC.COM which proceeds to read the 128 byte key that is stored on a special track 6. With this key the game’s executable is decoded and fun can commence. Without a valid ‘Play’ disk containing the special track and CPC.COM executable all one is instead left with is a request by the game to ‘insert your ORIGINAL disk 1’.

Sierra’s King Quest v1.0 for DOS.

As one can see in the Norton Commander screenshot of a Sierra game disk, the hidden file is easily uncovered in any application that supports showing hidden files. However, CPC.COM couldn’t be executed directly; it needs to be executed from a memory buffer and passed the correct stack parameters. Sierra likely put in very little effort when implementing Softguard’s solution in their products, as Superlok supports changing the encryption key offset and other ways to make life hard for crackers.

Sierra was using version 2.3 of Superlok, but Softguard would also make a version 3.0. This is quite similar to 2.x, but has a gotcha in that it reads across the track index for the outer sector. This requires track wrapping to be implemented. Far from this kind of copy protection cracking being a recent thing, there was a thriving market for products that would circumvent these protections, all the way up to Central Point’s Copy II PC Option Board that would man-in-the-middle between the floppy disk drive and the CPU, intercepting data and render those copy protections pointless.

As for the fate of Softguard, by the end of the 1980s many of its customers were tiring of the cat-and-mouse game between crackers and Softguard, along with issues reported by legitimate users. Customers like Infographics Inc. dropped the Superlok protection by 1987 and by 1992 Softguard was out of business.

Hackaday-feed 🤖@Hackaday-feed9/9/2024, 8:48 PM

This Tiny Steam Engine Takes a Watchmaker’s Skill to Build

Hackaday comments

Hackaday tags: Parts, Carbide, horology, HSS, lathe, micromachining, steam, steam engine, watchmaker

When your steam engine build requires multiple microscopes, including those of the scanning electron variety, you know you’re building something really, really tiny.

All of the usual tiny superlatives and comparisons apply to [Chronova Engineering]’s latest effort — fits on a pencil eraser, don’t sneeze while you’re working on it or you’ll never find it. If we were to put the footprint of this engine into SMD context, we’d say it’s around a 2010 or so. As one would expect, the design is minimalistic, with no room for traditional bearings or valves. The piston and connecting rod are one piece, meaning the cylinder must pivot, which provides a clever way of switching between intake and exhaust. Tiny crankshaft, tiny flywheel. Everything you’d associate with a steam engine is there, but just barely.

The tooling needed to accomplish this feat is pretty impressive too. [Chronova] are no strangers to precision work, but this is a step beyond. Almost everything was done on a watchmaker’s lathe with a milling attachment and a microscope assist. For the main body of the engine, a pantograph engraving machine was enlisted to scale a 3D printed template down tenfold. Drill bits in the 0.3 mm range didn’t fare too well against annealed tool steel, which is where the scanning electron microscope came into play. It revealed brittle fractures in the carbide tool, which prompted a dive down the rabbit hole of micro-machining and a switch to high-speed steel tooling.

It all worked in the end, enough so that the engine managed 42,000 RPM on a test with compressed air. We eagerly await the equally tiny boiler for a live steam test.

Hackaday-feed 🤖@Hackaday-feed9/9/2024, 7:45 PM

One Giant Steppe for Space Flight

Hackaday comments

Hackaday tags: Space, aerospace, cosmonaut, entry descent landing, Soyuz, space flight, The New Yorker

In a recent photo essay for the New Yorker magazine, author Keith Gessen and photographer Andrew McConnell share what life is like for the residents around the launch facility and where Soyuz capsules land in Kazakhstan.

Read the article for a brief history of the Baikonur spaceport and observations from the photographer’s15 visits to observe Syuz landings and the extreme separation between the local farmers and the facilities built up around Baikonur. A local ecologist even compares the family farmers toiling around the busy spaceport to a scene our readers may be familiar with on Tatooine.

A wide angle photo of a Kazakhstan grassy steppe littered with rusty abandoned pieces of Soyuz space capsules

We assumed Soyuz capsules splashdown somewhere near Russia just like the iconic images of Apollo capsules. While they can land in water, their 13 target landing sites are all on land in the sparsely inhabited Kazakhstan steppe (flat grasslands). According to russianspaceweb.com, the descent is slowed with a single large parachute. When the capsule is about one meter from the ground, solid rocket thrusters fire, “reducing the descent speed of the capsule to between 0 and 3 meters per second.” We learned that the rockets’ force, not the crumple zone on the capsule, causes so much stress that each is only suitable for a single use.

A typical final descent trajectory for the Soyuz spacecraft in Kazakhstan (courtesy russianspaceweb.com)

While there is fascinating engineering in the Soyuz landing, from the landing rockets mentioned above to parachute wires acting as antennae for transponders to the multiple automated and backup systems, there is some hacking by the local farmers as well. The cast-off parts of the single-use capsules become scrap metal for use around the farms, leading to haunting images that seem to come from a dystopian future where space flights are as common as commercial air travel but still out of reach for many.