6502.org

Posted: **Sat Apr 14, 2012 8:52 pm**

ElEctric_EyE wrote:

While looking for opcode decoding errors for load_reg in the .b core and comparing against Arlet's original posted on Github I noticed column 6 was not accounted for on Arlet's core. I think it should be, or am I mistaken?...

Ah, I think I understand why. All bitpatterns not matching go to the default SEL_A. This is where it was a bit of a challenge for me as there is no default accumulator in the .b core. Everything must be accounted for, at least as far as a good looking simulation is concerned.

Posted: **Sat Apr 14, 2012 11:46 pm**

I was working on the core for most of the day, and posted the progress previously mentioned. And now I am "chilling"..

Now I was thinking, if the default register 'catches' opcodes that are not defined previously, this could be an illegal opcode register on both the src_reg and the dst_reg side. Maybe set a D flag, D for detention! Then what to do after that? Maybe send a NOP, a BRK...

This is just a thought, no time to pursue it just yet...

Posted: **Sun Apr 15, 2012 6:03 am**

The reason I use defaults is to help the synthesis tools to minimize logic. If you want everything accounted for, you'll need more decoding logic.

Posted: **Sun Apr 15, 2012 6:34 am**

Yes, it's much more work to catch the undefined opcodes - not a good plan.

Posted: **Sun Apr 15, 2012 1:51 pm**

Since I have multiple Accumulators, I do have to define each one and I don't see any one being a default. Instead of leaving it open ended, I think it would be better for decoding to add a default which would naturally define all the opcodes not presently decoded and set a flag in the status register.

Posted: **Sun Apr 15, 2012 6:31 pm**

Well, I left everything open ended, no defaults. Everything seems to be working ok on the laptop, still getting undefined red X's on the desktop for some of the Accumulators. Max speed right now, without using smartexplorer, is 91MHz.

Here's a link to the core on Github for anyone interested. The prior post of the opcode matrix is up to date. A growing list of macro's can be found in the README txt file on github.

Posted: **Tue Apr 17, 2012 5:08 pm**

Oh man, I found out where my problem was! There were about 2000+ opcodes that were not accounted for in all the Accumulator src/dst_reg's due to the addition of the W register. Running sims on the desktop now show no undefined states. Also found a few other decoding errors along the way. I'm sure 1 or 2 more decoding errors scattered about that I'll find in future testing, but I believe it is 99% viable now. A few fixes to the comments and it'll be on Github soon.

Now I have a clearer picture as to approximately how many functional opcodes total there are on this beast:
LOGIC[A..Q]op[A..Q] = 52functionsx256opcodes = 13312
<SHIFT,ROTATE>[A..D]op[A..D] = 20functionsx16opcodesx15shifts,rotates = 4800
STORE,LOAD,COMPARE,INC,DEC,PL[A..Q],PH[A..Q],TRANSFERS = 44functionsx16opcodes = 704

Close to 19,000 opcodes seem to be all accounted for now!

Running SmartXPlorer with a constraint of 10.7ns got the speed up to 94.95MHz.

Really the only opcodes left are TXW, TYW, TWX AND TWY.

Posted: **Tue Apr 17, 2012 11:34 pm**

Quote:

Close to 19,000 opcodes seem to be all accounted for now!

Oh my gosh that's a lot of opcodes! Way too many to put into a built-in assembler mnemonic table. Space is one reason; trying to make certain they all get entered correctly is another.

I took a brief look at your macros. I see you've pretty much decided to indicate address mode in the name of the mnemonic itself. Practical but maybe not in the true 6502 spirit

Even with cut-and-paste, that's an awfully big job to enter them one by one. Have you considered macros with arguments? I may have to re-think my "mnemonic.reg" preference myself (unless, maybe, it just might work...)

Anyway, maybe something like (HXA syntax):

Code: Select all


; copy register to register
; example: XFR G,K

.macro XFR, ?sreg, ?dreg
]sndx = index("ABCDEFGHIJKLMNOQ", "?sreg")
]dndx = index("ABCDEFGHIJKLMNOQ", "?dreg")
.byte ]dndx << 12 | ]sndx << 8 | $45
.endm

...ignoring all error-checking and also whatever the real bit positions to indicate source and destination should be and also whatever the base opcode really is. But you get the idea. This would also be pretty simple to implement in a native version.

Huh - what if source and destination are the same? From a programming perspective, probably just set the N- and Z- flags, hmm?

On another note, I'm not sure I understand some of the macros. Are there some ADC and SBC variants that take three operands? They have very long names and it appears as if source register, destination register and immediate value are all specified. Is that correct, or am I misreading them?

Posted: **Wed Apr 18, 2012 4:06 pm**

teamtempest wrote:

...Oh my gosh that's a lot of opcodes! Way too many to put into a built-in assembler mnemonic table. Space is one reason; trying to make certain they all get entered correctly is another...I took a brief look at your macros. I see you've pretty much decided to indicate address mode in the name of the mnemonic itself. Practical but maybe not in the true 6502 spirit

..

I've tried to be true to the core of the NMOS6502. I'll have to do a full writeup on the workings of all the opcodes very soon! As in tomorrow, because you are interested!
But, some clues here as to my ramblings.

So tired, sorry. Will summarize tomorrow... But I've got decent comments on the opcodes on Github...

To start, all the 255 other pages of the opcode matrix follow the original matrix layer $00. BTW, there is some room for mobility as far as defining opcodes with the same src/dst_reg's. Right now, INC [A..Q] differs from INY, INX, INW, i.e. accumulators with same source/destination reg's are different than index registers with the same source/destination reg's, but they can be made to have the same upper 8bit structure, if this helps. What I mean is, I can change some values in order to help the assembler program...

teamtempest wrote:

...On another note, I'm not sure I understand some of the macros. Are there some ADC and SBC variants that take three operands? They have very long names and it appears as if source register, destination register and immediate value are all specified. Is that correct, or am I misreading them?

The ADC/SBC are some of the logic (52?) functions I previously mentioned, where the source and destination reg's are defined by the upper 8 bits of the opcode, per addressing mode. 4 bits for source, 4 bits for destination. So just 1 ADC (zp,x) for example can have 256 opcode variants alone, since it has 16 possible source accumulators and another 16 possible destination registers. The operand part of the sequence is the same as the original 65Org16. On the whole, this core is transparent to the original 65Org16! except for the D flag/opcodes. Notice where I have INW and DEW...

EDIT: Sorry I had to delete and repost this entire response. I had attached a .b core spec sheet. But I realized there is a glaring mistake in the code where I was attempting to do an accumulator transpositional store on the 16 <shift,rotate> opcodes that work on memory locations. I will attach the spec sheet again, but I thought I should delete it so as not to waste server space with erroneous information.

Posted: **Thu Apr 19, 2012 6:38 am**

Hi EEye
André has just posted a glimpse of his assembler syntax, which seems to me quite clear, and also compatible with TT's description of how HXA likes to see arguments:

Code: Select all

LDA B,$10,Y
JMP (B, $0012)

I think it would be good to write up a short user-friendly description of what your core offers: much better not to say that you have 16000 opcodes, which sounds like something impossible to learn, or to talk about transpositional whatnots, which nobody ever heard of, but to describe the useful features:
- 16 registers which replace the single accumulator of the 6502
- instead of being forced to read and then write back to the accumulator, you can read from one register and write back to another, with any of the logical and arithmetic operators.

That is to say, at present you've written a lot about how you've implemented the new features, but not so much to sell them, or how they are used. I would think this short sales pitch is what belongs on the head post.

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

Code: Select all

ADC address,X
ADC fromReg, toReg, address,X

were both acceptable? That would be an even better position, because it makes the extra registers and feature even more optional.

Cheers
Ed

Posted: **Thu Apr 19, 2012 8:28 am**

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.

Posted: **Fri Apr 20, 2012 12:01 am**

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: 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:

Code: Select all

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).

Posted: **Fri Apr 20, 2012 1:15 pm**

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

Posted: **Fri Apr 20, 2012 3:11 pm**

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

Posted: **Fri Apr 20, 2012 3:30 pm**

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

6502.org

65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core

Re: 65ORG16.b Core