(Edit: I'm speaking here of the 32bit flavour of 65Org16, which is not what Garth means by 65Org32 - see posts below.)

I think the only unexpected thing is that it's a directly scaled-up 8-bit micro, so as a 32-bit flavour, it goes through the motions of constructing 64-bit addresses and pulling two words from zero page to do it, which is probably wasted effort - unless you found a way to attach more than 2G words of memory! Similarly for JSR and RTS it will push and pop pairs of words to form a 64-bit PC value.

So, in fact, that's the other slightly unexpected thing about these simply scaled-up cores - they do not address bytes at all, only words. So, for 8-bit sized data you either need to waste some storage or you need to do a lot of shifting to pack and unpack data. For 8-bit I/O the same applies.

For both of these idiosyncrasies, it would take some work to address them, but would certainly be possible.

The 65Org32 (discussion starting here) was (or is, although it's still vaporware) really an extension of the 65816, with 32-bit address bus, data bus (and buses are not multiplexed, so yes, it has a lot of pins), and all registers (except probably the status register). It's well beyond just a wide 6502, being much better suited for things like relocatable code and multitasking. Nobody is working on it (unless someone is doing it in secret). I would like to emulate it with a microcontroller if I could put the time into it. It would be a very poor performer done that way, but at least I could experiment with the instruction set, and it shouldn't take long to develop it.

The one here on this forum who comes to mind who has probably made the most progress with a 32-bit 65-like processor is Michael Barry with his 65m32. It's not totally "65" though. For example, it has registers that are foreign to the 65's, an assembly language that strays quite a bit from the 65's, and has a 32-bit instruction word that mixes op-code bits with operand, so the whole instruction can be fetched in a single cycle. For operands that are no more than about 23 bits (I don't remember exactly), this works ok. For wider ones, he uses a bit in the op code to tell the processor to fetch the next word as a 32-bit operand. (I hope I'm remembering correctly.)

Other 32-bit 65's I'm aware of are the 6502EX and the 65GZ032.

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

It's true that we do have some confusion of terminology, or some missing terminology. It's clear what the 65Org16 is, and it's very simple. As you say Garth, you've used the name 65Org32 to mean something much more complex, although no-one has yet tried to implement it. So the 32-bit extension of a 65Org16 has no name: it's very simple, we know how large it is and how fast, we know how it behaves, but we're not supposed to call it a 65Org32. Nonetheless, for obvious reasons and without intending to confuse, I sometimes do call it that.

It's also reasonable to say that the 65Org16 is a full 16 version of the 6502 - it adds nothing, it takes nothing away - and so the 32-bit version can also be called a full 32 bit version. Again, it adds nothing, unlike all the others, which range from sketches to full implementations and do add features.

There is an in-browser emulation which can run in 8, 16 or 32-bit mode, if anyone wants to get a feel for programming and using the 65Org16 family:
http://biged.github.io/6502js/
It's a fork of Nick Morgan's 6502js, which is closely related to the easy6502 tutorial.

Here's an idea - we know what the 65Org16 is, so let's call the slightly odd but simple and usable 32-bit extension of it the 65Org32-lite, and then the 65Org32 can continue to refer to the rather tidier and somewhat extended design which still awaits an implementation.

I'm not sure where to look for a complete and definitive definition of 65Org32 - it may be found in this thread
viewtopic.php?t=1999
which presently sets off talking about what we're now calling the lite version, but Garth does join in to mention a DP register. I'm happy to update the head post over there with the updated definition - perhaps we can continue the discussion about 32 bit over there and leave this thread for 16 bit discussions?

Speaking of the 65m32, I thought perhaps we ought to have a thread which indexes the various efforts at extended architectures - there are several, and they reached various levels of development from pipedream to implementation. It turns out we do have one, although my head post isn't very organised - here it is:
viewtopic.php?f=1&t=4216

I have been wanting to work on a 32 bit version of an FPGA based 6502, but have been a bit unsure exactly how far to go. Here are my thoughts:
1. Revamp the whole addressing scheme - see below
2. Add only minimal instructions to the 65Org16 set - a 32X32 bit multiply and 64/32 divide would be what I was thinking. Most modern FPGAs have Wallace-Tree multipliers for DSP, so they cost almost nothing in the fabric. The dividers can be somewhat expensive but, if the FPGA is big enough, why not? These peripherals could also be conditionally compiled to allow for minimal/faster implementations.

Now for the "non-6502" additions:
3. Modify the architecture for maximal orthogonality - PC and SP would be treated as any other register in all ALU/memory operation. This would make jump tables a snap: LD PC,(whatEver).
4. Add a BSR - branch subroutine with the relative address as part of the instruction - with 32 bits and an 8 bit instruction, 16M reach is attainable
5. Branch instructions would have the relative address as part of the instruction
6. For stack based languages, add at least 3 more index registers that can be used as base pointers. These registers would also participate in all ALU/memory operations
7. Modify the increment/decrement instruction to use unused instruction bits to allow for fast adjustment of register values - useful for stack frames, etc
8. Add at least 2 more registers to assist with ALU operations - especially necessary if MULT and DIV instructions are added
9. Add either fast shift (using a barrel shifter) or SWAP instructions to make accessing byte data easier. SWAPs would allow any two bytes in the 32 bit word to be non-destructively interchanged. The barrel shifter method would work just as well (or better), but I am not sure how expensive it would be in an FPGA.
10. Add addressing modes such as (Base,reg), (Base,shortLiteral), (Base,longLiteral). shortLiteral would be a value in the instruction word (likely 16 bits due to number of available bits) and longLiteral would be 32 bits read from memory.

Obviously, the binary code would be completely incompatible with a bog standard 6502.

I have not been able to give this as much time as I would like, and have just translated the 65Org16 to VHDL. I can read Verilog, but if I try to use it I will only injure myself or those around me

I have a 32 bit barrel shifter in my X18-32 CPU core. It takes a bit of area, but not unreasonably so. It does add some delay (so does a multiply), so my trick was to add another register at the end, and add an extra cycle to the instruction. Although the register is at the end, the tools are smart enough to move the register stage inside the logic to break it up and increase speed.

Welcome! Be sure to read up first on what has already been discussed regarding a 32-bit version, and what is already in the works. I know of these topics (and Ed can probably bring up more):

• Idea for multitasking support on 65Org16 (or 65Org32) (BigEd)
• Defining the 65Org32 - addressing modes (and instructions) (BigEd)
• A 65Org32 variant - combining opcode and operand (BigEd)
• Improving the 6502, some ideas (VBR. This topic turned into the original definer of the 65Org32.)
• Introducing the 65m32 (Michael Barry, barrym95838) This one is on our sister forum, AnyCPU, and also has links back to this forum.

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