Re: [hatari-devel] DSP and HREQ

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


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






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