mikey@trsvax (09/04/85)
The V30 is the equivilent part for the 8086, the V20 is the 8088 chip. As I understand it, the V20 and V30 are not anywhere close to the same as their Intel brothers internally, just that they operate the same or faster, and at a lower power level (they're CMOS). The V20 executes some instructions up to 30% faster and in addition, supports the 80186 op codes for bit manipulation and stuff like PUSHA and POPA. The V20 also has a native 8080 mode that allows execution of 8080 code in either a 64K model or a 128K model (separate code and data segments). Overall, they are quite a powerful chip set. I have run into some problems using a V20. There was one program that worked ok with the 8088, but died with the V20. I traced it down with debug and discovered a place where the programmer accidentally executed a data area. Since the 8088 ignored some opcodes that the V20 uses, that was the difference. I put a jump around the erroneous data area and both processors now worked fine. (It also cleared up an obscure bug in the program) mikey at trsvax ps. There is also a similar CMOS part for a Numeric Coprocessor.
phil@amdcad.UUCP (Phil Ngai) (09/08/85)
In article <53400064@trsvax> mikey@trsvax writes: >The V30 is the equivalent part for the 8086, the V20 is the 8088 chip. >As I understand it, the V20 and V30 are not anywhere close to the same >as their Intel brothers internally, just that they operate the same If they are not anywhere close to the same, then why is Intel suing NEC for stealing their microcode? If NEC is in fact using Intel's microcode without permission, that would seem to be the same kind of thing as making an illegal copy of Lotus 1-2-3. On a huge scale. Actually, it would be like making a business of selling illegal copies of 1-2-3. Disclaimer: I speak only for myself. -- A hacker is someone who orders Sweet and Sour Bitter Melon just because it is "an impossible combination". Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
baba@spar.UUCP (Baba ROM DOS) (09/10/85)
> If they are not anywhere close to the same, then why is Intel suing > NEC for stealing their microcode? > > Phil Ngai (408) 749-5720 Well, it would seem to be to Intel's advantage to keep NEC out of their market by any means available, and if they can use the courts and the anti-Japanese hysteria of the moment to do so, so much the better. I'm not saying that this is what has happened. The evidence released to the press so far has been pretty inconclusive and at times contradictory. My question is: If NEC *did* steal Intel's microcode, why are the V20s reported to be 15% faster than their born-in-the-USA brethren, at the same CPU clock rate? Baba
phil@amdcad.UUCP (Phil Ngai) (09/10/85)
In article <510@spar.UUCP> baba@spar.UUCP (Baba ROM DOS) writes: >pretty inconclusive and at times contradictory. My question is: If NEC >*did* steal Intel's microcode, why are the V20s reported to be 15% faster than >their born-in-the-USA brethren, at the same CPU clock rate? > > Baba I imagine they did "clever and original" things like put an adder in the addressing unit so that the execution unit doesn't have to share its adder, allowing more concurrency. I put "clever and original" in quotes because Intel did the same thing (first?) in their 80186. So obviously they didn't take the microcode bit for bit. If they changed just one bit, is it stealing? What about 100? We have a slippery slope here but if I were the judge, I would probably rule NEC's action was improper if there were a substantial similarity to Intel's microcode. -- A hacker is someone who orders Sweet and Sour Bitter Melon just because it is "an impossible combination". Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
lotto@talcott.UUCP (Jerry Lotto) (09/11/85)
See for example:
"CMOS microprocessor series shapes its personality with software and
hardware", Electronic Design, March 21 1985, Hayden Pub. Inc.
"Making a new CMOS microprocessor part of an extended family",
Computer Systems Equipment Design, January 1985, McGraw-Hill Inc.
NEC spec sheets - uPD70108Dx (V20) and uPD70116Dx (V30) where x=5 or 8
depending on the speed - NECEL-000010-0585, Stock # 500635
Also ask for preliminary doc - the V40/V50 Microprocessor User Guide!
--
Gerald Lotto - Harvard Chemistry Dept.
UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
ARPA: lotto@harvard.EDU
CSNET: lotto%harvard@csnet-relaymikey@trsvax (09/13/85)
> If they are not anywhere close to the same, then why is Intel suing > NEC for stealing their microcode? They are not suing for stealing the micro-code. The internal bus of the V20 is TOTALLY different. I read somewhere that the 8088 uses an 18 bit, or something like that, bus for internal micro-code and the V20 is somewhere around 23 bits. There were some articles in EE Times about the lawsuit and evidently there were counter suits over people being told that the V20 would be illegal. I don't remember the whole story, but I thought that NEC brought the first lawsuit. mikey at trsvax
wdm@ecn-pc.UUCP (William D Michael) (09/13/85)
In article <3663@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >In article <53400064@trsvax> mikey@trsvax writes: >>The V30 is the equivalent part for the 8086, the V20 is the 8088 chip. >>As I understand it, the V20 and V30 are not anywhere close to the same >>as their Intel brothers internally, just that they operate the same > >If they are not anywhere close to the same, then why is Intel suing >NEC for stealing their microcode? > >If NEC is in fact using Intel's microcode without permission, that would >seem to be the same kind of thing as making an illegal copy of Lotus 1-2-3. >On a huge scale. Actually, it would be like making a business of selling >illegal copies of 1-2-3. > I thought the 8086 and 8088 were actually random logic machines, and so had no microcode. Is that wrong? bill (wdm@pur-ee)
phil@amdcad.UUCP (Phil Ngai) (09/15/85)
In article <384@ecn-pc.UUCP> wdm@ecn-pc.UUCP (William D Michael) writes: > I thought the 8086 and 8088 were actually random logic machines, and > so had no microcode. Is that wrong? Yes, that is wrong. I do believe that the Z8000 series is random logic. Don't know about the Z80000. -- We changed Coke again. hee hee Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
uhclem@trsvax (09/16/85)
[Hemlock Stones; In "The Case of the Missing Line Re: Better Processor Look-a-Likes Sounds like NEC has done the same thing for the 808x series that Hitachi did for the Z80. As far as I know, Zilog hasn't bothered to sue. Perhaps there are enough differences. (Or maybe Japan buys lots of Exxon fuel) Their Z80 is called the HD64180. Apart from adding on-chip MMU, 512k addressing in 64k segments, on-chip two-channel DMA, on-chip two Full Duplex Asynch channels, on-chip High speed clocked serial channel (200k Bits/Sec @ 4mhz), on-chip dual 16-bit programmable reload timers, on-chip interrupt handler (4 ext. 8 int.), and twelve new instructions including multiply, Hitachi shaved the t-states on many of the old-opcodes. Examples: JR cc,address on the Z80 was 12 t-states for the jump and 7-t states for the fall-through. On the 64180, it is 8-t for the jump and 6-t for the fall-through. LD r,(IX+offset) on the Z80 was 19-t. On the 64180, it is 14-t. SET r,(IX+offset) 23-t on the Z80. 19-t on the 64180. Even the NOP executes in fewer t-states. Only two problems have presented themselves. There is an early version that had some incompatible fall-out in the flags from the DAA (Decimal Adjust) instruction that some binary-to-hex algorithms take advantage of. That appears to have been fixed. The other problem is that it isn't pin comtatible with the Z80, (It has 64 pins, the Z80 had 40) requiring you to build a jig to plug it into existing hardware. But it's worth it for the speed-up. Back to the NEC. I hope they win their countersuit. Then they can bring out versions of the ipax#86 series with enough pins/signals so that other outfits can build x86 emulators, and we can throw away all of the Intel ICE-boxes (I HATE THAT BLUE BOX!!!). <The above is my opinion and not that of my employeer. They don't care anyway; IBM doesn't sell fuel, and they think a blue box gets you free phone calls. That may be true, but I didn't want to call Intel.> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem>
mikey@trsvax (09/16/85)
I went back and dug up the article about Intel and NEC fighting it out over the V20. First, it is in the June 17 issue of EE imes, page 7 if anybody wnats to look it up. The following is some of the information from the article. Second, NEC filed the first lawsuit, asking a federal court to rule there is no infringement, this was after providing Intel with samples the previous August but getting no response. Third, the Intel 8088 uses a single bus structure, the V20 uses a double bus structure. Fourth, the Intel 8088 uses microwords 21 bits wide, the V20 uses microwords 29 bits wide (sorry about the number error in a previous posting) Finally, Intel and NEC have an agreement giving each other full access to each others patents, so there can be no patent infringment suit to begin with. Intel can't sue for the microcode, even if it was a direct copy. As it is, they are suing for using the same "expression of program". If they win, this could apply to all aspects of "reverse engineering" causing all kinds of restrictive ramifications in the software and hardware market. There is other info in the article, read it if you are really interested. As to the V20 vs the 8088, speed in some aspects is incredible with the V20, but on a system that is disk intensive, one access and you lose a lot of the benefits, unless you redo the disk I/O to take advantage of the faster I/O, probably just experiment with interleave would be enough. Overall, don't expect lightning, just 5% to 30% in most cases. There is an 8 mhz part, but I don't have anything to try it in. There is also a numeric coprocesor. I don't know anything about it's speed, but I would like it just because it's CMOS and won't turn massive amounts of power into massive amopunts of heat. Be careful of the gotchas, bugs in programs that may become worse due to different execution of previously illegal opcodes. Presonally, I got a sample of the V20 for my brothers Tandy 1000 and it runs great. mikey at trsvax
phil@amdcad.UUCP (Phil Ngai) (09/21/85)
In article <53400074@trsvax> mikey@trsvax writes: >Finally, Intel and NEC have an agreement giving each other full access to >each others patents, so there can be no patent infringment suit to begin with. >Intel can't sue for the microcode, even if it was a direct copy. I don't see how this follows. Intel may have other grounds for a suit. A direct copy probably violates more laws than just patent infringment. Copyrights, for one thing. (yes, most devices are copyrighted) -- Where does your soul go when you die? Where does a flame go when it is blown out. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
crandell@ut-sally.UUCP (Jim Crandell) (09/21/85)
>Their Z80 is called the HD64180. Apart from adding on-chip MMU, > ... Hitachi shaved the t-states on many of the old-opcodes. >Examples: > JR cc,address on the Z80 was 12 t-states for the > jump and 7-t states for the fall-through. > On the 64180, it is 8-t for the jump and 6-t for the fall-through. > ... >Even the NOP executes in fewer t-states. Really? Not a very good idea. The Z-80 nop is 4 states -- standard opcode fetch. Considering the tightness of the read and refresh cycles in an opcode fetch, a 3-clock nop would absolutely necessitate eliminating the refresh cycle. Now, suppose you ran the following code: 1000h: NOP ; 3 clocks 1001h: NOP ; 3 clocks 1002h: NOP ; 3 clocks . . . 107Ch: NOP ; 3 clocks 107D: JR 1000h ; 8 clocks The loop iteration time at 4 MHz is 95.75 uS, giving a refresh interval for row 7F of over 12 mS, which is out of spec for every dynamic RAM I've ever heard of. Furthermore, if the system RAM capacity is over 64K bytes (256K if you use 256-K RAMS), and if you decode addresses onto RAS to save power (as most of us do), then that refresh interval applies to ALL rows in the devices which don't contain the code. An artificial example, you say? Perhaps so. But the (often sad) truth is, if there's a way to do it, sooner or later someone will. -- Jim Crandell, C. S. Dept., The University of Texas at Austin {ihnp4,seismo,ctvax}!ut-sally!crandell
alan@drivax.UUCP (Alan Fargusson) (09/22/85)
> > [Hemlock Stones; In "The Case of the Missing Line > > Re: Better Processor Look-a-Likes > > Sounds like NEC has done the same thing for the 808x series that > Hitachi did for the Z80. As far as I know, Zilog hasn't bothered to sue. > Perhaps there are enough differences. (Or maybe Japan buys lots of Exxon fuel) Not true, Zilog did sue. I don't know what happend, I quit Zilog around that time. -- Alan Fargusson. { ihnp4, amdahl, mot }!drivax!alan
uhclem@trsvax (09/26/85)
[Well, Watson, I'll have a Coke. I hear it comes in bottles in this country.]
> Re: Better Processor Look-a-Likes
I talked to a Hitachi rep and it appears that Zilog tried to get some
sort of injunction while they researched infringement. According to
the Hitachi rep, Zilog lost at the preliminary hearing and has not
tried any other action to date.
"Thank you, Uh Clem."
Frank Durda IV
@ <trsvax!uhclem>