Zezito in The Glittering Caves - MO5 Forth (Bandini) and 6809 Assembly

[Iapetus]

Je suis en train de porter mon jeu de commodore 64 programmé en forth a mo5 ( vidéo ) . Et hier, j'ai trouvé un bug bizarre et difficile de détecter sa cause, mais finalement, j'ai remarqué que l'action des paroles c! et c@ est sur l'octet de poids fort de la variable en question, et à cause de cela je ne peux pas utiliser +! pour ajouter une valeur à cet octet comme je le fais sur la version c64 durexforth. Après cela j'ai testé les paroles c! et c@ en Forth Bandini pour Mo5, FORTH-TO7, Durexforth sur c64, Pampuk d'Hector et ZX-Forth sur ZX Spectrum. Et seulement les forth pour les machines Thomson la opération de ces paroles est sur l'octet de poids fort, mais en forth pour les autres machines est sur l'octet de poids faible.

forthcompare.jpg (207.18 Kio) Consulté 1623 fois

le code en question version durexforh:

Code : Tout sélectionner

: sacaspr 
0 indexacido c!
 11 0 do 
  20 0 do
   i 2* 2* 2* 2* x2 !
   j 2* 2* 2* 2* y2 c!
   i j letilebuf 
   case 
    2 of \ tile cinza
     1 ntiles +!  ( <------ le problème)
    endof   
    3 of \ porta
     j 2* to vyporta i 2* to vxporta
     0 i j ptilebuf
    endof 
    4 of \ acido
     i 2* xacido indexacido c@ + c!  
     j 2* yacido indexacido c@ + c!  
     1 indexacido +!     ( <------ le problème)
    endof 
    11 \ zezito   
    of 
     x2 @ dup zx ! zxini !
     y2 c@ dup zy c! zyini c!
     0 i j ptilebuf
    endof
   endcase 
 loop 
loop 
;

le problème était:

Code : Tout sélectionner

1 ntiles +!

car sur durexforth je considère la variable ntiles comme 8 bits et ce n'est pas possible sur le mo5.

donc la version de la parole en mo5 est:

Code : Tout sélectionner

: SACASPR 
11 0 DO 
 20 0 DO
  I 16 * X2 !
  J 16 * Y2 C!
  I J LETILEBUF DUP DUP 
  2 = ( TILE CINZA)
  IF
   ( TILE CINZA)
    NTILES C@ 1+ NTILES C! ( <------ ou utilisé 1 NTILES +!  et je dois considérer la variable comme 16 bits )
  ENDIF   
  3 = ( PORTA)
  IF
    J 2 * VYPORTA C@ 
    I 2 * VXPORTA C@
    0 I J PTILEBUF
  ENDIF  
   11 = ( ZEZITO) 
   IF
    X2 @ DUP ZX ! ZXINI !
    Y2 C@ DUP ZY C! ZYINI C!
    0 I J PTILEBUF
   ENDIF
 LOOP 
LOOP 
;

Je pense que la raison est que le processeur du Thomson, 6809, est gros-boutiste(big endian) et le 6502 et z80 son petit-boutistes(little endian). Le problème est que comme j'ai mentionné en haut en Forth Bandini e Forth-TO7 il n'est pas possible d'utiliser +! . La solution est d'utiliser les valeurs 16bits au lieu de 8 bits pour certaines variables.



(merci pour votre patience avec mon français faible)

[__sam__]

C'est logique "c!" et "c@" écrivent et lisent l'octet pointé. Or comme le 6809 contrairement aux Z80 et 6502 est big-endian, si tu pointes sur une variable (16 bit en FORTH), tu touchera l'octet fort sur 6809 et faible sur les machines little-endian.

Solution: utiliser "!" et "@" partout (ce que tu indiques) ce qui est logique car c'est conçu pour fonctionner avec le type entier standard (16 bits big-endian sur thomson). Mais tu peux aussi te faire un mot spécifique (exemple: "c+!" ) qui fait l'addition sur l'octet de poids fort sur Thomson (ou plus généralement les big-enduan) et sur l'octet de poids faible sinon.

[Iapetus]

Merci __sam__ , la seule raison pour laquelle j'utilise certaines variables en 8 bits sur durexforth/c64 est parce qu'elles sont plus rapides. Et dans un jeu codé en forth, j’ai besoin de toute la vitesse possible. Et au contraire du Mo5, le c64 a un mode caractères y sprites par hardware que le rendre plus rapide quand on veut afficher des graphiques. C'est vrai que le 6809 est bein adapté à la manipulation des valeurs 16 bits donc je pense que ne será pas trop grave.

[Iapetus]

Testing le Sprite engine...

[__sam__]

XOR is in the place. It looks great.

[Iapetus]

Stressing le Sprite Engine avec 7 sprites

[__sam__]

It looks like all the sprites are all cleared and then redrawn at another location. Wouldn't it flicker less if each sprite, one at a time, is cleared and redrawn ? (e.g. at most one flickering sprite at a time, not all sprites flickering together in sync)

[Iapetus]

XOR is in the place. It looks great.

Yes that was the only way to get something acceptable, the video is not as smooth as on the emulator.I need to try this on the real machine at a later stage.

Also the sprites are moving at byte steps horizontally, I will improve that by making them move at least at 4 pixel steps.

I hope this won't get too slow after adding the player movement and collision checking.

[Iapetus]

It looks like all the sprites are all cleared and then redrawn at another location. Wouldn't it flicker less if each sprite, one at a time is cleared and redraw ? (at most one flickering sprite at a time, not all sprites flickering together in sync)

Yes that might make it less flickery, I will have to play with also other options yet, depending on how much free memory I have.

[Iapetus]

I have 10kb free

[__sam__]

Out of how much ? How "heavy" is the forth "bootstrap" memory footprint ?

[Iapetus]

This is the memory map taken from the manual:

mo5forthmemmap.jpg (36.89 Kio) Consulté 1278 fois

So I have about 10k, plus more or less 7kb using the écran buffer for data.

[Iapetus]

As it wouldn't be fair to have just a black and white version and the forth version is just a kind of pet project just to see what it can do, I am coding also another version in colour in assembly:


I have to tweak the animation of the snails as it is faster than it should be now.

[Zebulon]

Bravo c'est superbe !

[Iapetus]

Merci @Zebulon