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

spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Neotenien a écrit : 16 juil. 2022 01:07 Wow it's perfect really, so great!
I'm glad you liked it! I shared this video in the official ugBASIC group, and it got a lot of positive comments.
Neotenien a écrit : 16 juil. 2022 01:07 The C64 version is more not as cool as the MO6 one.
It doesn't surprise me. There are a number of reasons, the first of which is that it is hardware that has more limited graphics features. The reason I put those versions, actually, is to show how isomorphism works. I would have liked to show other targets too but, as you may have guessed, the source that is on the repository is still a "work in progress". I hope to be able, in the next days, to release a new version but I have to thoroughly test all compilers before.
Neotenien a écrit : 16 juil. 2022 01:07I created a asembly routine to display Sprite on BM16 mode (with Samuel helps) a few years ago, it worked very well, I can't push it to animat 11 sprites (8x16 pixels) in 80 movement in less than 6" (more 12 img/secondes) and here I thouygt to seriously do a personnal assembly program for TO8 in order to adapt the Atari ST version on TO8... But seing that result on video, that's really great!
Thanks, I am really flattered that the code produced by ugBASIC is being compared with an assembly code! :)
Neotenien a écrit : 16 juil. 2022 01:07In fact, on TO8, as it has 256 kO of memory, I based the size of caracter on 72x48 pxl max size. On MO6, because it has 128 kO only, this size of 48x 36 may be the max.
The ugBASIC language has three primitives for image management: IMAGE, IMAGES and SEQUENCE. The difference is that while IMAGE is a single image, IMAGES is an animation of a single pose (imagine it is a sort of "filmstrip") and, finally, SEQUENCE is a set of poses (imagine a parallel set of filmstrips). Clearly, you can use PUT IMAGE to specify which frame, among many, you want to draw:

Code : Tout sélectionner

   PUT IMAGE [image] AT [x],[y]
   PUT IMAGE [image] FRAME [frame] AT [x],[y]
   PUT IMAGE [image] SEQUENCE [sequence] FRAME [frame] AT [x],[y]
I made this small premise because the current banking mechanism on Olivetti Prodest 128 (with or without MSC1 compression) works by taking all the primitive together. That is, it considers all frames and poses together when it comes to moving memory from bank to main memory. It is not very efficient. If you were able to take the single frame, perhaps decompressing it "on the fly", it would be the best and will comply with your description.

There is also an issue about this kind of optimization.
About Palette, Samuel told me about the "Color" ugbasic instruction, but the "EXACT" option seems easier to use.
Yes, it is probably simpler but Samuel, who is much more experienced than me on the issue of the Olivetti Prodest PC128 chipset palette, will certainly have given you the best advice on the matter.
Neotenien a écrit : 16 juil. 2022 01:07- For the video, did you use the bm4 or bm16 video mode ? I have the impression that there is only 4 colors.. Maybe it's just an impression
The mode is BM16.
Neotenien a écrit : 16 juil. 2022 01:07And it seems that Ken has really a transparency color, so newt stage will be to hadd a background
This is because ugBASIC interpreted that color as a "background", and then set the background accordingly. However, it is not drawing "in transparency". For this type of activity, you must use the WITH TRASPARENCY keyword on the PUT IMAGE command.
It began to animate as on the video but coz of blanka one, it seems it get out screen memory, freeze the screen and some weird things appaer on the screen from bottom tu top (some little rectangle, maybe pixels ?).
Probably you are not using the compiler obtained by compiling the latest repository. Without the fixes contained in the repository, operation is not guaranteed due to a bug on reading the K7. I attach you the executable I used to create the video.

Have a nice day!
Pièces jointes
sf.zip
SF under ugBASIC (commit 9ac3a1e7)
(6.06 Kio) Téléchargé 51 fois
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

bonjour Daniel, et merci pour votre contribution intéressante à la discussion.
J'ai lu attentivement tous les échanges et, et j'aimerais écrire quelque chose sur ce que vous avez écrit.
Je m'excuse d'avance pour mon français, mais c'est celui de Google.
Daniel a écrit : 12 juil. 2022 09:30 Finalement, avec le recul, je suis très sceptique sur ces projets de compilateurs, que ce soit Basic, C, Pascal ou n'importe quoi. Et surtout si on annonce qu'ils sont multi-machines et multi-processeurs. Je n'y crois pas. Ca ne marchera jamais bien, il y aura des foules de bugs, d'incompatibilités, d'impossibilités. Les débutants auxquels ces compilateurs sont destinés n'en tireront rien de bon. Les programmeurs expérimentés les bouderont à cause de leurs limites et du manque d'optimisation.
Je pense que tu fais bien d'être sceptique. Les sceptiques sont ceux qui ne s'appuient pas sur une croyance mais recherchent des preuves pour étayer ce qu'on leur dit. Moi-même, si j'avais mis ce langage dans la lignée de ceux qui existent, non seulement j'aurais été sceptique mais j'aurais dit qu'il n'avait aucun sens. C'est précisément parce que je viens de ces langages (par exemple, BASIC et C) et j'ai essayé de les utiliser et d'en tirer le meilleur parti sur des ordinateurs 8 bits.

Mon expérience avec ces langages de haut niveau et portables, appliqués à des ordinateurs disposant de peu de ressources, m'a amené à conclure qu'il y a un "mal" à la base : l'abstraction ("abstraction" in english).

Tous les langages sont basés sur des "hypothèses", des axiomes, dont dérivent la syntaxe, la sémantique, les fonctions et les bibliothèques ("libraries"). Souvent et volontairement certains d'entre eux nuisent au programmeur, car le résultat est en deçà des performances attendues. Et il n'y a pas d'autre moyen de dépasser ces limites qu'en éliminant les axiomes, mais cela implique effectivement d'abandonner le langage et de revenir à l'assemblage.

Avec ugBASIC, je suis parti d'un concept différent, que j'ai appelé isomorphisme. En bref, je supposais que les ordinateurs construits très près les uns des autres avaient beaucoup de choses en commun et quelques différences. Je traitais les choses en commun pour ce qu'elles étaient, sans introduire d'abstractions, tandis que je laissais filtrer les différences à travers les primitifs du langage.

Un exemple typique est la pile CPU (CPU stack).

Sur les ordinateurs 8 bits, c'est une quantité ridicule, quelques centaines ou milliers d'octets, it depends. En pratique, il est impossible de l'utiliser pour mémoriser quoi que ce soit. Ainsi la plupart des langages l'ont implémenté via un logiciel (via "software") : pour les appels, pour le passage de paramètres, pour les variables locales. Des centaines d'instructions élémentaires pour faire des choses simples. Lent!!!

Le langage ugBASIC est "sans pile" ("stackless"), et donc la seule utilisation qu'il fait de la pile est ce que ferait un programme en assembly: préserver les valeurs de registre et les adresses de retour des fonctions. Pour cette raison, par exemple, ses procédures peuvent être appelées dans des interruptions ("interrupts") ou implémenter le multitasking.

Ce n'est évidemment qu'un exemple.
Daniel a écrit : 12 juil. 2022 09:30Nos avis sont inconciliables. Ou plutôt nous avons des objectifs différents : Je cherche à développer des programmes performants sur des ordinateurs familiaux 8 bits avec peu de mémoire et processeur lent, alors que Neotenien veut un langage bien structuré et simple à utiliser pour gros systèmes.
Je pense que ugBASIC pourrait représenter le point de rencontre de ces deux visions inconciliables. Évidemment, c'est mon avis : je préfère que ce soient les faits qui nous amènent à cette conclusion, c'est pourquoi j'espère dans les prochains échanges et dans les prochains exemples vous donner des éléments dans ce sens.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

About the latest PC-Olivetti compiler, I just download it from the IDE of ugBasic, but it seems not be the very last one...From here, and it dates from 16 days. And I can't find another executable one. And I wonder if the problem comes from here...

Well, the demo of Street Figter II is not complete, it's maybe good to have spare it, but not a referential one...The goal is at last, to spare one thing with a background decor. I just wonder how many different movement I can have on PC olivetti. I wonder even if it's possible to have the orange haired color for Blanka as in the original pictures instead of yellow one. Maybe..

Am surprised about the bad result in apparence on C64, it is supposed to be the best 8 bits computer as perdormances (there are so many very good games on it as Mayhem (1993), many more better than Super Mario Bros (in my advice)) :
.
Well it's also possible to obtain this on MO6/TO8 maybe with le 6309 processor (To answer to you, Thomson MOTO can be replace their processor by the 6309, in some case, easyly), the TFM instruction of this 6309 processor allows to copy n byte from a RAM area to another until 4 time faster than normal 6309 instructions (LDD ,X++, STD ,Y++ for instance where here, Y is before X).

Here is also a video showing that on a TO8 (so also on PC Olivetti), it is possible to have until a 50 img/s horizontal scrolling (maybe using the tips of PUL/PSH instructions ?)
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Neotenien a écrit : 16 juil. 2022 14:16 About the latest PC-Olivetti compiler, I just download it from the IDE of ugBasic, but it seems not be the very last one...
Sorry, but you have to build it from the sources.
I don't releases not final versions as precompiled.
Neotenien a écrit : 16 juil. 2022 14:16The goal is at last, to spare one thing with a background decor. I just wonder how many different movement I can have on PC olivetti.
In one of the previous posts there is a sample video about that, I think.
Neotenien a écrit : 16 juil. 2022 14:16I wonder even if it's possible to have the orange haired color for Blanka as in the original pictures instead of yellow one. Maybe..
It's a palette allocation problem, in my opinion. Try to define an image with all 16 colors you would like to see appear and load it as EXACT. It is the alternative to Sam's suggestion on palette and colors.
Neotenien a écrit : 16 juil. 2022 14:16Am surprised about the bad result in apparence on C64, it is supposed to be the best 8 bits computer as perdormances (there are so many very good games on it as Mayhem (1993), many more better than Super Mario Bros (in my advice))
Take a look at the previous post to Daniel, and you will have an answer. Specifically speaking, the Commodore 64 has a fixed palette and, in high resolution mode, a limited number of colors for an area of 8x8 pixels. So if you want to have a better result you should prepare images with colors as similar as possible to the palette, and be careful that it has no shades. In ugBASIC there is an elegant way of differentiate resources between different hardware, and that is to place the resources under a subdirectory where the original resources is placed and that has the name of the target. In this case, "/c64".

Regarding your examples about performances, in my opinion it is a very interesting topic but it should be developed with a different angle. In fact, the example you bring to C=64 exploits a series of hardware techniques that cannot be implemented under Thomson MO6, and that it would be ridiculous to try to emulate. For example, replacing the processor with a more powerful and versatile one (6809> 6309) is a solution that ugBASIC could support, since scrolling has been implemented, and infact the goal of ugBASIC is to bring out the best in every machine ("isomorphism") not a one-size-fits-all ("abstraction").
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Daniel »

spotlessmind1975 a écrit : 16 juil. 2022 14:05 bonjour Daniel, et merci pour votre contribution intéressante à la discussion.
J'ai lu attentivement tous les échanges et, et j'aimerais écrire quelque chose sur ce que vous avez écrit.
Nos positions sont voisines sur le fond du problème. Le développement du compilateur ugBasic est un challenge passionnant, et s'il est mené à terme pour tous les ordinateurs 8 bits ce sera un excellent outil pour les programmeurs BASIC. Ils pourront ainsi développer des applications incomparablement plus rapides par rapport à un interpréteur.

Par contre les programmeurs en assembleur, spécialistes d'un ordinateur particulier comme par exemple le TO8, ne changeront pas de langage. Sur les PC modernes nous sommes passés sans difficulté de l'assembleur au C car les performances et la taille en mémoire ne sont pas critiques avec une configuration moderne, une fréquence de plusieurs GHz et une mémoire de plusieurs Go.

Avec un MO5, son 6809 à 1 MHz et une RAM utilisateur de 32 Ko, il faut optimiser les programmes en taille et en vitesse, et utiliser les fonctions du moniteur en ROM pour gagner de la place. Pour les animations et la musique il est nécessaire de compter les cycles du programme car il n'y a pas d'autre moyen d'assurer la synchronisation. Seul l'assembleur le permet.

Exemple : Les applications SDDRIVE_Music et SDDRIVE_Video sont irréalisable en ugBasic.
http://dcmoto.free.fr/programmes/sddriv ... index.html
http://dcmoto.free.fr/programmes/sddriv ... index.html

Le compilateur ugBasic reste toutefois une excellente initiative, et permettra certainement de susciter des vocations de programmeur.
Daniel
L'obstacle augmente mon ardeur.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Sorry but I don't know how to compile, and as I use Linux and use Wine... I'll wait for the next version if ugbasic so (until that I'll have time to end my personnal game).

That's ok for explanations.

I see that it's doable to draw circle and ellipse whereas there is no mathematical function (about trigonometry), and even no floating var... O wonder how its possible... I hav an idea to draw some polygons and move them around gravity center but there is no function for that (apart "line" and "plot" bit for the rest, not possibility to calculate position of each point using even pytagore theorem (sqrt) ok I can used the square value finally, that's not a problem but to calculate "epure" of each point oin the screen, whicg nee cos an sin values it's impossible... So how can I do that (drawing, for instance, a tetraedron) with ug Basic ? (Knowing that all mathematical features are present on Thomson Extra Monitor)
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

En réponse à Daniel, SI il est possible d'avoir des compilateurs de langages de haut niveaux et il y a eu le langage Pascal, particulièrement le Kyan Pascal (sur les Apple II, Atari XL et C64) qui étaient déjà un langage générique de haut niveau pour les ordinateurs 8 bits. Sur Thomson on n'a eu que Pascal Base, qui permet, bonnant malant, d'avoir un code machine stable pour pas mal de routines mais il fallait réécrire les procédures spécifiques aux Thomson (pour accéder aux routines du moniteurs notamment). Ca donne un exécutable très rapide mais avec du code ajouté pour éviter les bug (c'est ce que Samuel m'avait dit) ça ralentit certainement le résultat mais au moins on avait un code fiable.

Le Kyan Pascal a été un excellent Pascal pour les ordinateurs 8 bits Atari XL, Apple II et C64 donc, et j'ai l'impresion qu'il a été développé pour les machines à base de 6502 (à vérifier), mais c'est déjà un exemple de langage "isomorphique" comme Marco dit, alors que c'est simplement un langage "standard" dont les compilateurs s'adaptent aus spécificités des machines.

Il y a eu plein d'autres compilo Pacal pour les machines 8 bits, j'en ai déjà relevé 6 différents rien que pour le C64. Et il y a eu (tu le sais) Pascal Base (compilo) et UCSD PAscal (P-code, qui fait exactemebnt que que Java fait 17 ans plus tard) sur les Thomson

Ug Basic reprend complètement l'esprit de ces langages Pascal là (et en plus, la même philosophie et des éléments identiques comme les "END", et "Procedure") à la différence près que la compilation se fait par PC (windows, linux), et pas sur la machine elle-même. C'est donc un ensemble de cross compilers. Et ça permet surtoit de créer rapidement des sprites, des modèles de jeux vidéo rapides pour chaque machine.

Et chacun des compilateurs adapte le code Basic au meilleur de chaque machine comme le dit Marco. Sauf que c'est encore un langage jeune... et donc pas encore fini pôur l'ensemble des instructions (pour les Thmson, l'audio pêche un peu). De ce que je vois il est donc possible de créer rapidement des jeux compilé 100% en machine pour MO5 et PC Olivetti/MO6, même en utilisant les modes vidéo spécifiques (Pour le bm16, par exemple, c'est "BITMAP ENABLE (160,200,16)
" et il est même possible d'utiliser le double buffering comme c'est le cas pour "Mission liftoff!" Iol sait gérer les banques mémoires notamment. La vidéo que j'ai extraite montrant 4 sprite en 16x32 en mouvementtrès rapide en mode bm16 est bluffante..

Comme le dit Marco, c'est de l'isomorphique. En faut c'est juste un standard comme il existe avec GNUC FreePascal, Java etc... et donc il existe un compilateur pour au moins 10 machines différentes actuellement.

Son seul défaut est qu'il est encore jeune et que toutes les fonction basic (comme l'audio par exemple), ne sont pas toutes implantées partout. Et à titre personnel, des fonctions mathématiques trigonométrique ça me plairait bien parce que pour une démo que je compte faire c'est nécessaire. Mais apparemment UG Basic n'utilise pas de variable flottante.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Je n'entre pas dans les raisons du passage d'ASM à C, qui ont d'autres causes que les performances. Il est vrai que les ordinateurs modernes ont rendu les abstractions acceptables, mais il est également vrai que surmonter les abstractions avec un compilateur C est plus difficile que d'écrire un traducteur BASIC vers ASM à partir de rien. Et c'est pourquoi ugBASIC existe aujourd'hui.
Daniel a écrit : 16 juil. 2022 18:13 Par contre les programmeurs en assembleur, spécialistes d'un ordinateur particulier comme par exemple le TO8, ne changeront pas de langage.
C'est sûrement une vérité.

Cependant, je pense que c'est plus un fait lié au manque de TO8 comme cible d'ugBASIC qu'à un libre choix du programmeur. Encore une fois, nous devons nous fier aux preuves et non à la croyance. De nombreux programmeurs ne trouveront sûrement pas ugBASIC utile, d'autres le trouveront utile et pour les raisons que vous avez vous-même décrites. Je sais pertinemment que certains programmeurs assembleurs spécialisés sont passés à ugBASIC dès qu'ils ont constaté que les avantages l'emportaient sur les inconvénients.Et je dis cela en sachant très bien que ugBASIC a de nombreux inconvénients, et certains sont en cours d'élaboration.
Daniel a écrit : 16 juil. 2022 18:13Avec un MO5, son 6809 à 1 MHz et une RAM utilisateur de 32 Ko, il faut optimiser les programmes en taille et en vitesse, et utiliser les fonctions du moniteur en ROM pour gagner de la place. Pour les animations et la musique il est nécessaire de compter les cycles du programme car il n'y a pas d'autre moyen d'assurer la synchronisation. Seul l'assembleur le permet.
Toutes les contraintes que vous décrivez sont certainement importantes. Cependant, ugBASIC ne vous empêche pas de les surmonter. En effet, avec l'aide de développeurs compétents, un moyen a déjà été trouvé pour obtenir des sources d'assemblage hautement optimisées.

Ce qui m'empêche vraiment de dire que "ugBASIC surmontera toutes les limites" est lié au temps que les développeurs ugBASIC (moi y compris) peuvent y consacrer. Surtout pour trouver un moyen de les surmonter. Parce qu'il y a toujours un moyen, puisque ugBASIC génère des assemblages, après tout.
Daniel a écrit : 16 juil. 2022 18:13Exemple : Les applications SDDRIVE_Music et SDDRIVE_Video sont irréalisable en ugBasic.
Je ne comprends pas très bien ce qui vous empêche de faire ces programmes en ugBASIC, mais c'est probablement ma limitation personnelle, et je m'en excuse. Cependant, il y a quelque temps, je me suis consacré à l'élaboration d'une norme de diffusion en continu à basse résolution qui était portable. Malheureusement, comme je l'écrivais dans le post précédent, j'ai dû surmonter les axiomes et les limites du C et, au final, c'est cela qui m'a forcé à l'étape de la création de l'ugBASIC. Dans les prochains jours, j'aimerais pouvoir reprendre cet algorithme et le ramener à ugBASIC, pour pouvoir gérer la vidéo et l'audio comme des primitives de langage.

Une fois arrivé à ce résultat, qu'est-ce qui empêcherait la création du logiciel mentionné ?
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Daniel »

En assembleur on peut compter le nombre de cycles des instructions pour synchroniser une routine. Par exemple, pour jouer de la musique numérique, il faut compter les cycles entre deux échantillons pour respecter la fréquence d'échantillonnage. Avec ugBasic on ne peut pas.

D'autres exemples peuvent être donnés dans le domaine du graphisme, par exemple pour changer la palette pendant le retour du faisceau vidéo ou pour synchroniser l'affichage sur la VBL. La maîtrise du nombre de cycles est indispensable dans de nombreux programmes.
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 vrai Daniel. Cependant je ne pense pas que ce soit le but d’un basic de faire des demos techniques. L’assembleur manuel est bien pour ca. Par contre un jeu un tant soit peu elaboré peut aussi vite devenir pénible en asm. Un basic compilé entre à ce niveau là, a savoir dépasser les jeux parfois élaborés, mais lents et poussifs qu’on faisait à l’époque pour les rendre plus fluides et sympa à utiliser.

@Neotenien le p-code du Pascal n’était déjà pas une nouveauté à l’époque. Le principe même de la z-machine d’infocom utilisait déjà cela de façon courante dans les années 70.

Les flottants sont juste un truc monstrueux en lenteur et taille de code. Ils sont inutiles à supporter quand tu veux être efficace. Aucun jeu ou demo bluffant n’utilise des float ieee sur machines 8, 16 et même 16/32 bits (il n’y a pas de floats dans Frontier Elite).

Le truc qu’on fasait, et qu’on fait encore dans les microcontroller embarqués, sont l’usage de fixed-point (nombres à virgule fixe). On peut faire avec tout ce que tu veux faire avec des float (arithmétique, trigonométrie, log, exponentielle, racine carrées, etc), mais super rapidement. Et pour cela il suffit d’avoir des entiers, ce que ugBasic possède déjà.

Je t’encourages à te documenter dessus, tu va voir comment c’est puissant et à quel point les floats ne sont pas utiles sur les configs peu puissantes comme les notres: https://connect.ed-diamond.com/GNU-Linu ... rgule-fixe

Un truc sympa à faire sur thomson, c’est le calcul de l’ensemble de mandelbrot en basic thomson avec float, puis avec des fixed-points, et de comparer les vitesses. On comprends assez vite l’intérêt des fixed-points. Pour la petite histoire, à l’époque je m’étais imprimé un poster de 1m² de cet ensemble par assemblage d’impressions d’écran sur imprimante manesmann-tally. Avec les floats il aurait fallu des semaines voir plus.

Tiens, ça serait bien un programme en ugBasic qui calculerait rapidement l’ensemble colorisé (160x200x16 couls et 48 iterations max par point) en fixed point sur toutes les machines. Moi je n’ai pas accès à un ordi là tout de suite (juste le téléphone, pardonnez les typos), mais toi tu pourrais essayer de le faire, puis en regardant l’asm généré voir comment améliorer ugBasic. T’en dis quoi?

Oui bien sur que l’écriture d’un mandelbrot en fixed point nécessite de travailler son code pour le convertir de float à fixed point. Peut être que plus tard ugBasic les supportera de façon transparente. Qui sait? Mais tu peux déjà faire des trucs bien avec les différents types d’entiers (y compris 32bits) que ugBasic supporte.
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
Avatar de l’utilisateur
pascalien
Messages : 965
Inscription : 21 janv. 2019 23:40
Localisation : 93200 ST DENIS
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par pascalien »

La Z-machine d'infocom c'est 1979.
https://fr.wikipedia.org/wiki/Z-machine

Le p-code du pascal c'est entre 1971 et 1973.

Edit: D'après Wikipédia c'est entre 1972 et 1974.
Dernière modification par pascalien le 18 juil. 2022 22:59, modifié 1 fois.
__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 et l’ucsd Pascal est aussi de la fin des 70s. Matlab apparu aussi dans les années 70 utilise aussi un bytecode. Dans mon souvenir Smalltalk né aussi au début des années 70 utilisait aussi un bytecode. Plus tôt avant (1967) le bcpl utilisait lui aussi un bytecode.

Bref, le principe du bytecode était bien en place des les années 70. Ucsd-pascal n’a rien d’innovant de ce point de vue, et de fait de nos jour on le retrouve partout, et pas qu’en java: https://en.m.wikipedia.org/wiki/Bytecode
Dernière modification par __sam__ le 17 juil. 2022 11:58, modifié 1 fois.
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
Avatar de l’utilisateur
ZamZam
Messages : 195
Inscription : 09 nov. 2020 16:10
Localisation : TOUL (54200) Meurthe & Moselle

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par ZamZam »

Dans les premières consoles de jeux, il y avait aussi de l'utilisation de bytecode comme pour la COSMAC VIP (1977) qui est utilisé encore aujourd'hui pour apprendre à faire une machine virtuelle basique, c'est cette console qui a initié la "norme" CHIP-8

https://en.wikipedia.org/wiki/COSMAC_VIP

https://fr.wikipedia.org/wiki/CHIP-8

Cela serait sympa d'avoir une VM CHIP-8 sur les thomson :)
mais on s'éloigne du sujet ugBASIC
Jean-Luc
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Daniel a écrit : 16 juil. 2022 20:11 En assembleur on peut compter le nombre de cycles des instructions pour synchroniser une routine. Par exemple, pour jouer de la musique numérique, il faut compter les cycles entre deux échantillons pour respecter la fréquence d'échantillonnage. Avec ugBasic on ne peut pas.
Je comprends le scepticisme, mais pourquoi êtes-vous convaincu que cela ne peut pas être fait?

Code : Tout sélectionner

VAR sample AS BYTE = 0
POKE $A7CF, PEEK($A7CF) AND $FB
POKE $A7CD, $3F
POKE $A7CF, PEEK($A7CF) OR $04

DO
    POKE $A7CD, sample
    INC sample
    IF sample > 63 THEN
        sample = 0
    ENDIF
LOOP
C'est un code qui lit une série d'échantillons audio (calculés) avec une loop. Pour la première fois j'ai utilisé directement les primitives BASIC classiques (POKE et PEEK), évitant ainsi d'utiliser les primitives dédiées à l'audio, juste pour ne pas mettre trop de viande sur le feu. Il est donc clair que ce code ne fonctionne qu'avec le DAC de PC128 et, pour simplifier, j'ai omis le chargement depuis la mémoire. Encore une fois, ce sont toutes des choses que, si cela a du sens, je traiterais de manière "isomorphe".

C'est l'onde qui est reconstruite (l'échantillonnage sur DCMOTO est de 25 Khz), je ne vois aucune trace de déformation:

Image

Tandis que la durée de la remontée me semble fixée à 3 millisecondes (0,003 s). Comme les échantillons sont au nombre de 64, la fréquence maximale à laquelle nous travaillons est d'environ 20 Khz. Cela signifie que ugBASIC est assez rapide. Bien sûr, vous avez raison lorsque vous tapez compter les cycles entre deux échantillons pour respecter la fréquence d'échantillonnage, mais ce n'est qu'une question de quelques essais.

La vitesse est constant et suffisante.
Daniel a écrit : 16 juil. 2022 20:11 D'autres exemples peuvent être donnés dans le domaine du graphisme, par exemple pour changer la palette pendant le retour du faisceau vidéo ou pour synchroniser l'affichage sur la VBL. La maîtrise du nombre de cycles est indispensable dans de nombreux programmes.
Encore une fois, je ne vois aucun problème à créer des effets raster sur ugBASIC. Ce programme affiche une bande fixe d'une certaine couleur sur l'écran.:

Code : Tout sélectionner

BITMAP ENABLE (16)
CLS BLACK

DO

    WAIT VBL

    COLOR #0, #$000
    WAIT #100 CYCLES: WAIT #100 CYCLES: WAIT #100 CYCLES
    WAIT #100 CYCLES: WAIT #100 CYCLES: WAIT #100 CYCLES

    COLOR #0, #$0ff
    WAIT #100 CYCLES: WAIT #100 CYCLES: WAIT #100 CYCLES
    WAIT #100 CYCLES: WAIT #100 CYCLES: WAIT #100 CYCLES
    WAIT #100 CYCLES: WAIT #100 CYCLES: WAIT #100 CYCLES
    WAIT #100 CYCLES: WAIT #100 CYCLES: WAIT #100 CYCLES

    COLOR #0, #$000

LOOP
C'est le résultat sur Olivetti Prodest PC128:

Image

And sur Commodore 64:

Image
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Daniel a écrit : 16 juil. 2022 20:11 En assembleur on peut compter le nombre de cycles des instructions pour synchroniser une routine. Par exemple, pour jouer de la musique numérique, il faut compter les cycles entre deux échantillons pour respecter la fréquence d'échantillonnage. Avec ugBasic on ne peut pas.

D'autres exemples peuvent être donnés dans le domaine du graphisme, par exemple pour changer la palette pendant le retour du faisceau vidéo ou pour synchroniser l'affichage sur la VBL. La maîtrise du nombre de cycles est indispensable dans de nombreux programmes.
A l'instar du Pascal ou du C, (et même Basic), on peut écrire des pocédures ou fonction en assembleur (c'est même possible de le faire avec Pascal Base sur Thomson!!) appelable directement au sein du langage, ceci est un faux problème! Et d'ailleurs, la plupart des routines spécifique en Assembleur en C sont pour les considérations matériels souvent (sauf quand il s'agit de standar comme pour le langage Ghostscript pour les imprimantes). D'ailleurs le Basic des MO-TO permet aussi d'écrire des modules en assembleur sauf que là, c'est souvent directement via les codes binaires sans paser par l'assembleur. Le but des langages de haut niveau est quand même de gagner énormément de temps à éviter d'écrire en assembleur (le simple fait d'écrire un "writeln 'Bonjour;'" en Pascal prend 20 secondes alors que faire la même choise en assembleur prend 10'!), et se concentret sur les algorithmes et écrire le moins d'assembleur possible.

Et je persiste à dire que le langage Pascal reste le meilleur des langages de hauts niveaux à TOUT point de vie (comparé au C, ou à Java), notamment du fait que ce n'est pas un langage permissif (et donc évite des bugs tou en ayant des compilateurs très performants (en fait, les compimateurs Pascal sont reconnu comme les plus rapides au monde du fait de l'aspect structuré du langage qui ets très proche de l'assembleur finalement! Exemple, les boucles FOR sont basé sur les instruction assembleur INC et DEC, alors qu'en C c'est un gros bordel!! Et l'alternative à FOR est WHILE ou REPEAT). Le C est un langage pour bidouilleur, et c'est pas parce que Kernigan a décrit sans doute le seul défait que Pascal avait au début des années 80 qui doit occulter les tares du C comparé au Pascal notamment à sa difficulté technique d'eapprentissage et ses dérives sur de la programmation propre.

Dans une étude de 2019 , Le langage Pascal est classé parmi les 3 langages les plus performants, aux côté du Goi ou du C, (tout en étant produisant du code fiable relativement facilement) quand on regroupe 3 critères (plus de 20 langages récents étudiés). Et il manque quiand même dans cette étude certains autres langages cmme modula 3 ou Oberon, qui sont les descendant du Pascal, ainsi que Julia, qui est le meiller des langages de script en terme de performance (aussi performant que le C compilé).

Tout ça pour dire que je suis heureux que ugbasic semble avoir certaines particularités du Pascal (les mot clé "END" et "Procedure" par exemple

Par contre, je déplore qu'il y ait une démultiplication des commandes pour des mêmes fonctions ('alors qu'en Pascal ce n'est pas le cas). Il ne fait PAS prendre la voie du C!! Avoir un langage atçmique le plus possible. Par exemple, avoir choisi d'avoir 2 noms pour une même fonction ne fait qu'embrouiller!! Obéron a encore + simplifié le Pascal en supprimant des fonctions inutiles et ça serait bien que UG Basic fasse de même (ce qui ne semple pas être le cas, comme par exemple, la déclaration "GLOBAL" qui a un autre mot synoyme, je dis NON!! D'autant que le mot GLOBAL est déjà celui existant dans d'autres langages et que ça réduit les possibilité de noms de variables. Avoir une liste de mot clés le plus court possible et pertinent.
Répondre