exxos's DFB1 trials

[exxos]

Hmm, just a thought, is the CPU seeing dsack when the FPU is ssserting, I wonder? Perhaps the CPLD has a failure and can’t read from one of the FPU dsack pins. It would therefore not assert to the CPU correctly.

Well I would assume it is working because without the FPU it crashes right away, with the FPU, it does actually complete the first test.. it crashes on the second.

Don't know what @dml makes of that also.

So from loading..

1.PNG

Number it comes up with is seemingly random each time.

It then waits there until I press space... Then does this..

2.PNG

Perhaps solder a wire to the bottom of the board for the dsack0 and 1 pins at the cpu and have cpu dsack0 on one channel with FPu dsack0 on the other? Same for dsack1?

Lost me now :lol: This is why I like the 68000, it has 1 DTACK, thats it. :lol:

But shouldn't DSACKx on the CPU have a pullup on it ? Or are you actively driving it from the PLD ?

[dml]

CPU is trying to move a constant, an (#imm)ediate value into a FPU register and it didn't succeed, the value that came back didn't match.

Seems like the CPU thinks the instruction actually happened but the data is wrong.

But the 11 bombs means the next instruction didn't work at all, CPU decided it is not implemented.

[dml]

The #spc instruction that crashed with 11 bombs is trying to load special constants to fpu registers, from this table. And it didn't like one, or maybe all of them. The ones at the end are the fun cases. All should work though on a good FPU.

Code: Select all

cf_special_const:
cf_zero:		dc.l	$00000000
cf_nzero:		dc.l	$80000000
cf_one:		dc.l	$3f800000
cf_gtone:		dc.l	$3f800001
cf_0333:		dc.l	$3eaaaaab
cf_pminn:		dc.l	$00800000
cf_pmins:		dc.l	$00000001
cf_pmax:		dc.l	$7f7fffff
cf_pinfinity:	dc.l	$7f800000
cf_ninfinity:	dc.l	$ff800000
cf_NaN:		dc.l	$7fffffff

[dml]

For the curious, all the tests have a similar pattern:

Code: Select all

test_fmoves_spec_reg_mem:

	hash32init	d0					; reset hash
	
	lea		cf_special_const,a0			; table
		
	moveq		#11-1,d7				; count
	
.all:
	foperand32	a0,0,0
	fsetup		1
	fmove.s		(a0)+,fp0				; key operation
	fend
	fmove.s		fp0,(a6)				; recover result
	hash32mr	a6,d0,d1,d4				; roll result into running hash
	
	dbra		d7,.all					; ...for all entries

	hash32emit	a6,d0					; emit the final hash (which is checked against expected result)

	rts

...because the results are all rolled into a running hash, it just takes one bit wrong somewhere in one of the ops in a test group for the test to fail.

[exxos]

...because the results are all rolled into a running hash, it just takes one bit wrong somewhere in one of the ops in a test group for the test to fail.

Though if the same bit was failing every time then wouldn't that mean number which is reported that would be consistent ? :stars:

[dml]

Though if the same bit was failing every time then wouldn't that mean number which is reported that would be consistent ? :stars:

Yes, the fact you get a different answer each time from the same test, means garbage is involved somewhere. Or some negotation isn't happening on the exchange.

BTW there are special FC bits used to address the FPU exclusively (IIRC) - its possible something is up with those because I think it is partly how the CPU decides if the FPU is even present (which causes LINEF exception, 11 bombs).

The FC bits are two of the special CPU address lines. I guess you or BW know more about this side of it than me though!

[dml]

Actually I should have said - if one bit is stuck high or low then yes you'd expect the same answer each time. If one bit is strobing with noise though, you'll get a random answer each time.

So it could be as few as one noisy pins/traces. But it could be more than that. Some kind of noise or broken negotiation though.

[exxos]

Actually I should have said - if one bit is stuck high or low then yes you'd expect the same answer each time. If one bit is strobing with noise though, you'll get a random answer each time.

So it could be as few as one noisy pins/traces. But it could be more than that. Some kind of noise or broken negotiation though.

While noise has been a royal PITA all my life with this stuff, I am not sure how it could work at all. I mean it boots up, ST-RAM, TT-RAM pass, and the FPU is right next to the CPU. It could possibly be the FPU doesn't tolerate the noise like other chips, but it is difficult to prove :( I mean generally things tend to just act up occasionally. But this is completely trashed every single time.

I checked the FCx pins were connected back to the PLD as well.

[Badwolf]

Hmm, just a thought, is the CPU seeing dsack when the FPU is ssserting, I wonder? Perhaps the CPLD has a failure and can’t read from one of the FPU dsack pins. It would therefore not assert to the CPU correctly.

Well I would assume it is working because without the FPU it crashes right away, with the FPU, it does actually complete the first test.. it crashes on the second.

DSACK[x] indicates the size of the transfer, both or either can terminate the cycle. It's possible that only one of those is firing. You'd get detection, but failure in (some!) calculations.

This could be what we're seeing.

Perhaps solder a wire to the bottom of the board for the dsack0 and 1 pins at the cpu and have cpu dsack0 on one channel with FPu dsack0 on the other? Same for dsack1?

Lost me now :lol: This is why I like the 68000, it has 1 DTACK, thats it. :lol:

But shouldn't DSACKx on the CPU have a pullup on it ? Or are you actively driving it from the PLD ?

Here's the AS/DS/DSACK[x] diagram:-

IMG_5994.jpg

So, yes, DSACK[x] to the CPU is driven at all times -- no pull-ups. The CPLD multiplexes DTACK from the motherboard, DSACK[0] from the DSP, and FPU_DSACK[1:0] from the FPU.

The points I've marked with 'OK' have been scoped as good, but it's just occurred to me that if the CLPD for some reason isn't reading one of those lines back properly, it might not be mirroring that assertion on the CPU's DSACK[x] lines.

Unfortunately probing the CPU DSACK lines means soldering a wire on the bottom of the CPU, or tapping the VIAs to the SW of the CPLD (as attached).

Anyway, I was thinking monitor FPU DSACK[0] on channel 1, CPU DSACK[0] on channel 2 and trigger on the former. There should be a 20~30ns delay between them. Repeat for DSACK[1]. If there's a mismatch, we've found our bug!

BW

Screenshot 2022-11-10 at 22.15.36.png

[exxos]

Unfortunately probing the CPU DSACK lines means soldering a wire on the bottom of the CPU, or tapping the VIAs to the SW of the CPLD (as attached).

Anyway, I was thinking monitor FPU DSACK[0] on channel 1, CPU DSACK[0] on channel 2 and trigger on the former. There should be a 20~30ns delay between them. Repeat for DSACK[1]. If there's a mismatch, we've found our bug!

I will scope those via's... Then calling it a night :) I did meet out all the lines from FPU/CPU/PLD and all seem connected fine. DSACK0/1 is entering the PLD as I posted screenshots earlier of those signals.