65ORG16.b Core

[ElEctric_EyE]

That's a good idea. Maybe use the unused upper 8 bits of the status register? Now how to go about coding for it... There are really $FFFF-1 possibilities where the stack could be, everywhere except the top due to the NMI/RES/IRQ vectors.

[Arlet]

ElEctric_EyE wrote:

That's a good idea. Maybe use the unused upper 8 bits of the status register? Now how to go about coding for it... There are really $FFFF-1 possibilities where the stack could be, everywhere except the top due to the NMI/RES/IRQ vectors.

It's also an interesting idea to be provide a register for these vectors, so they can be placed at other locations.

[BigEd]

I mused out loud a few minutes ago in another thread:

Quote:

I'm wondering about

Code: Select all

XSR #literal

which exchanges with a numbered Special Register - that allows for extensibility without needing more opcodes if we have more registers. For example, the 65Org16 could have a Stack High Address register, which allows us to overlap stack with zero page, or to place stack at the top of memory as mentioned earlier. Indeed, the 65Org16 could have a relocatable zero page, as the 816 does.

[ElEctric_EyE]

It seems pretty straightforward. 16 registers is an abundance and without creating more opcodes, I think it would be wise to dedicate 2 existing registers O and Q for the Zero Page Address Register and Stack Page Address Register.

[Arlet]

Hi Ed,

probably a good idea, because these special registers have to be kept outside the register file, so they won't fit in the regular opcode matrix anyway.

[ElEctric_EyE]

It appears to work! I ran the push/pull program from the other post when Q = 0 it starts pushing at $0000FFFB, then I put $0001 in the Q Accumulator, ran the program again and it starts pushing at $0001FFFB. I defined the 2 Registers before as 16-bit wide and added this:

Code: Select all

/*
 * Zero Page, Stack Address Register update
 *
 */
always @*
 begin
	ZEROPAGEReg <= QAWXYS[SEL_O];
	STACKPAGEReg <= QAWXYS[SEL_Q];
 end	

[ElEctric_EyE]

So now I'm thinking (uh-oh), of using a bit in the processor status register to enable or disable the transfer of data, from O and Q Accumulators to the ZEROPAGEReg/STACKPAGEReg registers, with a status bit. This will enable the O and Q acc's to not be dedicated unless the bit is set first.

I was thinking also there should be 2 new opcodes to set or clear any of the bits in the processor status register. A simple Load Processor Status Register with a value. Then a Store value of Procesor Status Register, because just pushing it on the stack will not suffice wen the stack locaion is changing...

[GARTHWILSON]

Quote:

I was thinking also there should be 2 new opcodes to set or clear any of the bits in the processor status register. A simple Load Processor Status Register, and a simple Store Processor Status Register.

The '816 calls them SEP and REP, and the operand is a bit pattern, where you put a '1' in each bit position you want to set (with SEP) or clear (with REP). '0' bits in the operand byte cause no change in their corresponding status register bits. It is super cryptic, which is why we make macros especially for ACCUM_16, ACCUM_8, INDEX_16, and INDEX_8 to show what we're doing.

[ElEctric_EyE]

Ah, thanks for that input Garth. I always read about SEP/REP here on 6502.Org, but I never knew what they meant... At one point a year or 2 ago I was about to make the jump from 6502 to 65816, but never did, due to the draw of programmable logic.

So I can probably make this work (with Arlet's watchful eye), as I feel I am learning a new language here and I've not heard his condemnation! Yet...

[BigEd]

SEP and REP is just about worthwhile, although if the bits in the status register are rarely enough changed then you don't need a high-performance way to change them, and fiddling with PHP and PLP with some more macros would be adequate. SEP and REP is extra work.

I really wouldn't make these two special registers subject to mode bits though, or take them from the arithmetic/logical register file. The feature can be kept out of play by leaving the registers at default values of 0 and 1. There's no reason at all why one might need high-performance arithmetic or logical operations on these special registers, and by using the general register pool all that's happened is a shrinking of the pool. You'd be compounding that mistake by adding a mode bit to disable it. As Arlet pointed out earlier, these special registers are accessed in parallel to the register file, so to his thinking and my thinking they should be separate.

Finally, if you do it the right way, the idea is applicable to the original core, and to an 8-register version too. It becomes a feature which is not tied in to the 16-register variation. It's independent. That's the best way to add features!

Cheers
Ed

[Arlet]

ElEctric_EyE wrote:

So I can probably make this work (with Arlet's watchful eye), as I feel I am learning a new language here and I've not heard his condemnation! Yet...

That's because I was sleeping.

Your design works, but it requires a triple ported RAM for the register file, while the original design only had 1 read port. Of course, the simulator isn't going to care, but the amount of logic will go up, and speed will probably go down (if not now, it may still cause an extra loss in speed later when you add more stuff). Now, triple ported RAM has its uses, but since these are kind of special registers, it would be preferable to keep them in special flip flops. They'll be faster, too, because by cutting them loose from the register file, the router is also free to move them around on the FPGA to optimize performance (probably close to the address bus).

I also agree with Ed that you won't be using these registers as regular accumulators, so they don't need a full set of operations. A special opcode to set them once or twice would be good enough. You could even make them memory mapped, although that would provide another challenge of finding a suitable memory area.

[ElEctric_EyE]

Well my intent wasn't to do anything complicated with the PAGE pointers by using a(n) accumulator(s). My thought was that once the bit disabled data going from the accumulator to the PAGE register, it could be used as a regular accumulator again. But I just ran a speed test and the design no longer fits under an 11ns constraint. That is intolerable IMO. So I will work on something simple that runs outside the main register file, and an opcode to load data into the PAGE pointers. Another opcode to read/modify/write data into the PAGE pointers.

EDIT: instead of a read/modify/write like INC, which would mean I'd need DEC, I think maybe a transfer to pointer would be useful.

[BigEd]

Can I suggest you consider an exchange instruction? Then you only need one. I did this for my B register which I used for my multiply instruction. It was pretty simple - you can probably just lift the code.
Cheers
Ed

[BigEd]

By the way, very interesting that the speed did drop off! We might have been wrong about how the synthesis would have implemented your approach...

[ElEctric_EyE]

BigEd wrote:

Can I suggest you consider an exchange instruction? Then you only need one. I did this for my B register which I used for my multiply instruction. It was pretty simple - you can probably just lift the code.
Cheers
Ed

Ill experiment with your code. Not making much progress today though. Work is busy unfortunately/fortunately! 1 instruction per register, so 2 total.