Open-source scsi device

[_mandark_]

Results for my A1200 68030 ACA1231-42Mhz (measured with SysSpeed 4.0):

scsi.device 43.45 2.488 KB/s
32 bit transfer (v1) 2.808 KB/s
32 bit transfer (v2) 2.818 KB/s

[NovaCoder]

Just gave it a go, both v1 and v2 give me the same result.

Specs: A1200 + IdeFixExpress + SD HD Module + Blizzard 1260 @ 80Mhz

4,092 KB/s according to SysInfo (faster than it was using SpeedyIDE), well done!

[Don_Adan]

Originally Posted by NovaCoder

Just gave it a go, both v1 and v2 give me the same result.

Specs: A1200 + IdeFixExpress + SD HD Module + Blizzard 1260 @ 80Mhz

4,092 KB/s according to SysInfo (faster than it was using SpeedyIDE), well done!

Thanks for info. Interesting how your config break PI0-0 limit (3.3 MB/s). This is done via special hardware or any software solution? If this is software then perhaps can be added to scsi.device.
BTW. Which result you have for 16 bit transfer (latest version)?

[alexh]

Originally Posted by Don_Adan

This is done via special hardware?

He's got an IDE-Fix Express which I *think* turns an A1200 Gayle IDE into a PIO-1 capable port.

[NovaCoder]

Originally Posted by Don_Adan

Thanks for info. Interesting how your config break PI0-0 limit (3.3 MB/s). This is done via special hardware or any software solution? If this is software then perhaps can be added to scsi.device.
BTW. Which result you have for 16 bit transfer (latest version)?

Yep an IdeFixExpress gives it more speed (I don't know how it works though).

Latest version from here seems to be slightly slower on my setup.

[Don_Adan]

Originally Posted by NovaCoder

Yep an IdeFixExpress gives it more speed (I don't know how it works though).

Latest version from here seems to be slightly slower on my setup.

It was 16-bit version only.
Next version is available on the WT page. Both (16bit and 32bit) transfer modes are supported and used, dependent to detected HD. This version can be a few slower than 16 bit or 32 bit due extra recognition is added/used.

[_mandark_]

New unified version is working good! And hardly slower (2.808 KB/s) than the previous 32bit versions.

[Don_Adan]

Originally Posted by _mandark_

New unified version is working good! And hardly slower (2.808 KB/s) than the previous 32bit versions.

Thanks for tests. Do you know which atapi drives works with this scsi device version? Atapi support code also used only 16bit transfer, perhaps some Atapi drives also works in 32bit mode. I don't have Atapi drives to check Atapi support code.

[tomse]

how do these work with the pio2 ide chips on the A4000
and are some of the fixes from piru/cosmos added ?

tbh I'm somewhat confused which versions to use now that there are quite a few
to choose from.

good work though :-)

[Don_Adan]

Originally Posted by tomse

how do these work with the pio2 ide chips on the A4000
and are some of the fixes from piru/cosmos added ?

tbh I'm somewhat confused which versions to use now that there are quite a few
to choose from.

good work though :-)

I don't have PIO2 chips installed in my A4000, but this version must works too, I think.
I changed only the scsi code which I understand "as is", I don't use direct fixes from other people (except Chris Hodges fix). Anyway if you think that something is missing, you can check the source and tell me what is missing or can/must be fixed. For me Cosmos version has some bugs, I don't checked Piru fixes (except 32bit transfer).
For now latest version is available on the Wanted Team page, you can always check the scsi.device date (at end of code or source). The 32bit version was test version only.

[tomse]

I can't code assembler, so unfortunately I have no idea what is missing or not :-)

[_mandark_]

Originally Posted by Don_Adan

Thanks for tests. Do you know which atapi drives works with this scsi device version? Atapi support code also used only 16bit transfer, perhaps some Atapi drives also works in 32bit mode. I don't have Atapi drives to check Atapi support code.

Unfortunately I cannot test this. Only got internal CF-Cards on my two A1200 and a PCMCIA CF-Card for data transfer.

[hooverphonique]

Originally Posted by tomse

how do these work with the pio2 ide chips on the A4000
and are some of the fixes from piru/cosmos added ?

tbh I'm somewhat confused which versions to use now that there are quite a few
to choose from.

good work though :-)

as far as I know, the PIO2 mod only changes some waitstates in the hardware interface from PIO0 to PIO2 - it shouldn't require software changes..

what do the mentioned fixes do/fix?

[Sandro]

Originally Posted by Don_Adan

It was 16-bit version only.
Next version is available on the WT page. Both (16bit and 32bit) transfer modes are supported and used, dependent to detected HD. This version can be a few slower than 16 bit or 32 bit due extra recognition is added/used.

I tested the devices and works faster compared to v39
2.4mb/s vs 2.7mb/s

btw,

there is a delay of 2 or 3 seconds in every reboot
can you make a scsi.device without those seconds of delay?
or
can you make a prefs program like the one that comes with idefix97 where you can select how many seconds of delay or not delay at all

thanks

[Don_Adan]

Originally Posted by Sandro

I tested the devices and works faster compared to v39
2.4mb/s vs 2.7mb/s

btw,

there is a delay of 2 or 3 seconds in every reboot
can you make a scsi.device without those seconds of delay?
or
can you make a prefs program like the one that comes with idefix97 where you can select how many seconds of delay or not delay at all

thanks

I'm not expert, but different HD's has different boot time. Perhaps if boot time will be shortest, not all HD's (especially older) will be works. For now I don't want to change this, anyway you can change this code:

TimerWaitLong
    moveq    #0,D0
    move.l    #$3D090,D1
    bra.b    TimerWait

And change $3d090 to shortest value. Perhaps it can speed up boot time for yours config.

[Don_Adan]

Originally Posted by tomse

I can't code assembler, so unfortunately I have no idea what is missing or not :-)

Too bad, time to learn assembler
Here is one bug in original scsi device code, present I don't know how I can fix this bug in clean way.

lbC002024    LEA    $38(A5),A0
    MOVEA.L    (A0),A1
    MOVE.L    (A1),D0
    BEQ.S    lbC002036        ; bug or not?
    MOVE.L    D0,(A0)
    EXG    D0,A1
    MOVE.L    A0,4(A1)
lbC002036    MOVEA.L    D0,A2        ; due here is set zero address too
    LEA    -$44(A2),A2
    MOVE.L    A2,$28(A5)
    MOVE.B    #3,$5C(A2)        ; and here zero page memory is trashed
    MOVE.B    #4,$5D(A2)        ; and here ...
    LEA    $4C(A2),A0
    MOVEA.L    (A0),A1
    MOVE.L    (A1),D0
    BEQ.S    lbC00205E                             ; seems to be second bug here
    MOVE.L    D0,(A0)
    EXG    D0,A1
    MOVE.L    A0,4(A1)
lbC00205E    MOVE.L    D0,$58(A2)
    MOVEA.L    D0,A3
    MOVEA.L    $18(A3),A1                     ; here is read from zero page, if D0=0
    MOVE.L    A1,$6C(A3)                        ; here is write to zero page
    MOVE.L    (A1),$60(A3)
    MOVE.L    12(A1),$64(A3)
    CLR.L    8(A1)
    CLR.W    $12(A1)
    LEA    $15(A1),A1
    MOVE.L    A1,$68(A3)
    RTS

[matthey]

Originally Posted by Don_Adan

Here is one bug in original scsi device code, present I don't know how I can fix this bug in clean way.

They are not necessarily bugs if both lists are never empty (these 2 lists must always have at least 1 node or memory is trashed). It looks like the programmer should have used the REMHEADQ macro instead of REMHEAD macro. The A3 register is available as a scratch register for REMHEADQ. See includes:exec/lists.i for the macro definitions. As long as you never see any Enforcer/MuForce hits from this, you could convert the 2 REMHEAD macros to REMHEADQ using the A3 scratch register as REMHEADQ is more optimal. About the only other choice is to change both branches to the rts at the bottom but that is no guarantee there won't be further problems.

lbC002024    LEA    $38(A5),A0   ;1st list
    MOVEA.L    (A0),A1   ;REMHEAD MACRO start
    MOVE.L    (A1),D0
    BEQ.S    lbC002036        ; bug or not?
    MOVE.L    D0,(A0)
    EXG    D0,A1
    MOVE.L    A0,4(A1)   ;REMHEAD MACRO end
lbC002036    MOVEA.L    D0,A2        ; due here is set zero address too
    LEA    -$44(A2),A2
    MOVE.L    A2,$28(A5)
    MOVE.B    #3,$5C(A2)        ; and here zero page memory is trashed
    MOVE.B    #4,$5D(A2)        ; and here ...
    LEA    $4C(A2),A0   ;2nd list
    MOVEA.L    (A0),A1   ;REMHEAD MACRO start
    MOVE.L    (A1),D0
    BEQ.S    lbC00205E                             ; seems to be second bug here
    MOVE.L    D0,(A0)
    EXG    D0,A1
    MOVE.L    A0,4(A1)   ;REMHEAD MACRO end
lbC00205E    MOVE.L    D0,$58(A2)
    MOVEA.L    D0,A3   ;A3 is free for REMHEADQ above because it's destroyed here
    MOVEA.L    $18(A3),A1                     ; here is read from zero page, if D0=0
    MOVE.L    A1,$6C(A3)                        ; here is write to zero page
    MOVE.L    (A1),$60(A3)
    MOVE.L    12(A1),$64(A3)
    CLR.L    8(A1)
    CLR.W    $12(A1)
    LEA    $15(A1),A1   ;*** suspicious ***
    MOVE.L    A1,$68(A3)
    RTS

I marked some suspicious code from above for you too. It would be nice to know if ($15,A1) is pointing to a string? This odd address is probably not optimal in any case and could lead to a crash on the 68000 if used later for memory accesses other than byte size. If you set a breakpoint at the top in a debugger, is this code ever executed?

Originally Posted by Don_Adan

Too bad, time to learn assembler

I plan to some day when I find the time .

[Sandro]

Originally Posted by Don_Adan

I'm not expert, but different HD's has different boot time. Perhaps if boot time will be shortest, not all HD's (especially older) will be works. For now I don't want to change this, anyway you can change this code:

TimerWaitLong
    moveq    #0,D0
    move.l    #$3D090,D1
    bra.b    TimerWait

And change $3d090 to shortest value. Perhaps it can speed up boot time for yours config.

thanks for the reply master!!!
but I'm not a coder and I don't how to change that
can you compile a special device for me for my A1200 with 0 seconds of delay?

[Don_Adan]

Originally Posted by Sandro

thanks for the reply master!!!
but I'm not a coder and I don't how to change that
can you compile a special device for me for my A1200 with 0 seconds of delay?

You can use any binary file editor, f.e. FileMaster 2.2. Find $0003D090 value inside scsi.device and replace (write) new lower value f.e. $00010000 and check effects, if it works (shortest boot time on your Amiga config), you can change this value to new lower value f.e. $00008000, etc. After some attempts, perhaps you can set/choose correct value for the shortest boot time.

[Don_Adan]

Next version is avalable. Inquiry and DoSCSICommand routines are reworked.