"Homebuilt" 6502 cpu's

Rob Finch · Post by **Rob Finch** » Fri Jan 17, 2003 7:14 am

Are there any people in cyberspace that have designed or built their own renditions of the 6502 processor ?

How faithfully does it represent the 6502 ? Have you added any custom instructions ? Have you changed it from 8 to 16, 32 or 64 bits ?

I'm currently working on my 5th! rendition. The first one was a Verilog implementation of original 6502 with no added features and it seems to work fine. The next three I've gotten partly finished then scrapped because I didn't like the look of the results. I just can't seem to do the 6502 justice.

I'm thinking of taking a different approach with this version. Originally I wanted a 32-bit version capable of also executing original 6502 code. But now I'm thinking of trying to capture the flavour of the original in a modernistic 32-bit form.

Rob

GARTHWILSON · Post by **GARTHWILSON** » Fri Jan 17, 2003 9:31 am

This link just appeared on the 6502 Yahoo forum:

http://translate.google.com/translate?u ... uage_tools

That's all one URL, so depending on how this appears, you might have to paste it into something and get rid of any CR characters that snuck in. This is the Google English translation of a young German man's project. He was determined to make his own processor without an FPGA, even if he had to do it with discrete transistors! He made a big reduction in the number of necessary gates by using large EPROMs for instruction decode, and then added large look-up tables for math functions in the EPROMs too. Of course it would not be practical at all to use this much silicon real estate if he were to integrate it all into a single IC.

Then there's Ruud Groetjes [Edit: it's Baltissen, not Groetjes], a Dutchman, working on a 32-bit 6502, the 65GZ032, with a lot of big-computer features. See the 65GZ032 Yahoo forum. See also http://Ruud.C64.org .

Look back through the archives of this forum, the Delphi 6502 forum, and the Yahoo 6502 forum for others who have written a 6502 in VHDL or Verilog. There are more than you might expect.

If I were ever to try it, some instructions I might like to investigate adding are:

STF STore FF to a memory location without affecting processor registers. Many times a byte is used as a flag, and STZ clears it, so STF would set it much more efficiently than STZ, DEC.

DIN and DDE Double INcrement and Double DEcrement. Same as INC INC or DEC DEC but only two clocks instead of four, and the C flag would tell if you went from FF to 01 or vice-versa without having to test in between the two INC or DEC instructions. This is particularly useful in higher-level languages that are always incrementing pointers to the next two-byte address.

SWN SWap Nybbles $12 becomes $21. Useful in cobbling together fast math routines. 65816 has an XBA instruction to swap bytes in the 16-bit accumulator.

JSR relative long, to anywhere in the 64K memory space. (This and long relative branching are possible on the 6502 by doing JSR to a routine that ends with JMP(ind), but it's very inefficient. The JSR puts the calling address on the stack so the routine can add the offset to it.)

Several other desirables are already implemented in the 65816, like a long relative branch, stack-relative addressing, block move, push an indirect address or a literal on the stack, movable base page that doesn't have to be ZP, 16-bit stack pointer, etc..

Putting just a few of Forth's internals like NEXT , nest , and unnest in microcode would make a big difference in execution speed and I believe could be used for other higher-level languages as well.

There is a reason of course why microprocessor designers don't just fill the op code table in with all kinds of cool-but-lesser-used instructions just to avoid wasting op code combinations. I'm not a processor designer, but I'm sure the added levels of instruction-decoding logic that would be necessary would reduce the maximum operating speed. At some point you have to strike a balance that will result in the best performance for the intended die size (relating to cost and yield), process geometry, etc..

Garth

kc5tja · Post by **kc5tja** » Fri Jan 17, 2003 9:47 pm

GARTHWILSON wrote:

Several other desirables are already implemented in the 65816, like a long relative branch, stack-relative addressing, block move, push an indirect address or a literal on the stack, movable base page that doesn't have to be ZP, 16-bit stack pointer, etc..

I had sent an instruction suggestion to WDC the other day, and got an e-mail back from Bill Mensch himself. I was surprised at that.

Anyway, I recommended adding two instructions: ADX and ADY -- add a signed value to either X or Y. It would have the same addressing modes as CPX and CPY. Because the value added is sign-extended, there would be no immediate need for a SBX/SBY (subtract from X/Y) instruction. Also, ADX/ADY would behave as if the carry flag were pre-cleared. Thus, doing a 16-bit or 32-bit addition with these instructions would become about as efficient as doing an 8-bit or 16-bit addition with the existing processors.

Quote:

Putting just a few of Forth's internals like NEXT , nest , and unnest in microcode would make a big difference in execution speed and I believe could be used for other higher-level languages as well.

While this is true, I wouldn't rank this as terribly high priority.

I would definitely consider, however, adding a rational math coprocessor to the chip. Why rational and not floating point? Because it works with integers and basically consists of an integer multiplier/divider, which takes a whole lot less transistors than a floating point processor. The only really specialized piece of hardware in it would be the rational reducer, which would reduce a fraction to its lowest form.

In addition, rationals can express certain mathematical quantities more precisely than floating point in the same memory space (e.g., 355/113 for Pi, for example).

Note that the dynamic range of the RPU (for lack of better term) wouldn't appear to be as great as an FPU at first, but there are three ways to mitigate this in software:

1. Use the RPU with an explicitly 65xx-managed exponent. This gives a hybrid approach that gives the advantages of both, at a slight expense in speed.

2. Take advantage of units. That is, why multiply a number like 25175000 by .0000009 when you know that the relative exponents of the two will cancel, and you need only multiply 25175 by 9 and scale the result to get the same value?

And finally,

3. Make the RPU scalable so it can handle multiple precision integers in both the numerators and denominators of each rational (e.g., give it a carry/borrow bit, and maybe a few other flags, to let it handle integers larger than it's natural word size). Even if this is done at the cost of speed, it'll still be much faster than the 65xx's own execution speed for this type of math.

This isn't as crazy as it sounds. When I was working for Hifn, I worked quite regularly with a "Bignum" coprocessor ironically called the 6500. The 6500 had 16 registers, each was 1024 bits in size. Yes, 1024 bits. It could do addition (with or without carry), subtraction (with or without borrow), multiplication, division, exponentiation, logical shifting, or any of the above in modulo arithmetic. While it wasn't used for rational math, lord knows it could easily have done so (we actually used it to support real-time cryptography and very high confidence random number generation). It could complete most operations in linear time, depending on where the most significant bit of the operand was located (internally, it had a 32-bit ALU). And it was fast -- faster than a Pentium at working with such large quanitites. Although, a Pentium IV did beat it ... finally.

I'm not sure if Hifn is still making these chips in discrete components; I'm pretty sure they are, but they're probably sunsetting them, as its core has been integrated into other, vastly more sophisticated network processor chips. Math coprocessors have never been Hifn's primary market anyway.

Anyone working on an existing 65816-based design that has a very high need for fast math with high precision, the Hifn 6500 is a very viable option for an external rational math coprocessor.

Rob Finch · Post by **Rob Finch** » Sat Jan 18, 2003 12:56 am

I had a look at that cpu that turned up on 6502 yahoo group.

I especially liked the "high-speed aluminum" arithmetic.

I guess google didn't didn't translate it with 100% accuracy.

kc5tja · Post by **kc5tja** » Sat Jan 18, 2003 12:59 am

Rob Finch wrote:

I had a look at that cpu that turned up on 6502 yahoo group.

I especially liked the "high-speed aluminum" arithmetic.

I guess google didn't didn't translate it with 100% accuracy.

Now that's the understatement of the century. And forget about translating anything inside tables -- those were still every bit as German as it could get.

That being said, I checked out Ruud's site, and saw absolutely NO mention of the 65GZ032 of any kind. If someone can provide a more detailed link, that'd be great. Otherwise, I have to assume the project has been killed off.

orac · Post by **orac** » Sat Jan 18, 2003 2:48 am

Hi Everyone,

Deffinitetly add "Swap nibbles".

The PIC and Z8 have it but the 6805/6811 don't.
8085, X86, Z80 and 68K also don't.
Motorola came to their senses with the 6808 and
finally added a swap nibbles command.

Bye,

Paul

kc5tja · Post by **kc5tja** » Sat Jan 18, 2003 3:16 am

orac wrote:

Deffinitetly add "Swap nibbles".

This can be implemented fairly easily with a 256-byte look up table, but I still agree a swap nybbles instruction would be nice. It'd allow for some really fast shifts by 4 bits.

Perhaps something to consider are the following commands:

Code: Select all

AS8 -- Arithmetic shift right 8 bits
AS4 -- Arithmetic shift right 4 bits
AS2 -- Arithmetic shift right 2 bits
RR8 -- Rotate Right 8 bits -- basically a swap bytes instruction for 65816
RR4 -- Rotate Right 4 bits -- For 8-bit quantities, swaps nybbles.
RR2 -- Rotate Right 2 bits
RL8 -- Rotate Left 8 bits -- just in case a 65832 really does see the light of day
RL4 -- Rotate Left 4 bits
RL2 -- Rotate Left 2 bits

This would allow shifting of a hardcoded, though arbitrary, shift count in O(n log n) time instead of O(n) time.

GARTHWILSON · Post by **GARTHWILSON** » Sat Jan 18, 2003 3:58 am

All those shift-and-rotate instructions for different numbers of bits would fill in a second table of op codes by the time you get all the different addressing modes. It would be better to just use one instructions with all the addressing modes, using one operand byte to tell how far in which direction to shift.

> I had a look at that cpu that turned up on 6502 yahoo group.
> I especially liked the "high-speed aluminum" arithmetic.
> I guess google didn't didn't translate it with 100% accuracy.

It looks like every occurrence of "aluminum" should be "ALU".

> That being said, I checked out Ruud's site, and saw absolutely
> NO mention of the 65GZ032 of any kind. If someone can provide
> a more detailed link, that'd be great. Otherwise, I have to assume
> the project has been killed off.

I was trying to figure out how I got onto the 65GZ032 Yahoo forum. I can't remember. I suppose someone posted a link on the 6502 Yahoo forum. Here's a URL for a post last week on the progress of the project (including about the 21-bit address offset field for the 32-bit branching instructions):
http://groups.yahoo.com/group/65GZ032/message/202
I think it will let you read it even if you're not a forum member-- you just won't be able to post until you are.

Garth

kc5tja · Post by **kc5tja** » Sat Jan 18, 2003 4:01 am

GARTHWILSON wrote:

http://groups.yahoo.com/group/65GZ032/message/202
I think it will let you read it even if you're not a forum member-- you just won't be able to post until you are.

You must be a member to view these messages.

GARTHWILSON · Post by **GARTHWILSON** » Sat Jan 18, 2003 9:09 am

> You must be a member to view these messages.

If you're interested in joining, try
http://groups.yahoo.com/group/65GZ032/join

If you still can't get there from here, I can E-mail Ruud through the forum for you for instructions of how to get on.

Check out also:
http://www.ucc.gu.uwa.edu.au/~john/65020.html
for another 32-bit 6502 work in progres.

As I was looking through archives on the 6502 Yahoo forum, I see that plenty of you guys are on that one too. Rob Finch, I now see that you already knew some of what I posted. I take it you're trying to stir up more discussion here on the same subject-- which is still a good idea. You posted an address, bc_cpu@yahoogroups.com , for CPU design discussion, but that's an E-mail address and not a website. Does sending E-mail to that address somehow sign us up automatically to get all the discussion E-mails sent to us?

Garth

kc5tja · Post by **kc5tja** » Sat Jan 18, 2003 6:16 pm

GARTHWILSON wrote:

Check out also:
http://www.ucc.gu.uwa.edu.au/~john/65020.html
for another 32-bit 6502 work in progres.

The 65020 processor is a definite possibility for a viable 32-bit architecture. When I home-built my 4-bit processor (which didn't do anything useful, I might add, but it was fun all the same!) many eons ago, I upgraded the architecture to 8-bits by doing basically the same thing. While the 8-bit CPU read in only 8-bit instructions, only the low 4-bits counted (they were the same instructions as the 4-bit CPU), and the top 4 bits were ignored. Now I could have added a lot more instructions by using those top four bits, but if I kept them zero, they mapped to the original, 4-bit architecture's instructions.

This means that, if I were to write a loader for the 4-bit software on the 8-bit architecture, I'd do it the normal way, making sure to AND each byte with $0F. The software would run the same, with the same instruction timings.

I've always wondered why more people didn't extend their processor architectures that way. It seems like such an obvious solution to the problem of backward compatibility, and it keeps the hardware extremely simple. It's true that understanding memory layout becomes a bit of an issue, but with good documentation, only the whiners will complain.

Kudos to the architect of the 65020!

John West · Post by **John West** » Tue Jan 21, 2003 9:43 am

GARTHWILSON wrote:

Check out also:
http://www.ucc.gu.uwa.edu.au/~john/65020.html
for another 32-bit 6502 work in progres.

"In progress" is a bit of an overstatement. I've been promising myself I'll learn enough VHDL to do it for the past 10 years. One day...

Wally Daniels · Post by **Wally Daniels** » Tue Jan 21, 2003 4:35 pm

Hello All,

Looking quickly on the discussion of HomeBuilt CPU's I wondered
if anyone on the list had investigated using a Coprocessor with
the 02 or 816. Are there any Coprocessors availible that can be used with the 65xx family ?

-Wally

kc5tja · Post by **kc5tja** » Tue Jan 21, 2003 8:18 pm

Wally Daniels wrote:

Hello All,

Looking quickly on the discussion of HomeBuilt CPU's I wondered
if anyone on the list had investigated using a Coprocessor with
the 02 or 816. Are there any Coprocessors availible that can be used with the 65xx family ?

-Wally

I can't think of any, but I've often wondered how difficult it'd be to build a rational math coprocessor using simple register accesses (think TTA here). While the register interface wouldn't be hard, it's the guts that I've been wondering about.

orac · Post by **orac** » Tue Jan 21, 2003 9:37 pm

Hi Everyone,

Here are some coprocessors that
target the PIC, but could probably
be used.

Enjoy!

http://www.al-williams.com/pak1.htm

Bye,

Paul

"Homebuilt" 6502 cpu's

"Homebuilt" 6502 cpu's

swap nibbles

Re: swap nibbles

Math CoProcessors

Re: Math CoProcessors

Coprocessors