English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   Coders. System (https://eab.abime.net/forumdisplay.php?f=113)
-   -   Open-source scsi device (https://eab.abime.net/showthread.php?t=67067)

_mandark_ 01 April 2013 14:58

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 02 April 2013 12:17

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 02 April 2013 18:04

Quote:

Originally Posted by NovaCoder (Post 879027)
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 02 April 2013 18:07

Quote:

Originally Posted by Don_Adan (Post 879070)
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 02 April 2013 22:42

Quote:

Originally Posted by Don_Adan (Post 879070)
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 07 April 2013 14:25

Quote:

Originally Posted by NovaCoder (Post 879117)
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_ 14 April 2013 01:20

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

Don_Adan 14 April 2013 19:47

Quote:

Originally Posted by _mandark_ (Post 881511)
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 14 April 2013 19:53

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 14 April 2013 20:27

Quote:

Originally Posted by tomse (Post 881663)
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 14 April 2013 21:29

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

_mandark_ 14 April 2013 21:45

Quote:

Originally Posted by Don_Adan (Post 881661)
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 15 April 2013 10:51

Quote:

Originally Posted by tomse (Post 881663)
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 15 April 2013 11:30

Quote:

Originally Posted by Don_Adan (Post 880037)
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 17 April 2013 18:56

Quote:

Originally Posted by Sandro (Post 881816)
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:

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 17 April 2013 19:00

Quote:

Originally Posted by tomse (Post 881698)
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.

Code:

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 17 April 2013 21:37

Quote:

Originally Posted by Don_Adan (Post 882239)
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.

Code:

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?

Quote:

Originally Posted by Don_Adan (Post 882239)
Too bad, time to learn assembler

I plan to some day when I find the time ;).

Sandro 21 April 2013 00:10

Quote:

Originally Posted by Don_Adan (Post 882237)
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:

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 21 April 2013 16:21

Quote:

Originally Posted by Sandro (Post 882970)
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 14 May 2013 18:22

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


All times are GMT +2. The time now is 08:28.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.08366 seconds with 11 queries