Anonymous Coward wrote:

I was always under the impression that a 16-bit ISA slot at 8MHz topped out at 5MB/sec for non-DMA file transfers. (DMA transfers should be slower).

I could increase the DMA transfer rate to 10 MB/s just to see if it does anything. The SCSI BIOS has a self-test for this, so if it passes, I might give it a go.

Anonymous Coward wrote:

I was always under the impression that a 16-bit ISA slot at 8MHz topped out at 5MB/sec for non-DMA file transfers. (DMA transfers should be slower).

I was meaning 16 bit 16 MHz ISA slots

There isn't an option on the AMI Mark V Baby Screamer to adjust the ISA divisor. It is running at 10 MHz with a 40 MHz CPU.

feipoa wrote:

There isn't an option on the AMI Mark V Baby Screamer to adjust the ISA divisor. It is running at 10 MHz with a 40 MHz CPU.

oh! I read some 25ish years ago on some computer magazine, some BUSes frequencies and performances summary table if I'm not wrong, that ISA max. speed was 16 bit 16 MHz...

I don't think ISA cards will cope with 16 MHz. I think 10 or maybe 11.1 Mhz is considered a safe upper limit.

feipoa wrote:

I don't think ISA cards will cope with 16 MHz. I think 10 or maybe 11.1 Mhz is considered a safe upper limit.

Really? wow!
Then, even in case I recall correctly, that summary should have been a summary of the max. theoretical limits of each bus, not considering the real life of the various cards.

Deunan wrote:

The 5.1 version of SCSI2SD PCB has room for a DB25 connector (that you need to get and solder in yourself), precisely to be used with common external SCSI cables. Depending on what kind of connector your card actually has you might need to hunt down a matching cable but that isn't usually much of a problem. DB25 doesn't have all the ground pins of a typical SCSI ribbon so the transfer speeds will be lower than SCSI-2 maximum, but then again v5 SCSI2SD isn't that fast in the first place.

That's a bare PCB with some holes for support pegs in the corners though, if you want a nice case you either have to 3D print it yourself or buy an old external HDD case and reuse that. Two things to note: SCSI ID setting is done via PC software when configuring SCSI2SD and the card, so you can't re-use the nice mechanical switch that the HDD box will likely have on the back. But on the bright side SCSI2SD can usually run on the terminator power supplied via the SCSI cable alone (if it's not too long) so any case will do, doesn't have to be one with a PSU in it.

I've recently got an SHD-FMX240 external HDD enclosure from ebay, in great shape, for some 50 Euros plus shipping. And the best thing is the drive in it (240MB) still works. Opportunities like these are rare but do happen.

Thanks for your reply. Actually the at least one of the SCSI2SD sites offers the option to install that DB25 on their for you. What are the system requirements for the software and does power over the SCSI cable raise any possible issues of damaging interface cards? I know the power over the floppy cables for certain Tandy machines, for instance, can end in tragedy if not considered.

Honestly, I'd really rather prefer CF over SD... I guess I'll have to just keep looking.

It wouldn't be too difficult to order an enclosure for the ACARD + CF-to-IDE adapter. You could use a wall wart for power.

I too would prefer a complete CF solution, but, SD is what is available. Maybe send Michael (the creator of SCSI2SD) an e-mail requesting a CF type adapter in the future? Has anyone asked him about this possibility?

feipoa wrote:

It wouldn't be too difficult to order an enclosure for the ACARD + CF-to-IDE adapter. You could use a wall wart for power.

Acard? I have an CF to IDE, but I was under the impression that SCSI/IDE wasn't compatible. I agree, it would be great to see a CF adapter in the future, especially with how expensive the card readers are for SCSI.

I think I paid $100 for my Acard 7720U more than a decade ago. How much are they now? Is SCSI2SD v6 much cheaper? CF-to-IDE is very cheap.

CF to IDE is easy because a CF card will natively support that interface. So all you need is match the connectors on both sides. Obviously then an adaptor will be cheap and plentiful. Both are, however, pretty much obsolete tech - I don't think anyone is going to bother making a new SCSI to IDE adapter. Simple fact is SCSI to SD is cheaper to make without the big (PCB-wise) delicate CF socket with it's 40 tiny gold-plated pins. Unless it's a for a client who needs it so much they will pay whatever you ask.
On the bright side CF to SCSI adapter should be way faster than SCSI2SD - but then, we are talking DOS machines here with SCSI-2 being the upper limit of data transfers. If you want Ultra speeds then yeah, CF makes more sense but that's not going to be cheap. Than again perhaps SD-based device with proper UHS card support could beat that - in both price and speed.

As for using terminator power - I don't think there's any danger, SCSI2SD does not pull that much current and any reasonable SCSI card will have built-in protection for shorts and other bus faults. There shouldn't be any issues, certainly nothing that couldn't arise with externally powered SCSI device as well.

For the SD and CF cards scanned on the previous page, I have attached the WinBench 96 - Disk Winmark results. Unfortunately, while it booted, the 2 GB SD card inserted into the CF adapter returned errors upon running the benchmarks

1WinBench could not load the string resource number 98. Check for a corrupt file.

It is interesting to see the incremental performance enhancements with newer SD cards, particularly with random writes, but not exclusively. While according to the author of SCSI2SD, the device does not make use of UHS-1, yet the SanDisk class 4 card with UHS-1 performed better than the SanDisk Ultra class 4 card without UHS-1. The improvement when using the class-10 card over the class-4 card was fairly unimpressive. For the same class 4 card, the SanDisk Ultra outperformed the Kingston by 23%. Even the SanDisk class 2 card beat the Kingston class 4 card. As others have noted, there is probably a lot more to the card's performance than just the published ratings.

I am curious as to how much more incremental gains could be achieved by using the current top-rated SD card.

krcroft wrote:

Here's a link to SanDisk's A2-rated Extreme Pro - https://www.amazon.com/dp/B07G3H5RBT/ Yes, you will find many more "Extreme Pros" that cost less, but they won't be A2 rated!

I noticed that the card in that photo says SDXC. Does SCSI2SD support SDXC, or only SDHC? If SDXC works, then here's an even cheaper A2, https://shop.sandisk.com/store/sdiskus/en_US/ … -UHSI-Card-64GB

Thanks for the test. Does Winbench also test write speeds? If so the combined scores you get will be skewed towards the high-end cards. Keep in mind that in typical DOS, and even modern user-oriented PCs (so not servers or workstations) you don't actually do a lot of writes, mostly reads. You might want to do a separate read test, and usually you'd care more about random access than sequential reads since DOS files tend to be small and there's not a lof of buffering going on, unlike in Windows.

As for SDXC, these are backwards-compatible with SDHC - though some devices might get confused by the higher capacity so it's not guaranteeed they'll work. However SDXC requires the card to use exFAT for the filesystem - and that is Microsoft creation to which they still hold valid patent rights. That's why only "proper" commercial projects (or Chinese clones that don't care) will support exFAT. Devices like SCSI2SD require plain old FAT (16/32). It is possible to reformat the card, obviously, though not with the official SD Formatter tool, it'll allow exFAT only on SDXC.

this is getting more and more interesting, thanks!

Deunan wrote:

Thanks for the test. Does Winbench also test write speeds? If so the combined scores you get will be skewed towards the high-end cards. Keep in mind that in typical DOS, and even modern user-oriented PCs (so not servers or workstations) you don't actually do a lot of writes, mostly reads. You might want to do a separate read test, and usually you'd care more about random access than sequential reads since DOS files tend to be small and there's not a lof of buffering going on, unlike in Windows.

Yes, WinBench96 tests for read and write, sequential and random, 200 bytes, 500 bytes, 2048 bytes, and 4096 byte block sizes. This is indicated on the bar graph and in the raw data contained in the first post. For the expanded data with the additional SD cards, refer to the attached Excel sheet.

Deunan wrote:

As for SDXC, these are backwards-compatible with SDHC - though some devices might get confused by the higher capacity so it's not guaranteeed they'll work. However SDXC requires the card to use exFAT for the filesystem - and that is Microsoft creation to which they still hold valid patent rights. That's why only "proper" commercial projects (or Chinese clones that don't care) will support exFAT. Devices like SCSI2SD require plain old FAT (16/32). It is possible to reformat the card, obviously, though not with the official SD Formatter tool, it'll allow exFAT only on SDXC.

Will DOS/FDISK let me delete the exFAT and create FAT16 partitions using SCSI2SD? Will WinXP let me do the same if I put the SDXC card into a USB card reader?

EDIT: Excel datasheet moved to the location under the multi-SD card chart above.

feipoa wrote:

Will DOS/FDISK let me delete the exFAT and create FAT16 partitions using SCSI2SD? Will WinXP let me do the same if I put the SDXC card into a USB card reader?

You can delete those Non-DOS-Partitions with FDISK.

Well, the "SD: Sandisk, class 2" is actually a bit faster at both random and sequential reads than "SD: Sandisk Ultra, class 4", but sucks at random writes. Shows that if you mostly do reads (like, have a DOS gaming machine and the only writes are saves) a cheap card will do fine.
But I'm curious about the sequential write results - those are awfully close to one another. I suspect your OS just buffered all the data (so the testing program isn't actually doing it right). Also, the "200 bytes" category is kind of useless form device perspective, it's less than 1 full sector and will just get buffered the OS. So what is really measured here is the OS overhead and data copying rather than directly the card speed (but obviously that also has an impact). "200 bytes random write" is even more puzzling, some results are all over the place.

Cards, not just SDs but in gerneral, can have partitions or be just one "flat" volume wih a filesystem. The other option is like having just one partition but without partition table so you can't add more. But useful in many cases as you'd just want all of the card space for the FS anyway, plus partition tables have their limitations (DOS have size and count limits, GPT is very new and not well supported by small devices). I prefer the volume method - and for cards up to 512MB there really isn't any point in having PT unless you want DOS older than 5.0. It seems to work just fine with CF card on 386+ mobos. I realize that a big card has to be partitioned because FAT16 has 2GB limit but if someone's building a more modern machine with Windows NT4/95 or higher, you can use FAT32 or better yet NTFS. Or any of the ext flavours for Linux.

UPDATE: I take that back, I just checked and it seems DOS will create a partition table anyway (and then format it) during the installation process. It was so long ago I did that it somehow slipped my mind. So you can't have a single volume for DOS.

You can reformat the card, though I'm not sure if DOS FDISK can handle these sizes. There's always Linux. Windows has been dumbed down from version to version and nowdays you can't repartition the card (that's a software lockout for removable media). There are 3rd party tools though, like "FAT32 Format" for example. It doesn't partition though, only formats the already existing ones.

I can only seem to find A1 SDHC cards. For A2 everything is XDHC. It would be a shame to get an XDHC, format it as FAT16 and have it not work. I assume this means that the max size will be 32 GB, even with a 64 GB XDHC card? Have you tried formatting an XDHC A2 card as FAT16 or FAT32 and work in systems designed around SDHC?

On the codesrc page, http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD , under V6 hardware, it was mentioned that a full-sized SD card up to 128 MB was tested. As SDHC was limited to 32 MB, I assume this means the author tested an XDHC card? But I don't understand how all of 128 GB could have been used in this configuration. Perhaps tested the SCSI2SD with XDHC in exFAT on Windows 7, rather than a vintage [DOS] OS?

Electrically there is no difference between a SDHC and an SDXC card, it's just a marketing gimmick.

Given that the maximum partition size for FAT16 is ~4GB (or ~8GB if you use 128KB clusters), it would make no difference if the card were 32 or 64GB.