680×0 vers 68000 (x>=2)

12 sujets de 1 à 12 (sur un total de 12)

Counia
22 février 2011 à 23h51 #9360
Si quelqu’un y a déjà planché ou a ça sous le coude !

Je recherche la logique de correspondance pour une compatibilité de brochage 68000:

A0(sur 680×0) <-> UDS + LDS(sur 68000) ; simul. du signal E du 68000 , etc et tout et tout avec la limite du bus-donné à 16bits si adresse <= 2^23.
Gilloo
23 février 2011 à 9h49 #143771
Cela vient du fait que le 68000 ne dispose pas de la ligne A0.

Il utilise le bus de données pour simuler A0 avec les lignes UDS, LDS et… AS

UDS upper data strobe

LDS lower data strobe

AS address strobe.

Avec le 68000, le bus de données 16bits se découpe en 2x8bits

UDS = 0; LDS = 0 => rien de valide sur le bus

UDS = 0; LDS = 1 => adresse impaire

UDS = 1; LDS = 0 => adresse paire

UDS = 1; LDS = 1 => utilisation du bus de données en 16 bits

Dans ton cas, tu veux A0, donc repérer les adresses impaires, c’est donc simplement la valeur de LDS quand AS vaut 1.

Physiquement, pour AS, UDS, LDS, c’est de la logique inversée. 0 => +5V; 1 => +0V

Donc quand AS vaut +0V,

si LDS vaut +5V => adresse paire.

si LDS vaut +0V => adresse impaire.

C’est tout expliqué ici:

http://www.users.cloud9.net/~stark/txhmt6.pdf
Counia
26 février 2011 à 21h53 #143772
Ok pour ça et merci pour le lien.

C’est plutôt l’inverse que je regarde, partir d’un A0 et chercher à simuler LDS+UDS et aussi les autres lignes spécifiques aux 8bits VMA, VPA, E.

Je pensais que ces équations seraient trouvables sur le Net, mais jusque là j’ai rien vu de valable.

Pour le forçages du bus en fonction de l’adresse j’ai vu les lignes DSACKn qui marcheraient bien.

Encore une différence d’après ce que j’ai vu sur leur Doc. les 680×0 ne semblent pas bloqués par une écriture non alignée en adresse paire (comme sur 68000).

Quelqu’un peut me confirmer qu’un MOVE.W/L en adresses impaires marche?
Counia
22 mai 2011 à 1h21 #143773
J’avance sur mes équations.

Par contre je ne décode que les seuls cas possibles du 68000 soit MOVE.L ; MOVE.W et les deux MOVE.B (adr paire et impaire).

Par contres en code >=68020, bien que techniquement possible est ce que les assembleurs Amiga autorisent les mésalignements de données ?

Et les L/E en 24bits ?

rem: Bien évidement je n’ai pas de 68020 dans le 2000 pour tester ces quatre “nouveaux” cas donc si quelqu’un veut bien si coller.
Gilloo
24 mai 2011 à 15h38 #143774
Quelqu’un peut me confirmer qu’un MOVE.W/L en adresses impaires marche?

Sur 68000/68010 cela plante, à partir du 68020 cela fonctionne.

Poseidon plante sur 68000 à cause de ça: le nombre de ports dans un hub s’obtient dans une structure non alignée.

Par contres en code >=68020, bien que techniquement possible est ce que les assembleurs Amiga autorisent les mésalignements de données ?

Oui. Il est écrit dans tous les grimoires de commodore, que les données des structures doivent être alignées sur mots de 16bits.

C’est le boulot de celui qui créé les structures de faire attention.

Dans mon exemple suivant je viole allégrement le règlement

(rooh po & sie)

struct toto

{

UBYTE pad0 ;

ULONG nonalignedULONG ;

UBYTE pad1 ;

UWORD nonalignedUWORD ;

} ;

struct toto montoto ;

montoto.nonalignedULONG = 1 ; // gourou en 68000

montoto.nonalignedUWORD = 2 ; // gourou en 68000
Counia
26 mai 2011 à 0h07 #143775
Merci Gilloo pour cette confirmation.

Finalement ça ne change pas la complexité de l’équation (légère modif sur la simul. du LDS).

En fait avec le bus multiplexé du 68020 on retombe sur les cas déjà traités.

Dans ton exemple, dommage pour la compatibilité, rien qu’en inversent l’ordre des déclarations c’était bon !

Question subsidiaire, en C y a t’il l’équivalent de la directive d’assemblage “EVEN” ou faut t’il déclarer un 8bits juste pour réaligner ?
Gilloo
26 mai 2011 à 9h30 #143776
Il existe une directive __packed, mais elle n’est utilisable uniquement que par gcc (SASC s’en fiche éperdument). Le plus simple est de compter les octets sachant qu’une variable sur la pile est alignée sur 2 octets et qu’une allocation par AllocMem ou AllocVec est alignée sur 4 octets (mots longs / 4 pour AmigaDOS).

Donc ne jamais faire ce que j’ai montré dans mon post précédent, i.e. décadrer les words et les longs, sinon gourou 2 ou 3 sur 68000.
Counia
26 mai 2011 à 23h55 #143777
Ce que tu dis sur les structures m’intéresse, c’est pas directement pour ce projet, mais pour du code que je refais en C pour mon montage USB.

Donc si je suis bien , le 1er octets d’une structure sera toujours sur une adresse paire, quelque soit la taille du premier champ.

Par contre si on utilise un tableau de structures.

Chaque structure sera t’elle alors réalignée en adresse paire ? Ou elles seront bêtement juxtaposées en mémoire ?

(et si de taille impaire, ça finira par un guru)

Pour exemple, si j’utilise ce tableau de structures:

struct Fichier

{

char NomDos[12];

char NomLong[32];

long Taille;

char Date[13];

}

struct Fichier TabRepertoire[REPERTOIRE_MAX];

Il est clair qu’on fini ici par monopoliser une adresse paire pour un seul octet, donc le prochain octet libre sera sur une adresse impaire.

Hors pour un 68000, il faudra que le “long Taille” soit toujours aligné.
henes
27 mai 2011 à 10h04 #143778
printf(“%un”, sizeof(struct Fichier)); te donnera ta réponse…
Gilloo
27 mai 2011 à 10h12 #143779
Si tu écris quelque part:

printf(“taille de struct Fichier %ldn”, sizeof(struct Fichier)) ;

tu as compté les octets de ta structure, soit 61 octets, mais tu vas avoir la surprise que le sizeof te dise 62! donc la tableau TabRepertoire de structures Fichier a bien chaque élément cadré sur une adresse paire.

Par contre essaie de mettre le champ Date en premier dans ta structure Fichier qui fera toujours 62 octets, et tu verras qu’au premier accès sur le champ Taille, ça plante en 68000.

Les chaines en C peuvent très bien commencer à une adresse impaire. (des fois je trouve que mes explications sont tirées par les cheveux )

Damned, je me suis fait grillé par Henes…
krabob
27 mai 2011 à 11h21 #143780
Par contres en code >=68020, bien que techniquement possible est ce que les assembleurs Amiga autorisent les mésalignements de données ?

De mémoire ( mais je suis sur à 99.9%) … non non non, les assembleurs n’acceptent de faire de move.w ou move.l que sur des adresses paire, que ce soit sur 68000 ou sur 680×0 !!! Aprés, ya moyen de faire exécuter de tels move (genre avec move.w d0,(a0,d1) et d1 impair ) mais ça donne des exceptions, d’ou l’utilisation massive de la commande “even” pour aligner du code après des data (note: les tailles des instructions asm sont 2 4 ou 6 et pas autre chose si je me souviens bien)

/me qui a fait du 68000 shortcode avec des movem partout ce week end.
Counia
27 mai 2011 à 23h16 #143781
Je dirais que c’est plutôt “printf” l’adresse des champs Taille qui donne la réponse.

Je suis effectivement, surpris de de voir la taille à 62 ; y a un Gremlins dans mon Amiga.

Donc sauf erreur:

printf(“%xn”, &(TabRepertoire[x].Taille)) ;

Ces adresses sont toujours paires (et espacées de 62).

J’ai donc passé le champ Date en début de structure.

Il en est de même (toujours paires).

J’ai même fais une mise à valeur des variables (Taille), mais pas de guru non plus.

J’en déduis que mon compilateur ajoute bien un 62éme octet et le fait avant le “long Taille”.

J’ai pas exploré en mémoire pour savoir exactement où, mais je parierais pour juste avant les “Long”.

Donc c’est un gentil Gremlins