Raspberry Pi Pico “Modchip” Unlocks The GameCube

July 5, 2022 by Tom Nardi 30 Comments

In terms of units sold, it’s no secret that the GameCube was one of Nintendo’s poorest performing home consoles. You could argue increased competition meant sales of the quirky little machine were destined to fall short of the system’s legendary predecessors, but that didn’t keep the Wii from outselling it by a factor of five a few years later. Still, enough incredible games were released for the GameCube that the system still enjoys a considerable fanbase.

Now, with the release of PicoBoot by [webhdx], we suspect the GameCube is about to gain a whole new generation of fans. With just a Raspberry Pi Pico, some jumper wires, and a widely available third-party SD card adapter, this open source project bypasses the console’s original BIOS so it can boot directly into whatever homebrew application the user selects. With how cheap and easy to perform this modification is, we wouldn’t be surprised if it kicked off something of a renaissance for GameCube homebrew development.

In the video after the break, [Tito] of Macho Nacho Productions provides a rundown of this new project, including a fantastic step-by-step installation guide that covers everything from soldering the jumper wires to the console’s motherboard to getting the firmware installed on the Pico. He then demonstrates booting the console into various community developed front-ends and tools, showing just how versatile the modification is. While some will see this as little more than an easier way to run bootleg games, we can’t help but be excited about what the future holds now that getting your own code to run on the system is so easy.

Alright, maybe it’s not so easy. To solder on the five wires that will eventually snake their way to the GPIO pins of the Pi Pico, you’ll need to strip the console all the way down to the main board. That wouldn’t be too bad itself, but unfortunately to reach two of the connections you’ll need to remove the system’s massive heatsink — which means you’ll need to clean up the old sticky thermal pads and apply new ones if you don’t want your GameCube to turn into a GameCrisp. It’s nothing that would scare off the average Hackaday reader, but it might give pause to those less handy with an iron.

The release of PicoBoot comes hot on the heels of the revelation that the Raspberry Pi Pico can be used not only as an N64 flash cart but as a supercharged PlayStation Memory Card. These projects would all be significantly improved with a custom RP2040 board, and no doubt that’s the direction they’ll eventually head, but it’s hard not to be impressed by what the low-cost microcontroller development board is capable of in its native form. Especially now that it comes in WiFi flavor.

Continue reading “Raspberry Pi Pico “Modchip” Unlocks The GameCube” →

Sea Level Rise From Melting Ice Sheets Could Soon Be Locked In

June 23, 2022 by Lewin Day 124 Comments

Where today we talk broadly of climate change and it’s various effects, the conversation was once simpler. We called it “global warming” and fretted about cooking outside in the summer and the sea level rise that would claim so many of our favorite cities.

Scientists are now concerned that sea level rises could be locked in, as ice sheets and glaciers pass “tipping points” beyond which their loss cannot be stopped. Research is ongoing to determine how best we can avoid these points of no return.

Continue reading “Sea Level Rise From Melting Ice Sheets Could Soon Be Locked In” →

Hackaday Podcast 167: Deadly Art Projects, Robot Lock Pickers, LED Horticulture, And Good Samaritan Repairs

May 6, 2022 by Tom Nardi 2 Comments

Join Hackaday Editor-in-Chief Elliot Williams and Managing Editor Tom Nardi for a review of all the tech that’s fit to print. Things kick off with an update about the Hackaday Prize and a brief account of the 2022 Vintage Computer Festival East. Then we’ll talk about an exceptionally dangerous art project that’s been making the rounds on social media, a smart tea kettle that gave its life so that others can hack their device’s firmware, some suspiciously effective plant grow lights, and the slippery slope of remote manufacturer kill switches. We’ll wrap things up with some thought provoking discussion about personal liability as it pertains to community repair groups, and a close look at what makes synthetic oil worth spending extra on.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments below!

Direct Download link.

Continue reading “Hackaday Podcast 167: Deadly Art Projects, Robot Lock Pickers, LED Horticulture, And Good Samaritan Repairs” →

Screenshot of a logic analyzer software, showing the SDA channel being split into three separate traces

I2C Tap Helps Assign Blame For SDA Conflicts

May 2, 2022 by Arya Voronova 8 Comments

If you’ve ever debugged a misbehaving I2C circuit, you probably know how frustrating it can be. Thankfully [Jim] over at Hackaday.io, has a proto-boardable circuit that can help!

Inter-integrated circuit bus (aka I2C) uses open collector outputs on a two wire interface. Open collector means a device connected to the I2C bus can only pull the bus down to ground. Chips never drive a logic “HIGH” on the wires. When nothing is driving the lines low, a weak resistor pulls the lines up to VCC. This is a good thing, because I2C is also a multidrop bus — meaning many devices can be connected to the bus at the time. Without open collector outputs, one chip could drive a high, while another drives a low – which would create a short circuit, possibly damaging both devices.

Even with all this protection, there can be problems. The SCL and SDA lines in the I2C communication protocol are bidirectional, which means either a controller or a peripheral can pull it low. Sometimes, when tracing I2C communications you’ll need to figure out which part is holding the line low. With many devices sharing the same bus, that can become nigh-impossible. Some folks have tricks with resistors and analog sampling, but the tried and true method of de-soldering and physically lifting chip pins off the bus often comes into play.

[Jim’s] circuit splits SDA signal into controller-side and peripheral-side, helping you make it clear who is to blame for hiccups and stray noise. To do that, he’s using 6N137 optoisolators and LMV393 comparators. [Jim] shared a NapkinCAD schematic with us, meant to be replicate-able in times of dire need. With this design, you can split your I2C bus into four separate channels – controller-side SDA, peripheral-side SDA, combined SDA and SCL. 4 Channels might be a lot for a scope, but this is no problem for today’s cheap logic analyzers.

Continue reading “I2C Tap Helps Assign Blame For SDA Conflicts” →

The cluster of HackRFs described in the article, boards on top of each other, plugged into two 1x4 RF power splitters that are in turn plugged into a 1x2 RF power splitter. An LNA is connected to the input of the final splitter, and a cable goes off the frame from there.

A Gang Of HackRFs Makes For A Wideband SDR

April 1, 2022 by Arya Voronova 13 Comments

[Oleg Kutkov] decided to build a wideband SDR – for satellite communication research and monitoring, you know, the usual. He decided on a battery of HackRF boards – entire eight of them, in fact. Two 1×4 and one 1×2 RF splitters and an LNA on their combined RF input made for a good start to the project, and from there, it only got more complex.

HackRF boards can be synchronized with a separate clock source, but you can’t just pull a single clock line to all of them in a star configuration. Thus, he’s built a clock distribution and amplifier board, with 4 ns propagation delay at 1 PPS, and only 10 ns delay at 10 MHz. Then, he integrated that board with the HackRF setup, adding a case, wiring up a purpose-built cable and dealing with the reflections that occurred.

HackRF boards are USB 2.0 and able to generate a stream of data up to 320 MB/s, and there’d be no viable way to aggregate eight 2.0 links into one. To solve that, he’s used eight separate PCI-E to USB 3.0 cards, each of them with one HackRF plugged in, all connected to an AMD Ryzen 9-powered PC through PCI-E risers we typically see used for mining purposes. To tie it all together, he created a gnuradio flowgraph and patched the osmocom source block to enable the external clock synchronization mechanisms he decided to use.

Each HackRF is connected to its own PCIe USB card.

In the end, [Oleg] shows us some promising results – two DVB-S transceivers visible on the waterfall display of the spectrum capture. The work is not over here, to be clear – he’s ran into a few roadblocks. The gnuradio flowgraph doesn’t lend itself well to multi-threading, even on a Ryzen 9 machine, and [Oleg] pledged to rewrite the capture mechanisms in C++ which can be nicely allocated to separate physical CPU cores, something gnuradio is apparently not quite good at.

More importantly, the spectrum captured is not continuous, and [Oleg] questions whether it can be demodulated properly. He had to resort to frequency overlaps due to upsampling, and he’s not quite sure how to compensate for that. Overall frequency stability is also in question. However, from here, seems like most of the work towards building a wideband receiver is done!

[Oleg] is typically seen on Twitter, lately doing some heavy tinkering with Starlink – as Kyiv, the city he’s currently in, is under bombardment of Russian Armed Forces. We can only respect and appreciate the dedication. In January, we’ve covered his work on an USA-imported Tesla LTE modem replacement to fix LTE band incompatibilities in Ukraine, and his blog is a treasure trove of experiments that we are yet to properly comb through, from astrophysics and satellite work to RS485 networks and Linux driver writing.

Clockwork DevTerm R-01 Takes RISC-V Out For A Spin

March 19, 2022 by Tom Nardi 23 Comments

If you’re anything like us you’ve been keeping a close eye on the development of RISC-V: an open standard instruction set architecture (ISA) that’s been threatening to change the computing status quo for what seems like forever. From its humble beginnings as a teaching tool in Berkeley’s Parallel Computing Lab in 2010, it’s popped up in various development boards and gadgets from time to time. It even showed up in the 2019 Hackaday Supercon badge, albeit in FPGA form. But getting your hands on an actual RISC-V computer has been another story entirely. Until now, that is.

Clockwork has recently announced the availability of the DevTerm R-01, a variant of their existing portable computer that’s powered by a RISC-V module rather than the ARM chips featured in the earlier A04 and A06 models. Interestingly the newest member of the family is actually the cheapest at $239 USD, though it’s worth mentioning that not only does this new model only include 1 GB of RAM, but the product page makes it clear that the RISC-V version is intended for experienced penguin wranglers who aren’t afraid of the occasional bug.

Newbies are persona non grata for the R-01.

Beyond the RISC-V CPU and slimmed down main memory, this is the same DevTerm that our very own [Donald Papp] reviewed earlier this month. Thanks to the modular nature of the portable machine, this sort of component swapping is a breeze, though frankly we’re impressed that the Clockwork team is willing to go out on such a limb this early in the product’s life. In our first look at the device we figured at best they would release an updated CPU board to accommodate the Raspberry Pi 4 Compute Module, but supporting a whole new architecture is a considerably bolder move. One wonders that other plans they may have for the retro-futuristic machine. Perhaps a low-power x86 chip isn’t out of the question?

Raspberry Pi And The Story Of SD Card Corruption

March 9, 2022 by Arya Voronova 107 Comments

Tales of Raspberry Pi SD card corruption are available online by the fistful, and are definitely a constant in Pi-adjacent communities. It’s apparent that some kind of problems tend to arise when a Raspberry Pi meets an SD card – which sounds quite ironic, since an SD card is the official and recommended way of booting a Pi. What is up with all of that?

I can start with a history lesson. Back when Raspberry Pi launched in 2012 – which is now 10 years ago – there were SD card controller driver problems, which makes sense given the wide variety of SD cards available out there. They were verifiably fixed one by one at some point in time, as debugging goes, their impact decreased and bugs with individual cards got smoothed over. This is how the “Pi SD card corruption” meme was originally born; however, if the problems were to end there, so would the meme. Yet, tales of broken SD cards plague us to this day – way less severe than they were in the beginning, but pronounced enough that you’ll see people encounter them every now and then.

Over the years, a devoted base of Pi SD card haters has grown. Their demand has been simple – Raspberry Pi has to get an ability to boot from something else, in large part because of corruption reasons, but also undeniably because of speed and capacity/cost limitations of SD cards. Thanks to their demands and work, we’ve seen a series of projects grow from unofficial efforts and hacks into officially supported Raspberry Pi abilities – USB boot being initially more of a workaround but now something you can enable out of the box, SSD-equipped Pi enclosures becoming more of a norm, and now, NVMe boot appearing on the horizon. Every few years, we get a new way to boot a Pi. Continue reading “Raspberry Pi And The Story Of SD Card Corruption” →