23 Sep
2007
23 Sep
'07
8:10 p.m.
On Sunday 23 September 2007 14:40, Chuck Guzis wrote:
Some of those look to be pretty handy, particularly those last two, which
would save a bunch of shuffling things around because of the normal asymmetry
of the instruction set...
Oh yeah.
I'll have a look then.
No big hurry on my part, I have all these other 8-bit parts I keep meaning to
get around to playing with still. Not as bad as youse guys out there
collecting the bigger stuff, but... :-)
--
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
M Dakin
On 23 Sep 2007 at 12:35, Roy J. Tellason wrote:
In a way, it makes sense. Consider that they needed *some* way to
access the mask register. They could perhaps take one of the "no op"
instructions, such as "ld c,c" and detail it off for special duty,
but that's taking an awful gamble that the code doesn't actually
appear anywhere. The 8085 RIM/SIM opcodes are already taken by the
relative jumps, so what to do? Reserve an I/O address and do your
best to make sure that 8085-type I/O doesn't inadvertently access it
by restricting the access to Z80 indirect I/O. At least if one hits
the port with some legacy Z80 I/O, it's easy to find.
I did at one point attempt a small monitor program, and it did seem to be
able to fit within a 2716, back when. It was table-driven, only I went
into it with the offset in A and the table could have 256 entries. ASCII
characters mapped to specific functions, and the higher half was used for
stuff that wasn't intended to be accessed from the keyboard. And
unprogrammed EPROM was taken into account too -- it would vector to a short
routine that would print "CRASH!"... :-) Aside from my use of relative
jumps for slightly better code compactness, I think it probably would have
run equally well on z80 or 8080 or 8085. I gotta dig the source for that out
one of these days, if I can find it...
without
accessing the internal register at 0BBh.
That's odd. :-) I never really made use of those, myself, nor
saw much source code for
stuff that did.
This comes in very handy for stack-relative and table addressing.
For the 8085:
LXI HL,offset on stack
DAD SP
MOV C,M (5 bytes)
(repeat for every reference)
For the Z80:
LD IX,0
ADD IX,SP (done only once at function entry)
LD C,[IX+offset] (3 bytes)
and it leaves HL free for other uses. The limitation, of course, is
that the displacement for the Z80 case can't exceed 255 locations--
but that generally isn't a big issue with a lot of x80 C code. What are
these? I remember some stuff in the magazines early on
(probably Byte, in its first year of publication or so) and have run
across some stuff on the 'net about undocumented z80 opcodes, most of
which don't seem to be terribly useful, but this is the first I've heard
of undocumented 8085 codes.
Make up your own mnemonics for these:
08 HL <= HL-BC All flags affected
10 Rotate HL 1 bit right No flags affected
18 Rotate DE 1 bit left Carry = old bit 15
28 Add immediate 8 bit value to HL All flags affected
38 Add immediate 8 bit value to SP All flags affected
CB If the V (overflow) flag is set, CALL 0040H
DE Load HL with the 16-bit value pointed to by DE
D9 Store HL into the 16-bit location pointed to by DE In addition, some 8 bit instructions affect bit 5 of
the flags register (in
a way that I don't completely understand). DD xx xx will jump to xxxx if
this bit is clear, ED xx xx will jump to xxxx if this bit is set.
Hm. I wonder if they had intended a use for that?
From my
viewpoint, some of these instructions look like afterthoughts-
-but some would have been useful in a couple of instances.
The biggest implication of the above, however, is that there's an
ugly trap for the lowly coder who decided that 08/10/18/28/38 was a
no-op. Do you know of
any handy data online for the part? A basic overview and
maybe some info on the instruction set and hardware would be nice.
Somehow or other I never managed to get a hold of any when that chip hit
the market.
http://www.datasheetarchive.com/preview/2602635.html Are those easy
enough to find these days if one wanted to play with 'em?
Not terribly difficult--there were a few commercial personal
computers that used them, mostly for the CMOS power advantage.
There's an eval kit from NSC on ePay right now.