Anyone ever though about a clone/improvement on those RAM-drives?

[hunterjwizzard]

With all the clone PCBs people are building, I'm curious if anyone's ever started a project to clone something like the GIGABYTE GC-RAMDISK i-RAM. That card takes 4 sticks of DDR and turns it into a 4gb hard disk. It even used a FPGA as part of the card so its not like there's any custom chips. But the device itself was never common and the prices for used ones are absolutely insane.

Be really entertaining if someone could come up with a clone or just build something similar with improvements.

 

[Chuck(G)]

I don't get the need--a RAM disk card with limited battery backup (less than a day). Why not a simple SATA SSD (cheep!) and a PCI SATA controller (also cheep)?

 

[MrImprovement]

With all the clone PCBs people are building, I'm curious if anyone's ever started a project to clone something like the GIGABYTE GC-RAMDISK i-RAM. That card takes 4 sticks of DDR and turns it into a 4gb hard disk. It even used a FPGA as part of the card so its not like there's any custom chips. But the device itself was never common and the prices for used ones are absolutely insane.

Be really entertaining if someone could come up with a clone or just build something similar with improvements.

I owned and used one of these in the past - while pretty cool, I don't think it really fits in with much stuff , in that you can get SSDs that are just as fast and more durable in terms of not having the data go away if the battery dies.

 

[hunterjwizzard]

I mean, the silly things still go for $500-$600 used, so clearly someone has a need(or want) for them.

 

[Chuck(G)]

...$500 and Steve Jobs had nothing to do with it? I'm shocked--shocked, I tell you.

 

[krebizfan]

There are more recent cards built around the concept but with a small SSD to back up the RAM. It is silly but easy to implement and can catch database users desperate to increase IOPS. https://www.ddrdrive.com/menu1.html
From the other side, there are RAM disks designed to soak up all the excess RAM on video cards.

 

[GiGaBiTe]

it even used a FPGA as part of the card so its not like there's any custom chips.

The FPGA IS the custom chip. You can't just toss on the same FPGA on a clone card and everything will work, without the programming, the thing is useless. Gigabyte most certainly blew the security fuses or locked the chip, so it's not a simple matter of reverse engineering it. That FPGA is doing a lot of heavy grunt work, it has to emulate the SATA drive, do the talking over the SATA bus and be a memory controller for the DDR.

The reason nobody has replicated that card, is because it's entirely pointless. You have a comparatively tiny amount of storage with a huge amount of bandwidth that is almost entirely wasted. DDR-400 is 3200 MB/s, but Gigabyte put it on a SATA150 or SATA2 interface, which limits you to 150-300 MB/s of bandwidth. The only benefit it had was I believe the IOPS were much better than mechanical drives of the time, but that was again a limited usefulness with how little storage it gave you.

From the other side, there are RAM disks designed to soak up all the excess RAM on video cards.

You can do this on Linux with a script fairly easily. You can map video memory to a block device and format the block device as storage. Problem is finding a video card with enough video memory to be useful. There were some weird low end cards back in the day with a ridiculous 2 or 4 GB of RAM attached to them, but they're harder to come by today. But that setup is orders of magnitude faster than the weird iRAM gigabyte card, because the video card is on the PCIe bus and can read and write to the RAM almost as fast as the RAM speed is. Unlike the iRAM which was limited to the SATA bus speed.

 

[hunterjwizzard]

...$500 and Steve Jobs had nothing to do with it? I'm shocked--shocked, I tell you.

I know, right? Given the low capacity I thought they'd be giving these things away after a few years. They now sell used for more than the original MSRP.

There are more recent cards built around the concept but with a small SSD to back up the RAM. It is silly but easy to implement and can catch database users desperate to increase IOPS. https://www.ddrdrive.com/menu1.html

I'm not entirely sure if the ddrive actually went on sale. It debuted in 2009 but I've never found one used(and I have looked). There's also a 5.25" drive somewhere out there that's even more rare and pricy than the iRAM.

The FPGA IS the custom chip.

Yes. But you can get more FPGAs to program. You cannot get any more of some custom one-off.

 

[Chuck(G)]

Yes. But you can get more FPGAs to program. You cannot get any more of some custom one-off.

It's not the chip per se that's the concern, but rather what's in the chip that's the sticky wicket.

 

[Timo W.]

I don't get the need--a RAM disk card with limited battery backup (less than a day). Why not a simple SATA SSD (cheep!) and a PCI SATA controller (also cheep)?

They existed for the same reason as IBM's Microdrive: as a stop-gap until flash memory got cheaper.

So yes, completely obsolete and useless today.

 

[hunterjwizzard]

So yes, completely obsolete and useless today.

Just like everything else on this forum.

 

[GiGaBiTe]

Yes. But you can get more FPGAs to program. You cannot get any more of some custom one-off.

The chip may as well be a custom one-off part because of the programming. It doesn't matter if you can get ten thousand of the same chip if you can't also dump the programming. Most companies will lock the chip using various means that can be extremely difficult or impossible to get around. These aren't old GAL and PAL chips that you can brute force to figure out what they are, these FPGAs are fantastically complex internally. I'm not even sure if it would be possible to figure out how they work by decapping them.

 

[MrImprovement]

Searching for "sata interface fpga" gives a host of links of people who have built SATA interfaces into FPGAs and some are even open-source down to the FPGA and the PCB board design itself. You would have to figure out how to "reverse" the SATA flow so that your FPGA would be a target of a SATA command rather than the host reading the SATA device. I have no idea as to the level of difficulty that would entail.

 

[GiGaBiTe]

You would also have to implement a full DDR memory controller and then figure out how to make the memory talk to the SATA controller.

It's an enormous amount of work for virtually no benefit.

 

[rmay635703]

A more fruitful endeavor (possibly) would be to fix windows 3.1/95 memory service to directly support using virtual memory on an ISA/VLB or PCI card so the multitude of machines that had very low real or artificial memory limits could have a slightly faster memory option.

As an example I have a 386sx-25 that lack any reasonable way of expanding memory past 2mb (maybe 4mb if I get lucky but the setup program is problematic even on isa based ram)
If an ISA device were developed to allow for 16mb+ of whatever cheap commodity ram exists and it could be directly accessed as virtual memory without the disk penalty associated with creating a ram disk, you could have a moderately fast way of accessing ram based virtual memory.

Many systems with VLB and even early PCI also have very small ram limits (my AST wouldn’t go past 20mb despite trying lots of memory sticks)

Have a Ram/virtual ram expansion with a fast utility to directly address it would help those of us who like to use Windows 3.x-98 on older equipment but the stuff we found has very poor/proprietary ram expansion possibilities.

 

[GiGaBiTe]

As an example I have a 386sx-25 that lack any reasonable way of expanding memory past 2mb (maybe 4mb if I get lucky but the setup program is problematic even on isa based ram)
If an ISA device were developed to allow for 16mb+ of whatever cheap commodity ram exists

The 386SX only has a 16 bit data bus and a 24 bit address bus, and the entire memory map is limited to 16 MB. This includes all peripherals in the system that are memory mapped. You'll never be able to have a full 16 MB of memory on a 386SX, and in practice, a lot less.

 

[rmay635703]

The 386SX only has a 16 bit data bus and a 24 bit address bus, and the entire memory map is limited to 16 MB. This includes all peripherals in the system that are memory mapped. You'll never be able to have a full 16 MB of memory on a 386SX, and in practice, a lot less.

I can easily have 64mb of virtual memory as it’s not tied to any physical address limit. Even with 2mb of ram in 386 enhanced mode I have a 20mb swap file setup and can run (very slowly) software that is designed for 8mb+ minimum.

And I’m not able to expand its memory past 2mb and when I’ve tried ISA ram expansion I get stuck at a memory size mismatch. 12mb or even 8mb is a wondrous dream compared to 2mb

So your concerns about a 16mb physical ram limit wouldn’t apply, a faster virtual memory solution for old systems would be nice as even ssd is rather slow on a 386sx

 

[krebizfan]

I doubt that the RAM disk solution would be faster than an SSD since all the SSDs I have transfer data at a higher rate than what is theoretically possible with16-bit ISA.

The solution of switching to a motherboard with more memory slots would probably be cheaper than creating a new version of the dedicated RAM disks.

 

[rmay635703]

I doubt that the RAM disk solution would be faster than an SSD since all the SSDs I have transfer data at a higher rate than what is theoretically possible with16-bit ISA.

The solution of switching to a motherboard with more memory slots would probably be cheaper than creating a new version of the dedicated RAM disks.

It is if you can remove the disk interface overhead. Physical ram as virtual memory only requires an extra address instruction to decode as compared to in address ram, add the drive layer and max throughput drops fast.

A ram device that is not behaving as a disk drive has a max output of about 8mb/sec, there is no reason this ram needs to be tied to the at address space.

Virtual ram on a drive maxes out around 2.5mb/s depending on the CPU on the other side.

You would need a different virtual ram service to support physical virtual ram properly, I’m actually surprised that despite the high cost of ram it never came up as a solution historically as opposed to the rather awkward method of having addressable ram made into a ram drive to use as virtual memory.

Several steps there that aren’t needed to have the cpu fetch virtual memory most efficiently.

The above is of coarse ISA related go vlb or pci and any 386+ can address 4gb of ram on a card

 

[GiGaBiTe]

I can easily have 64mb of virtual memory as it’s not tied to any physical address limit. Even with 2mb of ram in 386 enhanced mode I have a 20mb swap file setup and can run (very slowly) software that is designed for 8mb+ minimum.

And I’m not able to expand its memory past 2mb and when I’ve tried ISA ram expansion I get stuck at a memory size mismatch. 12mb or even 8mb is a wondrous dream compared to 2mb

So your concerns about a 16mb physical ram limit wouldn’t apply, a faster virtual memory solution for old systems would be nice as even ssd is rather slow on a 386sx

A page file is not real memory, you're not expanding anything by having a huge page file.

The page file works by having a tiny window in the x86 address space where blocks of memory are swapped in and out of the disk. The reason it is so slow is because applications cannot run directly from page file, the blocks of memory have to be swapped in to real memory first. Large programs that exceed the real memory size will be painfully slow because they have to wait for the system to move the requested memory off the disk and into the system RAM.

Another limitation is the system BIOS and chipset. Just because the CPU can address some amount of memory, doesn't mean the system can. If the BIOS and Chipset have a smaller arbitrary memory limit, it doesn't matter how much memory you cram on the board.

You're also not going to get any sort of speed on the 386SX because of the 16 bit data bus. At minimum you have a 50% speed penalty because moving 32 bits of data requires two bus operations. And if you have a hard disk controller that doesn't support DMA (which was pretty much all of them at the time), it's going to be that much slower since the CPU is having to do the data transfers in Programmed I/O. SCSI would speed things up by offloading data transfers from the CPU.