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 : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Non, ugBasic fonctionne quasiment sur du bare-metal. L’affichage est 100% géré par lui sans appel aux roms du tout. Cela est nécessaire pour la vitesse et aussi avoir le même rendu sur toutes les machines (le code ASCII ainsi que les codes spéciaux varient de machine â machine).
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
jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par jasz »

Merci sam, j'avais perdu de vue qu'il est multi machine.
Avatar de l’utilisateur
hlide
Messages : 3456
Inscription : 29 nov. 2017 10:23

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par hlide »

spotlessmind1975 a écrit : 22 juil. 2022 09:00 C'est le graphique trouvé sur le site, avec la vitesse officielle de ZX0. Je ne sais pas si cela fait référence à la version 8 bits (je ne pense pas),
Ben si, vu que l'on compare à du LDIR :). C'est que l'on compare à la performance d'un LDIR d'un Z80.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Donc sensiblement 1/3 d’une recopie mémoire directe, et une réduction de taille mieux que moitié.

Il y a des algos plus rapides, mais compressant moins bien. Msc1 travaillant sur un flux d’octets et non de bits fait probablement parti de ceux là. Il faut choisir le compromis vitesse/efficacité.
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 »

hlide a écrit : 22 juil. 2022 19:39 C'est que l'on compare à la performance d'un LDIR d'un Z80.
Ah d'accord, j'ai compris. D'accord, alors mon estimation est peut-être fausse. Ne rien faire, dès que j'aurai le temps, j'essaierai de comprendre où il se positionne plus précisément. Merci quand même!
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

__sam__ a écrit : 22 juil. 2022 20:31 Donc sensiblement 1/3 d’une recopie mémoire directe, et une réduction de taille mieux que moitié.
Probable. Comme je l'ai écrit, il s'agit d'une estimation purement théorique. À mon avis, une mesure précise devrait être faite, au moins en la comparant avec LDIR.
__sam__ a écrit : 22 juil. 2022 20:31 Il y a des algos plus rapides, mais compressant moins bien. Msc1 travaillant sur un flux d’octets et non de bits fait probablement parti de ceux là. Il faut choisir le compromis vitesse/efficacité.
Cependant il faut toujours tenir compte de la raison pour laquelle je l'ai conçu : pour compresser des écrans PETSCII de 40x25 caractères (1000 octets). Ces paramètres de liaison étaient la chose la plus fréquente lorsque je codais des images avec des similitudes entre les images et les "tuiles" (PETSCII ou caractères redéfinis), j'obtenais donc d'excellentes performances à la fois en compression et en vitesse. En particulier, ce dernier était très rapide car je pouvais compter sur le DMA de l'extension de mémoire REU pour Commodore 64, qui fonctionne au niveau de l'octet.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

pascalien a écrit : 18 juil. 2022 16:38
Neotenien a écrit : 18 juil. 2022 04:04 Essayez de faire un programme en itératif pour trouver la sortie d'un labyrinthe hors récussif, c'est IMPOSSIBLE!!
Dans le cas ou l'entrée et la sortie sont sur des bords, il n'y a besoin d'aucune recursion ou mémoire.
Il suffit de longer le mur à droite ou à gauche.
Eh ben si, il faut sauvegarder les états intermédiaires tout comme dans un arbre n-aire (ici n=4), opuisqu'il faut savoir si on est déjà passé par tel ou tel endroit

J'en reviens à l'itératif, en fait il semblerait que l'itératif est une programmation en mode séquentiel, donc tout algorithme est forcément itératif... Donc le récursif fait partie de la programmation itérative en fin de compte (machine à états)
Ythunder
Messages : 928
Inscription : 21 août 2019 10:12

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Ythunder »

Perso, vous êtes des fois un peu trop technique ou peut-être, trop dans l'aspect théorie genre philosophie de la programmation.
Avis personnel..
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Pour en revenir à la programmation MSC1, et le fait de ne pas le trouver sur les moteurs...(Pascalien), peut-être que le nom français est différent ?

En fait on devrait apeler ça un algorithme de compactage (sans perte de données) à la différence d'un algorithme de compression (comme celui utilisé dans le JPEG).

A la lecture du lien qu'à fourni Marco, ici, je ne comprend pas l'exemple donné pour le DUP :
When a DUPES BLOCK is encountered, the decoder must copy 4 bytes from the actual address of destination memory minus offset for count times. So, it starts by the offset: this is a 10 bit value (position 0…1024). The offset represents the position of the match to be copied from. 0 means “start position”. The maximum offset value is 1024.

Example: following bytes define a the repetition of string “ELLO” for 4 times:


Avec le code

Code : Tout sélectionner

5, H, E, L, L, O, 0x84, 0x00
0x84 = b(1)(000.01)00, d'après moi ça ne fait qu'une seule répétition (count) non ? Et pas 4 comme annoncé dans l'article ? Où est mon erreur ?

Et à quoi correspond l'offset ? Ici ça serait "Adresse moins 0" d'après ce qui ets écrit, donc à piori on enlève de l'adresse de destination cet offset, mais ici, l'offset est=0 alors je ne comprend pas trop comment on peut se positionner sur le E de Hello...

Pour ce qui est de la performance, je trouve que cet algorithme me parait bon (en terme de compression) parce que le nombre d'éléments à recopier n'est pas figés. Parce que le risque sinon est quand on rencontre des images de "qualité photos" (comme celles que produit Utopic" dans Graphx) et du coup, dans un algorithme de compactage aux champs fixe, on rirquerait même d'avoir un fichier compacté + gros que l'original.
Je pense que cel algorithme est peut-être meilleur en compression que les MAP des Thomson (je n'ai pas cherché)... Mais par contre, vu que le premier octet du CRT sert en partie au nombre de répétitions du motif (bits 6 à 2) et en partie à l'Offset, ça suppose des manipulation en terme de langage binaire qu'on n'aurait pas avec l'utiisation d'octets pleins. Au moins un décalage à gauche (pour vérifier si littéral ou dup) et un ensemble de 2 octets pour l'offset pour lequell n applique un "AND 3" sur l'octet de poids fort.
Je suis en train de voir l'algorithmme LZW utilisé pour le ZIP et le GIF (juste à titre personnel)
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Oui ici c'est comme si on n'eavait que le seul choix de tourner à droite à chaque noeud et qu'on fasse demi tour à chaque cul de sac... C'est un sous ensemble de solution et ça reste un arbre dans lequel on ne choisit toujours que le chemin de droite.

Mais comme écrit dans l'article ça fonctionne dans un labyrinthe parfait (exemple que j'ai donné initialement) pmais pas forcément dans un labyrinthe à ilots. De plus, ça ne donnera pas le parcours le plus court au final (puiqu'il n'y a pas de sauvegarde des états intermédiaires)... Ca me fait penser à des algorithes de recherche de chemins entre 2 noeuds dans un graphe... On peut trouver le chemin entre 2 points pasr un algo optimisé ou alors utiliser l'algorithme à fermeture transitive foirnissant une matrice complète (toutes les liaisons possibles entre noeuds) mais prenant + de temps de calcul.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Neotenien a écrit : 23 juil. 2022 18:49
pascalien a écrit : 18 juil. 2022 16:38

Dans le cas ou l'entrée et la sortie sont sur des bords, il n'y a besoin d'aucune recursion ou mémoire.
Il suffit de longer le mur à droite ou à gauche.
Eh ben si, il faut sauvegarder les états intermédiaires tout comme dans un arbre n-aire (ici n=4), opuisqu'il faut savoir si on est déjà passé par tel ou tel endroit
Non pas du tout. Pascalien a raison.

Quant á trouver le chemin le plus court, c’est un autre problème qui se résout aussi sans récursion (algo de Dijkstra, 1956, algorithme de Floyd 1962).
d'après moi ça ne fait qu'une seule répétition (count) non ? Et pas 4 comme annoncé dans l'article ? Où est mon erreur ?
Il est indiqué qu’on copie "count" fois 4 octets depuis l’adresse courante-offset:
When a DUPES BLOCK is encountered, the decoder must copy 4 bytes from the actual address of destination memory minus offset for count times
donc ça marche par groupe de 4. Par contre j’ai un doute l’octet final soit vraiment 0x00 en effet par rapport au code 6809.
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 »

Neotenien a écrit : 23 juil. 2022 20:09 Pour en revenir à la programmation MSC1, et le fait de ne pas le trouver sur les moteurs...(Pascalien), peut-être que le nom français est différent ?
La vraie raison pour laquelle vous ne trouvez rien, c'est parce que... je l'ai inventé il y a un peu plus d'un an et demi, pour résoudre un problème pratique inhérent à ce projet.

Le problème pratique est le suivant : chaque trame occupe 1000 octets d'informations bitmap et 1000 octets d'informations de couleur, disons donc 2000 octets pour chaque trame. Avec la vitesse DMA du REU d'un Commodore 64, j'ai pu avoir une vitesse décente (en termes de fps) mais une seconde m'a enlevé environ 24 Ko. Un 512K REU a ensuite stocké environ 20 secondes.

Après avoir étudié la distribution statistique des données, j'ai implémenté cet algorithme qui non seulement réduisait les trames mais, clairement, augmentait également la bande passante précisément parce que la décompression avait lieu au niveau de l'octet (et était donc gérable avec le REU), donc voilà était plus d'images par seconde. Bref, en appliquant le MSC1, une seconde occupait environ 5 Ko et donc dans un REU j'ai pu mettre un film de 90 secondes.

Ici vous voyez le résultat (il est reproduit sur un Commodore 64):

Neotenien a écrit : 23 juil. 2022 20:09 En fait on devrait apeler ça un algorithme de compactage (sans perte de données) à la différence d'un algorithme de compression (comme celui utilisé dans le JPEG).
Je crains que, dans ce cas, nous nous approchions des limites du langage utilisé. En italien, on dit compression à la fois si elle est sans perte ("lossless", en anglais) et si elle est avec pertes ("lossy"). J'ai donc utilisé le terme compression/décompression, mais en français il y a peut-être une nuance qui échappe à mon langage. Pour en revenir à MSC1, c'est définitivement une compression sans perte.
Neotenien a écrit : 23 juil. 2022 20:09A la lecture du lien qu'à fourni Marco, ici, je ne comprend pas l'exemple donné pour le DUP :
Je pense qu'il s'agit d'un concours de culpabilité entre moi, qui ai traité la version anglaise avec moins d'attention et le traducteur automatique de l'anglais vers le français, qui je suppose a un peu brouillé les cartes. Il y a en fait une erreur dans l'exemple, et je l'ai corrigée. La vraie erreur était dans la traduction anglaise, qui utilisait le mot "destination" pour indiquer la mémoire source, et n'expliquait pas non plus d'où elle calculait le décalage. Je viens de mettre à jour les versions anglaise et italienne du document pour améliorer la compréhensibilité.

The correct example was:

Code : Tout sélectionner

     5, H, E, L, L, O, 0x90, 0x06, ...
           |<------ 0x06 bytes-----|
0x90 = b(1)(001.00)00, donc ils font exactement 4 répétitions.
Neotenien a écrit : 23 juil. 2022 20:09 Pour ce qui est de la performance, je trouve que cet algorithme me parait bon (en terme de compression) parce que le nombre d'éléments à recopier n'est pas figés. Parce que le risque sinon est quand on rencontre des images de "qualité photos" (comme celles que produit Utopic" dans Graphx) et du coup, dans un algorithme de compactage aux champs fixe, on rirquerait même d'avoir un fichier compacté + gros que l'original.
Pour l'instant ce risque n'est pas couru, pour deux raisons. La première est que, statistiquement, même l'image photographique a un minimum d'entropie dans sa représentation, et le système est calibré pour l'exploiter : en pratique, nous aurons des économies allant jusqu'à 5 %. La seconde est que la version que j'ai implémentée dans ugBASIC fait une comparaison entre les tailles compressées et non compressées. Si la version non compressée est inférieure, laissez la version non compressée.
Neotenien a écrit : 23 juil. 2022 20:09 suppose des manipulation en terme de langage binaire qu'on n'aurait pas avec l'utiisation d'octets pleins.
Je comprends le point. En réalité, le mappage d'octets étant fixe et non variable, le coût de reconstruction des composants dans l'octet bitmap est constant et ordonné selon l'utilisation. Dans toutes les implémentations (Z80, 6502 et 6809), il y a toujours deux décalages vers la droite plus un ET. Si vous voulez (mais là je demande à Samuel si ça vaut le coup) il serait même possible d'implémenter une table de hachage qui "mappe" pour chaque combinaison des 127 bits la valeur relative des répétitions et le MSB du décalage. C'est si vous voulez remplacer deux équipes et un ET par une "table de recherche".
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Ok so i discovered little by little, I would want to do an animation with the MOB system and I try to create an algorithm, but there is many difficult...

Let's see my little program (just a reduce version here...)

Code : Tout sélectionner

REM @english
REM MULTI TASKING FOR DUMMIES (7)
REM
REM This example will show how to use multitasking to
REM make a multiple rebounds of a ball onto
REM differents planets.
REM

REM PORTABLE WAY
BITMAP ENABLE (160,200,16)
DOUBLE BUFFER ON
REM SCREEN #3
CLS BLACK

ballon_img = LOAD IMAGE("images/red_disk_32px.gif" )
X = 10
Y = 2000
Y_MAX = 15000
G = 981
ballon = 0
MOB SHOW ballon, ballon_img AT X, Y/100 VISIBLE

PARALLEL PROCEDURE moveball
    SHARED ballon, x, y
    blankaSleeper = 50
    DO
        DEC blankaSleeper
        IF blankaSleeper=0 THEN
            y = calc_y_pos [g,y]
            MOB ballon AT POSITION X, Y/100
            MOB RENDER
            blankaSleeper = 50
        ENDIF
END PROC

PROCEDURE calc_y_pos [g,y]
    SHARED Y_MAX,ADDY
    Y = Y + ADDY
    IF Y >= Y_MAX THEN
        y = Y_MAX + Y_MAX - Y
        ADDY = -ADDY
    ENDIF
    ELSE IF Y<= 2000  THEN
        y = 4000 - y
        ADDY = -ADDY
    ENDIF
    ADDY = ADDY + g
    RETURN Y
END PROC

DO: RUN PARALLEL: LOOP
I created the calc_y_pos procedure (and you guess for what it is done ...)

Well so many question here
1/ It seems that we MUST use only multiple of 8 pxl image for the "LOAD" function (the 1st one was in 20x20 pxl and IDE Ugbasic complained of that... So if we want to use, saying, a 18x14 sprite size, is it impossible ?
2/ Here
"ballon_img = LOAD IMAGE("images/red_disk_32px.gif" )
X = 10"
It complained that there is an unexpected end of file... I wonder if ugbasic can managed gif img,
3/ In that exemple

Code : Tout sélectionner

PARALLEL PROCEDURE moveBat
    SHARED bat, x, y, f
    DO
        PUT IMAGE bat FRAME [f] AT [x],[y]
        [f] = [f] + 1
        IF [f] == FRAMES(bat) THEN
            [f] = 0
        ENDIF
    LOOP
END PROC
Why var are between these bracket "[" and "]" ? Is there for Array var ?
4/ I want to have a background image with my balloon rebound, Does it take acare of transparency color (index 0) of my balloon image with the MOB technical ?

Anoter remark : here as ugBasic doesn't use real var, I use a x100 factory about g and y position in my algorith that I divide by 100 after... It's like the "fixed"point technical notriced by Samuel. So I divide the position of Y by 100 on the screen, I suppose it's an integer division ?

Do I have some other some wrong code here ?
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Hi Neotenien , first of all thank you for switching to English.

Then I want to clarify that in the documentation I always try to specify whether an instruction or a set of instructions are available or not for a certain target (chapter AVAILABLE ON). This point is very important. As you know, ugBASIC does not provide abstractions. This means that you don't have to assume that a command is available everywhere because "ugBASIC does it to work". You have to think that that command may or may not exist depending on whether (for example) the underlying graphics system lends itself or not.

For example, the MOB subsystem was developed and runs on the Commodore 64, which is my primary platform. However, I had some difficulty porting it to other platforms due to the different way of representing pixels. The Thomson chipset, for example, is one of them. After all, experiences of other developers on Thomson platforms, who used the GET IMAGE / PUT IMAGE combination, made me understand that it was more efficient to let the developer manage the sprites than to do it myself. Please refer to the official group for concrete examples.
Neotenien a écrit : 28 juil. 2022 11:28I created the calc_y_pos procedure (and you guess for what it is done ...)
The ugBASIC language does not support forward referencing.
You should define the function before using it.
Neotenien a écrit : 28 juil. 2022 11:281/ It seems that we MUST use only multiple of 8 pxl image for the "LOAD" function (the 1st one was in 20x20 pxl and IDE Ugbasic complained of that... So if we want to use, saying, a 18x14 sprite size, is it impossible ?
The requirement to have images of a certain size (module) does not depend on ugBASIC but on the hardware. Since ugBASIC does not introduce abstractions, this implies that it does not crop or scale or perform any other operations on the image. The image must be compatible with the hardware.
Neotenien a écrit : 28 juil. 2022 11:282/ Here
"ballon_img = LOAD IMAGE("images/red_disk_32px.gif" )
X = 10"
It complained that there is an unexpected end of file... I wonder if ugbasic can managed gif img,
There is a syntax error, it does not depend on the image. In ugBASIC the variables must be denoted by a lowercase word or by a word in camelCase. So the code is wrong, and ugBASIC is complaining about that.
Neotenien a écrit : 28 juil. 2022 11:28 3/ In that exemple
Why var are between these bracket "[" and "]" ? Is there for Array var ?
This is an ugBASIC-specific syntax, and is used to access a specific item assigned to a thread. Since ugBASIC is a stackless language, the local variables you define in a procedure are shared among all threads. To avoid this, a memory area (for example, an array) is exploited and accessed by exploiting the thread number. For example, assuming you have 16 threads that each need to increment a variable x then you could write:

Code : Tout sélectionner

INC x(THREAD)
To abbreviate you can write:

Code : Tout sélectionner

INC [x]
Neotenien a écrit : 28 juil. 2022 11:284/ I want to have a background image with my balloon rebound, Does it take acare of transparency color (index 0) of my balloon image with the MOB technical ?
See above.
Neotenien a écrit : 28 juil. 2022 11:28Anoter remark : here as ugBasic doesn't use real var, I use a x100 factory about g and y position in my algorith that I divide by 100 after... It's like the "fixed"point technical notriced by Samuel. So I divide the position of Y by 100 on the screen, I suppose it's an integer division ?
In my humble opinion, it makes no sense to use a fixed point representation in a discrete system, which works with units. How do you represent 0.54 in pixels? There are better algorithms if you want to approximate a fractional increment. For example, instead of simulating 1/3 pixel shift by adding 0.33, you can take into account the number of times you could increment and increment only after 3 steps. Clearly it is generalizable.

Code : Tout sélectionner

' This code will move a blob at a speed of 0,33 pixel/s without divisions
d = 0
DO
   ADD d, 1, 0 TO 2 : ' 0...1...2...0...1...2...
   IF d = 0 THEN
      INC x
      PUT IMAGE blob AT x,y
   ENDIF
   WAIT 1000 MS
LOOP
[code]
Répondre