ACSI2STM

[badwolf]

Good evening,

https://github.com/retro16/acsi2stm

I see from the list of supported hardware that 'ASCI2SD' (by which I presume ACSI2STM is meant) is unsupported because of a number of issues with it.

Would you please be able to supply more information on what you consider the issues to be such that there's a possibility to resolve them and have the system be supported by HDDriver?

Presently I'm using an ASCI2STM with ICD Pro, which works well, but I've been an HDDriver user for many years and would prefer to move back to this product.

ASCI2STM is open source, so I'd be keen to take a look.

The most notable issue I see when attempting to use HDDriver is that it identifies a 16GB drive as only 1GB. Partitioning and usage seems OK, but obviously not beyond that limit.

When reading back an existing partition table, HDUTIL will correctly identify the partitions but, naturally, calculates a negative free space.

Regards,

BW

[uweseimet]

I don't know whether ACSI2SD and ACSI2STM are the same. Regarding ACSI2SD I stumbled upon reports of users having severe issues with the ACSI2SD hardware and various drivers. I suggest that you use google to find those reports. I would not be surprised if you find errors to be reported when running the SCSI Driver testsuite against ACSI2SD.

In the past (also in the not too far away past) I was contacted several times by users who were working on new ACSI drive solutions. In most cases these interfaces were abandoned and never released, and they also had numerous issues with correctly implementing the SCSI standard. The typical question asked is "What do I have to do to make my hardware compatible with HDDRIVER." My typical answer is (and has to be) "Make it compatible with the SCSI standard. It's the standard that counts, not HDDRIVER."

HDDRIVER is not going to support hardware/firmware that is obviously violating standards. On the other hand, if there is (new) hardware that is fully compliant with the standard, it will work with HDDRIVER (and other drivers) out of the box.
Of course, if somebody points out that HDDRIVER violates the SCSI standard (and proves this by citing the conflict with the standard) I will do my best to update HDDRIVER accordingly. HDDRIVER usually supports the revision of the SCSI standard (see https://www.t10.org/drafts.htm or https://archive.org/details/SCSISpecifi ... IDocuments) that is official at the time the respective HDDRIVER version is released.

Don't get me wrong, but what I learned from these failed attempts to implement compliant hardware is that the most (not all) authors of this kind of new hardware do not study the SCSI standard. They think that if they can read and write a sector they are done. But often media changes are not working (resulting in a potential loss of data), error handling is not working, LUN handling is not working, SCSI error codes are wrong or no error information is returned at all etc. Unfortunately that's the way it is in many cases.

>When reading back an existing partition table, HDUTIL will correctly identify the partitions but, naturally, calculates a negative free space.

What you do mean with "naturally"? This should only happen if something is wrong with the existing partition sizes, i.e. the sum of the sizes exceeds the drive capacity.

[badwolf]

What you do mean with "naturally"? This should only happen if something is wrong with the existing partition sizes, i.e. the sum of the sizes exceeds the drive capacity.

I meant it in the context of the immediately preceding line:-

The most notable issue I see when attempting to use HDDriver is that it identifies a 16GB drive as only 1GB.
...
When reading back an existing partition table, HDUTIL will correctly identify the partitions but, naturally, calculates a negative free space.

Ie. Whatever SD card I put in, even though the textual identifier reads back correctly with the capacity, the HDDriver utils has only received 1GB as the disc size.

I'll give the SCSI Driver Testsuite a go, thanks. I didn't do this as I didn't think SCSI was involved as this was an ACSI native project

I didn't find any mention of ACSI2STM on your board here, so I presume you mean you saw reports on the wider internet and inferred a non-compliance?

Thanks,

BW

[uweseimet]

Now I see. If only 1 GB is detected the device is very likely not ICD compatible, i.e. it suffers from the restrictions of the ACSI protocol. Restricting the usable capacity to 1 GB is just one of them.

ACSI is essentially a subset of SCSI, i.e. SCSI is the respective standard. This is why the SCSI standard is also relevant for ACSI. With ICD compatible devices/adapters the full SCSI command set is available. But this is something anybody implementing ACSI devices should know. It's a standard topic in the Atari world, and has been for the last 30 years.

Regarding reports on ACSI2SD, I noticed these somewhere, but don't know where anymore. This is why I suggested using google to find them. Might have been a German forum, not necessarily an English one. I think this was not about non-compliance, but about general data transfer issues with various drivers. So compliance to standards could not even be tested.

[badwolf]

Now I see. If only 1 GB is detected the device is very likely not ICD compatible, i.e. it suffers from the restrictions of the ACSI protocol. Restricting the usable capacity to 1 GB is just one of them.

ACSI is a subset of SCSI, i.e. SCSI is the respective standard. This is why the SCSI standard is also relevant for ACSI. With ICD compatible devices/adapters the full SCSI command set is available. But this is something anybody implementing ACSI devices should know. It's a standard topic in the Atari world, and has been for the last 30 years.

I see. Then I'm even more surprised it works with ICD Drivers, but not HDDriver.

But I've never used a hard drive on an ST before so it's not, unfortunately, familiar to me. Nor would I know if being compatible with ICD Drivers is the same as it being an ICD compatible device (which would make sense, but may not be true -- I wouldn't know).

I'm afraid I only joined the hard drive crowd with the Falcon (IDE)!

BW.

[uweseimet]

If a device correctly implements support for the full SCSI command set exactly like ICD does it, HDDRIVER correctly detects it. It works for the original ICD adapters, the Link96/97, UltraSatan, GigaFile and the Inventronik host adapter, Hatari, RaSCSI and more. If it does not work with ACSI2SD you have just found an issue with this hardware I'm afraid ;-).

[badwolf]

Well yes. I had assumed there was an issue with the hardware. I was hoping to fix it.

The reason I came to ask is you stated it (well, probably it) has numerous errors. I was hoping you would know what those errors were.

Anyway, running the test suite is producing some meaningful error messages, so I'll start there.

Thanks,

BW.

[troed]

I just received an ACSI2STM today. I don't know whether it's the same as the ACSI2SD - but I know that the creator managed to get it up to the "correct" speed and so I thought it would be of use.

The following are my findings:

1) There's indeed a 1GB limit when using HDDrutil to partition.
2) The device is only recognized by HDDriver _after_ HDDrutil has been run.
3) An installed hddriver.sys will autoboot (!), but will not detect the device.
4) An installed hddriver.sys will throw four bombs after device detection, unless Control is held down.

Regarding #1 - apparently other partition tools can use the whole card.

Regarding #2 - this is the only thing that seems to actually hold up HDDriver from working reasonably well at the moment. It seems HDDrutil performs an action when starting up (nothing needs to be done - just exit again) that's needed for HDDriver to see the device. Some missing initialization?

The device comes with a pre-made image with Pera Putnik's driver and apparently works well with it. I really really would like to use HDDriver instead.

The source for the project lives here: https://github.com/retro16/acsi2stm Being open*, I'd be happy to look into things like why the inititalization doesn't work etc if I know what to look for :)

regards,
Troed

*) The version I have, by "masteries" on Atari-Forum, is based on this repository but with several xfer speed improvements. I don't think his version is open atm.

[uweseimet]

Well, I cannot really say more than I already did. The SCSI standard defines in detail how a compatible device has to work. If somebody designs a new hardware she/he has to follow the standard.
The test suites validate some (but not all) functionality, and if a device is not compatible with the standard an error is reported.
Neither HDDRIVER nor HDDRUTIL do something special. They just expect that the standard is followed. Devices that violate the standard are not supported. What HDDRIVER or HDDRUTIL do (which may differ from version to version) is not relevant anyway, because they are not the standard, but they are implemented against it. This is why the vast majority of devices works (more or less everything except some recent ACSI solutions, which also fail the test suites). There is no special treatment of any device (blacklist or whitelist), i.e. HDDRIVER does not check whether a device is a Gigafile, UltraSatan etc. The same code works for all devices, and it is meant to work with everything that is compliant with at least SCSI-2.

[troed]

Thanks Uwe, I've run the tests and opened an issue on the project.

https://github.com/retro16/acsi2stm/issues/22