🚀 go-pugleaf

dhoke wrote:

>(Thanks in advance...  Sorry if this seems off-topic to some, but it really 
>didn't seem non-technical in nature.)

Perhaps the TASM group?

>1)Please report if you spot an error in the BytesOK() routine.  Its intended 
>purposes is to scan the nbytes bytes starting at location pAddr, verifying 
>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.

>int BytesOK(unsigned char *pAddr, unsigned char bval, unsigned nbytes)
>{
>    unsigned ui ;
Warning: ui not used
>    _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.

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