🚀 go-pugleaf

Didn't follow your train of thought, comments below...

"Bob Gonder" <none@nowhere.invalid> wrote in message 
news:op3t7457p6inr75u4kkbfsr16r98gen5rm@4ax.com...
> dhoke wrote:
>
>>that all of those bytes have value bval.  It does not explicitly clear
>>direction flag, but CPU pane reports direction flag as clear (see further
>>below.)
>
> Well, there's an error to start:
> It Does clear the direction flag.

Which I wanted as that should cause EDI to be incremented, and looked for 
when I was searching for possible cause/error, but for some reason 
overlooked (I think I was looking in disassembly pane rather than source at 
time I checked, somehow missed fact that I had included it.)

>
>>int BytesOK(unsigned char *pAddr, unsigned char bval, unsigned nbytes)
>>{
>>    unsigned ui ;
> Warning: ui not used
yeah, that's for the conditionally compiled slower version I removed after 
inserting in the email.
>>    _asm
>>    {
>>         cld
>>         mov   al, bval
>>         mov   ecx, nbytes
>>         mov   edi, pAddr
>>         repe  scasb
>>         lahf
>>         //now, which bit is the zero/equal bit?
>>    } ;
>>    //if(_ECX)
>>    if(!(_EAX & 0x4000)) //0x40 set in AH
>>    {
>>         if(!MM3AdminData.survivalmode)
>>            if(MM3AdminData.callint3onerror) __asm int 3 ;
>>         return 1 ;
>>    }
>>    return 0 ;
>>}
>>pAddr == 0x044003e0
>>bval == 0xff
>>nbytes == 32
>>dump pane all bytes from 0x044003E0 through 0x044003FF as byte value 0xff
>
> I think you need to look a bit closer.
>
>>ECX == 0x7

>
> There were 7 bytes to go when it failed.


Yes - and the following 7 bytes were all bval (0xff)... as well as the 
preceding 25 or so...

>
>>EDI == 0x044003F9
>>pAddr == 0x044003e0
> 0x00000019 = 25
> pAddr[25] != bval
> might be [24], forget exactly how repe handles edi.
>

((char*)pVal + 25) == 0x44003f9
*((char*)pVal + 25) == 0xff  (all 32 bytes from 0x44003e0 through 0x44003ff, 
which includes 0x44003f9)

I'm not following your train of thought, as pVal[24] and pVal[25] as well as 
preceding and following bytes were all bval...

(I think) The routine should _not_ have tripped, calling the int 3, but it 
did - even though the circumstances presented by the debugger indicate to me 
it should not have...

>
>