6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 10:42 am

All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: 6800 and 6502 compared
PostPosted: Sun Sep 09, 2012 3:55 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
(Note that I'm a 6502 fanatic, but I don't think all valid observations about the micro are necessarily flattering.)

Reading BDD's description of his file system code, I realised that the 6502 is quite awkward when dealing with pointers (addresses) in data structures. You have to copy a pointer to zero page before using it. Similarly, stack-relative addressing has to be done by hand, indexing into page one. In these respects, the 6800 is more of a computer science CPU than the 6502 is. The 6502 does of course do very well in industrial control which is what I believe it was aimed at: the limitations of zero page are not so important, and the 8-bit index registers are adequate. The consequent increase in speed, due to decreased cycle count, is welcome. (There are also criticisms of the 6800 - see this old revision of the wikipedia article.)

But enough of my opinions. I turned up some interesting historical docs (pdfs):
- Robert H Cushman writes "2-1/2 Generation μP's -$10 Parts That Perform Like Low-End Mini's" in EDN, issue Sep 20 1975
- Laurence Altman writes "Microprocessor line offers 4, 8, 16 bits" in Electronics, issue July 24 , 1975
- Microcomputer Associates write in Microcomputer Digest, issue December 1975, mentioning the above EDN artice and Motorola's attempted injunction.
- Daniel Fylstra writes "Son of Motorola (or the $20 CPU Chip)" in BYTE November 1975 Vol. 1 No. 3 (Published October 18, 1975) - this says that array handling is much less convenient on 6800.

There are several related docs to be found in Michael Holley's excellent page Motorola M6800 Microprocessor History

See also my earlier comment which grew a few footnotes, including the EDN of Oct 27 1988 quoting Chuck Peddle as "[looking] for ways to make the chip cheaper": "I would ask potential customers what they would give up out of the 6800 if I was going to give them a cost-reduced version. It turned out that most everybody had the same set of things they would give up."

Cheers
Ed

Edit: some links now broken. Some snippets of Altman's article in Google Books with (mangled, OCR) text from it (p118, Electronics, Volume 8 ):
Quote:
Microprocessor line offers 4 , 8 , 16 bits
MOS Technology's low-cost n-channel family is compatible with Motorola's 6800 ; provides 68 instructions and 11 addressing modes

by Laurence Altman , Solid State Editor

Being an alternate source to as well
accepted a microprocessor system as
Motorola's 6800 isn't bad for a medium
sized company like MOS Technology
Inc. which until recently had only
a p-channel process suitable
primarily for calculator chip
design. But being able to supply the
microprocessor system in an
advanced n-channel design that offers
the user additional benefits at a
lower cost is even better.

That's what MOS Technology has
done with its first entry into the
microprocessor field. In fact, the
Pennsylvania-based company has
introduced four software-compatible
versions of its microprocessor family
that promise to outperform similar
products already on the market -
and to do it at a lower cost.

The family's first entry is the
MCS6501, an n-channel, silicon-
gate, depletion-load device that
operates from a single 5-volt supply. A
plug-in replacement for the Motorola
6800, it will be offered for delivery
in September for an incredibly
low single-unit price of $20.
...
Peddle, marketing director for
microcomputers, felt it could be
upgraded most directly "using our
smaller-chip capability." The chip,
however, has been reconstructed to
include some key user-oriented
features. Among these improvements
are significant expansion of addressing
capability, including two real index
registers (not available on any
other single-chip device), two
powerful forms of indirect addressing,
an 8080-type READY , fast decimal
arithmetic (including subtract), and
pipelining for higher throughput.

For example , the 6501 lets a user
load, add, and store in three locations
in 9 microseconds. In another
benchmark operation, the 6501 can
move an n-length word from one
memory location to another in only
13 microseconds, compared to about
20 μs for the Motorola and 23 μs for
the Intel devices.

None of these benefits, however,
will complicate the use of the 6501
by the growing number of people
familiar with the 6800 system. The
chip is plug-compatible with the
6800, runs from the same single 5-v
clock, comes in the same 40-pin
package, uses the same 1-MHz
Motorola two-phase clocking, and
can play with any of the Motorola
peripheral or communications-
adapter interface chips. In addition,
MOS Technology will supply some
unique peripheral circuitry, including
RAMs and ROMs.

It should be pointed out, however,
that the 6501, while plug-
compatible with the 6800, is not truly
bit-compatible, but requires some
recompiling of the standard 6800
instructions. Yet the family will be
fully supported by an advanced
cross-assembler - the only "Fortran-
like" emulator available in the
industry - and a full range of easy-to-
apply documentation. Starter sets to
be offered by the company range
from a two-chip $50 set to an
advanced sophisticated microprocessor-
development terminal.

Another version of the design is a
still easier-to-use 8-bit 6502 chip.
This device requires only a single-
phase TTL clock, instead of the
Motorola two-phase clock. Or,
simpler yet, it can be latched for an RC
network to generate its own clock.
The unit price is $25.

For 4-bit systems, a low-cost
small-packaged version is also being
prooffered .
...
are two more chips now in design.
They are a Fairchild-like F-8
equivalent that contains the I/O on
the chip and a design that Peddle
calls a pseudo 16. Upward-software-
compatible with the others, it's
capable of 8-bit transfers and 16-bit
operands.
...

Box: What's on the chip
Future With its advanced n - channel
...
program counter, an instruction
register, instruction decoder and
control circuits, two index
registers, and all input and output
buffers needed to operate with the
Motorola 8-bit bus system. The
chip architecture differs from
that of the 6800 in that it has one
accumulator and two index
registers, while Motorola's has two
accumulators and no index
register.

[slugs not yet slotted in:]
... the Rounding out mos
Technology's design because Chuck
Peddle , marketing director for

Technology's arithmetic - and - logic unit , a pro
gram counter , an instruction reg
ister , instruction decoder and are ...

immediate microprocessor efforts



Last edited by BigEd on Mon Oct 05, 2020 7:44 am, edited 15 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 10, 2012 12:12 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8509
Location: Midwestern USA
BigEd wrote:
Reading BDD's description of his file system code, I realised that the 6502 is quite awkward when dealing with pointers (addresses) in data structures. You have to copy a pointer to zero page before using it. Similarly, stack-relative addressing has to be done by hand, indexing into page one.

Indeed. While my filesystem code certainly could be written to run on a 65C02, it would be bigger and more complicated, would use more RAM—especially zero page, and far slower due to all the required indirect addressing. The 65C816 alleviates a lot of the pain, especially when considering Ed's example of working with an address table that is part of a larger data structure. The combination of 16 bit registers, stack relative addressing and stack indirect addressing essentially frees one from having to use indirect addressing to leap over the single page limits of the 'C02. Sixteen bit addressing allows direct indexing into a table that exceeds 256 bytes (e.g., indirect address blocks in a file system, which may have up to 256 32-bit addresses).

BigDumbDinosaur wrote:
...where the expression LBO*S_DWORD,S_DWORD would magically index to an entry in IBAT (if only it were that simple in assembly language).

An expression such as LBO*S_DWORD,S_DWORD is indeed awkward to implement on the 65C02, more so on the 6502 with its inability to push .X and .Y without using the accumulator. It's not bad with the '816 because code like the following is small and easy to write:

Code:
;
;
;   load 32 bit value from a table...
;
         rep #%00110000        ;16 bit registers
         lda index             ;table index somewhere in RAM
         asl                   ;quadruple it to align it...
         asl                   ;with a 32 bit "slot"
         tax
         lda table,x           ;get LSW
         ldy table+2,x         ;get MSW
         tay
;
   ...program continues...

Accomplishing the same thing with the 'C02 would mean much more code, plus the use of zero page to store a pointer to the table, since we're limited to an eight bit offset. Plus how would you shift a 16 bit value without using RAM? The above makes no use of RAM, except to get the index and read from the table.

I'm still massaging a program that generates a quasi-file structure on disk that exactly models the behavior of a true filesystem as bytes are written into a real file—the output essentially is a 4 GB file minus the directory listing (the inode is defined in core). The purpose of this exercise is to allow me to test my file access code on known cases before trying it in actuality. I will post the listing when done so it can be seen where the '816's 16 bit registers and enhanced addressing capabilities made for a relatively small and fast executing program.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Mon Sep 10, 2012 8:20 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 10, 2012 8:01 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Best way to compare performance is to solve the same problem on both micros, using the most appropriate tactics in each case (but broadly the same algorithm, of course) - we'd expect different results from different tests, depending on which strengths and weaknesses they exercise.

Elsewhere, Garth points out a particular datapoint:
GARTHWILSON wrote:
... the 6502 ran Ragsdale's fig-Forth 25% faster than the 6800 at a given clock speed


And nearby Egan points out another:
datajerk wrote:
... 6502 assembly Pi to 1000 digits. [...] On the Apple I (960 KHz) it takes 2:15. I had to reduce the amount of unrolling and dump all tables to fit in [4K].
[...]
What is most interesting is that I created a 6800 version this weekend, using the Apple-1 version as a guide. And it runs in 2:12 @ 960 KHz. That was unexpected. The dual accumulators really helped optimized the div/mult code.

Edit to add: more notes, a diagram, and code later in that thread.


Last edited by BigEd on Mon Sep 10, 2012 9:55 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 10, 2012 8:05 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
I don't have a precise or graphical breakdown of the two machine's datapaths, but it looks like the 16-bit incrementer on the 6800 takes up loads of space. As does the decimal adjust of the 6502. More crucially for each is the prospect of higher clock speeds: a 16-bit path, if there is one, will hurt. I read somewhere Rod Orgill saying that the 6502's PC wrapping from FFFF to 0000 is the worst case timing.


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 10, 2012 8:30 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8509
Location: Midwestern USA
BigEd wrote:
I don't have a precise or graphical breakdown of the two machine's datapaths, but it looks like the 16-bit incrementer on the 6800 takes up loads of space. As does the decimal adjust of the 6502. More crucially for each is the prospect of higher clock speeds: a 16-bit path, if there is one, will hurt. I read somewhere Rod Orgill saying that the 6502's PC wrapping from FFFF to 0000 is the worst case timing.

Yet adding and subtracting in BCD on the 65xx causes no execution penalty. Performance issues don't come to the forefront until multiplication and division get involved, operations that have never been a strong suit of the first and second generation eight bit MPUs.

What's interesting about the 65C816 is that using extended addressing generally penalizes the program by only one clock cycle. On average, use of the '816's 16 bit registers in multi-byte operations (e.g., address increments and decrements) can save as much as 40 percent in execution time, even thought data movement between core and processor occurs 8 bits at a time. It was this understanding that led me to totally scrap the 65C02-based machine language monitor I wrote for POC and start over with an '816-specific version. The difference in compute-bound performance, especially searching memory for patterns, was quite noticeable (and my algorithm is hardly exemplary).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 10, 2012 8:51 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
BigDumbDinosaur wrote:
BigEd wrote:
I don't have a precise or graphical breakdown of the two machine's datapaths, but it looks like the 16-bit incrementer on the 6800 takes up loads of space. As does the decimal adjust of the 6502. More crucially for each is the prospect of higher clock speeds: a 16-bit path, if there is one, will hurt. I read somewhere Rod Orgill saying that the 6502's PC wrapping from FFFF to 0000 is the worst case timing.

Yet adding and subtracting in BCD on the 65xx causes no execution penalty.

Indeed, but in that post, I was comparing implementation costs and tradeoffs, not cycle counts.

Quote:
Performance issues don't come to the forefront until multiplication and division get involved...
You perhaps mean differences between the 6800 and 6502 are not significant for addition and subtraction? As we've seen, other algorithms also show differences. But I think also one would compare the costs of the various addressing modes, and the additional cost of decimal adjust on the 6800. It's clear that the 6502 designers were prepared to spend a lot of chip area on faster BCD.

Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 10, 2012 9:49 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8509
Location: Midwestern USA
BigEd wrote:
It's clear that the 6502 designers were prepared to spend a lot of chip area on faster BCD.

Given that the market originally targeted by MOS Technology was not computers but machine control, where lots of decimal numbers get used, it made sense to minimize the pain of decimal arithmetic. As you say, more than a little chip area was committed to this feature, a cost that was not insignificant in those days. Fortunately for MOS, and we 6502 enthusiasts, the 6502 was noticed by two guys in a garage and thus the manufacturing volume was created that would justify the chip area gamble. The rest, as "they" often say, is history.

Speaking of BCD, I have used it quite a bit in 6502 programs. In the mid-1980s I wrote a checkbook program that had many of the features one might find in Quicken. At first, I called the arithmetic functions in the BASIC interpreter ROM but got fed up with the usual decimal to binary errors and decided to add BCD math to the program. That was the end of the errors. I also gained better control over formatting numbers for display and printing. My scheme used 4 byte signed numbers, with the sign bit carried in the MSB of the number. The numbers were in big-endian format to simplify comparisons and math procedures. Because of the fixed format I used performance wasn't an issue.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 10, 2012 10:12 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8545
Location: Southern California
Quote:
but got fed up with the usual decimal to binary errors

Just internally represent $.01 as 1, a dollar as 100 (ie, 64H), etc.. If you need tenths of cents, represent a cent as 10 (ie, 0AH), a dollar as 1000 (ie, 3E8H), etc.. The representation is 64H% correct, in scaled-integer.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 11, 2012 4:05 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8509
Location: Midwestern USA
GARTHWILSON wrote:
Quote:
but got fed up with the usual decimal to binary errors

Just internally represent $.01 as 1, a dollar as 100 (ie, 64H), etc.. If you need tenths of cents, represent a cent as 10 (ie, 0AH), a dollar as 1000 (ie, 3E8H), etc.. The representation is 64H% correct, in scaled-integer.

Actually, I did consider scaled integer—I had first encountered the basic idea in the late 1970s on locomotive event recorders, where distance and time were resolved to 0.1 miles and 0.01 seconds—but decided I could just as easily do it in BCD without incurring any significant performance penalties. It was rare in a checkbook program that multiplication and division were needed and no transcendental functions were required at all. Hence most of the math was addition and subtraction, which runs without a performance penalty in binary or BCD. The ease of conversion between ASCII and BCD was also a "selling point."

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 11, 2012 10:20 am 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
One of the first machines I ever programmed (an ICL 4/30) provided a full set of packed decimal arithmetic operations (including divide) on signed BCD numbers up to 31 digits. As the machine was lacking binary multiply and divide we used them quite intensively. It also provided a 'edit under mask' operation that formatted a BCD result into a printable string complete with floating current symbol, commas every three digits and suppressed leading zeroes.

All very COBOL friendly

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 09, 2014 5:08 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Just to note datajerk's comment in another thread, where he finds that a 6800 version of a Pi calculation runs about 30% faster than the 6502 version:
viewtopic.php?p=21304#p21304

Edit: also Garth's later comment: "the 6502 ran Ragsdale's fig-Forth 25% faster than the 6800 at a given clock speed"

Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 26, 2020 8:17 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
See also the new thread
The 6501 and 6800

Perhaps best to continue discussions over in that new thread.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: