[VG5000] Lode Runner
Modérateurs : Papy.G, fneck, Carl
- Mokona
- Messages : 1040
- Inscription : 17 déc. 2016 22:01
- Localisation : Nord Est des Yvelines
- Contact :
Re: [VG5000] Lode Runner
Il me semble que Daniel a dit que l'émulation du VDP ne respectait pas les timings sur vg5k (tout est immédiat).
Et MAME non plus (il me semble que le code VDP est inspiré de celui de Daniel).
Est-ce que mes souvenirs sont bon ?
Et MAME non plus (il me semble que le code VDP est inspiré de celui de Daniel).
Est-ce que mes souvenirs sont bon ?
Re: [VG5000] Lode Runner
Oui, tu as bonne mémoire !
Le 9345 est pour le moins complexe, et j'ai toujours dit que l'émulation est très approximative. Non seulement toutes les fonctions ne sont pas émulées, mais celles qui le sont ne sont pas parfaites. Ne comptez pas sur dcvg5k pour vérifier vos programmes, il faut les essayer sur la vraie machine.
Quelques bugs m'ont été signalés par des spécialistes, mais je suis un peu paresseux pour les corriger tant qu'ils n'empêchent pas les programmes commerciaux de fonctionner.
A la demande des développeurs de Mame je leur ai communiqué les sources en leur expliquant toutes les imperfections. Je ne sais pas s'ils les utilisent telles quelles où s'ils les ont améliorées.
Le 9345 est pour le moins complexe, et j'ai toujours dit que l'émulation est très approximative. Non seulement toutes les fonctions ne sont pas émulées, mais celles qui le sont ne sont pas parfaites. Ne comptez pas sur dcvg5k pour vérifier vos programmes, il faut les essayer sur la vraie machine.
Quelques bugs m'ont été signalés par des spécialistes, mais je suis un peu paresseux pour les corriger tant qu'ils n'empêchent pas les programmes commerciaux de fonctionner.
A la demande des développeurs de Mame je leur ai communiqué les sources en leur expliquant toutes les imperfections. Je ne sais pas s'ils les utilisent telles quelles où s'ils les ont améliorées.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [VG5000] Lode Runner
Tout problème d'affichage sur émulateur est un problème du code.
Xavier, les tas d'or qui rentrent dans le tableau c'est un problème avec le rnd.
dans le code basic: (rnd(1)*4). Autrement dit un nombre compris entre 0 et 3 avec tout ce que l'on a dit sur cette fonction.
Les bords de tableau sont a X=5. Comme un tas d'or est de largeur 2 ça colle.
Ma fonction rnd_4 renvoie des nombres compris entre 0 et 4, ca colle plus.
Xavier, les tas d'or qui rentrent dans le tableau c'est un problème avec le rnd.
dans le code basic: (rnd(1)*4). Autrement dit un nombre compris entre 0 et 3 avec tout ce que l'on a dit sur cette fonction.
Les bords de tableau sont a X=5. Comme un tas d'or est de largeur 2 ça colle.
Ma fonction rnd_4 renvoie des nombres compris entre 0 et 4, ca colle plus.
Re: [VG5000] Lode Runner
Bonjour
quelqu'un pourrait-il tester sur un VRAI VG5000 les 5 cassettes attachées et m'envoyer ou afficher des captures d'écran? C'est pour voir où commencent les emmerdes avec l'EF9345. Merci d'avance.
quelqu'un pourrait-il tester sur un VRAI VG5000 les 5 cassettes attachées et m'envoyer ou afficher des captures d'écran? C'est pour voir où commencent les emmerdes avec l'EF9345. Merci d'avance.
- Pièces jointes
-
- Lode Runner.zip
- (49.34 Kio) Téléchargé 92 fois
- Carl
- Modérateur
- Messages : 13254
- Inscription : 08 avr. 2007 13:21
- Localisation : http://www.doledujura.fr
- Contact :
Re: [VG5000] Lode Runner
joaopa, voici les copies d'écrans :
Carl
Carl
Re: [VG5000] Lode Runner
Wahou. Ce fut rapide. Merci Carl. C'est pire encore que ce que je pensais. Ca buggue dès le premier tracé graphique.
Incroyable.
Incroyable.
Re: [VG5000] Lode Runner
Je viens de lire la feuille d'application de l'EF9345 sur le site dcvg5k. Dans tous les exemples qui sont donnés, lors des remplissages des registres, le bit BUSY n'est jamais posé. Ca ne doit pas être un hasard. Du coup, j'en déduis que l'EF934 ne peut pas recevoir de remplissage de registres pendant qu'il exécute. Une fois qu'il ne travaille pas, on peut remplir les registres (autant qu'on veut) sans de nouveau attendre. Pour l'exécution, on doit s'assurer que BUSY n'est pas posé .Papy.G a écrit : ↑07 mai 2020 11:25 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.
Je vais tester sur LODE RUNNER. Le truc sympa c'est que l'on pourrait remplir R1,...,R7,R0+8 avec un seul test busy. Il faut juste faire attention que BUSY ne soit pas posé avant de remplir R1. Je vais tester avec Lode Runner.
Quelqu'un (Carl? ) peut-il tester ce qui a été écrit plus haut sur un VRAI VG5000? Merci d'avance.
Re: [VG5000] Lode Runner
L"EF9345 reste pour moi assez mystérieux, mais je pense que oui, tant que le bit busy n'est pas présent, tu ne dois rien faire, car le contrôleur ne prendra pas en compte tes commandes ou chargement de registres.
Ce que j'ai un peu de mal à savoir avec le datasheet, c'est s'il y a des moments où le contrôleur n'est pas disponible alors que tu ne lui fais rien faire... Si c'est le cas, l'idée d'essayer de remplacer le test du bit Busy par des timings à base de boucles d'attentes ou de nop (pour être au plus près de la durée d'exécution des commandes) risque d'être impraticable.
Ce que j'ai un peu de mal à savoir avec le datasheet, c'est s'il y a des moments où le contrôleur n'est pas disponible alors que tu ne lui fais rien faire... Si c'est le cas, l'idée d'essayer de remplacer le test du bit Busy par des timings à base de boucles d'attentes ou de nop (pour être au plus près de la durée d'exécution des commandes) risque d'être impraticable.
Re: [VG5000] Lode Runner
En règle général, un contrôleur qui a un état busy, c'est qu'il a un registre de commande pour lancer l'exécution sur le contrôleur, donc il devrait suffire d'inspecter ce statut avant toute manipulation des registres jusqu'à ce que la commande soit lancée (par l'écriture dans le registre spécifique servant de commande). Après, si on a un contrôle des cycles, on peut arriver à s'en passer en casant du code intermédiaire ou une séquence de NOP si le temps à attendre est suffisamment court par rapport à la méthode d'attente sur le statut busy.
Re: [VG5000] Lode Runner
Un exemple concret ? parce que je vois mal un contrôleur décider tout seule d'une opération à faire sauf si un événement extérieur vient le réveiller : une interruption côté contrôleur et non CPU.
Re: [VG5000] Lode Runner
Et même si c'était le cas : l'état busy passant à 1 alors qu'aucune opération n'a été demandée, c'est ingérable. En effet, après que l'on ait testé le bit qu'il est à 0, au moment d'écrire dans les registres à l'exception de celui de la commande, le bit passerait à 1 parce que ça lui prend de le faire comme ça ? tu ne pourras jamais communiquer viablement avec ce contrôleur !
- Carl
- Modérateur
- Messages : 13254
- Inscription : 08 avr. 2007 13:21
- Localisation : http://www.doledujura.fr
- Contact :
Re: [VG5000] Lode Runner
Joaopa, voici ce que ça donne :
Re: [VG5000] Lode Runner
Du rouge sur le dernier (grand) R de Lode Runner est normal ? et la brique à droite paraît tronquée.
Re: [VG5000] Lode Runner
Ca vient bon. Tout est nickel sauf le LODE RUNNER (le bonus c'est normal, je n'ai pas fini d'implémenter la fonction).
Je regarde le dernier chouia.
Je regarde le dernier chouia.
Re: [VG5000] Lode Runner
Un dernier essai