OK, thanks - I see now! There is a gain there, but to me it's a very marginal one, so I personally won't be rushing to code this up.
It's certainly looking like the first worked example should be the PHX set - I've added a
github issue for this set.
As OwenS has pointed out, we are throwing away memory density quite happily in giving up byte addressability. So enhancements which help code density don't get me excited at present. It's functionality that I keep coming back to. Things which are really tricky or ugly to write with the existing instructions. (So, handling BRK's operands has always been suggested as a job for the BRK handler, I think?)
A good example might be Garth's wish for a barrel shifter, which is something ARM has. Even more compelling for 65Org32. A set of power-of-two shift distances is a compromise. (Even without that, adding an optional 8-bit shift, with a quick peek at the best-in-class 6502 emulation code for ARM, would allow for an efficient 6502 emulator. That might come in handy...)
Another (obvious) example is some kind of multiply, since that's expensive in code but really cheap in FPGA. The difficulty here is how to get results in and out of the registers. I'd actually lean towards a memory-mapped peripheral here - not necessarily an FPU, but something which can take a couple of sensibly sized operands and return a sensibly sized result - that might occupy 8 words. There might be another word or two for the command and status register. In fact, such a peripheral would also be useful for a 6502 in FPGA - nothing 65Org16 specific about it, other than whether it presents a 16-bit wide interface or 8-bit wide. (One idea is that it could be placed under BASIC's floating point accumulators in zero page, and accelerate multi-byte shifts, adds and multiplies where possible, and otherwise act like memory. In FPGA there's probably next to no cost in such a precise memory mapping.)
I'm kind of aware I keep saying 'No, I won't be doing that...' - but I hope I'm also always saying '... but do go ahead if it seems interesting.' Previous discussions always looked to me a bit like Garth was hoping that some 'chip people' would turn up and make a chip that made at least some wishes come true. I think much more likely is that progress will come from people already here, who maybe haven't yet picked up on FPGAs but are already excited about 6502-related CPU tinkering, who will get started with the free tools and cheap dev boards, or will maybe use the emulator to show how some instruction or architecture change makes a difference to some particular software.
Here's what we've got to work with, beyond paper and pencil:
emulator, runs on windows and anything else
- can experiment with assembly code
- can try to port something higher level such as Forth or C
- can extend the instruction set or register set by writing python
- can enhance the emulator (lots of ideas...)
assemblers, run on windows and linux at least
- can port existing 6502 code
- can write new code (such as a monitor, microkernel, ...)
- can extend the assemblers to handle novel 65Org16 variants
verilog HDL on github
- can simulate in free Xilinx (or probably other free simulators)
- can design different or better system on chip
- can fix, extend or improve mine!
- can add cache
- can extend the instruction set or register set
- can experiment with ideas to improve speed
- could even build a T65 or other VHDL version of 65Org16
- can run on a OHO FPGA module
- could port to another FPGA dev board
Cheers
Ed