MFA GAL-Programmierer (4.14 Nachbau)

  • Eine der vielen Dinge in der digitalen Welt, die ich noch nicht nutze, sind bei mir GAL-Bausteine. Bislang hatte ich noch nie so richtig den Trieb mich hier einzuarbeiten. Wenn man aber etwas neues dazulernen will, sollte man es einfach mal selbst tun und sehen was dabei rauskommt. Und was liegt da näher als einen MFA dafür zu benutzen. Doch genau hier ist das Problem: ich habe zwar verschiedene Karten für meine MFAs, doch einige, unter anderem die GAL-Programmierkarte 4.14, fehlt mir leider. Diese Karte kam leider erst nach meiner damaligen aktiven MFA-Zeit auf den Markt.


    Die Karte scheint aber noch dazu relativ selten zu sein. Zumindestens gibt so gut wie keine in den einschlägigen MFA-Angeboten. Auch bauchbare Unterlagen sind nicht gerade im Überfluss zu finden. Schaltpläne gibt es zwar im Netz, aber auch hier sind zum Teil handschriftliche Korrekturen eingezeichnet. Aber das sollte einen ja nicht von einer Bastelaktion abhalten, eher im Gegenteil ... ;)



    Nach ein wenig Eagle-Geschubbse kam dann ein halbwegs brauchbarer Schaltplan heraus


    Bei der 16V-Programmierspannung kommt ein einstellbares DC/DC-Modul zum Einsatz, das ich bereits bei der FPU-Karte MFA FPU-Erweiterungskarte (reichelt: DEBO DCDC) eingeplant habe. Denn die +/- 12-Volt des MFA sind nicht gerade mein Steckpferd.


    Das Schaltplan des Frontpanels ist dagegen schon recht übersichtlich:


    Die Platinen sind weniger im Layout ein Problem, sondern eher in der Mechanik. Denn der Textool-Sockel, Frontpanel, Stecker und Kabelführung sollten hinterher ja auch genau passen:


    Montiert sieht das ganze schon recht passabel aus:


    Die Vorwiderstände der beiden LEDs auf dem Frontpanel sind auf SMD-Pads montiert, da ich hier bewusst auf eine Durchkontaktierung verzichtet habe. Werden die Bauteile zu tief montiert, könnten Sie über die Frontplatte einen Kurzschluss verursachen, weshalb die beiden Widerstände auf der Rückseite verlötet sind.


    Im Rack sind das ganze mittlerweile schon recht schick aus


    Erste Tests sehen schon mal vielversprechend aus, nur ein Problem zeigte sich hier. Ein Programmiertest schlägt mit dem Hinweis der Software "kein 16V8 / 16V8A gefunden" fehl. Die GALs die ich bei reichelt bestellt hatte (16V8BQL) lassen sich offenbar nicht mit der Karte programmieren. Muss mir wohl oder übel ein paar 16V8A besorgen :(

    Aber über weitere sachdienliche Hinweise für eine Fehlersuche, wäre ich dankbar. Denn meine Erfahrung mit GALs tendieren im Augenblick noch gegen Null.


    Die kompletten Eagle-Dateien, Schaltpläne und Frontpanel kommen morgen in einer Artikelergänzung hier noch dazu (muss die Frontblende erst noch ins STP-Format exportieren).


    Sollte jemand bereits Interesse an einem Nachbau haben, gerne melden. Nur habe ich diesmal nicht so viele Karten bestellt, da ich von einer längeren "Prototyp-Phase" ausgegangen bin. Ansonsten bitte etwas Geduld, bis ich zusammen mit meinem nächsten Projekt eine neue Bestellung vornehme.

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Coole Geschichte. :thumbup:


    Aber über weitere sachdienliche Hinweise für eine Fehlersuche, wäre ich dankbar. Denn meine Erfahrung mit GALs tendieren im Augenblick noch gegen Null.

    Ich denke das ist weniger Fehlersuche als evtl. Softwareanpassungen.

    Ich geh davon aus, das die GALs auch eine ID haben. Passt da eine Kleinigkeit nicht, geht's nicht. Da braucht nur der Hersteller die ID aendern wegen irgendeinem Feature, das aber keine Relevanz zur Programmierung hat.

    Ohne eine NDA mit dem Hersteller wirst du den Unterschied auch nicht erfahren.

    Also Software anpassen und ausprobieren.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • Aber über weitere sachdienliche Hinweise für eine Fehlersuche, wäre ich dankbar. Denn meine Erfahrung mit GALs tendieren im Augenblick noch gegen Null.

    Wo hast du denn die Software her?

    Die nachträglich parallel geschalteten Ausgänge am 8255, ist das in der Software entsprechend implementiert?


    Welche Programmierspannung ist überhaupt richtig?

    Du hast etwas von 16V geschrieben. Wenn ich den Spannungsverdoppler auf dem Originalschaltplan betrachte, könnten auch 20V oder mehr benötigt werden.


    Hab mir die Originalunterlagen noch nicht angeschaut. Von daher nur mal als Überlegung.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • Da hätte ich ggf. Interesse an einem Platinensatz... wenn alles funktioklappt...

    Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    An die Person, die meine Schuhe versteckt hat, während ich auf der Hüpfburg war: Werd' erwachsen! :motz:


    ::matrix::

  • Wo hast du denn die Software her?

    Die nachträglich parallel geschalteten Ausgänge am 8255, ist das in der Software entsprechend implementiert?

    Hi,

    die Software habe ich aus dem Beitrag von rfka01 entnommen, siehe MFA GAL Brenner Board, aber noch nicht genauer analysiert.


    Was die Schaltung angeht: hier habe ich drei mehr oder weniger ähnliche Schaltpläne gefunden mit mehr oder weniger identischen, handschriftlichen Änderungen bzw. Korrekturen. Die Schaltungsbeschreibungen beziehen sich auch auf diese teilweise merkwürdige Ausführung (3 Ports des 8255 zusammenschalten):



    Die Programmierspannung von 16 V ist in der Beschreibung so aufgeführt. Die Originalschaltung realisiert dies mit 2 Zener-Dioden (10V + 6,8V). Dies wird mit einem Rechteckgenerator in Verbindung mit den -12V realisiert. Dies wollte ich aber so nicht umsetzen (mag kein -12V), weshalb ich hier einen DCDC-Wandler einsetze. Aber hier werde ich nochmals genauer in die Fehlersuche einsteigen.


    Vielen Dank auch für Deinen Tipp mit der Chip-ID. "Damals" gab es vermutlich nur wenige 16V8 und somit auch nur eine begrenzte Ausprägung der Chip-IDs ... :grübel:

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Hallo,

    wie gestern schon erwähnt, hier nun die vollständigen Projektdateien:

    • Eagle-Projekt mit Gerberdateien für die Platine
    • Eagle-Projekt mit Gerberdateien für die Frontplatine
    • Frontblende in verschiedenen Formaten

    [Update]

    Die Platine für den Programmiersockel hat einen Fehler: LED1 und LED2 sind vertauscht (ich bin so ein Depp ... :fp:).

    Die Anlage des Eagle-Projektes habe ich gerade korrigiert (Rev 1.1).

  • Ich kann am WE mal schauen was ich so helfen kann. Ich habe noch einige Lattice 16V8A die damals mit dem MFA programmiert worden sind. Da kann ich mal nach der ID schauen. Ich habe auch noch ein GAL Handbuch von Lattice aus der Zeit von damals. Vielleicht steht da noch etwas drin.

  • Ich kann am WE mal schauen was ich so helfen kann

    Vielen Dank, an den Infos hätte ich echt Interesse :)


    Aber vorerst Entwarnung, hab den Fehler gefunden: der Textool-Sockel ist defekt (war auch merkwürdig billig bei Amazon ... :wand: )

    Das erklärt eventuell auch die sporadischen Meldungen, denn "GAL nicht vorhanden" bekam ich nicht immer als Fehler angezeigt.


    Nun funktioniert die Kiste und ich konnte auch die aktuellen GALs 16V8BQL anstandslos programmieren :)

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Ich geh davon aus, das die GALs auch eine ID haben.

    Die 16/20V8 GALS haben 64bit für eine Signatur. Diese ist steht aber zur freien Verfügung und ist keine Typen oder Seriennummer vom Chiphersteller.

    Interessant ist aber der "reserved space". Unter RA58 finden sich 64bit die dem Programmiergerät alles über den Chip verraten.

    Also sagt der Chip dem Programmiergerät, welche Programmierspannung usw. gebraucht wird. Das erklärt zum Beispiel, das vom ganzen Programmiervorgang nirgends etwas in den Datenblättern zu finden ist. Eine Art Copyright oder Lizenz-Vertriebsmodell für Programmiergeräte?

    Einmal editiert, zuletzt von Andechs ()

  • Ohne Software sieht auch die schönste Hardware eben nur schön aus...


    Der MFA Originalcode des GAL-Programmierers hat nun den Weg durch den Reassembler genommen und wurde danach noch ein wenig überarbeitet. Im Anhang findet ihr eine erste Version des kompletten Quellcodes (Basis: Microsoft Visual Studio Code in Verbindung mit dem RetroAssembler). Der Code wurde dann soweit angepasst, dass keine fixen Adressen mehr enthalten sind. Dadurch kann das Programm an beliebige Stelle im Speicher assembliert werden.


    Der nächste Schritt steht schon auf meiner ToDo-Wunschliste für die "freien" Tage: Integration des Code in das MAT32k ;) Erste Tests waren schon vielversprechend ... :grübel:


    Gruß

    Thilo

  • Dafür nehme ich ebenfalls den Retroassembler. Nur über die Kommandozeile mit der Option -d


    Code
    retroassembler.exe -d [-D=$1000] -C=8085 input-datei.bin output-datei.asm


    -D wird nur benötigt, wenn es sich um einen abweichenden Speicherbereich handelt (!=$0000) damit die Adressen/Labels wieder passen.


    Ich hatte mal einen wesentlich besseren Disassembler, der Textstellen bereits recht passabel übersetzt hat. Den find ich aber leider nicht mehr ?(

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Dafür nehme ich ebenfalls den Retroassembler. Nur über die Kommandozeile mit der Option -d

    Die ganzen Labels, die du eingefuegt hast, hast du die selber "generiert" ?


    Bei meinem Test hat der Retro(Dis)Assembler gar keine Labels generiert.

    Dann kann ich dir gerne einen besseren nennen.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • Die ganzen Labels, die du eingefuegt hast, hast du die selber "generiert" ?

    Ja, alle selbst generiert. Auch die Textstellen werden nicht erkannt. :wacko:


    Dann kann ich dir gerne einen besseren nennen.

    welchen kannst Du mir denn hier empfehlen ? :)

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Ich benutze i.a. z80dasm (schau ich morgen nochmal nach).

    Textstellen erkennt der auch nicht, kann man aber in einer Kontroldatei angeben. Mit dieser Kontroldatei hat das Teil viele Optionen.

    Liegt im Source vor, da hab schon einiges geändert, vor allem Ausgabeformatierung, aber auch die Behandlung der Mnemonic Ausgabe von 8080 und Z80.


    Es gibt noch einen Disassembler, dem man interaktiv Textstellen und andere Optionen angeben kann.


    Wie gesagt, sag ich dir morgen, liegt auf meinem Arbeitsplatzrechner.


    Nachtrag:

    In anderen Posts gefunden:

    http://www.brouhaha.com/~eric/software/d52/

    dazzle (interaktiver Disasm)

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • Danke für den Tipp. :thumbup:

    Der Disassembler hätte mir einiges an Arbeit erspart ... Aber ich hab ja noch ein paar Codeteile des MAT32k vor mir und dazu werde ich diesen mal einsetzen. :kafeee:

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Danke für den Tipp. :thumbup:

    Gerne doch.


    Ich hatte gerade die GUI mal angetestet, aber wieder verworfen.

    Wenn du einen Trace machst und damit ein Control-File generierst, werden auch ASCII Texte erkannt.


    Ich hatte das Trace nie ausprobiert, weil es ein evtl schon vorhandenes Control-File ueberschreibt.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)