JKB a écrit :Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :Un système à base de 68000 en wrapping ? Tu as dû sacrément t'amuser...
Ouaips. La carte était un peu plus grande qu'un format A4, avec
toute une palanquée et demi de 74xx pour gérer le bus (et de drivers
de bus parce que la puissance sortante du 68K n'était pas assez
grande pour gérer les composants de gestion du bus !).
En fait je n'ai utilisé le 68000 que dans une version microncontrôleur
68302 qui intégrait toute la tuyauterie nécessaire et nécessitait très
peu de logique additionnelle pour s'interfacer avec des circuits
externes. Ça doit être pour ça que j'en ai gardé un assez bon
souvenir... :-)
Côté 6809, il y avait un 6809, un 6840, un 6850, une mémoire RAM de 2Ko,
une PROM de 8, un 74138 et un registre à décalage 8 bits, des
résistances, condensateurs, une horloge TTL 8MHz et c'est à peu près
tout...
Du grand classique, y compris le 74138 comme décodeur d'adresses...
Le registre à décalage, c'était pour l'émission/réception des données ?
Le problème est qu'on avait à l'époque (je ne sais pas si ça a
évolué depuis puisque je n'ai plus été confronté au problème) des
périphériques (incluant la mémoire) à seize bits, mais avec un
signal de validation pour tout le bus.
C'est effectivement une situation à problème, qui interdit notamment
l'écriture sur 8 bits puisque ça écrirait n'importe quoi sur les 8 bits
restants.Sur le 68K, tu as deux
signaux asynchrone de validation des deux octets du bus de données
et rien ne te garantit que les deux octets du bus soient validés en
_même_ temps. J'ai passé des jours à débugguer ce genre de problème
à l'analyseur logique !
Tu veux dire _exactement_ en même temps lors d'un accès 16 bits ? Parce
que d'après tous les chronogrammes que j'ai pu avoir sous les yeux, /UDS
et /LDS bougent en même temps.
Mais c'est vrai que les signaux du bus du
68000 sont asynchrones au sens où ils ne sont pas référencés par rapport
à une horloge externe (ils le sont forcément en interne par rapport à
l'horloge CLK, mais les relations de timing par rapport à cette horloge
sont tout sauf évidentes à déterminer). Manifestement c'était prévu pour
piloter directement de la mémoire 8 bits asynchrone classique de
l'époque, mais pour le reste ce n'était pas un cadeau pour faire les
choses proprement comme on m'avait apris à l'école (machines synchrones
de Moore, toussa). D'où l'ajout des signaux /VPA et E pour piloter les
circuits périphériques à bus synchrone de la famille 6800 d'ailleurs.Bref, c'était jouable lorsque tu utilisais
des périphériques 8 bits ou deux mémoires 8 bits en parallèle, mais
c'était indémerdable dès que tu utilisais un CAN 12 bits (par
exemple).
Te rappelles-tu quel était le problème exactement ?
Quant à adresser des périphériques 8 bits sur un bus de 16, ça
n'avait aucune conséquence même en écriture
Ça faisait quand même des trous dans l'adressage puisqu'un périphérique
8 bits était accessible à des adresses paires consécutives s'il était
connecté sur l'octet de poids fort du bus de données et à des adresses
impaires s'il était connecté sur l'octet de poids faible. Et pour
accéder efficacement à un registre 16 bits d'un périphérique 8 bits, il
fallait utiliser une instruction spéciale MOVEP qui tenait compte de
cette particularité.
JKB a écrit :
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Un système à base de 68000 en wrapping ? Tu as dû sacrément t'amuser...
Ouaips. La carte était un peu plus grande qu'un format A4, avec
toute une palanquée et demi de 74xx pour gérer le bus (et de drivers
de bus parce que la puissance sortante du 68K n'était pas assez
grande pour gérer les composants de gestion du bus !).
En fait je n'ai utilisé le 68000 que dans une version microncontrôleur
68302 qui intégrait toute la tuyauterie nécessaire et nécessitait très
peu de logique additionnelle pour s'interfacer avec des circuits
externes. Ça doit être pour ça que j'en ai gardé un assez bon
souvenir... :-)
Côté 6809, il y avait un 6809, un 6840, un 6850, une mémoire RAM de 2Ko,
une PROM de 8, un 74138 et un registre à décalage 8 bits, des
résistances, condensateurs, une horloge TTL 8MHz et c'est à peu près
tout...
Du grand classique, y compris le 74138 comme décodeur d'adresses...
Le registre à décalage, c'était pour l'émission/réception des données ?
Le problème est qu'on avait à l'époque (je ne sais pas si ça a
évolué depuis puisque je n'ai plus été confronté au problème) des
périphériques (incluant la mémoire) à seize bits, mais avec un
signal de validation pour tout le bus.
C'est effectivement une situation à problème, qui interdit notamment
l'écriture sur 8 bits puisque ça écrirait n'importe quoi sur les 8 bits
restants.
Sur le 68K, tu as deux
signaux asynchrone de validation des deux octets du bus de données
et rien ne te garantit que les deux octets du bus soient validés en
_même_ temps. J'ai passé des jours à débugguer ce genre de problème
à l'analyseur logique !
Tu veux dire _exactement_ en même temps lors d'un accès 16 bits ? Parce
que d'après tous les chronogrammes que j'ai pu avoir sous les yeux, /UDS
et /LDS bougent en même temps.
Mais c'est vrai que les signaux du bus du
68000 sont asynchrones au sens où ils ne sont pas référencés par rapport
à une horloge externe (ils le sont forcément en interne par rapport à
l'horloge CLK, mais les relations de timing par rapport à cette horloge
sont tout sauf évidentes à déterminer). Manifestement c'était prévu pour
piloter directement de la mémoire 8 bits asynchrone classique de
l'époque, mais pour le reste ce n'était pas un cadeau pour faire les
choses proprement comme on m'avait apris à l'école (machines synchrones
de Moore, toussa). D'où l'ajout des signaux /VPA et E pour piloter les
circuits périphériques à bus synchrone de la famille 6800 d'ailleurs.
Bref, c'était jouable lorsque tu utilisais
des périphériques 8 bits ou deux mémoires 8 bits en parallèle, mais
c'était indémerdable dès que tu utilisais un CAN 12 bits (par
exemple).
Te rappelles-tu quel était le problème exactement ?
Quant à adresser des périphériques 8 bits sur un bus de 16, ça
n'avait aucune conséquence même en écriture
Ça faisait quand même des trous dans l'adressage puisqu'un périphérique
8 bits était accessible à des adresses paires consécutives s'il était
connecté sur l'octet de poids fort du bus de données et à des adresses
impaires s'il était connecté sur l'octet de poids faible. Et pour
accéder efficacement à un registre 16 bits d'un périphérique 8 bits, il
fallait utiliser une instruction spéciale MOVEP qui tenait compte de
cette particularité.
JKB a écrit :Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :Un système à base de 68000 en wrapping ? Tu as dû sacrément t'amuser...
Ouaips. La carte était un peu plus grande qu'un format A4, avec
toute une palanquée et demi de 74xx pour gérer le bus (et de drivers
de bus parce que la puissance sortante du 68K n'était pas assez
grande pour gérer les composants de gestion du bus !).
En fait je n'ai utilisé le 68000 que dans une version microncontrôleur
68302 qui intégrait toute la tuyauterie nécessaire et nécessitait très
peu de logique additionnelle pour s'interfacer avec des circuits
externes. Ça doit être pour ça que j'en ai gardé un assez bon
souvenir... :-)
Côté 6809, il y avait un 6809, un 6840, un 6850, une mémoire RAM de 2Ko,
une PROM de 8, un 74138 et un registre à décalage 8 bits, des
résistances, condensateurs, une horloge TTL 8MHz et c'est à peu près
tout...
Du grand classique, y compris le 74138 comme décodeur d'adresses...
Le registre à décalage, c'était pour l'émission/réception des données ?
Le problème est qu'on avait à l'époque (je ne sais pas si ça a
évolué depuis puisque je n'ai plus été confronté au problème) des
périphériques (incluant la mémoire) à seize bits, mais avec un
signal de validation pour tout le bus.
C'est effectivement une situation à problème, qui interdit notamment
l'écriture sur 8 bits puisque ça écrirait n'importe quoi sur les 8 bits
restants.Sur le 68K, tu as deux
signaux asynchrone de validation des deux octets du bus de données
et rien ne te garantit que les deux octets du bus soient validés en
_même_ temps. J'ai passé des jours à débugguer ce genre de problème
à l'analyseur logique !
Tu veux dire _exactement_ en même temps lors d'un accès 16 bits ? Parce
que d'après tous les chronogrammes que j'ai pu avoir sous les yeux, /UDS
et /LDS bougent en même temps.
Mais c'est vrai que les signaux du bus du
68000 sont asynchrones au sens où ils ne sont pas référencés par rapport
à une horloge externe (ils le sont forcément en interne par rapport à
l'horloge CLK, mais les relations de timing par rapport à cette horloge
sont tout sauf évidentes à déterminer). Manifestement c'était prévu pour
piloter directement de la mémoire 8 bits asynchrone classique de
l'époque, mais pour le reste ce n'était pas un cadeau pour faire les
choses proprement comme on m'avait apris à l'école (machines synchrones
de Moore, toussa). D'où l'ajout des signaux /VPA et E pour piloter les
circuits périphériques à bus synchrone de la famille 6800 d'ailleurs.Bref, c'était jouable lorsque tu utilisais
des périphériques 8 bits ou deux mémoires 8 bits en parallèle, mais
c'était indémerdable dès que tu utilisais un CAN 12 bits (par
exemple).
Te rappelles-tu quel était le problème exactement ?
Quant à adresser des périphériques 8 bits sur un bus de 16, ça
n'avait aucune conséquence même en écriture
Ça faisait quand même des trous dans l'adressage puisqu'un périphérique
8 bits était accessible à des adresses paires consécutives s'il était
connecté sur l'octet de poids fort du bus de données et à des adresses
impaires s'il était connecté sur l'octet de poids faible. Et pour
accéder efficacement à un registre 16 bits d'un périphérique 8 bits, il
fallait utiliser une instruction spéciale MOVEP qui tenait compte de
cette particularité.
Z'avez pas l'impression d'être carrément hors charte là ?
Z'avez pas l'impression d'être carrément hors charte là ?
Z'avez pas l'impression d'être carrément hors charte là ?
Si, le fil a dérivé depuis un moment. On dérange vraiment ?
Si, le fil a dérivé depuis un moment. On dérange vraiment ?
Si, le fil a dérivé depuis un moment. On dérange vraiment ?
Pascal Hambourg écrivait dans fr.comp.os.linux.configuration :En fait je n'ai utilisé le 68000 que dans une version microncontrôleur
68302 qui intégrait toute la tuyauterie nécessaire et nécessitait très
peu de logique additionnelle pour s'interfacer avec des circuits
externes. Ça doit être pour ça que j'en ai gardé un assez bon
souvenir... :-)
Certainement ;-) J'ai utilisé le 68008, c'était un bonheur à côté du
68000 !
Sur le 68K, tu as deux
signaux asynchrone de validation des deux octets du bus de données
et rien ne te garantit que les deux octets du bus soient validés en
_même_ temps. J'ai passé des jours à débugguer ce genre de problème
à l'analyseur logique !
Tu veux dire _exactement_ en même temps lors d'un accès 16 bits ? Parce
que d'après tous les chronogrammes que j'ai pu avoir sous les yeux, /UDS
et /LDS bougent en même temps.
Non. Si on regarde avec une résolution du cycle CPU, c'est vrai. Si
on regarde finement, ça ne l'est plus.
Il peut y avoir un quart ou
un demi cycle de différence selon les instructions.
Autant dire que
tu peux te retrouver avec des choses amusantes lorsque tu essayes
d'écrire en mémoire le résultat d'une lecture sur un bus qui est en
haute impédance ;-)
Le problème était simple : il fallait générer le 'CS' sur le
périphérique de sorte que le processeur ait accès en même temps à
l'ensemble des bits. Considère que tu veuilles écrire dans un
registre à 12 bits d'un CNA. Tu dois sélectionner le CNA à l'aide du
'CS' à partir du moment où les données sont valides sur les deux
octets du bus.
Pour peu que ton CNA soit aussi synchronisé par E,
c'est assez coton à faire (parce que la fenêtre temporelle de
données valides diminue sensiblement et que si tu ne fais pas gaffe
à ton programme, rien ne t'assure que tes 12 bits seront présent
simultanément sur le bus).
Pascal Hambourg écrivait dans fr.comp.os.linux.configuration :
En fait je n'ai utilisé le 68000 que dans une version microncontrôleur
68302 qui intégrait toute la tuyauterie nécessaire et nécessitait très
peu de logique additionnelle pour s'interfacer avec des circuits
externes. Ça doit être pour ça que j'en ai gardé un assez bon
souvenir... :-)
Certainement ;-) J'ai utilisé le 68008, c'était un bonheur à côté du
68000 !
Sur le 68K, tu as deux
signaux asynchrone de validation des deux octets du bus de données
et rien ne te garantit que les deux octets du bus soient validés en
_même_ temps. J'ai passé des jours à débugguer ce genre de problème
à l'analyseur logique !
Tu veux dire _exactement_ en même temps lors d'un accès 16 bits ? Parce
que d'après tous les chronogrammes que j'ai pu avoir sous les yeux, /UDS
et /LDS bougent en même temps.
Non. Si on regarde avec une résolution du cycle CPU, c'est vrai. Si
on regarde finement, ça ne l'est plus.
Il peut y avoir un quart ou
un demi cycle de différence selon les instructions.
Autant dire que
tu peux te retrouver avec des choses amusantes lorsque tu essayes
d'écrire en mémoire le résultat d'une lecture sur un bus qui est en
haute impédance ;-)
Le problème était simple : il fallait générer le 'CS' sur le
périphérique de sorte que le processeur ait accès en même temps à
l'ensemble des bits. Considère que tu veuilles écrire dans un
registre à 12 bits d'un CNA. Tu dois sélectionner le CNA à l'aide du
'CS' à partir du moment où les données sont valides sur les deux
octets du bus.
Pour peu que ton CNA soit aussi synchronisé par E,
c'est assez coton à faire (parce que la fenêtre temporelle de
données valides diminue sensiblement et que si tu ne fais pas gaffe
à ton programme, rien ne t'assure que tes 12 bits seront présent
simultanément sur le bus).
Pascal Hambourg écrivait dans fr.comp.os.linux.configuration :En fait je n'ai utilisé le 68000 que dans une version microncontrôleur
68302 qui intégrait toute la tuyauterie nécessaire et nécessitait très
peu de logique additionnelle pour s'interfacer avec des circuits
externes. Ça doit être pour ça que j'en ai gardé un assez bon
souvenir... :-)
Certainement ;-) J'ai utilisé le 68008, c'était un bonheur à côté du
68000 !
Sur le 68K, tu as deux
signaux asynchrone de validation des deux octets du bus de données
et rien ne te garantit que les deux octets du bus soient validés en
_même_ temps. J'ai passé des jours à débugguer ce genre de problème
à l'analyseur logique !
Tu veux dire _exactement_ en même temps lors d'un accès 16 bits ? Parce
que d'après tous les chronogrammes que j'ai pu avoir sous les yeux, /UDS
et /LDS bougent en même temps.
Non. Si on regarde avec une résolution du cycle CPU, c'est vrai. Si
on regarde finement, ça ne l'est plus.
Il peut y avoir un quart ou
un demi cycle de différence selon les instructions.
Autant dire que
tu peux te retrouver avec des choses amusantes lorsque tu essayes
d'écrire en mémoire le résultat d'une lecture sur un bus qui est en
haute impédance ;-)
Le problème était simple : il fallait générer le 'CS' sur le
périphérique de sorte que le processeur ait accès en même temps à
l'ensemble des bits. Considère que tu veuilles écrire dans un
registre à 12 bits d'un CNA. Tu dois sélectionner le CNA à l'aide du
'CS' à partir du moment où les données sont valides sur les deux
octets du bus.
Pour peu que ton CNA soit aussi synchronisé par E,
c'est assez coton à faire (parce que la fenêtre temporelle de
données valides diminue sensiblement et que si tu ne fais pas gaffe
à ton programme, rien ne t'assure que tes 12 bits seront présent
simultanément sur le bus).
JKB a écrit :Il peut y avoir un quart ou
un demi cycle de différence selon les instructions.
Cycle d'horloge d'entrée CLK ? Cela correspond à peu près aux timings de
la version à 8 MHz dans le manuel (seconde source Thomson-Efcis, en
français s'il vous plaît) que j'ai ressorti.
- période d'horloge : 125 ns min
- de l'horloge haute à AS, DS bas : 60 ns max
- de l'horloge basse à AS, DS haut : 40 ns max
Le décalage entre /UDS et /LDS peut donc atteindre au maximum 60 ns,
soit quasiment la moitié du cycle.
Autant dire que
tu peux te retrouver avec des choses amusantes lorsque tu essayes
d'écrire en mémoire le résultat d'une lecture sur un bus qui est en
haute impédance ;-)
Cela ne devrait pas arriver si l'écriture est validée par la combinaison
des deux signaux de validation.
Le problème était simple : il fallait générer le 'CS' sur le
périphérique de sorte que le processeur ait accès en même temps à
l'ensemble des bits. Considère que tu veuilles écrire dans un
registre à 12 bits d'un CNA. Tu dois sélectionner le CNA à l'aide du
'CS' à partir du moment où les données sont valides sur les deux
octets du bus.
Oui.Pour peu que ton CNA soit aussi synchronisé par E,
c'est assez coton à faire (parce que la fenêtre temporelle de
données valides diminue sensiblement et que si tu ne fais pas gaffe
à ton programme, rien ne t'assure que tes 12 bits seront présent
simultanément sur le bus).
Je suis un peu surpris car E n'est utilisé que dans un cycle de type
6800, plus long qu'un cycle d'écriture ordinaire (10 cycles d'horloge
contre 4 minimum). Et d'après le diagramme des temps que j'ai sous les
yeux E n'est actif que lorsque les données sont disponibles en sortie.
La fenêtre de validité des données devrait donc être au moins de la
largeur de l'impulsion positive de E.
JKB a écrit :
Il peut y avoir un quart ou
un demi cycle de différence selon les instructions.
Cycle d'horloge d'entrée CLK ? Cela correspond à peu près aux timings de
la version à 8 MHz dans le manuel (seconde source Thomson-Efcis, en
français s'il vous plaît) que j'ai ressorti.
- période d'horloge : 125 ns min
- de l'horloge haute à AS, DS bas : 60 ns max
- de l'horloge basse à AS, DS haut : 40 ns max
Le décalage entre /UDS et /LDS peut donc atteindre au maximum 60 ns,
soit quasiment la moitié du cycle.
Autant dire que
tu peux te retrouver avec des choses amusantes lorsque tu essayes
d'écrire en mémoire le résultat d'une lecture sur un bus qui est en
haute impédance ;-)
Cela ne devrait pas arriver si l'écriture est validée par la combinaison
des deux signaux de validation.
Le problème était simple : il fallait générer le 'CS' sur le
périphérique de sorte que le processeur ait accès en même temps à
l'ensemble des bits. Considère que tu veuilles écrire dans un
registre à 12 bits d'un CNA. Tu dois sélectionner le CNA à l'aide du
'CS' à partir du moment où les données sont valides sur les deux
octets du bus.
Oui.
Pour peu que ton CNA soit aussi synchronisé par E,
c'est assez coton à faire (parce que la fenêtre temporelle de
données valides diminue sensiblement et que si tu ne fais pas gaffe
à ton programme, rien ne t'assure que tes 12 bits seront présent
simultanément sur le bus).
Je suis un peu surpris car E n'est utilisé que dans un cycle de type
6800, plus long qu'un cycle d'écriture ordinaire (10 cycles d'horloge
contre 4 minimum). Et d'après le diagramme des temps que j'ai sous les
yeux E n'est actif que lorsque les données sont disponibles en sortie.
La fenêtre de validité des données devrait donc être au moins de la
largeur de l'impulsion positive de E.
JKB a écrit :Il peut y avoir un quart ou
un demi cycle de différence selon les instructions.
Cycle d'horloge d'entrée CLK ? Cela correspond à peu près aux timings de
la version à 8 MHz dans le manuel (seconde source Thomson-Efcis, en
français s'il vous plaît) que j'ai ressorti.
- période d'horloge : 125 ns min
- de l'horloge haute à AS, DS bas : 60 ns max
- de l'horloge basse à AS, DS haut : 40 ns max
Le décalage entre /UDS et /LDS peut donc atteindre au maximum 60 ns,
soit quasiment la moitié du cycle.
Autant dire que
tu peux te retrouver avec des choses amusantes lorsque tu essayes
d'écrire en mémoire le résultat d'une lecture sur un bus qui est en
haute impédance ;-)
Cela ne devrait pas arriver si l'écriture est validée par la combinaison
des deux signaux de validation.
Le problème était simple : il fallait générer le 'CS' sur le
périphérique de sorte que le processeur ait accès en même temps à
l'ensemble des bits. Considère que tu veuilles écrire dans un
registre à 12 bits d'un CNA. Tu dois sélectionner le CNA à l'aide du
'CS' à partir du moment où les données sont valides sur les deux
octets du bus.
Oui.Pour peu que ton CNA soit aussi synchronisé par E,
c'est assez coton à faire (parce que la fenêtre temporelle de
données valides diminue sensiblement et que si tu ne fais pas gaffe
à ton programme, rien ne t'assure que tes 12 bits seront présent
simultanément sur le bus).
Je suis un peu surpris car E n'est utilisé que dans un cycle de type
6800, plus long qu'un cycle d'écriture ordinaire (10 cycles d'horloge
contre 4 minimum). Et d'après le diagramme des temps que j'ai sous les
yeux E n'est actif que lorsque les données sont disponibles en sortie.
La fenêtre de validité des données devrait donc être au moins de la
largeur de l'impulsion positive de E.
Ça, c'est la théorie. Lorsque tu cascades plusieurs composants de la
famille 74, tu as très vite consommé ta fenêtre de validité en temps
de commutation de la logique de validation. Chaque fois que tu
rajoutes un signal, il faut compter avec le décodage de ce signal.
Je reprends tes chiffres (j'ai la flemme de chercher ma doc Hitachi
qui plus est en anglais). Le décalage peut aller jusqu'à 60 ns sur
une période de 125 ns. C'est énorme. Il y a quinze ans, les mémoires
statiques standard avaient un temps de cycle de 200 ns.
J'avais réussi
à faire acheter des mémoires statiques de 60 ns (2 * 64 Ko) mais ça
ne passait pas (il y avait des problèmes d'écriture), puis a faire
acheter des mémoires à 12 ns d'accès en écriture et je me
souviens que ça coûtait une petite fortune (mais ça marchait).
J'ai toujours utilisé E pour synchroniser le bus externe à la façon
du 6809. Il y avait une couillonnade que je viens de vérifier dans
le databook du 6809 (Motorola, première source ;-) ). E est valide
sur un front et non sur un niveau. Donc la commutation de E ne
t'assure la validité des données que sur le front et non sur la
durée du niveau. C'est à toi de maintenir tes données dans un driver
de bus si tu en as besoin.
Le E du 68K étant compatible avec le E du
6809, je suppose qu'il en est de même (les interfaces de type 6821,
6840, 6850 attendent des fronts).
Je propose d'arrêter à parce qu'on est passablement hors charte...
Ça, c'est la théorie. Lorsque tu cascades plusieurs composants de la
famille 74, tu as très vite consommé ta fenêtre de validité en temps
de commutation de la logique de validation. Chaque fois que tu
rajoutes un signal, il faut compter avec le décodage de ce signal.
Je reprends tes chiffres (j'ai la flemme de chercher ma doc Hitachi
qui plus est en anglais). Le décalage peut aller jusqu'à 60 ns sur
une période de 125 ns. C'est énorme. Il y a quinze ans, les mémoires
statiques standard avaient un temps de cycle de 200 ns.
J'avais réussi
à faire acheter des mémoires statiques de 60 ns (2 * 64 Ko) mais ça
ne passait pas (il y avait des problèmes d'écriture), puis a faire
acheter des mémoires à 12 ns d'accès en écriture et je me
souviens que ça coûtait une petite fortune (mais ça marchait).
J'ai toujours utilisé E pour synchroniser le bus externe à la façon
du 6809. Il y avait une couillonnade que je viens de vérifier dans
le databook du 6809 (Motorola, première source ;-) ). E est valide
sur un front et non sur un niveau. Donc la commutation de E ne
t'assure la validité des données que sur le front et non sur la
durée du niveau. C'est à toi de maintenir tes données dans un driver
de bus si tu en as besoin.
Le E du 68K étant compatible avec le E du
6809, je suppose qu'il en est de même (les interfaces de type 6821,
6840, 6850 attendent des fronts).
Je propose d'arrêter à parce qu'on est passablement hors charte...
Ça, c'est la théorie. Lorsque tu cascades plusieurs composants de la
famille 74, tu as très vite consommé ta fenêtre de validité en temps
de commutation de la logique de validation. Chaque fois que tu
rajoutes un signal, il faut compter avec le décodage de ce signal.
Je reprends tes chiffres (j'ai la flemme de chercher ma doc Hitachi
qui plus est en anglais). Le décalage peut aller jusqu'à 60 ns sur
une période de 125 ns. C'est énorme. Il y a quinze ans, les mémoires
statiques standard avaient un temps de cycle de 200 ns.
J'avais réussi
à faire acheter des mémoires statiques de 60 ns (2 * 64 Ko) mais ça
ne passait pas (il y avait des problèmes d'écriture), puis a faire
acheter des mémoires à 12 ns d'accès en écriture et je me
souviens que ça coûtait une petite fortune (mais ça marchait).
J'ai toujours utilisé E pour synchroniser le bus externe à la façon
du 6809. Il y avait une couillonnade que je viens de vérifier dans
le databook du 6809 (Motorola, première source ;-) ). E est valide
sur un front et non sur un niveau. Donc la commutation de E ne
t'assure la validité des données que sur le front et non sur la
durée du niveau. C'est à toi de maintenir tes données dans un driver
de bus si tu en as besoin.
Le E du 68K étant compatible avec le E du
6809, je suppose qu'il en est de même (les interfaces de type 6821,
6840, 6850 attendent des fronts).
Je propose d'arrêter à parce qu'on est passablement hors charte...
JKB a écrit :
Lorsque tu as programmé des trucs temps réel sur des 6809, tu
utilisais en _même_ temps U et S (le pendant de SSP et USP).
Dans mon souvenir, le registre U du 6809 n'est pas le pendant du
registre USP du 68000. U est le pointeur de pile "utilisateur" au sens
où comme tu le dis l'utilisateur peut en faire ce qu'il veut, comme les
registres d'index X et Y mais avec en plus le support des instructions
PSH et PUL pour empiler/dépiler le contenu de registres. En revanche USP
est le pointeur de pile utilisateur au sens où c'est le pointeur de pile
système SP (utilisé pour les appels de sous-programme, comme le registre
S du 6809) actif lorsque le processeur est en mode utilisateur, par
opposition à SSP qui est le pointeur de pile système SP actif lorsque le
processeur est en mode superviseur. Si tu as besoin de l'équivalent de U
sur 68000, tu peux utiliser un registre d'adresse An quelconque autre
que A7 et les instructions PSH et PUL du 6809 peuvent être remplacées
par l'instruction MOVEM du 68000.
JKB a écrit :
Lorsque tu as programmé des trucs temps réel sur des 6809, tu
utilisais en _même_ temps U et S (le pendant de SSP et USP).
Dans mon souvenir, le registre U du 6809 n'est pas le pendant du
registre USP du 68000. U est le pointeur de pile "utilisateur" au sens
où comme tu le dis l'utilisateur peut en faire ce qu'il veut, comme les
registres d'index X et Y mais avec en plus le support des instructions
PSH et PUL pour empiler/dépiler le contenu de registres. En revanche USP
est le pointeur de pile utilisateur au sens où c'est le pointeur de pile
système SP (utilisé pour les appels de sous-programme, comme le registre
S du 6809) actif lorsque le processeur est en mode utilisateur, par
opposition à SSP qui est le pointeur de pile système SP actif lorsque le
processeur est en mode superviseur. Si tu as besoin de l'équivalent de U
sur 68000, tu peux utiliser un registre d'adresse An quelconque autre
que A7 et les instructions PSH et PUL du 6809 peuvent être remplacées
par l'instruction MOVEM du 68000.
JKB a écrit :
Lorsque tu as programmé des trucs temps réel sur des 6809, tu
utilisais en _même_ temps U et S (le pendant de SSP et USP).
Dans mon souvenir, le registre U du 6809 n'est pas le pendant du
registre USP du 68000. U est le pointeur de pile "utilisateur" au sens
où comme tu le dis l'utilisateur peut en faire ce qu'il veut, comme les
registres d'index X et Y mais avec en plus le support des instructions
PSH et PUL pour empiler/dépiler le contenu de registres. En revanche USP
est le pointeur de pile utilisateur au sens où c'est le pointeur de pile
système SP (utilisé pour les appels de sous-programme, comme le registre
S du 6809) actif lorsque le processeur est en mode utilisateur, par
opposition à SSP qui est le pointeur de pile système SP actif lorsque le
processeur est en mode superviseur. Si tu as besoin de l'équivalent de U
sur 68000, tu peux utiliser un registre d'adresse An quelconque autre
que A7 et les instructions PSH et PUL du 6809 peuvent être remplacées
par l'instruction MOVEM du 68000.
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce que
tu ne sais jamais vraiment quand tes objets vont être libérés...).
?
Tes données sont libérées quand elles ne sont plus référencées.
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce que
tu ne sais jamais vraiment quand tes objets vont être libérés...).
?
Tes données sont libérées quand elles ne sont plus référencées.
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce que
tu ne sais jamais vraiment quand tes objets vont être libérés...).
?
Tes données sont libérées quand elles ne sont plus référencées.
L'instruction MOVEM sert à transférer un sous-ensemble quelconque des 16
registres de donnée et d'adresse depuis ou vers la mémoire. Combinée
avec les modes d'adressage que tu cites, elle permet d'émuler les
instructions d'empilage/dépilage multiple PSH et PUL du 6809 (sauf pour
le registre d'état SR ou de code condition CCR qui nécessitent des
instructions MOVE spéciales).
L'instruction MOVEM sert à transférer un sous-ensemble quelconque des 16
registres de donnée et d'adresse depuis ou vers la mémoire. Combinée
avec les modes d'adressage que tu cites, elle permet d'émuler les
instructions d'empilage/dépilage multiple PSH et PUL du 6809 (sauf pour
le registre d'état SR ou de code condition CCR qui nécessitent des
instructions MOVE spéciales).
L'instruction MOVEM sert à transférer un sous-ensemble quelconque des 16
registres de donnée et d'adresse depuis ou vers la mémoire. Combinée
avec les modes d'adressage que tu cites, elle permet d'émuler les
instructions d'empilage/dépilage multiple PSH et PUL du 6809 (sauf pour
le registre d'état SR ou de code condition CCR qui nécessitent des
instructions MOVE spéciales).
Le Fri, 29 Jan 2010 15:20:10 +0100, Yliur a écrit :
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référenc ées.
Encore faut-il qu'elles aient été déréférencées correctement. ..
Le Fri, 29 Jan 2010 15:20:10 +0100, Yliur a écrit :
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référenc ées.
Encore faut-il qu'elles aient été déréférencées correctement. ..
Le Fri, 29 Jan 2010 15:20:10 +0100, Yliur a écrit :
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référenc ées.
Encore faut-il qu'elles aient été déréférencées correctement. ..
