First glimpse: 65Org16 (6502 with 32bit addresses)

Arlet · Post by **Arlet** » Sat May 21, 2011 5:22 am

To add another accumulator, or other registers really isn't all that difficult. Suppose you want to add a register 'B', which can be used the same way as 'A':

- You'll need to widen the [1:0] regsel path, e.g. to [2:0] regsel. This allows 4 more registers. Widen src_reg and dst_reg the same way.

- Change SEL_A .. SEL_Y to 3'd0 .. 3'd3, and add SEL_B 3'd4.

To use the register B, all you need is extra decoding. The data path is already there. And the only decoding you need to use the B register instead of the A register, is to add a line for 'dst_reg <= SEL_B' and 'src_reg <=SEL_B ', when the IR matches your new instruction pattern. All the instructions that work for A (EOR, ADC, ROL, STA,...) then work automatically the same way for B.

The same thing applies to reg-reg transfers. To add a 'TBX' instruction, you'll need: load_reg <= 1, dst_reg <= SEL_X, src_reg <= SEL_B, and state <= REG when IR==TBX and state == DECODE.

BigEd · Post by **BigEd** » Sat May 21, 2011 5:16 pm

BigEd wrote:

I'm happy to say my simulation has sprung into life!

And now I've seen this design with block RAMs working on FPGA too - at a shade under 50MHz, so I don't need the DCM to produce a divided clock.

Arlet, your RAM code is so much cleaner than mine I'll have to port mine over to use your approach. I just needed to get mine working to satisfy myself.

Next stop on hardware development is to get host communication working properly.

Cheers
Ed

ElEctric_EyE · Post by **ElEctric_EyE** » Sat May 21, 2011 5:21 pm

Arlet · Post by **Arlet** » Sat May 21, 2011 5:21 pm

Note that my RAM is used in dual-port configuration, because I'm using the other part for the video generator. If you don't need that, you can pick the single port configuration, and simplify it even more.

ElEctric_EyE · Post by **ElEctric_EyE** » Sat May 21, 2011 5:22 pm

BigEd · Post by **BigEd** » Sat May 21, 2011 5:30 pm

ElEctric_EyE wrote:

Arlet wrote:

...Since you now have 16 bit instructions, it would be nice to add some more registers. Since the core is already using a register file, with enough resources to support 16 registers (only 4 are used right now), you can easily add 12 more without much impact on core size/speed.

I have a serious interest in adding more registers. I've made small progress mod'ing the cpu.v code to include an additional B, C, D, E registers to the A, X, Y, and Stack.

[snip]
Now that we have a [15:0] IR, maybe there will be room for all transfers between all registers I suggested TXB, TBX, TAE, TEA, etc.
More importantly though, which registers will be like the accumulator? I guess I need to look at the ALU.v code... More accumulator type registers will add some serious power.
Another question: Adding registers=easy. Adding accumulators=how difficult?

It just might be worth(*) a new thread on "65Org16 - more registers" for example, because there might be several things to explore (including the syntax and the implementation for the assembler, and the opcode encodings...) and we can keep them separate.

It's a worthwhile exploration, and I'd like to think 65Org16 is a good place to do that exploration - we have the opcode space, and a working starting point (and even, almost, a working SoC to experiment in)

You can make your own github fork with a single button press, once you've signed up to a (free) github account: that gives you somewhere to put your code.

You can even edit code on the github website, I think, so you don't have to get involved with using the 'git' command line tool. Which is a good thing, because that's yet another thing to learn.

Cheers
Ed

(*) Edit: note that EE has now started a thread for a register-rich variant of 65Org16

ElEctric_EyE · Post by **ElEctric_EyE** » Sat May 21, 2011 6:05 pm

Will do. When I get something working.

BigEd · Post by **BigEd** » Sat May 21, 2011 6:07 pm

Even before - I'm all for discussion. It's just the interleaving can be disorientating, and of course the topic title doesn't describe the topic.

Cheers
Ed

ElEctric_EyE · Post by **ElEctric_EyE** » Sat May 21, 2011 9:51 pm

The "interleaving" was totally unintentional. I prefer a smooth thread to follow as well. I will usually wait until noone is logged in, then post a reply in a thread. So, my apologies once again. After I hit the submit button and the screen refreshed I had just seen yours and Arlet's posts. I was at work and rushing so I may have forgot to check if anyone was logged in...

I would rather collaborate as a team to develop this, 3 minds are better than two or one.

BigEd · Post by **BigEd** » Sun May 22, 2011 8:05 am

Hmm, sounds a very complicated way to have two conversations in one topic. Once again, I recommend a new topic for a new topic. I guarantee all the usual suspects will turn up and you'll have the collaboration you wish for. With an appropriate topic title you'll get more attention from casual visitors and google searches too.

That's certainly what I'll do when I start to explore extensions of the 65Org16. For me, this is a bring-up thread.

Cheers
Ed

(Edit: in case this sounds hostile: I'm only trying to be tidy. As far as I can see, all the same characters turn up in all the conversations on the forum)

ElEctric_EyE · Post by **ElEctric_EyE** » Sun May 22, 2011 11:22 am

BigEd wrote:

Hmm, sounds a very complicated way to have two conversations in one topic... For me, this is a bring-up thread.

Cheers
Ed...

Ah ok. Now I understand.

Now to get us back on track, you had said you had the block ram working, is that the boot ROM with some code to test the core @50MHz? No zero page or stack RAM? I didn't get a chance to D/L from github again...

BigEd · Post by **BigEd** » Sun May 22, 2011 11:29 am

No problem.

I have the block Ram mapped in as low memory, so I can use it as zero page or stack - it is aliased all over the place due to incomplete address decoding. It's only 4k, occupies the first 2G, and zero page is the first 64k, stack is the next 64k.

My ROM is still hard-coded verilog - not memory at all. At present it contains a tiny test program, in due course it will need to contain the vectors and a boot loader.

I haven't quite figured out initialised memory - I've decided it would be a distraction. Also, ideally I would like to minimise the xilinx-specific nature of the project.

Cheers
Ed

Arlet · Post by **Arlet** » Sun May 22, 2011 11:41 am

To initialize memory, you may want to try a simple $readmemh/$readmemb call in an initial block. I've read that modern XST versions can synthesize that as well as simulate it. If some other vendor's tool doesn't support it, at least it is clear what you mean to do (and they may support it in the future). I've never done this myself, because the versions that I worked with didn't have that feature yet.

Here's an example from the XST manual, which also replaces the Xilinx block RAM macro with a generic memory:

Code: Select all

//
// Initializing Block RAM from external data file
//
module v_rams_20c (clk, we, addr, din, dout);
   input clk;  
   input we;
   input [5:0] addr;
   input [31:0] din;
   output [31:0] dout;

   reg [31:0] ram [0:63];
   reg [31:0] dout;

initial
    $readmemb("rams_20c.data",ram, 0, 63);

always @(posedge clk)
    begin
        if (we)
            ram[addr] <= din;
        dout <= ram[addr];
    end

endmodule

For a quick and dirty test, you may even try this

Code: Select all

initial begin
    ram[0] = 0;
    ram[1] = 1;
  // etc
end

BigEd · Post by **BigEd** » Sun May 22, 2011 8:30 pm

Hi Arlet
thanks - that's a really nice idea. I'd hoped to try and report straight back, but I'm still battling with my uart.

Cheers
Ed

BigEd · Post by **BigEd** » Mon May 23, 2011 9:47 pm

well, the simulation is accepting initialisation, and the synthesis is reading the hex file, but the bitstream isn't getting the result. So it looks like I'll need to get data2mem (pdf) sorted out, so I can inject the binary contents into the bitstream directly. It seems I need to cook up a BMM (memory map) file as well.

I do now have a working uart, and some support routines in my tiny test monitor to do buffered I/O with the CPU, and some slightly ropey python on the host side to communicate with the user (that's me.) There is as yet no code to interpret any user input.

I also picked up Ross Archer's Hex loader which is freeware, and mostly have it converted to 65Org16 syntax. It's in the form of a bootable ROM, so that could replace my test code: we then boot straight into a loader.

No update yet on the assembler license, so maybe tomorrow evening I'll commit a patch file to the original.

I did have a look and unfortunately the Ophis assembler looked a bit scary to me: it does all the proper lexing and parsing and takes a lot of code to do it. Whether I can dive in and find the right places to bump it up from 8 bits to 16 I'm not sure. Maybe it's worth a new thread on assembly code bases: which is the best starting point (and are any of the active developers interested in these kinds of explorations)

Cheers
Ed