[hatari-devel] DSP "bug" found by Thomas/New Beat

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi,

Just for your info, Thomas from New Beat wrote me a few days ago about a 
bug he found with the Hatari DSP.

I already knew about this : the Rx registers should not be filled with 
the new value immediatly, but after one instruction delay.
There are lot of exceptions in the rule (sometimes 2 instructions, 
sometimes immediatly, not when the change of the Rx register happends at 
the last instruction of a loop, ...)

I thought about fixing this, but I haven't done it yet for 3 reasons :

- this can't happen on a program that works on the Falcon, (I consider 
that all the Falcon DSP programs are well coded :)
- A compiler should warn about this
- I paid most attention to have a good compatibility from real hardware 
programs --> Hatari than the opposite (I wanted to have maximum of 
programs to work).

But in Thomas' case, he use hatari as the main plateform to develop his 
program, and Hatari allows to refresh Rx value immediatly.
(His problem is with the refresh of r0 in the last instruction of the 
loop, immediatly followed by the use of x:(r0)+ in the first instruction 
of the loop

Do you think it should be fixed ? (I'm afraid of the speed of the DSP 
emulation, as I'll have to add a buffer, some tests, and some register 
copies for each DSP instruction execution).
I think there are probably some other case where Hatari is too 
"friendly", or is it really accurate if used as the main "computer" to 
develop with ?

Do you expect a "perfect" reciprocal emulation or do you focuse on the 
real hardware -> emulator way ?

If yes, it'll be after the 1.6.2 release, of course.

Regards
Laurent


Heya,

I'm Thomas of New Beat and I'm working on ACE MIDI/Tracker music
applications.

I think I've found a bug in Hatari. It actually works to good. It is not
important for me to get it fixed but I thought I should tell you anyway.
Perhaps it is a known issue, in that case just ignore this mail.

This works in Hatari but not on real hardware:

 		do	x:(r6),_loop
 		move			x:(r0)+,a	y:(r5)+,b
 		eor	x0,b		b,x0		a,y:(r7)+
 		tmi	x0,a	r4,r0
_loop:		rts

This work both on Hatari and real hardware:

 		do	x:(r6),_loop
 		move			x:(r0)+,a	y:(r5)+,b
 		eor	x0,b		b,x0		a,y:(r7)+
 		tmi	x0,a	r4,r0
 		nop
_loop:		rts

Another problem with this is that Im not sure if the first code above is
legal. I think the assemblator should give an error but it doesn't (QASM)
so perhaps this is not even something to bother with at all. I always use
QASM so it took a while to find this "bug"... anyway, it is no big
problem.

Btw, what a fantastic piece of SW Hatari is. You and the crew have made
an incredible fantastic work!

Br,