• Please review our updated Terms and Rules here

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

SCSI would speed things up by offloading data transfers from the CPU.
This is off-topic(as so many things are) but do you think using SCSI would speed up a later PIII build? I just bought a ZuluSCSI and have been trying to work out which system to put it in.
 
This is off-topic(as so many things are) but do you think using SCSI would speed up a later PIII build? I just bought a ZuluSCSI and have been trying to work out which system to put it in.

No, that would be significantly slower. By the time of the Pentium III, IDE had DMA/UDMA modes depending on the board. I've had several boards that had ATA-66/100 support. Even the crappy boards had at least ATA-33.

The ZuluSCSI on the other hand is SCSI-1, so 10 MB/s max.
 
No, that would be significantly slower. By the time of the Pentium III, IDE had DMA/UDMA modes depending on the board. I've had several boards that had ATA-66/100 support. Even the crappy boards had at least ATA-33.

The ZuluSCSI on the other hand is SCSI-1, so 10 MB/s max.

Interesting.

Does that mean there are other, faster scsi-to-SD adapters out there? This one youtuber uses a scsi-to-sd adapter in his main retro gaming build and I just always assumed it was a zulu.
 
Yup, a lot depends on the controller and the connection. On a P3, you could probably run Ultra3/Ultra160 with few problems, given the right controller. That can be way, way faster than an SD card.
 
Interesting.

Does that mean there are other, faster scsi-to-SD adapters out there? This one youtuber uses a scsi-to-sd adapter in his main retro gaming build and I just always assumed it was a zulu.

Faster solid state SCSI drives exist, it's just they're hideously expensive and don't offer more performance than IDE with DMA/UDMA transfer modes. Here's one such example:

When the manufacturer only lists "inquire" for the price, you know it's not an affordable solution. There are also SCSI to IDE adapters, but "there be dragons". I've used them before, and they're classified as last resorts.

But you can have the fastest SCSI drive in the world, and it can be meaningless if you have a slow SCSI controller. Both the controller and the disk must support the same SCSI standards to utilize them. You can do silly things like put an SCA-80 Ultra-320 SCSI drive on a stack of adapters to get it working on an old single ended SCSI controller, and it will work, but it will be limited to the slow speed of the controller.

Yup, a lot depends on the controller and the connection. On a P3, you could probably run Ultra3/Ultra160 with few problems, given the right controller. That can be way, way faster than an SD card.

Modern SD cards are far faster than any Ultra-160/320 drive. A UHS-II class card can do 300 MB/s read and write, you just need the equivalent SD controller to sustain those speeds. SCSI drives can't even win on latency, since SD cards have a uniform near instant seek time to every part of the flash storage.
 
You'd need a server board with PCI-X slots and a PCI-X SATA/IDE controller, and a SD to IDE/SATA adapter that can run at the full speed of the card. A very rare unicorn.

Another route would be a PCI-X or 66 MHz PCI USB 3.0 card and a card reader that can run at the full speed of the card. There is this thing that is dual keyed:

This card may run in 66 MHz PCI/PCI-X slots, but I'm not paying $80 to find out lol.
 
Faster solid state SCSI drives exist, it's just they're hideously expensive and don't offer more performance than IDE with DMA/UDMA transfer modes. Here's one such example:
Thank you for telling me about this! I can't afford one right now(or the 8 I actually need), but assuming my fortunes change at some point this is a GREAT solution for a patently ABSURD build I am workshopping in my head.


As for my original inquiry - I went back and watched the video, turns out the guy is just using a plain old SCSI2SD. I guess that's faster than the Zulu? All I know is he runs win98 off an SD card with zero problems and the speed seems to be great.
 
I've used SCSI2SD boards and YMMV on speed depending on the system and SCSI2SD version. This guy did a bunch of benchmarks on several Macs. It shows the SCSI2SD is better in random I/O, but is considerably slower in many cases in sequential I/O than a mechanical drive.


Even if it runs faster on a PC system, you're still limited to an absolute max of 20 MB/s of the SCSI-2 bus, when you have that option enabled in the firmware, and assuming the SCSI2SD controller can run that fast. It will be soundly beaten by an ATA-66/100/133 drive.
 
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.
There is no point, none whatsoever. The iRAM was very expensive, too small and speed-limited by its interface.

Alternative A: Any reasonably modern SSD will be able to saturate the interface. More capacity, same speed, cheaper.

Alternative B: Add more RAM and configure it as a RAM drive. Same ballpark capacity, more speed, cheaper.

It even used a FPGA as part of the card so its not like there's any custom chips.
Any FPGA provides "custom hardware". Teach your brain to see it as a custom chip.

If you don't know the internal logic, you cannot replace or reproduce it at all. If you know the internal logic, you can only replace it with the exact same chip. And even if you have the source code, you probably won't be able to produce the same binary from it. Synthesizing the same source code twice produces different results unless you take precautions.

Replacing CPLDs or FPGAs is a big no-no. They are far, far, far, worse than PALs, and even these are huge problems for reproductions.

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.
If you cannot use the memory bus, then the next fastest thing is a fast disk controller paired with a fast disk drive. High-end controllers should be able to saturate the system bus. Windows supports swapping (paging) to disk already, no need to fix anything. Driver support may be challenging.

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)
Then you should add RAM to the ISA bus and fix your BIOS instead. There is no point in fixing the whole world because you got scammed by a garbage BIOS. Adding ISA memory to anything beyond a 286/8 will slow down the system substantially anyway.

You might as well connect a faster disk and configure Windows to use it as a swap space.

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.
You can't build an ISA device with more than 16 MB of memory without using memory banking. And if you want that, it's called EMS and easily available at Texelec or other places. Configure it as a RAM disk and let Windows swap to it. It will be slow and Windows 9x will hate you for it.

Virtual memory is called virtual because it simply doesn't exist. Software can pretend it exists, and the price is an huge performance loss. No matter how you work around the physical memory deficiency.

I just bought a ZuluSCSI and have been trying to work out which system to put it in.
From my understanding, all these devices are geared towards older, slower systems where high performance is less important. Most SD cards are not particularly fast, especially when used in a non-linear fashion, and neither are most SD controllers.

To outperform the IDE interface on a Pentium III, you'd need very much high-end gear from back in the days, which cannot be reproduced easily or cheaply. Additionally, fast SCSI devices are rare anyway.
 
Sandisk had to slow down a lot of their USB 3.x tiny flash drives because they produced so much heat that the drives failed. Samsung mentions some heat protection but what is the actual performance once that kicks in?
 
Sandisk had to slow down a lot of their USB 3.x tiny flash drives because they produced so much heat that the drives failed. Samsung mentions some heat protection but what is the actual performance once that kicks in?
Dunno--I use USB Pen drives mostly for giving to other folks. Even then, it's hard filling one up.
 
Sandisk had to slow down a lot of their USB 3.x tiny flash drives because they produced so much heat that the drives failed. Samsung mentions some heat protection but what is the actual performance once that kicks in?

I have a pile of USB 3.x Sandisk flash drives and they fall on their face if you hit them with sustained heavy writes. They'll start off at 100-130 MB/s, then settle to 70-90 MB/s after a minute or so. Any longer than 2-3 minutes, they rapidly start falling off and can go down as low as 0-10 MB/s. They also get extremely hot, like don't touch the metal USB connector or you'll get burned hot.

I'm probably the worst case scenario for them, I move around huge amounts of video data, as well as large ISOs for programs and operating systems.

Haven't had a Sandisk flash drive die yet though.
 
Mostly a matter of the SD controller, wouldn't you say?
Correct. Which is why I wrote "most".

I'm not aware of any affordable SCSI-to-SD solution using such a high-performance controller. A BlueSCSI is said to achieve approximately 3 MB/s when imaging a fast disk by itself (acting as the host controller). Personally, I've only used SD cards in SPI mode, which is much slower.
 
Getting FPGAs to mesh with common interfaces (like DIMMs, PCIe, etc.) is generally a solved problem. You can get code for a DDR controller from github.
 
Back
Top