|
Thanks a lot Andreas, I've upoaded your
patch.
Regards
Laurent
Le 09/06/2015 19:44, Andreas Grabher a écrit :
Thanks for the clarification. That makes sense. Finally i
found the problem to be located in the interrupt routine. This
time it is definitely a bug:
Problem description:
dsp_postexecute_interrupts():
switch(dsp_core.interrupt_pipeline_count), pipeline count ==
3, FAST interrupt:
We should jump to the next phase without executing another
instruction if the first interrupt instruction was 2 words long.
Else an invalid second interrupt instruction will be executed
from interrupt_instr_fetch+2 (next entry in the vector table)
before returning to interrupt_save_pc.
The appended patch will fix it. It finally makes the DSP
partially work with Previous, including DMA.
Hi,
> But i have another question regarding interrupts. The
host command interrupt has vector 0x24. But in the
emulator vector 0xFF is assigned to it.
No, that's not true. 0x24 is only the first address of the
DSP host commands interrupts. You can also use 0x26, 0x28,
0x2a, ...
As long as this interrupt can take many values, I didn't
fix it's name to 24. Maybe I should have used XX instead
of FF.
Hope this makes sense for you.
Regards
Laurent
Le 08/06/2015 17:59, Andreas Grabher a écrit :
Sorry, of course that is not a problem in the DSP code. It
was my problem not understanding how it is intended to
work on the first try.
But i have another question regarding interrupts. The
host command interrupt has vector 0x24. But in the
emulator vector 0xFF is assigned to it. Of course that
is replaced with the vector provided by the host. But is
there a special reason not using 0x24? Or did i miss
something in the datasheet?
Hi,
> Found the problem. Obviously the values for
the interrupts are not the vectors, but indexes
to a table.
That's not really a problem. I just needed
some constants to give a name to my interrupts
into the code.
Regards
Laurent
Le 06/06/2015 13:42, Andreas Grabher a écrit :
Found the problem. Obviously the values for the
interrupts are not the vectors, but indexes to a
table.
I
have another question about the DSP
code. The CPU needs to interrupt the DSP
using IRQB.
I looked at the available interrupt
vectors in dsp_core.h:
#define DSP_INTER_RESET 0x0
#define DSP_INTER_ILLEGAL 0x1
#define DSP_INTER_STACK_ERROR 0x2
#define DSP_INTER_TRACE 0x3
#define DSP_INTER_SWI 0x4
#define DSP_INTER_HOST_COMMAND 0x5
#define DSP_INTER_HOST_RCV_DATA 0x6
#define DSP_INTER_HOST_TRX_DATA 0x7
#define DSP_INTER_SSI_RCV_DATA_E 0x8
#define DSP_INTER_SSI_RCV_DATA 0x9
#define DSP_INTER_SSI_TRX_DATA_E 0xa
#define DSP_INTER_SSI_TRX_DATA 0xb
If does not match the on from the
data sheet (DSP56000/560001UM rev2,
see appended file):
0x0000: Hardware RESET
0x0002: Stack error
0x0004: Trace
0x0006: SWI
0x0008: IRQA
0x000A: IRQB
...
What might be the reason for this?
Mistake or intentional difference?
<interrupt sources.png>
Luckily it
turned out that the mode bits in
the system control register are
inverted. So mode 2 is mode 1
and that is the one that is
implemented.
With some additions to the
code (some bits in ICR seemed
to be ignored) now at least it
does something.
Maybe some of these changes
are useful for Hatari too (see
appended file). I'd be glad if
someone could check them for
correctness.
btw. It seems to me that
Hatari is releasing the HREQ
interrupt in a wrong way. DSP
should release it, not CPU.
|