Samuel Devulder a écrit:
Neotenien a écrit:
... ce qui, fatalement, écrase le script BASIC se trouvant en espace physique 2... On ne peut donc pas revenir à ce BASIC qui a été écrasé COMPLETEMENT par le traitement data servant à l'affichage écran.
Tu n'es pas obligé d'écraser les données du basic. Tu peux les sauvegarder les banques physiques 2 & 3 utilisées par le basic dans les banques 14 et 15 par exemple et restaurer le tout quand tu as besoin du basic.
C'est une idée que je garde sous le coude... Ca suppose de mettre un de ces espaces (banque 2 ou 14) en dessous de l'espace $A000... Donc en espace cartouche à priori. Pur le moment je ne voit pas trop l'intérêt d'utiliser le BASIC, vu que l'extramoniteur possède énormément de fonctions très intéressantes!! Les fonctions mathématiques, graphiques, et même le DOS Iconique. La fonction PLAY de l'extramoniteur en assembleur reprend EXACTEMENT la même démarche que celle du BASIC.
Je préfère quand même largement utiliser l'existant ET NE PAS LE REECRIRE. 2 raisons:
- Pour utiliser au mieux l'espace utilisateur entre $6100 et $9FFF (s'il y a des tas de routines.. Ok pour le moment, ma routine complète d'affichage de sprite prend moins de 256 Octets, mais il ne me reste que 61 (puisque l'espace $6000-$60FF sert pour le moniteur, que j'ai déjà 256 réservé pour la routine d'affichage de Tile/Sprites et 256 pour le masque des sprites) autres "pages" ram à utiliser. pour les routines assembleurs. Ca peut paraître beaucoup mais le jeu Bubble Boble me parait avoir énormément de fonction dedans!!
- Ca me fait perdre du temps pour écrire (ou recopier ?) ce code
Samuel Devulder a écrit:
De même tu peux mapper ce que tu veux dans l'espace ROM vu que tu peux restaurer à volonté et à bas cout CPU le contenu. Si tu voyais comment la ROM s'amuse à changer en permanence de banque ROM $000->3FFF et même en rom moniteur sur TO9, tu n'aurais aucun complexe à faire pareil.
Ca me rassure!! Parce que c'était un point sur lequel j'hésitais énormément (et j'étais même parti pour ne pas utiliser cette possibilité du tout, malgré ce que tu avais écrit auparavant sur la méthodologie d'allocation des espaces en RAM logique dans les jeux. Bon ben ça va me faire une routine de plus à écrire
Samuel Devulder a écrit:
Citation:
On a déjà parlé de ça avant..
Oui ca fait plusieurs fois que je te dis qu'il n'y a pas de raisons de ne pas cohabiter avec le basic. Mais dans le fond je me demande si ca ne sera pas plus sain pour toi de travailler sans le basic. Les routines de générateur aléatoire ne sont pas très difficiles à coder soi-même, et seront même plus rapide que celle du basic (voir du coté de ce que a fait G. Marsaglia en son temps).
Peut-être, au CNAM on en avait codé une telle routine en langage Pascal (que j'ai d'ailleurs gardé sous le coude pour Pascal Base)... Mais en fin de compte, je préfère utiliser l'existant pour les raisons que j'ai indiquées juste au dessus.
Samuel Devulder a écrit:
Citation:
Sans parler de tous les Sprites (j'ai pas compter mais ça doit bien dépasser les 100, à raison d'au moins 16 par personnages), les niveaux de tableaux (100 tableaux avec plus de 600 octets par tableau), les paramètres audio... Ca prend de la place tout ça.
Il te faudra dans tous les cas une gestion de mémoire rigoureuse avec un chargement et une organisation disk qui marche de concert.
A ce propos, j'espère qu'il y a une alerte dans le système indiquant quand un fichier est chargé ? Ca serait top. Je n'en sais pas encore à ce niveau. j'ai beaucoup d'autres trucs à faire avant.
De toutes façons, je pense que je vais tout charger du Basic (les 4 fichiers de 16kO pour les tableaux, 25 tableaux par fichier, dans différentes banques, les Motifs des tableaux (2 Tiles par tableau), les sprites, les programmes binaires, et l'audio...)
En tous cas, la routine assembleur actuelle permet de dire qu'elle peut effacer et afficher 200 Sprites (avec transparence) de 8x16 par seconde. C'est pas mal!! Sachant qu'il y aura grand max 20 Sprites (Personnages+bulles) à la fois, on peut tabler avec de la marge sur du 2 im/s au plus lent (en y intégrant la musique de fond).
Et le test d'animation de 12 Sprites en 4 MHz sous DC Moto (en mode 6809) donne une vitesse de déplacement PHENOMENALE! Je me demande comment l'Amstrad (Z80 à 4 MHz quand même) peut être aussi lent avec le jeu "Enduro Racer", je l'ai testé en mode 4 MHz sur DC Moto, ça va aussi vite qu'une borne d'arcade!! J'ose à peine imaginer ce que l'Hitachi 6309 avec les 4 registre d'ALU, les fonctions supplémentaire (dont déplacement de bloc je crois ? Et surtout division entière) donnerait mais ça ferait du Thomson l'ordinateur 8 bits le plus puissant existant. Même l'audio via CNA (au lieu d'avoir un VALTImer qu'on programme à 1/2000, on ferait du 1/8000 et n ne serait plus limité en rien!!) je crois qu'on aurait une machine équivalente à l'Atari ST même avec la moitié en MHZ (pour info, le 68000 à 8 MHz est donné à 1 MIPS seulement, alors que si le 6809E à 1 MHz est donné à 0.42 MIPS, le 6309 à 4 MHz... à priori, ça ferait au moins du 1.68 MIPS non ? Donc l'atari ST (et l'Amiga encore + puisque lui est à 7 MHZ) est éclaté LOL.