ram

67 Articles

The Mystery Of Zombie RAM

March 6, 2014 by 61 Comments

[Josh] had a little project where he needed to keep a variable in RAM while a microcontroller was disconnected from a power source. Yes, the EEPROM on board would be able to store a variable without power, but that means writing to the EEPROM a lot, killing the lifetime of the chip. He found an ATTiny can keep the RAM alive for a variable amount of time – somewhere between 150ms and 10 minutes. Wanting to understand this variability, he decided to solve the mystery of the zombie RAM.

The first experiment involved writing a little bit of code for an ATTiny4313 that looked for a value in RAM on power up and light up a LED if it saw the right value. The test circuit consisted of a simple switch connected to the power pin. Initial tests were astonishing; the ATTiny could hold a value in RAM for up to 10 minutes without power.

With the experiment a success, [Josh] updated his project to use this new EEPROM-saving technique. Only this time, it didn’t work. The value hidden away in RAM would die in a matter of milliseconds, not minutes. After tearing his hair out looking for something different, [Josh] rigged up an Arduino based test circuit with humidity and temperature sensors to see if that had any effect. It didn’t, and the zombie RAM was still not-undead.

The key insight into how the RAM in an ATtiny could stay alive for so long came when [Josh] noticed his test circuit had a LED, but the actual project didn’t. Apparently this LED was functioning as a very tiny solar cell, generating a tiny bit of current that kept the RAM alive. A dark room with a flashlight confirmed this hypothesis, and once [Josh] gets his uCurrent from Kickstarter he’ll know exactly how much current this LED is supplying.

Expanded Memory For The Teensy++ 2.0

February 17, 2014 by 3 Comments

RAM

Sometimes with a microcontroller project you need to do some very RAM-hungry operations, like image and audio processing. The largish AVR chips are certainly fast enough to do these tasks, but the RAM on these chips is limited. [xxxajk] has come up with a library that allows the use of huge RAM expansions with the Teensy++ 2.0 microcontroller, making these RAM-dependant tasks easy on one of our favorite microcontroller board.

[xxajk]’s work is actually a port of XMEM2, an earlier project of his that added RAM expansion and multitasking to the Arduino Mega. Up to 255 banks of memory are available and with the supported hardware, the Teensy can address up to 512kB of RAM.

XMEM2 also features a preemptive multitasking with up to 16 tasks, the ability to pipe messages between tasks, and all the fun of malloc().

The build is fairly hardware independent, able to work with Rugged Circuits QuadRAM and MegaRAM expansions for the Arduino Mega as well as [Andy Brown]’s 512 SRAM expansion. With the right SRAM chip, etching a board at home for XMEM2 is also a possibility.

Making 128MB SIMMs From Junk

October 25, 2013 by 25 Comments

simm

Working for a tech repair/recycling center, [Jax] has access to a ton of cool hardware. Most of it is junk, but that’s just the way he likes it. Among his better finds in the depths of a tech treasure trove is a huge antistatic bag of 64 MB 72 pin SIMMs. These were the standard RAM form factor for just about everything in the 90s, and while 64 MB is a huge amount of RAM for the time, they’re still a bit away from the 72 pin max of 128 MB.

After inspecting these sticks, [Jax] noticed something odd. Each side had pads for memory chips, but only one side was populated. Given the rarity of 128 MB sticks of RAM, [Jax] decided he would have a go at adding 64 Megs of RAM to these chips by desoldering one stick and sticking it on the back of another.

These new 128 MB SIMMs made their way into a Macintosh Quadra 605 for testing. While the 64 MB chips worked fine, the new 128 MB chips threw a chime of death. Something was terribly wrong.

While investigating, [Jax] couldn’t find any bridged solder joints, and everything looked okay. Heat is a wonderful test of what went wrong, and with the SIMM connected to a power source, he found all of the newly transplanted chips were hot. Because the chips on back side of the SIMMs were meant to be installed upside down, [Jax] had inadvertently connected the ground to power and power to ground.

Fixing his mistake on a new SIMM, [Jax] popped it in his old Mac and tried booting with these SIMMs again. There wasn’t a chime of death, but booting with these chips took a very long time. This was actually just the Mac checking all the RAM, which was successfully addressed once [Jax] finally booted his OS.

Testing DRAM From A Commodore 64

October 12, 2013 by 11 Comments

dram

A few months ago, [Josh] was given an old Commodore 64. He needed to make an AV cable and find a new power supply, and even after testing these new parts out, [Josh] found it still wouldn’t boot. Not one to look a gift horse in the mouth — or perhaps he enjoys the challenge — he set out on restoring a thirty year old circuit board.

He replaced a few chips and the caps, but found he had no way to test the DRAM chips. Compared to SRAM or Static RAM used by other computers of the era, DRAM is a bit harder to interface, requiring a capacitor in each memory cell to be refreshed a few dozen times every second. With a bit of help from his good friend [CNLohr], [Josh] figured out a circuit to read and write to his chips and build a small board based on the ATmega8U2 microcontroller for testing purposes.

Drive Bay Form Factor Dual Dekatron Readouts For RAM And CPU Usage

July 26, 2013 by 3 Comments

optical-drive-dual-dekatron

The two circular displays seen above are Dekatrons built into an optical drive enclosure. [Matt Sylvester] picked up a couple of different types of these tubes on eBay. He etched his own driver, and was able to control them with an Arduino. After a few months went by he decided to revisit the project to see if it would work as a CPU and RAM usage meter.

These tubes need high voltage to get the neon display glowing brightly. This raised some concerns about having those voltage levels inside of his PC, as well as the noise which may be introduced by the supply. To deal with those issues [Matt] gutted an old optical drive, using its case to physically isolate the circuitry, and some optoisolators to protect the logic connections. His driver board uses an ATmega328 running the Arduino bootloader. It connects to the PC using an FTDI USB to Serial cable. This makes it a snap to push the performance data to the display. It also has the side benefit of allowing  him to reprogram the chip without opening the case.

If you can’t find one of these tubes for your own project consider faking it.

Continue reading “Drive Bay Form Factor Dual Dekatron Readouts For RAM And CPU Usage” →

Building RAM Into Veronica – The 6502 Computer

March 31, 2013 by 3 Comments

ram-for-veronica

It seems strange that RAM is being added to a computer so late in the build, but [Quinn Dunki] must have had it in the back of her mind the whole time because it turns out to be a rather painless experience. For those of you keeping score, this makes her Veronica project Turing complete.

The brightly colored rats nest pictured above connects the new components to the 6502 computer backplane seen in the upper left. [Quinn] decided to go with two 32K SRAM modules which need very little in the way of drive hardware (it’s hanging out on the breadboard to the left). The RAM module will simply listen for its address and react accordingly. There is one hitch regarding a two-phase clock and the need to protect the RAM from erroneous data during the first of those phases.

Getting this all to work actually pointed out a bug in the ROM module she had long ago completed. After picking up on the problem she was able to correct it simply by cutting traces and soldering in jumper wires.

Extending Old Games With Reverse Engineering And MAME

March 27, 2013 by 8 Comments

For last year’s Toorcamp, the folks over at DorkbotPDX helped out with the Church of Robotron installation. A religion founded on the prophesy of a cybernetic uprising in the year 2084 is a little esoteric even for us, so the Dorkbot crew wanted a way to make playing Robotron: 2084 a little more visceral. Using MAME and a few debugging tools, they were able to read the memory of a machine playing Robotron to extend the game into the physical world. When the player dies, lights go off, alarms sound, and the prophet of the Church of Robotron is pleased.

The setup at the Church of Robotron included a machine running MAME with a Robotron ROM. When events happened in the game, such as lasers firing or a player death, physical events would be triggered. To do this, the Dorkbot team read the memory locations of a game of Robotron at different times and found memory locations tied to in-game events. On their blog they go over using the MAME debug tool to detect a player’s death which can then be translated into physical apparitions for the Church of Robotron.

It’s a very cool hack, and one we wish we had a video of. Having a plastic ghost hit a player while playing Pac-Man seems like an awesome idea, and with the Dorkbot tutorial, it looks fairly easy.