6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 22, 2024 11:39 am

All times are UTC




Post new topic Reply to topic  [ 353 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19, 20 ... 24  Next
Author Message
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Apr 20, 2012 5:21 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Apr 20, 2012 5:26 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Apr 20, 2012 6:06 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
I mused out loud a few minutes ago in another thread:
Quote:
I'm wondering about
Code:
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Apr 20, 2012 8:40 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Apr 20, 2012 8:43 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Apr 20, 2012 9:49 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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:
/*
 * Zero Page, Stack Address Register update
 *
 */
always @*
 begin
   ZEROPAGEReg <= QAWXYS[SEL_O];
   STACKPAGEReg <= QAWXYS[SEL_Q];
 end   

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Apr 20, 2012 11:28 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Fri Apr 20, 2012 11:41 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 21, 2012 12:24 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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! :lol: :wink: Yet...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 21, 2012 5:41 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 21, 2012 6:17 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
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! :lol: :wink: 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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 21, 2012 11:37 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 21, 2012 12:35 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 21, 2012 12:47 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
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...


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 21, 2012 4:04 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 353 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19, 20 ... 24  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 28 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: