6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 7:12 am

All times are UTC




Post new topic Reply to topic  [ 186 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 13  Next
Author Message
 Post subject:
PostPosted: Thu Jun 25, 2009 1:17 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
GARTHWILSON wrote:
Quote:
All of this discussion is well and good, especially ideas on memory management. But, how does it "improve" the 65xx?

VBR started the topic to discuss improvements to the hardware, especially the processor's instruction set. I took it further into extending bus and register widths to get more power while actually dropping some addressing modes. After apologizing for kind of hijacking the topic, I got no complaint from VBR but others showed interest. If this would, down the road, lead to developing a more powerful 65-family processor, it can only be good to discuss things we might want it to be capable of while still making it clearly a 65-family processor.

Don't get me wrong (as another member apparently has). The thought of a super-6502 is tantalizing. All I was pointing out is if all these hardware enhancements were built into the processor, it would cease to be a 6502. The hallmarks of the 6502 architecture are its simplicity and nearly orthogonal instruction set. Clearly, turning the MPU into something that looks like one of Intel's fine products would result in a non-6502 -- a fake one, if you will. :) However, don't let that stop the discussion. I, for one, would love to see multiply and divide instructions.


Last edited by BigDumbDinosaur on Fri Jun 26, 2009 7:04 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Jun 25, 2009 10:03 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
Quote:
All I was pointing out is if all these hardware enhancements were built into the processor, it would cease to be a 6502.

I think the enhancements can be made without undoing its "6502ness", although we won't get as much performance per dollar as what's in modern desktop computers. For the hobbyist and other low-volume user who, instead of treating it like an appliance, will put a lot of time into building and programming custom applications without the benefit of industry-strength resources, I do believe it will be a lot more friendly.

Quote:
The hallmarks of the 6502 architecture are its simplicity and nearly orthogonal instruction set. Clearly, turning the MPU into some that looks like one of Intel's fine products would result in a non-6502 -- a fake one, if you will. :)

My own dream for it is to produce a bigger 6502 that allows you to do more with it, but doesn't force you to, ie, doesn't keep you from treating it as a simple (just bigger) 6502 that feels as comfortable as your favorite pair of slippers. I followed the 65GZ032 project with interest but was not able to contribute much at all because they were doing what you said, and the only thing 6502 about it was that it had a mode that would run legacy code directly. The rest of it was unrecognizable as a 65-family processor. (If you want to check it out, go to Yahoo --> Groups, then in the "Find a Yahoo! Group" box, type in "65GZ032". Edit: The 65GZ032 Yahoo group is apparently gone. Andre has some info on it at the link above.

Quote:
However, don't let that stop the discussion. I, for one, would love to see multiply and divide instructions.

I see these touted on some microcontrollers where the manufacturer's reason for putting them in seemed to be more for show-off than practical. In the many embedded systems I have developed and brought to market, never once have I needed multiply or divide instructions. This one is different though. I definitely use them on my workbench computer, and it would be a big benefit to be able to do a multiply in a few clocks instead of hundreds, and of course to speed up the divide too (although I'm not sure there's any way to do that one quite as fast. Edit, later: My website section on 16-bit look-up tables has a 32-bit inverse for every 16-bit input, so you can divide by multiplying by the inverse. You can speed up the multiply also with the multiply table.)

I personally would not push for a floating-point unit though. (I know you weren't either, but it's related and the subject will probably come up.) Especially with 32-bit registers and possibly a 64-bit one for 32*32 multiply and 64/32 divide in fixed-point, the small additional benefit that floating-point would give would not justify the huge additional hardware overhead. I started a primer on fixed-point/scaled-integer arithmetic at viewtopic.php?t=716 to show that it is capable of far, far more than most people give it credit for, but never finished. Edit: The front page of the section of my website on large look-up tables for fast, accurate math has an article on very effective use of scaled-integer math.

My 65c02 workbench computer (actually, 65802 in '02 emulation mode) does a 2048-point complex FFT in about 5 seconds in Forth (not even assembly language) without floating-point. If I went to a 16MHz '816 and optimized the routine, I know I could get it under half a second. If I had a multiply op code that took no more than a few clocks, that would be speed it up dramatically and make it more suitable for real-time DSP.

I'm using 16-bit cells though, so when I'm running the transform on a set of samples from an 8-bit A/D converter, only a small percentage of the samples can have the highest two bits set or I'll get overflows in the intermediate results at 2K samples. (That's not too a big problem with audio though, as the average voltage tends to be low compared to the peak voltages.) If I went up to 4K or 8K samples, I'd have to further reduce the input amplitude; but with 32-bit standard cells instead of 16-bit, the problem goes away.

_________________
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  
 Post subject:
PostPosted: Fri Jun 26, 2009 4:17 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
Integer multiply and divide instructions can do a lot for simplifying certain types of programming situations, especially those involving pointer arithmetic or bitmap addressing. Such instructions can also be the building blocks for FP routines implemented in software, as ultimately all FP work can be reduced to integer operations of varying sizes and types.

As I said, creeping featurism will make the 6502 into something that is antithetical to the core philosophy of the MPU, just as Windows is antithetical to the UNIX philosophy. You're correct in saying enhanced features should be off by default, and enabled only if the programmer needs them.

Regarding the use of a 32 bit data bus, I would be more inclined to follow in the footsteps of the '816 and make register width a selectable feature, with consecutive reads or writes on memory if a data width greater than 8 bits is selected. This arrangement would open the door to being able to insert the new, improved 6502 into an existing board and not have to get worked up over the hardware implementation.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 26, 2009 4:28 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
Quote:
Regarding the use of a 32 bit data bus, I would be more inclined to follow in the footsteps of the '816 and make register width a selectable feature, with consecutive reads or writes on memory if a data width greater than 8 bits is selected. This arrangement would open the door to being able to insert the new, improved 6502 into an existing board and not have to get worked up over the hardware implementation.

That sounds like the 65832, whose full spec and probably verilog or VHDL is already in place. (I have a paper copy of it.) I wonder if WDC would license that to us if we wanted it. They finished designing it but decided not to make hardware until they had an order. What I'm looking for is both simpler and more powerful, but it definitely won't go into existing boards.

_________________
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  
 Post subject:
PostPosted: Fri Jun 26, 2009 7:12 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
GARTHWILSON wrote:
That sounds like the 65832, whose full spec and probably verilog or VHDL is already in place. (I have a paper copy of it.) I wonder if WDC would license that to us if we wanted it. They finished designing it but decided not to make hardware until they had an order. What I'm looking for is both simpler and more powerful, but it definitely won't go into existing boards.

The usual chicken-and-egg hardware situation. I wonder how big an order would be required to prod WDC into actually fabbing the thing.

Speaking of VHDL, right now I'm in the very early stages of concocting an '816-based system that will most likely use one or more CPLDs to handle the glue logic. The memory mapping scheme I'm considering will require more than the average number of chip selects to best use available RAM. However, if implemented with 'LS or 'HC type logic, I foresee where too much prop delay will get into the picture and it won't be possible to crank up Ø2 to the max. Writing the VHDL to make this mess work, plus testing the results, will keep me out of the local taverns on Saturday nights. :)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 26, 2009 7:43 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
Quote:
However, if implemented with 'LS or 'HC type logic, I foresee where too much prop delay will get into the picture

How 'bout 74AC/ACT?

_________________
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  
 Post subject:
PostPosted: Sun Jun 28, 2009 4:06 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
Here's a repeat of a post I made on Rob Finch's bc_cpu Yahoo forum in June of 2006:
--------------------------
I just got a book offer in the mail for a book called "Microprocessor Design—A Practical Guide from Design Planning to Manufacturing" by Grant McFarland, published in 2006 by McGraw-Hill. 408 pages, ISBN: 0-07-145951-0. I'll put a little more here that's not on the website. The paper that came says on the front:

    Master the basics of microprocessor design the easy way with this hands-on step-by-step guide. Proven microprocessor design crash course keeps your career on the fast track. You get a wealth of tested techniques to help you:

    • Plan for processor design flow and calculate design time and product cost
    • Analyze trade-offs in choosing an instruction set
    • Understand the functional areas of a processor and their impact on performance
    • Construct logic equations required to simulate processor behavior
    • Convert logic design equations into a transistor implementation
    • Produce layout drawings required for fabrication
    • Manufacture integrated circuits
    • Choose the most cost-effective packaging
    • Test and de-bug processors before shipping to customers

The web page above gives the name of each chapter, but here are some more details: (I shortened some things to not have to type so much)

    1. The evolution of the microprocessor
      the transistor
      the IC
      the µP
      Moore's law


    2. computer components
      bus standards
      chipsets
      processor bus
      main memory
      video adapters (graphics cards)
      storage devices
      expansion cards
      peripheral bus
      motherboards
      BIOS
      memory hierarchy

    3. design planning
      processor roadmaps
      design types and design time
      product cost

    4. computer architecture
      instructions
      instruction encoding

    5. microarchitecture
      pipelining
      designing for performance
      measuring performance
      microarchitectural concepts
      life of an instruction

    6. logic design
      overview
      objectives
      intro to hardware description language
      logic minimization

    7. circuit design
      MOSFET behavior
      CMOS logic gates
      sequentials
      circuit checks

    8. layout
      crating layout
      layout density
      layout quality

    9. semiconductor manufacturing
      wafer fab
      layering
      photolithography
      etch
      example CMOS process flow

    10. µP packaging
      package hierarchy
      package design choices
      example assembly flow

    11. silicon debug and test
      design-for-test circuits
      post-silicon validation
      silicon debug
      silicon test

Hopefully it will inspire someone. Doing it in programmable logic would eliminate steps 7 through 10.

[Edited 2/20/18 to update the URL.]

_________________
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  
 Post subject:
PostPosted: Sun Jun 28, 2009 10:05 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
There's an important activity I'd call 'verification' which shouldn't be underestimated. For a 6502 or close relative that would involve showing that all the instructions act as they should, including response to interrupts, RDY, decimal mode and how they affect the flags. The more complex and more novel the design, the more there is to do in this phase - even minimal pipelining makes it harder.

There's a big advantage in using reconfigurable logic: you can implement early and keep revisiting the design, because you haven't the high costs of tooling and manufacture to deal with.

There's normally also an activity of bringing up a tool chain: an assembler and a monitor in this case, maybe a compiler and debugger in the usual case.

I would recommend an incremental approach: start with a 6502 and then add features and test cases to it. Or, start with a well-understood RISC like ARM or MIPS. If you're looking for a clean and usable successor to 6502, start with a study of existing cores: ARM should be high on that list. If I recall correctly, the increment/decrement addressing modes allow any register to act as a stack pointer, and the conditional execution is a nice approach to short forward branches.


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 28, 2009 1:59 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
Fellow poster Rob Finch has a 6502 core in verilog - see this previous thread which also covered 6502 enhancements.

There's more choice with VHDL: see Sprow's, which derived from Free-ip's 6502, and see also FPGAarcade's version of opencore's T65 (page also links to Peter Wendrich's FPGA-64)

(Looks like the T65 also includes a 65816 core)

For completeness, I also found the M65 in a proprietary HDL.

I just found out that the Cray-1 was clocked at 80MHz, so for me that defines a worthwhile target clock speed!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Jun 30, 2009 9:09 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
Quote:
There's an important activity I'd call 'verification' which shouldn't be underestimated

That would fall under #11 above.

Quote:
There's a big advantage in using reconfigurable logic: you can implement early and keep revisiting the design, because you haven't the high costs of tooling and manufacture to deal with

which is why doing it in programmable logic instead of a custom IC would eliminate steps 7 through 10.

Quote:
There's normally also an activity of bringing up a tool chain: an assembler and a monitor in this case, maybe a compiler and debugger in the usual case.

I asked Mike Naberezny about adding a new forum for processor improvements on the forum index (as Tony suggested), and while he didn't mind adding another for a class of topics that would keep coming up, the very fact you mention is why he preferred not to do it at this time—that some of the issues would fall under hardware, some under programming, some under EhBASIC, some under Forth, some under simulation, etc., which are all forums we already have.

Quote:
I would recommend an incremental approach: start with a 6502 and then add features and test cases to it. Or, start with a well-understood RISC like ARM or...

That's basically what I would like to do—start with a 6502 but just extend everything to 32 bits, with not much extra. I should look into ARM, but I still keep hoping to keep it 6502-comfortable.

Thankyou for the links. I had forgotten about the other topic started by Rob Finch himself, to which I made the first reply. Now maybe I can finally get hold of him with the Email address on the web page that appears to be his. I never knew the "bc" in his bc_cpu Yahoo forum stood for "Bird Computer."

And wow, that BMOW computer you linked is insane! All done in 74xx logic, without a microprocessor. What an accomplishment!


Image Image

Image Image

Image Image

Image Image

Image Image

_________________
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  
 Post subject:
PostPosted: Tue Jun 30, 2009 9:48 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
GARTHWILSON wrote:
Quote:
There's an important activity I'd call 'verification' ...

That would fall under #11 above.

Quote:
... using reconfigurable logic: you can implement early and keep revisiting ...

which is why doing it in programmable logic instead of a custom IC would eliminate steps 7 through 10.

Good catch: the missing step 6b isn't missing if it can be deferred.

Thanks for the pictures - well worth another viewing. Inspiring.

Have you come across Randy Hyde's 65C816 Dream Machine essay? I think he was aiming for a 16bit machine which keeps the 6502 philosophy.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Jun 30, 2009 10:02 pm 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
I asked Mike Naberezny about adding a new forum for processor improvements on the forum index (as Tony suggested), and while he didn't mind adding another for a class of topics that would keep coming up, the very fact you mention is why he preferred not to do it at this time-- that some of the issues would fall under hardware, some under programming, some under EhBASIC, some under Forth, some under simulation, etc., which are all forums we already have.


When you think about it, such a project requires disciplines and discussions under all the fields. the idea behind a forum group was to address each concern. Perhaps its own Wiki page that has the information added and locked in as it proceeds?

_________________
"My biggest dream in life? Building black plywood Habitrails"


Top
 Profile  
Reply with quote  
PostPosted: Thu Jul 02, 2009 8:16 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
I've got a couple of suggestions for proceeding without needing a new top-level category:
    - prefix 65Org32-related discussion topics with "65Org32 core" - if they are active topics they will stay together and in any case can be searched.

    - use a topic such as "65Org32 Proposals" and re-edit the posts instead of replying to them. The original poster of each becomes the sole editor, perhaps accepting contributions by private message.

Or, sign up a new project on a site like sourceforge.net, which accepts hardware projects provided they are open source - they will host a wiki, a trac and/or a forum. (I recommend trac very highly as a wiki + issue tracker + task tracker + source code browser.)

It would be good to learn from the experience of the 65gz032 project - I suspect you need one or two highly motivated and productive people to get from a wishlist to a netlist. Pardon the pun.

Cheers
Ed

edit: I see now that the 65gz032 made it to in-circuit testing. Excellent!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Jul 15, 2009 9:53 pm 
Offline

Joined: Thu Jul 26, 2007 4:46 pm
Posts: 105
Warning: This post turned into a bit of a ramble!

I've been mulling over a CPU design of my own for quite a while now. It's definitely not 6502 alike; it's a more "traditional" RISC style load-store register machine, but I think that I can contribute a bit to a 6502 style design based upon my experiences designing it and researching how to design it.

Firstly, a quick description of it: The processor has 32 general purpose registers, named %r0 to %r31. %r0 is hardwired within the processor to be zero, as this has proven quite useful in practice [MIPS also does this]. %r31 is used for the frame pointer; %r30 is the default procedure return address register. The processor has an additional bank of 32 special function registers, which is not full, for controlling the processor and similar purposes.

All instructions are 32-bits and feature seven fields:
3-bit Write control: Contains the WZ (Write Zero), WC (Write Carry) and WR (Write result) flags.
3-bit Condition code: Each instruction can be made conditional on the aforementioned flags.
6-bit Opcode: Self explanatory
4x5-bit: Fields F1 through F4. Can refer to a register or contain a literal, and may be ganged together depending upon the instruction. Inputs generally come from F1, F2 and F3 in that order; Outputs are always determined by F4.

The opcode space is slightly reduced by some instructions which gang the opcode's LSB with the 15-bits of F1, 2 and 3 to form a 16-bit literal.

All operations are 32-bit wide except for loads and stores, which may be 32, 16 or 8 bit wide.

Instructions are decoded using microcode. Microcode need not be slow; in my case most instructions decode in one cycle. Microcode addresses are 7-bit, and the first microinstruction of an instruction is simply it's opcode zero extended. I haven't determined the microinstruction size yet.

A microinstruction simply consists of the various signals that are to be distributed to the various segments of the CPU pipeline, and the next instruction address. For example, the microcode for the add instruction would say the following:
ABus = Reg[F1]
BBus = Reg[F2]
CBus = F3
ALU Operation = Add
Memory Operation = Nop
WriteRegister = Reg[F4]

The instruction
add %r1, %r2, 5, %r3
Would do %r3 = %r1 + %r2 + 5

The next address field contains the address of the next microinstruction in the instruction; the last instruction contains the all-one address, which the microcode sequencer interprets to mean "Instruction finished". When this address is branched to, the sequencer branches to the next instruction's address if no interrupt is waiting (If one is, it branches to the interrupt microcode address - the all-one address)

The pipeline is structured as
Fetch -> Decode -> ALU -> Memory -> Writeback

One feature I'm really fond of is the fixed point support: The multiply and divide instructions contain, respectively, post and pre shift values in F3. This means that, with a 16.16 fixed point value, you can do
MULS %r1, %r2, 16, %r3
or
DIVS %r1, %r2, 16, %3

(Though the first implementation will probably lack a hardware divider)
And get a 16.16 value out. (The ALU operates on 64-bit intermediates)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Jul 16, 2009 11:25 am 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
I've been following this discussion for a while and it seems to me that many of the suggestions would lead to processors that would be so different from the 65C02 as to be new devices in their own right.

If you want to extend the 65C02 to 32-bits whilst remaining faithful to its approach and style you will have to follow the same path as the 65C816 and end up with something like the (once proposed) 65C832. This approach maintains architectural and code compatibility into 32-bits.

Once you start changing the instruction set, addressing modes or number of registers you lose this backwards compatibility have effectively have just created a new processor family. The 65GZ032 is good example of this. While it offers a 6502 compatibility mode its native 32-bit mode is very different and almost unrecognizable as a 6502 derivative.

If you want a 32-bit RISC based CPU then there are plenty of good commercially available devices. Do we really need to design yet another?

If we want a 32-bit 6502 then I'd suggest we implement a 65C832 in RTL or emulate within another micro-controller at low speed on a carrier board that fits a 65C816 socket.

Just my $0.02

_________________
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  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 186 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 13  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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: