BlueSCSI v2025.08.02, HDDRIVER 12.62, ICD host adapter (Atari)

[uweseimet]

I thought I would add a note on the hardware/software combination in the title. Not so much to start a discussion, but maybe to prevent it or at least provide information.

I was contacted by a user of my hard drive software who reported issues with this hardware/software combination. Actually, not with an original ICD host adapter but with a host adapter that he said was reverse-engineered but supposed to be compatible with the original ICD interface. The user explained that BlueSCSI V2 would require a special firmware in order to work with the ICD interfaces, and that this firmware has already been prepared by the BlueSCSI team.

Because this sounded quite strange to me I tested the respective hardware/software combination with an Atari TT, see the screenshot. I did not find any issue. With an original ICD host adapter everything is working as expected. The two BlueSCSI drives (HD0.hda and HD1.hda) are correctly detected at ACSI IDs 0.0 and 1.0 (drives L: to T:). There were no problems with copying files etc. All BlueSCSI settings were the default settings, i.e. there was no bluescsi.ini on the SD card. The HDDRIVER settings also were the default settings, except for the device ID list to be checked when booting.

My conclusion is that if anything is not working as expected, it would have to be the reverse-engineered host adapter.

Edit: Just found this with an internet search: https://www.atari-forum.com/viewtopic.php?t=45310

[Biker1bob]

This is something that myself and Jokker have been working on. This is to work with the Atari and the interfaces designed by tOri. These are ICD interfaces reverse engineered. I think Jokker was going to suggest this as a fork, or possibly just add a FLAG in the ini that could be set.
So far I have tested the firmware (modified 2024-04-03 I think) and it works with this version of the interfaces https://reversing.pl/atari16bit/icdmste/icdmste.html.

[fdanapfel]

So far I have tested the firmware (modified 2024-04-03 I think) and it works with this version of the interfaces https://reversing.pl/atari16bit/icdmste/icdmste.html.

@Biker1bob Since the version of the BlueSCSIv2 firmware that was modified is quite old it would be helpful to test if the issue still occurs with the current version: https://github.com/BlueSCSI/BlueSCSI-v2/releases/tag/v2025.08.02

And maybe also check if the issue also occurs with other harddisk drivers, like AHDI or ICD Pro, to see if there is actually any relation to HDDRIVER or not.

[uweseimet]

@fdanapfel The current firmware has already been tested by one of my beta testers. I have already reported the results in detail below.
Let me assure you that HDDRIVER has no eyes. It can neither see whether BlueSCSI is connected, nor the cables and plugs. I do not plan any software upgrade that adds such a feature.

Edit: @fdanapfel I cannot resist to ask: Please tell me why you think that a driver would work differently when instead of a DB25 cable/connector a ribbon cable/connector is used, and everything else, including the BlueSCSI firmware is identical. What would it be that from the driver perspective is different?

[fdanapfel]

@uweseimet

@fdanapfel The current firmware has already been tested by one of my beta testers. I have already reported the results in detail below.

This is fully clear to me. The only reason why I suggested that @Biker1bob should test with the latest BlueSCSIv2 firmware was to determine if the patches that were put in the older version of the firmware he uses to make the BlueSCSIv2 work with the ACSI adapter he used would still be needed with the current version of the firmware or not.

Also the suggestion to check if the issue also occurs with other drivers was purely to verify that the issue is indeed just caused by a communication issue between the ACSI adapter used by @Biker1bob and the BlueSCSIv2.

I was not trying to suggest in any way that HDDRIVER might be at fault in any way here.

Let me assure you that HDDRIVER has no eyes. It can neither see whether BlueSCSI is connected, nor the cables and plugs. I do not plan any software upgrade that adds such a feature.

I never asked for such a feature.

Edit: @fdanapfel I cannot resist to ask: Please tell me why you think that a driver would work differently when instead of a DB25 cable/connector a ribbon cable/connector is used, and everything else, including the BlueSCSI firmware is identical. What would it be that from the driver perspective is different?

Sorry, I'm not sure why you are asking me this, because I've never mentioned anything about different cables/connectors?

[uweseimet]

I unsubscribed and am suddenly subscribed again. Anyway ...

Does it really need some smiley to make clear that the remark about HDDRIVER's eyes was not a serious one? YOU did not suggest a bug in HDDRIVER, but a support request I received with crazy and confusing information about which release was working and which was not, was.
Even if there was a bug in HDDRIVER, which is always possible, why would this differ with the desktop and the DB25 version? This just did not make sense, therefore my joke about eyes that would be needed to see which hardware is connected.

But fortunately there is now much more information on what's definitely working. Thank you @franklukas for testing and sharing your results. It just takes one successful test with a well-defined setup that shows that statements that say that the respective setup does not work are wrong. Looks as if some users may have to check their cables, termination, firmware versions etc., Not only on AtariAge and Facebook ;-).

[uweseimet]

This sounds as if the real ICD interfaces (the original ones, not the ones that were reverse-engineered) also require this patch? My tests clearly show (see screenshot) that this does not appear to be the case, at least not generally. Which original ICD interface did you test that requires a patch?

[Biker1bob]

This was reported by other users. There are many threads going back years. Blue SCSI v1 with the stm32 seemed to work for everyone.. then when the switch to the pico pi issues occured. I am a user Uwe, not a developer. I consider myself very skilled at hardware assembly and competent at schematic work, but design is beyond me. I built interfaces hoping to have one or two myself and pass others along to those who could not find originals. If I could have bought a link2 ICD I would never have embarked on this. James

…

On Thu, Aug 21, 2025, 2:24 p.m. Uwe Seimet ***@***.***> wrote: This sounds as if the real ICD interfaces (the original ones, not the ones that were reverse-engineered) also require this patch? My tests clearly show (see screenshot) that this does not appear to be the case. Which original interface did you test that also requires a patch? — Reply to this email directly, view it on GitHub <#282 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH4SP633M43WI6AWH7CMFFT3OYFG5AVCNFSM6AAAAACEO575VSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJYGE4TKNI> . You are receiving this because you commented.Message ID: ***@***.***>

[uweseimet]

How do you know that these reports were correct? There is more wrong information posted in Atari forums than valid information. IMO these users should join this discussion and provide information on the original ICD adapters that require a special handling.

In case you are wondering why I started a discussion in a project I am not involved with: It's because you contacted me and I spent quite some time on a non-existing issue, and because it may just be a matter of time until somebody will ask if SCSI2Pi has issues with ICD host adapters. (I am not aware of any.) I want to prevent that in a stage as early as possible.
Currently (and this also applies to the PiSCSI software) there are no configurable work-arounds at all. This is just not needed, because the SCSI specification is very precise. If you were adding a work-around for any reverse-engineered hardware or for any hardware somebody says is not working because somebody else said that yet somebody else said it (remember the telephone game), there would be more and more of useless options. And then users would start to exchange mystical recipes on how to combine these countless options to achieve something trivial ...

What I claim is this: The reverse-engineered host adapter is broken, and it does not behave like an original ICD host adapter. I may be wrong, but like with most technical problems that should be proven with a test, i.e. an original non-working host adapter, and with a reference to the part of the SCSI specification that is affected. Then it would be clear whether the problem is on the initiator or the target side.

By the way, others (like Inventronik) do not re-engineer something (let's face it, this is most likely not legal), but they design a new product. That's an achievement! Their host adapter is still available, including support.

Just my two cents.

[fdanapfel]

I think this is related to the following discussion from last year: #167 ( originally started as #166)

[Biker1bob]

Yes it is related to that. James

…

On Sun, Aug 24, 2025, 1:02 p.m. Frank Danapfel ***@***.***> wrote: I think this is related to the following discussion from last year: #167 <#167> ( originally started as #166 <#166>) — Reply to this email directly, view it on GitHub <#282 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH4SP66ABO7I4UVFPDTSIHL3PHVZPAVCNFSM6AAAAACEO575VSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRQGMYTKMI> . You are receiving this because you commented.Message ID: ***@***.***>

[uweseimet]

From feedback I received after spending way too much time with trying to help others with this issue, where my software does not play any role, the result is this: There are strong indications that whether an ICD adapter or a counterfeit adapter works or does not work appears to depend on the BlueSCSI hardware type: With the desktop version they do, with the DB25 version they don't.
Testing was done with both counterfeit adapters and with real ICD adapters, using exactly the same hardware/software/firmware setup. (Except for the cable connection, of course.)
This confirms that the general claim "ICD adapters do not work" is incorrect. That such a claims was made by others, without testing with a real ICD adapter like I did, but just with an illegally cloned one that was called "ICD adapter", is annoying IMO. This is not how serious testing works.

Whether there is an issue with BlueSCSI or the adapters or both I cannot tell. But since the BlueSCSI firmware is not aware of the BlueSCSI model (desktop or DB25) I am surprised that a firmware fix would be an adequate solution.

Edit: Looks as if BlueSCSI V1 did not have this issue. If this is true, it indicates an issue with V2 and not necessarily with the adapters.

Edit 2: I have asked my beta tester to join the discussion, but I do not know whether he will. I looked at his results again, and he also mentioned that the DB25 version works fine with the LINK96 and the Inventronik host adapters. The original ICD Advantage adapter and its counterfeit fellow do not work with the DB25 version. But all adapters mentioned work with the BlueSCSI desktop version.
From that perspective I might say: Get yourself an Inventronik adapter, which is original hardware which is still supported, and you are fine.

[Biker1bob]

It has been checked with a current unmodified version and the problem is still there. Thanks James

…

On Sun, Aug 24, 2025, 3:02 p.m. Frank Danapfel ***@***.***> wrote: So far I have tested the firmware (modified 2024-04-03 I think) and it works with this version of the interfaces https://reversing.pl/atari16bit/icdmste/icdmste.html. @Biker1bob <https://github.com/Biker1bob> Since the version of the BlueSCSIv2 firmware that was modified is quite old it would be helpful to test if the issue still occurs with the current version: https://github.com/BlueSCSI/BlueSCSI-v2/releases/tag/v2025.08.02 And maybe also check if the issue also occurs with other harddisk drivers, like AHDI or ICD Pro, to see if there is actually any relation to HDDRIVER or not. — Reply to this email directly, view it on GitHub <#282 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH4SP66SDVKJ3IJZIJXTIQL3PID3FAVCNFSM6AAAAACEO575VSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRQGM3TKOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[uweseimet]

@Biker1bob Was this with the BlueSCSI desktop or DB25 version?

[Biker1bob]

I personally put the most recent version of blue SCSI firmware on my desktop version (I also own db25) and it would not work with tOri micro ICD based megaste internal adaptor.

[uweseimet]

Does this mean that for you neither the desktop nor the DB25 version works? Did you terminate your desktop version?
(I do not really like that I am asking the questions the BlueSCSI team should ask. I am the idiot that gets blamed ...)

[Biker1bob]

I was not able to get a db25 version working or the desktop with a micro based (type of ICD interface) tOri interface.. I don't own an Advantage based interface, like the one you have tested with.

[uweseimet]

Did you terminate your desktop version?

[Biker1bob]

Yes it has always been terminated with the jumper.

[uweseimet]

Well, then there is not really new information I think. I hope my summary is correct:

1. The counterfeit micro version does not work, neither with BlueSCSI desktop nor DB25.
2. An original ICD micro version has not been tested, so there cannot be any verdict on it.
3. Both the counterfeit Advantage version and the original ICD Advantage version work with the desktop version.
4. Neither the counterfeit Advantage version nor the original ICD Advantage version work with the DB25 version.
5. The LINK96 and the Inventronik adapter work with both the desktop and the DB25 version.

[Biker1bob]

Not correct as on Atari forum right now there are reports of link96 not working. Link2 does. The original Atari interface for megaste does not. I have not personally been able to get it to work at all with bluescsi. Original micro have also been tested by several on Atari Age, Facebook and Atari forum and found not working. Can I attest that they all knew how to configure things correctly no.
In fact currently bluescsi wiki suggestions are for a special Atari ini setup. You pointed out a correct setup would be simple naming and no ini (worked for me best)

But I think we can conclude Uwe this is nothing to do with the driver software at all.

James

[uweseimet]

Can I attest that they all knew how to configure things correctly no.

If I had received just one cent for all users who claimed that everything was fine with their cables and termination and where it turned out that something was wrong. I would be richer than Elon Musk. Recently there was yet another case were everything also was reported to be fine. A bit later it turned out that a pin on a BlueSCSI board did not have any contact ...

One has to be careful with trusting statements like "termination and cables are all good" too much. If something is working as it should, like in my screenshot, the verdict is clear. If something is not working, things are more complicated. Regarding the LINK96, I have a screenshot from a beta tester that clearly shows that it is working, but I don't know whether it is with a MegaST or a MegaSTE. I have already asked the beta tester who sent me the screenshot to contribute to this discussion, but I don't know whether he will. The BlueSCSI team member that was working on a software fix also has not contributed anything. He would have known which part of the SCSI specification this fix was addressing, and how/if the BlueSCSI board type (desktop/DB25) plays any role. Knowing this might have helped.
If there are so many users with problems in forums etc., this is kind of good news, because they can all run tests that help finding out what's wrong. I would expect that at least some of them have already contacted the BlueSCSI team. If not, I suggest that you ask them to do it.

Anyway, just as you say, nothing indicates that driver software has to do with it. I will end my attempt to moderate this discussion and to shed some light on what's working and what's not working, and I will unsubscribe from the discussion. I prefer to spend time again on my own projects ;-). Of course, I hope there will be a resolution.

[franklukas]

I test well the BlueSCSI Desktop and the DSub25 Version all with the 8/2025 Firmware with the Inventronic, the LINK96/97 and a ICD Avantage Hostadapter on a Atari Mega ST4 Computer. The original ICD Avantage and the Copy from tOri works well.

[fdanapfel]

Just to make sure there is no confusion: by "Copy from tOri" you mean this one: https://reversing.pl/atari16bit/adscsi_mste/adscsi_mste.html ?

And not the one that @Biker1bob is using (https://reversing.pl/atari16bit/icdmste/icdmste.html)?

[viking272]

Last year, I tested my icd adscsi card from T0ri and it worked fine in my Mega STE, testing with 3 mechanical scsi devices that I have but failed with BlueSCSI v2. My view was the BlueSCSI firmware wasn't compatible with the limited commands on the card. BS also had a LUN/acsi workaround built in too where the bluescsi.ini file needs:
System="MegaSTE"

Sadly my Mega STE has a fault now so I can't use it to test the latest BlueSCSI firmware. Btw the BlueSCSI-v2 device worked fine in my Falcon.