Amiga 1200 with SSD.

[Toni Wilen]

Stupid suggestion: partition is not set to automount? (Change-button in partitioning screen, check also filesystem type)

I don't see how it can be HD problem: partition table is not disappearing after power cycle and even if partition's block(s) disappear for some unknown reason, C:Info should still list all partitions. (Either as "not a dos disk" or "no disk in drive" status)

[IrY100Fan]

@Toni Wilen
I have double-checked that the partition is set to Automount and the file system is set to Standard File System with Fast File System enabled. I have also tried without FFS, changed the MaxTranfer value to 0x01FE00 (although I believe this to only affect large data transfers), set the device cylinders to 2047 to make it think it's a smaller drive than it is and all without success.

I just can't fathom what the issue is. I would think as long as HDToolBox is writing the partition table correctly then Workbench should see the unformatted drive.

[thomas]

Well, now you are entering advanced topics:

- dump the RDB and partition table into a file and attach it here for examination
- mount the partitions manually and format them to see if they work at all
- load updated IDE drivers from floppy disk to see if it makes any difference
- check if a firmware update is available for the SSD
- try with another (mechanical) HDD and check if it has similar issues
- if that works, copy the working RDB and partition table from the HDD to the SSD

[IrY100Fan]

I have a little more information available...

I was able to get the system to see the SSD. I connected the SSD via a USB-SATA adapter to my PC and used WinUAE to partition and format the SSD. When I moved the SSD back into the A1200 and booted from the OS 3.1 Install floppy. I can now see the drive and partitions I created. Next, I proceeded to install Workbench 3.1 on the SSD via the A1200. The install looked like it went through okay but it will not boot from the SSD. I entered the "Amiga Early Startup Control" screen and noticed the SSD does not show up in the boot options list. I put the SSD back on the PC, started up WinUAE and the OS booted up perfectly fine.

So,
It appears everything done on the A1200 is being correctly written to the drive but the A1200's ROM seems unhappy with the SSD. (At first glance.)

@thomas
I haven't gotten around to tackling anything you asked for yet. I will attempt to complete your list today if time permits.

[IrY100Fan]

@thomas
Since I am not fluent with how Amiga handles RDB and partition tables, here are my best attempts...

I zeroed the entire SSD on my PC using the "dd" command. I then used the A1200 to create a single 250MB partition. Attached are screen grabs of how I configured the SSD.

The attached file "rdb.dmp" contains the first 16 blocks of the hard drive which should have the RDB and partition table. The first 4 bytes contain the signature "RDSK" so I'm sure I got the RDB data. I see a reference to "DH0" but I don't know if that's part of the RDB or part of the partition.

I tried to mount the partition manually using "mount dh0:" but I get the error "Cannot open DEVS:MountList". I've never used the mount command before so I may be doing it wrong.

I'm not sure how to update the IDE drivers. Would this be a newer version of the "scsi.device" file?

I believe the SSD is already running the latest firmware available.

I don not have any mechanical IDE drives at this time to test with.

[thomas]

16 blocks is not enough. The file system code is stored in the RDB area making it a lot bigger. You should dump all blocks until you find one which does not have a 4-letter signature in the beginning. Or just dump the first 2MB, then everything is contained for sure.

Knowing that the drive is an SSD I would tweak the geometry a bit for proper alignment.

For example

Heads = 16
Sectors per Track = 128
Sectors per Cylinder = 2048
(this aligns partitions to megabyte boundary)

And file system block size = 4096

[IrY100Fan]

@thomas

I repartitioned the drive as you recommended. Attached is a dump of the first 32KB of the SSD. (It was all zeros after about the 27-28K mark to the 2MB mark.)

[IrY100Fan]

I received my CF and adapter today, installed it and things seem to be working well. The old A1200 actually boots really fast from solid state storage. (About 5 seconds from power-on.)

Not giving up on the SSD issue...
I copied the entire contents of the recently setup CF to the Transcend SSD. The SSD still will not boot or show the partitions. I am beginning to believe that my chances of getting the SSD working are slim.

Curiosity got the better of me, so I ordered a IDE-to-SATA bridge so that I can try one of the other SATA SSDs I have laying around. I don't hold much faith in those bridge-adapters, but it was only a few dollars to know for sure.

[IrY100Fan]

Update on the A1200/SSD issue...

I received my IDE-to-SATA adapter before the weekend. I hooked it up and tested it with a number of SATA SSDs. (OCZ 30GB, WDC 64GB, Mushkin 120GB) I get the same result as when I tried the Transcend SSD. HDToolBox can see and partition the drive and changes are remembered after reboot/power-off. The SSD partition never shows up on the desktop to to allow me to format it. Plus, the SSD is not shown in the Boot section of the Amiga's "BIOS". I did however put a SATA SSD on WinUAE, formatted it and I am able to use it on the real Amiga, I just can't boot from it.

Maybe I'll try creating a custom boot floppy with updated drivers (scsi.device ?) and see if that helps at all.

[IrY100Fan]

I created a custom 3.1 Install floppy using a updated scsi.device 43.24. This updated scsi.device file seems to correct the issues with the SSD. This module even stays resident after a reboot allowing the "BIOS" to see the SSD as well. So it appears that I am dealing with an incomparability between the SSD and the scsi.device built into the Kickstart 3.1 ROMs. (v40.68)

The scsi.device patch is really annoying though, it keeps flashing up a a message saying that the demo time has passed. (It is dated 1998.) Does anybody know where I can get a more recent updated scsi.device patch that works with AmigaOS/Kickstart 3.1? (I found a patch on AmiNet, but it requires numerous files from the 3.9 OS which I don't have.)

[Jope]

Patch your scsi.device to remove the timeout alert.

http://aminet.net/package/util/sys/patchstrip

There is no BIOS nor a BIOS Setup in the Amiga. What you're looking at is the Early Startup Menu.

[IrY100Fan]

I made a custom Workbench Install disk. On the disk I have an updated scsi.device loaded (which seems to survive even after a warm reboot) and I now have no problems accessing the SSDs. When I partition the SSD with HDToolBox and reboot, the unformatted drive's icon now appears on the desktop and can format it without any issues. Also, since the new scsi.device stays resident even after a warm reboot, the Eary Startup Menu now shows the SSDs as bootable devices.

Just for fun, while the system was able to see SSDs, I thought I'd take some quick benchmarks to see if there was any benefit to going through all this pain of getting a SSD working. I did a format of a 160 GB partition of each device to see how long it would take and also ran a drive benchmark with SysInfo. Below are some quick and unscientific observations.

Here are the CF cards I had available:

SanDisk Ultra 4GB CF Card = 1:56 m:s to format / 1.83 MB/s in SysInfo
SanDisk Ultra 8GB CF Card = 1:56 m:s to format / 1.83 MB/s in SysInfo
Transcend 300x 4GB CF Card = 1:58 m:s to format / 1.83 MB/s in SysInfo

Here is the IDE SSD I have:

Transcend 64GB SSD = 1:56 m:s to format / 1.84 MB/s in SysInfo

A finally, here are a few SATA SSDs connected through a IDE-to-SATA bridge adapter:

Kingston ssdNOW V Series 30GB SSD = 1:21 m:s to format / 2.76 MB/s in SysInfo
WD SiliconEdge Blue 64GB SSD = 1:21 m:s to format / 2.75 MB/s in SysInfo

I was shocked by these numbers. While searching on forums, I was under the impression that the best you could see from the on board IDE was about 1.8 to 1.9 MB/s. So there seems to be no performance increase with my Transcend IDE SSD over CF cards; but at first glance, the SATA drives appear to give a nice performance boost.

I don't know if anyone cares about this stuff, but I am going to continue doing some testing and research. I will try and keep this thread up to date with what I find.

[nogginthenog]

For what it's worth my A4000 (Cyberstorm MK II 68060) gets:
Kingston 16GB CF Card = 2.35 MB/s in SysInfo

I would have added my CyberSCSI results but my Amiga is playing up.

[oddodo]

I also have a Transcend 32GB and have no problems maybe it works because i use pfs3 ?
BTW does it work when you connecht it to your PC ?

[ShK]

Originally Posted by IrY100Fan

Here are the CF cards I had available:

SanDisk Ultra 4GB CF Card = 1:56 m:s to format / 1.83 MB/s in SysInfo
SanDisk Ultra 8GB CF Card = 1:56 m:s to format / 1.83 MB/s in SysInfo
Transcend 300x 4GB CF Card = 1:58 m:s to format / 1.83 MB/s in SysInfo

Here is the IDE SSD I have:

Transcend 64GB SSD = 1:56 m:s to format / 1.84 MB/s in SysInfo

A finally, here are a few SATA SSDs connected through a IDE-to-SATA bridge adapter:

Kingston ssdNOW V Series 30GB SSD = 1:21 m:s to format / 2.76 MB/s in SysInfo
WD SiliconEdge Blue 64GB SSD = 1:21 m:s to format / 2.75 MB/s in SysInfo

Is all these test made with scsi.device 43.24 or only bridge adapter test?

[IrY100Fan]

@nogginthenog:
I'm jealous of your setup. I have been searching for an A4000 and would love for it to have a '060 processor but I am unwilling to pay the exorbitant prices being asked for that setup. In the meantime my A1200 is good enough. I wish I could find an affordable '060 accelerator for it as well.

@oddodo:
On my A1200's stock configuration, the Early Startup Menu doesn't see the Transcend 64GB hard drive. I don't get far enough to even think about what filesystem to use when formatting it. This seems to be linked to the particular version of the scsi.device in my Kickstart 3.1 ROMs. The Transcend SSD works fine in my PC.

@ShK:
All of the benchmarks were taken using the updated scsi.device. (I wanted to try and keep things as equal as possible for benchmarking.) The CF cards were tested through a CF-to-IDE adapter from AmigaKit. The Transcend 64GB SSD is natively IDE, so no adapter was used there. And the SATA SSDs were connected using a SIIG IDE-to-SATA bridge board.


Since the SATA SSDs perform better then the CF cards, I am going to try another direction to replicate that magic without using an updated scsi.device. I just ordered one of those KingWin IDE DOMs (Disk on Module). From what I can tell, their firmware is more optimized for random IO than CF cards plus they have automatic TRIM and wear leveling built in. I'll update this when I have the results of that test.

[gulliver]

@IrY100Fan

I am just curious about the difference between the IDE SSD and the SATA SSDs.

Is this difference due to faster drives (newer technology) or something related to a hardware buffer present in the IDE-to-SATA bridge adapter?

[IrY100Fan]

@gulliver:
The Transcend IDE SSD was never a great performer to start with. In the Windows XP laptop I had it never really benchmarked above about 30-40MB/s. The SATA SSDs I have all benchmark above 450MB/s. Also, I think the small file/random I/O characteristics of the SATA drives are far more optimized. The nice thing about the Transcend is it was sort of developed with older OS's in mind, so the drive itself does TRIM and wear leveling and doesn't require OS support for those features. Thant's kind of why I thought it would be great in my A1200.

The KinWing DOM I just ordered looks like (on paper) a sort of modern update to the IDE SSD. Here's hoping it works out of the box.

[gulliver]

@IrY100Fan

Thank you for the reply. So it was just probably newer technology...

Anyway, I would love to hear about the KinWing DOM

[thomas]

@IrY100Fan:

Formatting an SSD is not very wise for two reasons:

1. there is nothing in an SSD which could be formatted. The Format program just writes random data to every block on the disk. A cell in an SSD can only be written to a limited number of times. Therefore writing to every cell in the SSD for no reason just reduces the life time of the SSD but has no practical use.

2. a cell which has been written to once can only be written again after it has been erased. Without TRIM which erases unused areas during idle times, writing once to every cell on the SSD just reduces speed. Once the formatting has finished the SSD will be slower than before.

And there is no such thing like TRIM without OS support. Only the file system knows which areas of the disk are unused. The SSD firmware could perhaps TRIM blocks which have been filled with all 0s or all 1s, but it cannot TRIM deleted files which is its actual task. Especially not if you use an alien file system, not to mention the alien partition table.


EDIT: Thinking a bit more about it, automatic TRIM could be implemented in combination with wear-levelling: if the operating requests to replace a non-empty block, the replacement could be written to somewhere else on the disk and the original block could be erased.

But this makes formatting even worse, because if you fill the entire disk with random data, there is not a single block left for wear-levelling and therefore automatic TRIM cannot be done.

Automatic TRIM and wear-levelling only work if there is some empty space on the disk. So it works best in combination with over-provisioning, i.e. leave 10% or more of the disk empty.

Now that you have already filled the disk with 100% garbage, you have to connect the SSD to a PC with TRIM support and send it the command to TRIM the entire disk. Then you can connect it again to your Amiga and create your partitions. But leave 10% without partitions and do *not* format your partitions.

Always use quick-format on any harddrive-like device!