Extended 6502 Project (Logisim)

[Proxy]

rpiguy2 wrote:

For the sake of compatibility rather than adding multiplication and division as instructions couldn't you implement a 65816-like "Coprocessor" instruction and build them as peripherals? Or is that cheating? (once you add a coprocessor you can do all sorts of things, like widen the registers to avoid carries and store intermediate results, etc.)

i could, but why/how would having MUL and DIV effect compatibility? the B Register is also used for 16 bit arithmetics, and they don't change the function of any existing Instructions...
so i don't really see the point of doing that unless i were to make an addon/Co-Prcoessor to an existing 6502 CPU

[GARTHWILSON]

Proxy wrote:

GARTHWILSON wrote:

What instruction may seem to be lacking are absent probably because they would not be used much and they're easily and efficiently simulated with other instructions, like BSR (branch to subroutine), or because they would require slowing the clock down (for a given silicon geometry), or would take too much expensive silicon real estate to justify the small benefit.

how do you even simulate BSR? you would need to add a 16 bit signed value to the PC...

You don't need a fixed-location subroutine. The 65816's PER (Push Effective Relative address) takes whatever the current address is at runtime and adds the 16-bit offset that's in the instruction's operand, and pushes the result onto the stack. So then you can do:

Code: Select all

     PER  $+5                ; Put return addr on the stack, then
     BRL  <subroutine_addr>  ; branch relative long to the sbr.

It works even if the program gets loaded at a different address each time, without re-assembling or re-linking.

Quote:

I know you really like your 65816, but personally i'm currently more comfortable with my 8 bit data bus and a 16 bit Memory space.
one day when i get to 16 bits i'll be sure to look into some 65816 projects.

Even if you don't latch, decode, or use the 816's high address byte, and even if you left its accumulator and index registers in the 8-bit size, you'd still get a load of benefits. In fact, its extra instructions and addressing modes are available even if you leave it in 6502-emulation mode (although a few of them would not be very useful, like the memory-move instructions MVP and MVN since with 8-bit-only registers, they'd be confined to zero page).


Similar to the memory-mapped coprocessor idea, there's the set of large look-up tables at http://wilsonminesco.com/16bitMathTables/ for not just multiplication and inversion (which are useful for dividing, by multiplying by the inverse), but also have log, trig, square-root, and other functions. If you use the whole set, it's 2MB, which is only 1/8 of the 816's memory map but would require going through I/O or banking if you implement them on the '02. Even doing that on the '02 though, there's still a huge performance advantage.

[BillG]

Chromatix wrote:

AMD used to make a couple of FPUs that were supposed to sit on the data bus and look like I/O devices. They had their own internal register sets, and some operations took several hundred cycles to complete (though this was still a major improvement over pure software). This would be something much simpler than that, but capable of handling much wider values - as I said, the target is quadruple-precision floats.

My 6809 computer had a special socket on the CPU board for a 9511 or 9512 math processor.

http://www.cpushack.com/2010/09/23/arit ... n-and-now/

SWTPC also sold the MP-N, a card containing a National Semiconductor calculator chip.

https://deramp.com/swtpc.com/MP_N/MP_N_Index.htm

[Proxy]

GARTHWILSON wrote:

Even if you don't latch, decode, or use the 816's high address byte, and even if you left its accumulator and index registers in the 8-bit size, you'd still get a load of benefits. In fact, its extra instructions and addressing modes are available even if you leave it in 6502-emulation mode (although a few of them would not be very useful, like the memory-move instructions MVP and MVN since with 8-bit-only registers, they'd be confined to zero page).

I see your point, but it makes it sound like i should give up on the project since the '816 already seems to do very similar things...
and to be honest i'm natually prone to abandon projects like these... manually programming nearly 256 instructions really isn't appealing to noone's surprise.

GARTHWILSON wrote:

Similar to the memory-mapped coprocessor idea, there's the set of large look-up tables at http://wilsonminesco.com/16bitMathTables/ for not just multiplication and inversion (which are useful for dividing, by multiplying by the inverse), but also have log, trig, square-root, and other functions. If you use the whole set, it's 2MB, which is only 1/8 of the 816's memory map but would require going through I/O or banking if you implement them on the '02. Even doing that on the '02 though, there's still a huge performance advantage.

to be honest i'd rather just sit down with Chromatix to design and build a Sophisticated Memory mapped Co-Processor than to store 2MB of LUTs.

[BigEd]

Don't be put off by other things! The '816 has nothing to do with your project. You have you own preferences and your own vision: what's important and how to do it.

[GARTHWILSON]

BigEd wrote:

Proxy wrote:

I see your point, but it makes it sound like i should give up on the project since the '816 already seems to do very similar things...
and to be honest i'm natually prone to abandon projects like these... manually programming nearly 256 instructions really isn't appealing to noone's surprise.

Don't be put off by other things! The '816 has nothing to do with your project. You have you own preferences and your own vision: what's important and how to do it.

Sure, definitely do it however you want. I would only encourage you to take advantage of the work already done by those who have gone before, who figured out what was most useful and how it balances out with things like silicon real-estate limitations, then decide how you'll modify their conclusions for your differing set of limitations and goals.

I think Bill Mensch did an outstanding job on the '816 design, but I think he could have done even better if Apple hadn't insisted that it be able to run legacy '02 code. They knew that the Apple IIGS would not have been accepted in the market if it could not run old Apple II software.

[Proxy]

GARTHWILSON wrote:

BigEd wrote:

Proxy wrote:

I see your point, but it makes it sound like i should give up on the project since the '816 already seems to do very similar things...
and to be honest i'm natually prone to abandon projects like these... manually programming nearly 256 instructions really isn't appealing to noone's surprise.

Don't be put off by other things! The '816 has nothing to do with your project. You have you own preferences and your own vision: what's important and how to do it.

Sure, definitely do it however you want. I would only encourage you to take advantage of the work already done by those who have gone before, who figured out what was most useful and how it balances out with things like silicon real-estate limitations, then decide how you'll modify their conclusions for your differing set of limitations and goals.

I think Bill Mensch did an outstanding job on the '816 design, but I think he could have done even better if Apple hadn't insisted that it be able to run legacy '02 code. They knew that the Apple IIGS would not have been accepted in the market if it could not run old Apple II software.

makes me think that making a Co-Processor for the 65816 to enhance it's functions would seem more worth while than starting from scratch....
but then again, i have never made a Co-Processor nor have i worked with the 816 before...

I'm currently just very demotivated to continue this... I'll sleep over it.

[BigEd]

The '816 is not a great example for a new project, because a new project won't have the same constraints or cost functions.

Proxy, it would be a great shame to see you retire from this project.

And for everyone else, including me, this could be a good lesson in the cost of relating new ideas always back to the same old ideas. Much better to read carefully where someone is coming from and what they are trying to do. Write for your audience, and aim to be encouraging. Adding a smiley does not entirely defuse a grenade.

[BigDumbDinosaur]

BigEd wrote:

The '816 is not a great example for a new project, because a new project won't have the same constraints or cost functions.

Ed, don't you think saying that on a 6502 forum is a bit out of place? Of the entire 6502 family, the '816 is by far the most capable and most adaptable to the things that the 6502/65C02 don't handle well. If someone like me who had no prior experience scratch-designing a computer could get an '816-powered machine running on the first try, Proxy should have no trouble doing the same. Having working hardware on the bench beats having theoretical hardware on a sheet of paper every time. And at the risk of redundancy, it's always good to keep in mind that this is a 6502 forum.

Quote:

And for everyone else, including me, this could be a good lesson in the cost of relating new ideas always back to the same old ideas.

Virtually everything in technology today relates back to old ideas. In fact, from my vantage point of having been involved with computers for so long, I don't see all that much that is truly new. Yes, processors are faster than ever (although that curve is starting to flatten a bit), hard drives are bigger and faster, programming tools are more powerful and less taxing to use, etc. However, the basic technology is not much different than what it was 50 years ago when I was writing machine code for Post Office letter sorting computers. Or to put it in automotive terms, despite all the technological advances that have occurred in motor vehicles, we still have steering wheels, gear shift levers and brake pedals in our cars, same as what my grandparents had in their cars in the 1920s and 1930s.

A fellow I worked for for a number of years had some good aphorisms that apply here:

• In order to go forward you have to learn from the past.
  
  Evolution, not revolution.
  
  Don't reinvent the wheel!

And of course there is Santayana's timeless advice...

Quote:

Much better to read carefully where someone is coming from and what they are trying to do. Write for your audience, and aim to be encouraging. Adding a smiley does not entirely defuse a grenade.

I've read most of this topic and my impression—pardon me for being blunt—is we have yet another person who thinks he will reinvent the 6502. I hate to discourage anyone in the world of technology, but the 6502/65C02/65C816 family evolved as it did for some excellent reasons. Yes, there are things that could be different or better. That is true of virtually everything man-made.

That said, when someone suddenly gets a notion to add all sorts of bells and whistles to what is basically a (to more-or-less quote Bill Mensch) "a cost-sensitive processor" I have to ask them if they have studied the design they are aiming to make over. Using an aviation analogy, suppose I yank the engine, wings and tail off a Beech D17 and replace them with the engine, wings and tail from a P51 Mustang. Would my Beech D17 still be a Beech D17? Or, would it be a P51? (Would it even fly? Anyone brave enough to find out? ) The answer to questions 1 and 2 would be no, right? That being the case, would you call something that has features that were never part of a 6502 a 6502?

Much of what I have read in this topic is—and again I will be blunt—fantasy. Why encourage someone to take a path that likely will lead them to failure? Again using an aviation analogy, why not just encourage would-be aviators who have only a limited knowledge of aerodynamics to fully extend their arms, leap off a cliff and start flapping like hell? Even though just about everybody who has tried that has ended up punching a hole in the ground with their head, we can't be discouraging such folly, can we?

Proxy wrote:

I'm currently just very demotivated to continue this... I'll sleep over it.

Don't be discouraged. Losing motivation is often a natural response to realizing that you may have taken on more than you can handle at present. Perhaps a period of goal-evaluation would be useful. You have bitten off a very large chunk of meat that is proving to be difficult to chew and swallow. It's good to have lofty goals. However, it's even better to have realistic ones.

BTW, designing a math coprocessor for the 65C816 could make you rich and famous...well, famous, if anything.

[BigDumbDinosaur]

GARTHWILSON wrote:

I think Bill Mensch did an outstanding job on the '816 design, but I think he could have done even better if Apple hadn't insisted that it be able to run legacy '02 code. They knew that the Apple IIGS would not have been accepted in the market if it could not run old Apple II software.

It was unfortunate that Apple insisted on legacy compatibility and also on continuing to use that weird disk interface that depended on a bus anomaly. But computing is littered with stories like that, and as you noted, the ][GS likely would have done poorly without some backward compatibility.

[BigEd]

No, BDD, it's not appropriate always to push the 816 as the best solution, and it's not consensus that it is a marvellous product.

If you've managed to discourage someone, it's a bit late to re-iterate all your points and then tell someone not to be discouraged. Far better to learn the lesson.

There are already threads about how and in what ways the 816 is an appropriate choice. The polite thing to do, when you have a hobby horse such as this, if you can't bear not to mention your favourite thing, is to post a simple link to a previous thread where all these points have been made.

This forum has a good reputation for being welcoming and helpful and good natured. Let's not spoil it by pushing every thread into the same direction.

[Proxy]

Don't worry i get discouraged very quickly by about anything.

I'll still finish this though. mostly for the sake of finishing a project.

I have decided on the Instructions i want to add, there are 93 new opcodes. bringing the total amount to 244, leaving a total of 12 opcodes empty for any future use.
today i'll try to program them all in, once done i'll make an Opcode table that not only shows the opcodes but also compares their cycle times with the original instruction set.

[GARTHWILSON]

I find that when I suddenly get interested in a new field, I soak up all the information I can about it, and it quickly changes my perspectives and goals to ones that are more realistic and useful and valuable than the ones I started with.

[BitWise]

One of WDC's soft core models has a memory mapped maths accelerator. You write the multiplier and multiplicand to memory registers and read the product from another location. You could do the same for division.

[rwiker]

BitWise wrote:

One of WDC's soft core models has a memory mapped maths accelerator. You write the multiplier and multiplicand to memory registers and read the product from another location. You could do the same for division.

The C256Foenix project (which may or may not still be going) also has memory-mapped maths acceleration: https://wiki.c256foenix.com/index.php?title=GABE. The floating-point coprocessor looks fairly neat.