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

I have not actively joined in the conversation on this topic, but I have been following the discussion.

I have implemented an enhanced version of the 6502/65C02 which I think is in keeping with the general philosophy of the 6502. However, I have taken liberties to add certain features that I think are important to the support of many High Level Languages (HLLs) such as C and Pascal. In addition, following some friendly prodding by Dr. Jefyll, I've included built-in support for a FORTH VM.

During my time actively working on the core, I've added dedicated instructions for stack-relative addressing, base-pointer addressing, and FORTH IP relative addressing with auto increment. I also included support for kernel and user mode stack pointers, an auxiliary (third) stack using X, and various prefix instructions for increasing the size of ALU operands and operations, adding indirection, and a combination of both indirection and size. In addition, I added prefix codes to override the accumulator with either X or Y.

In the final implementation of the M65C02A, I've eliminated specific base-relative instructions, and decided to use a 1-offset base relative addressing mode using the built-in pre-indexed (X) instructions. In other words, I gave up the need to use a 0-offset base relative addressing mode using dedicated opcodes; I came to appreciate the need to preserve compatibility with the modern WDC W65C02S instruction set.

In the process of porting the Mak Pascal compiler, I realized that I could implement a stack-relative addressing mode using the prefix instruction I had implemented to override the default stack pointer. When applied to the pre-indexed (X) addressing mode instructions, there is a full complement of instructions using both 8-bit and 16-bit offsets greater than the number I was able to support with the free opcodes of the W65C02S microprocessor. The only real limitation for me was that using S as the index/base register, an offset of 1 is needed instead of 0 to access the top of stack element. This is really an aesthetic personal preference; the code generator of a compiler really could care less if the offset for the top of stack or the stack frame is 0 or 1.

I have finished the development of the M65C02A core, although I've not fully tested all of the changes that I made. I frequently review and update the documentation that I've placed in the README file in the project's github directory. I also update the core's user manual when I have some free time. I've not updated the Pascal compiler, also found on github. in a few months because I'm working on completing another one of my processor projects. In particular, I've not updated the compiler to support the 1-offset format for base-relative and stack-relative addressing modes or the need to include the default override prefix instruction to the pre-indexed addressing mode instruction to derive the stack-relative addressing mode.

In the development of the M65C02A I had as an objective backward compatibility with the 6502/65C02. Other than my desire to remove all dead cycles from the instruction set (see the 65CE02), the basic implementation is fairly true to the 6502/65C02. (Some minor behavioral differences in the BRK, RTS, and RTI instructions should have no consequences on new developments, but may affect existing code. I had to make some minor changes to Daryll's monitor program.) I found that moving back and forth between extended/enhanced and normal operation was best handled by prefix instructions rather than a mode register. Unlike the 65816, which was not a consideration in the M65C02A project, the prefix bytes allow easy enhancement to 16-bit operation and easy return to 8-bit operation.

In the case of the Pascal compiler, if the enhanced 16-bit operations were to be the norm, the default size could easily be set to be 16 bits, and the size prefix could be used to change to 8 bits. This would improve the performance of the core for those instances where the Pascal compiler was used more often than not. Another alternative, which I think I've included in the released core, is to tie this capability to the mapping logic provided by an MMU. For certain address ranges the default size is 16 bits, and in other address ranges the default size is 8 bits.

I certainly enjoy the free exchange of ideas for improving the 6502 that characterizes many of the threads on enhancing the 6502 architecture. I've implemented some of the ideas offered up by many of the longtime members of the forum. As you can glean from my discussion above, I too have had a number of false starts. The trade-offs between the various enhancements and the basic architecture/flavor of the 6502 has been instructive personally, and given me a greater appreciation for the 6502, 6800/6801/68HC11, 8080/8085/Z80 microprocessors.

For me the 6502 has offered the best path toward an enhanced 16-bit option. The others have essentially filled opcode spaces, which makes the development of enhancements more difficult. The wide range of addressing modes supported by the 6502 also made the inclusion of base-relative and stack-relative fairly easy and useful as I found out when mapping the M65C02A onto the 8086 register set to port the Mak Pascal compiler.

My experience in developing the M65C02A core has been enhanced by trying out the ideas. I wanted the core to support stack frames and easily support a HLL like Pascal or C. I first started out by simply adding instructions that I thought might be useful for a compiler. But when I actually ported the Pascal compiler and mapped the instructions used, I found out for myself that what many sources claim regarding the utility of instructions with complex addressing modes or functions in compiled code is true.

I ran a histogram on the number of instructions that the compiler made use of for several different applications, and many of the instructions that I painstakingly added to the M65C02A were unused. I did find that base-relative and stack-relative addressing were extensively used. I also found that I could only effectively use just a fraction of the basic instructions and addressing modes of the 6502/65C02; the operations supported by the compiler and the virtual machine targeted by the compiler just do not make use of zero page or the many addressing modes into zero page. Thus, I reversed many of the "enhanced" instructions I had added and decided to simply use the default stack pointer prefix instruction to enable stack-relative addressing using the existing pre-indexed addressing mode.

The microprogram space freed up by this decision allowed me to make indirection work in more natural way. Previous to this final change, the prefix instructions adding indirection applied indirection prior to indexing. This meant that adding indirection to any pre-indexed addressing mode converted the operation to a post-indexed single or double indirect addressing mode. With the microprogram space recovered by eliminating dedicated base-relative and stack-relative instructions, I was able to apply single or double indirection after indexing by X or before indexing by Y. I think that this is more in keeping with the base architecture. The additional microprogram space also allowed me to implement more support for relative addressing mode: I increased the range for the branches from 8 bits to 16 bits and I added pc-relative subroutine instruction.

_________________
Michael A.

That usually works great for single programs. But if you're running a multitasking OS, with several user applications, you run into problems with sharing the zeropage.


With a wider bus it could be done in 2. And if you add separate Instruction/Data buses, it can be done in 1.

You can make a processor more compiler friendly, while also making it easier to program in assembly. The old ARM32 was easy to program in assembly (easier than 6502), but was also very compiler friendly.

The modern ARM Cortex is harder to program in assembly, and probably also a bit harder to use in a compiler, but it is much more efficient, because most of the opcodes are only 16 bit instead of 32. And the more work you have to do as compiler writer only has to be done once.

If you look at the x86, it is also clear that the irregular features (different functions for each of the registers), make it hard to write code for (both assembly as writing a compiler), but make it more code size efficient, because less opcode space is used for encoding the register number.

Very interesting to hear your story Michael: by implementing a HLL and reviewing how it makes use of your enhanced architecture, you've been able to close the loop. It's great to have a 6502 derivative which is fully worked out to implementation, which doesn't happen all that often, as it's a lot of work if you're making big changes.

Jeff, too: your Kim Klone and other experiments are marvels of practical engineering!

As I see it, the 6502 was the truest 8 bit processor of all around 197x. It has no 16 bit operations (just an incrementer for PC), so they need a solution for a variable (runtime) addressing of more than 256 bytes. Thats why they "invented" (zp,X) and (zp),Y. Neat and as it turns out pretty powerful - as you don't need to load and unload these pointers for most applications. The same applies to the limited stack, it was sufficient for hardware resources and return addresses.
Multitasking? No, or only in a limited context. Not that MT is impossible - but a general approach is simply painful (and thinking about memory swapping using DMA and perhaps hard disks very very expensive those days).

My cycle counting was done only with an 8 bit 6502+ in mind. The 16bit step was yet to come

I agree, the 6502 was good when it first came out. The problem is that some of the choices that were made to keep it cheap and simple didn't turn out to be very good for future requirements. The big role of zeropage is one of those problem spots. All the zeropage related instructions take up a fair bit of opcode space, while not being very useful for larger computer systems.

And while it's true that you don't need to load/unload the pointers in zeropage, it is quite painful to do pointer arithmetic, such as [B+N*X+offset] addressing, that's typically used in higher level languages. Anybody who disagrees is invited to write a 6502 version of my memory allocation challenge.

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

I was thinking about the case where you load in a few arbitrary user programs from external storage, and run them at the same time. Since the programs are all independently written, you can't statically allocate zeropage storage between them. Copying is possible of course, but very slow. Compare that to using a [base+offset] addressing mode (or even [base+index+offset]) which gives you all the benefit of zeropage compactness, while not having to bother with static allocation. The '816 helps a little with the DPR, but there's only one, and it's lacking direct manipulation of the DPR itself.

It's easier, yes, but it does waste an awful lot of cycles and it's not even very compact either.

Is copying zero page slow? A task switch for interactive users could take 10 milliseconds, feels like it's not too tight a constraint to me. You might well copy some stack too. And you don't need to copy all of ZP either - just the part which is agreed to be task-private. Could be half of it.

Zp-registers could be also used with cmp, cpx, ... 680x0 address register missed ROR, ASL, DEC, ... and the operations with them do not set flags. So the odds are close to equal. A two-byte instruction similar to MOVEM or z80 LDIR would be with 6502+ too maybe to 1980.


Do you try to work manually with O16/O32 and A16/A32 prefixes? It is almost impossible.


It would cost +1 cycle only if the page boundary was crossed like with the branches. Later 6502+ with 16/32/64-bit ALU would not have such a delay at all. So offs,S may be considered as a codespace waste.


Yes, +900% for some tasks. But it is impossible it will require too many opcodes. I have some tests with 6809 (2 accumulators) - they show that 2 accumulators may give even more than 100% speed boost.


Zp-registers and zp-memory are completely independent. I can't find any problem with it.


The main power of a man is his imagination.


No DPR, IMHO it was very bad idea. IRQ handlers may be adjustable to a current data width mode so we have to use different handlers only for different address size modes. Interrupt handlers mustn't use all zp-registers, so we have save only several of them. If we had dedicated PUSH/POP (they are mentioned above) then it would occupy maybe even less code than 65816 code.


The point is different. They are not all unfriendly, for example, x86(-64) or ARM look quite friendly for me. The point is that it is almost impossible to make code in assembler so efficient as a code produced by an optimized compiler for C/C++/Ocaml/... So assembler requires much more work and it gives slower codes than a high-level programming language with a good optimizing compiler.
I had some tests. A code in assembler is generally 2-3 slower than the same code written in C for good optimized compilers like gcc for x86.
BTW I don't like 65816 PER instruction. PEI and PEA are just extenders to PUSH.


There is another disadvantage of prefixes. The mentioned 6502+ architecture suggests 64 or even 256 modes - this will require 256 prefixes.
Thanks for the link to the interesting KK's projects but it uses fragmented memory while 6502+ allows flat 16MB/4GM/2^64B model.

_________________
my blog about processors

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

Yes, for realtime you might well need to be quicker. But then you can build your tasks to suit a more static arrangement. Or, set aside say 64 bytes for OS, 64 bytes for realtime and 128 bytes swappable for user tasks.

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