26 Feb
2009
26 Feb
'09
6:38 a.m.
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.
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.
I am sorry I am so slow here. Which is the problem? The value or the sequence?
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.
The Z80 thing is an interesting point. Before I started running CP/M on a V20, I allways
ran on a 8085. I would get annoyed when cp/m software required a z80, because it was not
a z80 operating system. I later did build a few z80 systems, a laptop and a 20mhz sbc
system, but all of the coding I did for them was 8080, except for using the 16 bit io
address features of the z80.
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.
I assumed the rabbit was a z180, you learn something new every day. I have done a few
designes with z180's, but I cant even rememer what language tools I used at this
point.
Les
--------------------------