8088 vs. 80c88

[Chuck Guzis]

On 24 Feb 2009 at 11:27, les at frii.com wrote:

> I am assuming the problem relates to following a lxi sp instruction
> immediatly with a call instruction, I can see how pipelining
> instructions could cause this failure.   I cant immagine how calling
> the address which happens to match the sp would be an issue. 

As far as we could determine, it was precisely the issue.

uP operation can be mysterious  I recall using early (pre-production) 
steppings of the 80186 and discovering that under certain 
circumstances a DMA transfer wouild clobber SI and DI (that one took 
almost 3 weeks to track down).
 
> My thought was that most cp/m programs either left the sp alone, and used
> the stack provided by cp/m, or set up a local stack early on in the
> program.  In either case this bug could be completly avoided.  Am I wrong
> here?  Is the bug related to calling the address which happens to be in
> the sp?

Again, yes.

> So as I understand your opinion, if NEC had stated in the V20
> documentation, that you should not follow a lxi sp instuction immediatly
> with a stack operation, this would not have been a bug.  In the case of
> the 386, they documented issues with the 386 queue, issues which crashed
> commercial software, but which are not a bug.  In this case, it was just
> code written for an older processor.

Probably not a bug, but definitely a factor in determining if I 
should have bothered to use the V20/30 for emulation at all.  
Certainly, I wondered if the lack of Z80 instruction set support 
would have been an issue.  It was--and I supplied a software emulator 
for that.  Fortunately, I also included an software 8080 emulator, so 
even users of JRT Pascal weren't left hanging.

To clarify my point, would you try to run CP/M on a Rabbit uC with 
all of its "we're just like a Z80 except when we're not" instruction 
set?  I've never tried, as the compatibility issues are just too 
severe.

Cheers,
Chuck