| Re: [hatari-devel] DSP and HREQ |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
I'm trying to do the test you're asking.
Is the cpu code OK for you ?
(I'm starting the DSP code now)
; Supervisor
clr.w -(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.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
; Supervisor
clr.w -(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.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
; 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:
trap #14
addq.w #2,sp
; Restore
move.l save_dsp_inter_adr,$3c
; 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:
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