Le langage TGOL

Pinup
SYSTEM 65

SYSTEM 80/80A et PROM de jeu

Présentation du système et du langage de programmation utilisé dans ces flippers.

Introduction

Les flippers des séries 80 et 80A ont en commun qu'ils utilisent tous la même carte CPU et le même système d'exploitation. Le SYSTEM 80A n'est qu'une évolution du SYSTEM 80 et ne s'en différencie que par des changements hardware minimes et de nouvelles PROM U2 & U3.

Ces deux PROM "SYSTEM" contiennent un système d'exploitation spécialisé pour flippers, un peu comme un BIOS. C'est le coeur du système et il assure les fonctions de base que l'on retrouvera ensuite sur tous les flippers:

  • Initialisations (des RIOT 6532, de la RAM, etc...)
  • Gestion de l'affichage (avec multiplexage)
  • Gestion des contacts (analyse et détection)
  • Gestion des solénoides et des sons (commandes temporisées)
  • Gestion de la configuration (DIP switches)
  • Fonctionnement de base (joueurs, parties, crédits, tilt, slam)

On y trouve également les routines de test, la gestion de l'imprimante de service (SYSTEM 80 uniquement) ainsi qu'une API avec un interpréteur de langage TGOL.

Ce système d'exploitation standardisé à été développé par Rockwell pour Gottlieb, sur un DC (Design Center): Rockwell DC

Chaque flipper était ensuite personnalisé avec une PROM de jeu, dans laquelle Gottlieb programmait une configuration et des régles de jeu spécifiques.

La PROM de jeu

Se présente sous la forme d'une ou deux PROM de 512, 1024 ou 2048 octets et contient deux éléments:

  1. Le paramètrage
  2. Le programme de gestion des contacts (régles de jeu)

Le premier permet de spécifier un certain nombre de caractéristiques standardisées, telles le nombre de joueurs, le fonctionnement de l'attract mode, la configuration des bonus (modes, lampes associées), les checksums de contrôle.

Le second permet de programmer le comportement de chaque contact détecté. Il s'agit d'une programmation événementielle, chaque contact déclenchant une séquence particulière écrite en langage TGOL. On peut ainsi programmer le nombre de points à compter, les bonus à affecter, les sons à jouer, etc... Sur le même principe existent des routines spéciales, pour le TILT, pour les débuts et fin de partie, ainsi qu'une routine de "polling" appelée régulièrement environ 6 fois par seconde.

Les PROM de jeu étaient écrites par Gottlieb sur un SYSTEM 65: SYSTEM 65

Le langage TGOL

Afin d'économiser la place mémoire et de simplifier la programmation, un langage spécifique dénomé TGOL (Tom's Game Oriented Language) a été developpé. Ce langage conçu par Tom DeFotis est le successeur du PGOL (Pinball Game Oriented language) utilisé dans les SYSTEM 1. Mais, mis à part le nom, ces deux langages ont finalement peu de ressemblances.

Le TGOL est une sorte de macro-langage, dont chaque instruction est codée sur un seul octet. Selon les besoins, elles peuvent être suivie d'un ou deux paramètres (ou d'aucun). On arrive ainsi à un codage extrémement compact et très éfficace.

Afin de ne pas être limité par le langage, une instruction spéciale permet d'executer directement du code assembleur 6502. Ainsi, ce qui n'est pas faisable en TGOL pourra toujours être programmé en assembleur.

Limitations et bugs

Du fait de l'utilisation de séquences en assembleur, la portabilité du langage se trouve extrémement limitée. Ainsi, on ne pourra pas utiliser un autre CPU qu'un 6502 (ou similaire) et on ne pourra pas non plus porter facilement une PROM d'un SYSTEM 80 à un SYSTEM 80A. En effet, certains appels à l'API du système se font par adressage absolu et les adresses sont différentes entre le 80 et le 80A.

Le langage TGOL n'est prévu à l'origine que pour des PROM de 512 ou 1024 octets. Ceci est fortement contraignant, car pour utiliser des mémoires de 2048 octets il faut jongler avec l'assembleur, le TGOL perd alors beaucoup de son intérêt. Il est dommage qu'une version améliorée ne soit pas apparue, car il aurait été très facile d'étendre les possibilités de ce langage dans ce domaine.

Certains bugs grossiers n'ont jamais été corrigés, comme par exemple l'impossibilité de faire un appel assembleur si l'instruction se trouve sur une frontière de page. Là encore, il n'était guère compliqué d'y remédier.

Remerciements

Nous tenons à remercier Allen Edwall pour son aide, grâce à qui nous avons pu identifier les équipements utilisés à l'époque pour le développement de ce système.

Dernière mise à jour de cette page: 28 Mai 2018