Ersatz eines PROMs AM27S12

[Ralf Kiefer]

Hallo!

Mir ist eine Platine aus dem Jahr 1985 (Entwicklungsstand vermutlich
1983) zugelaufen, bei der die Adreßdekodierung teilweise mit Hilfe eines
bipolaren PROMs gemacht wird, eingebaut: AM27S12. Der Hersteller sah
vor, daß der engagierte Endanwender so was in Abhängigkeit der gewählten
Bestückung der SRAM- und EPROM-Sockel selbst macht, weswegen die
Generierung des Inhalts grob umrissen ist. Zuerst dachte ich, daß es
diese PROMs schon lange nicht mehr zu kaufen gäbe. Nicht ganz :-) Bei
Ebay werden noch welche angeboten. Stolze Preise, aber vorhanden.

Beim Blick in die Liste meines China-Eprommers TL866CS finde ich
allerdings diese Produktgattung nicht. Gefunden habe ich in einem
Harris-Datenbuch die Anleitung, wie diese PROMs ihren Inhalt erhalten:
in Kurzfassung, eher rustikal. Im Detail: aus der Matrix der Dioden
werden die "rausgeschossen", die eine '0' werden sollen. Spannung
24-30V, Strom 750mA. Womit geklärt wäre, weswegen das China-Gerät am USB
nicht mitspielt. Und womit auch klar ist, daß ich das auf die Schnelle
nicht nachbauen werde.


Details: AM27S12, ein 512*4 PROM mit Open Collector, also 9 Eingänge und
4 Ausgänge. Vergleichstypen sind Signetics 82S130 und Harris 7620.
Das Detail "Open Collector" sieht mir nach einer "Aufgabe" aus. Denn
mein nächster Gedanke war ein GAL 16V8 zu nehmen, und das in einen
Sockeladapter von 20pol. (GAL) auf 16pol. (PROM) zu basteln. Ob Open
Collector überhaupt benötigt wird, weiß ich nicht, denn nach erstem
Durchmessen der Adreßdekodierung gehen die 4 Ausgänge zu einem 74LS139
(2 Stück 2-nach-4-Dekoder), der die /CS von SRAMs und EPROMs treibt, und
(vermutlich?) nichts mehr. Dann hätten die die OC-Typen statt der TS
(Tri-State)-Varianten der ROMs deswegen gewählt, damit der Pegel '1'
statt tri-state ist, wie ich aus einem Datenblatt zum 82S130/82S131
lese.

Hat so was schon mal jemand ersetzt und irgendwelche Hinweise, an die
ich noch nicht gedacht habe? Insbesondere bei der Open-Collector-Frage
bin ich nicht ganz schlüssig, wie ich das einordnen soll.

BTW eingebaut sind 6* 8kB-SRAMs mit Datecode aus dem Jahr 1985 (damals
relativ teure ICs), aber die eingebaute Dekodierung ist für 6* 2kB. Die
Sockel sollten sogar 32kB-JEDEC verkraften. Das muß ich allerdings noch
im großen Steckbrückenfeld durchklingeln. Damit ist meine Motivation
geklärt mindestens im 1. Schritt nicht gleich ein 20Euro-PROM zu
"zerschießen", falls ich mich irgendwie vertue.

Gruß, Ralf

[Volker Borchert]

Post by Ralf Kiefer
Mir ist eine Platine aus dem Jahr 1985 (Entwicklungsstand vermutlich
1983) zugelaufen, bei der die Adreßdekodierung teilweise mit Hilfe eines
bipolaren PROMs gemacht wird, eingebaut: AM27S12. Der Hersteller sah
vor, daß der engagierte Endanwender so was in Abhängigkeit der gewählten
Bestückung der SRAM- und EPROM-Sockel selbst macht, weswegen die
Generierung des Inhalts grob umrissen ist.

Wie kompliziert sind denn die Terme?

[Ralf Kiefer]

Post by Volker Borchert
Wie kompliziert sind denn die Terme?

Ziemlich einfach. Die Eingänge sind A12 bis A20 vom 68000, die Ausgänge,
wie beschrieben, 2* zwei für einen 74LS139. Der eine Dekoder vom 74LS139
ist für die SRAMs zuständig. D.h. im PROM wird die Adreßzuordnung für
die SRAM-Sockel so ausdekodiert, daß die SRAM-Sockel in Abhängigkeit der
Bestückung einen durchgehenden Adreßbereich abdecken. Ähnlich im anderen
Teil, der Dekodierung des EPROM-Teils. Irgendwelche Timing-Sachen sind
in diesem PROM nicht drin.

Gruß, Ralf

[Gerrit Heitsch]

Post by Ralf Kiefer

Post by Volker Borchert
Wie kompliziert sind denn die Terme?

Ziemlich einfach. Die Eingänge sind A12 bis A20 vom 68000, die Ausgänge,
wie beschrieben, 2* zwei für einen 74LS139. Der eine Dekoder vom 74LS139
ist für die SRAMs zuständig. D.h. im PROM wird die Adreßzuordnung für
die SRAM-Sockel so ausdekodiert, daß die SRAM-Sockel in Abhängigkeit der
Bestückung einen durchgehenden Adreßbereich abdecken. Ähnlich im anderen
Teil, der Dekodierung des EPROM-Teils. Irgendwelche Timing-Sachen sind
in diesem PROM nicht drin.

Wenn man nicht vorhat die Bestückung des RAMs dauernd zu ändern sondern
einfach 62256 einbaut kann man sich auch mit rein fester Dekodierung für
diese behelfen. Dürfte die Sache stark vereinfachen. Selbes für die ROMs.

Gerrit

[Ralf Kiefer]

Post by Gerrit Heitsch
Wenn man nicht vorhat die Bestückung des RAMs dauernd zu ändern sondern
einfach 62256 einbaut kann man sich auch mit rein fester Dekodierung für
diese behelfen. Dürfte die Sache stark vereinfachen.

Die erste Idee war, daß die eingebauten 6264 endlich mal komplett
genutzt werden statt nur im "6116-Modus". Ist ja peinlich sowas, wenn
mir das 30Jahre danach auffällt, daß viel mehr RAM eingebaut ist als
genutzt werden kann ;-)

Die nächste Idee kam, als irgendwo im Nebensatz erwähnt war, daß die
Sockel alternativ mit 32kB-EPROMs bestückt werden können. Schaunmermal.
Wenn's mit SRAMs geht, mache ich das. Dann bekommt diese Karte 192kB
SRAM und 64kB EPROM, aber das aktuelle Dekodier-PROM ist für 6* 6116 und
2* 27128, also 12kB SRAM und 32kB EPROM ausgelegt. Da ist nichts
gespiegelt und mehrfach vorhanden. Außerhalb der abgedeckten Bereiche
gibt's zuverlässig Bus Error.

Post by Gerrit Heitsch
Selbes für die ROMs.

Die Aufgabe vorher ist herauszufinden, wie die Resetvektordekodierung
geht.

Gruß, Ralf

[Gerrit Heitsch]

Post by Ralf Kiefer

Post by Gerrit Heitsch
Wenn man nicht vorhat die Bestückung des RAMs dauernd zu ändern sondern
einfach 62256 einbaut kann man sich auch mit rein fester Dekodierung für
diese behelfen. Dürfte die Sache stark vereinfachen.

Die erste Idee war, daß die eingebauten 6264 endlich mal komplett
genutzt werden statt nur im "6116-Modus". Ist ja peinlich sowas, wenn
mir das 30Jahre danach auffällt, daß viel mehr RAM eingebaut ist als
genutzt werden kann ;-)
Die nächste Idee kam, als irgendwo im Nebensatz erwähnt war, daß die
Sockel alternativ mit 32kB-EPROMs bestückt werden können. Schaunmermal.
Wenn's mit SRAMs geht, mache ich das. Dann bekommt diese Karte 192kB
SRAM und 64kB EPROM, aber das aktuelle Dekodier-PROM ist für 6* 6116 und
2* 27128, also 12kB SRAM und 32kB EPROM ausgelegt. Da ist nichts
gespiegelt und mehrfach vorhanden. Außerhalb der abgedeckten Bereiche
gibt's zuverlässig Bus Error.

Post by Gerrit Heitsch
Selbes für die ROMs.

Die Aufgabe vorher ist herauszufinden, wie die Resetvektordekodierung
geht.

Das ist alles was für verregnete Herbsttage und dunkle Winterabende.

Wenn ich das noch richtig weiss braucht man beim 68000 hier ein bisschen
Umschaltung damit beim Poweron ab $000000 ROM liegt um den RESET-Vektor
laden zu können und später ab $000000 RAM zu finden ist damit man die
Vektoren anpassen kann.

Ich hab noch irgendwo eine c't KAT-CE mit 68000-12, 128KB RAM und einem
etwas hemdsärmlich portierten Monitorprogramm im EPROM welches man über
RS232 anspricht.

Gerrit

[Ralf Kiefer]

Post by Gerrit Heitsch
Das ist alles was für verregnete Herbsttage und dunkle Winterabende.

Ich schaue nach draußen: Wind, Regen, 11Grad. Vorgestern waren es noch
über 20Grad. Der Herbst ist da.

Post by Gerrit Heitsch
Wenn ich das noch richtig weiss braucht man beim 68000 hier ein bisschen
Umschaltung damit beim Poweron ab $000000 ROM liegt um den RESET-Vektor
laden zu können und später ab $000000 RAM zu finden ist damit man die
Vektoren anpassen kann.

Nach dem Reset muß das ROM auf $0 dekodiert werden. Danach gibt's einige
unterschiedliche Varianten. Die einen zählen die Zugriffe (8, 4 oder 2)
und schalten dann auf die normale Dekodierung um. Andere schalten mit
dem ersten Zugriff aufs ROM um, d.h. wenn der erste Befehl aus dem ROM
gelesen wird. Wieder andere, z.B. die ersten Macs, machen die
Umschaltung software-gesteuert.

Post by Gerrit Heitsch
Ich hab noch irgendwo eine c't KAT-CE mit 68000-12, 128KB RAM und einem
etwas hemdsärmlich portierten Monitorprogramm im EPROM welches man über
RS232 anspricht.

Dank d.a.f.c werkelt hier auch eine KAT-Ce. Welche ROM-Version hast Du?
Und KAT-Cen jeglicher Art gewähre ich hier Asyl ;-) Die eine wird
gerade zum EPROM-Programmiergerät. Wenn nicht ständig was anderes
dazwischen käme, wäre die schon lange fertig ...

BTW die 68000-KAT-Ce macht die Resetvektorumschaltung mit dem ersten
Zugriff aufs EPROM.

Gruß, Ralf

[Gerrit Heitsch]

Post by Ralf Kiefer

Post by Gerrit Heitsch
Ich hab noch irgendwo eine c't KAT-CE mit 68000-12, 128KB RAM und einem
etwas hemdsärmlich portierten Monitorprogramm im EPROM welches man über
RS232 anspricht.

Dank d.a.f.c werkelt hier auch eine KAT-Ce. Welche ROM-Version hast Du?

Keine... Ich hab mir das Teil (sprich nur die Platine) damals gekauft
weil ich ein möglichst kleines System mit vollwertigem 68000 haben
wollte. Dann wurde ein simples Monitorprogramm auf das System portiert
und der Rest passierte dann per RS232 über einen Port des 68681. Die
ganze Sache grob übertaktet (12 MHz statt 8 MHz), schliesslich sind die
RAMs und EPROMs schnell genug, der I/O benutzt DTACK.

Post by Ralf Kiefer
BTW die 68000-KAT-Ce macht die Resetvektorumschaltung mit dem ersten
Zugriff aufs EPROM.

Das kann nicht stimmen, denn aus dem lädt es ja die Vektoren und da wäre
es fatal wenn der erste Zugriff gleich das EPROM ab $000000 wegschaltet.
Sicher, daß es nicht der erste Zugriff auf das RAM ist?

Gerrit

[Ralf Kiefer]

Post by Gerrit Heitsch

Post by Ralf Kiefer
BTW die 68000-KAT-Ce macht die Resetvektorumschaltung mit dem ersten
Zugriff aufs EPROM.

Das kann nicht stimmen, denn aus dem lädt es ja die Vektoren und da wäre
es fatal wenn der erste Zugriff gleich das EPROM ab $000000 wegschaltet.
Sicher, daß es nicht der erste Zugriff auf das RAM ist?

Mist, blöd ausgedrückt :-( Der erste Zugriff auf den normalen
Adreßraum des EPROMs schaltet das Einblenden ab $0 ab.

Gruß, Ralf

[Holm Tiffe]

Post by Gerrit Heitsch

Post by Ralf Kiefer

Post by Gerrit Heitsch
Ich hab noch irgendwo eine c't KAT-CE mit 68000-12, 128KB RAM und einem
etwas hemdsärmlich portierten Monitorprogramm im EPROM welches man über
RS232 anspricht.

Dank d.a.f.c werkelt hier auch eine KAT-Ce. Welche ROM-Version hast Du?

Keine... Ich hab mir das Teil (sprich nur die Platine) damals gekauft
weil ich ein möglichst kleines System mit vollwertigem 68000 haben
wollte. Dann wurde ein simples Monitorprogramm auf das System portiert
und der Rest passierte dann per RS232 über einen Port des 68681. Die
ganze Sache grob übertaktet (12 MHz statt 8 MHz), schliesslich sind die
RAMs und EPROMs schnell genug, der I/O benutzt DTACK.

Post by Ralf Kiefer
BTW die 68000-KAT-Ce macht die Resetvektorumschaltung mit dem ersten
Zugriff aufs EPROM.

Das kann nicht stimmen, denn aus dem lädt es ja die Vektoren und da wäre
es fatal wenn der erste Zugriff gleich das EPROM ab $000000 wegschaltet.
Sicher, daß es nicht der erste Zugriff auf das RAM ist?
Gerrit

Hier exakt das Selbe (Motorola FBUG portiert) ..um Ralfs Frage per Mail
nach meiner KatCe zu beantworten..
Auch ich habe die leere(n) Platinen einzeln gekauft.

Gruß,

Holm

[Christian Zietz]

Post by Ralf Kiefer
Nach dem Reset muß das ROM auf $0 dekodiert werden. Danach gibt's einige
unterschiedliche Varianten. Die einen zählen die Zugriffe (8, 4 oder 2)
und schalten dann auf die normale Dekodierung um. Andere schalten mit
dem ersten Zugriff aufs ROM um, d.h. wenn der erste Befehl aus dem ROM
gelesen wird. Wieder andere, z.B. die ersten Macs, machen die
Umschaltung software-gesteuert.

Wieder andere, z.B. die gesamte Atari-Reihe mit 68k, mappen einfach
$0-$7 dauerhaft ins ROM. So verliert man natürlich 8 Bytes kostbares
RAM; davon abgesehen ist das aber wohl die einfachste Lösung. Sicher
dass Dein Board nicht auch einfach genau das macht?

Grüße
Christian

[Gerrit Heitsch]

Post by Christian Zietz

Post by Ralf Kiefer
Nach dem Reset muß das ROM auf $0 dekodiert werden. Danach gibt's einige
unterschiedliche Varianten. Die einen zählen die Zugriffe (8, 4 oder 2)
und schalten dann auf die normale Dekodierung um. Andere schalten mit
dem ersten Zugriff aufs ROM um, d.h. wenn der erste Befehl aus dem ROM
gelesen wird. Wieder andere, z.B. die ersten Macs, machen die
Umschaltung software-gesteuert.

Wieder andere, z.B. die gesamte Atari-Reihe mit 68k, mappen einfach
$0-$7 dauerhaft ins ROM. So verliert man natürlich 8 Bytes kostbares
RAM; davon abgesehen ist das aber wohl die einfachste Lösung.

Leider hat diese Lösung den Nachteil, daß man den Reset-Vector nicht
verbiegen kann, OK, man meinte wohl, daß braucht man nie.

Gerrit

[Christian Zietz]

Post by Gerrit Heitsch

Post by Christian Zietz
Wieder andere, z.B. die gesamte Atari-Reihe mit 68k, mappen einfach
$0-$7 dauerhaft ins ROM. So verliert man natürlich 8 Bytes kostbares
RAM; davon abgesehen ist das aber wohl die einfachste Lösung.

Leider hat diese Lösung den Nachteil, daß man den Reset-Vector nicht
verbiegen kann, OK, man meinte wohl, daß braucht man nie.

Braucht man auch nicht. Eines der ersten Dinge, das TOS nach dem Reset
macht, ist nach Magic-Numbers im RAM [1] zu suchen und im Erfolgsfall an
eine ebenfalls im RAM stehende Adresse zu springen. Somit kann man sich
auch mit der oben beschriebenen Lösung in den Reset einklinken.

Grüße
Christian
[1] ... und im Adressbereich des Cartridge-Ports...

[Ralf Kiefer]

Post by Gerrit Heitsch
Leider hat diese Lösung den Nachteil, daß man den Reset-Vector nicht
verbiegen kann, OK, man meinte wohl, daß braucht man nie.

Wenn man den Reset-Vektor aus dem RAM nehmen möchte, muß die initiale
Ummap-Logik den Unterschied zwischen Kaltstart und Reset-Leitung kennen.
Manche 68k-Hardware nimmt Reset als Kriterium fürs Ummappen.

Trotzdem ein guter Hinweis :-) Im Code kommt mittendrin ein
Reset-Befehl vor.

Gruß, Ralf

[Ralf Kiefer]

Post by Christian Zietz
Wieder andere, z.B. die gesamte Atari-Reihe mit 68k, mappen einfach
$0-$7 dauerhaft ins ROM.

Ok, die Ataris kenne ich zu wenig.

Post by Christian Zietz
So verliert man natürlich 8 Bytes kostbares
RAM; davon abgesehen ist das aber wohl die einfachste Lösung.

Man muß ziemlich viele Adreßleitungen dekodieren, d.h. man braucht
Gatter. Wenn man wie im Atari sowieso einen großen Chip für die gesamte
Board-Organisation hat, dann geht das.

Post by Christian Zietz
Sicher
dass Dein Board nicht auch einfach genau das macht?

Das macht diese Platine sicher nicht, denn auf dieser Platine gibt's
nicht viel hochintegriertes. Ein 16R4 ist drauf, das angesprochene PROM
und sonst alles in 74[L]Sxx gebaut, d.h. das gesamte VMEbus-Interface
mit Slot-1-Funktion und Arbiter belegt schon geschätzt ein Drittel der
Platinenfläche. 40% Platinenfläche sind belegt mit SRAM, EPROM und den
IO-Chips.

BTW im SRAM steht im laufenden Betrieb von $0 bis $7 irgendwas
Zufälliges, nur keine gültige Adressen.

Gruß, Ralf

[Peter Heitzer]

Post by Gerrit Heitsch

Post by Ralf Kiefer

Post by Gerrit Heitsch
Wenn man nicht vorhat die Bestückung des RAMs dauernd zu ändern sondern
einfach 62256 einbaut kann man sich auch mit rein fester Dekodierung für
diese behelfen. Dürfte die Sache stark vereinfachen.

Die erste Idee war, daß die eingebauten 6264 endlich mal komplett
genutzt werden statt nur im "6116-Modus". Ist ja peinlich sowas, wenn
mir das 30Jahre danach auffällt, daß viel mehr RAM eingebaut ist als
genutzt werden kann ;-)
Die nächste Idee kam, als irgendwo im Nebensatz erwähnt war, daß die
Sockel alternativ mit 32kB-EPROMs bestückt werden können. Schaunmermal.
Wenn's mit SRAMs geht, mache ich das. Dann bekommt diese Karte 192kB
SRAM und 64kB EPROM, aber das aktuelle Dekodier-PROM ist für 6* 6116 und
2* 27128, also 12kB SRAM und 32kB EPROM ausgelegt. Da ist nichts
gespiegelt und mehrfach vorhanden. Außerhalb der abgedeckten Bereiche
gibt's zuverlässig Bus Error.

Post by Gerrit Heitsch
Selbes für die ROMs.

Die Aufgabe vorher ist herauszufinden, wie die Resetvektordekodierung
geht.

Das ist alles was für verregnete Herbsttage und dunkle Winterabende.
Wenn ich das noch richtig weiss braucht man beim 68000 hier ein bisschen
Umschaltung damit beim Poweron ab $000000 ROM liegt um den RESET-Vektor
laden zu können und später ab $000000 RAM zu finden ist damit man die
Vektoren anpassen kann.

Oder man verschenkt etwas Performance und baut Sprungbefehle in's RAM ein.
Dann kann ab 0x000000 auch ROM liegen. Ist halt nur für Systeme mit festem
Speicherausbau praktikabel und hat den Nachteil, daß dann u.U.
Interruptvektoren im Usermode änderbar sind.

[Marcel Mueller]

Post by Ralf Kiefer
Mir ist eine Platine aus dem Jahr 1985 (Entwicklungsstand vermutlich
1983) zugelaufen, bei der die Adreßdekodierung teilweise mit Hilfe eines
bipolaren PROMs gemacht wird, eingebaut: AM27S12. Der Hersteller sah
vor, daß der engagierte Endanwender so was in Abhängigkeit der gewählten
Bestückung der SRAM- und EPROM-Sockel selbst macht, weswegen die
Generierung des Inhalts grob umrissen ist. Zuerst dachte ich, daß es
diese PROMs schon lange nicht mehr zu kaufen gäbe. Nicht ganz :-) Bei
Ebay werden noch welche angeboten. Stolze Preise, aber vorhanden.

Was hat der Bursche denn für eine Pinbelegung? Kann man da nicht
irgendetwas anderes rein stecken? Zum S12 finde ich nichts, nur zum S13.

Ich hätte jetzt gesagt, GAL16V8 nehmen, Pins auf der Masse-Seite
überstehen lassen, und den GND-Pin mit einer Lötbrücke am Chip so mit
dem passenden Eingang verbinden, dass er Saft bekommt.

Post by Ralf Kiefer
Details: AM27S12, ein 512*4 PROM mit Open Collector, also 9 Eingänge und
4 Ausgänge. Vergleichstypen sind Signetics 82S130 und Harris 7620.
Das Detail "Open Collector" sieht mir nach einer "Aufgabe" aus. Denn
mein nächster Gedanke war ein GAL 16V8 zu nehmen, und das in einen
Sockeladapter von 20pol. (GAL) auf 16pol. (PROM) zu basteln.

Meine Rede :-)

Post by Ralf Kiefer
Ob Open
Collector überhaupt benötigt wird, weiß ich nicht, denn nach erstem
Durchmessen der Adreßdekodierung gehen die 4 Ausgänge zu einem 74LS139
(2 Stück 2-nach-4-Dekoder), der die /CS von SRAMs und EPROMs treibt, und
(vermutlich?) nichts mehr. Dann hätten die die OC-Typen statt der TS
(Tri-State)-Varianten der ROMs deswegen gewählt, damit der Pegel '1'
statt tri-state ist, wie ich aus einem Datenblatt zum 82S130/82S131
lese.

Notfalls Schottky-Dioden dazwischen.

Post by Ralf Kiefer
Hat so was schon mal jemand ersetzt und irgendwelche Hinweise, an die
ich noch nicht gedacht habe?

Sowas nicht, aber andere Chips schon. Ich hatte mal eine Schaltung, die
die üblichen 744x 7-Segment Dekoder drin hatten. Der habe ich mit einem
GAL ein Upgrade auf Hex-Fähigkeit verpasst.

Post by Ralf Kiefer
Insbesondere bei der Open-Collector-Frage
bin ich nicht ganz schlüssig, wie ich das einordnen soll.

Schaltung analysieren, ob es wirklich erforderlich ist.
Mit einem GAL bekommt man das mit ein paar Tricks auch hin, indem man
die 4 unbenutzten Eingänge auf OE der anderen 4 rückkoppelt. Aber da
reicht der Trick mit dem überstehenden Chip dann nicht mehr. Da muss
wirklich ein Adapter her.


Marcel

[Ralf Kiefer]

Post by Marcel Mueller

Post by Ralf Kiefer
Mir ist eine Platine aus dem Jahr 1985 (Entwicklungsstand vermutlich
1983) zugelaufen, bei der die Adreßdekodierung teilweise mit Hilfe eines
bipolaren PROMs gemacht wird, eingebaut: AM27S12. Der Hersteller sah
vor, daß der engagierte Endanwender so was in Abhängigkeit der gewählten
Bestückung der SRAM- und EPROM-Sockel selbst macht, weswegen die
Generierung des Inhalts grob umrissen ist. Zuerst dachte ich, daß es
diese PROMs schon lange nicht mehr zu kaufen gäbe. Nicht ganz :-) Bei
Ebay werden noch welche angeboten. Stolze Preise, aber vorhanden.

Was hat der Bursche denn für eine Pinbelegung? Kann man da nicht
irgendetwas anderes rein stecken? Zum S12 finde ich nichts, nur zum S13.

Das sind die "Brüder" von Signetics (136kB):
www.ralf-kiefer.de/VME/82S130.pdf
Der S13 hat Tri-state-Ausgänge, der S12 Open Collector. D.h. die Matrix
innen ist dieselbe.

Post by Marcel Mueller
Ich hätte jetzt gesagt, GAL16V8 nehmen, Pins auf der Masse-Seite
überstehen lassen, und den GND-Pin mit einer Lötbrücke am Chip so mit
dem passenden Eingang verbinden, dass er Saft bekommt.

Mein Gedanke :-) Das paßt sogar mechanisch.

Post by Marcel Mueller
Notfalls Schottky-Dioden dazwischen.

Danke für den Hinweis.

Post by Marcel Mueller
Schaltung analysieren, ob es wirklich erforderlich ist.

Problem: ich habe die Platine in Multilayer und keinen Stromlaufplan.
Den Teil mit der Belegung der Ein- und Ausgänge vom PROM herauszufinden
war noch einfach, weil sich das aus der kurzen Beschreibung im
Produktkatalog ergab.

Post by Marcel Mueller
Mit einem GAL bekommt man das mit ein paar Tricks auch hin, indem man
die 4 unbenutzten Eingänge auf OE der anderen 4 rückkoppelt. Aber da
reicht der Trick mit dem überstehenden Chip dann nicht mehr. Da muss
wirklich ein Adapter her.

Wenn ich einen etwas größeren Adapter bauen müßte, kam mir die Idee
einen 7406 oder 7407 an die Ausgänge vom PROM zu basteln. Die Lösung im
GAL fände ich allerdings eher lehrreich für mich :-)

Gruß, Ralf

[Marcel Mueller]

Post by Ralf Kiefer

Post by Marcel Mueller
Schaltung analysieren, ob es wirklich erforderlich ist.

Problem: ich habe die Platine in Multilayer und keinen Stromlaufplan.
Den Teil mit der Belegung der Ein- und Ausgänge vom PROM herauszufinden
war noch einfach, weil sich das aus der kurzen Beschreibung im
Produktkatalog ergab.

Hast Du ein Oszi? Falls es ein altes Hameg ist, könnte man mit dem
Komponententester mal die Impedanz an den Pins (ohne Chip) im
eingeschalteten Zustand abklappern. Pull-Ups sieht man damit ziemlich
schnell; andere Ausgänge, die gerade etwas auf Masse ziehen auch.

Bei anderen Oszis geht das auch im XY-Modus mit einem 12V
Wechselstromtrafo und einem 10k-Widerstand. Die Oszi-Masse muss dann
aber zwischen 10k-Widerstand und Messobjekt.

Alternativ ein bekanntes (Open-Kollektor) Rechteck-Signal drauf geben,
und dann mit dem Oszi über die Pins der anderen ICs ratschen, wo man es
findet. Wenn ein OC-Ausgang dabei ist => :-(

Post by Ralf Kiefer

Post by Marcel Mueller
Mit einem GAL bekommt man das mit ein paar Tricks auch hin, indem man
die 4 unbenutzten Eingänge auf OE der anderen 4 rückkoppelt. Aber da
reicht der Trick mit dem überstehenden Chip dann nicht mehr. Da muss
wirklich ein Adapter her.

Wenn ich einen etwas größeren Adapter bauen müßte, kam mir die Idee
einen 7406 oder 7407 an die Ausgänge vom PROM zu basteln. Die Lösung im
GAL fände ich allerdings eher lehrreich für mich :-)

Wobei die Dinger mittlerweile auch Abandonware sind.


Marcel

[Ralf Kiefer]

Post by Marcel Mueller
Hast Du ein Oszi?

Nur ein sehr einfaches Siemens-Gerät aus den späten 1960er Jahren, aber
immerhin Zweikanal.

Post by Marcel Mueller
Bei anderen Oszis geht das auch im XY-Modus mit einem 12V
Wechselstromtrafo und einem 10k-Widerstand. Die Oszi-Masse muss dann
aber zwischen 10k-Widerstand und Messobjekt.

Ich glaube, daß ich mehr Informatiker als E-Techniker bin ... Soll
heißen, daß ich diesen Ansatz nicht verstanden habe.

Post by Marcel Mueller
Alternativ ein bekanntes (Open-Kollektor) Rechteck-Signal drauf geben,
und dann mit dem Oszi über die Pins der anderen ICs ratschen, wo man es
findet. Wenn ein OC-Ausgang dabei ist => :-(

Durchklingeln mit dem Multimeter, vorzugsweise bei den Chips, bei denen
OC-Ausgänge bekannt sind.

Post by Marcel Mueller

Post by Ralf Kiefer
Wenn ich einen etwas größeren Adapter bauen müßte, kam mir die Idee
einen 7406 oder 7407 an die Ausgänge vom PROM zu basteln. Die Lösung im
GAL fände ich allerdings eher lehrreich für mich :-)

Wobei die Dinger mittlerweile auch Abandonware sind.

Die sind bei mir die Grenze dessen, was ich ohne Klimmzüge schaffe. Ich
habe hier einen PALASM laufen und die Möglichkeit die kleineren GALs zu
programmieren. Zudem habe ich etliche von denen als Vorrat, vorzugsweise
sogar 22V10 und nur noch sehr wenige 16V8.

Gruß, Ralf

[Holm Tiffe]

Post by Ralf Kiefer
sogar 22V10 und nur noch sehr wenige 16V8.
Gruß, Ralf

Da kann ich helfen (tauschen)

Gruß,

Holm

[Christian Corti]

Post by Ralf Kiefer
Wenn ich einen etwas größeren Adapter bauen müßte, kam mir die Idee
einen 7406 oder 7407 an die Ausgänge vom PROM zu basteln. Die Lösung im
GAL fände ich allerdings eher lehrreich für mich :-)

OC mit einem GAL zu realisieren ist einfach. Man schiebt die Gleichungen
zum Output Enable, und die eigentliche Pin-Gleichung ist konstant Null.

Hier ein Beispiel für ein PROM, das ich durch ein 16V8 ersetzt habe:

; M7681 RK05 ROM 139A1 (position E1)

chip condcode gal16v8

; Pinbelegung:
; 1 2 3 4 5 6 7 8 9 10
nc nc /ENA /A4 /A3 /A2 /A1 /A0 nc gnd

; 11 12 13 14 15 16 17 18 19 20
nc nc D6 D5 D4 D3 D2 D1 D0 vcc

equations

D0 = gnd
D1 = gnd
D2 = gnd
D3 = gnd
D4 = gnd
D5 = gnd
D6 = gnd

D0.oe = ENA & /A0
D1.oe = ENA & /A1
D2.oe = ENA & /A2
D3.oe = ENA & /A3
D4.oe = ENA & /A4
D5.oe = ENA & A0 & A1 & A2 & A3 & A4
D6.oe = ENA


Christian

[Ralf Kiefer]

Post by Christian Corti
OC mit einem GAL zu realisieren ist einfach.

Ok, ich muß noch etwas über Deine Gleichungen nachdenken :-) Das
ersetzte PROM ist ein M7681. Dazu finde ich den Vergleichstyp 82S181,
d.h 3-State-Ausgänge, kein Open Collector.

BTW der Einwand von Marcel wg. der Pullups mit 1k0 spielt auch 'ne
Rolle. Da stehe ich vor der Frage, ob ich an der originalen,
funktionstüchtigen Platine löte und evtl. was kaputt mache, oder ob ich
einen reversiblen Ersatz in den vorhandenen Sockel vom PROM stecke und
das Original original sein lasse. Denn wenn ich ein oder zwei Varianten
mit GALs getestet habe, könnte ich immer noch auf die Idee kommen zwei
PROMs zu kaufen und das Angebot von Patrick anzunehmen mir diese PROMs
zu programmieren.

Ich habe mit den Anregungen der Diskussion mit dem Piepser in der
Platine herumgestochert und komme gerade zu folgendem, vagen Bild:
Die OC-Ausgänge vom PROM treiben einzig die Eingänge vom 74LS139 (nicht
gesichert, nur ziemlich wahrscheinlich), der die /CS der EPROM- und
SRAM-Sockel generiert. Das Einblenden vom EPROM anstelle des SRAM nach
dem externen Reset wg. des Resetvektors passiert mit einer Logik vor dem
PROM und steuert das /OE von diesem. Ist das PROM per /OE disabled, dann
ziehen die Pullups die Eingänge vom 74LS139 nach High, so daß
aufgrunddessen der 74LS139 die /CS der EPROM-Sockel selektiert, in denen
das Boot-EPROM steckt. Die Resetvektorlogik scheint auf dem Zählen von
Zugriffen zu basieren. Mit Piepsen (und Bauchgefühl :-) ) suchte ich
einen Pfad vom /AS des 68000 zum /OE des PROM. Einer führt durch ein
74LS164 (Schieberegister), in dem offensichtlich bis auf 4 gezählt wird,
also 4* /AS für 16bit-Zugriffe ergeben die beiden 32bit-Vektoren, die
ein 68000 nach dem externen Reset zum Start benötigt.

Ich werde als nächstes das PROM auslesen, also irgendwas mit Steckbrett
an 'nem Rechner mit GPIOs machen, und nachschauen, ob das drin steht,
was ich erwarte. Offen ist jetzt wider Erwarten, was die beiden anderen
Ausgänge vom PROM ansteuern. Meine ursprüngliche Annahme hat sich beim
Herumstochern widerlegt.

Gruß, Ralf

[Peter Heitzer]

Post by Ralf Kiefer

Post by Christian Corti
OC mit einem GAL zu realisieren ist einfach.

Ok, ich muß noch etwas über Deine Gleichungen nachdenken :-) Das
ersetzte PROM ist ein M7681. Dazu finde ich den Vergleichstyp 82S181,
d.h 3-State-Ausgänge, kein Open Collector.

Vielleicht ist das PROM für unterschiedliche Baugruppen gedacht. Bei
OC kann man u.U. auf einen weiteren Dekoder verzichten und nur die
Wired-Or Funktion verwenden. Das gibt dann halt eher gröbere Speicherblöcke.

[Ralf Kiefer]

Post by Peter Heitzer
Bei
OC kann man u.U. auf einen weiteren Dekoder verzichten und nur die
Wired-Or Funktion verwenden. Das gibt dann halt eher gröbere Speicherblöcke.

Auf meiner Baugruppe ist alles pingelig ausdekodiert. Weder RAM noch ROM
sind im Adreßraum gespiegelt. Da kommt ein "sauberes" Timeout, falls ein
Zugriff auf "nichts" stattfindet. Konkret wird wohl aus den einzelnen
/CS das /DTACK generiert.

Gruß, Ralf

[Christian Corti]

Post by Ralf Kiefer
Ok, ich muß noch etwas über Deine Gleichungen nachdenken :-) Das
ersetzte PROM ist ein M7681. Dazu finde ich den Vergleichstyp 82S181,
d.h 3-State-Ausgänge, kein Open Collector.

Äh, M7681 ist eine DEC-Nummer für die Steckkarte, die im
RK05-Plattenlaufwerk steckt (ich glaube Cylinder address and difference)
Die PROM-Nummer habe ich jetzt nicht im Kopf, müßte ich nachschauen
gehen. Ist aber ein OC-Typ.

Christian

[Ralf Kiefer]

Post by Christian Corti
Äh, M7681 ist eine DEC-Nummer für die Steckkarte

... ist aber auch ein bipolares Harris-PROM mit 1024*8. Gut, daß wir
drüber geredet haben ;-)

Wenn ich beim Spielen mit den GALs ankomme, werde ich auf Deine Idee im
GAL zurückkommen.

Gruß, Ralf

[Patrick Schaefer]

Post by Ralf Kiefer
Ok, ich muß noch etwas über Deine Gleichungen nachdenken :-) Das
ersetzte PROM ist ein M7681. Dazu finde ich den Vergleichstyp 82S181,
d.h 3-State-Ausgänge, kein Open Collector.

Jedes EPROM (und jedes RAM) hat Tristate-Ausgänge. Es gibt dann einen
Pin, der "Output Enable" heisst. Darüber schaltet man aber alle Ausgänge
gleichzeitg ab, der Chip ist dann quasi unsichtbar.

Mit open collector ist der Chip nur bei High unsichtbar, Low kommt aber
durch. Und das ist für jede Datenleitung unabhängig möglich. Daher muss
bei der Emulation per GAL das OE pin-selektiv angesprochen werden
(complex mode), nicht global. Eben wie in dem Beispiel.

Post by Ralf Kiefer
BTW der Einwand von Marcel wg. der Pullups mit 1k0 spielt auch 'ne
Rolle.

Ein GAL kann locker 16 mA nach Masse treiben, oft auch 24 mA. Wie ein
guter alter Std-TTL. 1 kOhm Pullup sind da kein Problem, selbst die 330
Ohm vom Z80-Clockpin wären noch machbar. Warm wird das Ding natürlich,
aber Bipolaproms heizen genauso.

Post by Ralf Kiefer
Die OC-Ausgänge vom PROM treiben einzig die Eingänge vom 74LS139

Wird denn in der Dokumentation irgendwo zwingend OC verlangt? Oder kann
man einbauen was gerade da ist? Vielleicht ist es Zufall, dass Du gerade
eins mit OC erwischt hast.


Gruß
Patrick

[Ralf Kiefer]

Post by Patrick Schaefer
Mit open collector ist der Chip nur bei High unsichtbar, Low kommt aber
durch.

So herum habe ich drüber nachgedacht, wie sich die Schaltung im einen
oder anderen Fall verhalten könnte.

Post by Patrick Schaefer

Post by Ralf Kiefer
BTW der Einwand von Marcel wg. der Pullups mit 1k0 spielt auch 'ne
Rolle.

Ein GAL kann locker 16 mA nach Masse treiben, oft auch 24 mA. Wie ein
guter alter Std-TTL. 1 kOhm Pullup sind da kein Problem, selbst die 330
Ohm vom Z80-Clockpin wären noch machbar.

Ich bin im Punkt eigenes Schaltungsdesign eher nicht so fit. Ich
interpretiere meist nur die Schaltungen anderer Leute. Insofern sehe ich
jetzt nur, daß ihr nicht ganz einer Meinung seid.

Dann gehe ich einfach davon aus, daß ich trotz des Widerstandsnetzes mit
1k, das ich nicht auslöten möchte, ein GAL nehme, weil ich zwischen dem
PROM und dem 74LS139 keinen weiteren Anschluß an diesem Signal sehe. Die
Funktion vom Pullup ist mir mittlerweile einleuchtend. Siehe anderes
Posting von mir: nach dem (externen) Reset wird für die ersten 4
16bit-Zugriffe einfach das /OE vom PROM nicht eingeschaltet, so daß die
Pullups dadurch den LS139 so schalten, daß das gewünschte
(EPROM-)Sockelpaar eingeblendet wird.

Post by Patrick Schaefer
Wird denn in der Dokumentation irgendwo zwingend OC verlangt?

Es gibt keine Doku :-( Bitsavers hat gar nichts, und auch eine andere
Quelle in Herstellernähe, wo ich berechtigte Hoffnung hatte, hat nichts
mehr. Aus der Beschreibung von einem uralten MVMEbug habe ich heute
immerhin ein paar Hinweise auf die Funktion der vielen
Steckbrückengruppen erhalten.

Vorhin habe ich das 3*7-pinnige Jumper-Feld, das für jedes
JEDEC-Sockelpaar existiert, durchgeklingelt, weil ich außer drei
Varianten nichts habe. Das ist übrigens sehr interessant, wie man mit
solch einem kompakten Jumper-Feld SRAMs mit 2kB, 8kB und 32kB sowie alle
EPROMs zwischen 2716 und 27256 abdecken kann. In 16bit. Ein echtes
Kunstwerk :-) Ich bin zuversichtlich, daß ich dem Rechner statt 12kB
RAM und 32kB ROM demnächst 192kB RAM und 64kB ROM spendieren kann, so
wie der Maximalausbau vorgesehen war.

Weil außerdem die Dekodierung optimal gelöst ist, könnte ich bei Bedarf
auf dem VMEbus eine deutlich modernere 16MB-RAM-Karte dazustecken, die
sämtliche Adreßraumlücken füllt, so daß ich einen 68000-Rechner haben
kann, der 15,9MB RAM hat und nur 64kB für ROM und 68kB für IO
verbraucht. Mir fällt dafür zwar keine Anwendung ein ...

Post by Patrick Schaefer
Oder kann
man einbauen was gerade da ist? Vielleicht ist es Zufall, dass Du gerade
eins mit OC erwischt hast.

Ich habe nochmal Fotos im Web gesucht. Ich habe keins gefunden, wo ich
die Beschriftung zweifelsfrei entziffern kann. Bei einem ist
wahrscheinlich an dieser Stelle ein 82S130 drauf, also OC. Beim anderen
sieht's nach einem MMI 63S241 aus. Und das ist ein 3-State!

Fazit: Ich werde es mit einem GAL ohne Tricks und ohne Open Collector
probieren. Wenn's blöd läuft, kostet es das GAL und sehr
unwahrscheinlich den eingelöteten LS139. Nach dem, was ich jetzt über
die Schaltung weiß, glaube ich nicht, daß die sich spontan in Rauch
verwandeln :-)

Gruß, Ralf

P.S.: Laß Dir Zeit mit dem Anwärmen vom Data IO :-) Ich brauche jetzt
etwas mehr Zeit, bis ich die ein bis zwei Satz Gleichungen haben werde,
die funktionieren.

[Volker Borchert]

Post by Ralf Kiefer
Weil außerdem die Dekodierung optimal gelöst ist, könnte ich bei Bedarf
auf dem VMEbus eine deutlich modernere 16MB-RAM-Karte dazustecken, die
sämtliche Adreßraumlücken füllt, so daß ich einen 68000-Rechner haben
kann, der 15,9MB RAM hat und nur 64kB für ROM und 68kB für IO
verbraucht. Mir fällt dafür zwar keine Anwendung ein ...

*BSD drauf und als Router benutzen.

[Ralf Kiefer]

Post by Volker Borchert
*BSD drauf und als Router benutzen.

Dafür würde ich eine größere CPU nehmen, und dazu noch ein paar
netzwerktaugliche Interfaces. Sogar Cisco nahm vor 20Jahren schon 68030
in der 2500-Baureihe für zwei 10Mbit-Ethernet-Ports. Mit dem 68000 müßte
man für solch eine Anwendung arger Idealist sein, wenn ich zum
Mikrotik-Router rüberschaue: 850MHz MIPS, 64MB RAM, 5* 100BaseTX für
80mA @12V, dazu RouterOS.

*Eine* interessante Idee habe ich für den 68000 :-) Da wird ein UCSD
p-System drauf gebaut, wofür die 192kB genau reichen. Nur braucht's
dafür einen Massenspeicheranschluß, also doch eine zweite Karte.
Schaunmermal.

Mit der Runtime-Version vom OS-9 ginge zeitgerecht auch was, nur habe
ich dafür keinerlei Anwendung, auch nicht, wenn ich den Speicher auf
128kB RAM und 128kB ROM aufteilen würde.

Mit geeignetem Massenspeicher gäbe es zeitgerecht VersaDOS. Ich fürchte
nur, daß es dafür auf dieser Welt keine Medien mehr gibt. Papier dazu
wäre immerhin vorhanden.

CP/M-68k? Habe ich zwar mal was drauf gemacht, aber dabei leiert mir
immer der Ctrl-C-Finger aus ;-)

Eine Eumel-Installation wäre ebenso zeitgerecht. Aber ab hier wird's
schon sehr exotisch. Doch nicht unbedingt, denn ich sehe gerade, daß das
heute noch auf Github gepflegt wird. Unglaublich :-)

Gruß, Ralf

[Volker Borchert]

Post by Ralf Kiefer
*Eine* interessante Idee habe ich für den 68000 :-) Da wird ein UCSD
p-System drauf gebaut, wofür die 192kB genau reichen. Nur braucht's
dafür einen Massenspeicheranschluß, also doch eine zweite Karte.

+1

Würde man das auch als Gast in einem NetBSD-1.5.1 oder SunOS-4.1.1_U1
auf einer 3/80 in Gang bekommen?

[Ralf Kiefer]

Post by Volker Borchert

[UCSD p-System]

Würde man das auch als Gast in einem NetBSD-1.5.1 oder SunOS-4.1.1_U1
auf einer 3/80 in Gang bekommen?

Was meinst Du mit Gast?

Ein UCSD p-System ist heute ganz einfach :-) Du brauchst Compiler und
Assembler, die Code fürs Zielsystem erzeugen, wenn's p-System als
alleiniges System drauf laufen soll.

Mario Klebsch ( www.klebsch.de ), früher auch mal hier, schrieb den
p-Code-Interpreter in C. Der ist auf dem Stand vom Apple Pascal, also
II.1. Dazu braucht man ein BIOS für die zugrundeliegende Hardware. Das
ist bei Single-Tasking und solch kleinen Rechnern mit wenig IO kein
Hexenwerk. Massenspeicher und Terminal, auch über eine serielle
Schnittstelle, reichen im 1. Schritt. Später kann man Drucker und die
frei nutzbare serielle Schnittstelle ergänzen. Als Massenspeicher im
BIOS genügt ein blockorientiertes Gerät mit 512Byte-Blöcken, dazu ein
Programm, das ein Dateisystem anlegen kann, bei Disketten also einen
Formatierer. Das Terminal kann man aus einer kleinen Liste auswählen. Es
gibt so was ähnliches wie Termcap auf Benutzerebene. Die den meisten
bekannte 80-Zeichen-Ausgabe im Apple II basierte auf der Emulation von
irgendeinem Hazeltine-Terminal.

Wenn man eine Grafikausgabe zur Verfügung hat, kann man später noch die
Turtlegraphics anpassen.

Der p-Code-Interpreter spielt eine 16bit-CPU mit zwei Adreßräumen je
64kB für Code und für Daten. Dazu hat sie ein paar Register sowie Stack
und Heap usw. Alle wichtigen Komponenten vom p-System laufen als p-Code,
d.h. die Zentrale "Command", der Filer, Editoren, Compiler, Assembler,
Linker und Anwenderprogramme. Als Compiler gibt's damit Pascal und
Fortran 77. Ob der Modula-2-Compiler mit diesem p-Code-Interpreter
läuft, weiß ich nicht. Evtl. hat der sich etwas geändert, denn die
Modula-Umgebung läuft unter p-System IV.0. Mir fehlt da noch 'ne ganze
Menge an Wissen, um diese Entwicklung ab Mitte der 1970er Jahre
einordnen zu können.

Du kannst das p-System natürlich auch als Prozeß in einer ganz anderen
Umgebung bauen. Das war der Ansatz von Mario.

Gruß, Ralf

[Patrick Schaefer]

Post by Ralf Kiefer
Details: AM27S12, ein 512*4 PROM mit Open Collector, also 9 Eingänge
und 4 Ausgänge. Vergleichstypen sind Signetics 82S130 und Harris 7620.

Könnte ich Dir brennen. Mein Data IO Sprint Expert kann sowas. Zu
Apple's Zeiten wurden Bipolarproms regelmässig als Adressdecoder oder
Statemachines eingesetzt.

Post by Ralf Kiefer
Das Detail "Open Collector" sieht mir nach einer "Aufgabe" aus. Denn
mein nächster Gedanke war ein GAL 16V8 zu nehmen, und das in einen
Sockeladapter von 20pol. (GAL) auf 16pol. (PROM) zu basteln. Ob Open
Collector überhaupt benötigt wird, weiß ich nicht, denn nach erstem
Durchmessen der Adreßdekodierung gehen die 4 Ausgänge zu einem 74LS139
(2 Stück 2-nach-4-Dekoder), der die /CS von SRAMs und EPROMs treibt, und
(vermutlich?) nichts mehr. Dann hätten die die OC-Typen statt der TS
(Tri-State)-Varianten der ROMs deswegen gewählt, damit der Pegel '1'
statt tri-state ist, wie ich aus einem Datenblatt zum 82S130/82S131
lese.

Mit open collector und externem Pullup hast Du auch bei teilweise
programmiertem PROM sinnvolle Pegel an den Ausgängen. Den GAL16V8
müsstest Du im Complex mode programmieren mit einem Produktterm als /OE
pro Ausgang. Wenn ein Term nicht reicht müsste man einen zweiten Kanal
nehmen und darauf zurückführen. Oder wirklich Dioden in Reihe zu den
Ausgängen schalten.

Falls open collector benötigt wird, ist der AM27S13 mit
Tristate-Ausgängen keine Alternative. Dessen /OE schaltet alle Ausgänge
gemeinsam ab (wie bei 2716 ff).


Patrick

[Patrick Schaefer]

Post by Patrick Schaefer
Mit open collector und externem Pullup hast Du auch bei teilweise
programmiertem PROM sinnvolle Pegel an den Ausgängen.

EDIT: das ist blödsinn, denn unprogrammiert steht 0xFF drin, also
Highpegel.

Damit wäre der einzige Vorteil von open collector, dass man mehrere
Ausgänge zusammenfassen kann. So könnte z.B. das PROM drei
Adressbereiche decodieren, wo in Hardware immer der gleiche Baustein
eingeblendet wird. RAM war damals teuer, daher ist nicht jeder mit
Vollausbau gestartert. Dazu müsste aber ein Wrapfeld vorhanden sein.



Patrick

[Volker Borchert]

Post by Patrick Schaefer
Damit wäre der einzige Vorteil von open collector, dass man mehrere
Ausgänge zusammenfassen kann. So könnte z.B. das PROM drei
Adressbereiche decodieren, wo in Hardware immer der gleiche Baustein
eingeblendet wird. RAM war damals teuer, daher ist nicht jeder mit
Vollausbau gestartert.

Unterschiedliche Ausbaustufen mit inhaltsgleichen PROMs? Möglich.
Aber wozu dann die mitgelieferte Anleitung?

Post by Patrick Schaefer
Dazu müsste aber ein Wrapfeld vorhanden sein.

Im OP stand was von "großen Steckbrückenfeld".

[Ralf Kiefer]

Post by Volker Borchert
Im OP stand was von "großen Steckbrückenfeld".

Zu jedem Sockelpaar für SRAM oder EPROM gibt's ein Feld mit 3*7 Pins, wo
die Steckbrücken in "lustigen" Mustern eingesteckt werden. Neben den
unterschiedlichen Anschlußbelegungen sind Zugriffszeiten kodiert
(kleiner Hinweis irgendwo im vorhandenen Papier) und, so meine
Vermutung, die Zuordnung des Sockelpaars zu den /CS-Signalen für SRAM
oder EPROM, weil die in völlig unterschiedlichen Adreßbereichen liegen
und aus den beiden Hälften vom 74LS139 kommen.

Gruß, Ralf

[Ralf Kiefer]

Post by Patrick Schaefer
Könnte ich Dir brennen. Mein Data IO Sprint Expert kann sowas.

Danke. Ist notiert.

Post by Patrick Schaefer

Post by Patrick Schaefer
Mit open collector und externem Pullup hast Du auch bei teilweise
programmiertem PROM sinnvolle Pegel an den Ausgängen.

EDIT: das ist blödsinn, denn unprogrammiert steht 0xFF drin, also
Highpegel.

Siehe:
www.ralf-kiefer.de/VME/82S130.pdf
Das allerletzte Bild. Ich habe jetzt die Pullups dazu gefunden (1k0).

Mit Pullups sollte es eigentlich(?) möglich sein als PROM sowohl Open

Post by Patrick Schaefer
Damit wäre der einzige Vorteil von open collector, dass man mehrere
Ausgänge zusammenfassen kann. So könnte z.B. das PROM drei
Adressbereiche decodieren, wo in Hardware immer der gleiche Baustein
eingeblendet wird. RAM war damals teuer, daher ist nicht jeder mit
Vollausbau gestartert. Dazu müsste aber ein Wrapfeld vorhanden sein.

Das mehrfache Einblenden könnte tatsächlich möglich sein, denn die CPU
ist ein 68000 und das eine EPROM-Sockelpaar wird nach dem Reset zum
Lesen der ersten 8 Byte bei $0000.0000 statt dem SRAM eingeblendet. Im
(disassemblierten) Code fand ich bisher nichts, was auf eine
software-basierte Umschaltung deutet.

Da muß ich rausfinden, wie das mit dem Resetvektor gelöst ist.

Gruß, Ralf

[Marcel Mueller]

Post by Ralf Kiefer
Das allerletzte Bild. Ich habe jetzt die Pullups dazu gefunden (1k0).

Autsch! Das zieht dir ein GAL nicht sauber, und etliches andere auch nicht.
Wenn Du ohne Open Collector ran gehst, sollten die raus.

Post by Ralf Kiefer
Mit Pullups sollte es eigentlich(?) möglich sein als PROM sowohl Open

Ja, klar. Aber 1k ist hart.

Alternativ zum 7406/7 als Verstärker tut's auch ein Satz Transistoren
mit ca. 10k Vorwiderstand. GAL dann halt invers programmieren.


Marcel

[b***@gmail.com]

Post by Ralf Kiefer
Hallo!
Mir ist eine Platine aus dem Jahr 1985 (Entwicklungsstand vermutlich
1983) zugelaufen, bei der die Adreßdekodierung teilweise mit Hilfe eines
bipolaren PROMs gemacht wird, eingebaut: AM27S12. Der Hersteller sah
vor, daß der engagierte Endanwender so was in Abhängigkeit der gewählten
Bestückung der SRAM- und EPROM-Sockel selbst macht, weswegen die
Generierung des Inhalts grob umrissen ist. Zuerst dachte ich, daß es
diese PROMs schon lange nicht mehr zu kaufen gäbe. Nicht ganz :-) Bei
Ebay werden noch welche angeboten. Stolze Preise, aber vorhanden.
Beim Blick in die Liste meines China-Eprommers TL866CS finde ich
allerdings diese Produktgattung nicht. Gefunden habe ich in einem
in Kurzfassung, eher rustikal. Im Detail: aus der Matrix der Dioden
werden die "rausgeschossen", die eine '0' werden sollen. Spannung
24-30V, Strom 750mA. Womit geklärt wäre, weswegen das China-Gerät am USB
nicht mitspielt. Und womit auch klar ist, daß ich das auf die Schnelle
nicht nachbauen werde.
Details: AM27S12, ein 512*4 PROM mit Open Collector, also 9 Eingänge und
4 Ausgänge. Vergleichstypen sind Signetics 82S130 und Harris 7620.
Das Detail "Open Collector" sieht mir nach einer "Aufgabe" aus. Denn
mein nächster Gedanke war ein GAL 16V8 zu nehmen, und das in einen
Sockeladapter von 20pol. (GAL) auf 16pol. (PROM) zu basteln. Ob Open
Collector überhaupt benötigt wird, weiß ich nicht, denn nach erstem
Durchmessen der Adreßdekodierung gehen die 4 Ausgänge zu einem 74LS139
(2 Stück 2-nach-4-Dekoder), der die /CS von SRAMs und EPROMs treibt, und
(vermutlich?) nichts mehr. Dann hätten die die OC-Typen statt der TS
(Tri-State)-Varianten der ROMs deswegen gewählt, damit der Pegel '1'
statt tri-state ist, wie ich aus einem Datenblatt zum 82S130/82S131
lese.
Hat so was schon mal jemand ersetzt und irgendwelche Hinweise, an die
ich noch nicht gedacht habe? Insbesondere bei der Open-Collector-Frage
bin ich nicht ganz schlüssig, wie ich das einordnen soll.
BTW eingebaut sind 6* 8kB-SRAMs mit Datecode aus dem Jahr 1985 (damals
relativ teure ICs), aber die eingebaute Dekodierung ist für 6* 2kB. Die
Sockel sollten sogar 32kB-JEDEC verkraften. Das muß ich allerdings noch
im großen Steckbrückenfeld durchklingeln. Damit ist meine Motivation
geklärt mindestens im 1. Schritt nicht gleich ein 20Euro-PROM zu
"zerschießen", falls ich mich irgendwie vertue.
Gruß, Ralf

Is it one of the Motorola's MVME boards and if yes, whish one?

best regards,
Bo/