Re: [hatari-devel] DSP and HREQ

[ Thread Index | Date Index | More Archives ]

Also, are you sure about the $3c address ?

Le 27/01/2015 23:17, Laurent Sallafranque a écrit :

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");

    /* 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

    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

    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

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


    section data
save_dsp_inter_adr:    dc.l    0

    incbin "hreq.P56"

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

    jmp    tst_loop


Le 26/01/2015 15:49, Nicolas Pomarède a écrit :

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.


Mail converted by MHonArc 2.6.19+