Add An Extra 8GB Of VRAM To Your 2070

January 29, 2021 by Matthew Carlson 31 Comments

Most of us make do with the VRAM that came with our graphics cards. We can just wait until the next one comes out and get a little more memory. After all, it’d be madness to try and delicately solder on new components of something so timing-sensitive as RAM chips, right?

[VIK-on] took it upon himself to do just that. The inspiration came when a leaked diagram suggested that the RTX 2000 line could support 16 GB of RAM by using 2GB chips. NVIDIA never did release a 16GB version of the 2070, so this card is truly one of a kind. After some careful scouring of the internet, the GDDR6 chips were procured and carefully soldered on with a hot air gun. A few resistors had to be moved to accommodate the new RAM chips. During power-on, [VIK-on] saw all 16 GB enumerate and was able to run some stress tests. Unfortunately, the card wasn’t stable and started having black screen issues and wonky clocks. Whether it was a bad solder joint or firmware issues, it’s hard to say but he is pretty convinced it is a BIOS error. Switching the resistors back to the 8GB configuration yielded a stable system.

While a little more recent, this isn’t the only RAM upgrade we’ve covered in the last few months. Video after the break (it’s not in English but captions are available).
Continue reading “Add An Extra 8GB Of VRAM To Your 2070” →

A Look At How Nintendo Mastered Dual Screens

January 28, 2021 by Tom Nardi 24 Comments

When it was first announced, many people were skeptical of the Nintendo DS. Rather than pushing raw power, the unique dual screen handheld was designed to explore new styles of play. Compared to the more traditional handhelds like the Game Boy Advance (GBA) or even Sony’s PlayStation Portable (PSP), the DS seemed like huge gamble for the Japanese gaming giant.

But it paid off. The Nintendo DS ended up being one of the most successful gaming platforms of all time, and as [Modern Vintage Gamer] explains in a recent video, at least part of that was due to its surprising graphical prowess. While it was technically inferior to the PSP in almost every way, Nintendo’s decades of experience in pushing the limits of 2D graphics allowed them to squeeze more out of the hardware than many would have thought possible.

On one level, the Nintendo DS could be seen as a upgraded GBA. Developers who were already used to the 2D capabilities of that system would feel right at home when they made the switch to the DS. As with previous 2D consoles, the DS had several screen modes complete with hardware-accelerated support for moving, scaling, rotating, and reflecting up to four background layers. This made it easy and computationally efficient to pull off pseudo-3D effects such as having multiple backdrop images scrolling by at different speeds to convey a sense of depth.

On top of its GBA-inherited tile and sprite 2D engine, the DS also featured a rudimentary GPU responsible for handling 3D geometry and rendering. Hardware accelerated 3D could only used on one screen at a time, which meant most games would keep the closeup view of the action on one display, and used the second panel to show 2D imagery such as an overhead map. But developers did have the option of flipping between the displays on each frame to render 3D on both panels at a reduced frame rate. The hardware can also handle shadows and included integrated support for cell shading, which was a particularly popular graphical effect at the time.

By combining the 2D and 3D hardware capabilities of the Nintendo DS onto a single screen, developers could produce complex graphical effects. [Modern Vintage Gamer] uses the example of New Super Mario Bros, which places a detailed 3D model of Mario over several layers of moving 2D bitmaps. Ultimately the 3D capabilities of the DS were hindered by the limited resolution of its 256 x 192 LCD panels; but considering most people were still using flip phones when the DS came out, it was impressive for the time.

Compared to the Game Boy Advance, or even the original “brick” Game Boy, it doesn’t seem like hackers have had much luck coming up with ways to exploiting the capabilities of the Nintendo DS. But perhaps with more detailed retrospectives like this, the community will be inspired to take another look at this unique entry in gaming history.

Continue reading “A Look At How Nintendo Mastered Dual Screens” →

Trying (And Failing) To Use GPUs With The Compute Module 4

November 10, 2020 by Lewin Day 15 Comments

The Raspberry Pi platform grows more capable and powerful with each iteration. With that said, they’re still not the go-to for high powered computing, and their external interfaces are limited for reasons of cost and scope. Despite this, people like [Jeff Geerling] strive to push the platform to its limits on a regular basis. Unfortunately, [Jeff’s] recent experiments with GPUs hit a hard stop that he’s as yet unable to overcome.

With the release of the new Compute Module 4, the Raspberry Pi ecosystem now has a device that has a PCI-Express 2.0 1x interface as stock. This lead to many questioning whether or not GPUs could be used with the hardware. [Jeff] was determined to find out, buying a pair of older ATI and NVIDIA GPUs to play with.

Immediate results were underwhelming, with no output whatsoever after plugging the modules in. Of course, [Jeff] didn’t expect things to be plug and play, so dug into the kernel messages to find out where the problems lay. The first problem was the Pi’s limited Base Address Space; GPUs need a significant chunk of memory allocated in the BAR to work. With the CM4’s BAR expanded from 64MB to 1GB, the cards appeared to be properly recognised and ARM drivers were able to be installed.

Alas, the story ends for now without success. Both NVIDIA and ATI drivers failed to properly initialise the cards. The latter driver throws an error due to the Raspberry Pi failing to account for the I/O BAR space, a legacy x86 feature, however others suggest the problem may lay elsewhere. While [Jeff] may not have pulled off the feat yet, he got close, and we suspect with a little more work the community will find a solution. Given ARM drivers exist for these GPUs, we’re sure it’s just a matter of time.

For more of a breakdown on the Compute Module 4, check out our comprehensive article. Video after the break.

Continue reading “Trying (And Failing) To Use GPUs With The Compute Module 4” →

Finding The Random Seed Of Minecraft’s Title Screen

July 20, 2020 by Lewin Day 12 Comments

Minecraft is a game about exploring procedure-generated worlds. Each world is generated from a particular “seed” value, and sharing this seed value allows others to generate the same world in their own game. Recently, the distributed computing project Minecraft@Home set about trying to find the seed value of the world shown in the Minecraft title screen, and have succeeded in their goal.

The amount of work required to complete this task should not be underestimated. 137 users contributed 181 hosts with 231 GPUs to the effort, finding a solution in under 24 hours. The list of contributors to the project is a long one. It appears the method to find the seed involved comparing screenshots from various seed worlds to the original image. This took a lot of reverse engineering in order to calculate the camera FOV and other settings of the original capture, such that the results could be compared accurately. Interestingly, the group found two seeds that can generate the requisite world, suggesting the world generator code has some collisions between seed values.

We’re not sure what’s more astounding, the amount of work that went into the project, or that there’s a distributed computing project tackling advanced Minecraft research. Either way, we’re no strangers to Minecraft hacks around these parts. Video after the break. Continue reading “Finding The Random Seed Of Minecraft’s Title Screen” →

A Dead Macbook GPU Shouldn’t Stop You, With This BGA Soldering Hack

June 28, 2020 by Jenny List 42 Comments

On some 2011 Macbook Pro models, there is a tendency for the Radeon GPU to fail. This should mean game over for the computer, but surprisingly salvation is offered by its having not one but two GPUs on board. The Intel processor also has a GPU, and Apple use a pile of logic in an FPGA to switch at will between them. The community have produced fresh FPGA code to revive a dead Mac on its Intel GPU, but at the expense of losing brightness control. [Ayilm1] has brought back the brightness with a clever BGA reworking hack that gains access to a brightness control line present on the Intel BD82HM65 Platform Controller Hub chip but not used in the Macbook.

We’re used to impressive soldering work here at Hackaday, and we’ve seen our share of wiring direct to the balls on an upturned BGA chip. This is a similar idea but at another level, as a section of the top insulation on an in-place BGA is removed to expose the microvia above the ball carrying the required signal. A tiny wire is soldered to the exposed pad and taken to a piece of copper tape stuck down to provide mechanical strength, and a piece of enameled copper wire is run from that to the other side of the PCB where lies its destination. It comes with FPGA code to take advantage of it, but even for non-Macbook owners, it’s an extremely impressive piece of work. It’s not the first fine-soldering Macbook fix we’ve seen, either.

Thanks [lightpink784] for the tip.

Help Us Throw More Cycles At The Coronavirus Problem

May 10, 2020 by Mike Szczys 45 Comments

The Hackaday community has answered the call and put their computers put to work folding proteins found in the coronavirus. Team_Hack-a-Day ranks #44 in the world so far this month, and I’ve seen us rank as high as #19 on 24-hour leaderboards.

Want to join the fight? Donate some of those computing cycles you’re not using to battling SARS‑CoV‑2. You’re probably not an epidemiologist or a vaccine researcher, but you can make their jobs easier by providing them with the data they need through the Folding@home Project.

As Dan Maloney explained in his excellent article on protein folding, understanding the incredibly complex folding behavior of the proteins in the virus will be key to finding treatments and possibly a vaccine. Folding@home connects countless computers via the internet and is now the largest supercomputer in the world, consisting of over 3.5 million CPUs and over half a million GPUs. The resulting data is freely available to researchers.

Let’s take a look at how easy it is to get up and running, how a GPU can supercharge a setup, and dip into the stats for Team_Hack-a-Day’s effort.

Continue reading “Help Us Throw More Cycles At The Coronavirus Problem” →

GPU Turned Into Radio Transmitter To Defeat Air-Gapped PC

April 24, 2020 by Dan Maloney 31 Comments

Another week, another exploit against an air-gapped computer. And this time, the attack is particularly clever and pernicious: turning a GPU into a radio transmitter.

The first part of [Mikhail Davidov] and [Baron Oldenburg]’s article is a review of some of the basics of exploring the RF emissions of computers using software-defined radio (SDR) dongles. Most readers can safely skip ahead a bit to section 9, which gets into the process they used to sniff for potentially compromising RF leaks from an air-gapped test computer. After finding a few weak signals in the gigahertz range and dismissing them as attack vectors due to their limited penetration potential, they settled in on the GPU card, a Radeon Pro WX3100, and specifically on the power management features of its ATI chipset.

With a GPU benchmarking program running, they switched the graphics card shader clock between its two lowest power settings, which produced a strong signal on the SDR waterfall at 428 MHz. They were able to receive this signal up to 50 feet (15 meters) away, perhaps to the annoyance of nearby hams as this is plunk in the middle of the 70-cm band. This is theoretically enough to exfiltrate data, but at a painfully low bitrate. So they improved the exploit by forcing the CPU driver to vary the shader clock frequency in one megahertz steps, allowing them to implement higher throughput encoding schemes. You can hear the change in signal caused by different graphics being displayed in the video below; one doesn’t need much imagination to see how malware could leverage this to exfiltrate pretty much anything on the computer.

It’s a fascinating hack, and hats off to [Davidov] and [Oldenburg] for revealing this weakness. We’ll have to throw this on the pile with all the other side-channel attacks [Samy Kamkar] covered in his 2019 Supercon talk.

Continue reading “GPU Turned Into Radio Transmitter To Defeat Air-Gapped PC” →