Re: [hatari-devel] DSP and HREQ

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi,

OK, I need some help now ;)
Nicolas, I think you've pointed out a bugged part of the DSP emulation ;)

First, I've rewrote the code into hatari dsp emulation like this :
(The if statement seemed to be wrong to me).


static void dsp_core_hostport_update_hreq(void)
{
    int hreq;

    hreq = (dsp_core.hostport[CPU_HOST_ICR] & 
dsp_core.hostport[CPU_HOST_ISR]) & 0x3;

    /* Trigger host interrupt? */
    if ((hreq != 0) && ((dsp_core.hostport[CPU_HOST_ISR] & 
(1<<CPU_HOST_ISR_HREQ)) == 0)) {
        fprintf(stderr, "Interrupt\n");
        dsp_host_interrupt();
    }

    /* Set HREQ bit in hostport */
    dsp_core.hostport[CPU_HOST_ISR] &= 0x7f;
    dsp_core.hostport[CPU_HOST_ISR] |= (hreq?1:0) << CPU_HOST_ISR_HREQ;
}



Now, I get the fprintf message displayed into the console when I run my 
test code.

But : it seems I never reach the $3c address (ie in my test program, I 
never break into dsp_inter)

Could it be because of the     move.w    #$2500,sr ?
Or some bad inner code into hatari ?


Here is my current test code (it seems buggy somewhere as sometimes I 
get some bombs with it).


68030 side :
----------------

    ; Supervisor
    clr.l    -(sp)
    move.w    #$20,-(sp)
    trap    #1
    addq.l    #6,sp

    move.w    #$2500,sr
    move.l    $3c.w,save_dsp_inter_adr
    move.l    #dsp_inter,$3c.w

    move.b    #2,$ffffa200.w        ; Tx interrupt

    move.w    #105,-(sp)        DSP_Unlock
    trap    #14
    addq.w    #2,sp

dsp_locked:
    move.w    #104,-(sp)        DSP_Lock
    trap    #14
    addq.w    #2,sp
    tst.w     d0
    bne.s     dsp_locked

    move.w    #113,-(sp)        DSP_RequestUniqueAbility
    trap    #14
    addq.w    #2,sp

    move.w    d0,-(sp)        DSP_ExecProg
    move.l    #(dsp_mapping_fin-dsp_mapping_debut)/3,-(sp)
    pea    dsp_mapping_debut
    move.w    #109,-(sp)
    trap    #14
    lea    12(sp),sp

TestKey
    cmp.b    #$39,$fffffc02.w
    bne.s    TestKey

    move.w    #105,-(sp)        DSP_Unlock
    trap    #14
    addq.w    #2,sp

    ; Restore
    move.l    save_dsp_inter_adr,$3c.w

    ; The end
    clr.w        -(sp)
    trap        #1



dsp_inter:
    ; Read ISR
    move.b        $ffffa202.w,d0
    move.b        $ffffa207.w,d1
    move.b        $ffffa202.w,d2
    rte


    EVEN

    section data
save_dsp_inter_adr:    dc.l    0

dsp_mapping_debut:
    incbin "hreq.P56"
dsp_mapping_fin:




DSP side :
-------------


HSR        equ    $ffe9    ;Host Status Register
HTX        equ    $ffeb    ;Host Transmit Register


    ; START
    org    p:$0
    jmp     $40

    org     p:$40

    ; General code to initialise port B
    movep    #>0,x:<<$fffe
    movep    #$c00,x:<<$ffff
    movep    #>1,x:<<$ffe0
    andi    #$fc,mr

    jclr    #1,x:<<HSR,*
    move    a,x:HTX

tst_loop:
    jmp    tst_loop





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