Now I begin to see what you mean! I think it is starting to dawn on me. To be able to use all acumulators as a register like X or Y with their addressing modes. This would truly make it a powerful CPU! I think I can do it...

I forgot about this: The X and Y registers are unique to regsel. Not so easy as I was thinking before I looked at the code again.

At this point, I think I can still do my idea of making a simple register out of the Accumulators. I should be able to test it out today...

Hi EEye
I'm not quite sure if we're on the same page, yet.

I was thinking of the relatively simple idea, that by making X, Y and SP part of your 16-way set of accumulators (which is a very small change to the code) you can make these three registers the targets of your new two-operand instructions:
ADC #5 to B // you already have this
ADC #5 to X // you can't presently do this
ASL C by 3 to D // you already have this
ASL C by 3 to Y // you can't presently do this

For this case, there's no impact at all to the instruction encodings or to the decoding you have to do in the verilog.

It looks like you might be thinking of the more complex idea - which might be even more useful - of allowing some or any of the 16 accumulators to play the part of the X or Y registers in indexed addressing
JMP (location),C

I'm not thinking of this case. In this case you do have to think up some ideas about how to encode the choice of accumulator in the opcode.

Hope that helps.
Ed

The complex idea isn't really that complex. If you replace this:

by this:

Where 'index_reg' is a suitably defined reg, then it just becomes a matter of assigning the proper value to 'index_reg' during instruction decode.

I suppose my main point is to try to establish that there are two ideas kicking around here - one means changing quite a few lines of source and finding some new encodings, and the other doesn't.

I agree that more flexibility with the index registers is desirable - in fact I think EEye has added that to his headline goals. (But I think it's a quite an extra step... maybe a .c core? It would be good to see a settled final version of this core and this thread!)

Ed

Oh, I see where you're coming from now BigEd. There is one small problem with doing that though: The upper bits of the opcode, used for the src_reg or dst_reg, are full. For the <shift,rotate> these would be bits IR[11:8] for Acc's A through D. For the other functions like ADC,SBC, etc. these would be bits IR[15:8] for Acc's A through Q.

EDIT: IR[15:8] not IR[15:18]. typo

In my simple plan, you don't need to change any bits, or need any extra bits. Three of the 16 accumulators become the X Y and SP. Instead of 16+3, as you have now, you just have 16. It's actually simpler (except for the assembler)

Acc15, for example, is the SP. You might choose also to call it Q.

I thought you might suggest getting rid of 3 Accumulators!
I will keep the possibility in the back of my mind. Maybe when the final is done, which I would like to be after I add in the INcrement/DEcrement opcodes for the Acc's, someone could do this? I am finding myself busy, busy, busy! Work is picking up as well, so there is less free time.

Understood. In principle, it only changes about 4 lines of code.
Cheers
Ed

Why is this your opinion?

Good question! Let me consider. I certainly don't mean anything hostile.

I think what I'm getting at is that I want to congratulate you for a finished core: whether it's a v1.0 of the .b core, or the final .b core. For my taste, it would be good to see the end of a long development thread (in which much has been learnt) a short announcement, and then the start of another development thread if there is an expanded spec to be considered.

(I also realise that git and github allows us to tag versions, which means people can readily download a tar or zip file of that version. A stable version is probably more attractive for other people to have a look at.)

But it is a matter of taste!

Cheers
Ed

Oh ok. And thanks! Well I guess I can say I'm done adding to the .b core with the addition of the IN[A..Q], DE[A..Q]. They tested ok in ISim. Actually, I had to rename the Macro's to INCA...INCQ etc., because of IN[C] conflict with the INC command that's already there.

I have 928 Macro's typed out (this is not RISC, eh?) which I would like to add to Github. This would be useful for anyone not used to reading Verilog for the actual individual opcode values. All the Macro's have been tested in ISim, and some have even been tested successfully in my TFT graphics drivers.

How can I go about adding this .txt file?

It turns out you can't add a file direct from the website interface - you can if you use git from your PC.

What you can do, I think, is create a wiki on GitHub and paste into a page on that. Or create n issue and paste into there. Or even paste into an existing file like say the README

Ok thanks. I changed 1 of the README files. It currently has 928 Macros defining some opcode values. They are in As65 format.

There are many, many more opcodes that need Macro definitions. I don't have time to write them all down. Simulations have proven that the backbone is functional. Hopefully the 'RULES' I put at the head of this thread will help anyone interested in development! Fingers crossed... If not, ask away! My eyes are here at least once a day and I'm eager to help, and I know I'm not the only one.

Now I am off to do the .c core in a new thread here in the Programmable Logic section. It will also be based on the original 'architecture' of Arlet's NMOS6502, since it has proven itself after many modifications made for the .b core, while still maintaining the highest speeds. However, I think compatibility with even most of the original NMOS 6502 opcodes will suffer, due to what I have in mind... Shhhh! Accumulators and Index registers will become one as the Y!