[VG5000] Lode Runner

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

Xavier_

Re: [VG5000] Lode Runner

Message par Xavier_ »

:oops:

Code : Tout sélectionner

148 G$=CHR$(126)+CHR$(127)
149 ET 3:FOR I=3 TO 20 STEP 2:CURSORX INT(RND(1)*4):CURSORY I:PRINT G$:CURSORX INT(RND(1)*4)+35:CURSORY I:PRINT G$:NEXT I
où INT(RND(1)*4)= 5 !
Donc, RND(1)=…
Là aussi un problème d'initialisation de curseur…
Faut-il ajouter des ";" après les PRINT pour valider les valeurs ? (vu sur le TRS80 et d'autres machines exotiques)
joaopa
Messages : 512
Inscription : 14 sept. 2013 12:17

Re: [VG5000] Lode Runner

Message par joaopa »

Pour les problèmes d'affichages,je m'en doutais.
Dans la doc de l'EF9345, il est dit que l'on peut tester le bit BUSY simplement à l'execution (registre+8)
Quand on fait ça, on a les problèmes que l'on voit. Si à chaque remplissage de registre, on teste le bit BUSY, les problèmes disparaissent....
L'inconvénient de toujours tester le bit BUSY est que ça prend plus de temps.

Dans le premier tableau, il y a bien trois ennemis. Dans votre version, il y a la ligne 3 qui limite le nombre d'ennemis à 2
Je l'ai retirée
Xavier_

Re: [VG5000] Lode Runner

Message par Xavier_ »

Non seulement "bit BUSY" ça fait nom d'acteur porno, mais en plus, ça fout le bordel dans nos VG5000 !
Honteux soient les Français…

[faudra penser à retirer cette limitation de monstres. (lignes 216/217)]
Dernière modification par Xavier_ le 07 mai 2020 11:22, modifié 1 fois.
joaopa
Messages : 512
Inscription : 14 sept. 2013 12:17

Re: [VG5000] Lode Runner

Message par joaopa »

Pour l'histoire de rnd, c'est pourquoi j'ai ouvert un autre fil sur ça.
Pour l'instant my routine rnd(n) me renvoie un nombre compris (inclus) entre 0 et n
Ce que d'après Sam ne fait pas le VG5000
Il faudrait vraiment savoir ce qu'entendais faire Guillaume avec rnd: inclus ou pas inclus?
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [VG5000] Lode Runner

Message par Papy.G »

joaopa a écrit : 07 mai 2020 11:12Dans la doc de l'EF9345, il est dit que l'on peut tester le bit BUSY simplement à l'execution (registre+8)
Quand on fait ça, on a les problèmes que l'on voit. Si à chaque remplissage de registre, on teste le bit BUSY, les problèmes disparaissent...
Elle indique aussi les timings de prise en compte et de temps d'exécution des instructions, donc, la disponibilité du VDP est prévisible dans une machine, surtout si le CPU et le VDP ont une source d'horloge commune, s'il n'y a pas encore une erreur à ce niveau-là.
C'est vraiment dommage d'être obligé de tester avant chaque écriture, cela gaspille un temps machine considérable.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
joaopa
Messages : 512
Inscription : 14 sept. 2013 12:17

Re: [VG5000] Lode Runner

Message par joaopa »

Tirer de la rom du VG5000 commentée par Daniel

Code : Tout sélectionner

------------------------------------
position curseur en Y=h, X=l
------------------------------------
018c 0ecf      ld      c,0cfh
018e 3e26      ld      a,26h        26=Main pointer R6 (Y)
0190 d38f      out     (8fh),a
0192 ed61      out     (c),h
0194 3e27      ld      a,27h        27=Main pointer R7 (X)
0196 d38f      out     (8fh),a
0198 ed69      out     (c),l

------------------------------------
affichage caractere position curseur
------------------------------------
019a 01cf03    ld      bc,03cfh
019d 3e20      ld      a,20h        20=Command register
019f d38f      out     (8fh),a
01a1 dbcf      in      a,(0cfh) <-  attente EF9345 prêt
01a3 b7        or      a          |
01a4 faa101    jp      m,01a1h ---
01a7 3e22      ld      a,22h        22=Data register R2
01a9 d38f      out     (8fh),a
01ab ed51      out     (c),d        envoi de d
01ad 3e20      ld      a,20h        20=Command register 
01af d38f      out     (8fh),a
01b1 dbcf      in      a,(0cfh) <-  attente EF9345 prêt
01b3 b7        or      a          |
01b4 fab101    jp      m,01b1h ---
01b7 3e21      ld      a,21h        21=Data register R1
01b9 d38f      out     (8fh),a
01bb ed59      out     (c),e        envoi de e
01bd 3e28      ld      a,28h        28=Command register + exec request
01bf d38f      out     (8fh),a
01c1 ed41      out     (c),b        03 = ecriture mode 40 car. 16 bits 
01c3 c9        ret 
On voit qu'il y a 2 tests du bit BUSY alors qu'il n'y a qu'une seule exécution. C'est vraiment la merde
Xavier_

Re: [VG5000] Lode Runner

Message par Xavier_ »

Et c'est là que le patch d'Hervé devient indispensable !
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [VG5000] Lode Runner

Message par hlide »

Si le contrôleur a un état BUSY, je m'attendrais d'abord à tester sa disponibilité avant de modifier un registre. Dans l'exemple du curseur en assembleur, on commence déjà à taper sur des registres sans tester la disponibilité. En BASIC il y a sûrement assez de temps entre deux commandes jouant avec le contrôleur. Par compte en langage machine, les cycles peuvent être trop court entre deux appels et s'ils ne vérifient pas la disponibilité du contrôleur, ils vont droit au mur...
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [VG5000] Lode Runner

Message par Papy.G »

Oui, mais d'une manière optimale, mieux vaudrait faire autre chose en attendant, ou, au pire, attendre juste le temps nécessaire avec des Nops (en boucle, éventuellement) pour pouvoir envoyer dès que possible.
En testant le bit busy, à partir du moment où le VDP est dispo, il faut qu'on ait lu le registre, testé l'état du bit, puis déclenché l'envoi des valeurs. Même si l'on ne perd que cinq ou dix cycles pour un envoi, quand on doit remplir l'écran, même à supposer qu'on ait que 1000 caractères à envoyer (sans les attributs), on perd 5000 à 10000 cycles ainsi, comment remplir une page-écran entière pendant un V-Blank dans ces conditions?
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Guillaume
Messages : 46
Inscription : 26 avr. 2020 15:24
Localisation : Nice

Re: [VG5000] Lode Runner

Message par Guillaume »

joaopa a écrit : 07 mai 2020 11:21 Pour l'histoire de rnd, c'est pourquoi j'ai ouvert un autre fil sur ça.
Pour l'instant my routine rnd(n) me renvoie un nombre compris (inclus) entre 0 et n
Ce que d'après Sam ne fait pas le VG5000
Il faudrait vraiment savoir ce qu'entendais faire Guillaume avec rnd: inclus ou pas inclus?
Hello hello,
Pour les RND, quand on calcul un temps dans un mode pour les ennemis, aucune importance pour les bornes.
Pour les autre RND, par exemple choisir le mode des ennemis (il y en a 3), se peut être 0 1 2 "INT(RND(1)*3)" ou 1 2 3 INT(RND(1)*3)+1. C'est sans importance sauf si on utilise des branchement ON GOTO ou ON GOSUB. Dans ce cas soit la deuxième option INT(RND(1)*3)+1, soit ON a+1 GOTO ...
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [VG5000] Lode Runner

Message par hlide »

Si on fait de l'assembleur et que l'on connait l’enchaînement et les timings du VDP on peut allègrement se passer du bit BUSY en insérant du NOP si nécessaire effectivement. C'est le risque de vouloir utiliser des routines génériques dont on ne peut pas assurer le bon respect du timing qui crée cette contre-performance ou des bugs si on ne respecte pas le bit BUSY.
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [VG5000] Lode Runner

Message par Papy.G »

Le problème vient peut-être d'utiliser ces dites routines, génériques ou pas, n'importe quand (sans synchro avec le VBL). :|
La communication avec le VDP et l'exécution de commandes subit des délais variables pendant les scans qui sont détaillés dans la doc. :P
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Xavier_

Re: [VG5000] Lode Runner

Message par Xavier_ »

Merci Guillaume pour la mise au point sur le RND !

hlide et Papy.G, nous parlons ici du Basic, qui est normalement prévu pour afficher un truc avec PRINT.
Donc, comment les "ingénieurs" ont oublié de purger le registre des centaines de cycles après une commande !
Soit c'est une escroquerie industrielle, soit les usines ont lancer les camions avant la fin du plan R&D.

On aurai pas oublier d'effacer/initialiser l'écran pour purger les attributs fantômes avec d'imprimer les caractères?
Un truc comme INIT…

Un point virgule avec 'PRINT G$' ( Donc, PRINT G$; ) est-il suffisant pour la blague… sur une vraie machine… et non sur un émulateur trop précis et bien réalisé !

Dans ce cas, pourquoi ne pas l'avoir intégré au manuel...
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [VG5000] Lode Runner

Message par hlide »

Ah je croyais que les bugs concernaient la version assembleur qui utiliserait les routines génériques du BIOS/BASIC pour l'affichage et qu'à cause de sa vélocité il enchaînait trop rapidement entre deux routines qui "oublient" de tester. J'imaginais que l'exécution entre deux commandes graphiques par le BASIC laissait suffisament de temps au VDP d'être disponible. Au temps pour moi si ce n'est pas ça.
Xavier_

Re: [VG5000] Lode Runner

Message par Xavier_ »

Zut, Oui… tu as raison.

C'est le chargeur de page écran runtab.zip

Carl a testé le WAV de l'affichage ASM, et non le jeu Basic…

Donc, mes excuses… ce n'est pas du tout un problème Basic !


Pour me recentrer sur cette routine, le fichier donne à peut près les même problèmes sur émulateur.
LodeEcran.JPG
LodeEcran.JPG (75.4 Kio) Consulté 3210 fois
Donc, je comprends mieux le paramétrage direct et les problèmes de tampon sur les registres du VDP.
Si le timing sur l'émulateur est déjà serré, sur la vrai machine avec une horloge un peu moins précise, l'affichage a plus d'oublis de paramétrage d'attributs.

Sûrement une collision d'accès registre… effectivement.
On peut en déduire que l'horloge du VG5000 de Carl est plus lent que l'horloge étalon de l'émulateur.
Répondre