memory

53 Articles

Stealing RAM For A Microcontroller From A TFT Display

May 21, 2020 by 12 Comments

PC users with long memories will recall the days when the one-megabyte barrier was  a significant problem, and the various tricks of extended and expanded memory used to mitigate it. One of them was to install a driver that mapped surplus graphics card memory as system memory when the display was in DOS text mode, and it was this that was brought to mind when we read about [Frank D]’s microcontroller implementation of Conway’s Game Of Life.

The components were those he had to hand; an STM32F030F4P6 and an RM68130 176 × 220 TFT board. The STM is not the most powerful of chips, with only 16 kB of Flash and 4 kB of RAM. The display has enough on-board memory to support 18 bits of colour information, but when it is running in eight-colour mode it only uses three of them. The 15 bits that remain are thus available to be used for other purposes, and though the arcane format in which they are read required some understanding they could be used to provide a very useful extra 38720 bytes of RAM for the microcontroller just as once happened with those DOS PC graphics cards of old. Interestingly, the same technique should work with other similar displays.

Though this isn’t a new technique by any means we can’t recall seeing it used in a microcontroller project such as this one before. We’ve brought you many Games of Life though, as well as marking John Conway’s passing earlier this year.

Continue reading “Stealing RAM For A Microcontroller From A TFT Display” →

DIY Neuralyzer From Scrap Parts

May 15, 2020 by 9 Comments

Cosplay and prop making are near and dear to our hearts here at Hackaday. That’s why whenever we see sci-fi tech brought to life, we can’t help but pay close attention. Enter [How to make’s] DIY Neuralyzer, from the Men-in-Black franchise. Unfortunately, this won’t wipe your memories as the real-life Neuralyzer would, but it will make for a cool prop at your next cosplay event.

What makes this project worth sharing is its use of very simple home tools and a bit of scrap metal, some PVC, a single LED, a switch, and maybe a few more miscellaneous bits. The base of the design is composed of two pieces of hollow, rod-shaped scrap metal and a single spring that mechanizes the entire setup.

The video is a few months old at this point. It took a recent post on Reddit to send this across our feed, but we’re glad we came across it.

Great project [How to make]! May we suggest a few more LEDs?

Continue reading “DIY Neuralyzer From Scrap Parts” →

DDR-5? DDR-4, We Hardly Knew Ye

January 29, 2020 by 32 Comments

This month’s CES saw the introduction of max speed DDR5 memory from SK Hynix. Micron and other vendors are also reportedly sampling similar devices. You can’t get them through normal channels yet, but since you also can’t get motherboards that take them, that’s not a big problem. We hear Intel’s Xeon Sapphire Rapids will be among the first boards to take advantage of the new technology. But that begs the question: what is it?

SDRAM Basics

Broadly speaking, there are two primary contenders for a system that needs RAM memory: static and dynamic. There are newer technologies like FeRAM and MRAM, but the classic choice is between static and dynamic. Static RAM is really just a bunch of flip flops, one for each bit. That’s easy because you set it and forget it. Then later you read it. It can also be very fast. The problem is a flip flop usually takes at least four transistors, and often as many as six, so there’s only so many of them you can pack into a certain area. Power consumption is often high, too, although modern devices can do pretty well.

Continue reading “DDR-5? DDR-4, We Hardly Knew Ye” →

Creative Limitation And The Super Nintendo Sound Chips

July 31, 2019 by 18 Comments

The Super Nintendo recently experienced a surge in popularity, either from a combination of nostalgic 30-somethings recreating their childhoods, or because Nintendo released a “classic” version of this nearly-perfect video game system. Or a combination of both. But what made the system worthy of being remembered at all? With only 16 bits and graphics that look ancient by modern standards, gameplay is similarly limited. This video from [Nerdwriter1] goes into depth on a single part of the console – the sound chips – and uses them to illustrate a small part of what makes this console still worth playing even now.

The SNES processed sound with two chips, a processing core and a DSP. They only had a capacity of 64 kb, meaning that all of a game’s sounds and music had to fit in this tiny space. This might seem impossible if you’ve ever played enduring classics like Donkey Kong Country, a game known for its impressive musical score. This is where the concept of creative limitation comes in. The theory says that creativity can flourish if given a set of boundaries. In this case it was a small amount of memory, and within that tiny space the composer at Rare who made this game a work of art was able to develop a musical masterpiece within strict limitations.

Even though this video only discusses the sound abilities of the SNES, which are still being put to good use, it’s a good illustration of what made this system so much fun. Even though it was limited, game developers (and composers) were able to work within its limitations to create some amazingly fun games that seem to have withstood the test of time fairly well. Not all of the games were winners, but the ones that were still get some playtime from us even now.

Continue reading “Creative Limitation And The Super Nintendo Sound Chips” →

Recover Data From Damaged Chips

January 30, 2019 by 6 Comments

Not every computer is a performance gaming rig. Some of us need cheap laptops and tablets for simple Internet browsing or word processing, and we don’t need to shell out thousands of dollars just for that. With a cheaper price tag comes cheaper hardware, though, such as the eMMC standard which allows flash memory to be used in a more cost-advantageous way than SSDs. For a look at some the finer points of eMMC chips, we’ll turn to [Jason]’s latest project.

[Jason] had a few damaged eMMC storage chips and wanted to try to repair them. The most common failure mode for his chips is “cratering” which is a type of damage to the solder that holds them to their PCBs. With so many pins in such a small area, and with small pins themselves, often traditional soldering methods won’t work. The method that [Jason] found which works the best is using 0.15 mm thick glass strips to aid in the reflow process and get the solder to stick back to the chip again.

Doing work like this can get frustrating due to the small sizes involved and the amount of heat needed to get the solder to behave properly. For example, upgrading the memory chip in an iPhone took an expert solderer numerous tries with practice hardware to finally get enough courage to attempt this soldering on his own phone. With enough practice, the right tools, and a steady hand, though, these types of projects are definitely within reach.

Do Other Things Besides Output Video

January 15, 2019 by 18 Comments

Small microcontrollers and tiny systems-on-chips are getting more and more popular these days as the price comes down and the ease of programming goes up. A Raspberry Pi is relatively inexpensive and can do pretty much everything you need, but not every chip out there can do something most of us take for granted like output video. For a lot of platforms, it’s next to impossible to do while saving any processor or memory for other tasks besides the video output itself.

[Dave] aka [Mubes] has been working on the Blue Pill platform which is a STM32F103C8 board. While they don’t natively output video, it’s a feature that provides a handy tool to have for debugging in order to see what’s going on in your code. However, if the video code takes up all of the processor power and memory there’s not much point. [Dave]’s video output program, on the other hand, takes up only 1200 bytes of RAM and 24% of the processor for a 50×18 text display over VGA, leaving a lot of room left for whatever else you need the tiny board to do.

Video output on a device this small and lightweight is an impressive feat, especially while saving room for other tasks. This brings it firmly out of the realm of novelty and into the space of useful tools to keep around. If you want to try the same thing on an ATtiny, though, you might have to come up with some more impressive tricks.

Continue reading “Do Other Things Besides Output Video” →

Re-enacting TRON On The Apple IIgs

November 14, 2018 by 4 Comments

TRON is a science fiction classic, hitting cinemas in the midst of the burgeoning home computer era. It’s the film that created the famous light cycle, which spawned many video game recreations in the following years. Many years ago now, [Daniel] decided to flex his programming muscles by coding a version of the game for the Apple IIgs, with accidentally excellent results.

In the film, the characters find an escape from the light cycle game by forcing another player to crash into the walls of the play area. The resulting explosion left a hole, allowing the players to exit the light cycle game and explore the rest of the computer. Amusingly, due to a coding oversight, [Daniel] had created exactly this same flaw in his own code.

[Daniel]’s game differed from the original in that players were provided with missiles to destroy enemy trails. However, these missiles did not discriminate, and due to the simplicity of the code, were able to destroy the boundary on the play area. This was discovered when the computer player tried to escape an otherwise impossible situation. Upon blowing a hole in the arena wall, the computer player proceeded to drive off the screen – into invalid memory. This led to the computer crashing in short order, due to the unprotected memory space of the Apple II platform.

It’s a case of code imitating art – and completely by accident. The game managed to replicate the light cycle escape from the film entirely due to the unexpected behaviour of the simple missile code. [Daniel] steps through the code and how the bug happened, and covers the underlying principle behind the resulting crashes. It’s an entertaining tale of the risks of coding at low level; something we don’t always run into with today’s modern interpreted languages.

Thirsty for more tales of hacking the Apple II? How about going back in time to fix a 37 year old bug?