Forum TI-Planet.org

Xeda, qu'on ne présente plus, travaille actuellement, en plus de tous ses autres projets, sur "Jade"

Jade (dont la deuxième version est ici décrite) est une plate-forme simulée de sa création, qui n'existe pas dans le monde réel, dont le simulateur pour la famille 83+/84+ s'occupe d'un CPU et quelques ports matériels. Jade fournit 256 octets de RAM et 512 octets de code (ROM).
Contrairement à la plupart des CPUs, Jade n'a pas de vrais registres processeur: ils sont mappés en RAM. Les 53 premiers octets de la RAM contiennent les registres (SP, PC, etc.) et les ports; les 128 derniers octets sont alloués à une pile, mais il n'y a pas de danger à utiliser une partie de cet espace comme mémoire de stockage si on n'utilise pas l'intégralité des 128 octets de la pile.

Liste des ports matériels:
* 8 jeux de 5 ports qui contrôlent les sprites: pointeur vers le sprite, coordonnées, méthode de dessin;
* 7 ports pour les pressions de touches;
* 1 port pour sélectionner la liste des sprites qui sont dessinés;
* 1 port pour lire la liste des sprites qui ont été dessinés;
* 1 port pour sélectionner la liste des touches scannées par le simulateur;
* 1 port pour quitter Jade ou activer la mise à jour de l'écran;
* 1 pointeur de pile (SP);
* 1 compteur de programme (PC), utilisant 2 octets.

Le jeu d'instructions est inspiré d'un sous-ensemble du jeu Z80, toutes les instructions peuvent être optionnellement exécutées si les flags C et Z du processeur sont à 1:

Code: Select all

   0   1   2   3   4   5   6   7   8   9   A   B   C   D   E   F
0   lda()   adda()   adca()   suba()   sbca()   xora()   ora()   anda()   cpa()   inc()   rotl()   shftl()   pusha()   pop()   inv()   ldira()
1   ldc()   addc()   adcc()   subc()   sbcc()   xorc()   orc()   andc()   cpc()   dec()   rotr()   shftr()   pushc()   ex()   bits()   ldirc()
2   ret()   setz()   setc()   togz()   togc()   jp1()   jp2()   jrf()   jrb()   call1()   call2()   callf()   callb()
3
;Duplicate for execution on the c flag condition
4x,5x,6x,7x
;Duplicate for execution on the z flag condition
8x,9x,Ax,Bx
;<not implemented>
Cx,Dx,Ex,Fx

lda() charge un octet d'une adresse vers une autre.
ldc() stocke une valeur constante à une adresse.
jp1(), jp2(), call1(), and call2() permettent des sauts et appels relatifs et absolus.

L'état actuel du code est tout à fait utilisable, bien que Xeda indique que la documentation est faible:

Téléchargement première version de Jade v2: http://www.omnimaga.org/index.php?actio ... tach=14836
Plus d'infos sur la programmation en Jade (fichier Jade.inc + code source du programme exemple): http://www.omnimaga.org/index.php?topic ... #msg287207

Source: http://www.omnimaga.org/index.php?topic=15832.0 / http://www.cemetech.net/forum/viewtopic.php?t=8895

Merci beaucoup, Lionel Debroux! J'ai trouvé deux bugs, mais je leur ai fixés, et aussi, j'ai commencé le jeu Pong.

Et le code:

Code: Select all

#include     "ti83plus.inc"
#include     "Jade.inc"
.org 0
scratchmath  equ  252
scratchmath1 equ  253
ballxinc     equ  254
ballyinc     equ  255

Start:
     ldirc(sLSB0,25)
       .dw $100+ball \ .db 3,3,2  ;load the sprite data for Sprite0. The 2 is for XOR logic.
       .dw $100+paddle \ .db 0,24,2  ;load the sprite data for Sprite0. The 2 is for XOR logic.
       .dw $100+paddle \ .db 0,32,2  ;load the sprite data for Sprite0. The 2 is for XOR logic.
       .dw $100+paddle \ .db 94,24,2  ;load the sprite data for Sprite0. The 2 is for XOR logic.
       .dw $100+paddle \ .db 94,32,2  ;load the sprite data for Sprite0. The 2 is for XOR logic.
     ldirc(keyMask,2)
       .db %00010110,31              ;the second byte is for sMask (the sprite mask)
     ldc(ballxinc,1)
     ldc(ballyinc,1)
Loop:
     orc(status,2)      ;tell the status port to draw the sprites
     orc(status,3)      ;tell the status port to update the LCD, then draw the sprites
KeyLoop:
     bits(key1,40h)     ;check for the Clear key being pressed
     orcz(status,80h)   ;sets bit 7 of the status port if the z flag is set. This turns off Jade.
     bits(key2,2)       ;check if player 2 down key is being pressed
     togz()
     jrfz(TestP2Up)
     cpc(sY3,48)
     jrfz(TestP2Up)
     addc(sY3,2)
     addc(sY4,2)
TestP2Up:
     bits(key2,8)       ;check if player 2 down key is being pressed
     togz()
     jrfz(TestP1Down)
     cpc(sY3,0)
     jrfz(TestP1Down)
     subc(sY3,2)
     subc(sY4,2)
TestP1Down:
     bits(key4,2)       ;check if player 2 down key is being pressed
     togz()
     jrfz(TestP1Up)
     cpc(sY1,48)
     jrfz(TestP1Up)
     addc(sY1,2)
     addc(sY2,2)
TestP1Up:
     bits(key4,8)       ;check if player 2 down key is being pressed
     togz()
     jrfz(MoveBall)
     cpc(sY1,0)
     jrfz(MoveBall)
     subc(sY1,2)
     subc(sY2,2)
MoveBall:
     adda(sX0,ballxinc)
     callfz(TestP1Collision)
     cpc(sX0,89)
     callfz(TestP2Collision)
     adda(sY0,ballyinc)
     jrfz(NegYinc)
     cpc(sY0,60)
     togz()
     jrbz(Loop)
NegYinc:
     inv(ballyinc)
     inc(ballyinc)
     jrb(loop)

TestP1Collision:
     lda(scratchmath,sY1)
     jrf(CheckBounds)
TestP2Collision:
     lda(scratchmath,sY3)
CheckBounds:
     lda(scratchmath1,scratchmath)
     subc(scratchmath,3)
     ldcc(scratchmath,0)
     suba(scratchmath,sY0)
     jrfc(CheckOtherBound)
LoseCode:
     ldc(status,80h)
CheckOtherBound:
     addc(scratchmath1,15)
     suba(scratchmath1,sY0)
     jrbc(LoseCode)
NegXinc:
     inv(ballxinc)
     inc(ballxinc)     
     ret()
     
ball:
     .db 18h
     .db 24h
     .db 24h
     .db 18h
     .db 0,0,0,0
paddle:
     .db $C0
     .db $C0
     .db $C0
     .db $C0
     .db $C0
     .db $C0
     .db $C0
     .db $C0


C'est 200 octets Les "ROMs" peuvent rester dans archive, aussi.


Je devrai écrire la documentation pour Jade .__.

L'écriture de la doc est en cours.

Jade peut être utilisé pour faire des tilemaps:

Code: Select all

spriteX = stackbase-1
spriteY = stackbase-2
tilenum = stackbase-3
.org 0
     ldc(keyMask,255)
     ldirc(160,96)
;tilemap data
;drawn by column
     .db 1,1,1,1,1,1,1,1
     .db 1,0,2,2,2,2,0,1
     .db 1,0,0,2,2,0,0,1
     .db 1,0,0,0,0,0,0,1
     .db 1,0,0,0,0,0,0,1
     .db 1,0,0,0,0,0,0,1
     .db 1,0,0,0,0,0,0,1
     .db 1,0,0,0,0,0,0,1
     .db 1,0,0,0,0,0,0,1
     .db 1,0,0,2,2,0,0,1
     .db 1,0,2,2,2,2,0,1
     .db 1,1,1,1,1,1,1,1
     ldirc(sMSB0,4)
       .db 1,96,0,2
     ldc(sMask,1)
TileMap:
     ldc(sY0,64)
     subc(sX0,8)
     jrfc(Start)
TileMapLoop:
     subc(sY0,8)
     jrbc(TileMap)
     pop(tilenum)
     rotl(tilenum)
     rotl(tilenum)
     rotl(tilenum)
     addc(tilenum,tiles)
     lda(sLSB0,tilenum)
     orc(status,2)
     jrb(TileMapLoop)
tiles:
     .db 0,0,0,0,0,0,0,0
     .db 3Ch,42h,81h,81h,81h,81h,42h,3Ch
     .db 3Ch,7Eh,$FF,$FF,$FF,$FF,7Eh,3Ch     
Start:
     ldc(stackptr,0)
     orc(status,1)
     ldc(status,80h)

Source: http://www.cemetech.net/forum/viewtopic ... 768#201768

C'est intéressant, mais quelle est la réelle utilité de ceci, si c'est si semblable aux instructions du z80 ?

A part l'enrichissement personnel, bien sur ?

P-Rex wrote:C'est intéressant, mais quelle est la réelle utilité de ceci, si c'est si semblable aux instructions du z80 ?

A part l'enrichissement personnel, bien sur ?

Ça peut attirer les débutants à essayer "un ASM plus facile" avant de passer au "vrai ASM"

Par exemple, oui.

Je vois que tu as parlé de "simulateur", Lionel, faut-il donc comprendre que le langage machine Jade est converti est z80 avant d'être exécuté ?

mdr1 wrote:Je vois que tu as parlé de "simulateur", Lionel, faut-il donc comprendre que le langage machine Jade est converti est z80 avant d'être exécuté ?

Ben... oui, comme tous les langages, quoi...

Que ce soit un interpréteur ou un simulateur, c'est transformé en asm z80.
Le terme "simulateur" convient mieux cependant puisque là on considère un processeur fictif.

Persalteas wrote:C'est intéressant, mais quelle est la réelle utilité de ceci, si c'est si semblable aux instructions du z80 ?

Je crois que l'idée c'est de permettre à créer et faire courir des programmes avec un langage plutôt simple et dans un environment où il est impossible de planter la calto. Aussi, vue la limite de taille des programmes, on pourrait avoir peut-être des packs de jeux qui contiennent 10 ou 15 jeux mais n'occupent que 5ko. Une autre chose : le "simulateur" fait pas mal de choses pour toi, il gère tes sprites, met à jour l'écran, lit les touches, etc., donc avec très peu d'espace on peut faire des choses assez compliquées.

Xeda a aussi introduit l'indirection avec les commandes ind1() et ind2().