Open-source scsi device
 

I started to optimise/rework scsi device.
Three versions are available: for A600 (ROM 3.0+), for A1200 and for A4000 on:

http://wt.exotica.org.uk/test.html

At begining reworked are Init (partially) and ReadWriteData routines
New version is a few fastest, especially for slower CPU's. Also perhaps
one original bug is fixed for ReadWriteData routine error handling.

:O
Awesome!!!

Nice to have a new scsi.device mate /kudos.

Whoah, this is REALLY nice!!

yay finaly we might get the 1 scsi.device that dos everything, and of course dose it brilantly :great

Next version is available, I optimised a few ReadWriteData routine.

Next version is available. Trashed register for A1200/A4000 versions is fixed (my bug).

Tried out incorporating your scsi.device into my custom ROM, but my A1200 refuses to boot then. The ROM gets kicked via ACAtune but then my A1200 freezes.

Can it be due to this patch is missing: SCSI4345p.readme ?

My A1200 setup with 4 GB CF-Card and 2 PFS3 partitions only boots with scsidev 43.45 or Cosmos 43.47.

It could be that you need to repartition drive with this new scsi.device or older v43.43. I have the same issues with A1200&A4000D.
To verify, check if problem exists with scsi.device 43.43 from OS3.9 (or 3.9 BB1, not sure).


EDIT: I checked - I use 43.45 so same as yours. But anyway, some versions (ie. the 44.2) refuse to work for me so try some different versions, also try another drive and partition it with new scsidev.

I will later try this new scsi from Don_Adan and tell you how it works for me.

Hi Don,

That's some Awesome work you have done on the IDE versions of scsi.device! :great Do you think you could help improve one of the real versions of scsi.device?

http://eab.abime.net/showthread.php?t=67144

Next version is available, one my bug fixed, more routines reworked, can be a few fastest.

Please check next version, I fixed one my bug. This is a few different version than others, but I think that all necessary fixes are already added, also MaxTransfer problem is perhaps (I don't have HD to tests this) solved too, then every MaxTransfer value can be used, and perhaps over 128GB HD can be used too (again I don't have this HD for tests).

Yes, perhaps I can, but I can't test this version directly. I will resource ROM from the zone soon and later necessary changes can be done.

Thanks Don! :)

I did upload the complete A2091 16KB binary to the Zone. I've done a raw dis-assembly of this binary but I have a few problems. The disassembler does not seem know the difference between real 68K code and data structures and I don't know enough about AmigaOS code and data structures to separate them yet.

But I'll post some more technical info on the A2091 thread and I can test any modified versions myself.

Thanks! This version is running fine now on my A1200 and on WinUAE.

However at the moment it is a little bit slower than Cosmos v43.47, 2320 KB/s vs. 2530 KB/s on my CF-Card.

Here is resourced and exe version. This is scsi.device v37.64.
Your binary version is wrong, you splitted both ROM files in wrong rotation. Now you can make fixes/changes inside source. After assembling, you must remove/cut first 32 bytes and last 4 bytes from exe version to receive binary version. Later perhaps you must split binary file on two ROM parts. Remember this ROM file is fully PC relative (except module structure part), then don't use non PC relative code for your changes.

I don't remove/change wait code for now, maybe later it can be changed too. Which speed value occured for v43.45 on your setup?

Thanks very much Don! :)

The version I posted in the Zone was a ROM Ripped version due to lack of any Amiga software I could find to merge the even/odd binary's previously posted here on EAB. A modified and reassembled binary would have to be split into even/odd for ROM programming. PC relative is absolutely required since the A2091 ROMs can be Auto-Configed in any 64KB block of Zorro2 I/O space.

Awesome, can't wait to try this :)

Hi Don,

Here are some hardware design considerations for code optimizing the IDE versions of scsi.device:

- 68020/68030 internally handle dynamic bus sizing more efficiently than most 040/060 CPU cards. This is one reason (but not the only one) why word transfers seem to give better performance with 040/060.

- The A4000 state machine logic terminates the cycle on the CPU side of the bus approx. 5 clocks before the IDE side of the bus terminates it's cycle. The idea is to free the CPU to perform some other task while waiting for the IDE bus cycle to complete. This is more friendly to the OS in terms of CPU usage but if the CPU commits to a longer bus cycle due to a slower task or accessing a slower port it can delay the start of the next IDE bus cycle (resulting in a slower transfer rate).

- The 040/060 have larger internal caches and improved instruction execution pipelines so they are more likely to complete tasks and be ready to begin the next cycle on the IDE bus (but they can still be delayed by accessing a slower external port) and another reason why word transfers may be seem give a better performance with 040/060.

As you can see there are performance trade offs with word vs. longword transfers and CPU usage vs. IDE max. transfer rate. I hope this can be of some help to you. :)

My friend/tester reached over 3MB/s on A4000 CS 68060 80MHz, when maximum for PIO-0 is perhaps 3.3 MB/s. I don't know if A4000 IDE controller can works in PIO-2 or PIO-4 mode for reach better speed.