The TF330 is here

[terriblefire]

Maybe next time... you can waste a lot of time with this sort of thing.

Ok it’s now time to do something sad... this guy isn’t cutting it anymore. He’s a MC68030RC16...

9871BD07-280D-40E4-AD54-6265CBD42703.jpeg

He needs replaced..

I have to solder one of these into this board perm....

And the plastic versions don’t fit due to the standoff’s.

0DB0E120-1BA9-44D7-A4B7-2B5CB62C8AE8.jpeg

I await the hate

[8 Bit Dreams]

For me would be easier to redesign that pcb, making 4 holes larger instead of sacrifice ceramic cpu - these are getting rare...

[terriblefire]

The cost would be the same for me and would delay the TF330 until after Xmas

[terriblefire]

Update.

I have SDRAM working well enough to run code and games in. I havent turned on caches yet.

The CIA issue is still present. I can reproduce this reliably and it seems to be the cause of all my problems right now.

Essentially randomly a CIA write doesnt happen. Its very odd. This test code from DiagROM can reproduce my issue reliably.

Code: Select all

.loopa:
	move.l	#$f0,$dff180

	move.b	$400(a5),CIACtrl-V+1(a6)
	move.b	$500(a5),CIACtrl-V+2(a6)

	move.b	#(CIATIME&$FF),$400(a5)
	move.b	#(CIATIME>>8),$500(a5)			; Set registers to wait for 10000ms

.wait:
	move.w	#$0,$dff180

	cmp.w	#120,Frames-V(a6)
	bge	.vblankoverrun

	btst	d2,$d00(a4)
	beq	.wait
	add.l	#1,Ticks-V(a6)
	move.w	#$f,$dff180
.no:

	dbf	d6,.loopa				; Repeat this so we are doing it for a while
	bset	#0,(a3)
	clr.l	d6				; Clear D6, meaning we have executed this without Vblank overrun

	bra	.exit

Essentially the traces show that after a few turns round the loop the write to CIA timer B doesnt happen/take and we never get a reply from BFED01.

Very odd. Nothing unusual on the scope. The cycles are longer than the standard ones. Probably some emulation for the CIAs going on in the chipset.

EDIT: I have attached the trace. The line that seems to be having an issue is

2287 00BFE601 HIGH BYTE AEAE HIGH BYTE 1 0

listing.txt

[terriblefire]

Some interesting behaviour observed.

If you do not DSACK the CIA cycles then they repeat over and over.... At a guess if they arent acknowledged before a certain time in the DSACK cycle then the write is ignored (reads dont really matter because the data is on the data bus all the time).

I get this when using the 020 at 14Mhz

020_cia.JPG

And this when doing the same thing crossing the clock domains at 50Mhz..

030_cia_fail.JPG

Notice how little overlap there is between AS20 being high and DSACK being low in the 030 cycle. I think this is possibly the issue?

[terriblefire]

So if you miss the window completely you dont register a write. just did this artificially as a test..

miss_the_window.JPG

Which results in a completely repeatable/reliable never getting any results.

miss_the_window2.JPG

Very interesting that the chips behave this way actually.

[terriblefire]

Ok so a simple clock switch for these cycles works a treat but seems to have the same timing (to me) gaps as the others. Its a bit wasteful of CPLD space to do this.

030_cia_speed_switch.JPG

It is however 100% reliable.

[8 Bit Dreams]

If You are running out if space on cpld You can take XC95288XL - these are pin compatible with XC95144XL...
That would be even better, cause i can get these cheaper than XC95144XL's.... :)

[terriblefire]

If You are running out if space on cpld You can take XC95288XL - these are pin compatible with XC95144XL...
That would be even better, cause i can get these cheaper than XC95144XL's.... :)

Please tell me where already :)

[8 Bit Dreams]

Please tell me where already :)

Please don't laugh...on Ebay... :oops: :oops: :oops: