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.

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

...

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.

...

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

Will do. When I get something working.

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

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.

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)

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

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

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:


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

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

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