Langage FOCAL

[assinie]

FOCAL?

Formulating On-line Calculations in Algebraic Language

Il s'agit d'un langage développé par DEC pour le PDP-8 en 1968.

Le site http://homepage.cs.uiowa.edu/~jones/pdp8/focal/ fourni un peu de documentation.
Le manuel de 1968 est disponible ici et celui de 1970 ici

J'ai trouvé des sources pour le KIM-1 sur le site de Hans Otten et je me suis dit que ça pourait être amusant de le porter sur l'Oric (je ne pense pas qu'il en existe une version Oric)
Je n'ai fait que très peu de modifications:

• Changement de routines pour la lecture du clavier et l'affichage
  
• Ajout d'une procédure pour le déplacement en mémoire
  
• Ajout d'une procédure de patch en fonction de la version Oric-1/Atmos
  

La version cassette originale est en 2 fichiers, le premier écrase la page 0 et le deuxième est l'interpreteur chargé à partir de l'adresse $2000.
Pour la version Oric, je n'ai fait qu'un seul fichier chargé en $4000 puis la page 0 est écrasée et le reste est déplacé en $2000.

Le fichier source dont je me suis servi est FOCALV3D.zip
La documentation correspondante est ici
La touche [ALT MODE] de la documenation est la touche [ESC] de l'Oric

Les numéros de lignes sont des nombres décimaux et non des entiers comme pour le BASIC. La partie entière indique un groupe de lignes et la partie décimale une étape de ce groupe.
Les noms de variables sont sur 2 caractères dont le premier est une lettre différente de F et le second un chiffre (dans la version KIM)
Il n'existe que très peu de commandes (qui peuvent toutes être abrégées par leur initiale):

• ASK
  
• COMMENT
  
• CONTINUE
  
• DO
  
• ERASE
  
• FOR
  
• GO
  
• GOTO
  
• IF
  
• MODIFY
  
• ON
  
• QUIT
  
• RETURN
  
• SET
  
• TYPE
  
• WRITE
  

Plus quelques fonctions spécifiques dont le nom commence par F (FABS(), FRAN(), FINT(),...) d'où la limitation pour les noms de variables.

Exemple de programme (la commande WRITE affiche le listing du programme, le prompt est *):

Code:

*WRITE

 C FOCAL-65 (V3D) 26-AUG-77

 1.10 FOR X=1,5;DO 2.0
 1.20 GOTO 3.1

 2.10 TYPE !"     "%3,"X="X
 2.20 SET A=X+100
 2.30 TYPE !"     "%5.02,"A="A

 3.10 QUIT


Exécution:

Code:

*GO

     X=  1
     A=  101.00
     X=  2
     A=  102.00
     X=  3
     A=  103.00
     X=  4
     A=  104.00
     X=  5
     A=  105.00*


Il y a quelques trucs sympas comme la possibilté de rediriger l'affichage vers une variable et la saisie clavier depuis une variable, un mode trace activable pour une partie d'une ligne de programme uniquement ou globalement (faire GO ? au lieu de GO), ...

Le fichier .tap joint fonctionne aussi bien pour Oric-1 que pour Atmos mais uniquement avec Euphoric.
Il y a un problème avec Oricutron dont je ne suis pas encore parvenu à trouver la cause (si quelqu'un à une idée...)

Je n'ai pas essayé avec un véritable Oric/Atmos donc je ne sais pas lequel des 2 émulateurs à raison...

Fichiers joints

FOCALV3D.tap.zip Vous n'avez pas la permission de télécharger les fichiers joints.(5 Ko) Téléchargé 7 fois

[didierv]

Un langage de folie !
Quelle perversion... A part le fait que j'ai toujours du mal avec mon clavier oricutron mal configuré, peux tu préciser ce qui ne va pas ???

J'ai chargé ton tap dans oricutron 1.1 et apparemment cela fonctionne, mais je n'ai pas saisi le programme

[assinie]

Bonjour,

Les soucis que je rencontre avec Oricutron sont les suivants:

• Normalement au démarrage on obtient une ligne : ?-17
  mais avec Oricutron j'obtiens: ?-1?
  
• Si on tape la commande: "TYPE 1", l'Oric doit afficher "1.00000" avec Oricutron j'obtients "-1.8000" et une erreur -8 (de mémoire, je n'ai pas l'émulateur sous la main)
  
• Je ne parviens pas non plus à saisir une ligne de programme: 1.1 TYPE "TEST" , me renvoie systématiquement une erreur et  la ligne n'est pas enregistrée.
  

J'ai fait les tests avec plusieurs versions d'Oricutron, y compris la dernière en SVN et j'ai toujours les mêmes problèmes.

D'après ce que j'ai vu le problème est qu'à un moment je récupère une valeur incorrecte mais je ne sais pas pourquoi.
Le mode debug ne me permet pas de tracer le problème, bien au contraire je pense qu'il en rajoute. FOCAL utilise l'instruction BRK pour l'affichage des erreurs.

J'ai recompilé Oricutron pour pouvoir sortir une trace de toutes les instructions exécutées ainsi que la valeurs des différents registres, option non active par défaut, mais ça ma sorti 120 Mo de logs et je n'ai pas encore eu le courage d'examiner le fichier  

Je pense à un problème soit au niveau de l'émulation d'une instruction - peu probable à mon sens - ou de la gestion de la pile, soit un problème dans la gestion des interruptions (plus probable).
J'ai testé le programme dans un émulateur de carte à base de 6502 (py65mon) et je n'ai pas de problème et comme ça fonctionne avec Euphoric, je suppose que le soucis provient d'Oricutron.

Pour mémoire, j'utilise Oricutron sous Linux, je n'ai pas fait le test avec une version Windows, peut-être que c'est spécifique à la version Linux.
Peux-tu me dire si tu rencontres les mêmes problèmes?

Sinon, dans la série langages bizarres, j'ai aussi écrit une version de PILOT mais en BASIC ce coup-ci, à partir d'un source assembleur (juste pour le fun)
Le programme PILOT est directement dans le lilsting BASIC et l'interpréteur les cherche dans le source BASIC, le tout avec moultes manipulations de pointeurs de variables.

[Hialmar]

J'ai exactement les mêmes problèmes avec la dernière version Mac d'Oricutron :(

Euphoric sous Dropbox fonctionne parfaitement par contre.

Encore une preuve du génie de Fabrice

[assinie]

Ca se corse, je pensais que l'anomalie était "stable" et limité à certaines routines du code mais je me suis rendu compte par hasard hier que le comportement varie dans le temps.

Je m'explique, j'ai déclaré quelques variables pour faire des tests "SET A=5; SET B=5.5 ..." puis je demande plusieurs fois la liste des variables et leur contenu avec la commande "TYPE $".
Le résultat n'est pas toujours le même et le nom des variables peut être altéré de temps en temps.

Ca me fait de plus en plus penser à un problème de gestion des interruptions par Oricutron mais je n'arrive pas à bien cerner d'où cela peu venir (peut être une gestion de contexte incorrecte)
Il faudrait que je fasse un test en désactivant toutes les interruptions pour le confirmer.

Je vais continuer à éplucher les 100Mo de traces avant de me re-plonger dans les sources de Oricutron.

Est-ce que quelqu'un sait si Euphoric peut aussi générer un fichier de trace des instructions exécutées comme peut le faire Oricutron?

[assinie]

Ca y est j'ai trouvé

En fait ma première intuition était la bonne mais je l'avais classée comme "peu probable"  parce que je pensais que ça aurait déjà posé des problèmes avec la ROM ou d'autres programmes en LM.

Après un test négatif en interdisant toutes les interruptions, j'ai chargé un programme de test des instructions 6502 histoire de vérifier que tout était correct...

Raté: le programme m'indique une erreur dans l'un des tests, je relance ce test en mode pas à pas et je vérifie les résultats avec un autre émulateur pour lequel je sais qu'il n'y a pas de problème.

Et l'instruction gagnante est: ADC
Elle ne gère pas correctement le flag V.

Le code suivant devrait se terminer en $500A

Code:


5000    CLV
5001    CLC
5002    LDA #$B4
5004    ADC #$B4
5006    BVS Ok
5008    BRK
5009    BRK
Ok:
500A    BRK


mais il se termine en $5008.

Après l'exécution de l'instruction ADC, en devrait avoir:

Code:


       PC  AC XR YR SP NV-BDIZC
6502: 5006 68 00 00 00 01110001


Mais on a:

Code:


       PC  AC XR YR SP NV-BDIZC
6502: 5006 68 00 00 00 00110001


Du coup le BVS n'est pas exécuté et  programme ne fonctionne pas...

Je pense que peu de programmes doivent utiliser les instructions BVS et BVC et qu'il ne doit pas y en avoir dans la ROM ni dans Sedoric (pour FT-Dos j'ai vérifié et il n'y en a pas!)

Pour ceux qui peuvent recompiler Oricutron, le patch à appliquer est le suivant (SBC semble avoir le même problème):

Code:


--- 6502.c 2014-10-23 02:38:49.179408990 +0200
+++ 6502.c.new 2014-10-23 02:38:29.210833886 +0200
@@ -120,7 +120,7 @@
                  cpu->f_n = cpu->a&0x80;\
                } else {\
                  r = cpu->a + v + cpu->f_c;\
-                 cpu->f_v = ((cpu->a^v)&(cpu->a^(r&0xff))&0x80) ? 1 : 0;\
+                 cpu->f_v = (~(cpu->a^v)&(cpu->a^r)) & FF_N ? 1 : 0;\
                  FLAG_ZCN(r);\
                  cpu->a = r;\
                }
@@ -172,7 +172,7 @@
                  cpu->f_n = cpu->a&0x80;\
                } else {\
                  r = (cpu->a - v) - (cpu->f_c^1);\
-                 cpu->f_v = ((cpu->a^v)&(cpu->a^(r&0xff))&0x80) ? 1 : 0;\
+                 cpu->f_v = ((cpu->a^v)&(cpu->a^r)) & FF_N ? 1 : 0;\
                  FLAG_SZCN(r);\
                  cpu->a = r;\
                }


Je vais le poster également sur defence-force.org

[didierv]

Bravo pour cette analyse de haut vol !
Oricutron va encore progresser ...

[Hialmar]

Ah cool.

J'ai des trucs à modifier dans Oricutron donc si iss ne me bat pas encore une fois je les ajouterai dès que j'ai fini mes modifs.

[assinie]

Je me rend compte que je n'ai pas expliqué pourquoi le flag V devait être à 1 dans mon exemple  


$B4 est un nombre négatif, supérieur à $7F, donc le résultat de l'addition doit également être négatif mais comme le 6502 ne posséde que des registres de 8 bits.

$B4+$B4 = $168, ce qui implique que ACC = $68 et  C=1 (dépassement de capacité).

Le problème est que $68 est un nombre positif, inférieur à $7F, donc N=0, ce qui est incorrect c'est pourquoi le flag V doit être à 1 pour indiquer que N n'est pas cohérent avec le résultat réel.

Il y a un article sur le net qui explique le fonctionnement de ce flag ici

@Hialmar: Ok, merci.

[drpsy]

Alors là, Bravo !
Je vais de suite recompiler ça pour Mac.

J'adore les langages exotiques ou abandonnés et j'étais un peu frustré de ne pas pouvoir aller plus loin. J'avais fait quelques tests, et les comportements étaient curieux.

C'est bien de partager tout ça, ça nous fait progresser.

Au fait, vous connaissez le Brainfuck ? (sisi, ça existe, allez faire un petit tour sur Wikipedia).

[Hialmar]

Interpréteur Brainfuck pour 6502 :
https://groups.google.com/forum/m/#!topic/comp.emulators.apple2/Om3JKqDZoEA

Il n'y a plus qu'à l'adapter pour l'Oric.

[assinie]

Je connais le Brainfuck, il fait partie de toute une série de langages très éxotiques, mais je ne savais pas qu'il en existait une version pour 6502.
Je vais regarder ça de plus près.

Pour le FOCAL, la touche [£] du clavier Oric efface du début de la ligne jusqu'à l'emplacement du curseur.
Pour ceux qui préfèrent que la touche [DELETE] et la touche [£] effacent réellement les caractères au lieu d'afficher un '\' ou un '£', il suffit de taper la commande suivante:

Code:

TYPE FMEM(0,108,1)


La valeur affichée est celle avant modifcation de l'emplacement mémoire 108.

Pour mémoire, la commande FMEM est l'équivalent d'un peek si elle n'a que 2 paramètres et d'un poke si elle en a au moins 3 (il est possible de mettre plusieurs groupes de 3 paramètres à la suite).
Le premier paramètre est le numéro de page mémoire, le second l'offset dans la page, le troisième la valeur à placer.
1 page fait 256 octets.

Un petit exemple de programme, tiré du manuel FOCAL pour le KIM:

Code:

1.1 ASK "NOMBRE ",X; TYPE FSBR(99,X); QUIT

99.1 SET &1=&;SET &=2; SET &3=.000001
99.2 SET &2=&1/&; IF (FABS(&2-&)-&*&3) 99.3; SET &=(&+&2)/2; GOTO 99.2
99.3 RETURN


Ce court programme calcule... la racine carrée d'un nombre

[assinie]

@Hialmar: J'ai modifié la version brainfuck Apple pour la faire tourner sur Oric

J'ai encore quelques modifications à faire pour avoir une version Oric-1/Atmos.

Je pense aussi le modifier pour qu'on puisse mettre le programme dans une variable Alpha passée en paramètre comme ça on pourra l'utiliser depuis un programme BASIC.
Il restera à voir quelle zone mémoire utiliser pour la pile (peut-être un autre paramètre à passer à l'interpréteur)

[Hialmar]

He he

[drpsy]

Eh bien, vous avez du temps !
Moi, j'étais en train de faire une version en BASIC, interactive, avec ruban visible, zone d'entrées et zone de sorties.
Mais je suis loin d'être au résultat : manque de temps....

[assinie]

Ta version BASIC interactive serait plus beaucoup plus éducative que la mienne!
J'avais pensé faire une version de CARDIAC (ou ici) en BASIC dans le même esprit que toi en m'inspirant de la version parue dans un science et vie hors série, mais je n'ai pas encore commencé...
J'ai hate de voir ta version!

En attendant, ci joint, le fichier .tap de la version en LM, compatible Oric-1 et Atmos.
Il s'agit d'un programme de chargement BASIC pour la partie LM et d'un exemple d'utilisation.
Il est possible de sauvegarder la partie LM seule sur cassette ou disquette (début: $9600, fin: $96F6)

Pour exécuter un programme brainfuck, il suffit de le mettre dans une variable Alpha, d'ajouter un CHR$(0) à la fin de la variable et de faire un CALL $9602,nom_de_la_variable

Le programme utilise les adresses $9800 à $98FF pour la pile des données, ou pourait utiliser les adresses à partir de $9700 en faisant un POKE #9627, 151.
On pourrait aussi modifier le programme pour lui passer une autre variable ALPHA pour la pile, à voir...

Les adresse $00 à $05 sont également utilisées, je n'ai pas vérifié les éventuelles incompatibilités avec les différents OS.

Fichiers joints

BRAINFUCK.zip Version du 27/10/2014Vous n'avez pas la permission de télécharger les fichiers joints.(2 Ko) Téléchargé 2 fois

[didierv]

Chez les fous ... je suis
J'ai chargé mais testerais plus tard, il faut que je fasse le mag. je serais presque a l'heure ce mois-ci.

[Contenu sponsorisé]