[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

Répondre
Avatar du membre
Xavier_
Messages : 159
Enregistré le : 24 avr. 2020 21:20

Re: [VG5000] Lode Runner

Message par Xavier_ » 07 mai 2020 10:53

: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 : 500
Enregistré le : 14 sept. 2013 12:17

Re: [VG5000] Lode Runner

Message par joaopa » 07 mai 2020 11:12

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

Avatar du membre
Xavier_
Messages : 159
Enregistré le : 24 avr. 2020 21:20

Re: [VG5000] Lode Runner

Message par Xavier_ » 07 mai 2020 11:17

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)]
Modifié en dernier par Xavier_ le 07 mai 2020 11:22, modifié 1 fois.

joaopa
Messages : 500
Enregistré le : 14 sept. 2013 12:17

Re: [VG5000] Lode Runner

Message par joaopa » 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?

Avatar du membre
Papy.G
Modérateur
Messages : 2240
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [VG5000] Lode Runner

Message par Papy.G » 07 mai 2020 11:25

joaopa a écrit :
07 mai 2020 11:12
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...
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 : 500
Enregistré le : 14 sept. 2013 12:17

Re: [VG5000] Lode Runner

Message par joaopa » 07 mai 2020 11:38

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

Avatar du membre
Xavier_
Messages : 159
Enregistré le : 24 avr. 2020 21:20

Re: [VG5000] Lode Runner

Message par Xavier_ » 07 mai 2020 11:43

Et c'est là que le patch d'Hervé devient indispensable !

hlide
Messages : 1610
Enregistré le : 29 nov. 2017 10:23

Re: [VG5000] Lode Runner

Message par hlide » 07 mai 2020 12:31

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 du membre
Papy.G
Modérateur
Messages : 2240
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [VG5000] Lode Runner

Message par Papy.G » 07 mai 2020 12:50

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
Enregistré le : 26 avr. 2020 15:24
Localisation : Nice

Re: [VG5000] Lode Runner

Message par Guillaume » 07 mai 2020 13:19

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 ...

hlide
Messages : 1610
Enregistré le : 29 nov. 2017 10:23

Re: [VG5000] Lode Runner

Message par hlide » 07 mai 2020 13:20

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 du membre
Papy.G
Modérateur
Messages : 2240
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [VG5000] Lode Runner

Message par Papy.G » 07 mai 2020 14:22

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.

Avatar du membre
Xavier_
Messages : 159
Enregistré le : 24 avr. 2020 21:20

Re: [VG5000] Lode Runner

Message par Xavier_ » 07 mai 2020 17:01

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...

hlide
Messages : 1610
Enregistré le : 29 nov. 2017 10:23

Re: [VG5000] Lode Runner

Message par hlide » 07 mai 2020 19:10

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.

Avatar du membre
Xavier_
Messages : 159
Enregistré le : 24 avr. 2020 21:20

Re: [VG5000] Lode Runner

Message par Xavier_ » 07 mai 2020 19:46

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) Vu 121 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