Maybe 1993? (Although the pages from the webserver are dated April and May 2000, and archive.org has a version from 1997.)

Cheers
Ed

The Last-Modified date is 10 May 2000 02:48:27 GMT for the first page and 30 Apr 2000 17:41:48 GMT for the second page (the instructions page).

Edit: Ah, BigEd beat me to it. I didn't see the next page of the topic.

-Tor

Been thinking about the Acc-Acc transfers...

I think it's time to define some new base opcodes for the A accumulator. By base I mean in the original 6502 $00-$FF region.

I chose the columns $03 & $0B. Specifically, $BB, $AB & $9B for TAB, TAC, & TAD and $B3, $A3 & $93 for TBA, TCA, TDA. Other Acc to Acc transfers will depend on bits 11, 10, 9 & 8. Still working on it...

Ok, now I am getting confused. Could be because I am going back and forth between working on cars and the code, heh. But this is what I have so far for Acc to Acc transfers using the dst_reg. What about the src_reg? I have run out and am confused as to which Acc should be the src and which Acc is the dest.


SEL_D and SEL_E are actually the C and D Accumulators respectively.

In the TAX instruction, the 'A' is the source, and 'X' is the destination. So src_reg should be SEL_A, and dst_reg should be SEL_X.

I will rename the C flag (carry) so I can use SEL_C to make the code less confusing. Right now there's a conflict if I try to use SEL_C. For arguments sake SEL_C is Accumulator C.

But, consider a TBC and a TCB. Since the src_reg and dest_reg both are MUX'd into SEL_B-SEL_C. We could pick whether to put these opcode definitions in a dest_reg CASEX or a src_reg CASEX?

I will try a simulation of what I have so far...

I'm not really following you here.

For a TBC instruction, the src_reg should be SEL_B, and the dst_reg should be SEL_C. The TBC instruction is then executed in two cycles. In the first cycle, the src_reg is read from the register file, so it reads register 'B'. In the second cycle, the result is written to the dst_reg, so it writes register 'C'.

So, dst_reg always points to the register where the ultimate result of the operation is stored, and src_reg points to a register that is read during the instruction to get an operand.

I'll try to explain the way I have understood the progression.

first was this code, I'll use TAX etc. as an example.


then I modified the default with your help to get TBX, TCX, TDX etc.


So, it makes sense to do this doesn't it?:

I am trying to do much at once, especially with disturbances at work where I cannot focus on the code, although I do think about the code when working...

I ran a Sim and values are changing but not as expected. I will back up a few steps for Acc to Acc transfer opcodes... I should be able to post progress soon with the tools I have learned so far on ISim and your advice.

No, the source is B, the destination is A. So you should set dst_reg to SEL_A, and src_reg to SEL_B

Ok, finally got through my thick skull!

All Acc to Acc transfers appear to be working.



Will do more testing to be sure...

And do a speed test tonight if all goes well.

EDIT: I couldn't wait. It passes with a O2 constraint @ 10.5ns for 95MHz. Now I'll continue testing...

I was close. But after a couple cups of coffee on a fresh day (away from work), I got it 100% correct. A few of the transfers were not working, but they are all working now. I had to put TAA TBB TCC TDD in the code (even though the commands are useless) to get my logic straight. Here are the new opcodes. Posted on Github.

I have almost completed what I set out to do with this core according to the header of this thread. I have yet to add a Z index register, but there are a few things I would like to do next...

There are 6 bits left for the transfer opcodes. It would be useful I think to use 2 of the bits and have 4 logic functions (AND, OR, EOR, NOT) built into an Acc-Acc transfer. I think this should still take 2 cycles and shouldn't be too hard to code for and shouldn't slow down the core speed if I understand correctly.

An index register and adding logic to the transfer opcodes are not as easy as I thought and I grow weary of Verilog.

I'm going to take this core now and work with it on the DevBoard.

Back at work again and things are slow, so I thought I would tackle the 'transfer with logic' again with the new accumulators.

I realized I needed a separate register that would contain the result of the logic functions AND, OR, XOR amongst the 4 Accumulators. The opcode names look like TABand, TABor, TABxor etc. in my As65 Macro's.

So this register called LOGOP (Logic Operator) I have working already with TABand and it takes 2 cycles. It may take 1 or more cycle to transfer it to the src_reg or dst_reg. Transferring this value will be the challenge for me at this point... I just finished all the other 4 Acc transfer + Logic.

If in the end these 'transfer with logic' opcodes slow down the core too much, I'll probably remove them. I am always concerned with speed, so we will see if a speed sacrifice is worth it, compared to cycles saved per instruction. I intend to focus on this tradeoff, during this 65Org16.b Core expansion. If they prove good speedwise, then I'll look how to do the same 'transfer with logic' opcodes between the X & Y index registers, stack, and 4 accumulators.
Been thinking recently too, there needs to be a single cycle 16bit NOT (i.e. inverse) on any accumulator/index register.


Still working on the total opcode value list. Will post when they're all proven on Isim.

If you do that, you'll make the register file multi-ported, which will explode its size. It's better to try to fit the logic operators inside the normal path. This would require 3 cycles for the 'TABand' instruction:

1. read A (src_reg)
2. read B (dst_reg)
3. write B (dst_reg)

cycles 1 and 3 are already needed for the regular TAB instruction, so you need to add a cycle in the middle. This is a new one, so it requires an update to the state machine, and it requires an extra MUX in the register file access so you can read from dst_reg. The alternative is to do this:

1. read A (src_reg), src_reg <= B
2. read B (src_reg)
3. write B (dst_reg)

This avoids the extra MUX, but requires an extra write to src_reg.

Anyway, this change is not as straightforward as earlier changes, since register/register operations aren't natural to the 6502. Maybe you should try to come up with something simpler to do first, to get some more experience.

A simpler, but quite powerful, extension to the opcode space is what I've mentioned earlier, which is to allow the source and destination Acc to be different. This does not allow Acc-Acc operations, but it does allow things like ADC A, #10 and store the result in B, with a full set of addressing modes and operands. All this requires is an extra 2 bits in the opcode to designate the destination register, and a few lines of Verilog.