| ★ CODING ★ AMSLIVE ★ AMSLIVE n°05 - CPC (S)OS 1ère partie ★ |
| AMSLIVE n°05 - CPC Sos Partie 1 | Coding Amslive |
Cette rubrique s'adresse aux débutants et à tous ceux désireux de (re)découvrir leur CPC. Quelques renseignements pointus seront donnés, mais juste pour information. Si vous ne saisissez pas tout, vous pouvez quand même continuez la lecture. Le plus souvent, on distingue 3 niveaux de programmations chez le CPCiste : le BASIC, l'assembleur avec utilisation des routines "système" et la programmation directe des périphériques (Quelqu'un travaille sous CP/M ?!?). Leurs mélanges donne des résultats puissants, mais le plus souvent, buggés. Heureusement qu'AMSLIVE est là. LA MÉMOIRE De par sa conception (bus d'adresses de 16 bits et bus de données de 8 bits), le microprocesseur ne peut accéder que 65536 (=£10000) cases mémoires (octets) différentes, c'est à dire exactement 64 ko. Pourtant le CPC gère 256 ROMs de 16 ko (4 Mo), et 0.5 Mo de RAM (facilement multipliables). Le truc est de travailler par pages. Pour faciliter la manipulation, chaque page est découpée en blocs de 16 ko, et on peut ne changer que certains blocs (à la manière de ces livres d'enfants où les pages sonl coupées en plusieurs parties et où l'on crée d'innombrables combinaisons en ne tournant que certaines de ces parties). MATERIELLEMENT Ceci est fait par des composants annexes tel le Gâte Array pour les ROMS ou la permutation de blocs, et un PAL pour la RAM. Comme lors d'un adressage, seuls les 2 bits de poids forts sont analysés, ceci explique que la mémoire soit divisée en blocs de 16 ko (2 bits donnent 4 possibilités, et 64/4 = 1 6). A propos des ROMs, notez que la ROM DISC (no7) est traitée comme n'importe quelle autre ROM externe, mais elle n'est pas déselectionnable (sauf sur +). BIENVENUE DANS LA JONGLE Le système d'exploitation du CPC (on l'appelera "système" par fainéantise et habitude) doit constament jongler avec les blocs. Prenons un exemple : une routine système (qui s'éxècute donc en ROM, quelque part entre 0000 et 3FFF -voir schéma) veut lire le bloc 0 de RAM (aussi entre 0000 et 3FFF !). Si on commutait la RAM, plantage assuré, car ce n'est plus la routine en ROM qui serait exécutée mais la RAM à partir de la même adresse (lors de la lecture d'un livre, vous changez de page en plein en plein milieu de phrase, vous ?). Il faut alors avoir une routine située hors de cette zone qui se chargera de commuter la RAM, de la lire comme voulu, de commuter la ROM et d'y resauter.
LOGICIELEMENT : L'EXTERNE EST GERE MAIS PAS L'INTERNE ! Au démarrage, le système teste les ROM externes, qui soit prennent la main, comme l'interface graphique DES ou le moniteur HACKER, soit fournissent les fameuses R5X, extensions résidentes du système. Comprennez : commandes ou programmes entiers, en mémoire (bien sur puisque c'est des roms !), gérées par le système et accessibles sous BASIC. COMMENT CA MARCHE ? Le système est un ensemble de routines qui s'occupent de l'interfaçage matiériel. C'est à dire que c'est lui qui s'occupe de la gestion clavier, écran (texte ou graphique), fichier... A l'encontre de ce qu'on peut trouver sur les ordinateurs actuels, il ne gère pas les différents programmes qui peuvent s'exécuter. En fait, il n'a même pas "la main" ! Il la donne au BASIC si aucune autre ROM ne l'a prise avant. C'est sous interruptions que sont remises à jour les couleurs, qu'est scanné le clavier... Le BASIC, lui, se sert des différentes routines systèmes. Par exemple, la commande INK va appeler une routine qui changera non pas directement la couleur du stylo mais la case mémoire associé à ce stylo. Puis, le système appelé sous interruption lira cette case mémoire et alors changera effectivement la couleur. Je le répète, le système ne s'occupe pas de l'éxecution des programmes. Ceci implique qu'en cas de bug, il y a plantage, et non pas un message "votre programme à planté". Le programme a le contrôle absolu ! Ceci-dit, plusieurs programmes peuvent fonctionner en même temps. Soit parceque les interruptions système sont respectées, soit parcequ'une routine appelée redonnera la main à la fin de son exécution. LES VECTEURS Les routines sont stockées en ROM, c'est entendu. Mais pour les appeller, on ne saute pas directement en ROM : on passe par des vecteurs qui eux sont installés en RAM. Les avantages sont nombreux : en cas d'évolution de la ROM, les routines vont changer d'adresses, mais l'adresse du vecteur reste la même. D'autre part, les vecteurs sont placés dans une zone insensible aux permutations RAM/ROM. On peut y sauter sans risque quelquesoit la configuration en cours. J'ai gardé le plus intéressant pour la fin : on peut détourner ces vecteurs. Il n'y a qu'à placer un saut à vos propres routines. Plus de détails la prochain fois ! AMSLIVE n°5 » La suite : AMSLIVE n°10 - CPC (S)OS 2ème PARTIE : LA MÉMOIRE (2/3)
|
