The RTF65002 Core

[Rob Finch]

The RTF65002 core has been updated to add 65c816 backwards compatibility. It's currently untested, but synthesizes. The core size increased by about 20% and slowed down to 40MHz.
Code is on Github.

[BigEd]

Wow, nice work - could this be the first HDL core with '816 operation?
Here's the link: https://github.com/robfinch/Cores/tree/ ... 5002/trunk
What's the license Rob?
Cheers
Ed

[ElEctric_EyE]

BigEd wrote:

Wow, nice work - could this be the first HDL core with '816 operation?...
Cheers
Ed

The T65 cpu has limited 65C816 compatibility. Not sure how limited though... Good job Rob!

[Rob Finch]

BigEd wrote:

What's the license Rob?

The license is currently LGPL.

I've found and fixed several bugs in the core over the last couple of days. The '02 and 32 bit modes seem to work still as I can run my test system, but I really need some '816 code for testing.

[BigEd]

> LGPL
Great - thanks!

Here's a short 65816 program:
viewtopic.php?p=15531#p15531
It might not be terribly suitable as a test...

Here's a pointer to a C compiler: viewtopic.php?p=8321#p8321

I wonder if rigging up an Apple IIGS type environment would be useful, and then running the ROMs for that machine, as a test?

[Rob Finch]

BigEd wrote:

Here's a short 65816 program:
viewtopic.php?p=15531#p15531
It might not be terribly suitable as a test...

I got it to work as spec'd I think. It displayed 359 zeros on the screen Methinks there is a software bug.
I managed to fix several "hardware" bugs while trying to run this program.

BigEd wrote:

I wonder if rigging up an Apple IIGS type environment would be useful, and then running the ROMs for that machine, as a test?

I think this would be quite an undertaking, but it might be about the best way to test. Likely at least have to mod the keyboard/mouse code to use a PC style interfaces. Got to wondering what a bare-bones GS system would look like.

I have an real IIe sitting at home with an 65C802 cpu in it.

[BigEd]

(It should print the digits of pi - 314 zeros would be forgivable, or even 360, but preferably the first digit should be 3.)

[Rob Finch]

I haven't figured it out yet. There must be an instruction that's failing. When I dump the P array it's all zeros. So candidates are a store that stores zero, (sta P-1,x) or perhaps a shift/rotates fails when doing multiplication or division. It's slow going debugging at the moment because it take 1 1/2 hours place and route. It does seem to iterate properly.

I repost the PI calc code in case I copied it wrong somewhere.

Code: Select all

P	EQU		2
Q	EQU		1193*2 + 2
R	EQU		Q + 2
SSS	EQU		R + 2

Code: Select all

Test816:
		clc
		xce
		cpu		W65C816S
		rep		#$30		; acc,ndx = 16 bit
		mem		16
		ndx		16

		lda		#$1800		; setup stack pointer
		tas

		jsr		INITSUB
		ldx		#359
		ldy		#1193
L1S:	
		phy
		pha
		phx
		stz		Q
;		txa
;		ldx		#5
;		wdm
;		xce
;		cpu		RTF65002
;		jsr		PRTNUM
;		clc
;		xce
;		cpu		W65C816S
;		rep		#$30
;		plx
;		phx
		tya
		tax
L2S:	
		txa
		jsr		MULSUB
		sta		SSS
		lda		#10
		sta		Q
		jsr		ADJ1SUB
		lda		P-1,x
		jsr		UNADJ1SUB
		jsr		MULSUB
		clc
		adc		SSS
		sta		Q
		txa
		asl
		dea
		jsr		DIVSUB
		jsr		ADJ1SUB
		sta		P-1,x
		jsr		UNADJ1SUB
		dex
		bne		L2S
		lda		#10
		jsr		DIVSUB
		sta		P
		plx
		pla
		ldy		Q
		cpy		#10
		bcc		L3S
		ldy		#0
		ina
L3S:	
		cpx		#358
		bcc		L4S
		bne		L5S
		jsr		OUTPUTSUB
		lda		#46
L4S:	
		jsr		OUTPUTSUB
L5S:	
		tya
		eor		#48
		ply
		cpx		#358
		bcs		L6S
		dey
		dey
		dey
L6S:	
		dex
		beq		L7S
		jmp		L1S
L7S:
		jsr		OUTPUTSUB
		wdm
		xce
		cpu		RTF65002
		rts

		cpu		W65C816S
INITSUB:
		lda		#2
		ldx		#1192
IS1:
		jsr		ADJSUB
		sta		P,x
		lda		P,x
		eor		#48
		jsr		OUTPUTSUB
		eor		#48
		jsr		UNADJSUB
		dex
		bpl		IS1
		rts

MULSUB:
		sta		R
		ldy		#16
M1S:	asl
		asl		Q
		bcc		M2S
		clc
		adc		R
M2S:	dey
		bne		M1S
		rts

DIVSUB:
		sta		R
		ldy		#16
		lda		#0
		asl		Q
D1S:	rol
		cmp		R
		bcc		D2S
		sbc		R
D2S:	rol		Q
		dey
		bne		D1S
		rts
		
ADJSUB:
		pha
		txa
		asl
		tax
		pla
		rts
UNADJSUB:	
		pha
		txa
		lsr
		tax
		pla
		rts
ADJ1SUB:
		pha
		txa
		asl
		tax
		pla
		dex
		rts
UNADJ1SUB:
		pha
		txa
		lsr
		tax
		pla
		inx
		rts

OUTPUTSUB:
		wdm		; switch to 32 bit mode
		xce
		cpu		RTF65002
		jsr		DisplayChar
		clc		; switch back to 816 mode
		xce
		cpu		W65C816S
		rep		#$30		; acc,ndx = 16 bit
		rts

[BigEd]

As you have a 65802 system, can you add some instrumentation to the code and debug the difference that way? Going around a 90m P+R loop does sound arduous!
Cheers
Ed

[Rob Finch]

BigEd wrote:

As you have a 65802 system, can you add some instrumentation to the code and debug the difference that way? Going around a 90m P+R loop does sound arduous!

The 802's not a system I've really used a lot in the past. I got it because I wanted the case at one point, but never really got around to using it. 90m P+R isn't really acceptable to me, so I tweaked the core a little bit and reduced the time to 10m. It's amazing how the slightest change can cause the P+R time to vary by a lot. It's because the core is complex so a slight change in routing makes/breaks it.

But, phew! I finally fixed the bug and now it works ! It displays the digits of PI. The bug was in storing 16 bit data, it would place the same data for both the first and second write cycles. It didn't matter with eight bit data.

[BigEd]

That's great! And you got a quick-build option out of it too...

[ElEctric_EyE]

Rob Finch wrote:

...90m P+R isn't really acceptable to me, so I tweaked the core a little bit and reduced the time to 10m. It's amazing how the slightest change can cause the P+R time to vary by a lot. It's because the core is complex so a slight change in routing makes/breaks it...

What are the spec's of your desktop machine Rob? That is a terrible time to wait! Also, what version of ISE are you using?

[Rob Finch]

ElEctric_EyE wrote:

What are the spec's of your desktop machine Rob? That is a terrible time to wait! Also, what version of ISE are you using?

I'm using a quad-core 3.4GHz machine (3 levels of caches) 12GB RAM with Webpack 14.4 (on Windows 8). Webpack sometimes describes the routing as "heavily congested" which may mean there is too much combo logic with not enough regs. Webpack reports using 600MB memory for the design.
I can easily do other things on my desktop (like browsing the internet or working on the software) while waiting. It's just the turn-around time for testing a bug fix can be annoying sometimes.

One issue with using a larger FPGA is the undoutbedly longer P+R times.

[Rob Finch]

RTF65002 now incorporates a spinlock (SPL) instruction. This instruction continuously polls a memory location until the contents of the memory location are non-zero.
The memory must be set to non-zero by another processor OR by an interrupt routine. (The SPL instruction is interruptible).
The instructions replaces spinlock code that looks like:

Code: Select all

j1:
   lda   semaphore+1
   beq  j1

The code becomes just:

Code: Select all

   spl   semaphore+1

The idea is to use the instruction in conjuction with hardware semaphoric memory. Note the new code is two bytes shorter and several cycles faster as a branch has been eliminated.

[barrym95838]

If you execute a

Code: Select all

        spl  65002

do you trigger an Easter Egg?

Mike