Logicielsmoto.com

Nous sommes le 28 Mar 2024, 11:52

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5, 6 ... 12  Suivante
Auteur Message
MessagePosté: 07 Aoû 2020, 20:47 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Code:
MB rmb 256       ; à initialiser comme il faut en tenant compte du +128 ci-après
ROUT200
   LDU   #MB+128 ; astuce pour indexer comme si B était non-signé
   ANDA  B,U     ; A = A AND Z
   ORB   B,U
   NOTB          ; B = NOT(B OR Z)
   STB   ,-S     ; ici ca serait plus rapide d'avoir un accès direct-page à une variable tampon
   ORA   ,S+
   RTS


Je reviens sur ce code ASM, ça ne marchera pour plusieurs raisons:
- NOTA ou NOTB n'existe pas en ASM
- La négation est NEGA ou NEGB et ça donne le complément à 2 pas bit/bit! (Extrait de "Le microprocesseur 6809, périphériques et le processeur graphique 9365 -66" chez Eyrole:
"NEG : remplace le contenu accumulateur ou l'octet mémoire par son complément à 2. C représente une retenu de soustraction
ex : avec A=$37 NEGA-> $C9, ça marche pour ce cas, mais, avec $80 ça donne 80 (??) et avec $00 ça donne $00 est-ce parce que le complément de 0 = 0 ? C'est pas logique NON(0) = 255 chez moi
- Il n'y a pas de référence à ce qu'il y a à l'édresse écran pour le filtrage.

Bon bref,n j'ai réussi à optimiser le code en utilisant les conditions de comparaison avec 240 et 15.

Question, comment ça marche les piles (S et U) ? A priori c'est un endroit où des variables sont empilées mais où ? Dans quelle RAM ?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Aoû 2020, 20:56 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Bonjour

Le langage Pascal permet d'utiliser la récursivité dans les fonction ou procédure, c'est peut-être pourquoi on trouve des instruction d'empilement/dépilement à outrance ?

D'autre part, il y a aussi Pascal UCSD pour les TO TO9 et TO9+. L'avantage est qu'il gère tous les types de données et contient toutes les librairies équivalente du BASIC (et à ne pas retaper comme c'est le cas avec Pascal Base), mais l'inconvénient est qu'il utilise son propre DOS, donc inexploitable pour créer des jeux vidéos compilés comme une disquette Thomson normale. C'est quand même domùmage qu'on n'ai pas un pascal qui réunissent les 2 (la compilation et DOC Thomson pour Pascal BASE et tous les types de données+ ensemble de librairies équivalente à celle du BASIC 512 + quelques autres pour Pascal UCSD)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Aoû 2020, 21:14 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Sisi NOTA et NOTB existent, sauf qu'il s'écrivent COMA et COMB (ma mémoire..) Sinon petite curiosité au passage, on a X + COM(X) = -1, maintenant j'ajoute NEG(X) de chaque coté, il vient NEG(X)+X+COM(X) = NEG(X)-1. Or X+NEG(X)=0, donc COM(X) = NEG(X) - 1. Si tu est sur un CPU qui n'a pas de COM, mais un NEG, il te suffit de soustraire 1 au résultat du NEG pour avoir le complément à 2. Inversement, on peut optimiser COM(X)+1 en faisant NEG(X) directement. C'est cool ca!

Sinon, de ce que j'ai vu sur TO la pile de Pascal-base commence en $DFF8 (fin de RAM) et descend en fonction des vars locales etc et des appels récursifs (Cela bloque U et S: U est fixe dans chaque méthode, S varie en fonction des push/pull). Le code programme démarre en $AC00, mais il peut être relogé bien plus bas. L'espace de travail qui contient les primitives des vars temporaires pour fait les multiplications, les chaines de caractères etc est référencé par rapport à X qui me semble pointer juste après le code. On a l'organisation suivante:
Code:
$AC00 ................................................... $DFF8
Code --- espace de travail |                     <<<<PILE

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Aoû 2020, 11:33 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Sisi NOTA et NOTB existent, sauf qu'il s'écrivent COMA et COMB (ma mémoire..) Sinon petite curiosité au passage, on a X + COM(X) = -1, maintenant j'ajoute NEG(X) de chaque coté, il vient NEG(X)+X+COM(X) = NEG(X)-1. Or X+NEG(X)=0, donc COM(X) = NEG(X) - 1. Si tu est sur un CPU qui n'a pas de COM, mais un NEG, il te suffit de soustraire 1 au résultat du NEG pour avoir le complément à 2. Inversement, on peut optimiser COM(X)+1 en faisant NEG(X) directement. C'est cool ca!


Ah oui tien en effet! Je ne suis pas encore un expert de l'ASM 6809 (j'avais fait un truc dessus dans les années 90, une intro de Tétris qui s'est avéré très rapide) mais ça s'arrête là.

Merci pour les éclaircissements! Du coup j'tais parti effectivement dans l'idée du NEGA -1 (comme écrit dans la doc du bouquin sus cité), et ça aurait fait 4 instruction au lieu de 2, mais effectivement COM existe bel et bien, mais ils ne l'avaient pas classé dans la catégoirie "instruction logique" mais dans "Incrémentation/Décrémentation, Mise à zéro, complémentation" et comme le cerveua s'arrête au bout de 3 ordres LOL.

J'ai refait ma routine ASM pour les transparence d'octets sans en partant de mon idée initiale, c'est quelque chose du genre
Code:
    LDA ,X 4cy
    CMPA 240 2c
    BLT TRANSA 2c
    LDB ,Y 4c
    JMP TRANSB 3c
TRANSA LDB ,X 4c
TRANSB ANDB 240 2c
    STB ,-S 4c
    ANDA 15 2c
    CMPA 15 2c
    BLT TRANSC 2c
    LDA ,Y 4c
    ANDA 15 2c
TRANSC ORA ,S+ 4c
    STA ,Y+ 4c

Ca met entre 32 et 39 cycles (j'ai comparé avec ton code qui est de 43 cycles dûs aux nombreux appel indexés) suivant les conditions (sans transparence, ça demande 8 cycles, le temps et ici x3 à x4.5 pour chaque paire de pixel, mais si on voit l'instruction dans son ensemble (pour un sprite complet, avec les tests de limites de sprites en longueur et en hauteur), on doit être à x2 je pense au pire.

Question... Je compte utiliser la technique du double buffer couplé aux basculement de RAM vidéo. Je vois que pour le transfert d'un buffer image complet en utilisant le régistre D (2x5 cycle par octet avec LDD et STD), ça demanderait 16000x10/2 = 80000 cycles (sur 1 millions de cycles) soit quasiment 0.1s! Alors pour les sprites, il y a des cycles en plus, ça me parait difficile de tenir 10 images/s dans ces conditions... Faut-il faire un transfert complet de l'image de fond ou seulement utiliser les zones de chaque sprite ? pour Bubble Bobble, vu qu'il peut y avoir jusqu'à au moins 8 sprites en plus du Bubble ainsi que les bulles elles mêmes (une bonne dizaine au moins)... on arrive à 20 sprites (1280 octets sur un total de 8000... c'est vrai que vu comme ça)...Je me demande comment prehisto (même en tenant compte du fait qu'il a codé tous les sprites à la main) a pu s'y prendre pour arriver à 39000 cycles par image... Même si le nombre de sprites est inférieur à celui de Bubble Bubble.

Quand je vois les versions ZX Spectrum, Commodore 64 et Amstrad Homebrew (qui lui, n'utilise pas de double buffer, ça se voit). De plus, il y a une partie de l'écran qui est inerte (les murs gauche et droite occupant1/10 de la largeur d'écran soit 800 octets)

Citation:
Sinon, de ce que j'ai vu sur TO la pile de Pascal-base commence en $DFF8 (fin de RAM) et descend en fonction des vars locales etc et des appels récursifs (Cela bloque U et S: U est fixe dans chaque méthode, S varie en fonction des push/pull). Le code programme démarre en $AC00, mais il peut être relogé bien plus bas. L'espace de travail qui contient les primitives des vars temporaires pour fait les multiplications, les chaines de caractères etc est référencé par rapport à X qui me semble pointer juste après le code. On a l'organisation suivante:
Code:
$AC00 ................................................... $DFF8
Code --- espace de travail |                     <<<<PILE


Oui mais lors de la compil, il ne se réserve que l'espace entre $AC00 et $DF88 ce qui ne permet pas de coder grand chose (j'ai pu coder mes routines d'affichages de 50 Sprites en utilisant une partie avec les octets de couleurs Sprite en plus, mais ça reste restreint quand même. Quoiqu'il en soit, la compil Pascal donne des vitesses d'exécutions au moins x10 comparé au Basic Optimisé. De quoi faire un bon casse brique avec une vitesse raisonnable. Idem pour le tétris. Mais pour ce qui est de Bubble Bobble, ça a besoin d'ere optimisé.


Dernière édition par Neotenien le 08 Aoû 2020, 12:23, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Aoû 2020, 11:54 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
On peut faire plus efficace que d'utiliser D pour la recopie d'écran avec PSHS/PULS, mais ca reste lent quand même. L'idéal n'est que que de copier ce qui a changé.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Aoû 2020, 13:02 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
On peut faire plus efficace que d'utiliser D pour la recopie d'écran avec PSHS/PULS, mais ca reste lent quand même. L'idéal n'est que que de copier ce qui a changé.


Explique moi comment utiliser PSHS dans ce cas (j'ai du mal à comprendre l'utilité des pile ici, à part pour ton exemple sur la transparence, qui, en fin de compte, s'est avéré consommer + de cycle que ma propre routine) ? J'ai un exemple avec LDB dans le manuel technique des TO8/TO9/TO9+, ça ne doit pas gagner quand chose en cycle d'horloge...

Pour ce qui est de remplacer les parties à Sprite, ça pourrait se faire si on utilise une seule banque mémoire pour l'écran (décalage de chaque Sprite d'une unité à chaque fois ou pas), mais si on utilise 2 banques (pour le mode "page écran") pour éviter les scintillements, ça suppose de stocker 2 jeux de datas pour chaque Sprite pour leur position respective, l'ancienne et la nouvelle...

Je ne sais pas si pour Bubble Bobble, cette technique de remplacement par position de Sprite est tellement judicieuses surtout quand beaucoup de bulles sont sur l'écran... Mais sur C64, Amstrad (ces 2 utilisent la transparence) et ZX Spectrum (qui n'utilise pas de transparence!) la vitesse d'animation est quand même plus que correcte (et s'approche de celle de l'Atari ST). Je verrai au besoin... A priori je pars sur du remplacement de Sprite, et pour la transparence, sur mon algorithme qui est + efficace (d'environ 25% en vitesse en moyenne).


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Aoû 2020, 15:21 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
PSHS permet d'écrire plusieurs registres en RAM avec un coût de 1 cycle par octet supplémentaire. Si tu veux effacer une zone écran, tu mets 0 dans pleins de registres (disons D,X,Y,U), tu verrouilles les interruptions, modifie S pour qu'il pointe à la fin de la zone à passer à 0, et tu boucles sur une série de PSHS D,X,Y,U, et voilà 8 octets à 0 en 13 cycles. Voici un exemple de code qui utilise les instructions de pile pour remplir et copier à toute vitesse
Code:
* copie la valeur de D entre X et X+8191
FILL8K:
   PSHS D,X,Y,U,CC
   ORCC #$50          ; pas d'interruptions ici
   STS  FILL8k3+2,PCR ; sauve S
   LEAS 8192,X        ; fait pointer S en fin des 8ko
   STX  lblCMP+2,PCR  ; met à jour adresse de fin
   TFR  D,X           ; copie D en X
   LEAY ,X            ; copie X en Y
   LEAU ,X            ; copie X en U. Maintenant X=Y=U=D
FILL8k1
   PSHS  D,X,Y,U
   PSHS  D,X,Y,U
   PSHS  D,X,Y,U
   PSHS  D,X,Y,U
   PSHS  D,X,Y,U
   PSHS  D,X,Y,U
   PSHS  D,X,Y,U
   PSHS  D,X,Y,U      ; on écrit 8*8=64 octets à toute vitesse (104 cycles)
FILL8k2               
   CMPS  #0           ; dest de fin ?
   BNE   FILL8k1      ; non => on repart our 64 octets de plus
FILL8k3               
   LDS #0             ; recp S d'entrée puis retour à l'appellant
   PULS D,X,Y,U,CC,PC

* Recopie 8 ko entre X et Y   
COPY8k
   PSHS D,X,Y,U,DP,CC
   ORCC #$50          ; pas d'interruptiuons
   STS  COPY8k3+2,PCR ; sauve S

   LEAU 8192,X        ; adresse de fin de recopie
   STU  COPY8k2+2,PCR ; met a jour test de fin
   
   LDD  ,X++          ; 8192 = 21*390 + 2
   STD  ,Y++          ; on s'occupe des 2 premiers
   
   LEAS 7,Y           ; mets à jour les pointeurs
   LEAU ,X            ; U=source S=dest
COPY8k1
   PULU D,X,Y,DP      ; on lit 7 octets
   PSHS D,X,Y,DP      ; on écrit 7 octets
   LEAS 14,S          ; réajuste S => 12 + 12 + 5 = 29 cycles
   PULU D,X,Y,DP      ;
   PSHS D,X,Y,DP      ;
   LEAS 14,S          ;
   PULU D,X,Y,DP      ;
   PSHS D,X,Y,DP      ;
   LEAS 14,S          ; repété 3 fois = 21 octets recopiés à toute vitesse (87 cycles)
COPY8k2
   CMPU #0            ; fin ?
   BNE  COPY8k1       ; non => boucle 5 + 3 cycles
COPY8k3
   LDS  #0            ; recup S d'entrée
   PULS D,X,Y,DP,CC,PC

La copie c'est (3*29+5+3)*390 + 16(les 2 premiers octets) soit à la louche 37ms. On peut en faire 27 par seconde.

Le remplissage de 8ko c'est 128*(104+8) cycles soit 14ms. On peut en faire près de 70 par seconde. Pour remplir l'écran c'est idéal (on peut faire même un peu mieux en pushant DP en plus, mais bon le code exact ne compte pas, ce qui est utile est le principe).

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Aoû 2020, 18:11 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Ce qui est très utile pour scroller un écran par exemple


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 11 Aoû 2020, 10:16 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Autre Méthode pour afficher un écran complet le plus rapidement possible a partir d'une image, mais cela nécessite d'encoder les données de l'image source en sens inverse au préalable (avec un petit utilitaire).
ça ne fonctionne pas pour recopier une zone de données vers une autre évidement ;-)

Code:
DEBUTECRANA EQU $0014 * test pour fin stack blasting
FINECRANA   EQU $1F40 * fin de la RAM A video
DEBUTECRANB EQU $2014 * test pour fin stack blasting
FINECRANB   EQU $3F40 * fin de la RAM B video

DRAW_RAM_DATA_TO_CART_160x200
   PSHS U,DP      * sauvegarde des registres pour utilisation du stack blast
   STS DRAW_RAM_DATA_TO_CART_160x200A_E+2
   
   LDS #FINECRANA   * init pointeur au bout de la RAM A video (ecriture remontante)
   LDU #$A000

DRAW_RAM_DATA_TO_CART_160x200A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   CMPS #DEBUTECRANA
   BNE DRAW_RAM_DATA_TO_CART_160x200A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU B,DP,X,Y
   PSHS Y,X,DP,B

   LDS #FINECRANB   * init pointeur au bout de la RAM B video (ecriture remontante)
   LDU #$C000

DRAW_RAM_DATA_TO_CART_160x200B
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   CMPS #DEBUTECRANB
   BNE DRAW_RAM_DATA_TO_CART_160x200B
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU A,B,DP,X,Y
   PSHS Y,X,DP,B,A
   PULU B,DP,X,Y
   PSHS Y,X,DP,B
DRAW_RAM_DATA_TO_CART_160x200A_E
   LDS  #$0000 * rechargement des registres
   PULS U,DP
   RTS


A lire sur le sujet :
http://blog.moertel.com/posts/2013-12-14-great-old-timey-game-programming-hack.html


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 11 Aoû 2020, 11:17 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Il n'y a même pas besoin d'un petit utilitaire externe si tu charges l'image en VRAM une 1ere fois et que tu fais une première copie par pull/push de la VRAM vers la mémoire de "backup". La copie "backup" se trouvera alors inversée, mais remise dans le con ordre à chaque copie vers la VRAM.

Après recopier toute la ram vidéo est quand même plus lent que de ne juste restaurer les parties sous les sprites.

sam.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 12 Aoû 2020, 13:06 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
J'ai trouvé un code source du jeu ici :
https://www.dwedit.org/bubblebobble/

C'est une version de Bubble Bobble en assembleur pour z80 ...
et ça tourne sur calculatrice TI !

Bon c'est pas l'idéal mais ça peut se révéler utile pour comprendre le moteur du jeu même si c'est un fan game.

Du coup autre lecture ;-) :
https://nowhereman999.wordpress.com/2016/12/29/zilog-z80-to-motorola-6809-transcode-part-001/

et ici des informations sur la gestion des niveaux, des points ... :
https://web.archive.org/web/20190914161321/http://tjasink.com/games/bb/


Fichiers joints:
bbsource.zip [169.61 Kio]
Téléchargé 315 fois
Haut
 Profil  
Répondre en citant le message  
MessagePosté: 12 Aoû 2020, 14:36 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Bonjour

Toujours dans le cadre du développement de l'adaptation de Bubble bobble pour TO, je me suis mis à essayer de créer les routines assembleurs d'affichage de Sprite (avec ma routoine de transparence qui prend moins de 30 cycles d'horloge par Octet grâce au DP)

Cependant, j'ai essayé de convertir le code que j'avais fait du Pascal vers l'Assembleur, et juste pour un affichage de Sprite, j'ai quelque chose qui déconne!!

Voici le code
Code:
***********
* Equates *
***********
* Affichage d'un caractere
PUTC EQU $E803
* Selection DP
DIRECT EQU *<-8
 SETDP DIRECT
* Adresse ecran logique
ECRDEB EQU $4000
**************************
*Procedure affiche sprite
*avec transparence
*pour adresse ecran paire
***************************
 ORG $A000
SPRITP LDA >$E7C3
 ORA #1
 STA >$E7C3
 LDA #DIRECT
 TFR A,DP
BOUC01 LDA #0 Boucle RAMA ou RAMB
 STA ISPRP
 LDY RAMECR
BOUC02 LDA #0 Boucle I : HSPRIP
 STA JSPRP
TRANSP LDA ,X Boucle J : LSPRIP
*Debut transparence couleur 15
 CMPA #$F0
 BLO TRANSA
 LDB ,Y
 JMP TRANSB
TRANSA LDB ,X
TRANSB ANDB #$F0
 STB BTEMPO
 ANDA #$0F
 CMPA #$0F
 BLO TRANSC
 LDA ,Y
 ANDA #$0F
TRANSC ORA BTEMPO
* Fin transparence
 STA ,Y+
 LEAX 1,X
 LDA JSPRP
 INCA
 STA JSPRP
 CMPA LSPRIP
 BLO TRANSP
* Fin boucle J
 LEAY 40-LSPRIP,Y
 LDA ISPRP
 INCA
 STA JSPRP
 CMPA HSPRIP
 BLO BOUC02
* Fin boucle I
 LDA >$E7C3
 ANDA #1
 CMPA #1
 BNE FIPRO0
 LDA >$E7C3
 ANDA #254
 STA >$E7C3
 JMP BOUC01
FIPRO0 RTS
ADDATA FDB ADRSPR
ISPRP FCB 0
JSPRP FCB 0
HSPRIP FCB 16
LSPRIP FCB 2
BTEMPO FCB 0
******************
*Fin procedure
***************
********************
*Programme principal
*Affiche 20x11
*Sprites
********************
 ORG $A500
 ORCC #$50
MAIN LDB #$1B sequence d echappement
 JSR PUTC
 LDB #$5E Mode bm16c
 JSR PUTC
 LDU #$DFFF
* Affichage Sprites
 LDX ADRSPR
 JSR SPRITP
 RTS
***************
*Fin Main
***************
* Espaces mémoire divers
 ORG $B000
RAMECR FDB ECRDEB
MOTIF FCB $FF,$FF,$FF,$FF
 FCB $FF,$FF,$FF,$FF
XECR FCB 0
YECR FCB 0
**************************
* Les Sprites
**************************
* Bubble Droite 1
ADRSPR FCB 255,243,255,51,243,34,255
 FCB 34,255,39,51,112,243,112
 FCB 255,112,51,112,243,39,255
 FCB 0,255,34,245,39,245,39
 FCB 242,153,34,153,255,255,255
 FCB 255,51,47,50,34,242,39
 FCB 50,32,34,32,45,32,45
 FCB 32,32,39,82,112,82,34
 FCB 82,127,82,127,34,121,41
 FCB 121
 END


Au début, vous avez les équates
Puis ma "fonction" assembleur sensée afficher un sprite avec des variable locale (avec DP normalement)
Puis le programme principal que j'ai appelé "main" (comme pour le C)
Enfin des variables et tableau (Sprite) divers à la fin.
Alors il me semble avoir compris que la directive "ORG" permettait de mettre dans une certaine zone mémoire ce qui venait à la suite.
Donc j'ai utilisé ceci pour le code source. J'ai sauvegardé le binaire en "SPRITE.BIN"

Je le lance en Basic en adaptant le CLEAR avec les adressage issus de ce code source ('ORG)

Code:
1 clear,&H9FFF
2 loadm "SPRITES"
3 exec &HA500
4 a$=inkey$: if a$="" then goto 4

Et j'obtiens pas du tout ce que je comptais avoir (c'est à dire un petit Sprite en haut et à Gauche de l'écran) mais un remplissage totale avec des pixels de couleurs différentes sur tout l'écran (ceci étant l’affichage est quasi instantané après le chargement du binaire).

Qu'est ce qui cloche dans mon code assembleur sensé afficher un Sprite en haut et à gauche de l'écran ?
J'ai mis des "étiquettes" I et J pour la procédure et pour le programme principal


Dernière édition par Neotenien le 12 Aoû 2020, 18:45, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 12 Aoû 2020, 16:12 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Code:
     ORG $A500
MAIN
     LDB #$1B sequence d echappement
     JSR PUTC
     LDB #$5E Mode bm16c
     JSR PUTC

Bon, il faut arrêter avec les routines moniteurs relativement chronophages. ;)

Code:
     TFR A,DP

Pourquoi A (résultat de PEEK($HE7C3) OR 1) dans le DP?

Code:
ORG $A500
MAIN
     ...
     LDU #$DFFF
/* Affichage Sprites
     LDX ADRSPR
     STD RAMECR
     JSR SPRITP
     RTS

Pourquoi un STD .RAMECR après un #PUTC?


Dernière édition par jasz le 12 Aoû 2020, 16:36, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 12 Aoû 2020, 16:22 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Code:
     ORG $A500
MAIN
     LDB #$1B sequence d echappement
     JSR PUTC
     LDB #$5E Mode bm16c
     JSR PUTC

Bon, il faut arrêter avec les routines moniteurs relativement chronophages. ;)

Code:
     TFR A,DP

Pourquoi A (résultat de PEEK($HE803) OR 1) dans le DP?

Cette séquence est pour passer en mode bm16c (et c'est clairement écrit!! Je commente mes lignes), je ne vois pas ce que ton TFR vient faire ici...

Le TRF A sert justement à gagner du temps pour passer en mode page direct

J'aimerais des commentaires un peu plus objectifs...


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 12 Aoû 2020, 16:43 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Cette... séquence comme tu la désignes, est pour passer en mode video RAMA et non en BM16c. De plus tu devrais te servir d'avantage de la pile S

Ps. Dans le DP on met #$E7 ;)

J'ai désigné ce qui me semble être une anomalie. C'est à toi de comprendre :tourne:


Dernière édition par jasz le 12 Aoû 2020, 18:51, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5, 6 ... 12  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 34 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com