6502.org • View topic - 65ORG16.b Core

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC

65ORG16.b Core

Page 16 of 24

[ 353 posts ]

Go to page Previous 1 ... 13, 14, 15, 16, 17, 18, 19 ... 24 Next

Print view

Previous topic | Next topic

Author

Message

ElEctric_EyE

Post subject: Re: 65ORG16.b Core

Posted: Thu Apr 19, 2012 8:28 am

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

Hi Ed
I was just trying to get a grasp on how big this core is and only now at the very end of completion do I truly understand all the opcodes and how they work. Details are much clearer now and there's not actually so many opcodes as I originally thought.

I'm not so sure I like attaching the spec's at the head post. I'm not the best writer and I know some things will change and as I found out, in order to change or update a file means one has to copy, delete, then paste and update the post.

Attachments:

File comment: 65Org16.b Spec's

65016.b.zip [180.28 KiB]
Downloaded 107 times

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

Top

teamtempest

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 12:01 am

Joined: Sun Nov 08, 2009 1:56 am
Posts: 411
Location: Minnesota

Quote:

TT: would the HXA be able to support two syntaxes for the same opcode, so that

Sure. The native version already has to deal with things like:

Code:

LDA #$AB
LDA addr
LDA addr,X
LDA addr,Y
LDA (addr),Y
LDA (addr,X)

So the idea of having to deal with multiple possible arguments for one mnemonic isn't new to any 6502 assembler.

The macro version has to deal with the same things, of course. The way I handle it is to define a macro with the name of a mnemonic with as many arguments as there could legally be at most:

Code:

LDA .macro ?addr=@, ?ndx=@
..body..
.endm

The "=@" parts are default values; if the programmer does not supply values then that's what they become. So:

Code:

LDA #$45

gives '?addr' the text value '#$45' and '?ndx' the text value '@'. The macro code looks at these and decides what to do based on what it sees.

In short there's no problem defining as many arguments as you want, with as many of them having default values as you want, to make the job of generating code as easy as you want. For example, the only reason '?addr' has a default value at all is so that if someone perchance ever wrote LDA without any arguments at all, the macro code can issue a more-or-less meaningful error message (if '?addr' had no default value HXA would complain about the missing argument itself, though).

Top

ElEctric_EyE

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 1:15 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

I just ran a test program that is meant to fill the 4GB ($00010000-$FFFFFFF) worth of addressable memory using the W register in indirect indexed mode. I only let it run slightly past the 1st block to make sure it works properly. It's exactly like the bottom program which is more familiar to most folks.

Code:

START             LDWi
                  .BYTE $0000
                  STWzp
                  .BYTE $0000
                  LDWi
                  .BYTE $0001
                  STWzp
                  .BYTE $0001
                  LDX #$FFFE
                  LDA #$00A5
AD                LDWi
                  .BYTE $0000
AA                STazpw
                  .BYTE $0000
                  INW
                  BNE AA
                  INC $0001
                  DEX
                  BNE AD
                  NOP
                  NOP
                  
                  lda #$0000
                  sta $0000
                  lda #$0001
                  sta $0001
                  lda #$00a5
                  ldx #$fffe
ac                ldy #$0000
ab                sta ($0000),y
                  iny
                  bne ab
                  inc $0001
                  dex
                  bne ac
                  NOP
                  NOP

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

Top

ElEctric_EyE

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 3:11 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

I set the stack to be the same page as zero page, I think 64K is plenty for variable and stack. I found one more error in decoding upper 8 bits of PUSH/PULLs. Added some more macro's to github. Now this little programs works:

Code:

START             LDA #$00
                  INC A
                  PHA
                  TAB
                  INCB
                  PHB
                  TBC
                  INCC
                  PHC
                  TCD
                  INCD
                  PHD
                  TDE
                  INCE
                  PHE
                  TEF
                  INCF
                  PHF
                  TFG
                  INCG
                  PHG
                  TGH
                  INCH
                  PHH
                  THI
                  INCI
                  PHI
                  TIJ
                  INCJ
                  PHJ
                  TJK
                  INCK
                  PHK
                  TKL
                  INCL
                  PHL
                  TLM
                  INCM
                  PHM
                  TMN
                  INCN
                  PHN
                  TNO
                  INCO
                  PHO
                  TOQ
                  INCQ
                  PHQ
                  LDWi
                  .BYTE $FFFF
                  TWA
                  TWB
                  TWC
                  TWD
                  TWE
                  TWF
                  TWG
                  TWH
                  TWI
                  TWJ
                  TWK
                  TWL
                  TWM
                  TWN
                  TWO
                  TWQ
                  PLQ
                  PLO
                  PLN
                  PLM
                  PLL
                  PLK
                  PLJ
                  PLI
                  PLH
                  PLG
                  PLF
                  PLE
                  PLD
                  PLC
                  PLB
                  PLA
                  NOP
                  NOP
                  NOP

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

Top

BigEd

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 3:30 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England

I am considering that a register for the upper 'byte' of the stack pointer would be a good thing.
Cheers
Ed

Top

ElEctric_EyE

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 5:21 pm

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

Arlet

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 5:26 pm

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands

ElEctric_EyE wrote:

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

Top

BigEd

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 6:06 pm

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

ElEctric_EyE

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 8:40 pm

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

Arlet

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 8:43 pm

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

ElEctric_EyE

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 9:49 pm

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

ElEctric_EyE

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 11:28 pm

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

GARTHWILSON

Post subject: Re: 65ORG16.b Core

Posted: Fri Apr 20, 2012 11:41 pm

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
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

ElEctric_EyE

Post subject: Re: 65ORG16.b Core

Posted: Sat Apr 21, 2012 12:24 am

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:

Yet...

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

Top

BigEd

Post subject: Re: 65ORG16.b Core

Posted: Sat Apr 21, 2012 5:41 am

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

Page 16 of 24

[ 353 posts ]

Go to page Previous 1 ... 13, 14, 15, 16, 17, 18, 19 ... 24 Next

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC

Who is online

Users browsing this forum: No registered users and 16 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