La Place des Développeurs [EN COURS] VDP Flash Pipeline Expérimentations Quelques applications sur l'approche Flash
igal
Membre non connecté
Conseiller Municipal
J'ai du mal a "accepter" que le Turbo-R execute le Basic plus rapidement que le MSX. (ou alors...Pq les msx n'exécutent pas le Basic aussi rapidement que le Turbo-R)
D'une part parce que si je me trompe pas c'est le Z80 qui l'execute et d'autre part, dans tous les cas, pour garder une cohérence entre les machines, il faut "logiquement" que l'execution des programme soit identique.
Sans quoi, les jeux Konami par exemple seraient injouables etc... Edité par igal Le 25/07/2018 à 13h13
D'une part parce que si je me trompe pas c'est le Z80 qui l'execute et d'autre part, dans tous les cas, pour garder une cohérence entre les machines, il faut "logiquement" que l'execution des programme soit identique.
Sans quoi, les jeux Konami par exemple seraient injouables etc... Edité par igal Le 25/07/2018 à 13h13
Visiteur
Vagabond
Message : 0
Je ne comprends pas, le turboR (R800 16bits à 7,16MHz) est plus rapide qu'un MSX2 (Z80 8bits à 3,58MHz), qu'y a-t-il de choquant ?
En ce qui concerne les jeux Konami (par exemple...), d'une part ils ne sont pas écrits en Basic, et d'autre part ils utilisent le système d'interruption décrit dans l'autre article technique du moment sur les instructions VDP. Le fait de cadencer les traitements par les interruptions de l'affichage permet de se baser sur le 50Hz (ou 60Hz) et non pas sur la rapidité du processeur. C'est pour cela que la seule différence de vitesse dans les jeux est relative au rafraîchissement de l'affichage.
En ce qui concerne les jeux Konami (par exemple...), d'une part ils ne sont pas écrits en Basic, et d'autre part ils utilisent le système d'interruption décrit dans l'autre article technique du moment sur les instructions VDP. Le fait de cadencer les traitements par les interruptions de l'affichage permet de se baser sur le 50Hz (ou 60Hz) et non pas sur la rapidité du processeur. C'est pour cela que la seule différence de vitesse dans les jeux est relative au rafraîchissement de l'affichage.
le turbo-r peut exécuter les jeux basic en 3.58MHZ il suffit d'appuyer sur la touche 1 a l'init pour désactiver le mode 7Mhz
on peut aussi jouer a certains jeux en mode speed si on les charge en version disque
on peut aussi jouer a certains jeux en mode speed si on les charge en version disque
igal
Membre non connecté
Conseiller Municipal
ok..pour la synchronisation 50 ou 60Hz.
OK...alors le R800 est le Seul Cpu dans le Turbo-R et pour le coup, il est "Complatible" Z80 mais s’embarrasse pas simuler le nombre de cycle "identiques" aux capacités du Z80 mais envoie tout ce qu'il peut comme il le peut
OK...alors le R800 est le Seul Cpu dans le Turbo-R et pour le coup, il est "Complatible" Z80 mais s’embarrasse pas simuler le nombre de cycle "identiques" aux capacités du Z80 mais envoie tout ce qu'il peut comme il le peut
non dans le turbo-r il y a 2 processeurs , le Z80 est caché dans la puce T9769C
https://www.msx.org/wiki/Toshiba_T9769
https://www.msx.org/wiki/Toshiba_T9769
igal
Membre non connecté
Conseiller Municipal
Ah..
Que je comprenne:
Les instructions Basic passent par l'interpréteur et s'adresse au Z80 pour éxécuter le tout.
J'imagine que puisque l'interpréteur "interprète",il s'adresse au Z80 parce que ce dernier comprends parfaitement l'interprétation en question.
Je veux dire par la que...J'ai toujours pensé que c'est bien un Z80 qui prend en charge "au moins le Basic" et donc de ce fait, pq le Turbo-R le fait plus vite que le Msx2 et 2+ ?
Le phénomène est identique (je parle en émulation bluemsx) les temps de chargement des listing en .ASC sont 10 plus rapides que sur msx2.
En fait, je me dit que si dans un turbo-R certains composants permettent d'accélérer les exécution du Z80 au niveau hardware, on pourrait chercher à savoir quels sont ces composants dans la mesure ou le R800 n'y est pour rien!
Que je comprenne:
Les instructions Basic passent par l'interpréteur et s'adresse au Z80 pour éxécuter le tout.
J'imagine que puisque l'interpréteur "interprète",il s'adresse au Z80 parce que ce dernier comprends parfaitement l'interprétation en question.
Je veux dire par la que...J'ai toujours pensé que c'est bien un Z80 qui prend en charge "au moins le Basic" et donc de ce fait, pq le Turbo-R le fait plus vite que le Msx2 et 2+ ?
Le phénomène est identique (je parle en émulation bluemsx) les temps de chargement des listing en .ASC sont 10 plus rapides que sur msx2.
En fait, je me dit que si dans un turbo-R certains composants permettent d'accélérer les exécution du Z80 au niveau hardware, on pourrait chercher à savoir quels sont ces composants dans la mesure ou le R800 n'y est pour rien!
il faut imaginer deux CPU qui travaillent en paralèlle avec des organes commun
il y a une boite de vitesse dans le S1990
la doc du net n'est pas fidéle le R800 est a l'extérieur
MSX Turbo R
ASCII S-1990 TurboR bus controller
NEC S1990, combined with a Toshiba T9769C
The S1990 is not in itself an MSX-engine but acts like "bus controller", it is the combining element that combines the Z80 inside the T9769C (the actual MSX engine) and a R800 CPU, and the memory and slot logic and other hardware inside the T9769C. It also contains hardware to assists in the debugging of software.
MSX Turbo R
Contrôleur de bus ASCII S-1990 TurboR
NEC S1990, associé à un Toshiba T9769C
Le S1990 n’est pas en soi un moteur MSX mais agit comme un "contrôleur de bus", c’est l’élément de combinaison qui combine le Z80 à l’intérieur du T9769C (le véritable moteur MSX) et un processeur R800, la logique des slots et autre hardware à l'intérieur du T9769C. Il contient également du matériel pour aider au débogage des logiciels.
ne te fie pas trop aux émulateurs ce ne sont pas des vrais MSX
il y a une boite de vitesse dans le S1990
la doc du net n'est pas fidéle le R800 est a l'extérieur
MSX Turbo R
ASCII S-1990 TurboR bus controller
NEC S1990, combined with a Toshiba T9769C
The S1990 is not in itself an MSX-engine but acts like "bus controller", it is the combining element that combines the Z80 inside the T9769C (the actual MSX engine) and a R800 CPU, and the memory and slot logic and other hardware inside the T9769C. It also contains hardware to assists in the debugging of software.
MSX Turbo R
Contrôleur de bus ASCII S-1990 TurboR
NEC S1990, associé à un Toshiba T9769C
Le S1990 n’est pas en soi un moteur MSX mais agit comme un "contrôleur de bus", c’est l’élément de combinaison qui combine le Z80 à l’intérieur du T9769C (le véritable moteur MSX) et un processeur R800, la logique des slots et autre hardware à l'intérieur du T9769C. Il contient également du matériel pour aider au débogage des logiciels.
ne te fie pas trop aux émulateurs ce ne sont pas des vrais MSX
igal
Membre non connecté
Conseiller Municipal
Merci pour ces précision Jipe.
avant d'aller au dodo...
Implantation du scrolling multidirectionnel 8 directions => [Droite] [Gauche] [Saut] [chute] [Saut droite] [Saut gauche] [Chute droite] [Chute gauche]
Je vais réfléchir à implémenter la lecture de bribes graphiques verticales probablement par Copy..
A suivre...
Edit: Pour info, la vitesse d'émulation est à 100% sur Turbo-R Edité par igal Le 26/07/2018 à 01h53
avant d'aller au dodo...
Implantation du scrolling multidirectionnel 8 directions => [Droite] [Gauche] [Saut] [chute] [Saut droite] [Saut gauche] [Chute droite] [Chute gauche]
Je vais réfléchir à implémenter la lecture de bribes graphiques verticales probablement par Copy..
A suivre...
Edit: Pour info, la vitesse d'émulation est à 100% sur Turbo-R Edité par igal Le 26/07/2018 à 01h53
igal
Membre non connecté
Conseiller Municipal
Salut à tous.
Petite correctif sur le scroll avec scroll adéquat:
Afin de permettre le déplacement d'un héro dans le même temps que l'exécution d'un saut par n'importe lequel de l'autre héro, j'ai besoin d'introduire un GOSUB dans la boucle du nuancier de saut qui renvoie vers un RETURN qui se trouve dans la boucle principale du déplacement des héros.
Le problème étant que la boucle principale se trouve en "amont" du nuancier de sauts!
Au final, je me retrouve donc avec GOSUB qui vient "Après" le RETURN!
Le problème vous l'aurez compris est qu'on ne peut pas mettre un RETURN avant le GOSUB dans le basic MSX
Alors... Je vais couper court aux remarques "in-constructives".
Il suffit de déplacer ma boucle secondaire "Nuancier de sauts" en amont de la boucle principale "Déplacement des héros" pour résoudre ce problème.
Cependant, je trouve plus logique de placer les éléments secondaires après les éléments primaires
J'ai donc plusieurs questions:
1) Fondamentalement, pourquoi GOSUB=> <=RETURN est acceptable par le BASIC alors que dans le même temps, RETURN=> <=GOSUB renvoie une erreur?
2) Existe t il "une astuce de programmation" (Basic ou autre) qui permette d'obtenir l'équivalent de RETURN avant GOSUB?
Il y a probablement une subtilité qui échappe à mes yeux ou simplement à mes connaissances limités qui me donnent l'impression d'un choix arbitraire même si ce n'est pas le cas j'en suis sur.
La seule idée me venant à l'esprit mais j'ai un peu de mal à décrire est peut être que RETURN avant GOSUB pourrait créer (peut être même systématiquement) une sorte de "boucle infini" (ou je sais pas comment on appel ça) mais le genre de boucle qui fini par afficher un message du genre OUT OF MEMORY ou OVERFLOW je sais plus exactement mais je me suis déjà retrouvé avec ce genre d'erreur avec des boucles pas très catholiques
Merci pour vos réponses ou suggestions.
Vos idées m'intéressent Edité par igal Le 26/07/2018 à 10h11
Petite correctif sur le scroll avec scroll adéquat:
Afin de permettre le déplacement d'un héro dans le même temps que l'exécution d'un saut par n'importe lequel de l'autre héro, j'ai besoin d'introduire un GOSUB dans la boucle du nuancier de saut qui renvoie vers un RETURN qui se trouve dans la boucle principale du déplacement des héros.
Le problème étant que la boucle principale se trouve en "amont" du nuancier de sauts!
Au final, je me retrouve donc avec GOSUB qui vient "Après" le RETURN!
Le problème vous l'aurez compris est qu'on ne peut pas mettre un RETURN avant le GOSUB dans le basic MSX
Alors... Je vais couper court aux remarques "in-constructives".
Il suffit de déplacer ma boucle secondaire "Nuancier de sauts" en amont de la boucle principale "Déplacement des héros" pour résoudre ce problème.
Cependant, je trouve plus logique de placer les éléments secondaires après les éléments primaires
J'ai donc plusieurs questions:
1) Fondamentalement, pourquoi GOSUB=> <=RETURN est acceptable par le BASIC alors que dans le même temps, RETURN=> <=GOSUB renvoie une erreur?
2) Existe t il "une astuce de programmation" (Basic ou autre) qui permette d'obtenir l'équivalent de RETURN avant GOSUB?
Il y a probablement une subtilité qui échappe à mes yeux ou simplement à mes connaissances limités qui me donnent l'impression d'un choix arbitraire même si ce n'est pas le cas j'en suis sur.
La seule idée me venant à l'esprit mais j'ai un peu de mal à décrire est peut être que RETURN avant GOSUB pourrait créer (peut être même systématiquement) une sorte de "boucle infini" (ou je sais pas comment on appel ça) mais le genre de boucle qui fini par afficher un message du genre OUT OF MEMORY ou OVERFLOW je sais plus exactement mais je me suis déjà retrouvé avec ce genre d'erreur avec des boucles pas très catholiques
Merci pour vos réponses ou suggestions.
Vos idées m'intéressent Edité par igal Le 26/07/2018 à 10h11
le programme doit toujours commencer par un GOSUB et se termine par le 1er RETURN rencontré
exemple
10 GOSUB 100
20 PRINT "TERMINE"
30 END
100 PRINT "PASSE ICI"
110 RETURN
mais on peut faire appel a d'autres GOSUB imbriqués
10 GOSUB 100
20 PRINT "TERMINE"
30 END
100 PRINT "PASSE ICI"
110 GOSUB 200
120 RETURN
200 PRINT "PASSE AUSSI ICI"
210 RETURN
exemple
10 GOSUB 100
20 PRINT "TERMINE"
30 END
100 PRINT "PASSE ICI"
110 RETURN
mais on peut faire appel a d'autres GOSUB imbriqués
10 GOSUB 100
20 PRINT "TERMINE"
30 END
100 PRINT "PASSE ICI"
110 GOSUB 200
120 RETURN
200 PRINT "PASSE AUSSI ICI"
210 RETURN
le basic MSX permet de forcer la sortie d'un GOSUB vers une autre ligne que celle d'ou il vient
10 PRINT "test de gosub"
20 GOSUB 100
30 PRINT "fin de test de gosub"
40 END
100 PRINT "PASSE ICI"
120 RETURN 200
200 PRINT "on sort"
300 END
10 PRINT "test de gosub"
20 GOSUB 100
30 PRINT "fin de test de gosub"
40 END
100 PRINT "PASSE ICI"
120 RETURN 200
200 PRINT "on sort"
300 END
igal
Membre non connecté
Conseiller Municipal
Merci pour cet exemple Jipe.
Pas de soucis pour le processus GOSUB => <= RETURN.
Dans mon cas, je voudrais faire ce qui suit mais c'est impossible puisque j'ai automatiquement un [RETURN WITHOUT GOSUB].
10 "Boucle de mouvements des 2 héros"
20 si le joueur 1 saute GOSUB 100
30 RETURN (il s'agit du RETURN appartenant au GOSUB de la ligne 120) Ce RETURN étant interprété avant SON GOSUB, l'interpréteur va renvoyer l'erreur [RETURN WITHOUT GOSUB]
40 ' etc..
100 "Nuancier de sauts du héro 1"
110 ' processus de saut en cours...
120 ' Il faut injecter un RETURN vers la "boucle de déplacements des 2 héros" ICI donc => GOSUB 10
130 RETURN (il s'agit du return du GOSUB en ligne 20)
110 'etc...
Aborde ma question de la façon suivante.
Puisque RETURN => <= GOSUB peut se montrer utile dans mon cas et probablement dans plein d'autres cas, pourquoi le BASIC microsoft (ou encore les autres langages informatiques (je sais pas si c'est la cas) l'en empêchent?
En d'autres mots, quel est le problème "Mathématique" qui rend (peut être impossible) cette approche à savoir RETURN avant GOSUB du moment que les deux existent voir même que le nombre de GOSUB et RETURN sont égaux dans l'ensemble du programme? Edité par igal Le 26/07/2018 à 11h16
Pas de soucis pour le processus GOSUB => <= RETURN.
Dans mon cas, je voudrais faire ce qui suit mais c'est impossible puisque j'ai automatiquement un [RETURN WITHOUT GOSUB].
10 "Boucle de mouvements des 2 héros"
20 si le joueur 1 saute GOSUB 100
30 RETURN (il s'agit du RETURN appartenant au GOSUB de la ligne 120) Ce RETURN étant interprété avant SON GOSUB, l'interpréteur va renvoyer l'erreur [RETURN WITHOUT GOSUB]
40 ' etc..
100 "Nuancier de sauts du héro 1"
110 ' processus de saut en cours...
120 ' Il faut injecter un RETURN vers la "boucle de déplacements des 2 héros" ICI donc => GOSUB 10
130 RETURN (il s'agit du return du GOSUB en ligne 20)
110 'etc...
Aborde ma question de la façon suivante.
Puisque RETURN => <= GOSUB peut se montrer utile dans mon cas et probablement dans plein d'autres cas, pourquoi le BASIC microsoft (ou encore les autres langages informatiques (je sais pas si c'est la cas) l'en empêchent?
En d'autres mots, quel est le problème "Mathématique" qui rend (peut être impossible) cette approche à savoir RETURN avant GOSUB du moment que les deux existent voir même que le nombre de GOSUB et RETURN sont égaux dans l'ensemble du programme? Edité par igal Le 26/07/2018 à 11h16
Visiteur
Vagabond
Message : 0
Ha Igal! Si tout était aussi simple qu'un jus bio détox...
L'instruction "GOSUB" est conçue pour appeler une sous-fonction dans un programme. C'est un débranchement temporaire vers un endroit du programme réservé à cette sous-fonction.
La fin de la sous-fonction est déterminée par l'instruction "RETURN" et cela entraîne la reprise du programme principal.
Donc on doit systématiquement avoir la structure :
programme principal
GOSUB FONCTION
fin programme principal
FONCTION
fait ci, fait ça
RETURN
Pourquoi ne peut-on pas avoir un RETURN avant un GOSUB? Parceque le RETURN revient à l'endroit du GOSUB qui a appelé sa fonction. Si tu indiques un RETURN sans GOSUB avant, le BASIC ne sait pas où retourner.
Il faut bien séparer les instructions du programme principal et les partie de programme des fonctions appelées par GOSUB. De même il ne faut pas faire de GOTO entre le programme principal et une fonction et inversement.
Ce que tu essaies de faire est une sorte de "réentrance" (en pire!) c'est à dire appeler (sauter dans) le programme principal à partir d'une fonction.
Il faut que tu organises ton programme autrement en tenant compte que l'appel aux fonctions sont des débranchements temporaires vers une partie de code répétitive, ou sélective (ON . GOSUB).
Comme l'indique le lien donné par Jipe : "L'utilisation de GOSUB dans une boucle ou de manière récursive, sans les instructions RETURN correspondantes, provoque généralement un débordement de pile. C'est pour cela que lorsque l'interpréteur BASIC rencontre une instruction RETURN sans GOSUB, il émet une erreur RETURN WITHOUT GOSUB."
Note : Je parle de "fonction" mais c'est un abus de langage pour le BASIC MSX, il s'agirait plutôt d'une procédure, ou "débranchement temporaire" du programme.
igal
Membre non connecté
Conseiller Municipal
@Jipe et Sylvain: Merci pour vos lumières
@Sylvain: J'ai grugé en déplaçant "une bribe" de ma boucle principale.
En gros...
Dans ma boucle "Nuancier de Saut du Héro 1" j'ai intégré la partie de la boucle principale qui permet le déplacement du Héro 2.
T=STICK(1):ONT+1GOSUB10780,10890, etc...
Et inversement:
Dans ma boucle "Nuancier de saut du Héro 2", j'ai intégré la partie de la boucle principale qui permet le déplacement du Héro 1.
S=STICK(0):ONS+1GOSUB780,890,1060, etc...
De la sorte, j'ai conservé la nomenclature du programme à savoir boucle principale en premier (déplacement) et boucle secondaire (nuancier saut) par la suite.
La modification du programme a fait émerger un bug caché dans le nuancier de saut du Héro 2 (le Ninja)
A suivre...
@Sylvain: J'ai grugé en déplaçant "une bribe" de ma boucle principale.
En gros...
Dans ma boucle "Nuancier de Saut du Héro 1" j'ai intégré la partie de la boucle principale qui permet le déplacement du Héro 2.
T=STICK(1):ONT+1GOSUB10780,10890, etc...
Et inversement:
Dans ma boucle "Nuancier de saut du Héro 2", j'ai intégré la partie de la boucle principale qui permet le déplacement du Héro 1.
S=STICK(0):ONS+1GOSUB780,890,1060, etc...
De la sorte, j'ai conservé la nomenclature du programme à savoir boucle principale en premier (déplacement) et boucle secondaire (nuancier saut) par la suite.
La modification du programme a fait émerger un bug caché dans le nuancier de saut du Héro 2 (le Ninja)
A suivre...
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie