Bus - read/write 16

Bus - read/write 16

par Noé Eric De Santo,
Number of replies: 3

Bonjour,

j'aurais quelques petites questions concernant les opérations sur 16bits:

  • Quelle est l'endianess de la Gameboy; lors de la lecture, lequel des octets lus doit-être utilisé comme celui de poids faible ?
  • Lors de l'écriture sur 16bits, que faire si seul l'un des deux octets est mappé (et l'autre ne peut donc pas être écrit) ? De même lors de la lecture: dans ce genre de cas, doit-on considérer l'octet non lu comme 0x00, 0xFF, ou alors retourner 0xFF dès que l'un des deux ne peut pas être lu (par curitosité, sauriez-vous d'ailleurs pourquoi la valeux 0xFF est retournée plutôt que 0xFFFF, qui me semblerait plus logique) ?

Il y a aussi un petit détail dans les tests fournis que je trouve bizarre: dans bus_write_err (unit-test-bus.c; ligne 169), il est attendu une erreur de type ERR_BAD_PARAMETER. J'aurais voulu savoir si l'erreur est attendue car aucun composant n'est mappé à cette adresse, où s'il y a une autre raison qui m'a échappé.

Merci d'avance,
Noé
In reply to Noé Eric De Santo

Re: Bus - read/write 16

par Cédric Hölzl,

La Gameboy est "little endian", comme beaucoup d'ordinateurs de nos jours (dont probablement le votre). Il faut prendre des précaution (dans certains cas !) dans le cas ou l'émulateur est exécuté sur un système "big endian". 

Pour la lecture/ecriture de 16bit, l'énoncé stipule:
 "lit[/écrit], dans l'ordre d'adresses croissantes, l'octet présent à address et l'octet suivant". 
Il lirait/écrirait donc l'octet à l'adresse donnée dans bus (ainsi que l'octet qui le suit). Notez qu'on peut "accéder" au deuxième octet à partir du premier.

On retourne 0xFF pour la raison suivante mentionné dans l'énoncé: 
 "c'est effectivement le résultat obtenu sur la Game Boy, et certains programmes dépendent de ce comportement pourtant non documenté".

Finalement, a propos du test, une erreur est attendue car l'écriture ne peut pas être faite, il n'y a pas beaucoup de cas qui pourraient empêcher l'écriture à une adresse (votre intuition n'est pas fausse).


J'espère que ça répond à vos questions,

Cedric Hölzl 

In reply to Cédric Hölzl

Re: Bus - read/write 16

par Jean-Cédric Chappelier,

Merci Cédric !

juste quelques compléments :

  • nous avions au départ prévu la gestion de l'endianness (voir les fonction b2l_16 et l2b16 dans util), mais on a décidé de laisser tomber vu l'endianness courrante des ordis (mais si ça vous tente de tester votre code sur une machine big-endian, si vous en trouvez une, libre à vous ;-) )
  • pas nécessaire de « sur-vérifier » à ce stade (on suppose ici la cohérence du mapping : si a est mappé pour une lecture 16 bit  « a+1 » l'est aussi
  • je ne sais pas si l'erreur sur 16 bits de la game boy est 0xffff ou 0xff ; on sait juste que l'erreur 8 bits est 0xff et nous avons fait l'hypothèse, non démentie par nos tests que ce serait le cas aussi pour 16 bits (mais peut être que ça ne se produit simplement jamais ;-) )
  • oui c'est parce que ce n'est pas mappé