Z80 TRAP and CP/M
Roy J. Tellason
rtellason at blazenet.net
Tue Apr 4 14:26:13 CDT 2006
On Tuesday 04 April 2006 09:08 am, Don Y wrote:
> Roy J. Tellason wrote:
> > On Monday 03 April 2006 12:57 am, Don Y wrote:
> >> I think the real reason (?) goes to a difference in cultures between
> >> register rich and register poor machines IN THAT TIMEFRAME.
> > I think you're probably right...
> >> E.g., if you are writing code for a 68xx, you have little choice
> >> but to do everything in memory addressing. Whereas if you are
> >> using 8080/8085/Z80 et al., you just get used to *keeping* things
> >> in registers (I can recall spending lots of time evaluating
> >> which arguments I would put in which registers so I could
> >> *keep* them there -- or somewhere else in the register set -- for
> >> the duration of the algorithm... XCHG being a favorite tool
> >> in those cases!)
> > Yeah. Though XTHL was another one...
> As was PCHL. But, XCHG was lots of bang for the buck (4 clocks?)
Yes. And I often wished that they'd had one that would work with BC, as
> because it moved a lot of data in a little time. By contrast,
> XTHL (ex sp,(hl) for z80 folks) moved the same amount of data
> but, since it went to TOS, there were a lot more clocks involved
> (19 or 20, IIRC).
> >> Moving to something like a 99000 can be terribly distressing
> >> for the register rich crowd to become accustomed to! ;)
> > I found, though, when I was doing some z80 stuff a while back that most
> > of the time I'd use one pair for an address pointer and maybe one other
> > besides the accumulator and that was it, over 90% of the time.
> Z80 is a different beast from the 808. You write code differently for
> it because it has a much richer instruction set.
But I never used most of that stuff. Never got around to doing anything with
the index registers, the alternate set, or a lot of those "specials" that
were added. I kinda liked relative jumps, though, since it made it way
easier to do relocatable code and plus they were a byte smaller. :-)
> But, if you are doing things like adding an 8 digit BCD number to another 8
> digit BCD number, you quickly discover that you need a lot of registers (two
> pointers for the two arguments -- assuming the destination is one
> of these as well, a "digit counter", the accumulator and, of course, the
I suppose. I guess it all depends on what you want to do...
> > Oh, and the little monitor program that I was playing with didn't push a
> > parameter on to the stack, it put it inline, right after the call to
> > some subroutine -- the called code would pick it up and use it and adjust
> > the stack pointer to just past it for the return. :-)
> Yes, a favorite trick for "printing" strings, etc.
> CALL OUTPUT
> DB 'Hello, World!'
> <insert next instruction here>
> > I have to dig out that code, anyhow, there were a few little tricks in
> > there that I think I want to use again. Like funneling everything
> > through a dispatch table, so that un-programmed EPROM showing up as
> > "FFFF" in some entries would be handled automatically ("CRASH!" :-),
> > ferinstance.
> Or, using INR M to 'test' flags.
Sometimes I like the absolutely minimalist approach to things, too. One of
these days I'm gonna dig that code out, burn it, and see how small a z80
box I can build that'll still prove useful for all sorts of things. I sure
have enough of those parts on hand here...
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
Information is more dangerous than cannon to a society ruled by lies. --James
More information about the cctalk