It's working! Thanks a million Arlet!

I did a test where the hsync was one of the inputs and a branch if control flag 0 set (BCF0S $FFFE) and it successfully looped until hsync went low. I will update Github soon. Also, since I thought I was going to have to test the bits by masking, in the process of adding the inputs to the status register, I also added 16 opcodes to transfer the value of the status register to any accumulator. It added a MUX to the register file, which seems to have added over 100 LUTs. Although I'm not sure of the branching opcodes did this.
I'm running it through ISE now, so I may just remove this transfer function if it was the cause of the bloating.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The new code probably doesn't match any template for a memory, so the register file got implemented as flip flops instead. It's best to keep the register file assignment as one line QAWXYS[regsel] <= new_reg, and play with regsel/new_reg instead.

I removed it, but LUT's still seemed high. I ran smartexplorer again and after 23 runs it passed with a timing score of 0. So the cpu can still run at 100MHz in the project.
I'll add back the code for transferring status register to accumulator and rerun smartexplorer.

EDIT: Yeah, there's no hope it'll run @100MHz with that code. I'll delete that one.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Arlet briefly mentioned here about modifying his core to reduce the cycle time of the 2 cycles opcodes down to 1 cycle. These are opcodes like INX, TXA, PLA, etc. I didn't want to disturb that thread, so I ask him here: How would one go about this? There's enough software I've written for the character plotting and circle drawing in this thread that a real world test would be no problem to try to implement these changes in order to see if I'm successful.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

It seems I missed a lot of activity with the 65org16 cores. Would you be so kind as to summarize, in a few lines, the taxonomy of the 'org16 cores? Perhaps a line or two each, with distinguishing characteristics, level of completion/usability, etc. Or point me to another discussion if that makes more sense.
Thanks

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Give me a few days... I am lapsing in my header posts for the .b core and the .d core threads. More so in the .d core header. Both thread headers desperately need to be updated.
If you wish you can view my progress in Github. There is a .d core branch, and the .b core branch I took from BigEd. The files to observe for evolution would be ALU.v, cpu.v, and supporting-macros.a65 on both branches.

The .b core was meant to be run at no less than 100MHz. I diverged to the .d core when I widened the status reg to 32-bits (even 16-bits), but this core is meant to run at the same speed as a video pixel clock. Right now that is 70MHz with a resolution of 1024x768.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

PLA is a different beast, because it requires a memory read. A first step would be to consider all instructions that don't need memory access, so no operands, and no stack usage. The shift/rotate accumulator instructions can be left out in the first step. That leaves: the clear/set flag instructions, register inc/dec, and register-register transfers.

Reducing these to 1 cycle requires: updating the instruction decode so that these instructions go to DECODE state instead of REG state. So, instead of DECODE->REG->DECODE->REG, it will be DECODE->DECODE. In the current situation, when you do INX for instance, the ALU is fed with 'X' and '0', and CI=1. This is done in the REG cycle. The ALU takes one cycle to do the addition, so in the next (DECODE) cycle, ALU outputs X + 1, and this is stored back into the register file.

If you want to save a cycle (without adding a pipeline stage), there should be a direct path from register file -> inc/dec -> register file, without the 1 cycle ALU delay. One option could be to add a simple incrementer, only capable of doing -1, +0, +1. The output from that incrementer should be written to the register file instead of the output from the ALU. Without the BCD logic, we now have:

Where 'ADD' is the ALU output. This should be changed to something like this:

Where INCR is the output of the new incrementer, and 'bypass' is a register that is set to '1' for the new 1-cycle opcodes.

Of course, you also need to update the flags.

It would be great to have that overview as the head post of a new topic!

I catalogued (some) active threads at viewtopic.php?f=1&t=1982 but I haven't updated it recently, and in any case it doesn't describe the cores in quite the way enso is asking.

Cheers
Ed

Thanks, BigEd, for a really good resource page. I am on a cataloguing kick I suppose. We have so many cores at this point, and it's hard to see what's what sometimes. Those who spend a lot of time on specific projects know all the details of course, but it would be nice to have a chart of some sort, with distinguishing features, core sizes, project goals, etc. for all the cores in one place. That way, at a glance, one can pick a few prospects for any project, and then do deeper research.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Yes, there's value in an overview. I recommend well-titled new threads for this kind of thing. It's sometimes hard to find specific wisdom in mega threads, which serve a different purpose.

I see your gentlemens' point. I think the .b core thread header is pretty specific, but let me know what other info should be on there and I will then put the same type description for this .d core thread header. I will leave the overview thread for BigEd.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Thanks EEye. Is there a .c core which we missed?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Ah, thanks. Looks like I kind of took over the .c core thread. So it becomes some ideas - hopefully practical and sound ideas - without any attempt at implementation.

It was my fault, by no means blame yourself! I had met a few goals successfully early on with the .b core, with lots of help BTW (Arlet especially with his ideas and mentoring, and Michael with his very useful code for the bidirectional register databus ), that I prematurely started the .c core thread. This was at a time when I was fiddling with Verilog. By fiddling I mean struggling with just the syntax of it. So attempting some more serious mod's of Arlet's core was a pipe dream at that point. Now I feel I'm ready to tackle Arlet's latest suggestion, a few posts ago, of reducing some opcodes' cycles, with just a few hints so as not to be a burden.

When the .d core is finally done, which I don't expect will be too much longer, definately before then end of the year, most likely fall, I will be trying some of the code back into the .b core and still see if that core is 100MHz capable.

Speaking about 'if a core is 100MHz capable', we need to agree on what a test suite should be for a core, on an FPGA. To start, I like the idea of 1K Zero Page Block RAM, 1K Stack Block RAM, 4K Block ROM (for reset vectors and OS). Would someone like to start this thread, I'm too busy...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502