Routines d'interface hôte TOS
La communication entre l'application et le DSP sur l'Atari Falcon030 doit être effectuée via un ensemble d'appels TOS fournis. La virtualisation du matériel DSP assurera la compatibilité si le matériel devait être changé dans une future machine.
Cartographie de la mémoire DSP
La RAM privée que le DSP utilise pour entreposer des données ou des programmes ne rentrant pas dans les ressources internes est fournie par trois RAM statiques de 32 Ko. Cette mémoire apparaît au DSP comme suit. L'espace programme est un bloc contigu de mots de 32 Ko. Les espaces de données X et Y sont chacun des blocs séparés de 16 Ko. Le X et Y sont accessibles, dans la carte du DSP, sous forme de blocs commençant à 0 ou 16 Ko. L'espace programme chevauche physiquement à la fois l'espace de données X et Y, de sorte que le logiciel DSP doit en tenir compte pour éviter que le programme et la mémoire de données ne se corrompent. Notez que X:0, X:16 Ko et P:16 Ko ont le même emplacement dans la mémoire physique et que Y:0, Y:16 Ko et P:0 sont également cartographiés au même emplacement physique. Les services système résideront en haut de la mémoire X avec les sous-programmes DSP. La zone BSS des sous-programmes DSP occupera les 256 premiers mots de la mémoire X et Y. Un appel de sous-programme de vidage par le programme récupérera une partie de cette mémoire pour le programme. Un appel Dsp_Available doit toujours être effectué pour déterminer la quantité de RAM libre du DSP.
Programmes DSP
Certaines étapes doivent être suivies lors de la programmation de la plateforme Atari. Certains des 32 000 mots de la mémoire DSP sont alloués aux programmes système et aux sous-programmes résidents et ne sont donc pas disponibles pour une utilisation par le programme DSP. Un processus hôte doit donc effectuer un appel Dsp_Available pour connaître la quantité de mémoire restante pour son programme DSP. Si la quantité est satisfaisante, le processus hôte doit réserver cette zone de mémoire à l'aide d'un appel Dsp_Reserve. Cet appel empêchera la mémoire du programme d'être corrompue par le système. Il est également nécessaire que le processus hôte empêche l'accès au DSP par un autre processus hôte en effectuant un appel Dsp_Lock. Cet appel doit venir avant tout autre appel pour manipuler le DSP. Cela garantira que l'état du DSP ne sera pas modifié par quelqu'un d'autre pendant que l'application l'utilise. Lorsque le processus hôte utilise le programme DSP, il doit effectuer un appel Dsp_Unlock pour permettre à d'autres processus d'utiliser le DSP. Si un appel à Dsp_Lock renvoie une valeur «DSP busy», le processus hôte doit attendre avant d'effectuer des appels système DSP jusqu'à ce qu'un Dsp_Lock réussi puisse avoir lieu. Le non-respect de ces règles entraînera de mauvais résultats imprévisibles lors de la communication avec le DSP. Avant d'effectuer un appel de déverrouillage, l'application hôte doit s'assurer que le processus DSP a restauré l'IPR (X:$FFFF) et le MR à leur état d'origine.
Sous-programmes DSP
L'existence de sous-programmes DSP permet au système d'avoir plusieurs processus DSP résidents en même temps. Cela économise au système le temps de charger chaque programme dans le DSP chaque fois qu'il doit être utilisé. Ces sous-programmes resteront résidents dans le DSP jusqu'à ce qu'ils soient expulsés par d'autres sous-programmes ou vidés par un programme DSP souhaitant plus de mémoire. Les sous-programmes DSP sont soumis à beaucoup plus de contraintes et de restrictions que les programmes DSP. Le code de sous-programme doit être complètement déplaçable. Lors de l'écriture du code de sous-programme, les instructions doivent commencer à l'adresse 0. Lorsqu'un sous-programme est appelé via une commande hôte, le sous-programme peut obtenir son registre PC de démarrage via le port hôte. Cet emplacement de début étant envoyé par TOS doit être lu par la taille du sous-programme est limité à 1024 mots d'instructions DSP. Tout ce qui est plus grand serait probablement plus correctement exécuté en tant que programme. Le code sera déplacé quelque part dans la mémoire RAM du DSP externe. Il faut prendre soin de faire relocaliser toutes les adresses utilisées dans le programme (adresses de fin pour les boucles do par exemple) en se basant sur le compteur du programme d'origine. Toutes les données initialisées doivent être déclarées dans l'espace programme dans lequel elles sont contenues. Un bloc de mémoire X et Y a été mis de côté pour un espace variable non déclaré de sous-programmes. Cette zone est située dans les 256 mots de mémoire DSP les plus élevés de l'espace mémoire X et Y (X:3F00 - X:3FFF). Cette zone peut être utilisée librement par le sous-programme mais comme cette zone est utilisée par tous les sous-programmes, il ne faut pas supposer que la mémoire sera préservée la prochaine fois que le sous-programme s'exécutera. Les programmes hôtes doivent utiliser la fonction Dsp_Lock avant d'exécuter un sous-programme DSP. Étant donné que les sous-programmes DSP sont exécutés sous forme d'interruptions via les commandes hôtes envoyées par le système, ils doivent être interrompus par un RTI après la fin de son exécution. Le sous-programme ne doit assumer aucun état initial du DSP puisque son état est déterminé par des programmes et sous-programmes précédemment exécutés et non à partir d'un ensemble de démarrage. Une séquence typique d'appels pour exécuter un sous-programme peut ressembler à ce qui suit :
- if(!Dsp_Lock()) {
- ability = Dsp_RequestUniqueAbility();
- handle = Dsp_LoadSubroutine(ptr,size,ability);
- status = Dsp_RunSubroutine(handle);
- Dsp_DoBlock(data_in,size_in,data_out,size_out);
- Dsp_Unlock();
- }
Une manière plus efficace d'exécuter le sous-programme serait de vérifier d'abord si un sous-programme existe déjà sur le DSP satisfaisant aux exigences de l'application :
Capacité du programme
La capacité d'un programme (et d'un sous-programme) doit être signalée au système lors du chargement du processus DSP. Cette capacité est soit une capacité prédéfinie ayant été officiellement enregistrée auprès d'Atari, soit une capacité unique ayant été acquise par un appel Dsp_RequestUniqueAbility. Cette capacité peut être utilisée pour déterminer si l'hôte a besoin de recharger son processus DSP ou s'il peut utiliser un processus existant déjà à bord du DSP. Le concept de base de l'interface hôte est que les programmes et sous-programmes DSP n'appartiennent pas à l'application hôte les ayant chargés. Une fois chargés, les programmes DSP deviennent partagés et librement utilisables par toute application hôte souhaitant les utiliser.