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.

_________________
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?

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.

_________________
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?

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.

_________________
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?

_________________
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?

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.

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!

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!

_________________
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?

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.

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"

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!

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)

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