Page 12 of 12
Re: 32 is the new 8-bit
Posted: Thu Dec 12, 2013 4:26 pm
by Windfall
It is always safe to go with the datasheet
Generally, for worst case timing that is true. But how many engineers will have dumped the W65C816 for quoting this extremely unrealistic timing, is anyone's guess.
How much actual delay (in ns) did you find, compared to the datasheet? It would be nice to find out that the margin between the datasheet and the reality is huge.
From memory, address lines were valid something like 5 to 10 ns after phi1. It figures, of course, that the address is simply clocked into a register connected to the relevant pins, so it's not a surprising number either. When I saw the timing in the datasheet, I immediately distrusted it. WDC does not make very good documentation anyway. Quite messy, buggy and inconsistent ...
I think the discrepancy stems from confusion between the conceptual (where phase 1 is an address and control line setup period, and phase 2 is the transfer, i.e. where address and control lines, in principle, only
need to be valid when phase 2 starts) and the implementation.
Re: 32 is the new 8-bit
Posted: Fri Dec 27, 2013 11:08 pm
by player55328
I have a new processor design that removes the memory pipeline delay (that was required for using bram normally) from my original design. Unfortunately I have not been able to test it with normal sram. How I tested it was by clocking the bram on the negative edge of the clock to simulate normal sram single cycle access. I do not know how fast it will be able to run with sram but I was running it at 48MHz for my testing. The average cycle count for all instructions are half of what the original processors were.
If anyone tries to use it and finds any problems please let me know.
edit:
Well, I found 3 bugs and some extra code already, here are my suggested changes to fix the bugs...
This fixes indirect accesses to internal memory for memory to register operations.
replace
S_WR_MEM_OP,S_WR_MEM_OP: cpu_aw = tmp_a;
with
S_RD_MEM_OP,S_WR_MEM_OP: cpu_aw = tmp_a;
These fix not changing these flags when executing indirect addressing mode store operations.
replace
else next_N = alu_op_inc_neg;
with
else if(inc) next_N = alu_op_inc_neg;
else next_N = negative; //ix/iy writes
replace
else next_Z = alu_op_255;
with
else if(inc) next_Z = alu_op_255;
else next_Z = zero; //ix/iy writes
alu_op and tmp_a does not need to be initialized everywhere they are.
I imagine the compiler is taking care of most of these automatically. If you really want these changes I will upload another zip file. I renamed some variables for better clarity and grouped the code better so a diff with what I have already provide will be pretty big.
Re: 32 is the new 8-bit
Posted: Wed Feb 09, 2022 3:21 pm
by Windfall
For those stumbling across this old thread :
My proof of concept (a full implementation, really) can be read about here :
viewtopic.php?t=6284