Re: [hatari-devel] bugreport: ACSI-diskimage access - bogus/bouncing command byte

[Martin van der Koelen <vanderkoelen@xxxxxxxxxxx>]

Hi Nicolas,

thank you for fast response!

I do attach the diff-output here and a more detailed problem description.

Martin





Am 17.07.20 um 17:11 schrieb Nicolas Pomarède:
> Le 17/07/2020 à 17:06, Martin van der Koelen a écrit :
>> Hi all,
>>
>> as this is my first experience in mailing-list communication I do
>> apologize for potential inapropriate behaviour.
>>
>> Problem:
>> I could not access an ACSI diskimage, and tracing the ACSI-communication
>> I found a bogus byte in the command block.
>>
>> A slight correction in "hdc.c" fixed the problem (in my environment) and
>> since then diskimage mounts perfectly.
>>
>> I would like to provide the modified "hdc.c", and a more detailed
>> explanation, but I don't know, if it is possible to attach it to the
>> mail ???
> 
> Hi and welcome to the mailing list.
> 
> patches are always welcome :)
> 
> you can attach your modification to the mail, it will be visible.
> 
> but in that case don't send the full hdc.c, please use a "diff" between
> your version and the current hatari's version
> 
> Nicolas



28a29
> #define FIX_BYTECOUNT_BUG	1	// 2020-07-17 Martin van der Koelen
962a964,968
>     // vdk: 2020-07-15:
>     // encountered bogus/superfluous command byte, but A1 still 1
>     // -> so reset byteCount only if A1 is cleared to 0 (not here!) and
>     // drain the garbage ...
> 
963a970,973
>    #if FIX_BYTECOUNT_BUG
> 	if ((ctr->byteCount == 6  &&  ctr->opcode <  0x20) ||
> 	    (ctr->byteCount == 10 &&  ctr->opcode >= 0x20 && ctr->opcode < 0x60))
>    #else    // original:
965a976
>    #endif
990,991c1001,1006
< 
< 		ctr->byteCount = 0;
---
>    #if FIX_BYTECOUNT_BUG
> 	  // Dont reset byteCount here!
> 	  // => only in Acsi_WriteCommandByte() if A1 is set to zero
>    #else
> 	ctr->byteCount = 0;
>    #endif

Martin van der Koelen,  2020-07-16
vanderkoelen@xxxxxxxxxxx
===========================================================================
Host:       Linux, OpenSuse leap 15.1, kernel: 4.12.14-lp151.28.52-default
            x86-64, 4 cores

gcc:        v 7.5.0 (SUSE Linux)


Acsi-Diskimage: 
-----------------------------------------------------------
MBR:        Original Atari partitioning
            4 partitions 
            Bootsector 1.partition = #2
HD driver:  HuSHI-Junior, v 2.16
            H.D. Jankowski & J.F. Reschke (c) 1989-1991
            (in bootsector of first partition)
-----------------------------------------------------------

hatari:     v 2.2.1
emulation:  Atari 1040 ST, memory: 4MB 
TOS:        1.04


file:       hdc.c
function:   HDC_WriteCommandByte() / Acsi_WriteCommandByte()

problem:    Function 'HDC_WriteCommandByte()' is called twice 
            for the same byte, so the command bytes inside 
            the following command-blocks are wrongly shifted by one.

            ==> Diskimage inaccessible.

            Without further investigation I suspect a bouncing,
            bogus (emulation-) interrupt that may be encountered only by
            multi-core host systems and therefore was not noticed
            before. 

bugfix:     Reset the byte index/counter only, if A1 is pulled to zero


To trace the problem I inserted a 'printf()'  in the beginning of 
Acsi_WriteCommandByte() ...
      fprintf(stderr," Acsi_WriteCommandByte : %02X addr: $%X   byteCount: %d     target: %d\n",
                                        byte, addr, AcsiBus.byteCount, AcsiBus.target);
.... and catched the output.

    #
    #  First Command (6 Bytes: "read sector 0") was transmitted
    #  correctly and the MBR was delivered by DMA-transfer as expected
    #

 Acsi_WriteCommandByte : 08 addr: $0   byteCount: 0     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 1     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 2     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 3     target: 0
 Acsi_WriteCommandByte : 01 addr: $2   byteCount: 4     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 5     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 0     target: 0

    # After receiving 6 bytes, counter was erroneously resetted
    # to zero though 7th byte was a bogus repetition of previous.
    # See: addr (=A1 wire) still is 2 and not 0.
    # So all following command bytes are wrong indexed.
    #  => my recommendation: reset counter only if addr == 0

    # following command(='READ') in fact starts here: 
    #       target        = 0
    #       lun(device)   = 0
    #       startblock    = 2
    #       no. of blocks = 1
    #  ... but is not transferred correctly, for bad order/counter.

 Acsi_WriteCommandByte : 08 addr: $0   byteCount: 1     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 2     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 3     target: 0
 Acsi_WriteCommandByte : 02 addr: $2   byteCount: 4     target: 0
 Acsi_WriteCommandByte : 01 addr: $2   byteCount: 5     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 0     target: 0

 -------- de facto command boundary ------------

 Acsi_WriteCommandByte : 28 addr: $0   byteCount: 1     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 2     target: 0
 Acsi_WriteCommandByte : 00 addr: $2   byteCount: 3     target: 0

    ....