Dual Port RAM Teaches an Old NES New Tricks


[Andrew] is developing a game for the Nintendo Entertainment System (NES). Emulators are great for this, but [Andy] loves running on the real iron. To help, he’s created a dual port RAM interface for his NES. As the name implies, a dual port RAM is a memory with two separate data and address buses. The Cypress Semiconductor CY7C136 [Andy] used also includes arbitration logic to ensure that both ports don’t attempt to access the same memory cell and cause data corruption. In [Andy’s] case the NES was on one side, oblivious to the new hardware. On the other side of the dual port RAM, [Andy] installed an ATmega164 running his own custom firmware.

The new hardware gives [Andy] a live view of what’s going on in the NES’s memory. He added a live memory view/edit screen similar to the FCEUX emulator. The window runs on a PC while the game itself is running on an NES. [Andy] was even able to add rudimentary break and step features by connecting his circuit to the Non Maskable Interrupt (NMI) line of the NES. By holding the NMI asserted, the ATmega can essentially freeze the game in progress.

[Andy] has even used his circuit to teach the NES some new tricks. By reading the timer and score memory locations on Ice Hockey, he was able to create a scoreboard and goal light. Similar techniques were used to give Contra a muzzle flash light which puts Ambilight systems to shame.

We don’t know what [Andy] is planning next, but we hope it’s a source release so we can start hacking some some games ourselves!

Click past the break to see a couple of [Andy’s] Vine videos.

Continue reading “Dual Port RAM Teaches an Old NES New Tricks”

The Mystery Of Zombie RAM

[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


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


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


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


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


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.