Programmation système ou hardware?
Voici deux exemples de jeux qui chargent des programmes et données en mémoire. Le premier jeu est Blue War, un programme mélangeant Basic et assembleur. Comme le programme utilise le système pour charger ses fichiers, il est obligé de conserver la zone en début de mémoire et aussi celle localisée entre #A660 et #C000. Le programme utilise probablement l'instruction MERGE pour fusionner les petits programmes en Basic dont il est composé et conserver sa mémoire.
On remarque aussi avant chaque chargement, une bande blanche au début de la zone système aux 3/4, c'est le chargement sytématique du catalogue dans le but de récupérer les informations de localisation des fichiers.
Deuxième exemple avec le jeu Nord & Sud, avec un loader CPM. Le démarrage CPM va charger le secteur de boot à l'adresse #100 (tout en haut de la mémoire). Ensuite, le jeu utilise ensuite la ROM système pour charger son écran logo. Une fois le tatou chargé, il déconnecte définitivement la ROM haute qu'on voit disparaitre du mapping émulateur à droite en bas.
Ensuite les données pour l'intro sont chargées sans qu'une ROM soit connectée, les données écrasent allègrement la zone #A660-#C000 et on voit qu'il finit par se servir de la moitié de la mémoire pour animer le personnage sur son cheval (une technique dite du double-buffer, que nous aborderons... ...plus tard)
Conclusion
La conclusion de cette tentative de thèse, c'est que la programmation système impose de nombreuses limitations :- La programmation système n'est pas plus facile, il faut quand même gérer la logique du programme, les scénarios d'exécution.
- L'affichage est lent (dans notre exemple, 10 fois plus lent).
- Interdiction d'utiliser tous les registres! Il ne faut pas toucher IX, IY ainsi que tous les registres secondaires.
- Impossibilité de charger de très gros fichiers.
- Certaines fonctionnalités système sont incompatibles avec l'usage de la mémoire basse (#0000-#3FFF).
- Les chargements ne sont pas optimisés. Obligé de lire le catalogue pour chaque fichier lu.
- Impossible d'utiliser la mémoire située de #8000 à #C000 comme page vidéo (On verrait le système s'afficher à l'écran)
- L'utilisation du système impose qu'il soit actif et donc ralentit fortement l'exécution d'un programme.
La programmation matérielle pure par contre, permet d'utiliser 100% de l'espace mémoire et 100% de la puissance de calcul disponible, de la façon qu'on souhaite. Et ce n'est pas si difficile que ça, il faut progresser méthodiquement et se construire des briques réutilisables et optimisées.