Re: [hatari-devel] DSP question

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Laurent, this is *not* a bug, it's funny that even you don't remember how it works :))) As far as I remember, it works like this:

DSP -> 030: 2 possible writes without CPU doing anything
030 -> DSP: 1 possible write without DSP doing anything

To be clear, we're talking about hand shaked writes, when DSP/030 checks the other processor state for the "ready bit" on host port. (forgot the exact name, what a shame!)

It's a neat feature, I completely forgot about this one, thanks Doug for refreshing my memory.

On Tue, Feb 26, 2013 at 9:36 PM, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:
Hi,

If you don't read the value from the 68030 side, I don't think you should be able to send 3 values.
I'll have to check this.

Does this just happen for the 3 first transfers (which would indicate a little init bug) or always ?
 
Laurent


Le 26/02/2013 20:27, Douglas Little a écrit :
Hi,

I'm not sure to understand correctly the problem (if there's one).

There isn't exactly a problem (I tried to be clear about that) - but there appears to be some behaviour I did not expect to see and I'm trying to figure out if it makes sense or not.
 

I don't know what you're testing, so I try to guess.

You write a first value into the DSP host ---> to the 68030
Then you write a second one (this one shouldn't be writen into the internal HI register as long as the 68030 has read the first one) ...


Here is something closely resembling what I see (as far as I can tell, anyway - it is somewhat indirect):

DSP->WRITE [ok]
DSP->WRITE [ok]
DSP->WRITE [blocked]
           ......etc
           [unblocked]  [ok] READ->CPU
DSP->WRITE [ok]         [ok] READ->CPU


So I was really expecting to be able to write 1 value (into a completely clear port) before the port blocks, not 2. However this is not a complaint / something broken. I'm just curious about the behaviour implemented in Hatari.

i.e. If Hatari does not implement 2 levels of buffering, I need to find another explanation for what I'm seeing.

Maybe if you have a little test program that I could run on my falcon we could verify if there's a problem ?

Unfortunately I don't - at least not yet. I'm seeing this in quite a complex bit of code, based on excessive spinning activity measured the 3rd of of 6 exchanges made close together (with a long delay until the next 6).

I could try to write a separate test to see if the same thing happens when simplified, but it will probably have to wait a bit longer - then I'll do a few tests at once and report.

Thanks,
D.




--
MiKRO / Mystic Bytes
http://mikro.atari.org


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/