Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #200590 > unrolled thread

PAL, GAL, HAL (Vintage :-) )

Back to article view | Back to de.sci.electronics

Contents

  PAL, GAL, HAL (Vintage :-) ) R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-01-22 15:12 +0100
    Re: PAL, GAL, HAL (Vintage :-) ) "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-01-22 14:24 +0000
      Re: PAL, GAL, HAL (Vintage :-) ) Rafael Deliano <rafael_deliano@arcor.de> - 2016-01-23 11:16 +0100
    Re: PAL, GAL, HAL (Vintage :-) ) Rafael Deliano <rafael_deliano@arcor.de> - 2016-01-22 18:11 +0100
      Re: PAL, GAL, HAL (Vintage :-) ) Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-01-22 18:44 +0100
    Re: PAL, GAL, HAL (Vintage :-) ) Christian Zietz <newsgroup.1001@chz.xyz> - 2016-01-22 18:38 +0100
      Re: PAL, GAL, HAL (Vintage :-) ) Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-01-22 18:55 +0100
        Re: PAL, GAL, HAL (Vintage :-) ) Patrick Schaefer <pa.schaefer@web.de> - 2016-01-22 20:17 +0100
        Re: PAL, GAL, HAL (Vintage :-) ) Michael Schwingen <news-1326478115@discworld.dascon.de> - 2016-01-22 19:30 +0000
      Re: PAL, GAL, HAL (Vintage :-) ) R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-01-22 21:54 +0100
        Re: PAL, GAL, HAL (Vintage :-) ) "MaWin" <me@private.net> - 2016-01-23 01:19 +0100
          Re: PAL, GAL, HAL (Vintage :-) ) R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-01-23 16:35 +0100
        Re: PAL, GAL, HAL (Vintage :-) ) Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2016-01-23 14:59 +0100
          Re: PAL, GAL, HAL (Vintage :-) ) Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-01-23 15:09 +0100
          Re: PAL, GAL, HAL (Vintage :-) ) R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2016-01-23 16:35 +0100
            Re: PAL, GAL, HAL (Vintage :-) ) Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-01-23 16:39 +0100
    Re: PAL, GAL, HAL (Vintage :-) ) Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-01-22 22:33 +0100

#200590 — PAL, GAL, HAL (Vintage :-) )

Moin!

Ein paar Fragen an die Auskenner historischer Hardware, von denen ich
hier einige vermute :-)  Ich hatte seinerzeit nur ein bißchen was mit
diesen Bausteinen zu tun, hatte ein paar mit Hilfe von Isdatas Logic
erstellt und programmiert. Das war's. Jetzt betreibe ich gerade ein
Gedankenspiel, wie ich Bausteine dieser Art aus historischen Rechnern
auslesen und rekonstruieren könnte. 

Mein bisheriger "Gehirnsturm" zur Systematik:
PALs gibt's in diversen "Geschmacksrichtungen": als L-(Logic) und als
R-(Register)Typ. Die üblichen waren die mit 16 und die mit 20 Eingängen
und somit mit 20 bzw. 24 Beinchen. Die hintere Zahl ist die Zahl der
I/Os: 2, 4, 6 und 8 waren üblich. Die Kombinationen daraus sind die
allermeisten eingesetzten Sorten.

GALs gibt's als (22V10,) 16V8 und 20V8. Diese können obige PAL-Varianten
vollständig ersetzen und haben sogar ein paar Freiheitsgrade mehr.  

HALs sind "hart" programmierte PALs der üblichen Sorten. Typischer
Anwendungsfall: Großserieneinsatz wie im Apple //e. D.h. mit einem GAL
kann man genauso ein HAL ersetzen.

Ist das für meinen ersten Überblick soweit korrekt, ist was falsch oder
fehlt was Grundlegendes? Die ältere Technik der (PLAs) 82S<irgendwas>
klammere ich erstmal bewußt aus.

Gruß, Ralf

[toc] | [next] | [standalone]

#200591

Ralf Kiefer <R.Kiefer.SPAEM@gmx.de> wrote:
[Typen vo PALs und GALs]
>Ist das für meinen ersten Überblick soweit korrekt, ist was falsch oder
>fehlt was Grundlegendes? Die ältere Technik der (PLAs) 82S<irgendwas>
>klammere ich erstmal bewußt aus.
Ich würde noch reine Proms mit aufnehmen. Das war früher durchaus üblich 
als Adressdekoder.

[toc] | [prev] | [next] | [standalone]

#200614

> Ich würde noch reine Proms mit aufnehmen. Das war früher durchaus üblich
> als Adressdekoder.

Als NMOS-Mikroprozessoren noch lahm waren:
http://www.embeddedFORTH.de/temp/PROM-Controller.pdf

Nützlich Anregung für sowas wären alte Datenbücher
Signetics, TI weil es als Varianten von PROMs auch
Zustandsmaschinen ( Mealy & Moore ) single chip gab.
Unklar wie populär, vermutlich für Teilfunktionen
in Minicomputern gedacht.

Bipolares PROMs dürften wegen Stromverbrauch, mühsamer
Programmierung heute wenig parktikabel sein.
Es gab von Cypress schnelle 2716 in schmalem Gehäuse:
http://www.embeddedFORTH.de/temp/cypress.pdf
Hab die Dinger aber nicht zum Laufen bekommen,
demoliert bei Programmierung.

Andere Entwicklungsrichtung wäre 15V Logik
mit PMOS-EPROMs:
http://www.embeddedFORTH.de/temp/CD4000-PROM.pdf
Langsam jedenfalls, ob störfest wäre zu prüfen.

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#200595

> HALs sind "hart" programmierte PALs der üblichen Sorten. Typischer
> Anwendungsfall: Großserieneinsatz wie im Apple //e.

Quasi mit metal gate Maske gefertigt. Eventuell mußten
sie nur die letzten Prozesschritte ändern.
   Ich hatte immer den Eindruck daß MMI sie nie gemacht hätte
wenn Apple nicht mit der Entwicklung des kundenspezifischen
ICs für den Macintosh gescheitert wäre. Das war hochhomplex
und hätte bei VLSI Technology gefertigt werden sollen.
Burrell
https://en.wikipedia.org/wiki/Burrell_Smith
hatte die Prototypen alle mit PALs aufgebaut und da
Produkteinführung festen Termin hatte ergab sich dann
die Serie daraus. Daß es ausser Apple viel Kunden dafür gab
glaube ich nicht.

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#200597

On 01/22/2016 06:11 PM, Rafael Deliano wrote:
>
>> HALs sind "hart" programmierte PALs der üblichen Sorten. Typischer
>> Anwendungsfall: Großserieneinsatz wie im Apple //e.
>
> Quasi mit metal gate Maske gefertigt. Eventuell mußten
> sie nur die letzten Prozesschritte ändern.
>    Ich hatte immer den Eindruck daß MMI sie nie gemacht hätte
> wenn Apple nicht mit der Entwicklung des kundenspezifischen
> ICs für den Macintosh gescheitert wäre. Das war hochhomplex
> und hätte bei VLSI Technology gefertigt werden sollen.

Spätere Macintosh (mit 68000) hatten hochintegrierte ICs drauf. War 
anscheinend nur bei den ersten Revisionen so.


> https://en.wikipedia.org/wiki/Burrell_Smith
> hatte die Prototypen alle mit PALs aufgebaut und da
> Produkteinführung festen Termin hatte ergab sich dann
> die Serie daraus. Daß es ausser Apple viel Kunden dafür gab
> glaube ich nicht.

Commodore hat AFAIK im Amiga hier und dort auch HALs verbaut und ich 
meine sie auch schon im PC auf Grafikkarten  gesehen zu haben. Ich kenne 
die Dinger jedenfalls nicht nur aus dem MAC.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#200596

Ralf Kiefer schrieb:

> Jetzt betreibe ich gerade ein
> Gedankenspiel, wie ich Bausteine dieser Art aus historischen Rechnern
> auslesen und rekonstruieren könnte. 

Es würde mich freuen, über weitere Fortschritte dieses Gedankenspiels
hier zu lesen. Ich habe auch Vintage-Hardware mit PALs und GALs. Das
Reverse-Engineering anhand das von außen beobachtbaren Verhaltens ist ja
nicht so trivial, zumindest wenn der PAL/GAL mehr als ein reiner
Adressdecoder oder so ist.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#200598

On 01/22/2016 06:38 PM, Christian Zietz wrote:
> Ralf Kiefer schrieb:
>
>> Jetzt betreibe ich gerade ein
>> Gedankenspiel, wie ich Bausteine dieser Art aus historischen Rechnern
>> auslesen und rekonstruieren könnte.
>
> Es würde mich freuen, über weitere Fortschritte dieses Gedankenspiels
> hier zu lesen. Ich habe auch Vintage-Hardware mit PALs und GALs. Das
> Reverse-Engineering anhand das von außen beobachtbaren Verhaltens ist ja
> nicht so trivial, zumindest wenn der PAL/GAL mehr als ein reiner
> Adressdecoder oder so ist.

Solange es kein PAL mit 'R' in der Bezeichnung ist, also FlipFlops 
enthält sollte die Funktion zu eruieren sein.

Irgendwer hat  neulich behauptet, daß man Lattice GALs mit einem Trick 
auch bei gesetztem Schutzbit auslesen kann. Leider hat er den Trick 
nicht beschrieben.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#200600

Am 22.01.2016 18:55 schrieb Gerrit Heitsch:

> Solange es kein PAL mit 'R' in der Bezeichnung ist, also FlipFlops
> enthält sollte die Funktion zu eruieren sein.

Richtig. Für PROMs und L-PALs kann man einfach die Wertetabelle 
durchrattern. Ich nehme dazu einen Adapter auf 2764, packe den in den 
Sprint und jage den entstandenen Hexfile durch ein uraltes DOS-Tool 
namens XCPLD.com.

Dann mit copy & paste die Namen anpassen, und schon frisst es der 
GAL-Assembler.


Patrick

[toc] | [prev] | [next] | [standalone]

#200601

On 2016-01-22, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>> Es würde mich freuen, über weitere Fortschritte dieses Gedankenspiels
>> hier zu lesen. Ich habe auch Vintage-Hardware mit PALs und GALs. Das
>> Reverse-Engineering anhand das von außen beobachtbaren Verhaltens ist ja
>> nicht so trivial, zumindest wenn der PAL/GAL mehr als ein reiner
>> Adressdecoder oder so ist.
>
> Solange es kein PAL mit 'R' in der Bezeichnung ist, also FlipFlops 
> enthält sollte die Funktion zu eruieren sein.

Nicht trivial - mit internem Feedback *ohne* getaktetes Flipflop kann man
R/S-Flipflops, Pulsgeneratoren (Taktverdoppler etc.) und sonstige Sachen
aufbauen, die sich durch einfaches Beobachten von Eingangs- und
Ausgangssignalen nicht rekonstruieren lassen. Das ist nicht sauber und im
Verhalten vom Speedgrade des Bausteins abhängig, wurde aber damals durchaus
gerne gemacht.

Mit einem ausreichend schnellen Logikanalyser sollte es gehen ... IIRC sind
die Feedbackpfade ja immer an den Pins beobachtbar.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#200602

Christian Zietz wrote:

> Es würde mich freuen, über weitere Fortschritte dieses Gedankenspiels
> hier zu lesen. Ich habe auch Vintage-Hardware mit PALs und GALs. Das
> Reverse-Engineering anhand das von außen beobachtbaren Verhaltens ist ja
> nicht so trivial, zumindest wenn der PAL/GAL mehr als ein reiner
> Adressdecoder oder so ist.

Ok, dann mal ein paar meiner Ansätze dazu:

- Ich baue mir z.B. einen 20pol. Sockel an einen Rechner, an dem ich
viele GPIOs habe, an die ich wiederum per Anwender-Software relativ
einfach und schnell herankomme. Beim Sockel treffe ich die Annahme, daß
10 GND und 20 VCC sei, wobei ich das in der Schaltung oder im Schaltplan
vorher(!) verifizieren kann. Das sollte typisch genug sein. Ich gehe
weiterhin davon aus, daß ich einen Proband vor mir habe, bei dem die
Typenbezeichnung nicht (mehr) vorhanden ist. Ein Hinweis auf einen
speziellen Typ reduziert natürlich den Aufwand erheblich.

- Jedes Beinchen hängt so an den GPIOs:

IC-Bein -------+------[ R ]---------- GPIO (out)
               |
               +--------------------- GPIO (in)

Damit kann ich zunächst feststellen, ob es sich beim jeweiligen Beinchen
um einen Ausgang handelt. Tristate-Erkennung wird auf "später" vertagt,
denn das kann ich so nicht von einem Eingang unterscheiden. R wird so
gewählt, daß das Signal vom GPIO-Ausgang vom Proband noch erkannt wird,
wenn es Low oder High ist. Der R soll verhindern, daß ein möglicher
Ausgang vom Testobjekt überlastet wird, weil der GPIO dagegen treibt,
denn ich möchte nicht zerstörend testen. Vielleicht ist es sinnvoll,
noch mit ein wenig Pullup und/oder Pulldown am Testobjekt nachzuhelfen.
Gedanken zu Widerstandswerten stehen noch aus. Vorschläge nehme ich
natürlich dankend entgegen.

- Danach sollte ich ein Muster vom Test-Chip haben, wo die Ausgänge
sind. Also sind die anderen Beinchen entweder Eingang oder Ausgang mit
Tristate.

- Behandle ich sie daher wie Eingänge: alle möglichen Muster anlegen,
Tabelle mit den Ausgangsmustern anlegen. Die kann groß werden!

- Aufgabe #1: Tristate-Ausgänge. Erkenne ich, daß bei einem angelegten
Testmuster dieses nicht auch über die lesenden GPIO-Eingänge erhalten
bleibt, habe ich erkannt, daß es kein Eingang ist. Also
Anfangsbedingungen anpassen, nochmal von vorne beginnen.

- Aufgabe #2: Register und State Machines. Die Anzahl der (internen)
Register gibt die maximale Anzahl der Zustände vor: 2^Registerzahl. D.h.
hier setzen geeignete Wiederholungen einzelner Testschritte an. Das sind
verdammt viele, und die erzeugen große Ergebnistabellen.

- Nach dem Durchlauf liegen im Trivialfall (Baustein ohne
Registernutzung) Tabellen vor, aus denen die Abhängigkeiten der Ausgänge
von den Eingängen mit ein paar einfachen Gleichungen beschrieben werden
können. Ein Abgleich mit Mustern von Standard-TTL-Bausteinen kann hier
stattfinden, um beispielsweise einen 74LS244 erkennen zu können. Beides
ist eine Frage der Auswerte-Software, d.h. Muster von AND-, OR-, XOR-
und NOT-Verknüpfungen suchen.  

- Wurde Registernutzung erkannt, wird's herausfordernd :-)  Da habe ich
ein paar Ideen, das Gesamtkonzept fehlt noch, halte es aber für in
endlicher Zeit lösbar. Wesentlich: die Teile mit Registernutzung von den
reinen Logikteilen trennen, um den Datenumfang zu verringern. Sicherlich
kann ich nicht alle "Schweinereien" aus State Machines aufdecken, wenn
z.B. mit internen Gatterlaufzeiten gemurkst wurde. Saubere State
Machines basierend auf nachvollziehbarer Taktung sollten lösbar sein,
IMHO. Zumindestens habe ich gerade den Ehrgeiz es zu versuchen :-)   

- Die Erkennung z.B. eines 74LS245 (bidirektionaler Bustreiber) kann
obiger Algorithmus nicht leisten, denn die wechselweise Nutzung von
Beinchen als Ein- oder Ausgang ist so nicht möglich.

- Als "Host" dachte ich (ganz im Sinne von "Vintage") zunächst an die
KAT-Ce, die mir vor einigen Tagen frisch zugelaufen ist, siehe nebenan
in dafc. Die hat einen 68000 mit 8 oder 10MHz, ließe sich auf 68010
pimpen, ggf. sogar mit PAK auf 68020 oder 68030, aber die Anzahl der
GPIOs reicht nicht. Schnell genug wären die wenigstens. Nächste Idee:
die Anzahl von GPIOs wären in einem Apple //e kein Problem, da ich
mehrere Karten mit 6522, 6821 oder Eigenbau mit TTL-Treibern nachstecken
kann. Die Rechenleistung dürfte mit den 12,5MHz auch passen (und obige
KAT-Ce lässig schlagen). Allerdings reicht das RAM hinten und vorne
nicht für die erzeugten Tabellen. Also verfolge ich jetzt den Gedanken
ein oder zwei vorhandene VMEbus-Karten geeignet umzubauen, damit ich auf
die nötige Anzahl der GPIOs komme, denn im Originalzustand hängen an
denen Optokoppler und Relais. Mit 68040 oder 68060 @66MHz und 256MB RAM
(rund 240MB zur freien Verfügung und ggf. GBs auf Festplatte) sollten
ausreichend Ressourcen zur Verfügung stehen. Ich würde den
Low-Level-Teil in einen OS-9-Treiber verpacken, um ausreichend schnell
mit den CIO8536 sprechen zu können. Außerdem würde dieser Aufbau dem
Gedanken historische Hardware zu beschäftigen genügen :-)  Der
VMEbus-Rechner ist Stand der Technik von 1995.

- Zusätzlicher Nutzen dieses Aufbaus: bekanntes TTL-IC auf Funktion
prüfen. Wird es erkannt, dann funktioniert's offensichtlich. Wenn's
nicht erkannt wird, ist es kaputt. So was kann ganz nützlich sein, wenn
man einen kranken Apple ][, PET o.ä. vor sich hat und Verdachtsmomente
auf einzelne Gatterfunktionen zielen. 

Gruß, Ralf

[toc] | [prev] | [next] | [standalone]

#200608

"Ralf Kiefer" <R.Kiefer.SPAEM@gmx.de> schrieb im Newsbeitrag 
news:1mhfvvq.10yxogk1uumu3wN%R.Kiefer.SPAEM@gmx.de...
> Christian Zietz wrote:
>
>> Es würde mich freuen, über weitere Fortschritte dieses Gedankenspiels
>> hier zu lesen. Ich habe auch Vintage-Hardware mit PALs und GALs. Das
>> Reverse-Engineering anhand das von außen beobachtbaren Verhaltens ist ja
>> nicht so trivial, zumindest wenn der PAL/GAL mehr als ein reiner
>> Adressdecoder oder so ist.
>
> Ok, dann mal ein paar meiner Ansätze dazu:
>
http://dreamjam.co.uk/emuviews/pal/

-- 
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

[toc] | [prev] | [next] | [standalone]

#200624

MaWin wrote:

> http://dreamjam.co.uk/emuviews/pal/

Vom Ansatz her geeignet, aber da fehlt mir einiges. 

Gruß, Ralf

[toc] | [prev] | [next] | [standalone]

#200619

On Fri, 22 Jan 2016 21:54:32 +0100, R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) wrote:

>Ok, dann mal ein paar meiner Ansätze dazu:

Ich meine ich hätte mal beim VCFe eine Vortragsankündigung gesehen, wie man
defekte ICs in alter Elektronik mit moderner Technik ersetzt. 

Wenn ich mich richtig erinnere, ging's darum z.B. PAL/GALs oder
custom-chip-Zeugs von damals zu ersetzen, indem man auf einen DIL-Träger eine
moderne Mikroeletronik (PIC?) packt, und die Funktion in Software nachbildet.

Ich finde dazu nix, und war auch nicht auf dem Vortrag selbst. Aber vielleicht
weiß hier wer mehr, z.B. ob zum Auslesevorgang auch was dabei war?


Thomas Prufer

[toc] | [prev] | [next] | [standalone]

#200620

On 01/23/2016 02:59 PM, Thomas Prufer wrote:
> On Fri, 22 Jan 2016 21:54:32 +0100, R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) wrote:
>
>> Ok, dann mal ein paar meiner Ansätze dazu:
>
> Ich meine ich hätte mal beim VCFe eine Vortragsankündigung gesehen, wie man
> defekte ICs in alter Elektronik mit moderner Technik ersetzt.
>
> Wenn ich mich richtig erinnere, ging's darum z.B. PAL/GALs oder
> custom-chip-Zeugs von damals zu ersetzen, indem man auf einen DIL-Träger eine
> moderne Mikroeletronik (PIC?) packt, und die Funktion in Software nachbildet.

Das muss dann aber ein SEHR schneller PIC sein. Schon beim eher 
gemächlichen C64 hast du von dem Moment an dem die Rechnerlogik dir 
sagt, daß du gemeint bist weniger als 500ns Zeit bis du das Ergebnis 
geliefert haben musst. Das beinhaltet rausfinden was genau gewünscht wird.

Läuft der Controller mit 20 MHz hast du weniger als 10 Zyklen dafür.

Das ist einer der Gründe warum der SwinSID für den C64 den Atmel 
übertakten muss und trotzdem nur write-only ist, also keine Register 
ausgelesen werden können.

Hardware in Software nachbilden ist gar nicht so einfach wenn es nicht 
nur eine Simulation sondern eine Emulation sein soll.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#200625

Thomas Prufer wrote:

> Ich meine ich hätte mal beim VCFe eine Vortragsankündigung gesehen, wie man
> defekte ICs in alter Elektronik mit moderner Technik ersetzt. 

Bis jetzt habe ich genau damit noch keine Probleme. Ok, wenn ein
typischer Controller-Chip wie z.B. ein NCR5380 (SCSI) abraucht, dann
gibt's dafür nur adäquaten Ersatz durch dasselbe Teil. Ist ein 74LS oder
artverwandtes kaputt, gilt dasselbe. Das läßt sich meist organisieren,
ggf. verträgt die Schaltung einen 74-, 74S, 74F oder 74ALS stattdessen.

Altes durch Modernes ersetzen müßte ich z.B. auf einer Apple-][-Karte,
die einen 64kB-Druckerpuffer spielt (Grappler Pro, oder so). Da bestand
die lokale "Intelligenz" aus einem i8748. Und diese Controller mit
Guckloch zum UV-Löschen waren vor 25 Jahren selten und teuer. Zu meinem
ganz frischen Erstaunen gibt's davon jede Menge bei Ebay für moderate
Preise. Danke für den Anstoß, da werde ich gleich Kunde :-) 


Blöd wird's genau dann, wenn ich nicht erkennen kann, was es ist
(abgeschliffene Bezeichnung), oder wenn's ein programmierter Chip ist.
Wenn er kaputt ist, ist sowieso alles zu spät. Also versuche ich von der
für mich wertvollen Hardware Inhalte programmierter Chips vorsorglich
auszulesen, um später ggf. Ersatz beschaffen zu können. Für
EPROM-Inhalte gibt's bei populärer Hardware etliche Sammlungen, z.B. für
die Apple-][-Welt. Oder es gibt Bitsavers. Aber für meine VMEbus-Karten
gibt's nicht viel im Netz, konkret: häufg genug nicht mal eine
Fundstelle von einzelnen Karten oder gar komplett verschollene
Hersteller.


> Wenn ich mich richtig erinnere, ging's darum z.B. PAL/GALs oder
> custom-chip-Zeugs von damals zu ersetzen, indem man auf einen DIL-Träger eine
> moderne Mikroeletronik (PIC?) packt, und die Funktion in Software nachbildet.

PALs will ich durch GALs ersetzen können, im Reparaturfall. Denn ich
habe etliche 16V8, 20V8 und 22V10 hier rumliegen. Die
Wiederprogrammierbarkeit von denen ist natürlich ein weiterer großer
Vorteil. Wenn ich dagegen diverse 16L, 16R und dasselbe mit den 20L und
20R vorrätig halten sollte oder später mal beschaffen müßte, wird's eng.
Daher wäre es mir recht die Gleichungen zu haben, um bei Bedarf ein GAL
füllen zu können.

Außerdem gehe ich davon aus, daß sich die meisten PALs und GALs aus den
professionellen Geräten gegen das einfache Auslesen wehren. Soll heißen,
daß ich keine Idee habe, wie ich an die interne Logik kommen kann außer
durch Ausprobieren. 


> Ich finde dazu nix, und war auch nicht auf dem Vortrag selbst. Aber vielleicht
> weiß hier wer mehr, z.B. ob zum Auslesevorgang auch was dabei war?

Derzeit habe ich hier einen TL866CS als Programmiergerät inkl.
Chinesen-Software für fast alles, nur nicht für PALs (und 2708 und
i8748). D.h. für spezielle Sachen wäre hier basteln angesagt. 


Gruß, Ralf

[toc] | [prev] | [next] | [standalone]

#200627

On 01/23/2016 04:35 PM, Ralf Kiefer wrote:

> Außerdem gehe ich davon aus, daß sich die meisten PALs und GALs aus den
> professionellen Geräten gegen das einfache Auslesen wehren. Soll heißen,
> daß ich keine Idee habe, wie ich an die interne Logik kommen kann außer
> durch Ausprobieren.

Nicht notwendigerweise. Commodore scheint die ganzen PALs/GALs in ihren 
Rechnern nicht gegen Auslesen geschützt zu haben.


> Derzeit habe ich hier einen TL866CS als Programmiergerät inkl.
> Chinesen-Software für fast alles, nur nicht für PALs (und 2708 und
> i8748). D.h. für spezielle Sachen wäre hier basteln angesagt.

Wichtig bei einem Programmer der alte Rechner bedienen soll ist die 
Fähigkeit ein 2532 und ein 2564 programmieren zu können. Die waren 
pinkompatibel zu den 2332 bzw. 2364 Masken-ROMs und wurden deshalb oft 
statt diesen verwendet. Will man da ein 27xx verbauen braucht es einen 
Adapter.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#200604

On 22.01.16 15.12, Ralf Kiefer wrote:
> Ein paar Fragen an die Auskenner historischer Hardware, von denen ich
> hier einige vermute :-)  Ich hatte seinerzeit nur ein bißchen was mit
> diesen Bausteinen zu tun, hatte ein paar mit Hilfe von Isdatas Logic
> erstellt und programmiert. Das war's. Jetzt betreibe ich gerade ein
> Gedankenspiel, wie ich Bausteine dieser Art aus historischen Rechnern
> auslesen und rekonstruieren könnte.

In ein Programmiergerät hängen und alle möglichen Kombinationen 
durchklappern. Bei Register-Ausgängen ist das nicht ganz so trivial.

Harte Naturen ziehen die Ausgänge unabhängig von deren Wunschpegel auch 
mal auf High oder Low. Bei den meisten Exemplaren bekommt man so auch 
den Zustand der Rückkopplungs-Leitungen raus. Wenn natürlich irgendein 
Schlaumeier auf der Durchlaufzeit basierende Logik reinprogrammiert hat 
(z.B. mit dem Spike, der sich ergibt, wenn ein Ausgangssignal noch nicht 
dem Eingang gefolgt ist, irgendetwas bistabiles schalten), dann wird es eng.

Aber bevor man sich einen abbricht: zuweilen kann man die Dinger auch 
einfach auslesen.

> Mein bisheriger "Gehirnsturm" zur Systematik:
> PALs gibt's in diversen "Geschmacksrichtungen": als L-(Logic) und als
> R-(Register)Typ.

H-Logik wäre auch noch zu erwähnen.


> Die üblichen waren die mit 16 und die mit 20 Eingängen
> und somit mit 20 bzw. 24 Beinchen. Die hintere Zahl ist die Zahl der
> I/Os: 2, 4, 6 und 8 waren üblich.

Anders herum. Erste Zahl Anzahl I/Os, zweite Zahl Anzahl Os.

> GALs gibt's als (22V10,) 16V8 und 20V8. Diese können obige PAL-Varianten
> vollständig ersetzen und haben sogar ein paar Freiheitsgrade mehr.

Naja, mit der V-Marcocell geht so ziemlich alles, was mit L, H, und R 
auch geht. Man kann sie umschalten.

> Ist das für meinen ersten Überblick soweit korrekt, ist was falsch oder
> fehlt was Grundlegendes?

Passt schon so ungefähr.


Marcel

[toc] | [prev] | [standalone]

Back to top | Article view | de.sci.electronics

csiph-web