Page 16 of 24
Re: 65ORG16.b Core
Posted: Thu Apr 19, 2012 8:28 am
by ElEctric_EyE
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.
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 12:01 am
by teamtempest
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: Select all
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: Select all
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:
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).
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 1:15 pm
by ElEctric_EyE
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: Select all
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
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 3:11 pm
by ElEctric_EyE
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: Select all
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
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 3:30 pm
by BigEd
I am considering that a register for the upper 'byte' of the stack pointer would be a good thing.
Cheers
Ed
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 5:21 pm
by 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.
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 5:26 pm
by Arlet
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.
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 6:06 pm
by BigEd
I mused out loud a few minutes ago in another thread:
I'm wondering about
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.
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 8:40 pm
by 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.
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 8:43 pm
by 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.
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 9:49 pm
by 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
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 11:28 pm
by 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...
Re: 65ORG16.b Core
Posted: Fri Apr 20, 2012 11:41 pm
by GARTHWILSON
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.
Re: 65ORG16.b Core
Posted: Sat Apr 21, 2012 12:24 am
by 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...
Re: 65ORG16.b Core
Posted: Sat Apr 21, 2012 5:41 am
by 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