ugBASIC est arrivé sur Olivetti Prodest PC128!

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Ok, I kind of figured something about the syntax error in line 710:

Code : Tout sélectionner

$ asm6809 -H -e 7168 /tmp/out.asm -o /tmp/out.hex -s /tmp/out.sym -l /tmp/out.lis -v
syntax error: /tmp/out.asm:710:

with CR
with CR
Sans titre.png (18.51 Kio) Consulté 3126 fois
The "od -tc /tmp/out.asm" shows that the file contains double '\r':

Code : Tout sélectionner

0034360   T   A       ,       Y   +  \r  \r  \n  \r  \r  \n
0034400       L   E   A   X       -   1   ,       X  \r  \r  \n
0034420           C   M   P   X       #   0  \r  \r  \n
0034440   B   N   E       C   L   S   G   L   1  \r  \r  \n
                                                 ^^^^^^
0034460       R   T   S  \r  \r  \n  \r  \r  \n   C   L   S   2  \r  \r
0034500  \n  \r  \r  \n                   L   D   A       _   P   A   P
0034520   E   R  \r  \r  \n                   A   N   D   A       #   $
0034540   0   3  \r  \r  \n                   L   D   B       $   5   5
Now, if I remove all the '\r\r' in the file to just have plain "\r\n":

Code : Tout sélectionner

$ sed -e 's/\r\r/\r/g' /tmp/out.asm >out.asm
$ od -tc | less
0033300   5  \r  \n  \r  \n                   L   D   Y       B   I   T
0033320   M   A   P   A   D   D   R   E   S   S  \r  \n
0033340   L   D   X       C   U   R   R   E   N   T   F   R   A   M   E
0033360   S   I   Z   E  \r  \n   C   L   S   G   L   1  \r  \n  \r  \n
                                                         ^^^^^^
0033400                   L   D   A       $   a   7   c   0  \r  \n
0033420               O   R   A       #   $   0   1  \r  \n
0033440       S   T   A       $   a   7   c   0  \r  \n  \r  \n
0033460           L   D   A       #   $   0  \r  \n                   S
then asm6809 accepts the ./out.asm file.

:arrow: It seem the assembler doesn't like the "double CR" around 710.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Thanks for the analysis! :D

I would confirm that the problem is that. I add to your evidences that the code involved should be from an included file, so the problem should be present right on the "as is" file.I just added a ticket, to clean up the sources before passing them to the compiler:
https://github.com/spotlessmind1975/ugbasic/issues/174

On this occasion I would like to point out that I have (finally!) finished the first implementation of multitasking support on ugBASIC. It is currently only preliminary and it is available on the repository, but it should come out completed with the next release:
https://retroprogramming.iwashere.eu/ug ... ltitasking

Now I will deal with the various optimization reports, for which I still thank you!
Garland
Messages : 40
Inscription : 25 oct. 2018 19:40

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Garland »

J'ai déjà dit à spotlessmind que ugBasic pourrait faire une grande différence dans le développement 8 bits en raison de sa portabilité sur différentes plates-formes. C'est un projet qui, à mon avis, mérite un soutien maximal de toute la scène des développeurs rétro.

Il existe un groupe facebook officiel :
https://www.facebook.com/groups/867151224158600

Je voulais souligner quelques choses que j'ai trouvées lors des tests:

1) En 320x200x16 les couleurs reflètent celles de l'image chargée (BMP avec profondeur 16bit), en Bit16 à la place elles sont altérées
2) PRINT 1 + (8 * -1) : ceci sur le BASIC propriétaire donne comme résultat -7, avec le compilateur 9. Dans le manuel j'ai lu le paragraphe sur signed numbers mais je ne sais pas si j'ai raté quelque chose moi-même
3) Il serait très utile d'implémenter MOB avec synchronisation VBL ou double buffer afin d'éviter le flickering lors du déplacement des graphiques
4) J'ai vu que POKE a été récemment ajouté mais le compilateur ne reconnaît pas le token
5) Pour le clavier, j'ai un code assembleur qui contourne le buffer et reconnaît plusieurs touches enfoncées, existe-t-il un analogue sur ugBASIC? Sur le BASIC propriétaire, vous pouvez implanter du code machine via POKE, pouvez-vous faire quelque chose de similaire ici aussi ?
6) Envisagez-vous d'implémenter un token pour détecter la couleur d'un pixel aux coordonnées x, y ? Ce serait utile pour les collisions entre autres.
7) Pour le retournement des images, s'il n'est pas possible d'implémenter une commande en phase de dessin (ce qui serait peut-être trop lent), pourriez-vous mettre une option en phase d'import afin de les charger déjà en miroir sur le xy axe?

J'espère voir une nouvelle version bientôt car je suis curieux de commencer à écrire des prototypes :) bravo pour ce beau projet !
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Salut Garland, tout d'abord merci pour le soutien et pour les compliments. Vous êtes vraiment gentil!

J'espère pouvoir répondre à toutes les questions. Cependant, gardez à l'esprit que ce langage va là où les développeurs veulent l'emmener. Donc, s'il y a des choses qui pourraient être utiles, elles sont mises en place sans problème.
1) En 320x200x16 les couleurs reflètent celles de l'image chargée (BMP avec profondeur 16bit), en Bit16 à la place elles sont altérées
La raison pour laquelle cela se produit est que, dans le mode BIT16, la même palette que le Commodore 64 est utilisée (qui sont 16 couleurs conventionnelles). Ce chemin a été choisi pour la cohérence chromatique avec d'autres plates-formes. Pour le moment c'est le seul mode disponible mais un ticket a été ouvert pour vous permettre de changer le mode de mappage avec une commande spécifique (vous pouvez bien sûr la commenter si vous avez d'autres idées) :
https://github.com/spotlessmind1975/ugbasic/issues/175
2) PRINT 1 + (8 * -1) : ceci sur le BASIC propriétaire donne comme résultat -7, avec le compilateur 9. Dans le manuel j'ai lu le paragraphe sur signed numbers mais je ne sais pas si j'ai raté quelque chose moi-même
Cela ressemblerait à un bug.

Ticket ouverte :
https://github.com/spotlessmind1975/ugbasic/issues/176
3) Il serait très utile d'implémenter MOB avec synchronisation VBL ou double buffer afin d'éviter le flickering lors du déplacement des graphiques
Ticket ouverte :
https://github.com/spotlessmind1975/ugbasic/issues/177
4) J'ai vu que POKE a été récemment ajouté mais le compilateur ne reconnaît pas le token
Quel genre d'erreur obtenez-vous ?
5) Pour le clavier, j'ai un code assembleur qui contourne le buffer et reconnaît plusieurs touches enfoncées, existe-t-il un analogue sur ugBASIC? Sur le BASIC propriétaire, vous pouvez implanter du code machine via POKE, pouvez-vous faire quelque chose de similaire ici aussi ?
Ce n'est pas là pour le moment mais il serait utile de pouvoir le mettre en œuvre de cette façon. Peut-être y a-t-il la possibilité d'identifier la pression des touches de contrôle telles que SHIFT ou CTRL ?

Quoi qu'il en soit : pouvez-vous utiliser votre code pour remplacer l'appel ugBASIC actuel, qui est un simple appel système ? Considérons que nous mentionnons l'auteur du code au générique :
https://github.com/spotlessmind1975/ugb ... D-PARTS.md
6) Envisagez-vous d'implémenter un token pour détecter la couleur d'un pixel aux coordonnées x, y ? Ce serait utile pour les collisions entre autres.
Celui-ci devrait en théorie déjà être présent, et s'appelle

Code : Tout sélectionner

POINT (x, y)
Cependant nous devons vérifier s'il fonctionne dans tous les modes (40 COLUMNS, 80 COLUMNS, BIT4, BIT16).
7) Pour le retournement des images, s'il n'est pas possible d'implémenter une commande en phase de dessin (ce qui serait peut-être trop lent), pourriez-vous mettre une option en phase d'import afin de les charger déjà en miroir sur le xy axe?
C'est une excellente idée de toute façon, pour laquelle un ticket a été ouvert (bien sûr, vous pouvez la commenter si vous avez d'autres idées)
https://github.com/spotlessmind1975/ugbasic/issues/178
Zebulon
Messages : 2788
Inscription : 02 nov. 2020 14:03

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Zebulon »

Il me semble cohérent dans un langage qui se veut multi-target sans utiliser de compilation conditionnelle d'avoir des restrictions finalement au sous-ensemble commun des fonctionnalités proposées par toutes les cibles. Implanter du code spécifique à telle ou telle plateforme revient à spécialiser le code pour cette plateforme et nécessite d'utiliser de la compilation conditionnelle si on veut rester compatible avec les autres cibles. Le serpent se mord la queue.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Je n'ai pas bien compris à quel aspect vous faites référence, Zebulon.

En général vous avez raison mais cela ne s'applique pas à ugBASIC, car ce langage adopte une approche différente, appelée "isomoformisme" (je ne sais pas si le terme est rendu ainsi en français). En pratique, on essaie de trouver des correspondances entre différents ordinateurs, en termes fonctionnels, sans exiger d'uniformité ou de "plus petit commun multiple".

Il y a quelque temps, j'ai écrit un très court essai dans lequel j'ai essayé d'expliquer ce qui a motivé l'écriture de la bibliothèque C "MIDRES" (qui est, en pratique, la version C de ugBASIC):
https://retroprogramming.iwashere.eu/mi ... somorphism

Par exemple, le format dans lequel les données graphiques sont stockées dans la mémoire de l'ordinateur cible est celui de l'ordinateur cible. Ce n'est pas un format identique pour toutes les cibles. Cela implique qu'il n'est pas obligé des restrictions sur le sous-ensemble commun de fonctionnalités, car il adapte la source à l'ordinateur, et non l'inverse.
Zebulon
Messages : 2788
Inscription : 02 nov. 2020 14:03

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Zebulon »

D'accord mais on code d'une unique manière dans le source ugBASIC et c'est ensuite le compilateur qui adapte le code/les formats pour chaque cible.

Maintenant si on veut gérer une fonction spécifique d'une machine (tel que le scan du clavier via du langage machine pour détecter plusieurs touches pressées simultanément alors que les autres machines ne peuvent pas le faire) on perd l'intérêt de coder une seule fois un programme qui s'exécute de façon identique sur toutes les cibles sans ajouter de directives de compilation.

Mais peut-être que c'est moi qui ait mal compris. :wink:
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Non, écoutez, le problème est définitivement le mien que je ne peux pas bien m'expliquer.
Après tout, le paradigme est différent.
Je donne un exemple d'approche isomorphe, en espérant pouvoir l'expliquer même si je ne parle pas français.

La possibilité d'appuyer sur plusieurs touches est une caractéristique isomorphe de les ordinateurs, car il n'y a aucune raison pour qu'il ne soit pas possible de détecter cet événement. Il s'ensuit que cela n'a aucun sens que la fonctionnalité soit supprimée de ugBASIC (car il manque sur certains ordinateurs) ou qu'une fonctionnalité spécifique soit développée sur un seul ordinateur.

Une façon (ce n'est pas le seul) consiste à faire ressortir les fonctionnalités via un mécanisme ugBASIC natif. Par exemple, il existe actuellement plusieurs fonctions pour appuyer sur les touches du clavier : INKEY$, SCANCODE, etc. Je pourrais introduire l'instruction MULTIKEY$ (c'est un exemple!) et cette instruction détecterait plusieurs pressions de touche. Que le ordinateur puisse le faire ou non n'a pas vraiment d'importance. L'important, à ce stade, sera de programmer un logiciel capable de gérer les deux situations.

Je m'excuse si je n'ai pas été particulièrement clair, mais ce n'est pas encore un paradigme très "mûr". Actuellement, ugBASIC regorge littéralement de ces mécanismes, qui sont intimement liés au fonctionnement de l'ordinateur, précisément parce qu'ils représentent la pierre angulaire du langage.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par hlide »

J'imagine que MULTIKEY$ pourrait ne rendre qu'une touche dans le cas où un ordinateur n'est pas en mesure de gérer plusieurs touches simultanément, permettant au programme de fonctionner malgré tout sur cette machine, non ? on permet d'avoir le maximum de possibilités en obtenant au mieux plutôt que de restreindre les possibilités en obtenant le pire.

Je ne suis pas très BASIC mais je trouve que ce qui se dit et se fait ici est très intéressant.
Zebulon
Messages : 2788
Inscription : 02 nov. 2020 14:03

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Zebulon »

Si si c'est plus clair et merci beaucoup pour les efforts d'explication en français. :D
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Bon je pense avoir compris le problème du double CR.

Ce qu'il se passe: Je suis sous cygwin, et git effectue une conversion de fin de ligne dans la convention "Windows". Résultat: les fichiers ASM sous src/hw/ ont tous la convention windows "\r\n" pour les fin de lignes. Jusque là tout est bon.

Ensuite dans le makefile les règles comme

Code : Tout sélectionner

SOURCES_6809 := $(subst src/hw/6809/,src-generated/6809_,$(MODULES_6809:.asm=.c))

src-generated/6809_%.c: $(MODULES_6809)
	@xxd -i $(subst src-generated/6809_,src/hw/6809/,$(@:.c=.asm)) >$@
convertissent, via "xxd", les fichiers ASM en tableau de caractères pour pouvoir être écrits "tels quels" dans les fichiers ASM:

Code : Tout sélectionner

unsigned char src_hw_ef936x_startup_asm[] = {
  0x45, 0x46, 0x39, 0x33, 0x36, 0x58, 0x53, 0x54, 0x41, 0x52, 0x54, 0x55,
  0x50, 0x0d, 0x0a, 0x0d, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x4c, 0x44, 0x58,
        ^^^^^^^^^^
(..snip..)
  0x0d, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x52, 0x54, 0x53
};
unsigned int src_hw_ef936x_startup_asm_len = 225;
Bien évidemment on retrouve une trace du "\r\n" dans ce "dump" binaire des fichiers textes (regardez au dessus de ^^^^^).

Plus loin dans le code quand on doit écrire ces modules

Code : Tout sélectionner

ugbc/src/hw/ef936x.c:    deploy( ef936xstartup, src_hw_ef936x_startup_asm );
on utilise ultimement la macro

Code : Tout sélectionner

#define outembedded0(e)     \
    { \
        fwrite( e, e##_len, 1, ((Environment *)_environment)->asmFile ); \
        fputs( "\n", ((Environment *)_environment)->asmFile ); \
    } 
qui fait grosso-modo un fwrite() du tableau "en bloc".

Mais voilà que "asmFile" est un fichier ouvert en mode texte, et contrairement à ce qu'on croit, fwrite() effectue une conversion de ligne sur ce type de fichiers. :shock: Résultat le "\n" final de "\r\n" est lui même sorti comme "\r\n", et ob obtient un joli (?) "\r\r\n" dans le fichier.

Je sais que c'est très surprenant. Je m'attendais que fwrite() fasse une écriture binaire, y compris sur les fichiers textes, jusqu'à ce que je fasse ceci sous cygwin;

Code : Tout sélectionner

$ cat tst.c
/* strictement le même fwrite() mais l'un sur un fichier "wb" et l'autre "wt" */
#include <stdio.h>

unsigned char tst[] = {13,10};

int main(void)
{
        FILE *f;

        f = fopen("tst.txt", "wt");
        fwrite(tst, 2, 1, f); 
        fclose(f);

        f = fopen("tst.bin", "wb");
        fwrite(tst, 2, 1, f);
        fclose(f);
        
        return 0;
}

$ gcc tst.c -o tst

$ ./tst

$ xxd tst.bin
00000000: 0d0a                                     ..  # <== \r\n as expected

$ xxd tst.txt
00000000: 0d0d 0a                                  ... # <== \r\r\n !!!!
On voit clairement que le fichier ouvert en "wt" (texte donc) fait 3 octets alors qu'on en a écrit 2 via fwrite(), et qu'en outre le "\r" y est dédoublé. :?

:arrow: Donc voilà l'explication de l'apparition de ces "\r\r". Je ne sais pas si c'est un bug(*) de fwrite() ou si c'est juste un comportement inattendu sur un système ayant une notion de fichier texte.

Oui mais comment on contourne alors ?

Idéalement il faudrait dire à la bibliothèque C de ne pas interpréter les fins de ligne dans fwrite(). Je n'ai pas trouvé. Cependant si on défini outembedded0(e) comme suit:

Code : Tout sélectionner

#define outembedded0(e)     \
    { \
	int i; for(i = 0; i<e##_len; ++i) {int c = e[i]; if(c!='\r') {fputc(c, ((Environment *)_environment)->asmFile);}} \
        fputs( "\n", ((Environment *)_environment)->asmFile ); \
    } 
(on saute au dessus des '\r', et ainsi '\n' peut être étendu par les routines fXXX() comme fputc() sans que cela ne pose de problème), alors j'obtiens un ugcb.mo5 qui marche :D
Je note au passage que la fonte Thomson est remplacée par une fonte ressemblant à celle de l'AMSTRAD ;)
Je note au passage que la fonte Thomson est remplacée par une fonte ressemblant à celle de l'AMSTRAD ;)
dcmoto02.png (5.72 Kio) Consulté 3029 fois
___
(*) D'après "man fwrite" on est pas supposé l'utiliser sur autre chose que des fichiers binaires, et en outre, un échange d'il y a 18 ans sur cygwin reporte un soucis similaire: https://cygwin.com/pipermail/cygwin/200 ... 93124.html, donc ce problème existe depuis quasiment toujours.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Je suis vraiment impressionné par l'analyse approfondie et je vous remercie de l'avoir partagée. Sans aucun doute, la cause du problème me semble avérée, ce qui, si je comprends bien, ne se produit qu'avec cygwin sous Windows.

Voulant résoudre le problème, nous avons trois façons :
1) il faut dire à la bibliothèque C de ne pas interpréter les fins de ligne dans fwrite();
2) nous définissons outembedded0(e) pour sauter par dessus le '\r', et ainsi '\n' peut être étendu par les routines;
3) supprimez la séquence anormale de caractères du fichier de sortie, en post-traitement (était la solution initiale).

Je pense que la solution la plus générale est la seconde. Vous me dites si j'ai bien compris. Aussi parce que, du moins dans ma version, le problème ne se produit pas.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Daniel »

Dans le passé j'ai déjà eu ce genre de problème en C avec les fichiers texte. J'ai décidé alors de ne plus les utiliser, et d'ouvrir tous les fichiers en mode binaire, même si ce sont des fichiers texte. Ça nécessite de savoir gérer par programme les \r et \n et de savoir traiter aussi bien les fichiers Windows que les fichiers Linux, mais les pièges vicieux des terminateurs de ligne sont définitivement réglés.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Oui c'est cela, mais une autre possibilité serait de mettre un .gitattribute dans le projet pour que les fichiers *.asm soient considérés avec des fin de lignes à la Linux (core.autocrlf=input si j'ai bien compris). Ainsi les fichiers ASM modifiés et stockés sur le serveur seront à la convention linux stricte, et les checkout sous cygwin, cet attribut indiquera à git de laisser les fins de lignes tels quels.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Merci à tous pour les suggestions, j'ai mis à jour le ticket en les listant de manière exhaustive:
https://github.com/spotlessmind1975/ugb ... -954461368

Ensuite, peut-être, nous décidons ensemble de la meilleure façon de résoudre le problème.
Personnellement, j'aime l'option 4) qui ressemble à 3) mais faite au moment de générer les fichiers.
Répondre