Re: [hatari-devel] DSP patch suggestion

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hello all,

I created a new patch that will cleanly merge with Hatari. It contains these changes:

Changes without (noticeable) effect:
  • dsp.c: Changing "P ram" to "P rom“ in spaces[2][1]. This element of the array is unused by Hatari and the change therefore has zero effect but makes things future proof in case one wants to add the bootstrap ROM later.
  • dsp.c: Moving the check for program space above the check for internal RAM. This change has no functional effect but makes things future proof in case one wants to add the bootstrap ROM later. Very minor side effect is that one additional condition is checked in case of X and Y internal RAM access. Effect on performance is not noticeable (if one wants to optimise for performance many other things could be improved). No other accesses are affected.
  • dsp_core.c: Removing duplicate HSR initialisation. This has zero effect.
  • dsp_core.c: Moving dsp_host_interrupt initialisation to a different place inside the function. This is just cleaning and has zero effect.
  • dsp_core.h: Adding rom[2] (P ROM). This change has no functional effect but makes things future proof in case one wants to add the bootstrap ROM later.
  • dsp_cpu.c: Moving check for program space above check for internal RAM. See comments in point 2.

Changes with effect:
  • dsp_core.c: Adding host interface initialisation. This function of the DSP was not simulated previously but is required for some DSP code on the NeXT. I don’t know if any Hatari program makes use of this function but I think it should be included anyway to match real DSP more closely. I highly recommend this addition.
  • dsp_core.c: Adding early abort of the hacked bootstrap loader. The real bootstrap loader permanently checks HF0. If HF0 is set, it exits early even if a limited amount of bytes have been transferred. NeXT makes heavy use of this feature. This is required to accurately simulate the function of the bootstrap loader programmed to the real DSP. This addition is highly recommended and has zero negative side effects.
  • dsp_core.c: The real bootstrap loader sets R0 to the amount of bytes copied and OMR to 2. This needs to be added to accurately simulate the bootstrap program and match real DSP. This change is highly recommended and has zero negative side effects.
  • dsp_core.c: Adding host received data interrupt. This is missing from the current Hatari code. It must be a mistake. This is highly recommended to match real DSP.

Changes not included:
  • DMA interface: Atari obviously does not use the DMA interface of the DSP host port. Therefore I didn’t include my implementation of it.
  • Bootstrap ROM: This feature is not necessary. It is more a question of wanting to avoid using hacks (dsp_core.running et al). I did not include this in my patch because it requires extra CPU power without functional benefits.
  • Starting with different modes: The DSP has 4 different modes. Hatari is hard coded to always use mode 2 (normal expanded mode). Real simulation of the modes would be required for using bootstrap ROM. Although in theory there could be other programs making use of this, there seem to be none on the NeXT and probably also none on Atari. Therefore I did not include this.

There seem to be a few white space issues, because tabs are used between code and comments and because changing from SDL types to normal fixed length types messed things a bit. If you want me to fix this, I can provide a patch (replacing tabs with spaces).

Feel free to ask any questions.

Regards,
Andreas

Attachment: hatari_dsp_patch.diff
Description: Binary data


Am 02.12.2023 um 18:50 schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:

The appended patch for Previous might explain some of the suggested changes. It won’t apply smoothly to Hatari. It is just for information purpose.

<bootstrap_rom.diff>

Am 02.12.2023 um 17:52 schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

For my understanding, why do you manage P memory before internal RAM ?

Does this fix any problem or is it better to do it this way for any reason ?


Le 02/12/2023 à 17:47, Laurent Sallafranque a écrit :
Ah yes, you're right.

Thanks,


Le 02/12/2023 à 17:45, Andreas Grabher a écrit :
Hello Laurent,

it is unimplemented in Hatari, but there is a P ROM (bootstrap ROM) at the bottom of P memory space.

Regards
Andreas

Am 02.12.2023 um 17:24 schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

I Andreas,


Are you sure about P rom ? I'm pretty sure it's P int Ram for the 2 first strings


-        { "P ram", "P ram", "P ext memory", "P ext memory" }
+        { "P ram", "P rom", "P ext memory", "P ext memory" }

Regards

Laurent



Le 02/12/2023 à 16:32, Andreas Grabher a écrit :
Hello all,

I want to suggest the appended patch. It contains different parts. Some are just cosmetic changes and some are additional features (that might be unused by Hatari). Please tell me what you think and feel free to ask any question. These changes are already part of Previous.

Best wishes,
Andreas










Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/