Re: [hatari-devel] DSP for Previous

[Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>]

You're welcome! I found some more problems. But now it seems that the DSP works for me!

Most problems i found were related to the interrupt system. It does not reflect real behavior. I think i found most issues, but with this method of doing interrupts we will run into further problems sooner or later. I think it needs to be rewritten. My current patch is just a workaround.

Now it works like this:

The device sends the interrupt to the DSP like some kind of message. If it is not masked, it is then added to a list. The DSP reads the interrupt from the list, removes it and executes the interrupt service routine. If a masked interrupt is unmasked, the interrupt message needs to be re-sent. If an interrupt is on the list while it gets masked, it needs to be removed from the list. If the service routine does not make the device release the interrupt on first try, it needs to be sent again, if it isn't masked.

How it should work:

The device asserts the interrupt line. The DSP samples the line and sees the interrupt, if it is not masked. It executes the service routine, which then makes the device release the interrupt line. If a masked interrupt is unmasked, the DSP will start seeing it. If a pending interrupt is masked, the DSP will no longer see it. If the service routine does not make the device release the interrupt, the DSP will keep on seeing it, unless it is masked.

All these things can be emulated with the current behavior. But it is difficult to understand and can get quite complicated.

Another problem i found, is that the register R0 is not set to the correct value after simulated bootstrap. It should be loaded with the actual byte count. Furthermore writing to HF0 should stop the bootstrap early and start execution.

Is there a special reason, we don't use the program from the real Boot-ROM? It is documented in the datasheet.

Now not to be misunderstood:

I think this piece of software is really great! It seems to be very accurate im almost all cases and mostly complete. The problems i found are (with exception of the interrupt handling) only rare edge cases. Almost everything worked out of the box! Thank you very much for this!

I appended the patches and workaround for the mentioned problems. You may need to apply the first two manually, as i made some irrelevant changes in between (DMA interface). You may also need to fix some Atari-specific interrupts. I only did it for the host interface interrupts, because i can't test the others.

Attachment: dsp_patch3.diff
Description: Binary data

Attachment: dsp_patch11.diff
Description: Binary data

Attachment: dsp_patch12.diff
Description: Binary data

Attachment: dsp_patch13.diff
Description: Binary data

Am 11.06.2015 um 00:10 schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

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.

Am 09.06.2015 um 00:25 schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

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?

Am 07.06.2015 um 23:48 schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

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.

Am 06.06.2015 um 10:39 schrieb Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>:

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>

Am 04.06.2015 um 11:42 schrieb Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>:

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.

<dsp_patch3.diff>

Am 03.06.2015 um 19:10 schrieb Douglas Little <doug694@xxxxxxxxxxxxxx>:

Hi,

I added the DSP code from Hatari v1.8.0. It was easy to make it compile. But then i ran into an early problem:

The 56001 has 4 operating modes:

Has anyone some insight in how the other modes could be implemented? At first look the differences between the modes seem to be mostly related to DSP reset.

IIRC the modes affect two things - the reset 'delay' (16 cycles vs 'lots') and the address of external memory to bootstrap from. However, I haven't used any of that so there may be further complications :)

D