I thought it might be useful to have an index to threads about (or relevant to) the 65Org16(*), even if those threads are not active.

State of play with cores.

Tools and languages:

Assemblers (two to choose between)
Python emulator by Mike (py65)
In-browser emulator by Ed (based on easy6502)
C'mon, the Compact MONitor by Bruce, with single stepping extension.
Tiny BASIC for the 65org16
eForth ported to 65816 and 65Org16
Idea for a C compiler
Hint of an idea about FORTH
Software for the 65Org16.x (a quest for monitor software and device drivers)

Edit: some software can be found archived here.

Hardware:

EEye's v1.1 Dev Board with 16bit wide SDRAM, video, other peripherals. Spartan6, 100MHz.
Instruction set extensions (BigEd)
More Opcodes (EEye)
65org16.b variant with more registers, long distance shifts, reg-reg arithmetic.
Interrupts (latency, register banks)
Defining the 65Org32 (addressing modes, extra instructions) also mentions extra instructions for 65Org16 variants: shifts, multiply
support for future incl. possibility of FPGA sales

FPGAs generally:

Survey of FPGA dev boards
65Org16 CPU Module/General purpose FPGA breakout board
6502 Playground dev board with non-volatile FPGA and (8-bit wide) RAM by enso

Misc:

A Q&A thread
Points about multitasking

I'll update this head post - adding and dropping things according to what seems to be going anywhere. Other interested parties might like to jump in with a post each where they also maintain some bookmarks.

Historical threads:

First mention thread
First glimpse in simulation (and then on FPGA)
pi program on FPGA

(*) A simple-minded variation on 6502 where bytes are 16 bits wide, so addresses become 32 bits wide. With minimal change to existing VHDL or verilog cores, we get access to huge memory space. We get the option to add features. We do in some sense waste memory bandwidth and clock cycles. We make progress quickly because we don't get bogged down discussing all the possible ways to extend the machine.

Thanks Ed for the help in tying things together. This kind of thing makes the forum more useful. Also, it's always good when you (or anyone) links things together in posts ("In another topic, EEye said,...") to make it easier for readers to connect the pieces. I use the forum search function a lot but it's not very good, and it is especially time-consuming when I remember a particular post I want to see or reference again and it's in the middle of a long, multi-page discussion and the search doesn't tell you which page it's on so you have to look through the whole thing.

I almost always select the 'Posts' radio button at bottom left (which unhappily defaults to 'Topics') and then the search results give me individual posts rather than entire threads.

Similarly, I select "All available" in the Return First drop-down at bottom right, so I get the whole of each post.

Cheers
Ed

I've just updated the head post with two or three more links. I included enso's 6502 Playground although it's not ideally suited to 65Org16 experimentation because the on-board RAM is only 8 bits wide. However, there is scope to add a second RAM using flying leads, and it's also possible to run slower and perform dual accesses.

Thanks for the summary!

I never got involved into helping with the project, since it is vast, and i was always "out of date".
"Idea for a C compiler" if the cpu gets a C compiler, that might be the "killer app", although it is only a tool for making applications.

What do you plan to do with it when it is done? Will you leave it free for everyone to implement in their projects/products?

It's already free for use- it's LGPL so can be used in any open source or closed source project, provided source for the core is made available to your end-users.

Oh, and also it's ready for use, except for one known bug - the status register puts the N and V bits in the wrong place when you use PHP/PLP/RTI. Easy to fix but I haven't yet got around to it. (The N and V are supposed to be the top two bits)