Need advice: A2000 SCSI solution

[Toni.Wilen]

Great!

Odd ROM corruption mystery still remains.. It can't be a coincidence that both ROMs have same problem, two first bytes cleared. Unless they were originally factory programmed with broken programmer (I guess original chips were OTP EPROMs?).

 

[Morkath]

They are EPROMs, not OTPs, and I guess that was the case with all Golem Kupke cards for the A2000.
I also suspect that both chips were programmed with a faulty programmer, because the chips themselves are working perfectly.
After reprogramming them with the 3.9 image, autoboot capability started to work instantly.

http://amiga.resource.cx/photos/photo2.pl?id=golemscsi2000&pg=1&res=hi&lang=en

In this picture there are hand written texts on the stickers, but my ROMs were covered with "official", printed stickers, with the texts "HI v3.8" and "LO v3.8" respectively.
I cannot take a picture of them unfortunately, because they were in very bad shape and since I had to remove them to erase the chips, I threw them out afterwards.

Further progress: I could successfully add a CD-ROM to the SCSI chain too, after disabling parity and setting termination properly.
It couldn't detect disk changes at all first, but then enabling "Direct SCSI" in CacheCDFS solved that problem.
This is very helpful, because once the system works properly, I won't have to disassemble the Amiga in order to transfer data to the HDD via WinUAE.

I have some experience with the A1200 internal IDE + IdeFIX97 + PFS3 combination, which always works flawlessly for me.

However, IdeFix replaces scsi.device AFAIK, and leaves my scsi3.device intact. So even after reading tons of documentation about
the various limits of the components, I'm not sure what the optimal setup in my case would be. I intend to create an 500MB boot partition (any filesytem would do),
and a 7500MB PFS3 one for all the stuff. (In the meantime I replaced th 4GB HDD with a quieter 8GB one). But even if in the end turns out that I'm limited to less HDD space
either because of scsi3.device or the DirectSCSI protocol, that would be o.k. by me.

I guess examining how scsi3.device works, or patching it for large HDD support is out of the question.

But even in that case, I'm fine even with 2GB of storage capacity, but I would like to avoid any scenario where data corruption could possibly occur due to disobeying specific limits.

I forgot to mention that the working card proves that all three PAL contents are good, too.
(The numbering of the images I sent to you isn't necessarily correct, however.)

 

[Toni.Wilen]

All true SCSI controllers should not have any size limits as long as HD_SCSICMD (direct scsi) is used by the filesystem. Only possible size related problem is driver crashing/hanging during boot when it tries to detect the HD and getting confused with "too large" size. Another possible problem is driver not supporting any custom filesystems, this is unfortunately quite common problem.

 

[Morkath]

Thanks for clearing that up.

The setup works, but produces random Read / Write Block errors every once in a while.
Strange thing is: if I press Retry, it can always read and write the specific block at the second try - no problem.
All this with a single 500 MB FFS partition. The hard disk is in perfect condition.

I'm not sure if it's a timing problem of some sort or the controller itself is defective.
But I guess in the latter case I could not prepare the HDD, format is, install WB on it in the first place.