23 Sep
2007
23 Sep
'07
4:34 a.m.
Hi Chuck
I saw someone mention the NSC800. I don't think it was mentioned
that the NSC800 runs Z80 instructions but has the exact same
pins and interface as the 8085.
I don't recall if the NSC800 had the serial instructions of the 8085
but in this case, I don't think that is an issue.
It was true that the 8085 had just about as fast an execution
as the Z80, without the extra instructions of the Z80. This
was true for all but the tightest loops using some of the
special Z80 instructions. I recall when I was working at Intel,
we looked at many of the Z80 instructions and found them
to not be anything but code efficient with comparable speeds.
I have a couple NSC800s but not as separate packages. They
are in MA2000 modules.
The NSC800 also has the advanges of being CMOS. This means
lower power than either the 8085 or Z80.
Dwight
_________________________________________________________________
Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying
thanks for using Windows Live?.
http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2
23 Sep
23 Sep
5:34 a.m.
On 22 Sep 2007 at 21:34, dwight elvey wrote:
Not the same pinout at all; and some signals have inverted polarity.
What's similar is the timing (so the 8085 peripheral chips work)--and
the multiplexed data/address bus. It has the three "half-INT"
signals, but TRAPs to 0066h, like the Z80 and not 0024H like the
8085. There are no RIM and SIM instructions, and therefore, no
SID/SOD pins. There is also a low-power "sleep" feature.
To control the masking of the half-interrupt pins, since there's no
SIM instruction, there is a mask register located at I/O port 0BBh,
accessed by executing an output instruction--but only when accessing
the port via the indiirect "input/output to (C)" instructions; the
0D3h output and 0DBh input to immediate port function normally,
without accessing the internal register at 0BBh.
I never really considered the Z80 to be faster than the 8085, with
perhaps the exception of the 2-byte jump instructions. For
everything else, the Z80 seemed to be roughly as fast for most
things. But the Z80 was easier to program, particularly with the IX
and IY registers, particularly with the 8-bit displacement. And I
suppose interrupt servicing could be faster for high-priority
interrupts where the alternate register set could be used.
One real pain with the 8085 was the input and output instructions.
No indirection at all; just an immediate-valued port. One of the
engineers set up a peripheral that mapped into 64 I/O locations that
essentially forced us into self-modifying code to plug the port
address into a DBh or D3h instruction. That wasn't too bad normally,
but we had to access the ports during POST, which meant moving the
code to RAM from ROM so we could modify the I/O instructions.
What irritated me was that Intel never documented the additional 8085
instructions, even though they seemed to be present on every version
of the chip Intel (and second sources) ever produced. Because they
weren't "officially" documented, we adopted a policy that they should
not be used to avoid possible future "surprises".
I've got about 20 of the 40-pin DIP NSC800s; 3MHz ones, I believe.
Cheers,
Chuck
4:35 p.m.
On Sunday 23 September 2007 01:34, Chuck Guzis wrote:
That's odd. :-)
I never really made use of those, myself, nor saw much source code for stuff
that did.
And I suppose interrupt servicing could be faster for
high-priority
interrupts where the alternate register set could be used.
That's what Osborne did on the Executive, in their 1.2 ROM, which turned out
to be a mistake for software that wanted to use that alternate register set.
From what I understand this was a problem with Turbo
Pascal (which I never
used), I found it to be a problem with Mix C, where
attempting to do
anything dropped you back to a command prompt. The solution initially was to
automatically run a little program I found out there called "TPATCH" (I guess
for Turbo Pascal), that patched the code. Eventually I got an image for the
1.21 ROM and burned one and put it in there, which changed that bit of code.
The Exec's technical manuals contain ROM source and detail this.
That I/O capability and relative jumps are what I like most about the Z80.
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.
I've got about 20 of the 40-pin DIP NSC800s; 3MHz
ones, I believe.
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.
Are those easy enough to find these days if one wanted to play with 'em?
--
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
6:40 p.m.
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.
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.
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.
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.
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.
Cheers,
Chuck
7:10 p.m.
On Sunday 23 September 2007 14:40, Chuck Guzis wrote:
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...
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...
Hm. I wonder if they had intended a use for that?
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
6:54 p.m.
On 23 Sep 2007 at 12:35, Roy J. Tellason wrote:
The NSC800 hit the market in 1981; by then, a lot of firms were
already planning their 16-bit entry. As was usual with NSCs
marketing group, I was completely oblivious to the existence of the
thing until I'd moved on to the 8086/80186. The timing of the
product by National was very odd. And the initial speed offering--1
MHz--was insane, considering that the 4MHz Z80 was common fare and I
think the Z80B and Z80H may have been available by then (I'm not
certain, though).
Had the chip been available with a decent speed (say, 4MHz) in, say,
1979, we might well have used it.
Cheers,
Chuck
25 Sep
25 Sep
7:21 p.m.
New subject: HP computers available for rescue in Phoenix
Hi,
(In Phoenix, AZ)
The widow of a long-time HP 3000 developer is anxious
to find a new home/homes for some HP equipment and documentation.
I suspect shipping is unlikely, so local pickup is probably necessary.
Included are:
HP 3000, model 935 or 950 (PA-RISC)
HP 3000, model 37 or Micro3000 (Classic)
and ancillary peripherals
and a number of MPE / HP 3000 manuals.
Probably included is a wealth of manuals on internals of HP printers.
I've asked for clarification on the HP 3000 model numbers.
If anyone is interested, please email me at sieler at allegro.com
thanks,
Stan
--
Stan Sieler
sieler at allegro.com
www.allegro.com/sieler/wanted/index.html
27 Sep
27 Sep
12:59 a.m.
New subject: HP computers available for rescue in Phoenix
Re:
The widow of a long-time HP 3000 developer is anxious
to find a new home/homes for some HP equipment and documentation.
I suspect shipping is unlikely, so local pickup is probably necessary.
I've had three people email me, and I've emailed them the status.
We're still trying to get more information.
HP 3000/925 (PA-RISC) and HP 3000/37 (Classic)
thanks!
Stan
--
Stan Sieler
sieler at allegro.com
www.allegro.com/sieler/wanted/index.html
6409
days inactive
6413
days old
7 comments
4 participants
participants (4)
-
cclist＠sydex.com -
dkelvey＠hotmail.com -
rtellason＠verizon.net -
sieler＠allegro.com