SSD in Iyonix

I have a IDE to SATA converter. When placed in the Iyonix I can format a SATA mechanical drive if its capacity is lower than < 500 Gbyte. When I use a SSD it will give a ‘Format error on this track’ . When I connect the same SSD to a pi running RISC-OS 5.28 and format with HForm it does so without a problem. If I place the formatted SSD back in the Iyonix it complains it is not formatted. Someone having any ideas ?

Step 1: format to something lower than 256 GiB, since that is the Filecore limit with 512 bytes/sector. Also keep in mind that the IYONIX has a 128 GiB limit for UDMA operation (limitation of the ALi southbridge), so less than 128 GiB if you want it fast.

I am sure the topic of interchangeability between SCSI/USB and ADFS came up before numerous times. The only thing I remember is, that back in the 90s, we always formatted 270 MiB SyQuest media on ADFS, because then ADFS and SCSIFS was happy. If formatted on SCSIFS, ADFS could not read them. So sad that I mostly remember the mid-90s stuff instead of the stuff I read last year.

Hmm the sdd drives where one is 60 Gbyte and the other 120 Gbyte. To add to the mystery I also have an SSD in an A5000 which needed a modification on the IDE to SATA ( the famous 16 bit modification ) and works fine. About I can only use 500 Mbyte from it.
I didn’t know there were issues with SCSIFS and ADFS ;-). I heard today from someone else that also some SSD will give problems in Apple machines

issues with SCSIFS and ADFS

Most recently, I found that on the slimline IDE/SATA adapter with a 2.5" HD The formatting done by hform→usb using USB/SATA would not read on the IDE/SATA interface.
Formatting via IDE /will/ read on USB/SATA interface however.

Yes it seems that SATA SSD != SATA mechanical HDD I ordered the same type of SSD which work in the A5000 so lets see if I can get them to work in the Iyonix. I got the two SSD for under the Eur 50 so it is not that much money.

We tested a number of IDE to SATA interfaces a few years ago IIRC none worked on the Acorn IDE bus (A5000, RiscPC etc.) and none worked reliably ¹ on an Iyonix. I think there was one exception on the iyonix but there was another issue, something like it was a 44way IDE female.
We have recently come across one IDE to SATA that seems to work fine on the Acorn IDE bus in an A4000 but it is a 44way IDE male to mSATA so not ideal.
¹ IIRC the closest we got was one that seemed to work until you did a restart at which point the drive was reported as being unformatted!

Indeed the ones without the -IOCS16 modifications will not work in the A5000. I have one with modification in an A5000 which doesn’t to show the issues you pointed out. As a test I have a Logilink SATA to IDE converter ( LogiLink AD0006A ) with a 40 Gbyte SATA drive in the IYONIX which works perfectly without a hitch. So perhaps there are differences in IDE to SATA converters.
( Discussion about the -IOCCS16 :https://stardot.org.uk/forums/viewtopic.php?f=16&t=14016 )
It looks that IDE to SATA converters have a bit the same issues as CF Cards have as discussed in :https://stardot.org.uk/forums/viewtopic.php?t=16000

By the way thanks for the delivery of the Podule riser for my IYONIX it really completed the machine.

It seems there is progress in this case. When I use HForm (V 2.54 21 Jan 2003 ) on the IYONIX and use the option ‘I’ ( initialise ) instead of F it works like a charm. Strangly if I use the HForm program which is in the current Harddisk ( but that belongs to 5.28 ) it doesn’t work.
I have rebooted a couple of times and that went without any problems. The IDE to SATA converter even works without the 16 bits modification

RISCOS Version : 5.20

You may have fallen foul of an incompatibility. There have been reports that old versions of RO in the Iyonix won’t handle the longer IDLen field that newer versions of HForm use.

Do you know if that was by any change 5.20 ?.

The change was made in 2017 which corresponds to RISC OS 5.23. Hence RISC OS 5.20 would have a maximum idlen of 19.

Hmm, am I the only one here who thinks HForm is at fault for not checking the FileCore on the target machine is actually compatible with the change and either adapting or warning if not?

How can it know? You might use one machine to format a disk/drive for another.

Perhaps some explanatory notes?

How can it know?

Read the module version of FileCore?

You might use one machine to format a disk/drive for another.

It’s a fair point, in which case an on screen warning would be in order (in case you think you’re going to format this disc and copy some stuff onto it).

Perhaps some explanatory notes?

On screen. Because we all know how often us nerds bother reading the documentation. ;-)

Either way, formatting a drive in a format incompatible for the machine it is running on is…. what’s the polite word….

Do you say if I format a drive on a machine running RO 5.28 I cann’t put it in a machine RO 5.20 ?.

HForm should check if run on a machine which does not support IDLen=21, but can’t guess if you are formatting on a different machine.

What you can do is get to the part where it asks what LFAU to use, and then multiply its default suggestion by 4, which will result in an ID Len on 19 being used.

Do you say if I format a drive on a machine running RO 5.28 I cann’t put it in a machine RO 5.20 ?

No modern IDE standards drives will work on RO 5.20. It’s covered in the first StarDot thread you linked to, namely various changes were implemented in the 5.24 beta to support newer IDE standards. This included DRQ timeout changes and DMA/PIO mismatches.

Update your Iyonix to the latest stable OS release and it should hopefully then work. I’d suggest testing this by using a donor boot drive with the SSD as a slave; flashing Iyonix is not a good idea as the flash chips degrade over time and you’ll eventually brick it.

I’ve successfully got SSD’s to work all the way back to the A4000 (provided they support PIO), so it is possible. As you point out -IOCS16 becomes an issue as you go further back in the Acorn range, which can be fixed by hardware mods.

I believe the Iyonix supports IDE DMA transfer, so all SSD to date should work, provided the IDE standard is being adhered to by the OS.

then multiply its default suggestion by 8, which will result in an ID Len on 19 being used

Wouldn’t that be 2 ^(21-19) = 4 unless you’re using a different number system to me?

If a drive was formatted using the latest formatter/OS – the boot stuff copied over – would the drive be read able with whatever version of RO was last flashed?
Where the first job on startup – load the latest R0M.

@Sprow – sorry you are correct (excess alcohol exception), I’ve edited my post.

@Joh Abbott The good news was it is working I only had to use a somewhat older HFORM ;-). But because of the change of bricking my IYONIX by flashing I’m hesitant to do that. Soft loading doesn’t work either because I get a black screen. ( Outlined somewhere else on this forum )

Hi Timo,

Just a thought could your Iyonix issue be to do with the 147/148 module issue that was fixed in 5.29 post 20th December.

You could test by softloading the latest 5.29 on your Iyonix.

Wouldn’t that be 2 (21-19) = 4 unless you’re using a different number system to me?

Doesn’t the whole, override the default with a magic incantation bit rather imply that HForm ought to have an option to “format for legacy use”?

@Doug Webb
If I softload I get a black screen and it remains black so softload is not an option… ;-(.

The good news was it is working I only had to use a somewhat older HFORM ;-)

That might give you an accessible drive, but you will get DRQ timeout errors if you don’t update to a newer OS build.

If I softload I get a black screen and it remains black

Use 5.28 instead of 5.29, which may have an issue on Iyonix. If that still goes to a black screen, try a different version of softloader.