[Quinn Dunki] keeps rolling with her 6502 based computer build. This time around she’s added some memory to store the programs, but needed a way to get that code into the device. Above is her solution, a bank of hex switches used to program the 8-bit command and 16-bit address for each line of machine code.

This is a continuation of her Veronica project. The last time we saw it she had hardwired the logic levels for the data bus, but that’s no fun since nothing can actually be computed. [Quinn] picked up an SRAM chip which will store the program. It’s compatible with the 6502′s memory bus, but needs a bit of extra circuitry for her to be able to hand program it with this switch bank. She used some tri-state buffers to switch between connections to the processor, and to the hex switches. This way, she disconnects the RAM from the processor using the buffers, uses the switches and push button to clock in the program, then patches the RAM back into the computer.

Seeing this process in the video after the break certainly gives you an appreciation for what an improvement the punch-card system was over this technique. Still, seeing this is a delight that we’d like to try!

[Heli] had a WRT300N wireless router sitting around collecting dust. He decided to squeeze at bit more entertainment value out of it by seeing if he could pull off a RAM upgrade. He managed to double the router’s RAM and posted a walk through (translated) to help you do the same.

Swapping out surface mount RAM chips isn’t the easiest thing in the world and you must wondering what prompted this. It seems he wanted to run the LuCI package on the router but it was slow (or even incapable) of booting with the stock hardware’s 16 Mb. He first sourced some pin-compatible replacement chips from an old Pentium III computer. While his soldering iron was hot, he also wired up a JTAG header, which connects via the red wires just visible to the left. When he first fired up the unit he was happy that it was able to boot, but it still only detected 16 Mb.

It turns out you’re going to need to roll your own kernel to get it to take advantage of the upgrade. Source code for OpenWRT is easy to find and there’s plenty of guides for compiling it. If you try this, make sure to read [Heli's] post carefully as he’s got some important configuration information that will help you to avoid bricking your router.

[Andy] stuffed some more RAM onto an Arduino Mega and his three-part walk through on the design, construction, and software is a great read and one of the more ‘hard core’ Arduino builds we’ve seen.

The build is centered around a 512K × 8 SRAM module [PDF warning]. Because the RAM is divided up into about 512,000 chunks of 8 bits, the Arduino has to access the RAM through 16 ‘address lines’, then send the data through 8 ‘data lines’. [Andy] didn’t want to use up 24 pins on his Arduino, so he used a latch to multiplex the lowest 8 address lines and the data lines together. With the 512KB RAM expansion installed, the Mega is able to address a whopping 520 Kilobytes.

We’ve seen a few builds that have been limited by the amount of RAM available in the Arduino, like capturing video and some robot hacks, and adding some more RAM to those builds would be great. Multiplexing data and address lines using a latch can be expanded even further, but 520KB ought to be enough for anybody.

In modern computer systems, the biggest bottleneck of information tends to be in communicating with the hard disks. High seek times and relatively slow transmission rates when compared to RAM speeds can add up quickly. This was a necessary evil back when RAM space and costs were at a premium, but now it is not uncommon to see 4GB of RAM on laptops, and even 12GB on desktops. For  users whose primary computer use is browsing the internet (either for work, writing articles, or lolcats) and have some extra RAM, moving the browser cache to the RAM from the hard disk is a definite option for increasing speed.

In Linux systems (specifically Fedora and Ubuntu systems), this can be achieved for Chrome and Firefox by creating a larger ramdisk, mounting the ramdisk after boot, and then setting the browser of choice to use that ramdisk as a cache. The necessary commands to do this are readily available on the internet, which makes life easy. Using ramdisks for performance boosts are not exclusive to browsers, and can be used for other software such as Nagios for example.

We have previously covered a tool called Espérance DV for moving cache to RAM in Mac OSX, and for any Windows users feeling left out, there are ways of making Firefox bend to your will. Obviously you will see an increase in RAM use (duh), but this shouldn’t be a problem unless you are running out of free RAM on your system. Remember, free RAM is wasted RAM.

Those who are familiar with Atmel’s line of 8-bit AVR microcontrollers should already know that some of them have support for external RAM. But have you ever actually used this feature? We haven’t. Now you can learn how it’s done by reading through this guide. It touches on all of the hardware, but doesn’t dwell on it. Instead, you’ll get the background you need on how to write to, read from, and test an external module like the one sticking up in the image above. The test routine shows how to make sure everything’s working correctly with your memory mapping before you begin developing firmware around this increased capacity.

[Thanks Spman]

iFixit traveled all the way to Japan to bring you this iPhone 4 teardown, only to be shipped the device unexpectedly two days early!

We were surprised that the A4 processor (its naked body displayed for the world this past April) contained within the iPhone 4 had 512MB of ram, compared to the 256MB of the iPad. Other features include the 1420mAh battery (201mAh more than the 3Gs), 5MP rear camera and front VGA camera, and the use of micro-sim.

Frankly, we don’t see ourselves getting the device immediately, but how excited are you for the iPhone 4?

[Stephanie] beefed up the hardware on her Dingoo A320. She enjoyed the features that the A320 handheld gaming system offered, but wanted the 64mb of RAM available in its bigger brother, the A330. A comparison of the two led her to believe a swap might be possible and after sourcing a pair of replacement chips for $12.50 she took the plunge. Once the solder had cooled it was just a matter of flashing some different firmware to take advantage of the upgrade.

[Thanks Juan via Dingoonity]

Want 21 megabytes more ram in your Nexus One? [Coolbho3000] worked out a way to tweak the kernel and remap memory usage to free up some resources. That means this comes as a custom kernel image requiring no hardware alteration. Try it out and share your experiences in the comments. But if you don’t need more ram you can just upgrade to the most recent kernel.

[Thanks Juan]

Sometimes your project needs a lot of non-volatile ROM, right on cue [Matthew] let us know how to not only connect, interface, read, and write to SD cards with a PIC over serial, but also how to do the above mentioned with an old PATA HDD. For those without a PIC/serial connection don’t fret, [nada] let us know about his Bus Pirate SD card hack, of which our personal favorite part is the creative use of an old 5.25″ floppy connector as the SD card socket.

[Pelaca] upgraded the RAM on his D-Link DIR-320 router from 32MB to 64MB. This hack is simple enough: swap out the existing RAM chip for another one and change the bios to make use of the upgrade. The actual execution is not that simple because of the pitch of the TSOP II package; you’ll need to bring your mad soldering skills to pull this off.

This reminds us of when upgrading original Xbox RAM to 128MB was all the rage. It involved the same type of hack, adding four memory chips to unpopulated positions on the motherboard. The forums are thick with people complaining that their box not working after a failed upgrade attempt. Hopefully you’ll have better luck.

[Thanks Juan]

Check out this visual hardware guide from deviantART member [Sonic840]. It has everything from memory modules, to bus sockets, to power connectors, to an entire array of CPU sockets that have been used over the years. You’re bound to see something in there you didn’t know existed.

[via Gizmodo]

Microchip’s new 23K256 is a serially interfaced 32 kilobyte SRAM memory chip, available in 8 pin DIP and 8 pin SO packages. SRAM, like EEPROM, is a data storage medium. Data stored in SRAM is lost without constant power, but it’s really fast and there’s no limits to the number of write cycles. EERPOM stores data even without power, but it’s slow and usually limited to around a million write cycles.

32K SRAM chips typically have 15 address lines and 8 data lines, like the IS61LV256AL we used on our CPLD development board.  The 23K256 requires just four signal lines, but sacrifices the speed of a parallel memory interface. It’s a great way to add extra memory to a low-pin count microcontroller without routing 23 signal traces. We’ll show you how to interface this chip below.

Microchip 23K256, 32K SPI SRAM (Mouser search, Octopart search, $1.48). Datasheet (PDF).

We connected the 23K256 to our Bus Pirate universal serial interface tool as shown in the table. It’s very important to power the chip using only the Bus Pirate’s 3.3volt supply, the 23K256 isn’t rated for 5volts.

The Bus Pirate is an easy way to learn about a chip without writing any code, but the same principals apply to using the 23K256 with any microcontroller. This demonstration uses the latest version of the Bus Pirate firmware (26-FEB-2009), which you can download from our Google Code SVN.

HiZ>m <–choose mode
1. HiZ
…
5. SPI
…
MODE>5 <–SPI mode
MODE SET
… <–30KHz, all default settings
SPI READY
SPI>W <–capital ‘W’ enables power supplies
VOLTAGE SUPPLIES ON
SPI>

First, we put the Bus Pirate into SPI mode at 30KHz and chose the default settings for all options. We enabled the Bus Pirate’s on-board 3.3volt power supply with a capital ‘W’.

Configuration register

bit 7,6 = byte (00) page (10) sequence (01) mode
bit 0 = Hold disabled (1)

Data is stored inside the 23K256 in 1024 pages that each contain 32bytes. The scope of reads and writes is set by bit 7 and 6 of the configuration register. Storage can be accessed by the byte (00), by 32byte pages (10), or sequentially through the entire 32K (01).  We’ll work in sequence mode, which gives us access to read and write any length of data, anywhere in the 32K of storage space.

The hold pin is used to pause transfers when other chips on the same bus need to be accessed. Bit 0 of the configuration register controls the hold pin. When set to 1, the hold pin is disabled. We tied hold to ground for normal operation, but its functionality can be completely disabled by setting bit 0.

The configuration register is changed by sending the write configuration command (0b00000001) and the new settings.

SPI>[0b1 0b01000001] <–update config register
CS ENABLED
WRITE: 0×01 <–write config command
WRITE: 0×41 <–value to write
CS DISABLED
SPI>

We start an SPI transaction by enabling the 23K256 chip select line ([). We send the write configuration command (0b1, 0x01, or 1), followed by the new settings for the configuration register (0b01000001, 0x41). We set bit 6 for sequential access mode, and set bit 0 to disable the hold pin function. Bits 5-1 have no function, but the datasheet says to always write 0. The transaction concludes by disabling the chip select signal (]).

SPI>[0b101 r]
CS ENABLED
WRITE: 0×05 <–read config register
READ: 0×41 <–value read
CS DISABLED
SPI>

Next, we use the read configuration register command (0b00000101, 0b101, 0×05, or 5) to verify that the settings were properly written. This command returns one byte (r) which should match the value we wrote in the previous operation (0×41, or 0b01000001).

Data access

Now we can read and write data to the chip. Writes begin with the data write command (0b10, 0×02, or 2), followed by two bytes which determine where to write the data. The values to store are sent after the address. Depending on the access mode, a single byte, a page, or the entire memory can be filled in a single operation.

SPI>[0b10 0 0 1 2 3 4 5 6 7 8 9 10]
CS ENABLED
WRITE: 0×02 <–data write command
WRITE: 0×00 <–address byte 1
WRITE: 0×00 <–address byte 2
WRITE: 0×01 <–start of data to write
WRITE: 0×02
WRITE: 0×03
WRITE: 0×04
WRITE: 0×05
WRITE: 0×06
WRITE: 0×07
WRITE: 0×08
WRITE: 0×09
WRITE: 0x0A
CS DISABLED
SPI>

We start with the write data command (0b10) and set the write location to the beginning of the chip (0 0). We send a total of ten values to store, the numbers 1 to 10.

After writing the data, we can read it back with the read data command (0b00000011, 0b11, 0×03, or 3).

SPI>[ 0b11 0 0 r:10]
CS ENABLED
WRITE: 0×03 <–read data command
WRITE: 0×00 <–start address byte 1
WRITE: 0×00 <–start address byte 2
BULK READ 0x0A BYTES: <–read out 10 bytes
0×01 0×02 0×03 0×04 0×05 0×06 0×07 0×08 0×09 0x0A
CS DISABLED
SPI>

We send the read data command (0b11), followed by the address from which to start reading (0 0). We then read back 10 bytes (r:10). The 10 byte are the numbers 1 to 10, the same values we wrote in the previous step.

Like this post? Check out the parts posts you may have missed. Want to request a part post? Please leave your suggestions in the comments.

Frozen Cache is a blog dedicated to a novel way to prevent cold boot attacks. Last year the cold boot team demonstrated that they could extract encryption keys from a machine’s RAM by placing it in another system (or the same machine by doing a quick reboot). Frozen Cache aims to prevent this by storing the encryption key in the CPU’s cache. It copies the key out of RAM into the CPU’s registers and then zeroes it in RAM. It then freezes the cache and attempts to write the key back to RAM. The key is pushed into the cache, but isn’t written back to RAM.

The first major issue with this is the performance hit. You end up kneecapping the processor when you freeze the cache and the author suggests that you’d only do this when the screen is locked. We asked cold boot team member [Jacob Appelbaum] what he thought of the approach. He pointed out that the current cold boot attack reconstructs the key from the full keyschedule, which according to the Frozen Cache blog, still remains in RAM. They aren’t grabbing the specific key bits, but recreating it from all this redundant information in memory. At best, Frozen Cache is attempting to build a ‘ghetto crypto co-processor’.

We stand by our initial response to the cold boot attacks: It’s going to take a fundamental redesign of RAM before this is solved.

[via Slashdot]

A coworker approached us today wondering if they could get a performance boost using Samsung’s newly announced 256GB SSD. Most of their work is done in browser, so we said “no”. They’d only see benefit if they were reading/writing large files. Their system has plenty of RAM, and we decided to take a different approach. By creating a filesystem in RAM, you can read and write files much faster than on a typical hard drive. We decided to put the browser’s file cache into RAM.

We installed the Espérance DV preference pane in OSX to facilitate RAM disk creation. It’s really simple to setup. Just select how much space you want to dedicate to the disk and create it. You can have Espérance DV recreate the RAM disk on start and even have it automatically restore from a disk image. There is a check box for moving Safari’s Web Cache to the RAM disk, which creates the necessary symlink. You can also use it to speed up Xcode builds. Moving Firefox’s cache is fairly simple:

$ rm -r ~/Library/Caches/Firefox
$ ln -s /Volumes/RamDisk/Firefox ~/Library/Caches/Firefox

Since the browser isn’t having to hit the hard disk on every page load anymore, the performance is much snappier. Xbench says our random reads from RAM are now 86.19MB/sec instead of 0.61MB/sec when the cache was on the hard drive.

We immediately began looking for ways to get the entire OS into RAM; Tin Hat is a version of Linux that does that.

We’re very happy with the results of our RAM disk browser upgrade. Let us know in the comments if you’ve had a similar experience doing this in Windows.

An article in EETimes suggests that we may see a memristor-based memory prototype in development as soon as 2009. The memristor is claimed by many to be the theorized fourth passive circuit element, linking the fundamental circuit variables of charge and flux. This news may not sound that exciting to most computer geeks, but this new component could usher in a new era of computer memory by forming the basis of RRAM (resistive random-access memory).

Scientists at HP labs have finally confirmed that the memristor behaves as their theories predicted. The reason that the component will work so well for memory is that the process is nonvolatile and the bits themselves will only change after the CPU tells them to. The bits in current DRAM systems slowly fade out and require a refreshment every 50 nanoseconds.

[via /.]