Page 5 of 7
Posted: Sat May 21, 2011 6:05 pm
by ElEctric_EyE
Will do. When I get something working.
Posted: Sat May 21, 2011 6:07 pm
by BigEd
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
Posted: Sat May 21, 2011 9:51 pm
by ElEctric_EyE
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.
Posted: Sun May 22, 2011 8:05 am
by BigEd
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)
Posted: Sun May 22, 2011 11:22 am
by ElEctric_EyE
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...
Posted: Sun May 22, 2011 11:29 am
by BigEd
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
Posted: Sun May 22, 2011 11:41 am
by Arlet
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
Posted: Sun May 22, 2011 8:30 pm
by BigEd
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
Posted: Mon May 23, 2011 9:47 pm
by BigEd
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
Posted: Tue May 24, 2011 12:18 am
by ElEctric_EyE
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!
Posted: Tue May 24, 2011 5:50 pm
by BigEd
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
Posted: Tue May 24, 2011 6:55 pm
by ElEctric_EyE
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!!
Posted: Mon May 30, 2011 12:24 am
by ElEctric_EyE
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
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...
Posted: Mon May 30, 2011 5:45 pm
by fachat
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é
Posted: Mon May 30, 2011 5:54 pm
by BigEd
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)