Sender: skritch@ Newsgroups: alt.folklore.computers Subject: opcodes for Zilog 8800/Intel 8080 From: skritch@home.com Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Message-ID: <86yapc2lo7.fsf@home.com> Organization: TINO Lines: 14 X-Newsreader: Gnus v5.5/Emacs 20.3 Date: Mon, 16 Nov 1998 06:30:23 GMT NNTP-Posting-Host: 24.1.127.47 NNTP-Posting-Date: Sun, 15 Nov 1998 22:30:23 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newshub2.home.com!newshub1.home.com!news.home.com!news.rdc1.sfba.home.com.POSTED!not-for-mail Having suffered from a terminal attack of nostalgia, I've gotten my hands on an Altair and an Imsai emulator. However, I can't for the life of me track down the opcode list for either the Zilog 8800 or the Intel 8080, nor the memory map for either the Imsai 8080 or the Altair 8800 microcomputer. Does anyone have any of these available? I've checked most all of the computer museum and software/hardware archive and/or "we're preserving all this info for posterity" sites, as well as several books. Thanks! ###### From: fms@cs.umd.edu (Marat Fayzullin) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 16 Nov 1998 14:33:31 GMT Organization: U of Maryland, College Park, MD 20742 Lines: 12 Message-ID: <72pd3r$np0$1@cronkite.cs.umd.edu> References: <86yapc2lo7.fsf@home.com> NNTP-Posting-Host: nachos.cs.umd.edu X-Trace: cronkite.cs.umd.edu 911226811 24352 128.8.126.3 (16 Nov 1998 14:33:31 GMT) X-Complaints-To: abuse@cs.umd.edu NNTP-Posting-Date: 16 Nov 1998 14:33:31 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!howland.erols.net!nntp.abs.net!cs.umd.edu!not-for-mail skritch@home.com wrote: : However, I can't for the life of me track down the opcode list for : either the Zilog 8800 or the Intel 8080, nor the memory map for : either the Imsai 8080 or the Altair 8800 microcomputer. http://www.komkon.org/fms/comp/ : Does anyone have any of these available? I've checked most all of : the computer museum and software/hardware archive and/or "we're : preserving all this info for posterity" sites, as well as several : books. 8080 opcode tables are not *that* rare. ###### Sender: skritch@ Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> From: skritch@home.com Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Message-ID: <86r9v3fva3.fsf@home.com> Organization: TINO Lines: 28 X-Newsreader: Gnus v5.5/Emacs 20.3 Date: Mon, 16 Nov 1998 16:36:43 GMT NNTP-Posting-Host: 24.1.127.47 NNTP-Posting-Date: Mon, 16 Nov 1998 08:36:43 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!news-xfer.newsread.com!netaxs.com!newsread.com!newshub2.home.com!newshub1.home.com!news.home.com!news.rdc1.sfba.home.com.POSTED!not-for-mail fms@cs.umd.edu (Marat Fayzullin) writes: > skritch@home.com wrote: > > : However, I can't for the life of me track down the opcode list for > : either the Zilog 8800 or the Intel 8080, nor the memory map for > : either the Imsai 8080 or the Altair 8800 microcomputer. > http://www.komkon.org/fms/comp/ Yes, that's a wonderful site. I guess I should have been more specific...I'm looking for the opcode tables for these along with their binary or hex equivalents, as I'd like to actually program the Imsai or Altair using the front-panel toggle switches. This requires that I know, or am able to derive, the binary equivalent for each opcode. > > : Does anyone have any of these available? I've checked most all of > : the computer museum and software/hardware archive and/or "we're > : preserving all this info for posterity" sites, as well as several > : books. > 8080 opcode tables are not *that* rare. No, but they are surprisingly hard to find, at least in the form in which I need them. :) Thanks for the help, tho. ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 16 Nov 1998 21:18:10 +0100 Organization: My own Private Self Lines: 39 Sender: neil@chonsp.franklin.ch Message-ID: References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> X-Newsreader: Gnus v5.3/Emacs 19.34 skritch@home.com writes: > > fms@cs.umd.edu (Marat Fayzullin) writes: > > > skritch@home.com wrote: > > > > : However, I can't for the life of me track down the opcode list for > > : either the Zilog 8800 That is either Zilog Z80-CPU or Zilog 85x0 (can't remember the x), an 8080 compatible processor or Altair 8800, an early Intel 8080 processor based microcomputer. > > : Does anyone have any of these available? I've checked most all of > > 8080 opcode tables are not *that* rare. > No, but they are surprisingly hard to find, at least in the form in > which I need them. :) Thanks for the help, tho. I have got here an full opcode list of the 8085 (Intels compatible upgrade for the 8080) printed by Siemens, an official 8085 second source. It has the full mnemonics, binary representation, instruction description in english, but the detailed descriptions are in german (Siemens is an german firm). If you want a copy (3 2-sided A4) e-mail me your snail address. Actually, looking at it, this is the sort of thing that should be webbed. If it is not, I think I will put it on my website. And 6809 as well. I learned programming on Z80, 6809 was second. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### From: bill_r@inetnebr.com (Bill Richman) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Tue, 17 Nov 1998 05:59:33 GMT Organization: Internet Nebraska Lines: 24 Message-ID: <36560fa4.14625700@news.inetnebr.com> References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> NNTP-Posting-Host: in221.inetnebr.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.451 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!208.128.117.2!newsrelay.courtave.net!newsfeed.inetnebr.com!news.inetnebr.com!not-for-mail I have a copy of the 1976 Zilog Z80 Assembly Language Programming Manual. I scanned the table in the back with the opcodes and object code; this in combination with one of the instruction tables from http://www.comlab.ox.ac.uk/archive/cards.html should be all you need to start programming the Z-80. You can find my scanned pages on my web page under "Classic Computers", "Archive of Esoteric Documents for Obscure Computers". Hope this helps. P.S. - Come to think of it, the original IMSAI and the Altair 8800 both used the 8080 CPU, so this is probably of little use to you... DOH! --- On Mon, 16 Nov 1998 16:36:43 GMT, skritch@home.com wrote: >> >> : However, I can't for the life of me track down the opcode list for >> : either the Zilog 8800 or the Intel 8080, nor the memory map for >> : either the Imsai 8080 or the Altair 8800 microcomputer. -Bill Richman (bill_r@inetnebr.com) http://incolor.inetnebr.com/bill_r - Home of the COSMAC Elf Microcomputer Simulator, Fun with Molten Metal, Orphaned Robots, and Technological Oddities.) ###### Sender: skritch@ Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> From: skritch@home.com Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Message-ID: <86u2zylsmb.fsf@home.com> Organization: TINO Lines: 29 X-Newsreader: Gnus v5.5/Emacs 20.3 Date: Tue, 17 Nov 1998 06:49:57 GMT NNTP-Posting-Host: 24.1.127.47 NNTP-Posting-Date: Mon, 16 Nov 1998 22:49:57 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.direct.ca!newshub1.home.com!news.home.com!news.rdc1.sfba.home.com.POSTED!not-for-mail bill_r@inetnebr.com (Bill Richman) writes: > I have a copy of the 1976 Zilog Z80 Assembly Language Programming > Manual. I scanned the table in the back with the opcodes and object > code; this in combination with one of the instruction tables from > http://www.comlab.ox.ac.uk/archive/cards.html should be all you need to > start programming the Z-80. You can find my scanned pages on my web > page under "Classic Computers", "Archive of Esoteric Documents for > Obscure Computers". Hope this helps. > > P.S. - Come to think of it, the original IMSAI and the Altair 8800 both > used the 8080 CPU, so this is probably of little use to you... DOH! Thanks for the effort! But, now I guess I'm really confused. I'm positive that the IMSAI 8080 did use the Intel 8080 chip. So there's no debate there (unless I'm wrong, at which point I may break down in tears). But I thought the Altair 8800 used a Zilog chip. I've seen the Altair 8800 spoken about as using a "Zilog 8800" CPU, and have also seen people say it uses a Z80, or a Z80-compatible. I've even seen statements that the Intel 8080 and the Zilog Z80 are compatible. So, I guess now my question has evolved into, which is the real story? I really would rather not have to track down and crack open an actual Altair to check. I value by skin in its current state. :) ###### Message-ID: <3651998E.8F63F49F@jkmicro.com> From: Jim Stewart Organization: http://www.jkmicro.com X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> <86u2zylsmb.fsf@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 52 NNTP-Posting-Host: 168.150.253.121 X-Trace: news13.ispnews.com 911317402 168.150.253.121 (Tue, 17 Nov 1998 10:43:22 EDT) NNTP-Posting-Date: Tue, 17 Nov 1998 10:43:22 EDT Date: Tue, 17 Nov 1998 07:43:10 -0800 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!hub1.ispnews.com!news13.ispnews.com.POSTED!not-for-mail skritch@home.com wrote: > bill_r@inetnebr.com (Bill Richman) writes: > > > I have a copy of the 1976 Zilog Z80 Assembly Language Programming > > Manual. I scanned the table in the back with the opcodes and object > > code; this in combination with one of the instruction tables from > > http://www.comlab.ox.ac.uk/archive/cards.html should be all you need to > > start programming the Z-80. You can find my scanned pages on my web > > page under "Classic Computers", "Archive of Esoteric Documents for > > Obscure Computers". Hope this helps. > > > > P.S. - Come to think of it, the original IMSAI and the Altair 8800 both > > used the 8080 CPU, so this is probably of little use to you... DOH! > > Thanks for the effort! > > But, now I guess I'm really confused. I'm positive that the IMSAI > 8080 did use the Intel 8080 chip. So there's no debate there (unless > I'm wrong, at which point I may break down in tears). > > But I thought the Altair 8800 used a Zilog chip. I've seen the Altair > 8800 spoken about as using a "Zilog 8800" CPU, and have also seen > people say it uses a Z80, or a Z80-compatible. I've even seen > statements that the Intel 8080 and the Zilog Z80 are compatible. > > So, I guess now my question has evolved into, which is the real story? > I really would rather not have to track down and crack open an actual > Altair to check. I value by skin in its current state. :) I worked for IMSAI during this era so I know a little about the subject. The Altair 8800 used the Intel 8080A chip. The earliest IMSAI 8080's used the Intel 8080A cpu, but soon after the start of production, they switched to the NEC 8080A. After some problems involving the way the flags were handled, IMSAI went to the NEC8080AF, a cpu that handled the flags exactly as the Intel chip. Neither company used the Z-80 in their original products. A company called TDL made a very popular replacement/alternate cpu board with a Z-80 processor. The flag issue was an important one because the first releases of Microsoft Basic would only run on a Genuine Intel cpu. Details here are a little fuzzy, but as I recall, the Intel 8080A did not handle the parity flag correctly and Microsoft Basic exploited this in a bad way. As the NEC 8080A and the Z-80 handled the flag properly, early releases of Basic would not run on them. Microsoft later modified Basic to run on all the processors, but by that time damage had already been done. Jim ###### Date: Tue, 17 Nov 1998 10:51:08 -0800 From: twingo@bearriver.com (Tony Wingo) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Message-ID: References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> Organization: Bear River Associates X-Newsreader: MT-NewsWatcher 2.4.4 Lines: 32 NNTP-Posting-Host: 198.211.78.13 X-Trace: nntp1.ba.best.com 911328777 12758 198.211.78.13 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!feed1.news.rcn.net!rcn!news2.best.com!news3.best.com!nntp1.ba.best.com!not-for-mail In article <3651998E.8F63F49F@jkmicro.com>, Jim Stewart wrote: > I worked for IMSAI during this era so I know a little about the subject. I worked at IMSAI for a short while too. Would have been late '75 to mid '76. >The Altair 8800 used the Intel 8080A chip. The earliest IMSAI 8080's used the >Intel 8080A cpu, but soon after the start of production, they switched to the >NEC 8080A. After some problems involving the way the flags were handled, >IMSAI went to the NEC8080AF, a cpu that handled the flags exactly as the >Intel chip. Neither company used the Z-80 in their original products. A >company called TDL made a very popular replacement/alternate cpu board with a >Z-80 processor. > >The flag issue was an important one because the first releases of Microsoft >Basic would only run on a Genuine Intel cpu. Details here are a little >fuzzy, but as I recall, the Intel 8080A did not handle the parity flag >correctly and Microsoft Basic exploited this in a bad way. As the NEC 8080A >and the Z-80 handled the flag properly, early releases of Basic would not run >on them. Microsoft later modified Basic to run on all the processors, but by >that time damage had already been done. Actually, the problem was that INTEL didn't specify how the flags behaved on all instructions. So the various knock-offs behaved differently in the undefined cases. Unfortuately, a number of "clever" programmers figured out how Intel set the flags, then coded to this "standard". While MS may have been the worst offender, this was the source of numerous headaches at several companies I worked at. -t ###### From: fms@cs.umd.edu (Marat Fayzullin) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 17 Nov 1998 14:13:26 GMT Organization: U of Maryland, College Park, MD 20742 Lines: 17 Message-ID: <72s0a6$r13$1@cronkite.cs.umd.edu> References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> <86u2zylsmb.fsf@home.com> NNTP-Posting-Host: nachos.cs.umd.edu X-Trace: cronkite.cs.umd.edu 911312006 27683 128.8.126.3 (17 Nov 1998 14:13:26 GMT) X-Complaints-To: abuse@cs.umd.edu NNTP-Posting-Date: 17 Nov 1998 14:13:26 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!nntp.abs.net!cs.umd.edu!not-for-mail skritch@home.com wrote: : But I thought the Altair 8800 used a Zilog chip. I've seen the Altair : 8800 spoken about as using a "Zilog 8800" CPU, and have also seen : people say it uses a Z80, or a Z80-compatible. I've even seen : statements that the Intel 8080 and the Zilog Z80 are compatible. : So, I guess now my question has evolved into, which is the real story? : I really would rather not have to track down and crack open an actual : Altair to check. I value by skin in its current state. :) Can't say much about Altair, but Zilog Z80 CPU is an extended 8080 clone backward compatible with Z80 at the assembly level. Zilog has added more instructions and changed mnemonics, but the basic core of instructions works the same and has the same opcodes in both 8080 and Z80. They are just called with different names. Marat ###### Sender: skritch@ Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> From: skritch@home.com Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Message-ID: <863e7ib7da.fsf@home.com> Organization: TINO Lines: 29 X-Newsreader: Gnus v5.5/Emacs 20.3 Date: Tue, 17 Nov 1998 16:39:06 GMT NNTP-Posting-Host: 24.1.127.47 NNTP-Posting-Date: Tue, 17 Nov 1998 08:39:06 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!chippy.visi.com!news-out.visi.com!newsfeed1.earthlink.net!newsfeed.concentric.net!newshub1.home.com!news.home.com!news.rdc1.sfba.home.com.POSTED!not-for-mail Jim Stewart writes: > I worked for IMSAI during this era so I know a little about the subject. > The Altair 8800 used the Intel 8080A chip. The earliest IMSAI 8080's used the > Intel 8080A cpu, but soon after the start of production, they switched to the > NEC 8080A. After some problems involving the way the flags were handled, > IMSAI went to the NEC8080AF, a cpu that handled the flags exactly as the > Intel chip. Neither company used the Z-80 in their original products. A > company called TDL made a very popular replacement/alternate cpu board with a > Z-80 processor. > > The flag issue was an important one because the first releases of Microsoft > Basic would only run on a Genuine Intel cpu. Details here are a little > fuzzy, but as I recall, the Intel 8080A did not handle the parity flag > correctly and Microsoft Basic exploited this in a bad way. As the NEC 8080A > and the Z-80 handled the flag properly, early releases of Basic would not run > on them. Microsoft later modified Basic to run on all the processors, but by > that time damage had already been done. > > Jim Jim - Excellent! And I'm not at all surprised to hear that about Bill. :) So this means I shouldn't have any trouble with either the 8080 or the Z80 opcodes on either machine. Thanks for the history lesson. This should be saved for posterity (if it hasn't been already...in my focus on the chips themselves I've done my best to avoid the whole MS Basic controversy in any detail) ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> <86u2zylsmb.fsf@home.com> X-Disclaimer: Everything I write is false. Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 17 Nov 1998 16:29:00 -0800 Message-ID: Lines: 42 X-Newsreader: Gnus v5.5/Emacs 20.2 NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 17 Nov 1998 16:26:35 -0800, ruckus.brouhaha.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!newsfeed.berkeley.edu!enews.sgi.com!news.sgi.com!news.spies.com!ruckus.brouhaha.com skritch@home.com writes: > But I thought the Altair 8800 used a Zilog chip. Nope. It used the good 'ol 8080. The Zilog chip wasn't even announced until more than a year after the Altair 8800 shipped. > I've seen the Altair 8800 spoken about as using a "Zilog 8800" CPU, There wasn't ever a Zilog 8800, although Zilog had a Z-8000 series (16-bit) and a Z80,000 (32-bit, never actually shipped AFAIK). There *almost* was an Intel 8800, but it wasn't even *similar* to the 8080; it was a 32-bit chip set, and became the iAPX-432 when it was announced in 1981. The schematics of the 432/100 evaluation board (which ran a custom version of Rosetta Smalltalk) show the GDP chips with part numbers 8801 and 8802, which became 43201 and 43202. > and have also seen > people say it uses a Z80, or a Z80-compatible. I've even seen > statements that the Intel 8080 and the Zilog Z80 are compatible. The Z-80 is nowhere near pin-compatible with the 8080. The 8080 requires a two-phase non-overlapping clock at MOS levels, and requires some external logic to decode the bus status. Intel offered support chips for clock generation and bus interfacing, but AFAIK the Altair did not use them, probably because they were expensive. The Z-80 was much easier to design with, because it only required a single-phase clock (almost but not quite TTL compatible), and had internal bus signal decoding. Software-wise, the Z-80 is mostly upward compatible from the 8080. I've heard that there was a change in how one of the flag bits was affected by one instruction, but I'm not sure if that is true. Zilog adopted a different (and more logical) set of mnemonics, possibly because Intel claimed that the 8080 mnemonics were copyrighted. However, the object code was identical. Almost all 8080 software runs fine on the Z-80. CP/M was written for the 8080 and did not use Z-80 features, but some vendors wrote BIOS code that used extra registers without properly saving and restoring them; this later caused problems with some application software that also used Z-80 registers. Eric ###### From: william.hamblen@nashville.com (William Hamblen) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 18 Nov 1998 04:20:15 GMT Organization: utterly disorganized Lines: 15 Message-ID: <36594a26.56248379@news.nashville.com> References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> <86u2zylsmb.fsf@home.com> Reply-To: william.hamblen@nashville.com NNTP-Posting-Host: 207.65.180.69 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 911362843 4TJCV727NB445CF41C usenet58.supernews.com X-Complaints-To: newsabuse@supernews.com X-Newsreader: Forte Agent 1.5/32.452 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!Supernews73!supernews.com!Supernews69!not-for-mail On 17 Nov 1998 16:29:00 -0800, Eric Smith wrote: >Software-wise, the Z-80 is mostly upward compatible from the 8080. I've heard >that there was a change in how one of the flag bits was affected by one >instruction, but I'm not sure if that is true. The Intel 8080 set the parity bit after every arithmetic or logical instruction. The Z80 set the parity bit only after the logical instructions and used the same flag bit for an overflow bit after arithmetic instructions. The 8080 didn't have an overflow bit. If you wanted the Z80 parity bit to behave just like the 8080 parity bit you needed to put an AND A instruction after the arithmetic instruction. ###### Date: 18 Nov 98 11:01:03 -0800 From: "Charlie Gibbs" Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> Message-ID: <1612.626T153T6613270@sky.bus.com> Newsgroups: alt.folklore.computers Lines: 33 X-Newsreader: THOR 2.5a (Amiga;TCP/IP) NNTP-Posting-Host: news.skybus.com X-Trace: 18 Nov 1998 12:29:05 -0800, news.skybus.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!Supernews60!supernews.com!news-stk-2.sprintlink.net!news-backup-west.sprintlink.net!news.sprintlink.net!204.244.4.2!news.westel.com!news.skybus.com!204.244.247.115 In article <72tm5g$3vd$1@news.wlg.netlink.net.nz> don@news.daedalus.co.nz (Don Stokes) writes: >(Personally, I think the Zilog style assembler mnemonics (ld to,from) >make more sense than the Intel equivalents (mov to,from), but that's >probably because the Intel way is backwards from the DEC way (mov >from,to) that I'm used to.) Oh hell, I might as well get another flame war going. I prefer the Intel mnemonics. IMHO the Zilog mnemonics are bad because they create an illusion of orthogonality where none exists. At least saying MOV, LXI, STA, or whatever keeps you aware that the corresponding operations are quite different from each other, and it's quite obvious which operations are not allowed - something which the Zilog mnemonics conceal. (That might be OK for a high-level language, but we're down to the bare metal here.) The other thing that irritates me about Zilog mnemonics was that opcodes are almost redundant - everything's becoming LD, it sometimes seems. I thought of modifying my assembler (or at least adding macros) to make it so: e.g. LD @A, instead of INP, or LD PC, instead of JMP(*), for instance. Once all instructions have the same op code, you can get rid of it entirely, and write your program as just a series of operands. :-) * Yes, I know that the Zilog mnemonic for an unconditional jump is JP, even though every fiber of my being screams, "NO! That's wrong! JP means Jump if Plus!" But I hate the format of the Zilog jump instructions too, so there. :-p -- cgibbs@sky.bus.com (Charlie Gibbs) Remove the first period after the "at" sign to reply. ###### Date: 18 Nov 98 18:11:54 -0800 From: "Charlie Gibbs" Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> Message-ID: <3843.626T2705T10915530@sky.bus.com> Newsgroups: alt.folklore.computers Lines: 82 X-Newsreader: THOR 2.5a (Amiga;TCP/IP) NNTP-Posting-Host: news.skybus.com X-Trace: 18 Nov 1998 18:19:50 -0800, news.skybus.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!cyclone.news.idirect.com!island.idirect.com!news1.tor.metronet.ca!news1.cal.metronet.ca!news1.van.metronet.ca!kneehigh.imag.net!news.westel.com!news.skybus.com!204.244.247.119 In article <72viq9$g90$1@cronkite.cs.umd.edu> fms@cs.umd.edu (Marat Fayzullin) writes: >Charlie Gibbs (cgibbs@sky.bus.com) wrote: > >: Oh hell, I might as well get another flame war going. Yup, someone bit. :-) >: I prefer >: the Intel mnemonics. IMHO the Zilog mnemonics are bad because >: they create an illusion of orthogonality where none exists. At >: least saying MOV, LXI, STA, or whatever keeps you aware that the >: corresponding operations are quite different from each other, and >: it's quite obvious which operations are not allowed - something >: which the Zilog mnemonics conceal. (That might be OK for a >: high-level language, but we're down to the bare metal here.) > >How are they different? I agree that they are different in the >way CPU internals perform them, but for me as a programmer they >are all the same: data transfers. I simply don't care how CPU >performs them, as long as they are around. See my last sentence above. If I'm down to assembly language, I often _do_ care how the CPU does it. >: The other thing that irritates me about Zilog mnemonics was that >: opcodes are almost redundant - everything's becoming LD, it >: sometimes seems. I thought of modifying my assembler (or at >: least adding macros) to make it so: e.g. LD @A, instead >: of INP, or LD PC, instead of JMP(*), for instance. Once >: all instructions have the same op code, you can get rid of it >: entirely, and write your program as just a series of operands. :-) > >Lousy argument. Zilog uses "LD" for data transfers. They are all >called LD because they all perform the same operation, including >the infamous LD PC, opcode. There is a lot of other mnemonics >in Z80 assembly though, ADD, EX, DEC, and INC to name a few. Why "LD" instead of something that better suggests a general move, such as "MOV"? Whenever I see "LD" I think "Load". This isn't too appropriate for a move from a register to memory, which is commonly referred to as a "store". "Load" is usually reserved to mean a move in the opposite direction. >: * Yes, I know that the Zilog mnemonic for an unconditional jump >: is JP, even though every fiber of my being screams, "NO! That's >: wrong! JP means Jump if Plus!" But I hate the format of the >: Zilog jump instructions too, so there. :-p > >Then how you distinguish it from JR? Remember, Z80 has relative >jumps. 8080 doesn't. JRZ, JRNZ, etc. I got used to extended branch mnemonics on the IBM 360, although I do admit it took me a while. On the 1620, on the other hand, the different conditional branches were separate instructions with unique first bytes, just like on the 8080/Z-80. (But I could be opening a whole new can of worms regarding instruction decoding if we follow that one too far...) Still, if the mnemonic was more obviously "Jump on Condition" (the 360 uses "BC" as in "Branch on Condition"), I might find it easier to swallow. JP just doesn't sound like "jump" to me, I guess. >PS: Some of the most dreadful mnemonics I have seen in my life > were XTHL,SPHL,PCHL, and XCHG (*four* consonants in a row), > all from 8080. I am sure IBM/360 programmers will readily > come with even worse ones though. Those one _are_ a mouthful. I spell the first three letter by letter. The last one can be pronounced "exchange", though. Let's see, the 360 has things like MVC, MVN, and MVZ, which again are easier to just spell out. But it also has ZAP, which is kind of fun. Then there are the inbetween ones like BXLE. Most people pronounce that one "bixel", but I once heard someone pronounce it "boxel" and I liked it so much I adopted it. No such luck with its sister instruction BXH, though... -- cgibbs@sky.bus.com (Charlie Gibbs) Remove the first period after the "at" sign to reply. ###### Message-ID: <36532888.48030FCD@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 77 Date: Wed, 18 Nov 1998 20:05:28 -0400 NNTP-Posting-Host: 198.232.144.27 X-Trace: audrey2.cais.com 911438062 198.232.144.27 (Wed, 18 Nov 1998 20:14:22 EDT) NNTP-Posting-Date: Wed, 18 Nov 1998 20:14:22 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.cwix.com!206.165.3.11!nntp.primenet.com!in1.nntp.cais.net!199.0.216.204.MISMATCH!audrey2.cais.com!not-for-mail Marat Fayzullin wrote: > > Charlie Gibbs (cgibbs@sky.bus.com) wrote: > : Oh hell, I might as well get another flame war going. I prefer > : the Intel mnemonics. IMHO the Zilog mnemonics are bad because > : they create an illusion of orthogonality where none exists. At > : least saying MOV, LXI, STA, or whatever keeps you aware that the > : corresponding operations are quite different from each other, and > : it's quite obvious which operations are not allowed - something > : which the Zilog mnemonics conceal. (That might be OK for a > : high-level language, but we're down to the bare metal here.) > How are they different? I agree that they are different in the > way CPU internals perform them, but for me as a programmer they > are all the same: data transfers. I simply don't care how CPU > performs them, as long as they are around. The original 8080A mnemonics were a very direct mapping between the different move types possibe and the mnemonics. The moves can be broken up into several different types: 1. Register to register, and register to M, byte moves. (i.e. MOV B,D or MOV M,A). 2. Move immediate byte to register commands, i.e. MVI B,5. 3. Move immediate 2-byte word to register commands, i.e. LXI D,5632. 4. Move accumulator to memory location (and reverse) commands, i.e. STA 4567, LDA 8321. 5. Store and load HL pair commands, i.e SHLD 4567, LHLD 8321. 6. The STAX B, LDAX B, STAX D, and LDAX D type moves. 7. The PCHL, SPHL, XTHL, and XCHG mnemonics, all in a class of their own :-). The above different sorts of moves are *very* different to someone who's learned 8080A assembly language, or who has spent years of their lives toggling programs into front panel machines. Within any given type of move, the move is orthogonal, and the 8080A mnemonics nicely delineate the different classes of moves to keep clear what is possible. For instance, you can't do a LD B,(DE) (in Z-80 style mnemonic) on an 8080A, and you wouldn't dream of doing so in 8080A mnemonics because such a mnemonic doesn't exist. Why should a programmer care what class of "load" they're doing? Every byte counts, and the number of bytes and cycles it takes to do each operation is perfectly clear in 8080A mnemonics. The Z80 mnemonics hide all this, making the actual operation much more opaque. (I won't start complaining about all the "prefix" opcodes the Z80 designers had to introduce to deal with the IX and IY registers.) > : The other thing that irritates me about Zilog mnemonics was that > : opcodes are almost redundant - everything's becoming LD, it > : sometimes seems. I thought of modifying my assembler (or at > : least adding macros) to make it so: e.g. LD @A, instead > : of INP, or LD PC, instead of JMP(*), for instance. Once > : all instructions have the same op code, you can get rid of it > : entirely, and write your program as just a series of operands. :-) > Lousy argument. Zilog uses "LD" for data transfers. They are all > called LD because they all perform the same operation, including > the infamous LD PC, opcode. Yep, to the untrained eye they all perform the same operation. To folks who have to worry about how many bytes are used by each instruction and how many clocks it takes to execute each instruction, the "LD" is a pain in the butt because it hides these important details. IMHO, if you're using assembler, it's because you want to get involved at the detailed level. Anything that hides these details from you - like the Z80 mnemonics - is doing you more harm than good. -- Tim Shoppa Email: shoppa@trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 ###### Message-ID: <36534B14.E58E393@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 21 Date: Wed, 18 Nov 1998 22:32:52 -0400 NNTP-Posting-Host: 198.232.144.27 X-Trace: audrey2.cais.com 911446904 198.232.144.27 (Wed, 18 Nov 1998 22:41:44 EDT) NNTP-Posting-Date: Wed, 18 Nov 1998 22:41:44 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!news-pen-3.sprintlink.net!news-in-east1.sprintlink.net!news.sprintlink.net!in1.nntp.cais.net!199.0.216.204.MISMATCH!audrey2.cais.com!not-for-mail Charlie Gibbs wrote: > > In article <72viq9$g90$1@cronkite.cs.umd.edu> fms@cs.umd.edu > (Marat Fayzullin) writes: > >Lousy argument. Zilog uses "LD" for data transfers. They are all > >called LD because they all perform the same operation, including > >the infamous LD PC, opcode. There is a lot of other mnemonics > >in Z80 assembly though, ADD, EX, DEC, and INC to name a few. > > Why "LD" instead of something that better suggests a general > move, such as "MOV"? Because the good mnemonics were copyrighted by Intel, Zilog had to be different or be sued. (Not that Zilog ever had much in the way of profits in any event!) -- Tim Shoppa Email: shoppa@trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 ###### From: fms@cs.umd.edu (Marat Fayzullin) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 18 Nov 1998 22:47:37 GMT Organization: U of Maryland, College Park, MD 20742 Lines: 39 Message-ID: <72viq9$g90$1@cronkite.cs.umd.edu> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> NNTP-Posting-Host: nachos.cs.umd.edu X-Trace: cronkite.cs.umd.edu 911429257 16672 128.8.126.3 (18 Nov 1998 22:47:37 GMT) X-Complaints-To: abuse@cs.umd.edu NNTP-Posting-Date: 18 Nov 1998 22:47:37 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!news-raspail.gip.net!news-peer.gip.net!news.gsl.net!gip.net!cyclone.news.idirect.com!island.idirect.com!tor-nx1.netcom.ca!news.louisville.edu!uky.edu!info.usuhs.mil!cs.umd.edu!not-for-mail Charlie Gibbs (cgibbs@sky.bus.com) wrote: : Oh hell, I might as well get another flame war going. I prefer : the Intel mnemonics. IMHO the Zilog mnemonics are bad because : they create an illusion of orthogonality where none exists. At : least saying MOV, LXI, STA, or whatever keeps you aware that the : corresponding operations are quite different from each other, and : it's quite obvious which operations are not allowed - something : which the Zilog mnemonics conceal. (That might be OK for a : high-level language, but we're down to the bare metal here.) How are they different? I agree that they are different in the way CPU internals perform them, but for me as a programmer they are all the same: data transfers. I simply don't care how CPU performs them, as long as they are around. : The other thing that irritates me about Zilog mnemonics was that : opcodes are almost redundant - everything's becoming LD, it : sometimes seems. I thought of modifying my assembler (or at : least adding macros) to make it so: e.g. LD @A, instead : of INP, or LD PC, instead of JMP(*), for instance. Once : all instructions have the same op code, you can get rid of it : entirely, and write your program as just a series of operands. :-) Lousy argument. Zilog uses "LD" for data transfers. They are all called LD because they all perform the same operation, including the infamous LD PC, opcode. There is a lot of other mnemonics in Z80 assembly though, ADD, EX, DEC, and INC to name a few. : * Yes, I know that the Zilog mnemonic for an unconditional jump : is JP, even though every fiber of my being screams, "NO! That's : wrong! JP means Jump if Plus!" But I hate the format of the : Zilog jump instructions too, so there. :-p Then how you distinguish it from JR? Remember, Z80 has relative jumps. 8080 doesn't. PS: Some of the most dreadful mnemonics I have seen in my life were XTHL,SPHL,PCHL, and XCHG (*four* consonants in a row), all from 8080. I am sure IBM/360 programmers will readily come with even worse ones though. Marat ###### Message-ID: <36536059.4FC4E60F@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <36532888.48030FCD@trailing-edge.com> <730633$e61$1@cronkite.cs.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 72 Date: Thu, 19 Nov 1998 00:03:37 -0400 NNTP-Posting-Host: 198.232.144.27 X-Trace: audrey2.cais.com 911452350 198.232.144.27 (Thu, 19 Nov 1998 00:12:30 EDT) NNTP-Posting-Date: Thu, 19 Nov 1998 00:12:30 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!206.165.3.11!nntp.primenet.com!in1.nntp.cais.net!199.0.216.204.MISMATCH!audrey2.cais.com!not-for-mail Marat Fayzullin wrote: > > Tim Shoppa (shoppa@trailing-edge.com) wrote: > : Why should a programmer care what class of "load" they're doing? > : Every byte counts, and the number of bytes and cycles it takes > : to do each operation is perfectly clear in 8080A mnemonics. > : The Z80 mnemonics hide all this, making the actual operation > : much more opaque. (I won't start complaining about all the > : "prefix" opcodes the Z80 designers had to introduce to deal > : with the IX and IY registers.) > Incorrect. If we do not look at the IX/IY operations, you will > have to agree that each Z80 opcode takes 1 (one) byte plus > as many bytes as it's argument takes. Well, you're leaving out the BIT, SET, and RESET prefixes, which can be combined with the IX and IY prefixes to create very long "instructions", i.e. BIT 6,(IX+08) assembles to DDCB0876, four bytes. Notice that the "08" is sort-of an argument (it takes a byte), while the "6" isn't in the same sense. > Execution time may differ (of course), but it also doesn't take > too much time to deduce from the number of parenthesis and > numerical arguments. Actually, it's much more complicated than just counting parentheses and numerical arguments. When counting cycles, you *have* to think of all the different LD forms, and their various IX and IY prefixes, as different instructions. The LD mnemonic form is just hiding this from you. If it's just a matter of counting parantheses, how come LD HL,(8) takes such a substantially different amount of time than LD (IY+08),C ? > Now, if you look at 80x86 architecture from the same Intel, and > look at how much time ADD to AX takes in comparison to, let us > say, ADD to DX, you will see what "non-orthogonal" means. I'll agree that 80x86 mnemonics are just as bad, if not worse, than Z80 mnemonics :-). > : IMHO, if you're using assembler, it's because you want to > : get involved at the detailed level. Anything that hides > : these details from you - like the Z80 mnemonics - is doing > : you more harm than good. > Anything that makes me memorize hundreds of different mnemonics > will do me more harm than good by making my brain do additional > useless work. But with "LD" you're doing the work of remembering which LD forms are legal and which aren't. LD A,I works, but LD B,I doesn't. LD (HL),C works but LD (DE),C doesn't, yet LD (DE),A does. You've got to remember all the rules for what different real operations are possible with LD, when 8080 mnemonics do that work for you (and more) automatically. And I would argue that the mnemonics are easier to remember (hey, isn't that what mnemonic is defined as?!) than seemingly arbitrary rules about which LD combinations are legal and which aren't. What I'm saying is this: The Z80 mnemonic LD isn't one instruction. It actually assembles to one of a couple dozen different instructions, all with radically different binary forms. This is a complete breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic is one instruction, and where the argument bit patterns get filled in in a very predictable manner. Folks like me who grew up with assemblers that directly map mnemonics to instructions like it that way, because knowing the mnemonic tells you a lot about what actually happens at the machine level. I feel uncomfortable with assemblers that hide the machine level stuff from me. Tim. (shoppa@trailing-edge.com) ###### From: fms@cs.umd.edu (Marat Fayzullin) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 19 Nov 1998 04:16:35 GMT Organization: U of Maryland, College Park, MD 20742 Lines: 41 Message-ID: <730633$e61$1@cronkite.cs.umd.edu> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <36532888.48030FCD@trailing-edge.com> NNTP-Posting-Host: nachos.cs.umd.edu X-Trace: cronkite.cs.umd.edu 911448995 14529 128.8.126.3 (19 Nov 1998 04:16:35 GMT) X-Complaints-To: abuse@cs.umd.edu NNTP-Posting-Date: 19 Nov 1998 04:16:35 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!nntp.abs.net!cs.umd.edu!not-for-mail Tim Shoppa (shoppa@trailing-edge.com) wrote: : Why should a programmer care what class of "load" they're doing? : Every byte counts, and the number of bytes and cycles it takes : to do each operation is perfectly clear in 8080A mnemonics. : The Z80 mnemonics hide all this, making the actual operation : much more opaque. (I won't start complaining about all the : "prefix" opcodes the Z80 designers had to introduce to deal : with the IX and IY registers.) Incorrect. If we do not look at the IX/IY operations, you will have to agree that each Z80 opcode takes 1 (one) byte plus as many bytes as it's argument takes. The latter can be clearly seen from the program: LD HL,0053h <-- 1 byte opcode + 2 byte argument Execution time may differ (of course), but it also doesn't take too much time to deduce from the number of parenthesis and numerical arguments. Now, if you look at 80x86 architecture from the same Intel, and look at how much time ADD to AX takes in comparison to, let us say, ADD to DX, you will see what "non-orthogonal" means. : Yep, to the untrained eye they all perform the same operation. : To folks who have to worry about how many bytes are used by : each instruction and how many clocks it takes to execute : each instruction, the "LD" is a pain in the butt because it : hides these important details. See above. Both Z80 and 8080 are (generally, not counting FD/FF/ED/CB which we are not arguing about) 1-byte-per-opcode CPUs whose opcode execution times rigidly depend on the number and addressation of opcode arguments. Both these parameters are quite obvious from Z80 mnemonics. : IMHO, if you're using assembler, it's because you want to : get involved at the detailed level. Anything that hides : these details from you - like the Z80 mnemonics - is doing : you more harm than good. Anything that makes me memorize hundreds of different mnemonics will do me more harm than good by making my brain do additional useless work. ###### From: fms@cs.umd.edu (Marat Fayzullin) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 19 Nov 1998 04:21:55 GMT Organization: U of Maryland, College Park, MD 20742 Lines: 16 Message-ID: <7306d3$e61$2@cronkite.cs.umd.edu> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> NNTP-Posting-Host: nachos.cs.umd.edu X-Trace: cronkite.cs.umd.edu 911449315 14529 128.8.126.3 (19 Nov 1998 04:21:55 GMT) X-Complaints-To: abuse@cs.umd.edu NNTP-Posting-Date: 19 Nov 1998 04:21:55 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!sunqbc.risq.qc.ca!tor-nx1.netcom.ca!news.louisville.edu!uky.edu!info.usuhs.mil!cs.umd.edu!not-for-mail Charlie Gibbs (cgibbs@sky.bus.com) wrote: : Yup, someone bit. :-) But of course :) : Why "LD" instead of something that better suggests a general : move, such as "MOV"? Whenever I see "LD" I think "Load". This : isn't too appropriate for a move from a register to memory, which : is commonly referred to as a "store". "Load" is usually reserved : to mean a move in the opposite direction. Does the sentence "Load a memory cell from the register" sound like a broken English to you? "MOVE", on the other hand, is an English verb used to mean a removal of an object from location A and placing it to location B. Do any of the 8080 operations we are talking about remove anything from anywhere? ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Thu, 19 Nov 1998 13:03:08 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 63 Message-ID: <73151g$6bj@cpca3.uea.ac.uk> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <36532888.48030FCD@trailing-edge.com> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!newsfeed.cwix.com!194.72.7.126!btnet-peer!btnet!nntp.news.xara.net!xara.net!server6.netnews.ja.net!server4.netnews.ja.net!server2.netnews.ja.net!cpca3.uea.ac.uk!news Tim Shoppa wrote in message <36532888.48030FCD@trailing-edge.com>... :The above different sorts of moves are *very* different to :someone who's learned 8080A assembly language, or who has :spent years of their lives toggling programs into front panel :machines. Within any given type of move, the move is :orthogonal, and the 8080A mnemonics nicely delineate the :different classes of moves to keep clear what is possible. :For instance, you can't do a LD B,(DE) (in Z-80 style mnemonic) :on an 8080A, and you wouldn't dream of doing so in 8080A :mnemonics because such a mnemonic doesn't exist. Hmm, well 8080 has the *appearance* of being more orthagonal, but IMHO, it actually conceals far more than Z80. For example the Z80 instruction LD A,(HL) has an obvious dependency on the HL register pair. The use of M in 8080 as a psuedo-register makes that much less obvious. I don't really see any advantage in having different mnemonics for the different types of load. IT doesn't take long to learn which combinations are possible in Z80 and you have far less instruction mnemonics to remember, since every type of load uses LD. :Why should a programmer care what class of "load" they're doing? :Every byte counts, and the number of bytes and cycles it takes :to do each operation is perfectly clear in 8080A mnemonics. But it isn't exactly difficult to see which addressing modes are being used by the Z80, is it? For instance, in 8080 the MOV B,A and MOV M,A instructions appear to be the same. In reality one uses implicit addressing, the other indirect. The Z80 equivalents LD A,B and LD A,(HL) are quite obviously using different addressing modes due to the introduction of the brackets. :Yep, to the untrained eye they all perform the same operation. :To folks who have to worry about how many bytes are used by :each instruction and how many clocks it takes to execute :each instruction, the "LD" is a pain in the butt because it :hides these important details. No it doesn't. It arranges all of the data transfer operations into a single class, the LD group. The addressing modes are obvious from the parameters. Since the timing and length of the instructions is wholly dependent on the addressing mode it is quite easy to see how long, or how many bytes an instruction requires. :IMHO, if you're using assembler, it's because you want to :get involved at the detailed level. Anything that hides :these details from you - like the Z80 mnemonics - is doing :you more harm than good. So you don't want to hide the details, but you prefer an assembler to "disguise" indirect addressing via the HL pair by using a pseudo-register M? I really don't see the logic in that argument. Give me the much more straightforward and far easier to read Z80 anyday. AndyC ###### From: Dave Daniels Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 18 Nov 1998 20:34:09 GMT Organization: ArgoNet, but does not reflect its views Lines: 30 Distribution: world Message-ID: References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> <86u2zylsmb.fsf@home.com> <72s0a6$r13$1@cronkite.cs.umd.edu> Reply-To: Dave Daniels NNTP-Posting-Host: userp262.uk.uudial.com X-Newsreader: NewsAgent 0.84 for RISC OS Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!192.71.180.34!newsfeed1.swip.net!swipnet!newsfeed.ecrc.net!join.news.pipex.net!pipex!warm.news.pipex.net!bore.news.pipex.net!pipex!argonet.co.uk!argbq79 In article <72s0a6$r13$1@cronkite.cs.umd.edu>, fms@cs.umd.edu (Marat Fayzullin) wrote: > Can't say much about Altair, but Zilog Z80 CPU is an extended 8080 clone > backward compatible with Z80 at the assembly level. Zilog has added more > instructions and changed mnemonics, but the basic core of instructions > Whilst we are talking about the 8080 and Z80, does anybody have any ideas as to what the undefined 8080 opcodes did? I am refering to opcode values such as 0x08, 0x10, 0xCB, 0xDD, 0xED and so forth, the ones later used in the Z80. ISTR hearing somewhere that one of the undefined codes was a 16-bit subtract instruction, but whether this is true or not, I have no idea. Has anybody got any information on this? Dave -- ANTISPAM: Please note that the email address above is false. My correct address is: dave_danielsargonetcouk Please replace the and s with @ and . respectively when replying - Thanks! ###### Date: 19 Nov 98 10:47:09 -0800 From: "Charlie Gibbs" Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <7306d3$e61$2@cronkite.cs.umd.edu> Message-ID: <1482.627T479T6474100@sky.bus.com> Newsgroups: alt.folklore.computers Lines: 37 X-Newsreader: THOR 2.5a (Amiga;TCP/IP) NNTP-Posting-Host: news.skybus.com X-Trace: 19 Nov 1998 13:12:05 -0800, news.skybus.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!news-peer1.sprintlink.net!news-east1.sprintlink.net!news-nysernet-16.sprintlink.net!news-in-east1.sprintlink.net!news.sprintlink.net!news.westel.com!news.skybus.com!204.244.247.121 In article <7306d3$e61$2@cronkite.cs.umd.edu> fms@cs.umd.edu (Marat Fayzullin) writes: >Charlie Gibbs (cgibbs@sky.bus.com) wrote: > >: Yup, someone bit. :-) > >But of course :) > >: Why "LD" instead of something that better suggests a general >: move, such as "MOV"? Whenever I see "LD" I think "Load". This >: isn't too appropriate for a move from a register to memory, which >: is commonly referred to as a "store". "Load" is usually reserved >: to mean a move in the opposite direction. > >Does the sentence "Load a memory cell from the register" >sound like a broken English to you? Not so much broken English as improper usage. The distinction between "load" and "store" that I gave above reflects a convention much older than the Z-80. >"MOVE", on the other hand, is an English verb used to mean a removal >of an object from location A and placing it to location B. Do any of >the 8080 operations we are talking about remove anything from anywhere? No. But doesn't the word "load" also imply a removal of an object from its original location? I grant your point that in everyday English, moving (or loading) an object removes it from location A before placing it in location B. However, the common usage of these terms in computer parlance (assembly language in particular - the MS-DOS MOVE command doesn't count) implies a copy without removal from the source location. -- cgibbs@sky.bus.com (Charlie Gibbs) Remove the first period after the "at" sign to reply. ###### Date: 19 Nov 98 12:15:50 -0800 From: "Charlie Gibbs" Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <3653bf1a.51440060@news.vip.net> Message-ID: <2515.627T2530T7356187@sky.bus.com> Newsgroups: alt.folklore.computers Lines: 66 X-Newsreader: THOR 2.5a (Amiga;TCP/IP) NNTP-Posting-Host: news.skybus.com X-Trace: 19 Nov 1998 13:12:07 -0800, news.skybus.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.direct.ca!news-peer1.sprintlink.net!news-east1.sprintlink.net!news-nysernet-16.sprintlink.net!news-in-east1.sprintlink.net!news.sprintlink.net!news.westel.com!news.skybus.com!204.244.247.121 In article <3653bf1a.51440060@news.vip.net> genew@vip.net (Gene Wirchenko) writes: >"Charlie Gibbs" wrote: > >>Why "LD" instead of something that better suggests a general >>move, such as "MOV"? Whenever I see "LD" I think "Load". This >>isn't too appropriate for a move from a register to memory, which >>is commonly referred to as a "store". "Load" is usually reserved >>to mean a move in the opposite direction. > > A move? Come on! "LD" is much better because a value is being >loaded. "MOV" is inaccurate as the value is NOT being moved. It's >still at the source after the load. The same applies to "LD". If you load something on a truck, it's no longer on the loading dock. Of course, the same argument also applies to "store" - but it's still an ancient (in computer terms) convention that data is LOADed into an accumulator from memory, and STOREd from an accumulator to memory. >"COPY" is another possible, accurate opcode. True. Maybe future processor designers should consider this, if they're feeling bold enough to challenge the convention. >>>PS: Some of the most dreadful mnemonics I have seen in my life >>> were XTHL,SPHL,PCHL, and XCHG (*four* consonants in a row), >>> all from 8080. I am sure IBM/360 programmers will readily >>> come with even worse ones though. >> >>Those one _are_ a mouthful. I spell the first three letter by >>letter. The last one can be pronounced "exchange", though. > > Um, how about "ex-thil", "spill", and "pitch-el"? I didn't >spit much saying them. Hmm, I'd probably want to say "sphil", but aside from that you have a point. You can do rather a lot by strategically inserting a schwa here and there. >>Let's see, the 360 has things like MVC, MVN, and MVZ, which again >>are easier to just spell out. But it also has ZAP, which is kind > > "move-see", "move-en", and "move-zee"? Or "muvuc", "muven", and "muvz". >>of fun. Then there are the inbetween ones like BXLE. Most people >>pronounce that one "bixel", but I once heard someone pronounce it >>"boxel" and I liked it so much I adopted it. No such luck with its >>sister instruction BXH, though... > > I'd probably say "bixel" or maybe "bix-lee". That isn't from >ever using it. I've heard both pronunciations. > "bix-huh" or "bix-hi"? I've tried to imagine things like "bugzh", but usually gave up. I hardly ever used BXH anyway. :-) -- cgibbs@sky.bus.com (Charlie Gibbs) Remove the first period after the "at" sign to reply. ###### Message-ID: <36544F50.6007BBBC@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <36532888.48030FCD@trailing-edge.com> <730633$e61$1@cronkite.cs.umd.edu> <36536059.4FC4E60F@trailing-edge.com> <73202k$qjn$1@cronkite.cs.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 38 Date: Thu, 19 Nov 1998 17:03:12 -0400 NNTP-Posting-Host: 198.232.144.27 X-Trace: audrey2.cais.com 911513526 198.232.144.27 (Thu, 19 Nov 1998 17:12:06 EDT) NNTP-Posting-Date: Thu, 19 Nov 1998 17:12:06 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.direct.ca!nntp.giganews.com!nntp.primenet.com!in1.nntp.cais.net!199.0.216.204.MISMATCH!audrey2.cais.com!not-for-mail Marat Fayzullin wrote: > : This is a complete > : breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic > : is one instruction > PDP11 is a *really* bad example here. If we are to stay consistent, > DEC would be required to make up a new mnemonic for each addressation > method used by its instructions, which is not a case with PDP11 > assembly. Using your own rhetorics, this would be the only way to know > "what actually happens at the machine level". I don't object to different addressing modes usable by the same instruction. (Indeed, in 8080A mnemonics you can put "M" anywhere you can put a register operand.) What I object to are similar looking mnemonics that assemble to completely different instructions; for example, LD A,(HL) is a very different opcode (167 octal) than the opcode (012) for LD A,(BC). Then if you get into the (IX) and (IY) modes all of a sudden the opcode becomes doubled in length, despite the fact that the mnemonic syntax looks much the same as if (HL) or (BC) was used. The PDP-11's MOV mnemonic is, on the other hand, entirely orthogonal: there's a 16-bit opcode, 6 bits determine the source register and addressing mode, another 6 bits determine the destination register and addressing mode. The opcode is never suddenly lengthened by a word for certain addressing modes, and the opcode's bit positions aren't arbitrarily rearranged for certain addressing modes. Note that there are separate PDP-11 mnemonics for move-type operations that don't fit into the MOV mold; for instance, the MFPI (Move From Previous Instruction Space), MFPF (Move From Previous Data Space), MFPT (Move from Processor model Type), etc., all get their own special opcodes. This, of course, is how it should be, because these instructions don't fit the MOV model at all. Tim. (shoppa@trailing-edge.com) than LD A,(BC), which itself is ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Thu, 19 Nov 1998 18:02:41 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 68 Message-ID: <731mj4$9p1@cpca3.uea.ac.uk> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <36532888.48030FCD@trailing-edge.com> <730633$e61$1@cronkite.cs.umd.edu> <36536059.4FC4E60F@trailing-edge.com> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news-feed1.eu.concert.net!btnet-peer!btnet!server2.netnews.ja.net!cpca3.uea.ac.uk!news Tim Shoppa wrote in message <36536059.4FC4E60F@trailing-edge.com>... :Actually, it's much more complicated than just counting :parentheses and numerical arguments. When counting cycles, :you *have* to think of all the different LD forms, and their :various IX and IY prefixes, as different instructions. The :LD mnemonic form is just hiding this from you. No you don't. The length (in both bytes and cycles) can easily be deduced from the addressing modes used by the two arguments for LD. :If it's just a matter of counting parantheses, how come :LD HL,(8) takes such a substantially different amount of time :than LD (IY+08),C ? Because LD HL,(8) is using 16-bit absolute addressing wheras LD (IY+08),C is using indexed addressing. The difference is obvious and largely irrelevant in this thread anyway, given that indexed addressing simply doesn't exist on the 8080. :But with "LD" you're doing the work of remembering which LD :forms are legal and which aren't. LD A,I works, but LD B,I :doesn't. LD (HL),C works but LD (DE),C doesn't, yet LD (DE),A :does. You've got to remember all the rules for what different :real operations are possible with LD, when 8080 mnemonics do that :work for you (and more) automatically. And I would argue that :the mnemonics are easier to remember (hey, isn't that what :mnemonic is defined as?!) than seemingly arbitrary rules about :which LD combinations are legal and which aren't. But it doesn't take very long to learn which addressing modes are valid and it is certainly easier to remember than several different mnemonics for the same type of instruction. It is also much easier to read and understand Z80 (with the possible exception of the block operations) than 8080 because there are less mnemonics and less hidden information. :What I'm saying is this: The Z80 mnemonic LD isn't one instruction. :It actually assembles to one of a couple dozen different instructions, :all with radically different binary forms. This is a complete :breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic :is one instruction, and where the argument bit patterns get filled :in in a very predictable manner. Folks like me who grew up with :assemblers that directly map mnemonics to instructions like it :that way, because knowing the mnemonic tells you a lot about :what actually happens at the machine level. I feel uncomfortable :with assemblers that hide the machine level stuff from me. True to some extent although 8080 conceals certain facts about the addressing modes as well. MOV M,A takes longer (7 cycles, IIRC) than MOV B,A (4 cycles) so it hardly makes everything perfectly clear. Actually the whole business about using M instead of (HL) sucks big time, because it makes dependencies in the code less obvious to the casual observer. Of course, Z80 isn't entirely free of this type of thing but I dread to think how you would describe the dependencies of LDIR in a single instruction. :) Also the larger instruction set of the Z80 would have required even more mnemonics for a 1:1 mapping and that would have been far too many. AndyC ###### From: genew@vip.net (Gene Wirchenko) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Thu, 19 Nov 1998 19:36:01 GMT Organization: Posted via Supernews, http://www.supernews.com - Discussions start here! Lines: 119 Message-ID: <3654560b.5743505@news.vip.net> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <36532888.48030FCD@trailing-edge.com> <730633$e61$1@cronkite.cs.umd.edu> <36536059.4FC4E60F@trailing-edge.com> Reply-To: genew@vip.net NNTP-Posting-Host: 204.209.212.57 X-Trace: 911504070 A01OARAUVD439CCD1C usenet87.supernews.com X-Complaints-To: newsabuse@supernews.com X-Newsreader: Forte Free Agent 1.1/32.230 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!chippy.visi.com!news-out.visi.com!Supernews73!supernews.com!Supernews69!not-for-mail Tim Shoppa wrote: >Marat Fayzullin wrote: >> >> Tim Shoppa (shoppa@trailing-edge.com) wrote: >> : Why should a programmer care what class of "load" they're doing? >> : Every byte counts, and the number of bytes and cycles it takes >> : to do each operation is perfectly clear in 8080A mnemonics. >> : The Z80 mnemonics hide all this, making the actual operation >> : much more opaque. (I won't start complaining about all the >> : "prefix" opcodes the Z80 designers had to introduce to deal >> : with the IX and IY registers.) >> Incorrect. If we do not look at the IX/IY operations, you will >> have to agree that each Z80 opcode takes 1 (one) byte plus >> as many bytes as it's argument takes. > >Well, you're leaving out the BIT, SET, and RESET prefixes, >which can be combined with the IX and IY prefixes to create >very long "instructions", i.e. BIT 6,(IX+08) assembles to >DDCB0876, four bytes. Notice that the "08" is sort-of an >argument (it takes a byte), while the "6" isn't in the same >sense. Sure it is. It's just that only three bits are needed to encode it. If you want an example of "isn't in the same sense, look at LDA. The A register is implied. "LDA"? There's that "LD" again. >> Execution time may differ (of course), but it also doesn't take >> too much time to deduce from the number of parenthesis and >> numerical arguments. > >Actually, it's much more complicated than just counting >parentheses and numerical arguments. When counting cycles, >you *have* to think of all the different LD forms, and their >various IX and IY prefixes, as different instructions. The >LD mnemonic form is just hiding this from you. Personally, I found the 8080 numbmonics hid stuff from me. Trying to figure out the memory transfer instructions was a pain. In the Z-80 mnemonics, it all got dealt with by LD and there was no need to go flipping through the manual looking for another one that might do it. When confronted with 8080 mnemonics, I would mentally convert most to Z-80. >If it's just a matter of counting parantheses, how come >LD HL,(8) takes such a substantially different amount of time >than LD (IY+08),C ? And numerical arguments. "IY+08" is a clue. >> Now, if you look at 80x86 architecture from the same Intel, and >> look at how much time ADD to AX takes in comparison to, let us >> say, ADD to DX, you will see what "non-orthogonal" means. > >I'll agree that 80x86 mnemonics are just as bad, if not worse, >than Z80 mnemonics :-). So it's good that I never did get around to x86 Assembler? >> : IMHO, if you're using assembler, it's because you want to >> : get involved at the detailed level. Anything that hides But not too detailed or you would simply write your code in binary. >> : these details from you - like the Z80 mnemonics - is doing >> : you more harm than good. Come on! Different levels of abstraction! To me, most of the time, the non-semantic details of the instruction don't matter, but if I want to check, say, the execution time of an instruction, I can look it up and I can find the right one -- the mnemonics are NOT confusing to me. >> Anything that makes me memorize hundreds of different mnemonics >> will do me more harm than good by making my brain do additional >> useless work. > >But with "LD" you're doing the work of remembering which LD >forms are legal and which aren't. LD A,I works, but LD B,I >doesn't. LD (HL),C works but LD (DE),C doesn't, yet LD (DE),A >does. You've got to remember all the rules for what different >real operations are possible with LD, when 8080 mnemonics do that >work for you (and more) automatically. And I would argue that >the mnemonics are easier to remember (hey, isn't that what >mnemonic is defined as?!) than seemingly arbitrary rules about >which LD combinations are legal and which aren't. Six of one, half a dozen of another. It's syntactic sugar. Some of us like the white sugar and some of us like the brown sugar. I don't think that either is *inherently* better. See my sig. >What I'm saying is this: The Z80 mnemonic LD isn't one instruction. >It actually assembles to one of a couple dozen different instructions, >all with radically different binary forms. This is a complete >breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic >is one instruction, and where the argument bit patterns get filled >in in a very predictable manner. Folks like me who grew up with >assemblers that directly map mnemonics to instructions like it >that way, because knowing the mnemonic tells you a lot about >what actually happens at the machine level. I feel uncomfortable >with assemblers that hide the machine level stuff from me. Well, they all do. That was the intention. Oh, sure I know a few Z-80 opcodes: RET is C9, CALL is CD, JP is C3, the RSTs were 00ddd111, but XOR A assembles to, ah, who cares? The assembler will deal with it; that's why I'd use one. Sincerely, Gene Wircheno Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. ###### From: slanning@buphy.bu.edu (Scott Lanning) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 19 Nov 1998 20:06:41 GMT Organization: Boston Univ. Physics Lines: 16 Message-ID: <731toh$23a$1@news1.bu.edu> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <3653bf1a.51440060@news.vip.net> NNTP-Posting-Host: buphy.bu.edu X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!141.211.144.13!newsxfer3.itd.umich.edu!news.eecs.umich.edu!news.bu.edu!slanning Gene Wirchenko (genew@vip.net) wrote: :"MOV" is inaccurate as the value is NOT being moved. It's still at the :source after the load. "COPY" is another possible, accurate opcode. Last spring, I took an electronics class where I programmed an M68008 CPU using a keypad to enter hex instructions (wrote the program in assembly then, looked-up the codes). At first, I thought move.b actually moved the byte, leaving the old register blank or indeterminate; I mean, why else would they name it move?!? I ended doing something contorted, like loop while decrementing until zero and simulataneously incrementing two other registers (or something like that). Next day, the prof (Tom Hayes, excellent teacher and man) mentioned that move should probably be named copy, and I think I audibly groaned... -- Scott ###### From: fms@cs.umd.edu (Marat Fayzullin) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 19 Nov 1998 20:46:12 GMT Organization: U of Maryland, College Park, MD 20742 Lines: 34 Message-ID: <73202k$qjn$1@cronkite.cs.umd.edu> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <36532888.48030FCD@trailing-edge.com> <730633$e61$1@cronkite.cs.umd.edu> <36536059.4FC4E60F@trailing-edge.com> NNTP-Posting-Host: nachos.cs.umd.edu X-Trace: cronkite.cs.umd.edu 911508372 27255 128.8.126.3 (19 Nov 1998 20:46:12 GMT) X-Complaints-To: abuse@cs.umd.edu NNTP-Posting-Date: 19 Nov 1998 20:46:12 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!nntp.abs.net!cs.umd.edu!not-for-mail Tim Shoppa (shoppa@trailing-edge.com) wrote: : Marat Fayzullin wrote: : > Incorrect. If we do not look at the IX/IY operations, you will : > have to agree that each Z80 opcode takes 1 (one) byte plus : > as many bytes as it's argument takes. : Well, you're leaving out the BIT, SET, and RESET prefixes, : which can be combined with the IX and IY prefixes to create : very long "instructions" : If it's just a matter of counting parantheses, how come : LD HL,(8) takes such a substantially different amount of time : than LD (IY+08),C ? Read the original statement above. : > Anything that makes me memorize hundreds of different mnemonics : > will do me more harm than good by making my brain do additional : > useless work. : But with "LD" you're doing the work of remembering which LD : forms are legal and which aren't. It's ok: I just feed them to assembler as I write and eventually start to evade the non-existant ones or write macros for them. : What I'm saying is this: The Z80 mnemonic LD isn't one instruction. : It actually assembles to one of a couple dozen different instructions, : all with radically different binary forms. Which is perfectly ok with me. : This is a complete : breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic : is one instruction PDP11 is a *really* bad example here. If we are to stay consistent, DEC would be required to make up a new mnemonic for each addressation method used by its instructions, which is not a case with PDP11 assembly. Using your own rhetorics, this would be the only way to know "what actually happens at the machine level". ###### From: nailed_barnacle@junkfree.hotmail.com (barnacle) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Thu, 19 Nov 1998 21:05:46 GMT Organization: [posted via Easynet Ltd] Lines: 7 Message-ID: <73219k$2b1$1@quince.news.easynet.net> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <7306d3$e61$2@cronkite.cs.umd.edu> NNTP-Posting-Host: nbarnes.easynet.co.uk X-Trace: quince.news.easynet.net 911509620 2401 194.154.98.206 (19 Nov 1998 21:07:00 GMT) X-Complaints-To: abuse@easynet.net NNTP-Posting-Date: 19 Nov 1998 21:07:00 GMT X-Newsreader: News Xpress 2.01 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!194.186.254.21!newsfeed.gamma.ru!Gamma.RU!newsfeed.wirehub.nl!easynet-tele!easynet-apple!egbert Of course, Intel improve things no end with the x86/87 where you have 'mov' instructions for the cpu and fld/fst for the fpu...guess they couldn't make up their minds... barnacle nailed-barnacle.home.ml.org ###### From: spalding@iol.ie (Nick Spalding) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Thu, 19 Nov 1998 21:31:12 GMT Organization: Ireland On-Line Lines: 16 Message-ID: <365a8d7f.133670281@news.iol.ie> References: <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <7306d3$e61$2@cronkite.cs.umd.edu> <1482.627T479T6474100@sky.bus.com> Reply-To: spalding@iol.ie NNTP-Posting-Host: dialup-0146.dublin.iol.ie Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.451 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!iol!iol.ie!not-for-mail Charlie Gibbs wrote: > No. But doesn't the word "load" also imply a removal of an object > from its original location? I grant your point that in everyday > English, moving (or loading) an object removes it from location > A before placing it in location B. However, the common usage of > these terms in computer parlance (assembly language in particular - > the MS-DOS MOVE command doesn't count) implies a copy without removal > from the source location. In the IBM 1401 Move and Load both did a copy operation from one memory location to another (there were no programmer accessible registers) but Move only copied the data bits and Load copied the Word Marks as well. -- Nick Spalding ###### From: autismuk@aol.com (AutismUK) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Lines: 13 NNTP-Posting-Host: ladder01.news.aol.com X-Admin: news@aol.com Date: 19 Nov 1998 21:45:36 GMT References: <731mj4$9p1@cpca3.uea.ac.uk> Organization: AOL, http://www.aol.co.uk X-Newsreader: AOL Offline Reader Message-ID: <19981119164536.21562.00000110@ngol08.aol.com> Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!news-peer.gip.net!news.gsl.net!gip.net!portc01.blue.aol.com!audrey01.news.aol.com!not-for-mail In article <731mj4$9p1@cpca3.uea.ac.uk>, "Andrew Cadley" writes: >Because LD HL,(8) is using 16-bit absolute addressing wheras LD (IY+08),C is >using indexed addressing. The difference is obvious and largely irrelevant >in this thread anyway, given that indexed addressing simply doesn't exist on >the 8080. Well, actually it does.... LD A,(HL) for example. It just doesn't have offset indexed addressing. Mr NitPick (autismuk@aol.com) ###### From: genew@vip.net (Gene Wirchenko) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Fri, 20 Nov 1998 04:32:46 GMT Organization: Posted via Supernews, http://www.supernews.com - Discussions start here! Lines: 50 Message-ID: <3654c507.34159307@news.vip.net> References: <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <3653bf1a.51440060@news.vip.net> <2515.627T2530T7356187@sky.bus.com> Reply-To: genew@vip.net NNTP-Posting-Host: 204.209.212.31 X-Trace: 911536215 A01OARAUVD41FCCD1C usenet52.supernews.com X-Complaints-To: newsabuse@supernews.com X-Newsreader: Forte Free Agent 1.1/32.230 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!195.200.0.51.MISMATCH!newshub.bart.net!ayres.ftech.net!news.ftech.net!newsfeed.nacamar.de!howland.erols.net!nntp.abs.net!newsfeed-east.supernews.com!supernews.com!Supernews69!not-for-mail "Charlie Gibbs" wrote: >In article <3653bf1a.51440060@news.vip.net> genew@vip.net >(Gene Wirchenko) writes: [snip] >> Um, how about "ex-thil", "spill", and "pitch-el"? I didn't >>spit much saying them. > >Hmm, I'd probably want to say "sphil", but aside from that you >have a point. You can do rather a lot by strategically inserting >a schwa here and there. > >>>Let's see, the 360 has things like MVC, MVN, and MVZ, which again >>>are easier to just spell out. But it also has ZAP, which is kind >> >> "move-see", "move-en", and "move-zee"? > >Or "muvuc", "muven", and "muvz". > >>>of fun. Then there are the inbetween ones like BXLE. Most people >>>pronounce that one "bixel", but I once heard someone pronounce it >>>"boxel" and I liked it so much I adopted it. No such luck with its >>>sister instruction BXH, though... >> >> I'd probably say "bixel" or maybe "bix-lee". That isn't from >>ever using it. > >I've heard both pronunciations. > >> "bix-huh" or "bix-hi"? > >I've tried to imagine things like "bugzh", but usually gave up. >I hardly ever used BXH anyway. :-) I wonder how many assembler instructions are avoided because the programmer can't pronounce them. Imagine a code review: "Then there's a [XTHL]... uh ext-hell? cross thill? ex-tee-aitch-el... followed by a... how do you say it...? Um... %^&$$%%$# IT ALL! I'm replacing it all with eight-bit loads! See you tomorrow." Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. ###### Newsgroups: alt.folklore.computers From: hoh@approve.se.NO_JUNK_EMAIL (Goran Larsson) Subject: Re: opcodes for Zilog 8800/Intel 8080 Message-ID: <1998Nov20.094024.7977@lorelei.approve.se> Originator: hoh@approve.se.NO_JUNK_EMAIL (Goran Larsson) Sender: hoh@lorelei.approve.se.NO_JUNK_EMAIL (Goran Larsson) Organization: [1] + 5934 done /bin/rm -rf ~/ & X-No-Archive: yes X-Newsreader: trn 4.0-test66 (4 June 1998) References: <86yapc2lo7.fsf@home.com> <36536059.4FC4E60F@trailing-edge.com> <73202k$qjn$1@cronkite.cs.umd.edu> <36544F50.6007BBBC@trailing-edge.com> Lines: 28 Date: Fri, 20 Nov 1998 09:40:24 GMT NNTP-Posting-Host: 130.244.106.38 X-Complaints-To: news-abuse@swip.net X-Trace: nntpserver.swip.net 911555306 130.244.106.38 (Fri, 20 Nov 1998 10:48:26 MET DST) NNTP-Posting-Date: Fri, 20 Nov 1998 10:48:26 MET DST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed1.swip.net!swipnet!nntpserver.swip.net!not-for-mail In article <36544F50.6007BBBC@trailing-edge.com>, Tim Shoppa wrote: > same instruction. (Indeed, in 8080A mnemonics you can put "M" > anywhere you can put a register operand.) That is false. You can have MOV A,A and MOV A,M and MOV M,A, but you can't have MOV M,M. The bit pattern for the non existent MOV M,M is used by HALT. How quaint. > similar looking mnemonics that assemble to completely different > instructions; for example, LD A,(HL) is a very different opcode > (167 octal) than the opcode (012) for LD A,(BC). Then if you > get into the (IX) and (IY) modes all of a sudden the opcode > becomes doubled in length, despite the fact that the mnemonic > syntax looks much the same as if (HL) or (BC) was used. Everything gets much clearer if you think of DD and FD as a prefix to other opcodes. The DD prefix will replace HL in the following opcode with IX (and IX+n if (HL) is used) and FD the same for IY. The only exception is EX DE,HL as it doesn't actually swap the contents of DE and HL, it just flips a X switch it the datapath to the DE and HL registers. -- Goran Larsson hoh AT approve DOT se I was an atheist, http://home DOT swipnet DOT se/hoh/ until I found out I was God. ###### Message-ID: <36553EE0.418B32C1@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <7306d3$e61$2@cronkite.cs.umd.edu> <1482.627T479T6474100@sky.bus.com> <733tf8$1gsa$2@ausnews.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 47 Date: Fri, 20 Nov 1998 10:05:20 -0400 NNTP-Posting-Host: 198.232.144.27 X-Trace: audrey2.cais.com 911574854 198.232.144.27 (Fri, 20 Nov 1998 10:14:14 EDT) NNTP-Posting-Date: Fri, 20 Nov 1998 10:14:14 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed.wirehub.nl!howland.erols.net!news-peer1.sprintlink.net!news-in-east1.sprintlink.net!news.sprintlink.net!in1.nntp.cais.net!199.0.216.204.MISMATCH!audrey2.cais.com!not-for-mail glass2@glass2.cv.lexington.ibm.com wrote: > Of course, don't forget that with certain memory technologies that > were in use in the early days of computers (e.g., core memory) a read > of a memory location was destructive. Thus, the process of pulling a > value out of a memory location to be placed into an accumulator > resulted in the memory location being cleared. Thus, maybe "Load" was > appropriate back then. > > Of course, with any system where the designers weren't on a permanent > coffee break, the memory controller would immediately perform a write > back into the memory location just read so that a read wouldn't be > destructive. No, that's what the designers did if the *were* on a permanent coffee break. The good designers had the CPU specifiy two kinds of read cycles: 1. Read followed by memory controller write back ("DATI" in Unibus terminology). Used, for example, on a memory- to-register operation. 2. Destructive read, not followed by memory controller write back ("DATIP" in Unibus terminology) This is used for instructions where the CPU is going to immediately be writing data to the same memory location, so there's no need for the memory controller to do so. Used, for example, on an add-register-to-memory-location operation. The write-back on a mid-70's minicomputer took of order 100ns, as compared to the 300ns or read, so there was a potential 25% speedup on read-modify-write access cycles. (See, for example, any mid-to-late-70's _PDP-11 Processor Handbook_.) Admittedly, on many instruction streams the number of cycles that would be saved by read-modify-write cycles was much less than 25%. But there are inner loops of some codes - for example, matrix-vector or matrix-matrix multiply loops - where near-maximum speedups are realized. And for systems where DMA I/O was a substantial fraction of the memory bus traffic freeing up even 5-10% of the bus time can substantially improve the success of timing-critical I/O transfers. -- Tim Shoppa Email: shoppa@trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 ###### From: jmfbahciv@aol.com Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Fri, 20 Nov 98 13:28:23 GMT Organization: UltraNet Communications, Inc. Lines: 44 Message-ID: <733rv3$h9r$2@ligarius.ultra.net> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <3653bf1a.51440060@news.vip.net> <36540435.3388B69C@trailing-edge.com> NNTP-Posting-Host: d11.dial-15.mbo.ma.ultra.net X-Complaints-To: abuse@ultra.net X-Ultra-Time: 20 Nov 1998 13:48:19 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!newspeer1.nac.net!newspeer.monmouth.com!news.ultranet.com!d11 In article <36540435.3388B69C@trailing-edge.com>, Tim Shoppa wrote: >Gene Wirchenko wrote: >> You'd hate PDPs then, eh? I understand from the PDP afficionados >> (spelling?) that JUMP on PDPs doesn't jump. > >On a PDP-11 it does. You're thinking of the PDP-10, where a >JUMP without any condition codes never jumps (because the condition >is never met!) You guys are just a tad confused, I think :-). I'll give you the instruction set for the JUMP instruction as written up in our cheat sheet cards. I will capitalize the characters that are part of the instruction mneumonic. JUMP if ac }--- never Less Equal Less or Equal Always Greater Greater or Equal Not equal So if I want to jump to a location, X, when the contents of the AC are greater than or equal to zero, instruction line in the code would look like this: JUMPGE AC,X So you are correct that a JUMP AC,X would never jump (we always called them a NOOP). However, we always used JFCL for a NOOP because it was a faster instruction. A good discussion would be _why_ we used NOOPs; I don't recall ever writing a NOOP in FORTRAN. /BAH /BAH Subtract a hundred and four for e-mail. ###### From: atbowler@thinkage.on.ca (Alan Bowler) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 20 Nov 1998 18:00:22 GMT Organization: Thinkage Ltd. Lines: 23 Message-ID: <734anm$1ul$1@demon.uunet.ca> References: <36532888.48030FCD@trailing-edge.com> <730633$e61$1@cronkite.cs.umd.edu> <36536059.4FC4E60F@trailing-edge.com> NNTP-Posting-Host: 192.102.11.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.direct.ca!news.uunet.ca!atbowler In article <36536059.4FC4E60F@trailing-edge.com> Tim Shoppa writes: > >What I'm saying is this: The Z80 mnemonic LD isn't one instruction. >It actually assembles to one of a couple dozen different instructions, >all with radically different binary forms. This is a complete >breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic >is one instruction, and where the argument bit patterns get filled >in in a very predictable manner. Folks like me who grew up with >assemblers that directly map mnemonics to instructions like it >that way, because knowing the mnemonic tells you a lot about >what actually happens at the machine level. I feel uncomfortable >with assemblers that hide the machine level stuff from me. I agree. When I ported the Zed compiler to the z8000, I spent ages going over the manual trying to discover what the real instruction set was. (writing down bits patterns etc.) I eventually found a very nice classic register storage architecture that was completely hidden under the archane variations of LD in the documentation. I made up my own nmemonics using old fashioned names like load, store, load immediate etc that mapped to fixed machine opcodes, and the rest proceeded smoothly. The guy that ported TLA (The Last Assembler) used my choice of opcodes. ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 21 Nov 1998 02:19:29 GMT Message-ID: <7357vh$uiv$9@irk.zetnet.co.uk> References: <1612.626T153T6613270@sky.bus.com> NNTP-Posting-Host: man-107.dialup.zetnet.co.uk X-Trace: irk.zetnet.co.uk 911614769 31327 194.247.40.137 (21 Nov 1998 02:19:29 GMT) NNTP-Posting-Date: 21 Nov 1998 02:19:29 GMT X-Everything: Net-Tamer V 1.08X Lines: 15 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!masternews.telia.net!news-feed.inet.tele.dk!bofh.vszbr.cz!dispose.news.demon.net!demon!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-11-18 cgibbs@sky.bus.com said: :I thought of modifying my assembler (or at :least adding macros) to make it so: e.g. LD @A, instead :of INP, or LD PC, instead of JMP(*), for instance. Once :all instructions have the same op code, you can get rid of it :entirely, and write your program as just a series of operands. :-) Yes, but things like ADD get difficult. :> However, in machines where you have the PC and other important registers in the general register set, you can dispose of the JMP instructions entirely (eg. ARM) - but the assemblers seem to define those instructions anyway. (Why?) -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 21 Nov 1998 02:19:32 GMT Lines: 58 Message-ID: <7357vk$uiv$10@irk.zetnet.co.uk> References: <73151g$6bj@cpca3.uea.ac.uk> NNTP-Posting-Host: man-107.dialup.zetnet.co.uk X-Trace: irk.zetnet.co.uk 911614772 31327 194.247.40.137 (21 Nov 1998 02:19:32 GMT) NNTP-Posting-Date: 21 Nov 1998 02:19:32 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news-feed1.eu.concert.net!btnet-peer!btnet-feed2!btnet!newsfeed.icl.net!demeter.clara.net!news.clara.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-11-19 a.p.cadley@uea.ac.uk said: :Hmm, well 8080 has the *appearance* of being more orthagonal, but :IMHO, it actually conceals far more than Z80. For example the Z80 :instruction LD A,(HL) has an obvious dependency on the HL register :pair. The use of M in 8080 as a psuedo-register makes that much :less obvious. But wasn't that inherited from the 8008, where M was the *only* way of accessing something from memory? No ambiguity there, unless you were going to spend all day looking for the M register. :I don't really see any advantage in having different mnemonics for :the different types of load. IT doesn't take long to learn which :combinations are possible in Z80 and you have far less instruction :mnemonics to remember, since every type of load uses LD. Yes, but remembering gaps is always more of a hassle than remembering a few extra mnemonics with consistency through them. Adding is easier than subtracting. I'd much rather have LDI instructions dotted throughout my x86 code. (In fact, I might do an assembler that way. & NEC's V20 manual did use Z80-type mnemonics instead of Intel ones.) :But it isn't exactly difficult to see which addressing modes are :being used by the Z80, is it? For instance, in 8080 the MOV B,A and :MOV M,A instructions appear to be the same. In reality one uses :implicit addressing, the other indirect. The Z80 equivalents LD A,B :and LD A,(HL) are quite obviously using different addressing modes :due to the introduction of the brackets. Yes, but MOV A, B and LD A,(HL) makes it even clearer. It also makes the assembler much simpler to code, since you don't have to hover about trying to parse one mnemonic into several completely different instruction varieties. Forth x86 assemblers are worth looking at, to see what a mess it is (compare and contrast with, say, a 6800 assembler). :No it doesn't. It arranges all of the data transfer operations into :a single class, the LD group. The addressing modes are obvious from :the parameters. Since the timing and length of the instructions is :wholly dependent on the addressing mode it is quite easy to see how :long, or how many bytes an instruction requires. Until you have to remember that LD A,(IX) takes many more cycles and 2 bytes longer than an LD A,(HL). That's far from obvious. (You'd rather write it LD A,(IX+0)? Then why not have MOV A,D instead of LD A,D?) :So you don't want to hide the details, but you prefer an assembler :to "disguise" indirect addressing via the HL pair by using a :pseudo-register M? I really don't see the logic in that argument. Nor do I, but I don't think it's his either. These things happen somewhere along threads... -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing Net-Tamer V 1.08X - Test Drive ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 21 Nov 1998 02:19:34 GMT Message-ID: <7357vm$uiv$11@irk.zetnet.co.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> NNTP-Posting-Host: man-107.dialup.zetnet.co.uk X-Trace: irk.zetnet.co.uk 911614774 31327 194.247.40.137 (21 Nov 1998 02:19:34 GMT) NNTP-Posting-Date: 21 Nov 1998 02:19:34 GMT X-Everything: Net-Tamer V 1.08X Lines: 21 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.uk.ibm.net!ibm.net!dispose.news.demon.net!demon!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-11-19 a.p.cadley@uea.ac.uk said: :Actually the whole business about using M instead of (HL) sucks big :time, because it makes dependencies in the code less obvious to the :casual observer. Of course, Z80 isn't entirely free of this type of :thing but I dread to think how you would describe the dependencies :of LDIR in a single instruction. :) Well, at least that set of instructions is completely consistent, self-contained and sane, unlike the rest of the LD & CP groups, and streets ahead of Intel's MOVS WORD PTR [SI], WORD PTR ES:[DI] notation. Of course, LDS I, R would be even nicer... ;> Incidentally, the thing I really liked about the 6502 was that all the instructions had TLMs. For some reason I enjoyed the consistency... -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing (OK, PSH was pshing it.) ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 21 Nov 1998 02:19:36 GMT Message-ID: <7357vo$uiv$12@irk.zetnet.co.uk> References: <73202k$qjn$1@cronkite.cs.umd.edu> NNTP-Posting-Host: man-107.dialup.zetnet.co.uk X-Trace: irk.zetnet.co.uk 911614776 31327 194.247.40.137 (21 Nov 1998 02:19:36 GMT) NNTP-Posting-Date: 21 Nov 1998 02:19:36 GMT X-Everything: Net-Tamer V 1.08X Lines: 19 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news-feed1.eu.concert.net!btnet-peer!btnet!dispose.news.demon.net!demon!ayres.ftech.net!news.ftech.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-11-19 fms@cs.umd.edu(MaratFayzullin) said: :PDP11 is a *really* bad example here. If we are to stay consistent, :DEC would be required to make up a new mnemonic for each :addressation method used by its instructions, which is not a case :with PDP11 assembly. Using your own rhetorics, this would be the :only way to know "what actually happens at the machine level". No they wouldn't. The opcode bits don't change, only the bits which determine the addressing mode. They're in a fixed place anyway, so that isn't a problem. Encoding is much more convoluted in the Z80, and you probably do want a new mnemonic for each case, because there's no consistent (a) set of addressing modes, (b) place to set them. Perhaps we can all just agree that the Z80's instruction set was a right mess because of the need to retain compatibility with the 8080... -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 21 Nov 1998 02:19:38 GMT Message-ID: <7357vq$uiv$13@irk.zetnet.co.uk> References: <73219k$2b1$1@quince.news.easynet.net> NNTP-Posting-Host: man-107.dialup.zetnet.co.uk X-Trace: irk.zetnet.co.uk 911614778 31327 194.247.40.137 (21 Nov 1998 02:19:38 GMT) NNTP-Posting-Date: 21 Nov 1998 02:19:38 GMT X-Everything: Net-Tamer V 1.08X Lines: 15 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.uk.ibm.net!ibm.net!news-lond.gip.net!news.gsl.net!gip.net!dispose.news.demon.net!demon!ayres.ftech.net!news.ftech.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-11-19 nailed_barnacle@junkfree.hotmail.com(barnacle) said: :Of course, Intel improve things no end with the x86/87 where you :have 'mov' instructions for the cpu and fld/fst for the fpu...guess :they couldn't make up their minds... Oh, yes, the x86. With its multiple ways of encoding instructions, some of which are shorter and execute more quickly than others (and sometimes it's the long variants which are the quick variants!), you gotta love that one. (Oh, and MOV gt used for everything, whether or not it was appropriate.) -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: arargh@arargh.com (Arargh!) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Sat, 21 Nov 1998 03:15:09 GMT Organization: Arargh!! Lines: 15 Message-ID: <365a25ed.87311472@news.mcs.net> References: <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <7306d3$e61$2@cronkite.cs.umd.edu> <1482.627T479T6474100@sky.bus.com> <365a8d7f.133670281@news.iol.ie> Reply-To: arargh@arargh.com NNTP-Posting-Host: jwright.pr.mcs.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.452 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!209.244.253.199!newsfeed.xcom.net!cam-news-hub1.bbnplanet.com!chicago-news-feed1.bbnplanet.com!news.gtei.net!news.mcs.net!ddsw1!news.mcs.net!not-for-mail On Thu, 19 Nov 1998 21:31:12 GMT, spalding@iol.ie (Nick Spalding) wrote: >Charlie Gibbs wrote: > >In the IBM 1401 Move and Load both did a copy operation from one >memory location to another (there were no programmer accessible >registers) but Move only copied the data bits and Load copied the Word >Marks as well. Sure there were, if you had paid for the advanced programming feature. They just happened to be in memory, but were used as registers. arargh ###### From: fleetvis@ricochet.net (phil) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Sat, 21 Nov 1998 11:21:08 GMT Organization: Posted via Supernews, http://www.supernews.com - Discussions start here! Lines: 37 Message-ID: <3652857b.14437830@news.ricochet.net> References: <86yapc2lo7.fsf@home.com> <72pd3r$np0$1@cronkite.cs.umd.edu> <86r9v3fva3.fsf@home.com> <36560fa4.14625700@news.inetnebr.com> <86u2zylsmb.fsf@home.com> NNTP-Posting-Host: 204.179.134.61 X-Trace: 911647139 F7W8ZAFJM863DCCB3C usenet87.supernews.com X-Complaints-To: newsabuse@supernews.com X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.berkeley.edu!Supernews73!supernews.com!Supernews69!not-for-mail On 17 Nov 1998 16:29:00 -0800, Eric Smith wrote: >skritch@home.com writes: >> But I thought the Altair 8800 used a Zilog chip. > >Nope. It used the good 'ol 8080. The Zilog chip wasn't even announced >until more than a year after the Altair 8800 shipped. > >The Z-80 is nowhere near pin-compatible with the 8080. The 8080 requires >a two-phase non-overlapping clock at MOS levels, and requires some external >logic to decode the bus status. Intel offered support chips for clock >generation and bus interfacing, but AFAIK the Altair did not use them, >probably because they were expensive. The Z-80 was much easier to design >with, because it only required a single-phase clock (almost but not quite >TTL compatible), and had internal bus signal decoding. Didn't the Z80 also offer some decent support for refreshing dynamic ram? >Software-wise, the Z-80 is mostly upward compatible from the 8080. I've heard >that there was a change in how one of the flag bits was affected by one >instruction, but I'm not sure if that is true. Zilog adopted a different (and >more logical) set of mnemonics, possibly because Intel claimed that the 8080 >mnemonics were copyrighted. However, the object code was identical. The big attraction of the 8080 mnemonics is that you can write haikus using them and the result may actually assemble (with appropriate comment lines). The Z80 mnemonics were far too logical. phil. lxi h,99 push l pop h lxi h,99 ret ;all is the same ###### From: jmfbahciv@aol.com Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Sat, 21 Nov 98 12:47:23 GMT Organization: UltraNet Communications, Inc. Lines: 17 Message-ID: <736duf$i5u$2@ligarius.ultra.net> References: <86yapc2lo7.fsf@home.com> <86u2zylsmb.fsf@home.com> <3651998E.8F63F49F@jkmicro.com> <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <3653bf1a.51440060@news.vip.net> <36540435.3388B69C@trailing-edge.com> <733rv3$h9r$2@ligarius.ultra.net> <36553421.3B72D7A8@trailing-edge.com> NNTP-Posting-Host: d11.dial-11.mbo.ma.ultra.net X-Complaints-To: abuse@ultra.net X-Ultra-Time: 21 Nov 1998 13:07:27 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!news-raspail.gip.net!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.cwix.com!209.244.253.199!newsfeed.xcom.net!news.ultranet.com!d11 In article <36553421.3B72D7A8@trailing-edge.com>, Tim Shoppa wrote: >jmfbahciv@aol.com wrote: >> A good discussion would be _why_ we used NOOPs; I don't recall >> ever writing a NOOP in FORTRAN. > >Did you ever use CONTINUE ? (Or do you not count CONTINUE >as a NOOP ?) Actually no. I always used a CONTINUE statement to close a DO loop. I realize it wasn't necessary at the time but became more so as we transported our programs to other manufacturer's compilers. /BAH Subtract a hundred and four for e-mail. ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Sun, 22 Nov 1998 10:31:53 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 18 Message-ID: <738p9u$95h@cpca3.uea.ac.uk> References: <1612.626T153T6613270@sky.bus.com> <7357vh$uiv$9@irk.zetnet.co.uk> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!nntp.news.xara.net!xara.net!server6.netnews.ja.net!server4.netnews.ja.net!server2.netnews.ja.net!cpca3.uea.ac.uk!news lisard@zetnet.co.uk wrote in message <7357vh$uiv$9@irk.zetnet.co.uk>... :Yes, but things like ADD get difficult. :> However, in machines where :you have the PC and other important registers in the general register :set, you can dispose of the JMP instructions entirely (eg. ARM) - but :the assemblers seem to define those instructions anyway. (Why?) I believe the word you're looking for is readability. It makes far more sense to have a JMP rather than an LD PC type instruction. In much the same way that my Z80 assembler supports LD HL,BC as a replacement for LD H,B; LD L,C or EX HL,DE for EX DE,HL. AndyC ###### Newsgroups: alt.folklore.computers Date: Sun, 22 Nov 1998 21:45:35 +0100 Message-ID: From: peterk@combo.ganesha.com (Dr. Peter Kittel) Subject: Re: opcodes for Zilog 8800/Intel 8080 Reply-To: peterk @ combo.ganesha.com References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> X-Newsreader: rn7.bas Lines: 21 Organization: Private Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news-feed.inet.tele.dk!bofh.vszbr.cz!nntp.news.xara.net!xara.net!newsfeed.ecrc.net!blackbush.xlink.net!ganesha.ganesha.com!shorter!combo.ganesha.com!peterk In article <7357vm$uiv$11@irk.zetnet.co.uk> lisard@zetnet.co.uk writes: > >Well, at least that set of instructions is completely consistent, >self-contained and sane, unlike the rest of the LD & CP groups, and >streets ahead of Intel's MOVS WORD PTR [SI], WORD PTR ES:[DI] notation. Yes, the Intel "MOV to, from" is just so illogical, it hurts. The Z80 repaired this by rewording it to "LD" far enough that I could stand it. >Incidentally, the thing I really liked about >the 6502 was that all the instructions had TLMs. For some reason I >enjoyed the consistency... Fully agreed. I learnt the 6502 shortly after the 8085, and practically fell in love immediately. This consistency, these neatly equally sized mnemonics, this (in comparison) orthogonal command set, I like it much better. -- Best Regards, Dr. Peter Kittel // E-Mail: Private Site in Frankfurt, Germany \X/ peterk @ combo.ganesha.com ###### Message-ID: <36593972.6B9C865F@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 21 Date: Mon, 23 Nov 1998 10:31:14 -0400 NNTP-Posting-Host: 198.232.144.27 X-Trace: audrey2.cais.com 911835609 198.232.144.27 (Mon, 23 Nov 1998 10:40:09 EDT) NNTP-Posting-Date: Mon, 23 Nov 1998 10:40:09 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!news-peer1.sprintlink.net!news-in-east1.sprintlink.net!news.sprintlink.net!in1.nntp.cais.net!199.0.216.204.MISMATCH!audrey2.cais.com!not-for-mail Dr. Peter Kittel wrote: > Fully agreed. I learnt the 6502 shortly after the 8085, and practically > fell in love immediately. This consistency, these neatly equally sized > mnemonics, this (in comparison) orthogonal command set, I like it much > better. 6502? Orthogonal command set? Surely you're joking! Maybe you mean that wherever there's an "A" in a mnemonic, you can almost always only use A, wherever there's a "X" in an mnemonic, you can almost always only use X, and wherever there's a "Y" in an instruction, you can almost always only use Y. Maybe you're referring to the 255 registers that MOS Technology called "zero page" :-) ? I will agree that the 6502 is a nice microprocessor to program at the machine code level. And it'd beat the pants off a Z80 clocked several times faster on most anything. Tim. (shoppa@trailing-edge.com) ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 23 Nov 1998 13:35:06 GMT Organization: Daedalus Consulting Lines: 19 Message-ID: <73boaa$o1a$1@news.wlg.netlink.net.nz> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> NNTP-Posting-Host: toyunix.zl2tnm.gen.nz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!203.97.37.7!newsfeed.clear.net.nz!news.wlg.netlink.net.nz!don In article , Dr. Peter Kittel wrote: >Fully agreed. I learnt the 6502 shortly after the 8085, and practically >fell in love immediately. This consistency, these neatly equally sized >mnemonics, this (in comparison) orthogonal command set, I like it much >better. Orthogonal? 6502? Huh? The 6502 I grew up with couldn't put an index register on the stack, could transfer between X or Y and A, but not between X & Y, had one kind of indexing that could only be done using X and another that could only be done with Y, and so-on. Still, it might have been a finicky damn thing, but it ran like a scalded cat and that's what mattered. 8-) -- Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724 ###### From: autismuk@aol.com (AutismUK) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Lines: 19 NNTP-Posting-Host: ladder03.news.aol.com X-Admin: news@aol.com Date: 23 Nov 1998 16:13:52 GMT References: <36593972.6B9C865F@trailing-edge.com> Organization: AOL, http://www.aol.co.uk X-Newsreader: AOL Offline Reader Message-ID: <19981123111352.26663.00000998@ngol03.aol.com> Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.cwix.com!152.163.199.19!portc03.blue.aol.com!audrey03.news.aol.com!not-for-mail In article <36593972.6B9C865F@trailing-edge.com>, Tim Shoppa writes: >6502? Orthogonal command set? Surely you're joking! The design is much more orthogonal than it looks ; it looks messy because many opcode tables include the non-std instructions. In terms of emulating the functionality by code generation of repeated opcode types almost everything works except the logically impossible (store immediate) and things like INX. But the LDA group, the INC group, the ROL group the branches and the flag instructions follow a fairly regular pattern. Compared to an ARM or sim it isn't very orthogonal tho' ###### From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 23 Nov 1998 17:39:29 GMT Organization: Cal Berkeley-- Space Sciences Lab Lines: 33 Message-ID: <73c6kh$ptv$1@agate.berkeley.edu> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> NNTP-Posting-Host: islay.ssl.berkeley.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!agate!islay.ssl.berkeley.edu!korpela In article <36593972.6B9C865F@trailing-edge.com>, Tim Shoppa wrote: >I will agree that the 6502 is a nice microprocessor to program >at the machine code level. And it'd beat the pants off a Z80 >clocked several times faster on most anything. Ahhh, the myth of the "fast" 6502 rears its (ugly) head again. The reason that this was the case is that the clock speeds were not directly comparably because the interface between the clock and the chip internals was different. In a comparison to recent Intel processors (to give the newbies a reference point), I'd say that the Z80 to a 66 MHz 486 as the 6502 is to a 66 MHz 486 DX2 processor. Externally, the DX2 is clocked at 33 MHz, so it looks like it does twices as much per (external) clock cycle. That does NOT make it a faster or more efficient processor. The important thing is that when viewed contemporaneously, at the available clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by a miniscule margin. When 4 MHz Z80's were the norm, the 6502 was still limited to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as many clock cycles to execute an instruction. I've often felt that this berating Z80 performance was precipitated by Microsoft SoftCards showing up in Apple ][s. The design sucked. Fifty percent of the memory bandwidth was still given to the 6502, resulting in a 2 MHz Z80 operating at an effective 1 MHz. Of course Apple ][ owners were going think the Z80 was slow, because the one they had access to was running a 1/4 the speed of a typical Z80 system. Eric -- Eric Korpela | An object at rest can never be korpela@ssl.berkeley.edu | stopped. Click for home page. ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 23 Nov 1998 23:22:23 +0100 Organization: My own Private Self Lines: 55 Sender: neil@chonsp.franklin.ch Message-ID: References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> X-Newsreader: Gnus v5.3/Emacs 19.34 korpela@islay.ssl.berkeley.edu (Eric J. Korpela) writes: > > Tim Shoppa wrote: > >at the machine code level. And it'd beat the pants off a Z80 > >clocked several times faster on most anything. > > Ahhh, the myth of the "fast" 6502 rears its (ugly) head again. The > reason that this was the case is that the clock speeds were not directly > comparably because the interface between the clock and the chip internals Thanks. > was different. In a comparison to recent Intel processors (to give the > newbies a reference point), I'd say that the Z80 to a 66 MHz 486 as > the 6502 is to a 66 MHz 486 DX2 processor. Externally, the DX2 is > clocked at 33 MHz, so it looks like it does twices as much per (external) Replace that with DX/4 (or DX/5 as DX/4 is actually an DX/3). The 8080 and Z80 used 4 clocks per memory cycle. While the 6800, 6809 and 6502 used one clock per memory cycle. Generally 4MHz *80 were the same speed as 1MHz 6*0*. The *80 started though at 2.5MHZ and went to 8MHZ. The 6*0* started at 1MHz and went to 4MHz. But 4 and 1 were the widest spread versions. > The important thing is that when viewed contemporaneously, at the available > clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by > a miniscule margin. As minuscle as zero, IMHO. I used both, never noticed any difference. I did prefer the 6809 instruction set the most. That 4 byte Forth interpreter was nifty. Forth ran at 2/3 assembly speed. > When 4 MHz Z80's were the norm, the 6502 was still limited > to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as > many clock cycles to execute an instruction. 4 times as many. > I've often felt that this berating Z80 performance was precipitated by > Microsoft SoftCards showing up in Apple ][s. The design sucked. Fifty Is anyone surprised? -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Mon, 23 Nov 1998 21:11:25 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 34 Message-ID: <73cj53$b4e@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!howland.erols.net!newspeer.monmouth.com!rill.news.pipex.net!pipex!server1.netnews.ja.net!cpca3.uea.ac.uk!news Eric J. Korpela wrote in message <73c6kh$ptv$1@agate.berkeley.edu>... :In article <36593972.6B9C865F@trailing-edge.com>, :Tim Shoppa wrote: :The important thing is that when viewed contemporaneously, at the available :clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by :a miniscule margin. When 4 MHz Z80's were the norm, the 6502 was still limited :to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as :many clock cycles to execute an instruction. Very true. Although there are of course examples where the 6502 can out perform the Z80, but not as many. :I've often felt that this berating Z80 performance was precipitated by :Microsoft SoftCards showing up in Apple ][s. The design sucked. Fifty :percent of the memory bandwidth was still given to the 6502, resulting in :a 2 MHz Z80 operating at an effective 1 MHz. Of course Apple ][ owners were :going think the Z80 was slow, because the one they had access to was running :a 1/4 the speed of a typical Z80 system. The Commodore 128 was another example of this. In order to operate correctly with the VIC video chip both the 6502 and Z80 were limited to a 2Mhz clock rate. Effectively crippling the Z80 while allowing the 6502 to shine. AndyC ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Tue, 24 Nov 1998 01:00:16 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 56 Message-ID: <73d0i7$cg9@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!newsfeed.cwix.com!158.43.192.17!rill.news.pipex.net!pipex!server1.netnews.ja.net!cpca3.uea.ac.uk!news Neil Franklin wrote in message ... :korpela@islay.ssl.berkeley.edu (Eric J. Korpela) writes: :> The important thing is that when viewed contemporaneously, at the available :> clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by :> a miniscule margin. : :As minuscle as zero, IMHO. I used both, never noticed any difference. I :did prefer the 6809 instruction set the most. That 4 byte Forth :interpreter was nifty. Forth ran at 2/3 assembly speed. Consider the following code fragment in Z80 to fill from 1000h to 10FFh with 44h (an example I cheekily swiped from a recent flamewar) :-) LD HL,1000h LD DE,1001h LD BC,255 LD (HL),44h LDIR which takes 5390 cycles. Or in 6502... LDA #$44 (2 Cycles) LDX #$00 (2 Cycles) -loop STA $1000,X (5 Cycles) DEX (decrement X-register, 2 Cycles) BNE loop (Branch if not equal Zero, 2 Cycles) Which is 2306 cycles. At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502 routine. There is even a Z80 stack based version which is capable of doing it in LESS CYCLES than the 6502 version. This is a classic example of where the Z80 is *significantly* faster. :> When 4 MHz Z80's were the norm, the 6502 was still limited :> to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as :> many clock cycles to execute an instruction. : :4 times as many. Nope, it's about 3:1. This discussion has come up many, *many* times between comp.sys.sinclair and comp.sys.cbm, with the overall result that, on average, the Z80 will be faster. AndyC ###### From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 24 Nov 1998 01:21:08 GMT Organization: Cal Berkeley-- Space Sciences Lab Lines: 68 Message-ID: <73d1m4$g6q$1@agate.berkeley.edu> References: <731mj4$9p1@cpca3.uea.ac.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> NNTP-Posting-Host: islay.ssl.berkeley.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news.pbi.net!131.119.28.147!su-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.berkeley.edu!agate!islay.ssl.berkeley.edu!korpela In article , Neil Franklin wrote: > >> When 4 MHz Z80's were the norm, the 6502 was still limited >> to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as >> many clock cycles to execute an instruction. > >4 times as many. Well, of course, this depends upon the instruction. For example, (I may have the addressing syntax wrong on the 6502. And of course many are not exact equivalents.) 6502 Z80 instruction clocks instruction clocks ratio LDA $NNNN 4 LD A,(NNNN) 13 3.25 In general, the ratio for instructions which access memory is closer to 3 than to two. For instructions that don't access memory (for example register increments) the ratio is closer to two. And, of course for adding two registers together, well, the 6502 can't do that. Given two 16 bit pointers to 16 bit numbers on the stack add them and return the result on the stack and the original numbers unchanged. I'll pretty much guarantee that the Z80 will run in less than 4 times the clock cycles. POP HL ; 10 POP BC ; 10 LD A,(BC) ; 7 ADD A,(HL) ; 7 LD E,A ; 4 INC BC ; 6 INC HL ; 6 LD A,(BC) ; 7 ADD A,(HL) ; 7 LD D,A ; 7 PUSH DE ; 11 RET ; 10 Total 89 cycles I don't remember my 6502 very well. As a handicap, I'll let the operands be passed in zero page locations $4A,B and $4C,D and the result to be on the stack in the wrong (IMHO) byte order. LDY #0 ; 2 CLC ; 2 LDA ($4A),Y ; 5 ADC ($4C),Y ; 5 PHA ; 3 INY ; 2 LDA ($4A),Y ; 5 ADC ($4C),Y ; 5 PHA ; 3 RTS ; 6 Total 38 cycles If I chose the wrong indirect addressing mode, you can add another 4 cycles to that. Both of these are, of course, unoptimized. I'm sure a 6502 programmer could shave off 25% in cycles, but I'm just as sure that a Z80 programmer could shave off as many. The ratio in this case is 2.3:1. Eric -- Eric Korpela | An object at rest can never be korpela@ssl.berkeley.edu | stopped. Click for home page. ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 24 Nov 1998 11:16:57 GMT Organization: Daedalus Consulting Lines: 36 Message-ID: <73e4j9$ssh$1@news.wlg.netlink.net.nz> References: <731mj4$9p1@cpca3.uea.ac.uk> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> NNTP-Posting-Host: toyunix.zl2tnm.gen.nz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!203.97.37.7!newsfeed.clear.net.nz!news.wlg.netlink.net.nz!don In article <73d0i7$cg9@cpca3.uea.ac.uk>, Andrew Cadley wrote: >Consider the following code fragment in Z80 to fill from 1000h to 10FFh with >44h (an example I cheekily swiped from a recent flamewar) :-) > >LD HL,1000h >LD DE,1001h >LD BC,255 >LD (HL),44h >LDIR ^^^^ You're cheating. Much of the reason the 6502 is fast is because it has a primitive pipeline, which the Z80 lacks, thus the overhead of executing each instruction is much lower, hence less clock cycles to acomplish a given number of instructions. The above executes eleven opcode/operand fetches and five instruction decodes, whereas your 6502 example executes 1,540 opcode/operand fetches and 770 instruction decodes. Apples to apples comparison? I don't *think* so. Not every operation is amenable to LDIR. Strange but true. (Admittedly, LDIR & friends were a pretty major improvement on the 8080, except that to maintain 8080 combatibility, hardly any CP/M code used it...) >At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502 My cheap off-the-shelf 6502 based box ran at 2MHz. Contemporary Z80 based boxen couldn't catch it. Even 1MHz 6502s still *felt* faster than anything I ever used with a Z80 in it. -- Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724 ###### From: Kevin Connolly Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Tue, 24 Nov 1998 12:59:09 +0000 Organization: Alcatel Ireland Lines: 25 Message-ID: <365AAD9D.415C@ansf.alcatel.NOSPAM.fr> References: <731mj4$9p1@cpca3.uea.ac.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> <73d1m4$g6q$1@agate.berkeley.edu> NNTP-Posting-Host: irlp9402.ck.cit.alcatel.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.04 (WinNT; I) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-lond.gip.net!news.gsl.net!gip.net!news.alcatel.fr!usenet Eric J. Korpela wrote: > > In article , > Neil Franklin wrote: > > > >> When 4 MHz Z80's were the norm, the 6502 was still limited > >> to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as > >> many clock cycles to execute an instruction. > > > >4 times as many. > I seem to recall the SY6502A being available at the same time as the 4MHz Z80 and IIRC it ran at 2.5MHz The H/W designs were cleaner too and I often had two processors sharing the same RAM on the same address and data buses, one using the bus when PhiClock was high and one when it was low. -- Remove the NOSPAM from the reply address Kevin Connolly, EI4ANB ROT13: xriva.pbaabyyl@nafs.nypngry.se ICBM: 51 40.2'N 08 29.7'W ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Tue, 24 Nov 1998 13:54:04 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 64 Message-ID: <73edt0$kuc@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> <73e4j9$ssh$1@news.wlg.netlink.net.nz> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!news.maxwell.syr.edu!rill.news.pipex.net!pipex!server1.netnews.ja.net!cpca3.uea.ac.uk!news Don Stokes wrote in message <73e4j9$ssh$1@news.wlg.netlink.net.nz>... :In article <73d0i7$cg9@cpca3.uea.ac.uk>, :Andrew Cadley wrote: :>Consider the following code fragment in Z80 to fill from 1000h to 10FFh with :>44h (an example I cheekily swiped from a recent flamewar) :-) :>LDIR : ^^^^ : :You're cheating. Not really. You can do it *much* faster on the Z80 with the following code: LD SP,1100h 10 cycles LD HL,0 10 LD B,128 7 loop PUSH HL 11 DJNZ loop 13/8 Which is only 3094 cycles and isn't using the LDIR instruction. Even a 2Mhz 6502 can't outperform that. Unrolling the loop even a little bit, as I said before, can actually take it down to less cycles than the equivalent 6502. In case you were wondering, the original problem was suggested by a 6502 advocate... :Much of the reason the 6502 is fast is because it has a primitive :pipeline, which the Z80 lacks, thus the overhead of executing each :instruction is much lower, hence less clock cycles to acomplish a given :number of instructions. The above executes eleven opcode/operand :fetches and five instruction decodes, whereas your 6502 example executes :1,540 opcode/operand fetches and 770 instruction decodes. Wrong, wrong, absolutely brimming over with wrongability. The Z80 LDIR version executes no less than 521 operand/opcode fetches and 514 instruction decodes. The stack based version is 392 operand/opcode fetches and 259 instruction decodes. The thing is, it can be difficult to find like for like examples because the Z80s larger register and instruction set generally require less instructions for similar operations. :Not every operation is amenable to LDIR. Strange but true. True, but LDIR is not the most effcient instruction in the Z80 by a long shot. :>At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502 : :My cheap off-the-shelf 6502 based box ran at 2MHz. Contemporary Z80 :based boxen couldn't catch it. Even 1MHz 6502s still *felt* faster than :anything I ever used with a Z80 in it. 6502 may have *felt* faster, but Z80 *was* faster. AndyC ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 24 Nov 1998 23:56:49 +0100 Organization: My own Private Self Lines: 90 Sender: neil@chonsp.franklin.ch Message-ID: References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 "Andrew Cadley" writes: > > Neil Franklin wrote in message ... > : > :As minuscle as zero, IMHO. I used both, never noticed any difference. I > > Consider the following code fragment in Z80 to fill from 1000h to 10FFh with > 44h (an example I cheekily swiped from a recent flamewar) :-) > > LDIR > which takes 5390 cycles. According to this list here (Rodney Zaks) the LDIR will use 256 times 21 cycles. Seems to be right. > Or in 6502... > > -loop STA $1000,X (5 Cycles) > DEX (decrement X-register, 2 Cycles) > BNE loop (Branch if not equal Zero, 2 Cycles) > Which is 2306 cycles. Here I dispute the cycle numbers. IIRC (from reading a borrowed MOS Technology manual over 10 years ago) STA $aabb,X has 4/5 cycles depending on bb+X carrying over*. In this example 00+X you actually never have an carry. So ca 2050 cycles. * it actually outputs the 256 too low address, forces R/W pin to R and then throws away the input! The 6502 is an true 8bit processor, no 16bit address calculations. The DEX I am not sure of. Could also be 1 cycle (fetch next instruction while doing the DEXing). So ev 1800 cycles. BNE is 2/3 depending on where in memory the code is (again carry over). > At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502 So we may already be down to 1.5. And then there is the question of the LDI/D*. It only works if it is applicable. Special purpose hardware usually beats software if it can be used. > routine. There is even a Z80 stack based version which is capable of doing > it in LESS CYCLES than the 6502 version. No re-reading the data (as the LDIR does) and 2 bytes per PUSH. Very neat hack, but also a very special case, not representative. Also requires you to DI/EI to missuse SP. The OS may not allow this. > This is a classic example of where > the Z80 is *significantly* faster. Classic (= representative) example? More a special case. Loops and indirect addressing are generally the weak points on the 6502. Try some code that does lots of direct accesses to random variables in RAM. Thats difficult to write short benchmarks for, but that is where the 6502 runs good. Take an realistic (from user standpoint) job such as Basic interpreter doing an print "Hello, world". For that the Z80-4 = 6502-1 was a good approximation. But perhaps all the Z80s around here were slow ones (they often used an extra wait state because 250ns was too little for DRAM, while the 500ns on the 6502 never required that). > Nope, it's about 3:1. This discussion has come up many, *many* times between > comp.sys.sinclair and comp.sys.cbm, with the overall result that, on > average, the Z80 will be faster. CBMs (at least the wide spread C64) had an 40% cycle loss (= they were running at effective 0.6MHz) due to the video chips wanting to get at 80bytes of video data for each screen line. Sinclairs did not. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 25 Nov 1998 00:18:13 +0100 Organization: My own Private Self Lines: 57 Sender: neil@chonsp.franklin.ch Message-ID: References: <731mj4$9p1@cpca3.uea.ac.uk> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> <73e4j9$ssh$1@news.wlg.netlink.net.nz> <73edt0$kuc@cpca3.uea.ac.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 "Andrew Cadley" writes: > > Not really. You can do it *much* faster on the Z80 with the following code: > > loop PUSH HL 11 > DJNZ loop 13/8 That certainly is neat. Just hope the stack is not needed for interrupts. > Which is only 3094 cycles and isn't using the LDIR instruction. Even a 2Mhz > 6502 can't outperform that. But that is really special case. Not average code, which is what the user waiting in front of the machine sees. > Unrolling the loop even a little bit, as I said > before, can actually take it down to less cycles than the equivalent 6502. Hmm, I doubt that. You can reduce the DJNZes with unrolling. But the 6502 can reduce the DEXes* and BNEs with unrolling. * Use the STAs with different base adresses: lda #$44 ldx #$80 loop dex sta $1000,X ; doesn't change flags from dex sta $1080,X bne loop > The thing is, it can be difficult to find like for like examples because the > Z80s larger register and instruction set generally require less instructions > for similar operations. And that os why examples that use many random memory accesses foul up the Z80 by killing its register advantage. Initialisation loops are fast, but actual programs spend time doing other things. > :>At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502 > :My cheap off-the-shelf 6502 based box ran at 2MHz. Contemporary Z80 > :based boxen couldn't catch it. Even 1MHz 6502s still *felt* faster than > :anything I ever used with a Z80 in it. > > 6502 may have *felt* faster, but Z80 *was* faster. In loop benchmarks, not on user code. At least none I ever saw. Of course my 1.9MHz 6809 ran rings around both of them :-). -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Tue, 24 Nov 1998 16:31:58 GMT Organization: Videotron Communications Ltd. Lines: 35 Message-ID: <365addce.2462530@news.prosurfr.com> References: <863e7ib7da.fsf@home.com> <72tm5g$3vd$1@news.wlg.netlink.net.nz> <1612.626T153T6613270@sky.bus.com> <72viq9$g90$1@cronkite.cs.umd.edu> <3843.626T2705T10915530@sky.bus.com> <3653bf1a.51440060@news.vip.net> <2515.627T2530T7356187@sky.bus.com> <3654c507.34159307@news.vip.net> NNTP-Posting-Host: c9169-002.prosurfr.com X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.direct.ca!news.insinc.net!stimpy.cal.sfl.net!news.videotron.ab.ca!not-for-mail Someone posted: >>>>Let's see, the 360 has things like MVC, MVN, and MVZ, which again >>>>are easier to just spell out. But it also has ZAP, which is kind >>>>of fun. Then there are the inbetween ones like BXLE. Most people >>>>pronounce that one "bixel", but I once heard someone pronounce it >>>>"boxel" and I liked it so much I adopted it. No such luck with its >>>>sister instruction BXH, though... Ah, yes. MVC: Move Character - for copying a string of bytes from one location to another. MVN, MVZ: Move Numeric, Move Zone: for overlaying the high or low nibbles of a series of bytes, useful in converting from packed decimal to character form. ZAP: Zero and Add Packed: the equivalent of a load instruction for packed decimal. BXLE, BXH: Branch on Index Low or Equal, Branch on Index High: these instructions were used at the end of DO-loops. Despite their names, therefore, these were all fairly sensible computer instructions, doing perfectly prosaic things. The 360 used A for Add, and AH for Add Halfword (16-bit add), and so the Zilog Z-80 mnemonics were somewhat inspired by the 360, while the original 8080 mnemonics were more along the lines of the mnemonics used in the 7090 (and the PDP-8, and the Honeywell 316, and virtually all the pre-360 architectures). John Savard http://www.freenet.edmonton.ab.ca/~jsavard/index.html ###### From: fms@cs.umd.edu (Marat Fayzullin) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 24 Nov 1998 16:55:32 GMT Organization: U of Maryland, College Park, MD 20742 Lines: 6 Message-ID: <73eoe4$9tn$1@cronkite.cs.umd.edu> References: <731mj4$9p1@cpca3.uea.ac.uk> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> <73e4j9$ssh$1@news.wlg.netlink.net.nz> <73edt0$kuc@cpca3.uea.ac.uk> NNTP-Posting-Host: nachos.cs.umd.edu X-Trace: cronkite.cs.umd.edu 911926532 10167 128.8.126.3 (24 Nov 1998 16:55:32 GMT) X-Complaints-To: abuse@cs.umd.edu NNTP-Posting-Date: 24 Nov 1998 16:55:32 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed1.swip.net!swipnet!nntp.abs.net!feeder.qis.net!news.umbc.edu!cs.umd.edu!not-for-mail Andrew Cadley (a.p.cadley@uea.ac.uk) wrote: : 6502 may have *felt* faster, but Z80 *was* faster. Who says "was"? Low-end TI graphing calculators, TI Avigo, Franklin electronic dictionaries, Nintendo GameBoy, SEGA GameGear all use Z80 or its close derivatives. This is only to name a few. Lately, the focus seems to shift toward 68000 though (TI92, PalmPilot). ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Tue, 24 Nov 1998 18:02:12 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 66 Message-ID: <73eseb$nlh@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> <365A97C3.3214ED56@trailing-edge.com> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!howland.erols.net!rill.news.pipex.net!pipex!server1.netnews.ja.net!cpca3.uea.ac.uk!news Tim Shoppa wrote in message <365A97C3.3214ED56@trailing-edge.com>... :Andrew Cadley wrote: :> Or in 6502... :> :> LDA #$44 (2 Cycles) :> LDX #$00 (2 Cycles) :> -loop STA $1000,X (5 Cycles) :> DEX (decrement X-register, 2 Cycles) :> BNE loop (Branch if not equal Zero, 2 Cycles) :> Which is 2306 cycles : :Actually, the BNE takes 3 Cycles when the branch is taken to :the same page; 4 if the branch is taken to an adjacent page. :So there's really at least 255 more cycles, coming out at 2563 :(you seem to have left two out of your original calculation). Tch. I should have known not to trust the timings given my a Commode owner. :-) The crap maths though, is entirely my fault... :Or, with a slight loop unrolling: : : LDA #$44 (2 Cycles) : LDX #$40 (2 Cycles) :-loop STA $1000-1,X (5 Cycles) : STA $1040-1,X (5 Cycles) : STA $1080-1,X (5 Cycles) : STA $10C0-1,X (5 Cycles) : DEX (2 Cycles) : BNE loop (3 Cycles except on last) : :Which is 1603 cycles - less than one-fourth the number on the Z80. : :> There is even a Z80 stack based version which is capable of doing :> it in LESS CYCLES than the 6502 version. : :That sounds interesting - I'd like to see that. I gave the basic form elsewhere, but more specifically: LD SP,1100h (10 cycles) LD HL,0 (10 cycles) LD B,16 (7 cycles) loop PUSH HL (11 cycles) PUSH HL (11 cycles) PUSH HL (11 cycles) PUSH HL (11 cycles) PUSH HL (11 cycles) PUSH HL (11 cycles) PUSH HL (11 cycles) PUSH HL (11 cycles) DJNZ loop (13/8 cycles) Which is a total of 1638 cycles, significantly less than the 2563 mentioned above. Naturally you can continue to unroll this and get less than the 1603 cycles you mention above. Although, even when comparing a 2Mhz 6502 to a 4Mhz Z80, it is a *lot* faster as it is. And it takes one less byte than the unrolled 6502. :-) AndyC ###### From: nailed_barnacle@junkfree.hotmail.com (barnacle) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Tue, 24 Nov 1998 20:38:24 GMT Organization: [posted via Easynet Ltd] Lines: 23 Message-ID: <73f5im$5ci$1@quince.news.easynet.net> References: <731mj4$9p1@cpca3.uea.ac.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> <73d1m4$g6q$1@agate.berkeley.edu> <365AAD9D.415C@ansf.alcatel.NOSPAM.fr> NNTP-Posting-Host: nbarnes.easynet.co.uk X-Trace: quince.news.easynet.net 911939990 5522 194.154.98.206 (24 Nov 1998 20:39:50 GMT) X-Complaints-To: abuse@easynet.net NNTP-Posting-Date: 24 Nov 1998 20:39:50 GMT X-Newsreader: News Xpress 2.01 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newspeer1.nac.net!newsfeed.wirehub.nl!easynet-tele!quince.news.easynet.net!easynet-quince!egbert In article <365AAD9D.415C@ansf.alcatel.NOSPAM.fr>, Kevin Connolly wrote: >I seem to recall the SY6502A being available at the same time as >the 4MHz Z80 and IIRC it ran at 2.5MHz > >The H/W designs were cleaner too and I often had two processors >sharing the same RAM on the same address and data buses, one using >the bus when PhiClock was high and one when it was low. > > and boy was it easier to interface video output...you could use the non-cpu active clock phase to address the video - even run code *in* the video memory without twinklies. It was also a dream if you had to genlock your output to input video (graphics displays, counters etc) - you could just use a VCO to a suitable multiple of line frequency. barnacle p.s. when i (later) had a z80 based cpm machine, i only ever had an 8085 assembler so i never used *any* of the z80 clever-bugger ops...forth didn't half fly though! barnacle nailed-barnacle.home.ml.org ###### From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 24 Nov 1998 23:46:29 GMT Organization: Cal Berkeley-- Space Sciences Lab Lines: 21 Message-ID: <73fggl$9b4$1@agate.berkeley.edu> References: <731mj4$9p1@cpca3.uea.ac.uk> <73d0i7$cg9@cpca3.uea.ac.uk> NNTP-Posting-Host: islay.ssl.berkeley.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!agate!islay.ssl.berkeley.edu!korpela In article , Neil Franklin wrote: >> Nope, it's about 3:1. This discussion has come up many, *many* times between >> comp.sys.sinclair and comp.sys.cbm, with the overall result that, on >> average, the Z80 will be faster. > >CBMs (at least the wide spread C64) had an 40% cycle loss (= they were >running at effective 0.6MHz) due to the video chips wanting to get at >80bytes of video data for each screen line. Sinclairs did not. i As much as I'm sure that the Z80 @ 4MHz is faster than the 6502 @ 1MHz, I don't think anyone should be pointing to the Sinclair as a speed demon. The sinclair lost far more than 40% of its cycles to video. The only advantage was that its video could be shut off to increase processing speed. Eric -- Eric Korpela | An object at rest can never be korpela@ssl.berkeley.edu | stopped. Click for home page. ###### From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 24 Nov 1998 23:52:14 GMT Organization: Cal Berkeley-- Space Sciences Lab Lines: 23 Message-ID: <73fgre$9f3$1@agate.berkeley.edu> References: <731mj4$9p1@cpca3.uea.ac.uk> <73d1m4$g6q$1@agate.berkeley.edu> <365AAD9D.415C@ansf.alcatel.nospam.fr> NNTP-Posting-Host: islay.ssl.berkeley.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.berkeley.edu!agate!islay.ssl.berkeley.edu!korpela In article <365AAD9D.415C@ansf.alcatel.nospam.fr>, Kevin Connolly wrote: >Eric J. Korpela wrote: >I seem to recall the SY6502A being available at the same time as >the 4MHz Z80 and IIRC it ran at 2.5MHz The SY6402A may have been available at a time when 4MHz Z80s were still available, but I'd be really really suprised if the 4 MHz Z80 wasn't avaiable at least 1 year earlier. I'd also like you to point me to a system available before 1982 that used a 6502 at anything faster than 1.3 MHz. >The H/W designs were cleaner too and I often had two processors >sharing the same RAM on the same address and data buses, one using >the bus when PhiClock was high and one when it was low. Cleaner until you wanted to use DRAMs. Eric -- Eric Korpela | An object at rest can never be korpela@ssl.berkeley.edu | stopped. Click for home page. ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 25 Nov 1998 19:34:37 +0100 Organization: My own Private Self Lines: 21 Sender: neil@chonsp.franklin.ch Message-ID: References: <731mj4$9p1@cpca3.uea.ac.uk> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> <73e4j9$ssh$1@news.wlg.netlink.net.nz> <73edt0$kuc@cpca3.uea.ac.uk> <73eoe4$9tn$1@cronkite.cs.umd.edu> X-Newsreader: Gnus v5.3/Emacs 19.34 fms@cs.umd.edu (Marat Fayzullin) writes: > > Andrew Cadley (a.p.cadley@uea.ac.uk) wrote: > : Z80 *was* faster. > Who says "was"? Low-end TI graphing calculators, TI Avigo, Franklin > electronic dictionaries, Nintendo GameBoy, SEGA GameGear all use Z80 or And don't forget the Adaptec 1542-CF SCSI controller that was once popular in the PC server world. It has an 10 MHz Z-80 on it. The 1542-B had an 8085-8. That would make some damn fast CP/M systems. The Z-80 is most likely the cheapest full CPU, ca $1 for single parts retail. As part of an ASIC in 1000er batches most likely 10c. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 25 Nov 1998 19:38:26 +0100 Organization: My own Private Self Lines: 27 Sender: neil@chonsp.franklin.ch Message-ID: References: <731mj4$9p1@cpca3.uea.ac.uk> <73d0i7$cg9@cpca3.uea.ac.uk> <73fggl$9b4$1@agate.berkeley.edu> X-Newsreader: Gnus v5.3/Emacs 19.34 korpela@islay.ssl.berkeley.edu (Eric J. Korpela) writes: > > Neil Franklin wrote: > > > >CBMs (at least the wide spread C64) had an 40% cycle loss (= they were > >running at effective 0.6MHz) due to the video chips wanting to get at > >80bytes of video data for each screen line. Sinclairs did not. > i > I don't think anyone should be pointing to the Sinclair as a speed demon. > The sinclair lost far more than 40% of its cycles to video. The only Aha. So they also did that. > advantage was that its video could be shut off to increase processing speed. No advantage. The C64 also had an video-off control bit (0xd011, bit 4). Various fast tape and fast* disk programs used it to allow faster sending of bits over the software implemented serial ports. * relatively, that is. C64 disks were never anywhere near real fast. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### Newsgroups: alt.folklore.computers Date: Tue, 24 Nov 1998 21:07:52 +0100 Message-ID: From: peterk@combo.ganesha.com (Dr. Peter Kittel) Subject: Re: opcodes for Zilog 8800/Intel 8080 Reply-To: peterk @ combo.ganesha.com References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <73boaa$o1a$1@news.wlg.netlink.net.nz> X-Newsreader: rn7.bas Lines: 26 Organization: Private Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!isdnet!news-raspail.gip.net!news.gsl.net!gip.net!newsfeed.ecrc.net!blackbush.xlink.net!ganesha.ganesha.com!shorter!combo.ganesha.com!peterk In article <73boaa$o1a$1@news.wlg.netlink.net.nz> don@news.daedalus.co.nz (Don Stokes) writes: >In article , >Dr. Peter Kittel wrote: >> >>Fully agreed. I learnt the 6502 shortly after the 8085, and practically >>fell in love immediately. This consistency, these neatly equally sized >>mnemonics, this (in comparison) orthogonal command set, I like it much >>better. > >Orthogonal? 6502? Huh? Read closer: "in comparison", to the 8080/8085, of course. And I still claim this. >The 6502 I grew up with couldn't put an index register on the stack, >could transfer between X or Y and A, but not between X & Y, had one kind >of indexing that could only be done using X and another that could only >be done with Y, and so-on. But the LDA, STA, and some more commands were available in nearly all addressing modes, something completely unknown to the 8080, *and* its x86 successors... -- Best Regards, Dr. Peter Kittel // E-Mail: Private Site in Frankfurt, Germany \X/ peterk @ combo.ganesha.com ###### Newsgroups: alt.folklore.computers Date: Tue, 24 Nov 1998 21:14:26 +0100 Message-ID: From: peterk@combo.ganesha.com (Dr. Peter Kittel) Subject: Re: opcodes for Zilog 8800/Intel 8080 Reply-To: peterk @ combo.ganesha.com References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> X-Newsreader: rn7.bas Lines: 35 Organization: Private Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!194.162.162.196!newsfeed.nacamar.de!blackbush.xlink.net!ganesha.ganesha.com!shorter!combo.ganesha.com!peterk In article <73c6kh$ptv$1@agate.berkeley.edu> korpela@islay.ssl.berkeley.edu (Eric J. Korpela) writes: >In article <36593972.6B9C865F@trailing-edge.com>, >Tim Shoppa wrote: >> >>I will agree that the 6502 is a nice microprocessor to program >>at the machine code level. And it'd beat the pants off a Z80 >>clocked several times faster on most anything. > >Ahhh, the myth of the "fast" 6502 rears its (ugly) head again. Huh? But it *is* fast. If you cautiously design the software (like it was done in the CBM 8032 and the C64), you can exploit the extremely fast access to Zero Page addresses (only 2 clock cycles) for all your time critical SW parts. This really makes it fly. >The important thing is that when viewed contemporaneously, at the available >clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by >a miniscule margin. When 4 MHz Z80's were the norm, the 6502 was still limited >to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as >many clock cycles to execute an instruction. Well, our results (with an accent on floating point number crunching) gave us a ration of 2.5, i.e. a 2.5 MHz Z80 has approximately the same performance as a 1 MHz 6502. And there were 6502 with 2 MHz clock in wide use, e.g. in the C128. And a 4 MHz "Turbo Board" for the C64 was also sold. >I've often felt that this berating Z80 performance was precipitated by >Microsoft SoftCards showing up in Apple ][s. No Apples here far and wide, my colleague had a Tandy Model II. -- Best Regards, Dr. Peter Kittel // E-Mail: Private Site in Frankfurt, Germany \X/ peterk @ combo.ganesha.com ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 25 Nov 1998 08:19:45 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 35 Message-ID: <73gem8$u4l@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <73d0i7$cg9@cpca3.uea.ac.uk> <73fggl$9b4$1@agate.berkeley.edu> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!212.63.192.161.MISMATCH!newshub.bart.net!news.tele2.nl!newsfeed1.swip.net!swipnet!rill.news.pipex.net!pipex!server1.netnews.ja.net!cpca3.uea.ac.uk!news Eric J. Korpela wrote in message <73fggl$9b4$1@agate.berkeley.edu>... :In article , :Neil Franklin wrote: :>> Nope, it's about 3:1. This discussion has come up many, *many* times between :>> comp.sys.sinclair and comp.sys.cbm, with the overall result that, on :>> average, the Z80 will be faster. :> :>CBMs (at least the wide spread C64) had an 40% cycle loss (= they were :>running at effective 0.6MHz) due to the video chips wanting to get at :>80bytes of video data for each screen line. Sinclairs did not. Actually it was only slowed to about 0.98Mhz, although the video display had "bad" lines which added a additional slowdown every 8 lines. The spectrum also suffers from memory contention under certain circumstances, but it can be avoided if you aren't altering the screen. Although it was only clocked at 3.54 MHz. :As much as I'm sure that the Z80 @ 4MHz is faster than the 6502 @ 1MHz, :I don't think anyone should be pointing to the Sinclair as a speed demon. :The sinclair lost far more than 40% of its cycles to video. The only :advantage was that its video could be shut off to increase processing speed. You're thinking of the ZX81. It wasn't actually losing cycles as such, the video display was produced in software by the Z80. The spectrum is a different matter, the video was produced by the ULA and the processor was always running in the equivalent of the ZX81's FAST mode. AndyC ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 25 Nov 1998 08:39:57 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 88 Message-ID: <73gfs7$uci@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> <73e4j9$ssh$1@news.wlg.netlink.net.nz> <73edt0$kuc@cpca3.uea.ac.uk> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!rill.news.pipex.net!pipex!server1.netnews.ja.net!cpca3.uea.ac.uk!news Neil Franklin wrote in message ... :"Andrew Cadley" writes: :> :> Not really. You can do it *much* faster on the Z80 with the following code: :> :> loop PUSH HL 11 :> DJNZ loop 13/8 : :That certainly is neat. Just hope the stack is not needed for interrupts. That's what DI is for. :-) :> Which is only 3094 cycles and isn't using the LDIR instruction. Even a 2Mhz :> 6502 can't outperform that. : :But that is really special case. Not average code, which is what the :user waiting in front of the machine sees. That is admittedly a somewhat specialised case. Normally you'd be looking at requiring about 3 times as many cycles as the 6502. To give a third example of the above routine: ld hl,$1100 10 ld b,0 7 ld a,b 4 loop ld (hl),a 7 inc l 4 djnz loop 13/8 Which is 6165 cycles. *Still* faster than in Z80@4Mhz than a 6502@1Mhz although you would never code Z80 like that unless you were thick as Devon custard. :-) :> Unrolling the loop even a little bit, as I said :> before, can actually take it down to less cycles than the equivalent 6502. : :Hmm, I doubt that. You can reduce the DJNZes with unrolling. But the :6502 can reduce the DEXes* and BNEs with unrolling. See another post for the actual timing. :* Use the STAs with different base adresses: : : lda #$44 : ldx #$80 :loop dex : sta $1000,X ; doesn't change flags from dex : sta $1080,X : bne loop The thing is though, each additional STA adds three bytes to the length of the code. Each additional PUSH adds only one, so it is more feasible to unroll the Z80 further. :> The thing is, it can be difficult to find like for like examples because the :> Z80s larger register and instruction set generally require less instructions :> for similar operations. : :And that os why examples that use many random memory accesses foul :up the Z80 by killing its register advantage. Initialisation loops are :fast, but actual programs spend time doing other things. It isn't actually as fast as you might think. There are table based algorithms that execute faster in 6502 (fast multiply is one example) but a well coded Z80 routine often comes in very close if not faster. :> 6502 may have *felt* faster, but Z80 *was* faster. : :In loop benchmarks, not on user code. At least none I ever saw. In the majority of cases. Perhaps you haven't looked hard enough? AndyC ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 25 Nov 1998 08:58:43 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Message-ID: <73ggv9$ufe@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Lines: 77 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-lond.gip.net!news.gsl.net!gip.net!dispose.news.demon.net!demon!rill.news.pipex.net!pipex!server1.netnews.ja.net!cpca3.uea.ac.uk!news Neil Franklin wrote in message ... :"Andrew Cadley" writes: :> :> Neil Franklin wrote in message ... :> Or in 6502... :> :> -loop STA $1000,X (5 Cycles) :> DEX (decrement X-register, 2 Cycles) :> BNE loop (Branch if not equal Zero, 2 Cycles) :> Which is 2306 cycles. : :Here I dispute the cycle numbers. Well they were given to me by a C64er, who of course I trust implicitly. The variation may be down to the fact a C64 uses a 6510, I think. Or he may have just been wrong. :> At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502 : :So we may already be down to 1.5. But given that was an "all the time in the world" type Z80 routine, it's hardly surprising hat optimised 6502 is going to be closer in speed terms. :And then there is the question of the LDI/D*. It only works if it is :applicable. Special purpose hardware usually beats software if it can :be used. It can still be written idiot-fashon, without LDIR or PUSH, and go faster than the 6502. Not that real Z80 ever looks anything like that. :Also requires you to DI/EI to missuse SP. The OS may not allow this. OS? Pah! Sod that and write directly to the hardware. :-) Not that any OS could *stop* you doing a DI... :> This is a classic example of where :> the Z80 is *significantly* faster. : :Classic (= representative) example? More a special case. Classic in the same sense that a fast multiply is used to try and demonstrate that 6502 is faster. However the difference in that case is *much* smaller. :Loops and indirect addressing are generally the weak points on the :6502. Try some code that does lots of direct accesses to random :variables in RAM. Thats difficult to write short benchmarks for, but :that is where the 6502 runs good. Branching and jumping are generally slower in Z80, as is memory indexing. Algorithms that work almost exclusively with large-ish tables tend to do better on 6502. Z80 code tends to rely more on page alignments to allow HL to be used as an pseudo-index register and will do better with algorithms that fit into the registers and don't need to branch too much. :Take an realistic (from user standpoint) job such as Basic interpreter :doing an print "Hello, world". For that the Z80-4 = 6502-1 was a good :approximation. Hmmm. That's entirely dependent on the type of display you have though. A character based version will obviously lend itself to yet another LDIR. A bitmapped one can get tricky, but not nessecarily slower in Z80. Perhaps you could supply some 6502 examples? AndyC ###### From: dg@ (David Given) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 25 Nov 1998 12:57:28 GMT Organization: I'm organised? Wow! Message-ID: <911998648.19989.0.nnrp-10.9e9878e0@news.demon.co.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <73boaa$o1a$1@news.wlg.netlink.net.nz> NNTP-Posting-Host: taos.demon.co.uk X-NNTP-Posting-Host: taos.demon.co.uk:158.152.120.224 X-Trace: news.demon.co.uk 911998648 nnrp-10:19989 NO-IDENT taos.demon.co.uk:158.152.120.224 X-Complaints-To: abuse@demon.net Lines: 46 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!btnet-peer!btnet!dispose.news.demon.net!demon!news.demon.co.uk!demon!taos.demon.co.uk!!dg In article , Dr. Peter Kittel wrote: [...] >>The 6502 I grew up with couldn't put an index register on the stack, >>could transfer between X or Y and A, but not between X & Y, had one kind >>of indexing that could only be done using X and another that could only >>be done with Y, and so-on. Don't you remember... PHA TXA PHA TYA PHA ... PLA TAY PLA TAX PLA for interrupts? The 65C102, the next generation, had a slightly better rounded instruction set. PHA PHX PHY ... PLY PLX PLA It also had STZ, which stored zero to a memory location. Handy. -- +- David Given ----------------+ This is a test. This is only a test. | Work: dg@tao.co.uk | Had this been a real emergency, you | Play: dgiven@iname.com | would all be dead by now. +- http://wiredsoc.ml.org/~dg -+ ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 25 Nov 1998 13:42:14 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 42 Message-ID: <73h1is$1vh@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!nntp.abs.net!newsfeed.axxsys.net!router1.news.adelphia.net!uunet!in5.uu.net!news1-gui.server.ntli.net!news-feed.ntli.net!news5-gui.server.ntli.net!news-feed.ntli.net!server4.netnews.ja.net!server2.netnews.ja.net!cpca3.uea.ac.uk!news Dr. Peter Kittel wrote in message ... :In article <73c6kh$ptv$1@agate.berkeley.edu> korpela@islay.ssl.berkeley.edu (Eric J. Korpela) writes: :>In article <36593972.6B9C865F@trailing-edge.com>, :>Tim Shoppa wrote: :>Ahhh, the myth of the "fast" 6502 rears its (ugly) head again. : :Huh? But it *is* fast. If you cautiously design the software (like it :was done in the CBM 8032 and the C64), you can exploit the extremely :fast access to Zero Page addresses (only 2 clock cycles) for all your :time critical SW parts. This really makes it fly. And your point is? If your clever about the way you write Z80 routines then they can also fly. They just usually fly faster. :-) Zero page isn't that much of an advantage in real terms. If we set H to be the base address, we can index any value in a 256 byte, page aligned, table using L as the index. Since LD (HL),A requires just 7 cycles the Z80 is ahead with a 4:1 clock ratio. And of course we can access more than one table. :Well, our results (with an accent on floating point number crunching) :gave us a ration of 2.5, i.e. a 2.5 MHz Z80 has approximately the same :performance as a 1 MHz 6502. And there were 6502 with 2 MHz clock in :wide use, e.g. in the C128. And a 4 MHz "Turbo Board" for the C64 was :also sold. I think you'll find more generic results lean towards a 3:1 time ratio. In either case the Z80 was faster. 2Mhz 6502s came along later (the C128 was 1985) which should be faster, but faster Z80s like the 6MHz Z80B were also widely available. Surely the real testement to the Z80 is that it is still commonly used in embeded controllers. AndyC ###### Newsgroups: alt.folklore.computers From: hoh@approve.se.NO_JUNK_EMAIL (Goran Larsson) Subject: Re: opcodes for Zilog 8800/Intel 8080 Message-ID: <1998Nov25.180407.10065@lorelei.approve.se> Originator: hoh@approve.se.NO_JUNK_EMAIL (Goran Larsson) Sender: hoh@lorelei.approve.se.NO_JUNK_EMAIL (Goran Larsson) Organization: [1] + 5934 done /bin/rm -rf ~/ & X-No-Archive: yes X-Newsreader: trn 4.0-test66 (4 June 1998) References: <731mj4$9p1@cpca3.uea.ac.uk> <73edt0$kuc@cpca3.uea.ac.uk> <73gfs7$uci@cpca3.uea.ac.uk> Lines: 19 Date: Wed, 25 Nov 1998 18:04:07 GMT NNTP-Posting-Host: 130.244.109.168 X-Complaints-To: news-abuse@swip.net X-Trace: nntpserver.swip.net 912017285 130.244.109.168 (Wed, 25 Nov 1998 19:08:05 MET DST) NNTP-Posting-Date: Wed, 25 Nov 1998 19:08:05 MET DST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed1.swip.net!swipnet!nntpserver.swip.net!not-for-mail In article <73gfs7$uci@cpca3.uea.ac.uk>, Andrew Cadley wrote: > :That certainly is neat. Just hope the stack is not needed for interrupts. > > That's what DI is for. :-) But then you have to figure out if you should do an EI after the critical region. There is a way, but many years have passed since I wrote code like that. One way the 6502 really sucks is the page 0 stuff and the fixed location for the stack. It is fast and convenient for small programs, but a total disaster for multitasking. -- Goran Larsson hoh AT approve DOT se I was an atheist, http://home DOT swipnet DOT se/hoh/ until I found out I was God. ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 25 Nov 1998 19:45:05 GMT Lines: 41 Message-ID: <73hmo1$iki$2@irk.zetnet.co.uk> References: <73d0i7$cg9@cpca3.uea.ac.uk> NNTP-Posting-Host: man-063.dialup.zetnet.co.uk X-Trace: irk.zetnet.co.uk 912023105 19090 194.247.41.78 (25 Nov 1998 19:45:05 GMT) NNTP-Posting-Date: 25 Nov 1998 19:45:05 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!ayres.ftech.net!news.ftech.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-11-24 a.p.cadley@uea.ac.uk said: :Consider the following code fragment in Z80 to fill from 1000h to :10FFh with 44h (an example I cheekily swiped from a recent :flamewar) :-) [conservative programming examples snipped] :At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502 :routine. There is even a Z80 stack based version which is capable :of doing it in LESS CYCLES than the 6502 version. This is a classic :example of where the Z80 is *significantly* faster. But that version will die if the Z80 gets an interrupt halfway through the loop. Turning them off won't help with the NMIs. :Nope, it's about 3:1. This discussion has come up many, *many* :times between comp.sys.sinclair and comp.sys.cbm, with the overall :result that, on average, the Z80 will be faster. Actually, it depends on a hell of a lot more factors than simple CPU speed. For example, the 6502 could usually arrange itself so that it never encountered a wait state on memory (you were guaranteed that the bus was free for half of every clock cycle; a fair few video generators used this, including the BBC's). The Z80 had a far less predictable memory cycle, which meant that video would probably trip up the CPU and take the effective speed down 20%. (The Spectrum was even worse here, since the video circuitry was used to refresh all the RAM, eating about 50% of memory bandwidth.) There's also the issue of how amenable the instruction set is to real speed-intensive hacking, and I believe that the 6502 was felt to be a little friendlier in that respect. And then there's the "it just feels..." factor, and I think that's where the consensus arose. Also, there's the issue of what the chips were designed for; the 6502 for washing machines, and the Z80 for shifting lots of data around in a way wordprocessors would appreciate. And how often do you need to fill an area of memory without more complicated range tests anyway..? -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 25 Nov 1998 19:45:11 GMT Lines: 18 Message-ID: <73hmo7$iki$3@irk.zetnet.co.uk> References: NNTP-Posting-Host: man-063.dialup.zetnet.co.uk X-Trace: irk.zetnet.co.uk 912023111 19090 194.247.41.78 (25 Nov 1998 19:45:11 GMT) NNTP-Posting-Date: 25 Nov 1998 19:45:11 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed.wirehub.nl!ayres.ftech.net!news.ftech.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-11-23 neil@franklin.ch.remove said: :As minuscle as zero, IMHO. I used both, never noticed any :difference. I did prefer the 6809 instruction set the most. That 4 :byte Forth interpreter was nifty. Forth ran at 2/3 assembly speed. Now you're talking. :> I didn't realise it was as little as 4 bytes; even the x86s (hell, even 68000s!) are more than that. I wonder if a 6809 emulator would run at full speed on a 486/33..? ;> (Oh, that's a point, there's a Dragon emulator I should really look at first.) -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing Net-Tamer V 1.08X - Test Drive ###### From: William.Hamblen@nashville.com (William Hamblen) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 25 Nov 1998 23:34:48 GMT Organization: Posted via Supernews, http://www.supernews.com - Discussions start here! Lines: 17 Message-ID: <365b7e1c.5616325@news.nashville.com> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> NNTP-Posting-Host: 207.65.180.74 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 912036863 4TJCV727NB44ACF41C usenet52.supernews.com X-Complaints-To: newsabuse@supernews.com X-Newsreader: Forte Agent 1.5/32.452 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!feeder.qis.net!newsfeed-east.supernews.com!supernews.com!Supernews69!not-for-mail On Tue, 24 Nov 1998 01:00:16 -0000, "Andrew Cadley" wrote: >At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502 >routine. There is even a Z80 stack based version which is capable of doing >it in LESS CYCLES than the 6502 version. This is a classic example of where >the Z80 is *significantly* faster. 4 MHz was the "fast" Z80A. The "normal" Z80 ticked over at 2.5 MHz. An instruction fetch took 4 clocks and other memory references took 3. So a 2.5 MHz Z80 was roughly equivalent to a 1 MHz 6800 or 6502. A Z80A would be like a 68B00 (2 MHz clock). I don't recall the part number for a 2 Mhz 6502. The big advantage of the MOS Technology 6502 back in 1975 was that it was a lot cheaper than the parts produced by the other manufacturers. That was important for garage inventors. ###### From: dg@ (David Given) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Thu, 26 Nov 1998 12:29:45 GMT Organization: I'm organised? Wow! Message-ID: <912083385.5085.0.nnrp-08.9e9878e0@news.demon.co.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <73gfs7$uci@cpca3.uea.ac.uk> <1998Nov25.180407.10065@lorelei.approve.se> NNTP-Posting-Host: taos.demon.co.uk X-NNTP-Posting-Host: taos.demon.co.uk:158.152.120.224 X-Trace: news.demon.co.uk 912083385 nnrp-08:5085 NO-IDENT taos.demon.co.uk:158.152.120.224 X-Complaints-To: abuse@demon.net Lines: 18 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!ayres.ftech.net!news.ftech.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!taos.demon.co.uk!!dg In article <1998Nov25.180407.10065@lorelei.approve.se>, Goran Larsson wrote: [...] >One way the 6502 really sucks is the page 0 stuff and the fixed >location for the stack. It is fast and convenient for small programs, >but a total disaster for multitasking. True. The way out, of course, is to shadow the relevant bits of memory so different process' zero-page and stack live in different address spaces. This does require extra hardware, of course. -- +- David Given ----------------+ | Work: dg@tao.co.uk | Truth is stranger than fiction, because | Play: dgiven@iname.com | fiction has to make sense. +- http://wiredsoc.ml.org/~dg -+ ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 27 Nov 1998 08:17:52 GMT Organization: Daedalus Consulting Lines: 13 Message-ID: <73ln7g$3hk$1@news.wlg.netlink.net.nz> References: <731mj4$9p1@cpca3.uea.ac.uk> <73boaa$o1a$1@news.wlg.netlink.net.nz> <911998648.19989.0.nnrp-10.9e9878e0@news.demon.co.uk> NNTP-Posting-Host: toyunix.zl2tnm.gen.nz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed1.swip.net!swipnet!newsfeed.cwix.com!203.97.37.7!newsfeed.clear.net.nz!news.wlg.netlink.net.nz!don In article <911998648.19989.0.nnrp-10.9e9878e0@news.demon.co.uk>, David Given wrote: [65C02] >It also had STZ, which stored zero to a memory location. Handy. So did the vanilla 6502, but it wasn't documented. I can't remember if it was the same opcode. The 65C02 also had BRA, which got rid of the CLC BCC or equivalent sequences for writing position independent code. -- Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724 ##### From: dg@ (David Given) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Fri, 27 Nov 1998 13:04:57 GMT Organization: I'm organised? Wow! Message-ID: <912171897.20013.0.nnrp-05.9e9878e0@news.demon.co.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <911998648.19989.0.nnrp-10.9e9878e0@news.demon.co.uk> <73ln7g$3hk$1@news.wlg.netlink.net.nz> NNTP-Posting-Host: taos.demon.co.uk X-NNTP-Posting-Host: taos.demon.co.uk:158.152.120.224 X-Trace: news.demon.co.uk 912171897 nnrp-05:20013 NO-IDENT taos.demon.co.uk:158.152.120.224 X-Complaints-To: abuse@demon.net Lines: 38 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!bullseye.news.demon.net!demon!news.demon.co.uk!demon!taos.demon.co.uk!!dg In article <73ln7g$3hk$1@news.wlg.netlink.net.nz>, Don Stokes wrote: >In article <911998648.19989.0.nnrp-10.9e9878e0@news.demon.co.uk>, >David Given wrote: >[65C02] >>It also had STZ, which stored zero to a memory location. Handy. > >So did the vanilla 6502, but it wasn't documented. I can't remember if >it was the same opcode. > >The 65C02 also had BRA, which got rid of the CLC BCC or equivalent >sequences for writing position independent code. Unfortunately it only took a single byte operand, so you could only jump +-128 bytes. That made it not very useful. Hmm... JSR next next: PLA CLC ADC #offsetlo TAX PLA ADC #offsethi PHA TXA PHA RTS Eeek! -- +- David Given ----------------+ | Work: dg@tao.co.uk | In capitalism, man exploits man. With | Play: dgiven@iname.com | communism, it's exactly the opposite. +- http://wiredsoc.ml.org/~dg -+ ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 27 Nov 1998 20:07:09 GMT Organization: Daedalus Consulting Lines: 25 Message-ID: <73n0pd$ai9$1@news.wlg.netlink.net.nz> References: <731mj4$9p1@cpca3.uea.ac.uk> <911998648.19989.0.nnrp-10.9e9878e0@news.demon.co.uk> <73ln7g$3hk$1@news.wlg.netlink.net.nz> <912171897.20013.0.nnrp-05.9e9878e0@news.demon.co.uk> NNTP-Posting-Host: toyunix.zl2tnm.gen.nz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-peer.gip.net!news.gsl.net!gip.net!news.maxwell.syr.edu!worldfeed.news.gte.net!intgwlon.nntp.telstra.net!news.telstra.net.nz!news.wlg.netlink.net.nz!don In article <912171897.20013.0.nnrp-05.9e9878e0@news.demon.co.uk>, David Given wrote: >>The 65C02 also had BRA, which got rid of the CLC BCC or equivalent >>sequences for writing position independent code. > >Unfortunately it only took a single byte operand, so you could only jump >+-128 bytes. That made it not very useful. CLC BCC hop ... ; < 128 bytes hop: BCC target ... ; < 128 bytes target: ... What's bothersome is that I use the same trick in the VAX because althoug the VAX has a lovely programmer friendly (and CPU designer hostile) three operand architecture with lots of niceties, some halfwit spoiled it by having only byte-relative conditional branches. Admittedly the intermediate branches can be BRW instructions, so you don't need several hops for long branches. Heck, at least the pdp11 had *word* relative branches, giving a +-255 byte range, and VAX instructions are on averagge bigger. -- Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724 ###### From: Charles Richmond Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Sat, 28 Nov 1998 12:45:51 +0000 Organization: Cannine Computer Center Lines: 36 Message-ID: <365FF07E.9D7F8A9@plano.net> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> Reply-To: richmond@plano.net NNTP-Posting-Host: 209.44.41.231 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 912278615 R67V8VHUD29E7D12CC usenet57.supernews.com X-Complaints-To: newsabuse@supernews.com X-Mailer: Mozilla 4.04 (Macintosh; I; 68K) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-dc.gip.net!news-peer.gip.net!news.gsl.net!gip.net!europa.clark.net!206.132.26.41!newsfeed-east.supernews.com!supernews.com!Supernews69!not-for-mail Neil Franklin wrote: > > [snip...] [snip...] [snip...] > > As minuscle as zero, IMHO. I used both, never noticed any difference. I > did prefer the 6809 instruction set the most. That 4 byte Forth > interpreter was nifty. Forth ran at 2/3 assembly speed. > The Motorola 6809...there is *one* great chip!!! Too bad that it came so late in the 8-bit era that it was essentially stillborn. What made it so good for FORTH was that it has *two* hardware supported stacks. And also it has a JMP instruction format that will branch to the address pointed to by the operand. (indirection, yeh). The 6809 *is* fairly orthogonal. Data can be moved between any two like sized registers (with one exception), and any two like sized registers can have their contents *exchanged* with one assembly instruction. These used a bit-mask for the registers to be exchanged, and the PSH/PUL instruction used a bit-mask to identify registers to operate on. So *one* instruction could push the entire register file. The exception to the data transfer (but *not* to data exchange) is the direct page register. The direct page register contains the upper byte of the address of the direct page (which is limited to the first 256 locations on the 6800 and 6502). So changing this register lets you use direct page instructions for *anywhere* in memory. There was a three part article in BYTE magazine about the design of the 6809 (I think in the summer of 1980 or 1981). There was an attempt to take statistical measures of the instruction frequency used in 6800 programs, and to make the most used instructions execute fastest on the 6809. -- +-------------------------------------------------------------+ | Charles and Francis Richmond | +-------------------------------------------------------------+ ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 28 Nov 1998 23:11:59 +0100 Organization: My own Private Self Lines: 46 Sender: neil@chonsp.franklin.ch Message-ID: References: <731mj4$9p1@cpca3.uea.ac.uk> <73d0i7$cg9@cpca3.uea.ac.uk> <73fggl$9b4$1@agate.berkeley.edu> <73gem8$u4l@cpca3.uea.ac.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 "Andrew Cadley" writes: > > :Neil Franklin wrote: > :> > :>CBMs (at least the wide spread C64) had an 40% cycle loss (= they were > :>running at effective 0.6MHz) due to the video chips wanting to get at > :>80bytes of video data for each screen line. Sinclairs did not. > > Actually it was only slowed to about 0.98Mhz [go digging for 64 internals book, page325ff C64 circuit diagram reprint, (C) 1983 CBM Yup, in those days we still got diagrams] All numbers are NTSC|PAL. Quarz 14.31818|17.724472 divided 1:18|1:14 (74LS193+flipflop) goes to PLL (MC4044). Other input is from an PLL controlled VCO divided 1:8 (6567|6565, the VIC chip). VCO is used for pixel clock, which is 8 times CPU clock (1.0227|0.985248). After this you then get the problem that the VIC wants for every 8 pixels 1 byte character number and 1 byte pixel pattern = 80 bytes from DRAM (plus 40 nibbles color number over separate bus from an 2114). So to do this the VIC has to use both halfs of the CPU clock, so it stops the 6510 dead for 40 clocks per line. That is 200*40 = 8000 clocks per frame, 8000 * 60|50 = 480000|400000 clocks per second. That gives 1.0227|0.985248 - 0.48|0.40 = 0.54|0.58 MHz effective clock. Sprites costed an additional 21*4 clocks per frame and per sprite. Then there is the normal DRAM refresh, also done by the VIC. > although the video display had > "bad" lines which added a additional slowdown every 8 lines. What process would this be? -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 29 Nov 1998 00:03:00 +0100 Organization: My own Private Self Lines: 77 Sender: neil@chonsp.franklin.ch Message-ID: References: <73hmo7$iki$3@irk.zetnet.co.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 lisard@zetnet.co.uk writes: > > On 1998-11-23 neil@franklin.ch.remove said: > :As minuscle as zero, IMHO. I used both, never noticed any > :difference. I did prefer the 6809 instruction set the most. That 4 > :byte Forth interpreter was nifty. Forth ran at 2/3 assembly speed. > > Now you're talking. :> I didn't realise it was as little as 4 bytes; The following is from memory, read it 15 years ago in a book (Author R Zaks, title I can't remember). It had an comparison table of the inner interpreter in 6502, 8080, LSI-11, 6809, 8086 of how FIGforth does it. 6809 register usage was: return stack S (hardware return stack, Forth has no JSR/RTS) data stack U (user stack) forths "instruction" pointer Y forths loaded "instruction" (address of primitive) X "do" was something like: do: LDX (Y++) JMP (X) My 6809 instruction set sheet (incomplete, postbytes not explained) plus a code example (Dragon 32 Basic ROM disassembly) here would translate this to: AE A1 6E 84 As the JMP do: at the end of every primitive would be 3 Bytes (7E xx xx) and there are not that many primitives it was actually worth it to put a copy of do: at the end of every primitive to save even more time. Secondaries would start with an JSR to semis (here memory is very unreliable, I have reconstructed this code): semis: LDD , S++ ; EC E1 addr of first word, from JSR STY ,--S ; 10 AF E3 TFR Y,D ; 1F 20 MACRO do: ; AE A1 6E 84 Then there are of course the fully orthogonal Arithmetic and stacking, making "+" simply: plus: LDD ,U++ ; EC C1 ADDD ,U++ ; E3 C1 STD ,--U ; ED C3 MACRO do ; AE A1 6E 84 Thats compact and fast. Terrific chip. At 2MHz, 1 clock per memory access. > I wonder if a 6809 emulator would run at full speed on a 486/33..? ;> > (Oh, that's a point, there's a Dragon emulator I should really look at > first.) I don't know, never tried. Have got an hardware Dragon, so why use an emulator? :-) This post was great fun. Assembler again. Ahhhh. What klutz had the idea of high level languages. Should be retroactively killed. Anyone got an time machine? :-) -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 01 Dec 1998 00:09:35 +0100 Organization: My own Private Self Lines: 66 Sender: neil@chonsp.franklin.ch Message-ID: References: <731mj4$9p1@cpca3.uea.ac.uk> <73d0i7$cg9@cpca3.uea.ac.uk> <73fggl$9b4$1@agate.berkeley.edu> <73gem8$u4l@cpca3.uea.ac.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 Michael Kircher writes: > > Neil Franklin writes: > > > > After this you then get the problem that the VIC wants for every 8 > > pixels 1 byte character number and 1 byte pixel pattern = 80 bytes > > from DRAM (plus 40 nibbles color number over separate bus from an 2114). > > The character numbers were only read in the first raster of the > respective line, leading to a dead stop of the CPU for only > 40*25 cycles per frame. In the following 7 rasters the VIC used > something like a cache => 1000 * 60|50 = 60000|50000 cps. Interesting. Would require 80*8=640bits=640*6=3840 transistors (assuming SRAM, less for an DRAM shift register). Sounds believable for 1982 technology. > > Sprites costed an additional 21*4 clocks per frame and per sprite. > > 21*3 clocks as sprites were fixed 24 pixels (3 Bytes) width. Sprites were 3 Bytes wide. But they required 4 bytes from memory, for the same reason that characters required 2 bytes for 8 bits. The first 8 bytes after the 25*40 bytes characters were used (shifted left by 6 bits) to find the 64 byte block from which the 63 sprite bytes were taken (the VIC used 14 bit adresses, top 2 were supplied by one of the 6526s). Of course the cache trick may have only required the 4th byte for the first line of an sprite. I always wondered why they did not provide 8 registers for instead of taking bytes from memory. > > Then there is the normal DRAM refresh, also done by the VIC. > > In fact the bus had 2MBytes/sec bandwidth, used by the VIC to > read the character patterns every other cycle, with said exception > above. The way it was also done on the VIC-20 and the Dragon 32 (6809/6847). > However the CPU was unable to use the free cycles in the border. That was then added AFAIK in the C128 which had an 2MHz 8510. > To give the VIC priority for memory accesss was a far better solution > than some Sinclair clones employed to resolve bus contention: The irregular bus cycle of the Z80 (sometimes 4, sometimes 5 clocks) makes this somewhat more difficult to do it properly. > In some > cases a busy CPU could lead to "snow" on the screen :). The IBM PCs CGA video also had this "feature". -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### From: Richard Lamb Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Mon, 30 Nov 1998 20:13:04 -0600 Organization: Tapestry Software Lines: 58 Message-ID: <366350B0.E08355E2@flash.net> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> <365b7e1c.5616325@news.nashville.com> <3662BD76.2D6D@ic.ac.uk> Reply-To: lamb01@flash.net NNTP-Posting-Host: p102.amax2.dialup.sat1.flash.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: "Richard Lamb" (Unverified) X-Mailer: Mozilla 4.04 [en]C-FLASHNET (Win95; I) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!nntp.flash.net!excalibur.flash.net!not-for-mail Back in the CP/M days, I made a lot of spare change hopping up Kaypros. Z80H would run at 10 MHz! Now THAT was a Fast Machine! And it was a really easy mod, too. Ahhh, yes, the good old days. Simon wrote: > > Ralph Wade Phillips wrote: > > > > Hi, William! > > > > William Hamblen wrote in message <365b7e1c.5616325@news.nashville.com>... > > > > > >... > > >A Z80A would be like a 68B00 (2 MHz clock). I don't recall the part > > >number for a 2 Mhz 6502. > > > > 6502B, IIRC. The 65C02 was the CMOS 2MHz version, with the extended > > instruction set (again, IIRC from my Apple ][ Service Center days. ORAM > > failures may have occured ... ) > > > 6502A was the 2MHz part. Although my plain 1MHz 6502 ran quite happily > at 2MHz (some of my 650ns 2114s couldn't cope with 2MHz though!). The > CMOS 65C02 range ran from 1 to 4 MHz with part numbers 65C02P1 ... > 65C02P4. > The CMOS parts, I found were more speed critical, and the 65C02P1 I had > would not run at 2MHz. > > > > > > >The big advantage of the MOS Technology 6502 back in 1975 was that it > > >was a lot cheaper than the parts produced by the other manufacturers. > > >That was important for garage inventors. > > > > I remember reading an article where Woz mentioned that the main > > reason for the Apple and the Apple ][ using a 6502 was that the 6800 was > > still $400 in singles, the 8080 was $495 in singles, and the 6502 was under > > $10 in singles ... You can put in a HELL of a lot of support TTL for that > > difference! > > > > Actually, I THINK it was the 6500 that was $10 - a pin compatible to > > the 6800, which wasn't made very long (the 6502 wasn't pin compatible to > > forstall a lawsuit from Motorola, IIRC.) > > > > RwP > > Even so, the 6502 incompatibilities were kept to the region around the > clock generator, so it would still have been possible to make a small > 6502 daughterboard that plugged into a 6800 socket, and passed data, > address, interrupts, etc. through while doing its own clock generation > (6502 clock generators were simpler than the 6800 IIRC). Such a pity the > 6809 pins were skewed the way they were wrt to the 6800, making such a > plug-in replacement so much more awkward. Pity too, that some 6809 > instructions take so long! > > Simon. ###### From: Larry Anderson Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Mon, 30 Nov 1998 20:55:56 -0800 Organization: Goldrush World Access, Ltd. Lines: 30 Message-ID: <366376DA.7320852@goldrush.com> References: <731mj4$9p1@cpca3.uea.ac.uk> <7357vm$uiv$11@irk.zetnet.co.uk> <36593972.6B9C865F@trailing-edge.com> <73c6kh$ptv$1@agate.berkeley.edu> <73d0i7$cg9@cpca3.uea.ac.uk> <365b7e1c.5616325@news.nashville.com> <3662BD76.2D6D@ic.ac.uk> Reply-To: foxnhare@goldrush.com NNTP-Posting-Host: jx-078.goldrush.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.06 (Macintosh; I; PPC) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.berkeley.edu!su-news-hub1.bbnplanet.com!news.gtei.net!news.pbi.net!206.171.171.4!news.goldrush.com!usenet Simon wrote: > > Ralph Wade Phillips wrote: > > >The big advantage of the MOS Technology 6502 back in 1975 was that it > > >was a lot cheaper than the parts produced by the other manufacturers. > > >That was important for garage inventors. > > > > I remember reading an article where Woz mentioned that the main > > reason for the Apple and the Apple ][ using a 6502 was that the 6800 was > > still $400 in singles, the 8080 was $495 in singles, and the 6502 was under > > $10 in singles ... You can put in a HELL of a lot of support TTL for that > > difference! > > > > Actually, I THINK it was the 6500 that was $10 - a pin compatible to > > the 6800, which wasn't made very long (the 6502 wasn't pin compatible to > > forstall a lawsuit from Motorola, IIRC.) > > From the July 1980 Creative Computing the microprocessor price before the 6502: Intel 8080 - $175.00 Then the MOS 6502 was introduced for $20.00 ($25 with hardware/software manual) That same day (Wescon Show in Sept is the only reference) the Motorola dropped thier 6800 price to $79.00 Before that the 'big boys' had the home/hobbiest microcomputer market convinced that the lowest price for a single microprocessor would be around $200.00. Be glad for competition. ###### From: "Andrew Cadley" Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Tue, 1 Dec 1998 00:52:28 -0000 Organization: University of East Anglia, Norwich, Norfolk, NR47TJ, UK Lines: 51 Message-ID: <73veno$afj@cpca3.uea.ac.uk> References: <731mj4$9p1@cpca3.uea.ac.uk> <73d0i7$cg9@cpca3.uea.ac.uk> <73fggl$9b4$1@agate.berkeley.edu> <73gem8$u4l@cpca3.uea.ac.uk> NNTP-Posting-Host: oak6d.vlg1.uea.ac.uk X-Newsreader: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed1.news.luth.se!luth.se!masternews.telia.net!news-nyc.telia.net!news.maxwell.syr.edu!rill.news.pipex.net!pipex!server1.netnews.ja.net!cpca3.uea.ac.uk!news Neil Franklin wrote in message ... :Michael Kircher writes: :> The character numbers were only read in the first raster of the :> respective line, leading to a dead stop of the CPU for only :> 40*25 cycles per frame. In the following 7 rasters the VIC used :> something like a cache => 1000 * 60|50 = 60000|50000 cps. :Interesting. Would require 80*8=640bits=640*6=3840 transistors :(assuming SRAM, less for an DRAM shift register). Sounds believable :for 1982 technology. Which is what I meant originally by the term "bad lines". :> 21*3 clocks as sprites were fixed 24 pixels (3 Bytes) width. : :Sprites were 3 Bytes wide. But they required 4 bytes from memory, for :the same reason that characters required 2 bytes for 8 bits. Are you sure? Surely the sprites only needed to perform memory reads for the three pixel patterns. Of course, I may be wrong. :> To give the VIC priority for memory accesss was a far better solution :> than some Sinclair clones employed to resolve bus contention: : :The irregular bus cycle of the Z80 (sometimes 4, sometimes 5 clocks) :makes this somewhat more difficult to do it properly. It was done in Amstrad's CPC range. In that case each individual M-cycle is rounded up to the nearest four clock cycles. It makes timing easier but you don't half suffer from lost cycles. The beauty of the Sinclair approach is that you only lose speed when executing code in the contended memory (from #4000 to #7fff on the 48s) or when you are reading/writing to this area. :> In some :> cases a busy CPU could lead to "snow" on the screen :). : :The IBM PCs CGA video also had this "feature". It's pretty easy to avoid it though. Although it was used to great effect by Arkanoid, IIRC. AndyC ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 1 Dec 1998 19:43:44 GMT Lines: 26 Message-ID: <741gtg$88i$7@irk.zetnet.co.uk> References: NNTP-Posting-Host: man-141.dialup.zetnet.co.uk X-Trace: irk.zetnet.co.uk 912541424 8466 194.247.40.180 (1 Dec 1998 19:43:44 GMT) NNTP-Posting-Date: 1 Dec 1998 19:43:44 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!diablo.theplanet.net!demeter.clara.net!news.clara.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-11-29 neil@franklin.ch.remove said: :lisard@zetnet.co.uk writes: :Then there are of course the fully orthogonal Arithmetic and :stacking, making "+" simply: :plus: LDD ,U++ ; EC C1 :ADDD ,U++ ; E3 C1 :STD ,--U ; ED C3 :MACRO do ; AE A1 6E 84 :Thats compact and fast. Terrific chip. At 2MHz, 1 clock per memory :access. Two questions. What's the cycle count? Would it be practical to use D as a TOS cache? :I don't know, never tried. Have got an hardware Dragon, so why use :an emulator? :-) I don't, so there. :P It'd be fun to hack, too. :This post was great fun. Assembler again. Ahhhh. Some of us never left those days, Neil. :> -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 02 Dec 1998 01:31:14 +0100 Organization: My own Private Self Lines: 41 Sender: neil@chonsp.franklin.ch Message-ID: References: <741gtg$88i$7@irk.zetnet.co.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 lisard@zetnet.co.uk writes: > > On 1998-11-29 neil@franklin.ch.remove said: > :lisard@zetnet.co.uk writes: > :Then there are of course the fully orthogonal Arithmetic and > :stacking, making "+" simply: > :plus: LDD ,U++ ; EC C1 > :ADDD ,U++ ; E3 C1 > :STD ,--U ; ED C3 > :MACRO do ; AE A1 6E 84 > :Thats compact and fast. Terrific chip. At 2MHz, 1 clock per memory > :access. > > Two questions. What's the cycle count? Unfortunately I have no list of cycle times. But I would _assume_ 1 cycle for each fetch of an byte of opcode or fetch/store of data, at least for simple instructions. IIRC it took 8 cycles for the MUL (A * B -> D, A and B are the two 8 bit halves of D). > Would it be practical to use D as a TOS cache? Given that all other registers (PXYUS) are in use, I would assume that D gets used too often for other things, so you would end up with many push/pops anyway. > :This post was great fun. Assembler again. Ahhhh. > > Some of us never left those days, Neil. :> I did Z80, 6809, 6502, 8051, 68k in Assembler. The 80x86 sort of persuaded me to change to C. For the T800 there wasn't even Assembler available... Today I work on 80486, MIPS, Sparc, none are Assembler friendly. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 02 Dec 1998 01:38:15 +0100 Organization: My own Private Self Lines: 62 Sender: neil@chonsp.franklin.ch Message-ID: References: <731mj4$9p1@cpca3.uea.ac.uk> <73d0i7$cg9@cpca3.uea.ac.uk> <73fggl$9b4$1@agate.berkeley.edu> <73gem8$u4l@cpca3.uea.ac.uk> <740fuc$cdm$1@mermaid.ucc.gu.uwa.edu.au> X-Newsreader: Gnus v5.3/Emacs 19.34 john@ucc.gu.uwa.edu.au (John "West" McKenna) writes: > > Neil Franklin writes: > > >Interesting. Would require 80*8=640bits=640*6=3840 transistors > >(assuming SRAM, less for an DRAM shift register). Sounds believable > >for 1982 technology. > > Not that many. There were 40 characters per line, Oops. Thinko. I am just too used to 80 character displays these days :-). > at 8 bits each (plus 4 bits for colour). Nope. The 4 color bits are fetched over 4 separate pins of the VIC from an 2114 (at $D800). So they don't contend with the DRAM reads. > That makes 40*12=480 bits. So even only 40*8=320 bits. > The buffer was almost > certainly dynamic - Commodore's patents from around that time are full of > ways of doing things with dynamic NMOS circuits. So 320 transister/capacitor pairs (as this is an shift register). Even cheaper. > >Sprites were 3 Bytes wide. But they required 4 bytes from memory, for > >the same reason that characters required 2 bytes for 8 bits. > > Sprites require 4 bytes each per line, but two of them are on the off- > phase, when the processor can't access RAM anyway. Each sprite takes 2 > cycles away from the processor each line. That is what I expected they would do. > >> > Then there is the normal DRAM refresh, also done by the VIC. > > The DRAM refresh didn't steal any processor time. Of course not. That easily fits into the slots not used by the processor. > Christian Bauer wrote an article which should give you more information on > the workings of VIC than you ever wanted. > > http://www.funet.fi/pub/cbm/documents/chipdata/index.html is the place to > look - you want VIC-Article.gz Looks like something for my URL-to-read file. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ "No, it was a JOKE! You can't RUN this!" Ken Thompson ###### From: Martin ``rydis'' Rydstr|m Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 02 Dec 1998 06:23:43 +0100 Organization: The Bing! Society of Lesser Importance Lines: 22 Sender: d3rydma@licia.dtek.chalmers.se Message-ID: References: <741gtg$88i$7@irk.zetnet.co.uk> Reply-To: rydis+replies@cd.chalmers.se NNTP-Posting-Host: licia.dtek.chalmers.se Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Attribution: mr X-Url: http://www.cd.chalmers.se/~rydis/ Mail-Copies-To: rydis+copies@cd.chalmers.se X-Newsreader: Gnus v5.5/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-peer.gip.net!news.gsl.net!gip.net!howland.erols.net!newsfeed1.telenordia.se!newsfeed.sunet.se!news01.sunet.se!news99.sunet.se!news.chalmers.se!dtek.chalmers.se!d3rydma >>>>> "l" == lisard writes: l> Two questions. What's the cycle count? Would it be practical to use D as l> a TOS cache? I can only answer the first, having a 6809 ref-card by my bed: plus: LDD ,U++ ; EC C1 (5) ADDD ,U++ ; E3 C1 (6) STD ,--U ; ED C3 (5) MACRO do ; AE A1 6E 84 (5+3) ----- (24) TTFN, 'mr -- Varmt |l }t frusna m{n, : Martin `rydis' Rydstr|m, geek and drunken bastard och varmt |l }t tr|tta; : Finger me for geek code and PGP-key. : Please do ty varmt |l {r kroppens v{n : http://www.dtek.chalmers.se/~d3rydma/ : NOT quote och h}gens stav och st|tta. --Frans G. Bengtsson, R|de Orm. :: this .sig ###### From: gsc@zipworld.com.au (Sean Case) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: Wed, 02 Dec 1998 18:40:34 +1100 Organization: Marginal Lines: 47 Message-ID: References: <741gtg$88i$7@irk.zetnet.co.uk> NNTP-Posting-Host: 61.8.20.235 X-Newsreader: MT-NewsWatcher 2.3.5 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!intgwpad.nntp.telstra.net!news1.optus.net.au!optus!newsfeed.zip.com.au!the-fly.zip.com.au!gsc In article <741gtg$88i$7@irk.zetnet.co.uk>, lisard@zetnet.co.uk wrote: > On 1998-11-29 neil@franklin.ch.remove said: > :lisard@zetnet.co.uk writes: > :Then there are of course the fully orthogonal Arithmetic and > :stacking, making "+" simply: > :plus: LDD ,U++ ; EC C1 > :ADDD ,U++ ; E3 C1 > :STD ,--U ; ED C3 > :MACRO do ; AE A1 6E 84 > :Thats compact and fast. Terrific chip. At 2MHz, 1 clock per memory > :access. > Two questions. What's the cycle count? Would it be practical to use D as > a TOS cache? The cycle count for this is bloody awful; it's quicker to say: ldd ,u++ addd ,u std ,u because changing u costs cycles. Similarly, subtract becomes: ldd 2,u subd ,u++ std ,u Then, you can speed up the four-byte inner interpreter by going to direct threaded code, which has a two-byte inner interpreter: jmp [,y++] but this costs you an extra four bytes of overhead on each colon definition. Personally, I'd take the space hit in exchange for all those cycles. Using D as a stack cache is quite doable, but you'd have to be very careful about saving and restoring it--D is also your two eight-bit accumulators, and you're going to want them quite frequently. I don't know if anyone has ever done this on an '09. Sean Case -- Sean Case gsc@zipworld.com.au Code is an illusion. Only assertions are real. ###### From: john@ucc.gu.uwa.edu.au (John "West" McKenna) Newsgroups: alt.folklore.computers Subject: Re: opcodes for Zilog 8800/Intel 8080 Date: 2 Dec 1998 20:46:31 +0800 Organization: The University of Western Australia Lines: 16 Message-ID: <743cr7$ike$1@mermaid.ucc.gu.uwa.edu.au> References: <731mj4$9p1@cpca3.uea.ac.uk> <73d0i7$cg9@cpca3.uea.ac.uk> <73fggl$9b4$1@agate.berkeley.edu> <73gem8$u4l@cpca3.uea.ac.uk> <740fuc$cdm$1@mermaid.ucc.gu.uwa.edu.au> NNTP-Posting-Host: mermaid.ucc.gu.uwa.edu.au X-Newsreader: NN version 6.5.0 CURRENT #118 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!newspump.monmouth.com!newspeer.monmouth.com!dca1-hub1.news.digex.net!digex!intgwlon.nntp.telstra.net!vic.nntp.telstra.net!intgwpad.nntp.telstra.net!news1.optus.net.au!optus!news.uwa.edu.au!not-for-mail Neil Franklin writes: >> at 8 bits each (plus 4 bits for colour). >Nope. The 4 color bits are fetched over 4 separate pins of the VIC >from an 2114 (at $D800). So they don't contend with the DRAM reads. Since we're talking about two things at once here (transistor count and cycle-stealing), we're both right. The colour bits are read in parallel with the character codes on 4 dedicated pins, and so they don't take any bandwidth from main memory, but they still need to be stored somewhere. They're not read on every raster (if that were the case, VIC would spend a reasonable approximation to all of the time reading colour memory, and the processor would never get a look at it). John West