New 65C02/W65C816 copro

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

Re: New 65C02/W65C816 copro

Postby 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: 258
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: New 65C02/W65C816 copro

Postby 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: 1486
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New 65C02/W65C816 copro

Postby BigEd » Fri Sep 08, 2017 1:03 pm

An interesting (and frustrating?) gotcha!

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

Re: New 65C02/W65C816 copro

Postby 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: 258
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: New 65C02/W65C816 copro

Postby 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: 6
Joined: Sat Feb 27, 2016 6:20 pm
Location: MID BEDFORDSHIRE , UK
Contact:

Re: New 65C02/W65C816 copro

Postby 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: 258
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: New 65C02/W65C816 copro

Postby 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: 1486
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New 65C02/W65C816 copro

Postby BigEd » Sun Oct 29, 2017 10:43 am


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

Re: New 65C02/W65C816 copro

Postby 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: 258
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: New 65C02/W65C816 copro

Postby 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: 6605
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: New 65C02/W65C816 copro

Postby 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: 258
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: New 65C02/W65C816 copro

Postby 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: 258
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: New 65C02/W65C816 copro

Postby 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.


Return to “hardware”

Who is online

Users browsing this forum: danielj, duikkie and 13 guests