Bernoulli Disk Goes “Wii!” When Plugged Into WiiU

The Bernoulli disk was a wild piece of 1980s hardware. Take a big floppy. Spin the platter at 1500 RPM just a micron or so from a read head. The airflow around that rapidly-spinning disk actually stabilizes the disk that close to the read-head via the Bernoulli effect, hence the name. Once upon a time, everybody wanted a Bernoulli Box to put under their Macintosh 512, but [Will It Work?] wanted to see how well these old drives held up to the 21st century by using it to load games onto a WiiU.

It’s not as crazy at is it seems. The WiiU is happy to read and write anything that looks like a USB mass storage device. The Bernoulli Box is of course pre-USB — even the later model 5 1/4″ drive [Will] is using from 1987. That means it uses SCSI, the USB of the 1980s. He’s got a 90 MB disk, though Iomega did make disks of higher capacity in that format, all the way up to 230 MB. Yes, the same Iomega of Zip-drive fame and infamy. But don’t worry, the peculiar pneumatic nature of the Bernoulli disks makes them immune to the click of death.

You might think it’s going to take a great deal of hacking and homebrew to get the WiiU talking to a SCSI drive from the 80s, but as we said in the introduction, Nintendo made this thing respect USB conventions, so all that’s needed is an SCSI-to-USB cable. Well, plus a passive SCSI 1 to SCSI 2 adapter to get the USB adapter to fit.

It doesn’t seem like the drive slows down the WiiU nearly as much as we’d expect, but then it’s not a console known for fast load times. The other surprising detail is how much space the WiiU’s formatting sucked up, knocking the 90 MB disk down to only 68 MB. Combine that with the WiiU’s firmware wanting to pad space for save files, and not much fits. Thus we don’t expect this odd tower of power to take off like the original did. Still, if you had one of these back in the day, it might be a nice nostalgia hit to hear the drive whirring away.

If you think a disk drive is something Nintendo would never imagine for their consoles, think again! The Japanese version of the NES had the Famicom Disk System, which turns out to be essential if you want to run UNIX on it.

Continue reading “Bernoulli Disk Goes “Wii!” When Plugged Into WiiU”

Nintendo DS Port Of Super Mario 64 Released With Multiplayer Support

For some time now [Tobi Friedly] has been tinkering away at porting the original Super Mario 64 from the Nintendo 64 to just about any device imaginable. One of these being the Nintendo DS, with the code and build instructions now up on GitHub, along with the demonstration video below that shows off the added multiplayer functionality.

We previously covered this project and the challenges involved. The main problem that kept him from just taking the existing Nintendo DSi port by [Hydr8gon] and running it on the original DS is that the latter doesn’t have enough RAM to load the entire game ROM into memory. The integration of NitroFS for asset streaming took some time, along with addressing sound support and overall stability. Meanwhile it appears that multiplayer support was also added along the way.

This multiplayer involves two DS systems, each running its own copy of the game. This can be nice for co-op playing of the game, as well as just for goofing around in a 120 star fully finished game with a buddy.

Continue reading “Nintendo DS Port Of Super Mario 64 Released With Multiplayer Support”

Downloadable Xbox Thumbstick Toppers Give Gamers Accessibility Options

Microsoft has a history of taking accessibility options seriously for gaming controllers, and that trend continues with downloadable thumbstick toppers for Xbox controllers. Being straight from the source, the 3D models should fit as well as can be expected with a minimum of fiddling. Just make sure you select the right controller model, because they are each subtly different.

The toppers themselves come in different styles, and there’s a design to fit a variety of needs, from a thumb cradle to ones intended for more serious adaptations —  the perforated X-shaped topper, for instance, is meant to anchor a custom shape molded overtop it.

Continue reading “Downloadable Xbox Thumbstick Toppers Give Gamers Accessibility Options”

Robot Chess But Each Piece Is A Small Robot

A topless chess piece. (Credit: 3DprintedLife, YouTube)
A topless chess piece. (Credit: 3DprintedLife, YouTube)

We have seen a number of self-playing chess boards over the years, but the general theme has been standard chess pieces moved by either an internal electromagnet or an external robotic arm. This is, of course, a reasonable choice, as it reduces complexity, and sometimes you can even use standard chess pieces on a regular board. But what if each piece could move by itself? That seems cooler, so that’s what [3DprintedLife] did with 3D-printed chess pieces that are also tiny robots.

Although technically not the first, as you can buy the commercial Chessnut Move offering, this being an open hardware and source project makes it a lot more interesting, also because the general design is generic enough to be usable for applications other than just playing chess.

The MiniBots, as the individual pieces are called, are built around a custom PCB with an ESP32-C3 module, two PMO8-2 miniature stepper motors with requisite drivers, a magnetometer, and are powered by a 170 mAh LiPo battery. Communication with the central hub is done using ESP-NOW, with each MiniBot using its own dedicated channel.

This hub’s mainboard also runs on an ESP32-C3 for the wireless interface, while the processing is handled via a serial link with a Raspberry Pi SBC that runs the main Python-based software. Localizing the individual pieces on the board is done by scanning electromagnets embedded in the board and using the readings from the individual magnetometers to triangulate the positions.

Although at the end of the video a basic prototype sort of works, the ESP32-C3, being a single-core MCU, tripped up the firmware, necessitating some changes that should be in the next update, along with power saving and easier recharging being issues to address.

If you want to see a more conventional chess robot, we’ve seen plenty.

Continue reading “Robot Chess But Each Piece Is A Small Robot”

Deeply Optimized MSX Emulation On ESP32-S3 With VGA Output

ESP32-S3 board with VGA and audio output during development. (Credit: Ivan Svarkovsky)
ESP32-S3 board with VGA and audio output during development. (Credit: Ivan Svarkovsky)

The ESP32-S3 is by many metrics quite the powerful little computer, which has led to it being used even for things like emulating retro consoles and similar. Here [Ivan Svarkovsky]’s S3-MSX-PC project pushes the envelope by taking the multi-system Retro-Go project’s MSX component and optimizing it for the ESP32-S3’s Xtensa Lx7 CPU cores.

The project involves an ESP32-S3 as the core, requiring at least 8 MB of PSRAM (N16R8 configuration) to match the tested configuration. Any software is loaded into PSRAM before it’s executed, with the MSX1, MSX2 and MSX2+ supported.

For audio you have to wire up your own PDM filters to connect to the two GPIO pins that are used for audio output, while VGA output is handled by a basic 2-bit R-2R RGB222 DAC. For input devices you can use any USB keyboard, while software is added via the web interface or directly onto an SD card.

The Technical Deep Dive section goes into more detail as to what exactly got changed – with the blessing of the fMSX author – in the original fMSX core, such as targeting the Lx7 core’s cache dimensions and optimizing hot paths to avoid bottlenecks. Memory accesses were aligned for Xtensa and moving certain data from Flash to RAM was another change, along with the prevention of pipeline flushing due to certain branching decisions.

Considering that MSX specifications are based on a Z80 core, it’s not so crazy that one of these ESP32-S3 MCUs can effectively emulate them. The Retro-Go project itself claims to cover a whole swath of Nintendo and Sega consoles, as well as others, making it almost too easy to do some retrogaming without even having to drag out a Raspberry Pi SBC or so.

A RayCast FPS In COBOL

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.

Investigating The S3 Virge’s Reputation As A 3D Decelerator Card

The special 512x384 mode with S3 card installed. (Credit: Bits und Bolts, YouTube)
The special 512×384 mode with S3 card installed. (Credit: Bits und Bolts, YouTube)

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.

Continue reading “Investigating The S3 Virge’s Reputation As A 3D Decelerator Card”