6502.org

Woz rules in my book!!
Mike

Using a 65C816, you can get "sweet 16" by clearing a bit or two in the status register.

(Just to note: this thread is one of many with ideas about extending the 6502 architecture. I've posted an attempt at an index to such threads here. There's another flavour of discussion, which is ideas about implementing the 6502 architecture with higher performance. See this recent thread for example. I think it's useful to keep those two kinds of things separate - they are both interesting and useful topics of discussion and areas of work, but they scratch different itches.)

I had a flash of inspiration and I've been implementing a 65Org32 emulator in C. I'm presently working on an assembler.

It is possible to place four 8 bit opcodes into one 32 bit instruction fetch. In this regard, it is very much like Charles Moore's C18 processor or Seymour Cray's CDC6600, although with the registers and addressing modes that we know and love. It doesn't retain binary compatibility with 6502 or 65816, in part because batches of opcodes precede any subsequent operands. Regardless, it has similar registers and addressing modes to 65816. Specifically, direct, absolute and long. I've arranged function and addressing mode into two nybbles. This regular format allows one operand to be sourced from the usual places. The major differences (apart from 32 bit everywhere) is multiplication which can source one operand from anywhere and a lack of carry flag. This would be a lovely architecture for signal processing but I relatively certain that operand size precludes general use.

Unfortunately, I have a technical problem. I'm developing on Unix. This aids some aspects of development. For example, I use a shebang hack to make a 65Org32 binary work transparently like a native binary. Specifically it is possible to prefix any foreign binary with '#!' and the path of the interpreter. Normally, this technique is used to distinguish text scripting language and dialect, such as the various versions of shell, Perl, Python and Ruby. However, it can also be used to run a 6502 binary as easily as any script. I was hoping to apply this technique in other projects and I hoped that others would similarly benefit in this project and their own work. However, I'm fairly certain that the most likely alpha testers for 65Org32 don't use Unix. This may greatly hinder contributions and feedback.

It would also be useful if a standard format is adopted for opcode maps. This would allow considerable generality within a macro assembler. I enclosed an example in CSV format. The first line defines opcode. The second line defines addressing mode. Subsequent lines may define details such as clock cycles and privileges.

(Would be good to see this reinvigoration of 65Org32 in a new thread, Sheep64)