ATARI 800XL - Pas de message READY

[hlide]

Ah mais moi je ne cherchais pas le source pour le 800XL. Ce que je voulais, c'est récupérer les outils pour ne pas GALérer avec les PAL d'Atmel et PALier avec les GAL de Lattice si ça s'avère plus simple à programmer avec le TL866 que j'ai.

[nicolho]

Ah bah ça s'adressait pas spécialement à toi, mais désolé si c'est pas ce que tu cherchais, pas de problème, enfin tu m'excuseras, j'en parlais vu que, à la base, ce fil est consacré à la réparation de Bruno et son 800XL, son MMU cassé et peut-être défaillant, tout ça... (et il s'agit pas du code source, mais du JEDEC qui est la version "compilée" à programmer).

Sinon, l'Atmel ATF16V8 est apparemment supporté par le TL866, on trouve de nombreux témoignages positifs à ce sujet, mais c'est peut-être pas ton expérience ? Dans ce cas tu pourrais nous dire en quoi c'est une GALère pour toi ?

[atariman]

Normalement le jedec d'un pal ne peut pas être utilisé pour griller un GAL
Un PAL a une sortie plutot fixe definie par sa référence...

la sortie d'un GAL est configurable

Par contre normalement il suffit de recompiler en changeant le device pour que ca fonctionne
le GAL été prévu comme un replacement configurable et reprogrammable du PAL

je me rapelle quand dans les années 80 on utilisais plein de barettes de PAL (chaque essai coutait un PAL)...

Le début de code VHDL ne fonctionne pas et ne fonctionneras pas
J'en ai commencé un autre basé sur le code pour le PAL
(il est d'ailleurs plus coherent que le code trouvé pour un GAL)

[atariman]

Pour programmer les GAL Atmel je me suis acheté un G540 (la plaie il est 32 bits)
J'ai du le faire fonctionner sur un portable sous windows 10 32bits

Mes essai on apparement réussi…
Mais je n'ai pas encore monté la chaine complete pour produire des GAL atmels...

J'utilise le G540 via un hub USB alimenté (dans le passé j'ai eu plein de problemes avec les alim via USB)

[atariman]

[message approuvé a posteriori donc il apparaît avec un décalage]

J'ai produit un VHDL et un jedec…
pas encore testé….

Voila le code VHDL

Code : Tout sélectionner

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

entity mmugal is
	PORT (
		a       	: in   std_logic_vector(15 downto 11);
		mapx	: in   std_logic;
		rd4		: in   std_logic;
		rd5		: in   std_logic;
		ren		: in   std_logic;
		ref		: in   std_logic;
		mpd		: in   std_logic;	
		be		: in   std_logic;

		s5      	: out  std_logic;
		basic   	: out  std_logic;
		os      	: out  std_logic;
		ci		: out  std_logic;
		io      	: out  std_logic;
		s4      	: out  std_logic
	);

	attribute LOC : string;

	attribute LOC of a		: signal is "P5,P4,P3,P2,P1";
	attribute LOC of mapx	: signal is "P6";
	attribute LOC of rd4		: signal is "P7";
	attribute LOC of rd5		: signal is "P8";
	attribute LOC of ren		: signal is "P9";
	attribute LOC of ref		: signal is "P11";
	attribute LOC of mpd		: signal is "P14";
	attribute LOC of be		: signal is "P18";

	attribute LOC of s5		: signal is "P12";
	attribute LOC of basic	: signal is "P13";
	attribute LOC of os		: signal is "P15";
	attribute LOC of ci		: signal is "P16";
	attribute LOC of io		: signal is "P17";
	attribute LOC of s4		: signal is "P19";

end;

architecture behavioral of mmugal is
	signal zos : std_logic;
begin



-- S4      = !A13 & !A14 & A15 & RD4 & REF;/* RD4 and addresses $8000-$9FFF */

	s4 <= '0' when (a(15 downto 13) = "100") and (ref = '1') and (rd4 = '1') else '1';


-- S5      = A13 & !A14 & A15 & RD5 & REF;	/* RD5 and addresses $A000-$BFFF */

	s5 <= '0' when (a(15 downto 13) = "101") and (ref = '1') and (rd5 = '1') else '1';


-- IO      = A12 & !A11 & !A13 & A14 & A15 & REF;   /* addresses $D000-$D7FF*/

	io <= '0' when (a(15 downto 11) = "11010") and (ref = '1') else '1';

-- OS      = A13 & A14 & A15 & REN & REF		/* addresses $E000-$FFFF */
--         # !A12 & !A13 & A14 & A15 & REN & REF   /* addresses $C000-$CFFF */
--        # A12 & A11 & !A13 & A14 & A15 & MPD & REN & REF /* addresses $D800-$DFFF */
--        # A12 & !A11 & !A13 & A14 & !A15 & !MAP & REN & REF; /* addresses $5000-$5800 - mapped */

	zos  <= '0' when ((a(15 downto 13) = "111")		and (ren = '1')	and (ref = '1'))                 		or
	        	        ((a(15 downto 12) = "1100")	and (ren = '1')	and (ref = '1')) 				or
				((a(15 downto 11) = "01010")	and (mpd = '1')	and (ren = '1')	and (ref = '1'))	or
				((a(15 downto 11) = "01010")	and (mapx = '0')	and (ren = '1')	and (ref = '1')) 
	    	   else '1';

	os   <=  zos;


-- CI      = !A13 & !A14 & A15 & RD4 & REF		/* right cart. */
--        # A13 & !A14 & A15 & RD5 & REF		/* left cart. */
--        # A13 & !BE & !A14 & A15 & !RD5 & REF	/* BE and $A000-$BFFF */
--        # OS					/* OS addresses */
--        # A12 & !A11 & !A13 & A14 & A15 & REF	/* I/O addresses */
--        # !REF;					/* memory refresh */

	ci <= '0' when  ((a(15 downto 13) = "100")		and (rd4 = '1')	and (ref = '1'))				or
			      ((a(15 downto 13) = "101")		and (rd5 = '0')	and (ref = '1'))				or
	       		      ((a(15 downto 13) = "101")		and (rd5 = '0')	and (be = '0')	and (ref = '1'))	or
			      ((a(15 downto 11) = "11010")	and (ref = '1'))							or
			      (ref = '0')														or
			      (zos = '1')
		  else '1';	

--BASIC   = A13 & !BE & !A14 & A15 & !RD5 & REF;   /* BE and $A000-$BFFF */

	basic <= '0' when a(15 downto 13) = "101" and (rd5 = '0') and (ref = '1') and (be = '0') else '1';

end behavioral;

l'optimisation faite par l'optimiseur de ISPLever semble assez feroce…

voila le JEDEC

Code : Tout sélectionner

ispLEVER Classic 2.0.00.17.20.15 Lattice Semiconductor Corp.
JEDEC file for: P16V8AS V9.0
Created on: Wed Nov 07 22:51:47 2018

*
QP20* QF2194* QV0* F0*
 X0*
NOTE DEVICE NAME: GAL16V8D-7LP*
NOTE Table of pin names and numbers*
NOTE PINS a_15_:5 mapx:6 rd4:7 rd5:8 ren:9 ref:11 mpd:14 a_14_:4 be:18*
NOTE PINS a_13_:3 s5:12 a_12_:2 basic:13 a_11_:1 os:15 ci:16 io:17 s4:19*
L0000 11111011101101111111011111111101*
L0512 01101011011101111111111111111101*
L0768 11110111011101111111111111110101*
L0800 10111111011101111111111111110101*
L0832 01101011011110111011111111110101*
L0864 01101011011110111101111111110101*
L1024 11110111011101111111111111110101*
L1056 10111111011101111111111111110101*
L1088 01101011011110111011111111110101*
L1120 01101011011110111101111111110101*
L1536 11110111101001111111111110111101*
L1792 11110111101101111111111101111101*
L2048 00010000*
L2121 1*
L2125 1*
L2128 1111111111111111111111111111111111111111111111111111111111111111*
L2192 1*
C320C*
D846

JEDEC format "brief' les lignes de 0 ne sont as includes...

Demain je cramerais un GAL et je ferais un test....

[hlide]

Ah bah ça s'adressait pas spécialement à toi, mais désolé si c'est pas ce que tu cherchais, pas de problème

Pas de soucis, je ne répondais qu'à ton "Bon, vous cassez pas [...]". Rien de méchant.

Sinon, l'Atmel ATF16V8 est apparemment supporté par le TL866, on trouve de nombreux témoignages positifs à ce sujet, mais c'est peut-être pas ton expérience ? Dans ce cas tu pourrais nous dire en quoi c'est une GALère pour toi ?

Ben tant mieux. Je vais me tourner vers les GAL puisqu'ils sont reconfigurables contrairement aux PAL. Je débute dans l'histoire et je lisais vos dernier posts. Ça fait un moment que je pensais me pencher sur un PAL pour prendre en compte des décodages, mais je ne m'étais jamais vraiment poser la question des différences entre PLA, PAL, GAL et CPLD. Et pour GALérer et PALier c'est plus un exercice de style qu'autre chose - pas besoin d'en faire un foin. Si je peux me rattraper avec les GAL alors que les PAL sont foutus une fois programmés, ça me ferait bien chier de foutre en l'air un stock de PAL dans la mise au point.

[atariman]

En gros:

Une PROM a une matrice d'entrée fixe (c'est le décodage d'adresse)
et a une matrice de sortie programmable (les données que l'on met dedans)

une EPROM/EEPROM c'est comme une prom mais reprogrammable

Un PAL a une matrice d'entrés programmable et une matrice de sortie fixe (combinatoire ou registre)

Sur le PLA je crois que les 2 sont programmable (mais je ne connais pas trop les détails)

Un GAL a une patrice d'entrée programmable et une matrice de sortie fixe mais l'etage final de sortie est configurable
combinatoire ou registre (ce qui permet d'eviter d'avoir plein de type differents en fonction de l'utilisation
c'est des bits de config qui definissent comment la sortie se comporte
(en quelque sorte c'est l'embryon des macrocells de CPLD)

Il y a un autre type de produit (la serie Mach de Lattice)
mach130 / mach131 bien connu par les fabriquants de decodeur canal plus pirate
a l'interieur en quelque sorte il y 4 GAL (c'est la version lite du CPLD)

Un CPLD est une sorte de gros Mach avec une sortie configurable assez évoluée, la macrocell
le meilleur CPLD que j'ai trouvé c'est le Max7000S d'Altera il est compatible 5v se trouve encore facilement
a une possibilité de sortie en collecteur ouvert
il s'intégre a merveille dans des developement concu pour d'ancien hardware...
exemple: j'ai concu un MMU pour MPF1B contenant plusieurs registre pour configurer le mapping memoire base sur un 7064S
en fonction de la config on a un MPF1B de base ou un mapping mémoire compatible CP/M ou MP/M
Pour programmer un max 7000 il faut utiliser Quartus 13 (il n'est plus supporté par les versions ultérieures)

le FPGA est assez different il est composé de different type d'élément SLICE/EBR/PLL/DCM/DSP/...
SLICE: groupe de base composé de LUT et DFF
EBR: bloc mémoire
PLL: phase locked loop (permet de creer des frequences)
DCM: comme en pll mais en digital (a de serieuse limitations sur les possibilités)
DSP: bloc pour faire des calculs
...: certains constructeurs ajoutent d'autre fonctionalités

En prime certain possedent des bloc de sorties varies comme par exemple des SERDES
le bus PCI par exemple utilise des SERDES (pour sérialiser / désérialiser les données)
la plupart possède un mode de fonctionnement pour des paires différentielles...

Le mode de fonctionnement etant different il est plus difficile d'écrire du code pour un CPLD que pour un FPGA
sur le CPLD les resources sont plus limités et certaines constructions ne passent pas

Attention les termes utilisé pour les FPGA peuvent être très different d'un constructeur a l'autre


Le FPGA a un incovenient, il ne contient pas sa config, il la charge sur un chip externe
il n'est donc pas pret immediatement, il faut le syncrhoniser

Un CPLD lui contient sa config, il est donc immediatement opérationnel

Certains constructeur comme ACTEL et je crois Lattice fournisse maintenant des FPGA avec la memore de config
interne en EEPROM (je n'ai pas les détails)

Sur les chips moderne la difference entre CPLD et FPGA s'ammenuise de plus en plus et en quelque sorte
le CPLD devient un petit FPGA (comme la serie MachX0 / MachX02 / MachX03)
le machX02 contient même PLL et EBR
si vous voulez jouer avec ces produits: https://tinyfpga.com/

[nicolho]

Bon bah c'est cool, tout ça, merci d'avoir publié ta "traduction" en VHDL. Comme je voulais m'y mettre aussi, j'ai finalement pris le temps de regarder vraiment le code source disponible, ça ressemble à du chinois mais en fait c'est simple et très clair, surtout que c'est parfaitement commenté, même le peu de grammaire nécessaire est expliquée dedans (je vois que tu as justement reproduit code et commentaires du fichier source pour PAL dans ton code, certainement comme canevas, c'est pas mal ce côté "livre bilingue/pierre de Rosette").

D'ailleurs, le code source pour GAL me semble également correct, en tout cas identique dans ses combinaisons logiques (en même temps je pense pas que la page dédiée au MMU aurait laissé depuis 20 ans des liens vers du code erroné, surtout aussi concis).

Donc en effet, c'est du simple adressage (ça éclaire d'ailleurs parfaitement cet aspect du 800XL) rien de bien folichon à adapter pour n'importe quel langage de description de matériel (HDL) même pour un débutant, et en tout cas, ce type de petit projet, c'est certainement une bonne introduction pratique aux circuits logiques programmables, ces SPLD étant suffisamment simples pour qu'on puisse en comprendre tous les tenants et aboutissants.

Pour le JEDEC, on a déjà celui publié il y a des années sur le forum Atariage et que j'ai posté hier, mais le faire soi-même complètement, c'est bien aussi. De mon côté, je vais essayer de m'acheter un GAL, peut-être dans la journée, voir si j'arrive à le programmer, avant de le tester.

[atariman]

Pour le moment le gal que j'ai produit avec le VHDL ne fonctionne pas (écran noir)
je vais devoir revoir le code... et peut être trouver d'autres info specifiques au 800xl

Je doute que ce fichier palasm soit pour le 800xl il parle d'une cartouche droite et gauche or mon 800xl ne supporte qu'une seule cartouche

Je pense que le probleme est dans CI

J'ai aussi essayé de copier le PAL dans le GAL ca ne fonctionne pas

Dans la boite ou je me trouvais dans les années 80, l'atari etait considéré comme une machine evil
en fait c'est une machine super bien concue, sur certain point mieux que le commodore 64

C'est une machine super sympa a découvrir comme pour le pet et le c64 il y a vraiment du genie dans cette machine

Pour en revenir a PLD de toutes sortes, finalement si on commence par les plus simple (les GAL) (les PAL coutent trop cher)
Ce n'est pas si compliqué a utilisé puis aprés on peut passer au CPLD puis au FPGA
De toute facon il ne faut pas réver les prix des FPGA haut de gamme les mettent hors de portée des hobbyistes
Mais on peut bien s'amuser avec CPLD / Cyclones / Spartans / MachX0 / MachX02...

[atariman]

J'ai testé le jedec de Bob Wooley trouvé sur le web
ce n'est pas un jedec pour PAL mais pour GAL (probablement obtenu a partir du PAL)

La copie de PAL dans le GAL ne fonctionne pas
Par contre ce jedec fonctionne

Il va me permettre de finaliser le vhdl en comparant ce jedec avec celui que j'obtient...

J'ai trouvé la datasheet du PAL 16V8 c'est interessant il contient un bloc de sortie configurable V = versatile ?
peut être l'element manquand entre le PAL et le GAL ?
Je n'ai jamais connu ceux la je n'avais utilisé que des pal L et R

Il faudrait comparer cette datasheet a celle du GAL 16v8
Finalement les jedec sont peut être compatible mais dans ce cas pourquoi la copie ne fonctionne pas

[romu]

Je doute que ce fichier palasm soit pour le 800xl il parle d'une cartouche droite et gauche or mon 800xl ne supporte qu'une seule cartouche

En effet c'est l'Arari 800 qui a 2 ports cartouche.

[nicolho]

J'ai testé le jedec de Bob Wooley trouvé sur le web
ce n'est pas un jedec pour PAL mais pour GAL (probablement obtenu a partir du PAL)

Euh non, ça a déjà été dit dans un message posté hier ( https://www.youtube.com/watch?v=jNnwgCQajFg ) et pour rendre à César ce qui est à César, plus précisément c'est un JEDEC fourni par HiassofT, et "probablement", je vois pas, puisqu'il avait clairement précisé que c'était adapté du code source PAL de Bob Wooley, mais que ce fichier était bien destiné à programmer un GAL : viewtopic.php?f=1&t=9412&start=15#p144708

Enfin puisque, apparemment, la priorité c'est de raconter sa vie, j'ai l'honneur de vous faire part de l'heureux achat ce jour de mon premier GAL dans un magasin près de chez moi ! (oui, c'est du luxe de pouvoir se fournir à deux pas... et le prix "magasin" aussi ). C'est Bibi qui va pouvoir en faire des trucs supers maintenant !

[edit] suite de mon autobiographie : ce matin, j'ai sorti le TL866, téléchargé et installé son logiciel, s'en est suivie la mise à jour du firmware du programmeur, proposée au lancement. Quelques recherches pour vérifier les bonnes cases à (dé)cocher après avoir sélectionné le modèle exact du GAL utilisé puis le JEDEC prévu pour refaire le MMU (celui récupéré sur atariage, voir messages précédents), en deux temps trois mouvements le GAL était programmé et vérifié, finalement avec les éléments requis sous la main, tout ça n'a nécessité que quelques minutes (il me reste à le tester).

[Bruno33]

J’ai reçu hier midi du Bénélux (rewingames.eu) puis installé dans la foulée le fameux MMU et j’ai retrouvé le même résultat à l’écran qu’auparavant avant que je ne casse avec maladresse les 2 pattes du mien.. .
J’ai ensuite réalisé les tests proposés par Nicolho et voici les résultats obtenus :
Pour toutes les mesures qui suivent, j’ai pris la masse (- du voltmètre) sur la patte 10 (GND) du MMU
- Machine sous tension, j’ai 5V sur la patte 13 (BASIC) du MMU, cartouche ou pas.
- Sur la patte 8 (RDS) du MMU, j’ai 5V si la cartouche est insérée, j’ai 0,6V sans la cartouche.
- Sur la patte 20 de la ROM, j’ai 1,1V sans la cartouche.
- En démarrant l’ordinateur avec la touche OPTION enfoncée, j’ai 5V sur la patte 6 (MAP) du MMU.
Quelles conclusions en tirer ? A part faire un trou dans le sable, y placer l'ordinateur et reboucher le tout !
Au plaisir de vous lire.
Bruno

[nicolho]

Bonjour ! Donc tu as bien un nouveau MMU de XL, je me demande pourquoi on est tout de suite parti du principe que tu avais commandé un PAL vierge...
En tout cas, merci d'avoir déjà fait ces premiers relevés (d'autres à venir !), je sais que ce n'est pas toujours évident, bien repérer les pattes, placer les sondes sans bouger, etc.…surtout machine sous tension.

- Machine sous tension, j’ai 5V sur la patte 13 (BASIC) du MMU, cartouche ou pas.

Alors le signal /BASIC sur cette patte sous entends, par le 'slash' qui le précède, qu'il est actif à 0V, ça correspond sur la Rom BASIC (U4) à l'activation de la puce par son entrée /CS , qui veut dire Chip Select, pareil, on voit à son nom (encore le slash qui précède) qu'on active la puce en le mettant au niveau bas, 0v (à la masse)
Moralité : si ce signal est à 5V, la rom Basic est encore désactivée à la fin du "démarrage".

- Sur la patte 8 (RDS) du MMU, j’ai 5V si la cartouche est insérée, j’ai 0,6V sans la cartouche.

C'est normal, ça rejoint ce que j'avais dit, je cite : "(…) si une cartouche est insérée (par conséquent à condition que RD5 ( patte 8 ) passe à 5V..."
Tu remarqueras sur le schéma que j'avais posté précédemment, que RD5 (c'est un 5 à la fin) est aussi reliée à une résistance dite de "pull-down", qui sert à la maintenir vers la masse, au niveau bas, quand aucune cartouche n'est présente (plutôt que sa tension ne "flotte" et change n'importe comment).

- Sur la patte 20 de la ROM, j’ai 1,1V sans la cartouche.

Alors là, je me demande si tu n'aurais pas plutôt testé la ROM OS (c'est à dire U5) au lieu de la ROM BASIC (U4) ? Dans ce cas, ça confirmerait plutôt que la ROM en question est bien activée, bien que 1,1V semble un poil élevé, mais bon...

- En démarrant l’ordinateur avec la touche OPTION enfoncée, j’ai 5V sur la patte 6 (MAP) du MMU.

Normalement, la touche est détectée par le programme d'initialisation de la ROM, qui active alors le Self-Test en mémoire. Celui-ci peut également se déclencher si la cartouche (ou le BASIC) n'a pas été détecté par test logiciel... (il est aussi brièvement activé momentanément en mémoire dans tous les cas au lancement, le temps d'effectuer un test de son contenu, il me semble)


Maintenant qu'on peut à priori considérer que ton MMU est ok, il faudrait voir du côté du PIA, je te donne quelques explications et nouveaux relevés plus complets à faire concernant la gestion des roms intégrées.
Si tu as fais de l'assembleur sur 800XL, ça a du t'arriver de désactiver le BASIC intégré ou l'OS pour récupérer à la place de la RAM aux même adresses. Les bits 0,1 et 7 à l'adresse $D301 servent justement à activer ou désactiver les roms intégrées.

Si on appelle cette case mémoire le PORTB, c'est qu'elle contrôle du PORT B du PIA, composé de 8 sorties (une par bit) dont certaines directement reliées au MMU pour contrôler l'activation des roms :
- PB0 (le bit 0) est relié à l'entrée REN du MMU pour contrôller sa sortie /OS vers /CS sur la ROM OS (U5)
- PB1 (le bit 1) est relié à l'entrée /BE du MMU pour contrôler sa sortie /BASIC vers /CS sur la ROM BASIC (U4)
- PB7 (le bit 7) est relié à l'entrée /MAP du MMU pour contrôler sa sortie /OS lors de l'accès au Self-Test (car stocké aussi dans la ROM OS)

Le souci se situe donc peut-être au niveau du PIA (U23, voir aussi le schéma ci-dessous, à mettre en rapport avec celui posté il y a quelques jours) qui ne contrôle pas correctement ces entrées du MMU.

Pour faire un peu le tour, il te faudrait déjà tester chacune de ces 3 "lignes" de bout en bout (celles indiquées plus haut, surtout les deux dernières en fait), en particulier avec des relevés pour chaque groupe de pattes (notées en gras) à tester, côté PIA puis entrée et sortie du MMU et éventuellement côté ROM (histoire de vérifier en même temps que les liaisons sont bonnes) après démarrage normal, sans cartouche.
Puis aussi la dernière ligne (PB7 et /MAP) quand tu démarres avec la touche Option enfoncée (éventuellement, vérifie avant qu'elle fonctionne toujours dans le jeu Tennis).
Là encore, ne pas hésiter à retirer puis bien remettre la puce si elle est sur support, et à recommencer les relevés pour les confirmer.

J'espère que ça permettra d'avancer encore, ça peut être plus complexe, ou bien un souci avec la ROM BASIC (j'ai peut-être une idée pour la tester quand même... ) a+

schéma PIA 800XL.PNG (10.08 Kio) Consulté 3158 fois

[6502man]

tester les signaux avec un voltmètre me semble pas du tout efficace

Je suis le post avec intérêt car j'ai récupéré des 800XL en panne il y a quelques temps, ca me permettra peut être de les réparer