Unknows S-100 System

Roy J. Tellason rtellason at verizon.net
Sun Sep 23 14:10:42 CDT 2007


On Sunday 23 September 2007 14:40, Chuck Guzis wrote:
> On 23 Sep 2007 at 12:35, Roy J. Tellason wrote:
> > > without accessing the internal register at 0BBh.
> >
> > That's odd.  :-)
>
> 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 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.

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...

> > 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

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...

> 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.

Oh yeah.

> > 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

I'll have a look then.

> > 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.

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




More information about the cctech mailing list