Reverse engineering of some ICD Link adapter

[wongck]

Thanks for the tech rundown. Very enlightening indeed.

[SofiST]

I moving gradually to new forum: http://forum.8bitchip.info/hardware-16/ ... d-timings/
First thread there is related tight with this one.
There are some other oldie sections too - Sinclair, Amiga, C64 . Join as fast you can, later will need to wait in line

[1024MAK]

I moving gradually to new forum: http://forum.8bitchip.info/hardware-16/ ... d-timings/
First thread there is related tight with this one.
There are some other oldie sections too - Sinclair, Amiga, C64 . Join as fast you can, later will need to wait in line

Well I have just joined, that now makes 7 members!

[3AtariSTE]

I moving gradually to new forum: http://forum.8bitchip.info/hardware-16/ ... d-timings/
First thread there is related tight with this one.
There are some other oldie sections too - Sinclair, Amiga, C64 . Join as fast you can, later will need to wait in line

Thx
I have just joined.

[wongck]

CATA ought to be a good solution rather than reverse engineer the LINK.
Looks like you are have most of it done.

[SofiST]

Yeah, finally achieved that CATA work well with STs . But it costed a lot of time and nerves, + almost killed STE and protoboard because of too much solderings, testings.
Just to say: basic concept of data transfer is same as in first test version (what ensures high speeds). But I reworked IF pretty much in last weeks: it has now almost perfect IDE timings, filtered out some glitches in signals + did some necessary changes in driver SW.

Considering CATA vs Link - actually not link, but AdSCSI ST adapter .
First is for IDE disks, so CF cards, classic PATA hard disks, CD/DVD ROM drives - still shops are full with PATA variants, not to mention a lot of lying around.
Second is for SCSI. At moment I'm not sure can some SCSI CD Writer work via AdSCSI ST - I did not see that someone says strictly that it works not. But I'm really not so much for writing CDs at all on ST machines.

For both stays: speed is top, what is achievable on regular ST(E) machines. And AdSCSI ST can more than Atari says for ACSI port max data rate.

http://atari.8bitchip.info/astide.php

[3AtariSTE]

Yeah, finally achieved that CATA work well with STs . But it costed a lot of time and nerves, + almost killed STE and protoboard because of too much solderings, testings.
Just to say: basic concept of data transfer is same as in first test version (what ensures high speeds). But I reworked IF pretty much in last weeks: it has now almost perfect IDE timings, filtered out some glitches in signals + did some necessary changes in driver SW.

Considering CATA vs Link - actually not link, but AdSCSI ST adapter .
First is for IDE disks, so CF cards, classic PATA hard disks, CD/DVD ROM drives - still shops are full with PATA variants, not to mention a lot of lying around.
Second is for SCSI. At moment I'm not sure can some SCSI CD Writer work via AdSCSI ST - I did not see that someone says strictly that it works not. But I'm really not so much for writing CDs at all on ST machines.

For both stays: speed is top, what is achievable on regular ST(E) machines. And AdSCSI ST can more than Atari says for ACSI port max data rate.

http://atari.8bitchip.info/astide.php

Good work SofiST.
Just to understand, i would know if CATA works with HDDRIVER (by Uwe) or it needs of a custom driver sw.
About CD burn ROM, unfortunately i can't help you (you know i am not an hw guru).
Anyway i will wait your final CATA project (i hope full woking)

[SofiST]

...
Just to understand, i would know if CATA works with HDDRIVER (by Uwe) or it needs of a custom driver sw.
About CD burn ROM, unfortunately i can't help you (you know i am not an hw guru).
Anyway i will wait your final CATA project (i hope full woking)

As on site stays, it needs "proprietary drivers" . In other words, someone must write special (custom) driver(s) for this special, non-standard IF (adapter). So, it will not work with Hddriver, AHDI , ICD etc.
I don't see it as some drawback - but that's me. If you can point here on some of features of Hddriver what can be useful for CATA driver, and are not present in my current drivers and announced plans I can implement them. But must say ahead, only what makes sense and has use. So, something like bus scan is out of question - because driver will support only one, specific IF, with support for 2 devices max. and all detection goes while driver loads into RAM.

Next step is making PCB and assembling units. 'Full working' (compatibility) should be very high. Everything what supports PIO3 mode must work. And such is practically everything IDE/ATA made in last 12-15 years. I spotted only one device which returned that no PIO3 mode support: no-name CF card of 128 MB (now over 5 years old), so almost worthless anyway.

[3AtariSTE]

Thanks for the info

...In other words, someone must write special (custom) driver(s) for this special, non-standard IF (adapter). So, it will not work with Hddriver, AHDI , ICD etc.

I think, Uwe could add CATA support in Hddriver , but this will depend on how many people will buy CATA adapter.
Anyway, is not a problem for me to use a custom driver for CATA...

Maurizio

[wongck]

Huh? Why need someone else to write the driver?
Ppera already has one that is working as can be seen on the 8bitchip site.
Looks like done and working to me... unless I missing something.

[SofiST]

Huh? Why need someone else to write the driver?
Ppera already has one that is working as can be seen on the 8bitchip site.
Looks like done and working to me... unless I missing something.

You are mostly right. Driver works well. However, it still needs some improvements. I observed that 2.5 inch Hitachi drive works not - and I know what it missing, so will add it ... Human just can not keep all those things in mind, especially not couple years after.
Plus, I'm doing some reworks in driver, for even better game compatibilty + solving settings via CFG file. All it goes slow.

[DrCoolZic]

Just discovered about this thread and it is quite interresting!

I have been chasing ICD adapters for over 4 years now. I first got one working but it is a very old version, limited to 1 GB and no parity support (and not working very well). Then I got a AdSSCI not working, then I got an AdSCSI Plus not working ...

Then recently I was lucky and got one AdSCSI Plus and one Advantage Plus boads both working and for a very very good price.
I have not yet done tooç much test on them but seems like both support over 1GB and have parity support.

I started two years ago reverse engineering on the AdSCSI and ADSCSI Plus boards. I almost completed (about 70%) the schematic, but unfortunately I had a crash on my PC and lost the schematic (still have a printout of the imcomplete schematic).
So I recently restarted recently to enter the schematic and I have about 30% done.
But I have been busy lately on other things... I might get back on finishing the schematic.

The board uses 5 PAL or GAL but it seems that ICD had many many different versions. My 4 boards look very similar but have small differences and the PAL seems to be differents: I tried to switch PAL from one board to another and some seems to be the same (can be interchange) but some seems different... You have to be very careful as the PAL are not marked!

If there is interest I can publish the partial schematics?
I still have plenty of SCSI drives from 500MB to 16GB and plenty of SCSI CD ROM and SCSI tape drives.
I have a working configuration with several drives and a CD ROM working like a charm. But I could not use the tape drive because I do not have a driver. But is it useful?
For info my first ICD board have a problem on the output and I could not make it work with Satan/UltarSatan I need to test with the new boards I bought.

[simbo]

all i can say is

has anyone approched the authors of the firmware
to ask for there co-op ???

i bet not one person has
and i can also guarantee if you track down these now old guys
youll find they will help 100%

[SofiST]

That's cool DrCoolZic : if you can finish schematic of AdSCSI Plus ST, then I can jump on getting PAL logics.

For now I know that my exemplar supports parity and of course handles over 1GB, CD ROMs. But it seems that ICD did not marked revisions (well). No any sticker on PAL chips

I'm pretty sure that there are different revisions, considering diverse speeds reported with similar drives. And that's usual.

Btw. I made this days test circuit to see how fast ST(E) DMA is really. It can perform 1-byte transfer in only 4 clocks, so in 500nS. It means that peak transfer rate is 2 MB/sec. So, what Jookie measured with Link is real (over 1700 KB/sec). And 'fast ACSI' option is Hddriver is for them.

SImbo: I tried to e-mail ICD stuff, but even e-mail address is dead

[simbo]

SImbo: I tried to e-mail ICD stuff, but even e-mail address is dead

my email is vsmlibs@talktalk.net

msn email is for msn you cant change it there i have over 2000 people on msn i dont want too loose

so.. stick to this email

im sure the guys who made the units will help

[SofiST]

My error: not stuff but ICD staff

[DrCoolZic]

My error: not stuff but ICD staff

I think it will be difficult to track down these people as the company has disapeared long time ago?

I finally found my old schematic. As I already mentioned it is incomplete and unfortunately I have lost the original file.
However even this incomplete version shows the different data paths and most of the control logic. Note that the schematic is from an Advantage ST board and not an Advantage Plus.

As I already mentionned I do not know what are the differences between the AdSCSI and the Advantage boards. They look very very similar and both of them have a "Plus" version that has a batery backup real time clock?

I have restarted the capture of the schematic but it is not currently on top of my priority...

[alexh]

My error: not stuff but ICD staff

I think it will be difficult to track down these people as the company has disapeared long time ago?

They were semi active about 5-6 years ago when they got all nostalgic. Sent me some technical data on the Amiga Trifecta SCSI controller. But they continue to pay their hosting fees & Domain name fees.

http://www.icd.com/

But as Pera said, their email doesn't work.

[DrCoolZic]

http://www.icd.com/

But as Pera said, their email doesn't work.

Info http://www.allbusiness.com/companyprofi ... F2E-1.html
http://www.icd.com/index/about.htm

I have sent an email using sales@icd.com; support@icd.com; webmaster@icd.com; feedback@icd.com
3 of them where rejected but sales@icd.com did pass trough.
Now waiting to see if someone reply.
_______________________________________________________________________________________
The mail system

<feedback@icd.com>: host post.rockriver.net[209.94.48.11] said: 556 5.7.1
<feedback@icd.com>: Recipient address rejected: Unknown user
feedback@icd.com (in reply to RCPT TO command)

<support@icd.com>: host post.rockriver.net[209.94.48.11] said: 556 5.7.1
<support@icd.com>: Recipient address rejected: Unknown user support@icd.com
(in reply to RCPT TO command)

<webmaster@icd.com>: host post.rockriver.net[209.94.48.11] said: 556 5.7.1
<webmaster@icd.com>: Recipient address rejected: Unknown user
webmaster@icd.com (in reply to RCPT TO command)

[DrCoolZic]

http://www.icd.com/

But as Pera said, their email doesn't work.

Info http://www.allbusiness.com/companyprofi ... F2E-1.html
http://www.icd.com/index/about.htm

I have sent an email using sales@icd.com; support@icd.com; webmaster@icd.com; feedback@icd.com
3 of them where rejected but sales@icd.com did pass trough.
Now waiting to see if someone reply.

Also maybe someone in US can give a call or sent a Fax?
_______________________________________________________________________________________
The mail system

<feedback@icd.com>: host post.rockriver.net[209.94.48.11] said: 556 5.7.1
<feedback@icd.com>: Recipient address rejected: Unknown user
feedback@icd.com (in reply to RCPT TO command)

<support@icd.com>: host post.rockriver.net[209.94.48.11] said: 556 5.7.1
<support@icd.com>: Recipient address rejected: Unknown user support@icd.com
(in reply to RCPT TO command)

<webmaster@icd.com>: host post.rockriver.net[209.94.48.11] said: 556 5.7.1
<webmaster@icd.com>: Recipient address rejected: Unknown user
webmaster@icd.com (in reply to RCPT TO command)

[SofiST]

...
I finally found my old schematic. As I already mentioned it is incomplete and unfortunately I have lost the original file.
However even this incomplete version shows the different data paths and most of the control logic. Note that the schematic is from an Advantage ST board and not an Advantage Plus..

Can we get Eagle SCH file instead pic ? It will make updates easier

[DrCoolZic]

Preferrably ICD Link II
It was proposed here couple times, among others by Ijor - to make a rev. enineering . I think that it is real, not easy, but also not extremely hard. Problem is, as may know that GAL chips are protected from reading out internal logic. But it can be get by examining behaviour. Knowing where pins are connected we can deduct their functions, and then may get slowly internal logic, by well concepted tests- Myself did couple times such examinations, although with simpler circuits, containing GALs or PALs.

I have also proposed many times that someone starts a SCSI adapter project (specially to Jookie)! But he was right in saying that there is small interest and therefore that it would not sell in large quantities. However that does not mean it is not interesting!

As far as reverse engineering: Yes ICD is a good starting point but however ICD link II is probably not the easiest one to study as it uses almost only one IC! AdSCSI is probably a better choice as it allows to see easily the data paths and the control logic. Note that it uses an architecture very similar to the adapters used in the Atari Megafile series of hard disk. This architecture allows to daisy chain the ASCI peripherals (i.e. HD and printer) which in turn implies to use bidirectional drivers on the bus. Where the Link II and equivalent adapters only allow one ASCII device (but of course many SCSI devices).

On the other hand the Satan/UltraSatan uses the ASCII bus in a different (but obviously working) way: they use the ASCI data bus as a tri-state bus. However the bus has not really been design for that initially so it implies that in order to use the Satan/UltraSatan devices with standard ASCI peripheral you needs to connect them on the output connector of the last ASCI device.

So what are we trying to design here?
Do we still have a lot of people using Megafile or laser printer on the ASCI bus?
Probably not!
So I guess that the UltraSatan approach/architecture is the best (I do not remember now but I think there was something incorrectly implemented on the way the Satan is connected to the ASCI bus). This still allow to use other ASCI prepherals as long as yo place the SCSI adapter as described before.

if you look at the incomplete schematic of the ICD I have posted the structure/architecture is easy to follow: we have bidirectional buffer used for daisy chaining the buses and we have buffer/latch between the ASCI bus and the SCSI bus. It is also interesting to note that the three upper bit of the ASCI bus are handled by the PAL/GAL. Here again reason is obvious: I will not go into detail but on the ASCI bus the device addressed is specified in the 3 upper bits where this not the case not on the SCSI bus. So we have some logic to decode the device accessed on the ASCI bus and this need to be filtered on the SCSI bus. Other feature implemented on the ICD adapter is the ICD extended command capability. Again without going into details this is recognized by sending the command 1F (+device number) and again this needs to decoded and filtered by the adapter.

One very important note is that the ICD is an ADAPTER and not a CONTROLLER. So the adapter is just used to adjust the differences between ASCI and SCSI protocols. Another very important point is that contrary to the SCSI bus the ASCI bus does not a support master/slave devices. What does that means? On the ASCI bus a peripheral can never request to take control of the bus spontaneously (i.e. only the Atari DMA request information from the device). In turn that means that a SCSI device can never request control of the bus. In turn this means that there is no need to implement SCSI bus arbitration (contrary to what I have seen on this thread) and that also simplified a lot the adapter logic. So the SCSI adapter control logic is in fact relatively simple: it has to take care of the ASCI control signals, decode the device address, filter the three upper bits, and take care of the simple SCSI control signals (e.g. parity...).

Therefore if we want to design an ASCI to SCSI adapter the best solution is to start from the UltraSatan device (this is why I asked Jokkie many times). We already have all the control of the ASCI bus, decode logic, ICD extended decode etc. The only thing that needs to be done is an adaptation to the SCSI bus instead of accessing an SD card and this should be fairly easy (remember that there is no need for arbitration). To help we can also use the logic circuit provided by Atari on an ASCI to SCI adapter.

I must admit that now that I have succeeded to buy 2 SCSI adapters I am less interested in this project. However even if no practical realization is proposed for sell, it would be good to have a description so that someone can build the adapter for himself.

[wongck]

I have also proposed many times that someone starts a SCSI adapter project (specially to Jookie)! But he was right in saying that there is small interest and therefore that it would not sell in large quantities. However that does not mean it is not interesting!

Hey then this is a project driven by "just for kicks" rather than $$$.
Great stuff.... keep on going man!!

[simbo]

now we are all back to
adding a second dma channel
via cart and asci port combo or we are back to adding some sort of extra portage and added signals
i myself and ppera said years ago {7 now}
perhaps and i know i am happy with sdcards for st and falcon
the TT i will eventualy flash in the newer block
once i see its ok and once i fix my TT
i dont see the point in adding more than this
other than a bank of 4Mb flash eeproms as im building myself slowly
schematic is 70% finished dma and cart for data and address access past the dma can
and cold boot menu update
games loaded at 10Mb per sec sound better as i need only say 8X 4Mb chips 29F040
to hold 8 games and disks images...
i still think you can reach these guys and save some time

there is far better than a new scsi support
a whole new approch is needed

some pc tools to handle sdcards that are atari format is needed
as generics and handled direct by windows etc as image's
as i think file tables and direct read and write are a bad idea
a custom ide not a use this and that approch
...

[SofiST]

Original idea was to hit 2 flies at once: getting PAL logics, so can repair now very old ICD adapters. + making replicas.
Now we are smarter, for sure. I think at moment that doing AdSCSI ST replica now is not the best idea. It is not so fast as could be - at least not my exemplar. It is possible to do faster ACSI-SCSI adapter with some GALs or with CPLD. But question is, is it now interesting in era of Flash cards ?

I don't see the reason for second DMA channel. Now, knowing Atari ST DMA real speed, I feel more respect for (see in other thread, near) .

I agree that no need for full SCSI implémentation - considering arbitration. No real advantage

DrCoolZic: I think that you are wrong considering usage of 3-state by ICD. It is elementary if want that your device/design work together with some other on ACSI bus. Data lines of inactive device must be in high-Z state. And regular bidirectional drivers all have that state. The problems (device conflicts) appear usually with IDs. If IDs are not problem, then inperfect signal decodings, noise, short glitches are culprits. Or overloaded bus/lines.

All it is matter of investment/price - considering time spent in development/testings + money invested + final price of device. There is people who wants only solo device, cheap, and others, who want to connect more at once (usualy who already own something). It is not possible to satisfy all them, I think. Also, doing 2-3 versions of same basic device for different target users is not economical way.