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

BigEd, I've checked out the data2mem. It doesn't look easy!

Maybe you should consider creating a new project with a schematic as your top level. Then create symbols of the CPU, make an address decode schematic, make a symbol of that and add it to your top level schematic. Then add new source for the ROM, using IPCoregen GUI. The wire everything up... It is very easy for old guys like me still stuck on schematics.
Unless you are looking for the challenge of doing everything verilog!

Yes, I'm afraid it's verilog all the way. I did have a wobble a week ago thinking that schematics might be the answer, but I recovered!

I've no objection to seeing an equivalent schematic, of course. It's just that it's not my preference.

Cheers
Ed

Whew! I wish you luck my friend!!

Maybe an equivalent verilog from schematic?

I've checked out "View HDL Functional Model" under Design Utilities in the Process window, of some of my own schematics in order to try to understand verilog...

One question on the side. Will this CPU be compatible with the 6502 if you pull the upper data byte to zero on reads?

The reason I ask is that I'm looking into getting a GODIL Xilinx module, and the first application would be to make an adapter so that I can plug that into a 6502 socket as a 6502 replacement, and run my original 6502 software on it. I'm certainly looking into this for my 65k projekt. Not being compatible would certainly restrict its applicability, you'd be restricted to new designs.

I fear that 16 bit arithmetic operations work differently than 8 bit wides, so this would be a difference. (Or you could make the "low byte" of the status register reflect the status result from an 8-bit operation, and some high bits reflect the result of the 16 bit operation, but that would need additional flags for the branch/clear/set opcodes, and more. And ROR/LSR would still behave differently...)

André

well, backward branches need sign-extension rather than a zero upper byte, so to make this work you'd need to write in a restricted subset. I did consider it, for the case of having only an 8-bit program loader. But I think it might prove cumbersome. It certainly won't work with general 6502 software.

I do think it's possible to fit 65Org16 into a 40-pin package though: use the same trick as the '816 to multiplex some address signals with some data signals, and have an external latch to separate them. You'd end up with a 24-bit physical address space (or a bit more if you scavenge some pins)