Re: [hatari-devel] DSP and HREQ

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi nicolas,

I've found some time working on the test, and I get strange results :

The code of the exception :

dsp_inter:
    ; Read ISR
    clr.l        d0
    clr.l        d1
    clr.l        d2

    move.b        $ffffa202.w,d0
    move.b        $ffffa207.w,d1
    move.b        $ffffa202.w,d2

    ; Display Result (move result into D0 first)
    lea    TextNbBytes(pc),a0
    jsr    PrintHexLong

    pea     Begin_Text
    move.w  #9,-(sp)
    trap    #1
    addq.l  #6,sp

     ; Display Result (move result into D0 first)
    move.l    d1,d0
    lea    TextNbBytes(pc),a0
    jsr    PrintHexLong

    pea     Begin_Text
    move.w  #9,-(sp)
    trap    #1
    addq.l  #6,sp

     ; Display Result (move result into D0 first)
    move.l    d2,d0
    lea    TextNbBytes(pc),a0
    jsr    PrintHexLong

    pea     Begin_Text
    move.w  #9,-(sp)
    trap    #1
    addq.l  #6,sp

    rte


So, I read ISR, then a value sent from the DSP, then ISR again.

under hatari, I get :

ISR = $87
DSP = $3
ISR = $86

Then, There's no more interrupt and I can press space and quit.


Under my real Falcon, the behaviour is different : the interrupt is 
called forever (I never return to the main program to press space, as 
soon as the exception is over, there's another one that starts.
I can't read the 3 values, it scrolls too fast.

I haven't done the second test for now, but at least, the 1st one shows 
a big difference between hatari and real hardware.

I think I read somewhere that one has to reset ISR himself by software 
in the interrupted exception code to disable another exception, I'll 
read again the Motorola doc to find this.

I can send the full code of my test if someone is interrested.

Laurent




Le 26/01/2015 15:49, Nicolas Pomarède a écrit :
> Hello
>
> while looking at the level 6 interrupt ttat the DSP can trigger, I 
> wonder if everything is emulated.
>
> From the DSP user manual, HREQ is set in non DMA mode when RXDF and/or 
> TXDE are set, and HREQ is cleared when both RXDF and TXDE are cleared 
> (this requires TREQ and RREQ to be set in the ICR)
>
> In Hatari, the status of HREQ is maintained in the function 
> dsp_core_hostport_update_hreq().
>
> When HREQ becomes 1, it calls DSP_TriggerHostInterrupt which sets 
> bDspHostInterruptPending=true and creates a pending level 6 interrupt.
>
> But what happens when HREQ becomes 0 at the dsp side ? From the 
> current code, it seems bDspHostInterruptPending will remain true and 
> the level 6 interrupt remains pending ?
> Is this really the case on a real Falcon ? I can't test it myself, but 
> I guess it should set bDspHostInterruptPending=false and cancel the 
> pending DSP's level 6 int.
>
> Can someone test this on his falcon ? (Maybe doug already encountered 
> this ?)
>
> For example :
>
> test 1 :
>
>  - set SR=2500 at the cpu side
>  - have the DSP set HREQ=1 (by transferring data)
>  - we should get a level 6 interrupt at the cpu side, that will call 
> by default exception number $F (at address $3c)
>
> In the interrupt handler :
>  - If we read ISR, is bit 7 set to 1 ?
>  - If we then read the low byte of receive or transmit register, this 
> should clear ISR. Is ISR bit 7 set to 0 after a read ?
>
>
>
> test 2 to test when hreq goes back to 0 :
>
>  - set SR=2700 at the cpu side
>  - have the DSP set HREQ=1 (by transferring data)
>  - poll ISR to see when HREQ=1 in bit 7
>  - when HREQ=1 in bit 7, read the low byte of receive or transmit 
> register
>  - wait for HREQ to become 0 in bit 7 (should be immediate after the 
> read above I guess)
>  - set SR=2500 : nothing shuold happen, level 6 interrupt at $3c 
> should not be called.
>
>
> Nicolas