New 65C02/W65C816 copro

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
dominicbeesley
Posts: 625
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: New 65C02/W65C816 copro

Post by dominicbeesley » Wed Sep 06, 2017 2:07 pm

Sounds good though room/pads for a ZIF socket for a ROM is always welcome!

I've gone for a mix of through hole and smd on my latest creations, the advantage of SMD are cost availability etc but hackability is still far easier with through hole chips....I'm still glad I had the sense to put the 245 buffer on my 6809 board (between cpu D bus and ram/video D bus) there are a whole bunch of test tags hanging off that....I wish I'd spent the £5 extra for through hole 157's and extra board space to make my video/ram/cpu multiplexer through hole, I would now have proper mode 7 working!

I've been watching all this with interest!

D

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Fri Sep 08, 2017 12:34 pm

For those interested in hardware/tech details:

A very frustrating intermittent "hang" (spoiler alert) now squashed!

I use the serial port to remote my dev beeb and it was hanging with the 2nd processor when issuing *fx commands - I mute the screen output when sending program listings to speed things up.

I worked out quite quickly that the tube comms was getting out of sync with the parasite stuck in a BIT STATUSREGx infinite loop waiting for data. So I spent a huge amount of time investigating the tube signals, looking for glitches which might latch something early and eat a byte or noise on the address lines causing the write to go to the wrong registers. No problems evident. Cross talk issues on host reads all cured.

The 2nd processor seemed to run fine, Elite ran fine it seemed. BASIC ran fine & I could send programs and they would run (as long as I didn't use *fx3,6!). So the processor runs fine right?! It seemed less flakey at higher parasite CPU clock speeds so parasite tube IO read timings maybe?

Very frustrating. So more time debugging data available flags and tube FIFOs but I can't find anything wrong! More scoping CPU but all the signals seem to be OK and stable at the appropriate edges.

I prepared a test to fill &1000-&7FFF with (seeded) random numbers using ?&xxxx=&yy lines fed to BASIC interpreter via serial and the host from the PC. Then run a BASIC program to check the contents. After a few thousand lines though BASIC didn't work anymore properly... no MISTAKE errors, no program execution. Humm. So tube bytes are being corrupted and some of my writes ended up trampling BASIC...?

Code: Select all

REM test RND
*BASIC
HIMEM=&1000
10srand%=-99
20P.RND(srand%)
30*fx3,5
40FORP%=&1000TO&7FFF
50R%=RND(255):IF ?P%<>R% P."Error @ ";~P%;" mem=";~?P%;" rnd=";~R%:STOP
60N.

FORP%=&1000TO&7FFFSTEP4:!P%=0:N.
?&1000=&CE
?&1001=&C1
....
?&7FFE=&6D
?&7FFF=&51
More scoping and more everything looking fine. No glitches on the tube. No glitches on the parasite bus.

Can't be the CPU/memory timing... it runs Elite and BASIC, right? Try latching the address bus & chip select anyway at phi0 going positive for the RAM. Fixed.

The WDC 65C02 is really quick on changing its address lines on phi0 falling edge. There is no hold at all sometimes. My test board is tiny with very short traces (low inductance and capacitance) and the delays throught the 3.3V-5v buffers and FPGA was just enough that some writes trampled random addresses intermittently I think.

My Tube ULA implementation and hardware was fine all along. Led astray because I thought it was executing properly! #-o

Fun fun fun. :S

User avatar
BigEd
Posts: 2060
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New 65C02/W65C816 copro

Post by BigEd » Fri Sep 08, 2017 1:03 pm

An interesting (and frustrating?) gotcha!

dominicbeesley
Posts: 625
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: New 65C02/W65C816 copro

Post by dominicbeesley » Fri Sep 08, 2017 1:54 pm

You did set up all your timing constraints in your FPGA code didn't you? You didn't, nor do I usually for "slow" stuff but I found the 65816 to be a real bugger for fast timing even though its running at only 8MHz on my board it will happily respond to *very* short glitches, and as you've found it had pretty skinny hold times!

Well done on sorting it out! I can't remember what I did in the end, I know at some point I made two more phases leading phi1/2 by one 50Mhz cycle but in the end I think I managed to tweak the SDC/timing constraints file...a long time ago now. I never did get the 65816 running realiably plugged into the 6502 socket with latches due to spurious clocks getting through

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Sat Sep 09, 2017 10:20 am

I need to take more measurements before I am sure but I think the WDC 65C02 violates the minimum address hold "guaranteed" in the datasheet on some writes. The address then changes before the write cycle is concluded. The RAM is 10ns ISSI stuff so performs a write to that memory too because the address change violates the RAM's address hold after WE high requirement.

I am tight on the address setup time for some reads too - depending on instruction. With the 5v-3.3v buffer delay and the input pin delay on the FPGA the address is not always correct at phi2 posedge on some CPU read cycles.

The write thing wouldn't be a problem if you have a system with DRAM since the CAS negedge would latch the address for the write cycle. Presumably reads are OK because delays in sorting out your RAS (maybe 5-10ns with 74F logic) would allow the correct address to be present... + no extra delay in address lines from level shifting.

But you are correct... I did not bother with timing constraints. The current memory system I have implemented is only a stop gap so I am happy enough with knowing what the problem was & that I don't have a problem elsewhere in the ULA implementation.

I've done the reg3 quirkyness. Does anyone know of some code which tests reg3 one & two byte modes & the interrupts?

User avatar
1987akaTheMoneyPit
Posts: 7
Joined: Sat Feb 27, 2016 6:20 pm
Location: MID BEDFORDSHIRE , UK
Contact:

Re: New 65C02/W65C816 copro

Post by 1987akaTheMoneyPit » Thu Sep 14, 2017 9:15 pm

cmorley wrote:
BigEd wrote:1MHz bus might be about as good because the device is allowed to present some code on the bus which gets run at reset time, and can upload any control software it needs to.
I didn't know that. Interesting.
BigEd wrote:As for the question of the Tube ROM client: it will technically be someone's copyright, but most of us suppose that nobody cares, so it won't be enforced. Same with PCB artwork and schematics.
The problem is if I embed the ROM and make the things available to sell... it defeats the purpose a bit if I have to engineer it and say "find your own boot ROM". I tracked Acorn OS IP to PACE in the late 90s but no idea who has it now. It would be good to get a definitive answer if I can.
BigEd wrote:Electron doesn't have a Tube, but one of the recent upgrade projects includes one. Same for the Atom.
Are they 2MHz like the B/Master?
The Elk's tube is here if anyone is interested? http://www.stardot.org.uk/forums/viewto ... &hilit=AP5
[-X if it ain't broke don't fix it :idea:

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Sun Oct 15, 2017 12:01 pm

After a hiatus in development I'm back to working on the copro again.

The WDC 65C02 I'm using seems to be stable at 21MHz which is promising. It will run BASIC and Tube Elite at that clock quite happily (Tube Elite is unplayable via keyboard at this clock speed though...)

Code: Select all

BBC BASIC CPU Timing Program
Real REPEAT loop        21.69MHz
Integer REPEAT loop     21.92MHz
Real FOR loop           20.00MHz
Integer FOR loop        21.70MHz
Trig/Log test           21.03MHz
String manipulation     22.04MHz
Procedure call          21.87MHz
GOSUB call              21.84MHz
Combined Average        21.53MHz
There is still some work left to do. I need to reprogram the PLL on the fly to change the CPU clock and nail the timing constraints (& .SDC).

I haven't found anything that doesn't work yet but I don't know if my reg3 tube ULA implementation is actually correct or not in one/two byte modes. I implemented it from the Acorn app note :S

Does anyone know of some software which exercises reg3 or indeed a ULA test program?

User avatar
BigEd
Posts: 2060
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New 65C02/W65C816 copro

Post by BigEd » Sun Oct 29, 2017 10:43 am

Does hoglet's OSWORD test help at all?
viewtopic.php?p=106198#p106198
viewtopic.php?p=106346#p106346

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Nov 16, 2017 9:45 pm

BigEd wrote:Does hoglet's OSWORD test help at all?
viewtopic.php?p=106198#p106198
viewtopic.php?p=106346#p106346
I downloaded the ZIP and opened the file in a text editor. It looks like a BASIC program so I fired up BeebEm and imported it to a new SSD image but I am unable to load it. I get Bad Program with LOAD or *LOAD fn 1900

Is it a B BASIC program :S?

Also I've been chasing my tail with something that seems like a bug in my copro but now I am not so sure...

Turn on B. Turn on copro. Ctrl-break. Run TUBE Elite from disc. Get the load new commander prompt. f0 a couple of times to launch. BREAK. Reaload TUBE elite and it sticks on the copyright screen just before the load commander prompt.

It will stick until the host B is power cycled then next load works fine. Resetting the copro doesn't help. *FX 151,78,127 + BREAK doesn't help. Only power cycling the host B.

After Elite other things are flaky too - like RS423 after *fx3,6 hangs - from the looks of it the host is sitting in one of its while !data tube loops.

DFS1.2 for the host code.

So I thought this was my tube ULA implementation but now I wonder if it is something TUBE Elite corrupts on the host... I don't have a real copro to see if that does it too on this B (in case there is something wrong with this B). I tried to buy one but they have gone lolprice in recent months!

Edit: Grr.. now it works all the time and won't hang at the loading screen! Typical.
Last edited by cmorley on Thu Nov 16, 2017 10:30 pm, edited 1 time in total.

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Nov 16, 2017 10:01 pm

These WDC65C02s OC quite well. Here with a core clock of 26MHz

Code: Select all

>RUN
BBC BASIC CPU Timing Program
Real REPEAT loop        26.97MHz
Integer REPEAT loop     27.15MHz
Real FOR loop           24.85MHz
Integer FOR loop        26.96MHz
Trig/Log test           26.06MHz
String manipulation     27.24MHz
Procedure call          27.10MHz
GOSUB call              27.10MHz
Combined Average        26.67MHz

Compared to a 2.00MHz BBC B
I think it will go faster but I need to close the timing. 19ns per half cycle isn't long for things to respond to a CPU read...

User avatar
hoglet
Posts: 7450
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: New 65C02/W65C816 copro

Post by hoglet » Thu Nov 16, 2017 10:15 pm

cmorley wrote:
BigEd wrote:Does hoglet's OSWORD test help at all?
viewtopic.php?p=106198#p106198
viewtopic.php?p=106346#p106346
I downloaded the ZIP and opened the file in a text editor. It looks like a BASIC program so I fired up BeebEm and imported it to a new SSD image but I am unable to load it. I get Bad Program with LOAD or *LOAD fn 1900

Is it a B BASIC program :S?
I think that OSWORD test is just for the Master 512.

Try this one instead:
viewtopic.php?p=159143#p159143

To run it you just:

Code: Select all

CHAIN "TSTRUN"
(this should run on any Co Pro that supports BBC Basic)

Dave

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Nov 16, 2017 10:50 pm

hoglet wrote: Try this one instead:
viewtopic.php?p=159143#p159143
Super thanks hoglet. That disk works. I transfered it to a floppy and mine hangs on test 6. Reading your following post... I implemented R3 from the App note but quite possibly made a mistake so will look at that.

Edit: Ohh yeah... there is an N instead of an A3 on page 14!

Code: Select all

-			3'd4: pdata_out<={p_reg3_avail, !p_reg3_full, 6'b111111};
+			3'd4: pdata_out<={(p_reg3_avail || !p_reg3_full), !p_reg3_full, 6'b111111};
Now all the tests pass.. :)

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Fri Nov 24, 2017 5:08 pm

I managed to make no progress over the ABUG weekend but I'm not complaining. It was a fun weekend. Today I finally think I've nailed the low clock (3-14MHz) instabillity. It is nearly stable at 29MHz on my prototype board now...

Code: Select all

BBC BASIC CPU Timing Program
Real REPEAT loop        30.14MHz
Integer REPEAT loop     30.25MHz
Real FOR loop           27.67MHz
Integer FOR loop        30.16MHz
Trig/Log test           29.02MHz
String manipulation     30.43MHz
Procedure call          30.26MHz
GOSUB call              30.20MHz
Combined Average        29.76MHz
I didn't anticipate this board ever getting that high... I thought low 20s would be the limit but apparently not. A PCB with different buffers & better power & ground might clock faster still.
Next up on the todo is the PLL reconfigure on the fly.

User avatar
BigEd
Posts: 2060
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New 65C02/W65C816 copro

Post by BigEd » Thu Jul 05, 2018 11:59 am

How's this project going? Looks like it could be the fastest physical CPU on the block (FPGAs not counting in this case.)

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Jul 05, 2018 2:13 pm

I modified my original prototype as much as I could but hit the speed wall of the data bus buffer I was using. I drew and ordered some new PCBs using CBT FET switches (in TVC mode) for the level shifting. The boards have arrived but I haven't had time to solder one up yet.

I am hopeful of 35-40MHz perhaps higher still...

User avatar
BigEd
Posts: 2060
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New 65C02/W65C816 copro

Post by BigEd » Thu Jul 05, 2018 2:29 pm

How are you doing the clocking? Perhaps using the FPGA's PLL to make a clock? In which case you've got fine-grained control. No need to swap crystals!

Edit: tweak
Last edited by BigEd on Thu Jul 05, 2018 2:29 pm, edited 1 time in total.

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Jul 05, 2018 2:48 pm

BigEd wrote:
Thu Jul 05, 2018 2:29 pm
How are you doing the clocking? Perhaps using the FPGA's PLL to make a clock? In which case you've got fine-grained control. No need to swap crystals!

Edit: tweak
Yes, the FPGA generates the CPU clock in one of the PLLs. I also used a couple of other outputs skewed by a few ns for IO timing - which a PLL is great for too.

Sadly the FPGA needs >5MHz in clock so I can't directly use the 2MHzE on the Tube connector. So back when I was only targetting 20MHz I generated 8Mhz from the internal oscillator and some FPGA fabric - timed from the BBC 2Mhz - and looped that back to the PLL input. This is fine for 20Mhz but there is jitter - so I put a 3.3v mems oscillator footprint on the new boards. The thought being less jitter would help with reaching the max 6502 core speed.

User avatar
BigEd
Posts: 2060
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New 65C02/W65C816 copro

Post by BigEd » Thu Jul 05, 2018 5:05 pm

I think Dave (hoglet) tried once to get a clock signal derived from the host's 2MHz but because of cycle-stretching couldn't get the PLL to lock.

But part of the job of the Tube ULA (or the HDL equivalent) is to allow the second processor's clock to be completely independent of the hosts, no?

Edit: I'm sure you're right, a clean clock with minimal jitter and exactly 50% duty cycle will be needed to reach the highest speeds.
Last edited by BigEd on Thu Jul 05, 2018 5:05 pm, edited 1 time in total.

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Jul 05, 2018 5:27 pm

The Max10 FPGA has an 80ish Mhz internal oscillator (can't remember quite what it is) so I used that. Basically making a DPLL using both edges of the internal clock and the 2MHzE as a reference - accounting for cycle stretching. This then causes the 8Mhz to jitter by 1/2 an 80Mhz cycle as the rounding error goes +/- one tick on the 8Mhz half period - which then feeds into the PLL causing matching jitter on the PLL clock.

Worked fine with no external components for slow clocks <30Mhz. It might work ok higher too but I think an oscillator will be better.

Yes you are correct, the Tube ULA bridges the clock domains. I used FIFOs made from internal RAM blocks but I might have to change that if I can't close timing at higher clocks - or insert a waitstate >30Mhz. No one is going to care, the host is only running at 2MHz anyway!

I will try non-50% duty cycles. I will crush the high and low clock half cycle periods down until the processor fails (setup violations on the bus will probably be the limit I think). I have a suspicion that I can effectively shorten the low half cycle (where address is set up) - the limit being how fast I can provide the correct data to the CPU.... should be interesting to experiment whatever the outcome.

Edit: I put 10ns SRAM on the board. I think there is some 8ns at a similar price I could switch to if I need 2ns more :D
Last edited by cmorley on Thu Jul 05, 2018 5:29 pm, edited 1 time in total.

User avatar
hoglet
Posts: 7450
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: New 65C02/W65C816 copro

Post by hoglet » Thu Jul 05, 2018 5:31 pm

BigEd wrote:
Thu Jul 05, 2018 5:05 pm
I think Dave (hoglet) tried once to get a clock signal derived from the host's 2MHz but because of cycle-stretching couldn't get the PLL to lock.
Yes Ed, you remember correctly.

It was in ICE-T65 on a Spartan 3E FPGA. In theory, when used in DFS mode (rather than DLL mode), the PLL should lock down to 1MHz. But the cycle stretching causes the PLL to loose lock. In the end I used an independent clock (50MHz in my case) with sufficient synchronisation, and accepted the ~20ns jitter this introduced.

At some point I need to re-visit this, because the timing on ICE-T65 is not quite right yet. Specifically, at the recent ABug, Phill found the Apple IIe would not boot with ICE-T65. Chris, I'd like to understand better your DIY DPLL approach.

But we also need a better characterisation of some actual 6502s to make progress on this. This is something Ed and I have started on.

Dave

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Jul 05, 2018 7:27 pm

hoglet wrote:
Thu Jul 05, 2018 5:31 pm
Chris, I'd like to understand better your DIY DPLL approach.
Written while I was still very much learning FPGA and verilog. The ping ponging timer violates timing on -8 speed grade @ according to Quartus but it works. The internal clock is 82MHz nominal but can be 55-116Mhz says the datasheet.

Here is the verilog:

Code: Select all

	// 8 MHz generator
	localparam FCLKINT = 82;
	localparam FREF = 2;
	localparam SCALE = 1<<24;

	localparam integer TIMEPERTICK = (SCALE*FREF)/FCLKINT;//409200;
	localparam integer TIMEPERTICKMIN = TIMEPERTICK*0.7; // 116 MHz internal clock
	localparam integer TIMEPERTICKMAX = TIMEPERTICK*1.5; // 55MHz internal clock


	reg [19:0] timepertick=TIMEPERTICK;
	reg [23:0] freerunning;
	reg [23:0] freerunning2;
	reg [26:0] tcycle;


	reg [1:0] prevclk_2MHzE;
	reg up;

	// register 2MHzE for finding edge
	always@(posedge clk_internal)
	begin
		prevclk_2MHzE <= {prevclk_2MHzE[0],clk_2MHzE};
	end

	// run cycle timer
	always@(posedge clk_internal)
	begin

		if (prevclk_2MHzE[1] && !prevclk_2MHzE[0]) // negedge 2MHzE
		begin
			timepertick = timepertick + (up?2:-1);
				
	//		if (timepertick>TIMEPERTICKMAX) timepertick = TIMEPERTICKMAX;
	//		else if (timepertick<TIMEPERTICKMIN) timepertick = TIMEPERTICKMIN;

			tcycle=2*timepertick;
		end
		else tcycle = tcycle + timepertick;

		if (tcycle[26]) timepertick = TIMEPERTICK; // not seen a clock in a while, use open loop period			
	end

	// gen free running clock
	always@(posedge clk_internal )
	begin
		freerunning = freerunning2 + timepertick;///2;
	end

	always@(negedge clk_internal )
	begin
		freerunning2 = freerunning + timepertick;///2;
	end

	// sync to clock
	always@(negedge clk_2MHzE)
	begin
		up = ~tcycle[24];
	end

	// 
	//assign clk_8meg = freerunning[21];
	assign clk_8meg = !clk_internal?freerunning[22]:freerunning2[22];
So IIRC on posedge it times the 2MHzE and adjusts the timepertick. On both edges it runs 2 free running clocks and switches between them for the extra 1/2 (internal clock) period resolution. Freerunning isn't synced - it created more jitter and I only needed an 8MHz source for the PLL.

dominicbeesley
Posts: 625
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: New 65C02/W65C816 copro

Post by dominicbeesley » Fri Jul 06, 2018 4:40 pm

You might want to have a look at my TUBE ULA vhdl code I posted further up this thread - the implementation isn't great or full but I used Flancters to decouple the clocks and seemed to work though I never got my board to go much as fast as you're managing!

I'll be looking carefully at your DPLL code above. At present I'm using a modified version of Hoglet's godil code for generating phi2/1 in my 6809+blitter fpga but the jitter is proving troublesome I might try a pll to shift the 50MHz clock up to 150Mhz then use something like your dpll to then generate an onboard 48MHz clock that is synced up to the beeb's clock.

D

dominicbeesley
Posts: 625
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: New 65C02/W65C816 copro

Post by dominicbeesley » Sun Jul 08, 2018 9:41 am

Sorry, that was a bit terse - I'm pushed for time at the moment moving out of one house while rebuilding another.

The way I'd "solved" the clock domain problem was to treat only the available/full flags in the tube registers as mattering in terms of clock domains. I used a flancter to get them from one clock domain to another and then delayed them by another clock in the destination domain to ensure that the relevant register had time to settle - this may have been overkill, however it does seem to work! Other than that I kept the two domains completely unsynchronised.

What I didn't work out properly was how to put this into an SDC file so that the timing analysis understood what was going on. I can imagine it would be doable by somebody who better understands these things. [I'm self taught to a basic level in VHDL (and verilog) but I've never quite got to the bottom of how the timing stuff works - every time I think I've got it I discover I've misunderstood something. There are a number of textbooks on FPGA/CPLD stuff but they all seem to stay well clear of explaining the fundamentals of timing analysis!]

D

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Tue Jul 24, 2018 8:13 pm

I ran some experiments with my new level shifting hardware. With a simple hard coded program fed from the FPGA the W65C02S (40 pin dip version) will do >50MHz @ 5V Vcc. It might not run a proper program at that without crashing...

interestingly it looks like at 3.3V Vcc it might hit 40Mhz which would obviate the level shifting :o I would have to build up another PCB with the level shifters bypassed to try that properly.

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Aug 02, 2018 5:16 pm

Mid 40s MHz seems to be the upper limit with Vcc @5v. This is with running the RAM and FPGA IO @ 3.9v which is still in spec (just).

Still PDQ for a 65C02 :)

Edit: 35Mhz seems to be the upper limit for Vcc @ 3.3v. Again not bad considering the datasheet specs 14MHz @ 3.3v
Last edited by cmorley on Thu Aug 02, 2018 5:54 pm, edited 1 time in total.

dominicbeesley
Posts: 625
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: New 65C02/W65C816 copro

Post by dominicbeesley » Thu Aug 02, 2018 6:41 pm

Impressive! Is there a lot of difference between the wdc/rockwell/other parts? What way does it tend to fail?

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Thu Aug 02, 2018 6:48 pm

dominicbeesley wrote:
Thu Aug 02, 2018 6:41 pm
Impressive! Is there a lot of difference between the wdc/rockwell/other parts? What way does it tend to fail?
I set up a simple test program which is:

Code: Select all

inx
stx zp
nop
inc zp
nop
jmp &aa00
The first thing that dies is that the INC zp does not increment the value. The processor is still executing the instruction sequence - just returning wrong values. If you go much too fast for it then it starts crashing and doing vector pulls...

BTW Dominic, did you want a board with an '816 on? PM me if you are interested. I have adapters (untested but should work :S) for internal or Tube connection. I've plenty of spare PCBs.

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Sun Aug 19, 2018 8:21 pm

I am making headway with the new board. I got it working and stable today... it took me a while to work out why it wouldn't run the Tube client ROM code so did a bit of debugging & head scratching... I eventually realised I had my RAM we & oe inverted :roll:

Once that was sorted it ran OK. Passes the Tube tests hoglet linked. Passes the dorman CPU tests & JGH's BASIC speed test (looped)...

It's dangling off a 50cm cable at the moment and working but I had to remove my ROM breakout board (off another 50cm cable)... poor little abused B :cry:

Next thing is to push the clock up and see where this board will max out... I need to add some waitstate to the Tube ULA read cycles as that is the limit at the moment (@26Mhz). I also think I'll do some test code and time that off another PLL output & sweep it towards the negedge of phi2 until the processor falls over. I should then have an idea of the required setup time of the 65C02 relative to the input clock - then I can nail my SDC constraints file down properly :)

User avatar
BigEd
Posts: 2060
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New 65C02/W65C816 copro

Post by BigEd » Sun Aug 19, 2018 8:25 pm

Spectacular speed! Any photos? Demos or benchmark pics maybe?

cmorley
Posts: 616
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: New 65C02/W65C816 copro

Post by cmorley » Sun Aug 19, 2018 9:04 pm

BigEd wrote:
Sun Aug 19, 2018 8:25 pm
Spectacular speed! Any photos? Demos or benchmark pics maybe?
I'll take some photos tomorrow when there is daylight. :)

As for the speed... don't scroll up the thread :- (where the previous prototype topology maxed out at 29MHz).

I had a thought about the CPU speed limit. It is possible that it simply can't drive the data bus in time (turn around the direction & assert the data) hence why it seems to not write the answers back to RAM but still appears to be executing the instruction sequence. I will try adding a waitstate to writes & maybe that will allow it to run faster.

Post Reply