🚀 go-pugleaf

And it just occurred to me that 0xcc is an int 3 instruction...

And further occurred to me to check my breakpoints.  Sure enough, I have an 
address breakpoint set with that value (two of them it seems.)

So I guess it's my fault after all, not bds2006.

"dhoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:488047c1$1@newsgroups.borland.com...
> This issue is partially resolved.  It's apparently a bds2006 debugger 
> issue.
>
> Using a hacked program to externally read the debuggee process memory 
> after a bogus trip (in the filler region being checked by bytesOK) shows 
> that, in fact, the byte at that particular location is _NOT_ what the 
> debugger is displaying in the CPU pane.  The debugger is displaying 0xff 
> for location 0x04403f8.  The hack program shows the byte as 0xcc (and all 
> the other bytes in the filler region as 0xff, as does the debugger. 
> hackprog also agrees about 4-bytes preceding and following the filler area 
> [so I think the hack is probably working correctly].  It seems to differ 
> only in the one byte currently of interest.)
>
> The bds2006 debugger cpu window memory dump display is apparently 
> incorrect.
>
> So what if I can't trust the tools (not that I have anyway for a while) - 
> I got Bob G to write me some nifty faster code - maybe it'll balance out 
> if I can manage that a few more times. :) (Well, would need it a LOT more 
> times...)
>
> And I guess I can assume my CPU isn't actually failing in this regard - 
> that at least is good.
>