SCSI to Micro SD Interface Adapter

[Marchie]

Hi Folks,

Just received my SCSI to Micro SD Interface Adapter from AmigaKit and I need to get an SD card for it.

What types/brands of cards are people using with these?

I must confess I'm almost completely ignorant of SD card types and standards: When I search for Micro SD cards I get mostly Micro SDHC cards, which I believe is means SD Hi-Capacity.

Is SDHC this the same as Micro SD? Will it work with the SCSI to Micro SD Interface Adapter? (and/or Vampire for that matter?)

Thanks in advance for any help people can offer.

[thomas]

SD = up to 2 GB
SDHC = up to 32 GB
SDXC = more than 32 GB

The adapter has to support HC or XC, otherwise cards of these sizes won't work.

[thgill]

Unless Amigakit has altered the design of the SCSI2SD board from the original design, it supports SDHC and SDXC cards.

Speed wise, I wouldn't be too worried about what card to use. The SCSI2SD is limited to around 1 to 2 megabytes a second performance. Pretty much any class 10 card is way more than sufficient.


I use one in my x68000 computer. Works well, just not blistering fast by any stretch of the imagination.

[Marchie]

Great, thanks!

[Marchie]

Ok, fishing for help if anyone has any...

Ok, put a card in the adapter, connect to PC by USB just got "unrecognised USB device" so figured I'd just go withthe default 2Gb disk (SD card is 16gb)

Put it in the amiga, SCSI prep utility sees the disk, let's me partition it but seems ot be pretty random and confused about partitiion size and number of cylinders, etc.

If I quick-format the partitions (which I thought I variedin size from several hundred meg to 1 gig) I get one of about 123mb, then all the others at 999k...

Not sure what to do here, thought WB 3.1 could handle up to 4g? Can I low-level format the partitions? Or does that just kill the disk (like defragging an SSD)?

[mark_k]

I think the USB port is just for firmware updates, it doesn't act as a card reader. Could you post some screenshots of your partitioning program, maybe I could see what the problem might be.

[Marchie]

Originally Posted by mark_k

I think the USB port is just for firmware updates, it doesn't act as a card reader. Could you post some screenshots of your partitioning program, maybe I could see what the problem might be.

My understanding is that's mostly correct - although you can (apparently) also change the disk size, by default the card is suppose to show up as 2Gb.

Will post some pics of the HD prep utility when I get home. Thanks for your help!

[lost_loven]

usb port is used for firmware and set up of the sd card on the pc. You can set hd size there depending on size card (2/4/8/16/32/64) and save. Then on the amiga side boot your hdtools or use what ever to set your partition sizes then save reboot and quick format them. Also dont forget to check off a boot partition also if you make more than one.

[Marchie]

Ok, update if you're interested:

Got the utility working on USB (my Win 10 PC recognised it, Win 8 did not).

In short the it seems to work, but the size allocations are all over the place. If I configure the card (on the PC) as 2Gb, I get 124 mb drive on the Amiga (irrespective of how I partition it);
PC 4Gb = Amiga 256 mb
PC 8Gb = Amiga 510 mb *
PC 16Gb = Amiga 9Gb

At present I have split the SD card into three devices (not partitions) using the utility of 8Gb, 7.5Gb, and 400mb. Once placed in the Amiga it sees three drives of 510mb, 1260mb and 1260mb.

Yes, this makes no sense I know.

At least as it is I have three drives, decently large, and none more than 4Gb. I'm still concerned that the Amiga isn't reading the card correctly and as I fill up these drives I'll get data overwriting other data, etc. But don't know what else to do but forge ahead and see what happens.

mark_k: here's a snap of the partitioning program "SCRAMPrep" not sure it will help much though. It has a sliding bar to manually setup partitions, but the size counts seem to be all over the shop. Cylinder count does seem to correspond to drive size though - 260 cyl = 124mb, 520 cyl = 256. I've just auto-configured each drive as a single partition, that at least seems to give consistent results...

[Irl]

It could be that the sizes are correct, but the application is not able to see passed ~4GB. This means that, to the Amiga, your 4GB partition is ~256MB greater than this limitation, and so it wraps around the integer and starts counting from zero.

Same works for the 8GB, think of it as twice the 4GB and if the 4GB was about 256MB of wrap around, then the 8gb would have wrapped twice. I can't explain the 16Gb as 9Gb however.

[Irl]

Also, if you check out my post on a different SD reader (http://eab.abime.net/showthread.php?t=86613) I had noticed that the Windows tool was using base-2 (KiB, MiB, and GiB) whereas the SD card was labeled in base-10 (GB) for sizes.

More information is here: https://www.linkedin.com/pulse/20140...-mib-gb-vs-gib

This means that, for a 16GB SD card you really need to think of it as 14.9GiB when deciding how the SCSI reader is configured.

[Irl]

Originally Posted by Marchie

Can I low-level format the partitions? Or does that just kill the disk (like defragging an SSD)?

Low level format will not kill the SD, but it is usually superfluous. If the data on the device is marked as freespace by the filesystem, it should have no effect on the operation of the device.

In the old days, many hard drives were shipped without any initialization or low level preparations. This is required before using the drive for the first time, so the option exists on older OS's for that reason. Modern or used drives will already have this initial format and are good-to-go.

This means that low-level formatting is really only good for data destruction of a drive (Zero-pass).

SD Cards and SSD devices have a limited (although quite large) number of writes before they degrade. This is why de-fragmenting is bad for memory-devices (SD, SSD); it moves data around repeatedly trying to align all of it into congruent chunks and in doing so reduces the life-span of the device.

This is further compounded by the fact that fragmentation is only an issue on mediums that seek (Floppy, Hard Drives, etc). Fragmentation would cause the device to have to re-seek for each fragment of the file and greatly increase the read-times of those devices. Because SD and SSD devices are actually memory, addressing to multiple fragments of a file has little impact on performance as there is no physical aspect (changing rotational speed of drive, moving heads into position, reading data until requested sectors are located, etc).

In summary, de-fragmentation is bad for solid state devices because it has no gains and causes degradation of the lifespan of the device. It is unlikely to kill the device outright, unless performed regularly (such as an OS's cleanup processes that attempt to de-fragment data in the background). Low Level format would have been applied to the SD card at manufacture, and has no benefits aside from data destruction after that point.

[thebajaguy]

The basic rules with SCSI2SD, Aztek CFMonster, and any other large capacity device is:<br />
<br />
Most classic SCSI controllers will have a problem with &gt;4GB SCSI disk device targets. This is because SCSI devices are accessed by block numbers, and when an unsigned 32-bit integer (for a block number) goes past the value of 4GB, we have wrap-around to 0, 1, 2, etc. That's catastrophic corruption of the file system time. Ergo, in the SCSI2SD configure program, slice up your flash media to 4GB pieces (max), and not a byte more. <br />
<br />
The exception to the above rule is where the SCSI driver has been updated to handle &gt;4GB values on SCSI devices. GuruROM v6.11 and higher for GVP Series II/G-Force/Combo and A2091 supports it. There have also been some patches/updates done to the ROM-based scsi.device after KS 3.1 (research it). Other maker's controllers may have updates, or patches, but I don't follow them, so specific research on them would be needed.<br />
<br />
The next pitfall is the filesystem. FFS, classic 1.3-3.1 era, can only handle 2GB partitions. It has signed 32-bit integers in it that wrap basically at 2GB. There are options available with 3rd party PFS and SFS to go beyond 2GB per partition, but heed the 4GB line on the device unless you know your controller driver handles larger. An updated FFS came out after 3.1 - you will need to research the version - and it can be used - that supports &gt;2GB, but still heed the 4GB line on your controller driver. If you do go this route with FFS, you should be very careful how you modify boot blocks and re-save the FFS versions to the RDB on the disk - because loading an old FFS on a &gt;2GB new FFS partition is again asking for file system disaster - and sometimes the FFS loaded at boot time is in ROM (and gets patched at bootup). It is probably safest to keep FFS partitions to 2GB unless you truly need them bigger. In that case, experiment where you can afford to lose test data. <br />
<br />
It is advisable to make your first bootable partition &lt;2GB to ensure you always have an available boot drive.<br />
<br />
I have worked with SCSI2SD v5 (on an 8GB card, sliced up into 4 2GB pieces, looks like 4 SCSI drives to Amiga), Aztek MonsterCF (4GB), and I have a GuruROM for GVP Series II hardware, but also have older GVP Series I hardware and older FastROM with the 4GB limit. The slower SCSI2SD (vs Aztek) is still very good when it comes to small files - head seek and rotation latency are effectively 0ns, making any fragmentation delays also 0ns, so no defrag needed. Controller driver and OS/Filesystem overhead (latency) is the only delays. The SCSI2SD is still effectively faster than most of the mainstream SCSI drives of the early 1990's.<br />
<br />
Low Level format was a step needed when ST-506/RLL/MFM 'controllers' of the 1980's directly drove the stepper motors and electrical properties of the attached disk drive. Bad blocks (imperfect parts of the media) needed to be learned by the controller and written to tables also created/stored on that disk and maintained by the host's file system. All of that media information and bad block detail is hidden from the host computer and file system nowadays. Write a boot block, which defines the partition, mount it with a matching mountlist (or reboot and it's seen as unformatted) and quick-format the disk (puts a blank directory and block allocation map in place).

[Pat the Cat]

Originally Posted by Marchie

Ok, update if you're interested:

mark_k: here's a snap of the partitioning program "SCRAMPrep" not sure it will help much though. It has a sliding bar to manually setup partitions, but the size counts seem to be all over the shop. Cylinder count does seem to correspond to drive size though - 260 cyl = 124mb, 520 cyl = 256. I've just auto-configured each drive as a single partition, that at least seems to give consistent results...

My 2 cents worth - your values for cylinders, heads, and surfaces seem very strange.

I can't remember which one, think it's heads, but you are limited to max value of 255... so a value of 451 is way over the maximum of CHS limits.

An SD card doesn't actually have heads or different surfaces, of course, but SCSI drives do, and that is what the adapter should be trying to emulate.

This is a speculative post, HDToolbox defaults to 16 heads and 63 surfaces on my system, giving total of 1008 blocks per track. BUT, I'm using an IDE-SD adapter, not a SCSI-SD adaptor.

Personally, in your position, I'd be very tempted to just delete the PC partitions and use Amiga ones from scratch. I guess it depends whether you want to use an SD card to swap data from PC to Amiga or not... Linux is lovely for that, Windows isn't (although WinUAE is maybe what you are aiming for).

So, maybe trying to setup the device with WinUAE on the PC using Amiga software might be the way forward for you, as opposed to setting up partitions using just Amiga tools on the Amiga.

Sorry I can't add more, but I've shitcanned Windows as a complete waste of my time.

[mark_k]

SCSI drives are accessed in terms of sector numbers. Any cylinders/heads/sectors-per-track numbers are just fake and bear no relation to the actual drive geometry (all modern drives have a varying number of sectors per track anyway).

I'm not sure what's up with those weird ScramPrep fake-geometry figures. It could be that the SCSI-to-SD adaptor is returning bogus values in the rigid disk geometry mode page. That's probably where ScramPrep is getting the numbers shown under Drive Parameters from. Or maybe the SCSI-to-SD doesn't support that mode page, but ScramPrep was never tested for that case?

For each emulated SCSI drive, run SCSIQuery or SCSIUtil on the Amiga to tell you how many sectors the drive has. Then you can make up your own fake geometry values to put in the RDB (using a different HD-prep program, HDToolBox or RDPrep maybe?).

Another thing to watch out for... the RDB specifies a particular fake geometry (numbers of cylinders, sectors/track and heads). After changing the emulated SCSI drive capacity, if you have old data still in the RDB, HD prep programs may read that old no-longer-valid fake geometry and use it by default. You need to tell whichever prep program you're using to not do that, i.e. to use your own fake geometry values instead. If using HDToolBox, you click the entry for the drive in the list, then "Change Drive Type", then "Define New...". You can click "Read Configuration", but be sure to edit the Cylinders, Heads and Blocks per Track fields putting your own calculated values there instead.

[Marchie]

Thanks Pat, thanks mark_k,

Looks like I'm going to have to start digging deeper...

It must be a peculiarity of my SCSI card, but drives won't show up in HD toolbox (all the options/buttons are just greyed-out, like I would expect if no hard drives were attached at all). It expects me to set the partitions in the utility, then format them in WB.

WB reads the un-formatted partitions as 1.3G, but they come out at 300mb once formatted. (and neither of these values are correct BTW - they should be about 700mb)

Setting up everything under emulation sounds like an idea worth trying, I've been steering away from it because I know even less about emulation than I do real hardware, but maybe it's time to learn.

Originally Posted by Pat the Cat

Sorry I can't add more, but I've shitcanned Windows as a complete waste of my time.

If I understood Linux better, I would join you, Windows blows.

[mark_k]

Originally Posted by Marchie

It must be a peculiarity of my SCSI card, but drives won't show up in HD toolbox (all the options/buttons are just greyed-out, like I would expect if no hard drives were attached at all). It expects me to set the partitions in the utility, then format them in WB.

Did you set the device name tooltype in the HDToolBox icon before running it? You need to set it to
SCSI_DEVICE_NAME=whateveryourrscsideviceiscalled.device

I'm not sure what your SCSI device name is, maybe scram8.device or scram16.device?

[Pat the Cat]

Yeah, good point Mark...

Marchie - which sort of Amiga SCSI controller are you trying to get the device working with? Some have max partition sizes way smaller than 1GB, so that might be part of your issue.

[Marchie]

Originally Posted by mark_k

Did you set the device name tooltype in the HDToolBox icon before running it? You need to set it to
SCSI_DEVICE_NAME=whateveryourrscsideviceiscalled.device

I'm not sure what your SCSI device name is, maybe scram8.device or scram16.device?

No, I was not at all aware I had to set the device name, how do I do it? (it's scram16.device). Just execute a command "ED HDToolbox"? Or go to info in the menus?

Pat- will check the partition sizes too - I thought I was safe at 2g, but it's worth knowing I may not be.

Will upgrading from 3.1 to O.S. 3.9 iron out any of these issues? (I have it lying around, but got the impression it would just chew up more RAM for features that I just won't use on a 12mb/020 system).

[Irl]

Originally Posted by Marchie

No, I was not at all aware I had to set the device name, how do I do it? (it's scram16.device). Just execute a command "ED HDToolbox"? Or go to info in the menus?

Pat- will check the partition sizes too - I thought I was safe at 2g, but it's worth knowing I may not be.

Will upgrading from 3.1 to O.S. 3.9 iron out any of these issues? (I have it lying around, but got the impression it would just chew up more RAM for features that I just won't use on a 12mb/020 system).

In Workbench, select the HDToolbox icon, hold right mouse and use the Icon menu. Select "Information" and there is an edit box at the bottom. Find the entry. If it has parenthesis around it, remove them.

SCSI_DEVICE=scram16.device

Be sure to press return after changing the text and then save it and run it.