Das Wochenendrätsel, oder welche Fragen mir ein alter Eurocom-1-Rechner stellt

[Ralf Kiefer]

Hallo!

Die Vorgeschichte: ich restauriere gerade einen Eurocom-1-Rechner von
Eltec aus dem Jahr 1979. Der hat einen 6802 @1MHz, 2kB EPROM (2716), 1kB
RAM (2* 2114), zwei 6820, einen 6850 sowie 30 Tasten und acht
Siebensegmentanzeigen auf der Platine. Ein Foto davon gibt's hier:
www.ralf-kiefer.de/hist/EltecE1/E1BSklein.JPG

Die Platine hat auf der Rückseite zwei Dutzend "Reparaturen" mit
Kupferlackdraht. Hier bevor ich anfing:
www.ralf-kiefer.de/hist/EltecE1/E1LSklein.JPG
Ich mußte noch ein paar Drähte ergänzen, um den Unfall beim Vorbesitzer
von vor über 30 Jahren auszubügeln. Beim Durchklingeln (statisch) paßt
alles.

Dazu habe ich zwei Erweiterungskarten von Eltec, eine Terminalkarte für
Textausgabe mit 16 Zeilen je 64 Zeichen sowie eine Speicherkarte, die in
4 Bänken je 4kB bestückt werden kann:
www.ralf-kiefer.de/hist/EltecE1/E1SHEBSklein.JPG
Die hatte keinen Unfall und demzufolge keine "dritte Lage" auf der
Unterseite ergänzt. Die hat Bustreiber sowohl für Adreß- (LS241) wie
Datenbus (LS245).

Die Backplane übernahm ich aus einem fast ebenso alten Industrierechner,
habe diese auf jeweils 5 Steckplätze abgesägt und in einem 19"-Rack
versenkt. Das originale Eltec-Netzteil hat(te) Schwächen, die mit Hilfe
von dafc bereits teilweise beseitigt wurden. Die aktuellen Tests mache
ich allerdings am Labornetzteil, das eine bessere Regeleigenschaft
aufweist. Beim Test waren durchgehend zwischen 5,0 und 5,1V angelegen.
Die Backplane ist kurz und hat keine Terminierung. Beim Test steckt die
CPU-Karte am einen Ende, die Speicherkarte am anderen Ende. Diese
Backplane wurde seinerzeit mit bis zu 21 Steckplätzen in
Industriesteuerungen verwendet, die mit 6809 @2MHz (und Bustreibern)
liefen. Die Eurocom 1 hat dagegen keine Bustreiber für Adreß- oder
Datenbus.

Problematisch ist der Betrieb der Speicherkarte. Es betrifft sowohl die
alte von Eltec wie auch eine gerade selbst "gefädelte", die nur aus
einem 62256 (32kB SRAM) sowie einem 74LS10 zur Dekodierung besteht, also
ohne Bustreiber.

Die Eltec-Karte hat eine Monitor-Software, mit der ich Speicher
beschreiben und auslesen kann. D.h. ich kann auch Code ins RAM schreiben
und diesen aus dem Monitor starten. Ich kann weiterhin ein zweites EPROM
mit eigenem Code ergänzen und diesen daraus starten.

Erster Versuch mit der Speicherkarte, nachdem ich die RAMs tauschte,
weil einer der Chips offensichtlich die >30 Jahre Lagerzeit nicht
überlebt hatte, oder bereits beim Vorbesitzer kaputt war. Der eine
kaputte produzierte immer eine Eins, was ich durch Tauschen der Plätze
in den Sockeln recht einfach rausfand. Ein netter Regular aus dafc
überließ mir seinen Vorrat an passenden RAMs. Aus dem Monitor kann ich
jetzt die RAMs Adresse nach Adresse beschreiben, nach dem Schreiben
liest der Monitor den Inhalt sofort zurück und würde sich beschweren,
wenn der Inhalt nicht stimmt. Aber das machte er nur mit dem einen
defekten Chip, nicht mit den getauschten. Ich konnte im zweiten Versuch
viele Adressen manuell mit Bitmustern beschreiben und diese nach
mehreren Betriebsstunden problemlos aus den SRAMs rücklesen. Soweit sah
die Speicherkartenbastelaktion zunächst erfolgreich aus.

Im dritten Anlauf schrieb ich ein wenig 6802-Code, um den Speicher zu
füllen und zu prüfen. Genau das geht schief! Ich erhalte prinzipiell
mehr 1er zurück, als ich reinschreiben ließ. Die Muster wiederholen
sich, allerdings nicht ganz systematisch. Diverse Konstellationen (Code
im RAM sowohl in den 128Byte im Prozessor wie in den beiden 2114, Code
im EPROM, verschiedene Varianten des Schreibens mit unterschiedlichen
Bitmusterabfolgen) waren erfolglos, manchmal bereits bei der ersten
Adresse, manchmal erst die 200.

Irgendwann habe ich mein uraltes Oszi ausgepackt (Siemens Oscillar M911,
späte 1960er Jahre, leicht schiefes Bild, derzeit nur 1 Kanal
funktionierend) und reingeschaut. Ergebnisse: die "Kurven" der
Adreßleitungen sehen gut aus, d.h. Low-Pegel wirklich Low, High-Pegel
bei rund 4V, die Flanken sind steil. Aber die Datenleitungen sind
gruselig. Hier sehen sie IMHO noch relativ gut aus, wenn auch etwas
auffällig mit ihren Stufen:
www.ralf-kiefer.de/hist/EltecE1/D0_unbelastet.JPG
www.ralf-kiefer.de/hist/EltecE1/D1_unbelastet.JPG
www.ralf-kiefer.de/hist/EltecE1/D2_unbelastet.JPG
Meßbedingungen: die Eurocom 1 liegt ohne Backplane herum, einen von den
hierzu nicht benötigten 6820 habe ich rausgezogen, d.h. die 6802-CPU
treibt auf ihrem Datenbus einen 6820, einen 6850, ein EPROM 2716 sowie
zwei 4bit-SRAMS 2114. Das Oszi-Bild ist bei 1V/cm und 1usec/cm
entstanden, das Bild hängt ein bißchen schräg hinter der Skala.

Stecke ich die Eurocom 1 auf die Backplane und lasse die
Spannungsversorgung über die Backplane laufen, ändert sich das Bild
praktisch nicht. Stecke ich die alte Eltec-Speicherkarte SHE dazu (ohne
Zugriffe drauf), dann ändert sich das Bild massiv:
www.ralf-kiefer.de/hist/EltecE1/D2_mit_SHE_passiv.JPG
www.ralf-kiefer.de/hist/EltecE1/D7_SHE.JPG
Soweit wäre eigentlich der Fehler gefunden: entweder ist der 74LS245 von
der Speicherkarte hinüber, oder die CPU packt die zusätzliche Last
nicht. Die CPU konnte ich einfach austauschen: statt der Motorola 6802
von 1978 steckt bei diesen Bildern vom Oszi eine jüngere Hitachi-6802
(Datecode 5E1, was immer das sein mag) drauf. Es sieht nahezu gleich
(schlecht) aus. Logischer Fehler wäre demnach: 74LS245 von der
Speicherkarte.

Das große Aber: stecke ich meine eigene gefädelte Karte stattdessen in
denselben Slot, sieht das Bild schon viel schöner aus:
www.ralf-kiefer.de/hist/EltecE1/D2_mit_RAM32.JPG
Aber die Fehler beim Schreiben per Code bleiben dieselben! Ich schreibe
per Schleife Daten in den Speicher, im direkt nach dem Schreiben
folgenden Lesebefehl stimmen die Daten noch, aber beim späteren Lesen
sind die kaputt. Auffällig häufig liefern D7 und D6 eine 1 statt einer
0. Schreibe ich die Bitmuster per Monitor-Software rein, stimmt der
Inhalt und die Daten bleiben erhalten. Per Code-Schleife ändern sich
dagegen die Daten.

Den LS245 kann ich natürlich tauschen, allerdings vermute ich in diesem
nicht unbedingt den (einzigen) Fehler. D.h. ich möchte mir das Löten in
der alten Hardware sparen, wenn es nur Trial&Error ist und nicht
unbedingt das Problem löst.

Ich gehe davon aus, daß die Schaltung seinerzeit prinzipiell
funktioniert hat. Der Vorbesitzer kann sich ebenso an die
Funktionsfähigkeit genau dieser Hardware-Konstellation erinnern, was
nicht heißt, daß während >30Jahren Lagerung mehr kaputt ging als nur ein
RAM-Chip.


Jetzt die Preisfrage (ohne Preis): Was ist kaputt?
Oder: Wieviel Fehler habe ich in diesem Aufbau?
Oder: Was kann ich mit dem Oszi anschauen, wie kann ich mit ein paar
Assemblerbefehlen dem Fehler auf die Spur kommen?
Oder: Kann irgendwas in der "dritten Lage" auf der Eurocom 1 schuld dran
sein?


Danke schonmal fürs geduldige Lesen :-)

Gruß, Ralf

[Holger]

Ralf Kiefer schrieb:

> Jetzt die Preisfrage (ohne Preis): Was ist kaputt?

Die Datenleitungen möchten gerne terminiert werden. Am besten mit einer
aktiven Terminierung, die über Widerstände (150 Ohm) auf jede Leitung
rund 2.5 Volt gibt. Diese Spannung sollte mit einem Spindeltrimmer
einstellbar sein. Außerdem empfiehlt sich die Verwendung von Bustreibern
wie 74LS244 und 74LS245.

HTH, Holger

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Ralf Kiefer]

Moin Holger!

Holger wrote:

> Die Datenleitungen möchten gerne terminiert werden.

Die Idee hatte ich schon, aber wieder verworfen. Der Adreßbus
funktioniert prima ohne. Vermutlich (ich zweifle grad alles an :-( ).
Wenn der Adreßbus ebenfalls rumzicken sollte, dann bräuchte auch der
eine Terminierung. Es gibt nur leider keine eindeutigen Muster, daß der
ggf. schuld sein könnte. Warum sollte dann nur der Datenbus zicken? An
dem hängen ungefähr genauso viele Lasten.

> Am besten mit einer
> aktiven Terminierung, die über Widerstände (150 Ohm) auf jede Leitung
> rund 2.5 Volt gibt.

Du hast die auffälligen Spannungsrampen trotz Low-Pegel gesehen? Die
habe ich übrigens direkt am CPU-Beinchen abgegriffen. Ich gehe mal davon
aus, daß da Low-Pegel sein sollte. Hilft mir eine Terminierung, die an
der CPU in Richtung 2,5V "zieht"?

Oder ist das eine Fehlinterpretation von mir, daß das Low-Pegel sein
soll? Ich habe blöderweise momentan nur den einen Kanal im Oszi, so daß
ich kein VMA (Valid Memory Address) drüber anzeigen kann.

Sind 150Ohm nicht ein bißchen wenig gegen die "arme" CPU?

> Diese Spannung sollte mit einem Spindeltrimmer
> einstellbar sein.

Wozu? Z.B. der VMEbus hat eine fixe Spannung für seine aktive
Terminierung.

> Außerdem empfiehlt sich die Verwendung von Bustreibern
> wie 74LS244 und 74LS245.

1. Geht nicht ohne die Platine massiv umzubauen,
2. hielt das Eltec damals für nicht nötig, es soll ohne funktioniert
haben,
3. gibt's ein Schaubild, auf dem Eltec zwei dieser Karten als
Aufrüstoption eingezeichnet hatte (ich habe lediglich eine).

Andrerseits gibt's im Handbuch keinerlei Hinweise auf die Beschaffenheit
einer Backplane, nicht mal auf die Existenz einer solchen.

Bedenke, daß ich Daten- und Adreßbus nur um rund 10cm verlängere, bis
auf meiner Eltec-Speicherkarte die Bustreiber kommen. Da noch weitere
Treiber davorzusetzen wäre Overkill, IMHO.

Gruß, Ralf

[Hans-Peter Diettrich]

Ralf Kiefer schrieb:

> Problematisch ist der Betrieb der Speicherkarte. Es betrifft sowohl die
> alte von Eltec wie auch eine gerade selbst "gefädelte", die nur aus
> einem 62256 (32kB SRAM) sowie einem 74LS10 zur Dekodierung besteht, also
> ohne Bustreiber.

Die fehlenden Bustreiber könnten das Problem sein. Dazu die Distanz
zwischen CPU und Speicherkarte.
Stützkondensatoren? Alte Elkos austauschen?

BTW meine Rechner kamen bis 4 MHz ganz ohne Bustreiber aus.
Möglicherweise verursachen die unterschiedlichen Pegel/Schwellen der
TTL-Treiber und MOS Bausteine Probleme.

Zwei Tips zur Diagnose:

Eine Speicherzelle in Schleife auslesen, Signale mit Oszi prüfen. Oder
zwei Speicherzellen mit komplementärem Inhalt.

Takt testhalber auf 1 MHz verringern, dann läßt sich der Verlauf der
Flanken besser prüfen.

DoDi

[Rafael Deliano]

> www.ralf-kiefer.de/hist/EltecE1/E1BSklein.JPG

Der scheint ja schon ordentliche Sockel zu haben.
Trotzdem hätte ich mich da mit Reinungsspray versucht.

http://www.embeddedFORTH.de/temp/4040.pdf
Bei dem 4040 den ich hier rumliegen habe mit seinen
schlechten Sockeln wird das absehbar problematischer.

> www.ralf-kiefer.de/hist/EltecE1/D2_mit_SHE_passiv.JPG

Die Lowpulse sind ja da. Daß das Signal bei tristate
floated würde mich nicht stören.

> 74LS245

Die Grundaussage ist ja wohl daß das unerweiterte Board
nach groben Tests funktioniert, aber mit Speicher-
erweiterung nichtmehr.
Die zynische Einschätzung ist aber wohl auch daß die
8 Bit Systeme damals ohnehin nur marginal funktioniert
haben. D.h. 1MHz CPU konnte schon mit 450nsec Speichern
fast auflaufen. Das beisst sich eben mit was am
Wochenende auf der VCFe auch wieder diskutiert wurde
"Hardware im Originalzustand restauriert" vs. moderne
Bauteile reinklatschen bis es stabil läuft.
Den 74LS245 würde ich als kanonisches Bauteil für design
reviews ansehen. Nach den (langsamen) S100 Boards mit
ihren 2114 Feldern war der eher nicht nötig und
stört oft nur.
Das Ding sockeln und erstmal durch Drahtbrücken-
Stecker ersetzen.

> Was kann ich mit dem Oszi anschauen,

Bei dem 4040 werde ich wohl erstmal die CPU raus-
werfen und mich mit Ports eines Einplatinencomputers
ankoppeln. Damit kann man die Memorymap bequem komplett
durchklappern.
Es kann nötig sein Pegelwandler 74xx245 / 74LS244 zu
verwenden. Eventuell reicht aber auch Versorgung 4V.
Moderne 8 Bit Controller kommen im Timing an alte 1MHz
CPUs knapp ran. Echte Logicanalyzer mögen für schnellere
Systeme nützlich sein.

MfG JRD

[MaWin]

"Ralf Kiefer" <R.Kiefe...@gmx.de> schrieb im Newsbeitrag
news:1mmqxdh.pmaw1r1oouyamN%R.Kiefe...@gmx.de...

> Die Platine hat auf der Rückseite zwei Dutzend "Reparaturen" mit
> Kupferlackdraht. Hier bevor ich anfing:
> www.ralf-kiefer.de/hist/EltecE1/E1LSklein.JPG

Eigentlich sind die Verbindungen zum Eurokartenstecker auch auf der
Vorderseite der Platine. Er hat also irgendwie den ruiniert und dann
hinten geflickt.

> Beim Test steckt die CPU-Karte am einen Ende, die Speicherkarte am

> anderen Ende. Problematisch ist der Betrieb der Speicherkarte.

D.h. ohne Speicherkarte funktioniert der Einplatinencomputer mit
seinem lokalen RAM und ROM.

> Ich erhalte prinzipiell mehr 1er zurück, als ich reinschreiben ließ.

Wundert nicht wenn man

> www.ralf-kiefer.de/hist/EltecE1/D2_mit_SHE_passiv.JPG

sieht: Der 0-Pegel steigt über 0.8V. Es sieht ein wenig so aus, als ob
der Datenbus freigegeben wird (Tri-State, die CPU macht also einen Lese-
Zugriff und der Speicher antwortet nicht weil er nicht glaubt daß
gelesen werden soll) und dann langsam die Spannung ansteigt. Das spricht
für ein gestörtes R/W oder Adressignal.

> Das große Aber: stecke ich meine eigene gefädelte Karte stattdessen in
> denselben Slot, sieht das Bild schon viel schöner aus:
> www.ralf-kiefer.de/hist/EltecE1/D2_mit_RAM32.JPG

Stimmt, müsste auslesbar sein.

> Jetzt die Preisfrage (ohne Preis): Was ist kaputt?
> Oder: Wieviel Fehler habe ich in diesem Aufbau?
> Oder: Was kann ich mit dem Oszi anschauen, wie kann ich mit ein paar
> Assemblerbefehlen dem Fehler auf die Spur kommen?
> Oder: Kann irgendwas in der "dritten Lage" auf der Eurocom 1 schuld dran
> sein?

Früher hatte man keine Erfahrung in ordentlicher Masseführung und guter
Abblockung, die Schaltungen liefen oft nur auf Gut Glück.
Deine Backplane macht es noch viel schlimmer.

Genau so problematisch ist aber das Messen mit dem Oszilloskop, ohne
1:10 Teiler und kurze Masseclips misst man eher nur Schrott und nicht
die realen Spannungsverläufe.

Ich vermute, es wird funktionieren, wenn du deine gefädelte Speicherkarte
mit dem 62256 mit einem VG-Stecker so baust, daß sie direkt in die
DIN41612 VG-Buchse der Eltec-Karte passt, ohne Backplane.

Insgesamt ist der Weg über die Backplane doch schon ziemlich weit ohne
Treiber für die alten NMOS-Ausgänge. Du hast sie abgesägt. Was passiert
wenn du alle Karten bestückst ? Dann hast du nämlich Dämpfung und
Terminierung. Kannst du zwischen Karten jeweils an den GND-Anschlüssen
der Chips mit dem Oszi Potentialunterschiede messen ? Das würde für
schlechte Masseführung sprechen.

Es kann auch nicht schaden, bei jedem grösseren IC einen 100nF Kerko
von unten als Stützkondensator anzulöten UND die Masseverbindungen mit
dickerem Draht an den Stromversorgungseingang zu ziehen, sternförmig.
--
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

[Andreas Graebe]

Am Wed, 04 May 2016 23:59:40 +0200 schrieb Ralf Kiefer:

> Im dritten Anlauf schrieb ich ein wenig 6802-Code, um den Speicher zu
> füllen und zu prüfen. Genau das geht schief! Ich erhalte prinzipiell
> mehr 1er zurück, als ich reinschreiben ließ. Die Muster wiederholen
> sich, allerdings nicht ganz systematisch. Diverse Konstellationen (Code
> im RAM sowohl in den 128Byte im Prozessor wie in den beiden 2114, Code
> im EPROM, verschiedene Varianten des Schreibens mit unterschiedlichen
> Bitmusterabfolgen) waren erfolglos, manchmal bereits bei der ersten
> Adresse, manchmal erst die 200.

Hallo, Ralf,

für mich hört sich das so an, als ob irgendetwas mir der
Adressdecodierung nicht korrekt ist. Wenn ich mich recht erinnere, muß
die Adressfreigabe beim 6802 mit dem VMA-Signal verknüpft werden, wogegen
die Datenfreigabe (hier wohl insbesondere das /WRITE am Ram) mit dem E
der CPU.

Manche alten Designs haben sich wohl auf die Langsamkeit der Bausteine
verlassen, da störte ein Glich auf der /Write-Leitung nicht. Neuere
Bausteine reagieren möglicherweise auf solche Glitches. Es fällt ja auf,
dass der RAM-Inhalt direkt nach dem Schreiben korrekt ist, sich aber nach
einiger Zeit verändert. Ist eventuell ein Hinweis auf "versehentliche"
Schreibzugriffe. Versuche doch bitte mal, die Erzeugung des Write-Signals
nachzuvollziehen, dort direkt die R/W der CPU anzuschließen ist
möglicherweise problematisch. Weiterhin sollte die Freigabe der Bausteine
unbedingt mit VMA verknüpft sein, wenn ich mich recht erinnere, gibt es
beim 6802 Befehle, bei denen eine Information auf der Adressleitung
anliegt, ohne dass VMA high wird.

Die Datenleitungen sehen meiner Meinung nach gut aus. Die langsamen
Anstiege sind wohl während der Tristate-Phasen, also unkritisch. Wenn
Dein Oszi einen Fremdtrigger hat, versuche doch mal, mit der steigenden
Flanke von E zu triggern. Es wird ja mit der fallenden Flanke von E
gelesen oder geschrieben, der Datenbus muss sich also bis zum Ende von
E=high stabilisieren.

Ganz wichtig ist natürlich die Stabilität der Versorgungsspannung, hier
können gar nicht genug keramische Kondensatoren zwischen GND und VCC
liegen.

Wenn Du irgendwie die Schaltung der Karte auftreiben könntest, wäre das
sicher hilfreich, so ist alles nur Vermutung. Im Netz finde ich nur die
Version mit einer 6809-CPU.

Viel Erfolg.

[Volker Borchert]

Ralf Kiefer wrote:

> Das grosse Aber: stecke ich meine eigene gefaedelte Karte stattdessen in
> denselben Slot, sieht das Bild schon viel schoener aus:

> www.ralf-kiefer.de/hist/EltecE1/D2_mit_RAM32.JPG
> Aber die Fehler beim Schreiben per Code bleiben dieselben! Ich schreibe
> per Schleife Daten in den Speicher, im direkt nach dem Schreiben

> folgenden Lesebefehl stimmen die Daten noch, aber beim spaeteren Lesen
> sind die kaputt. Auffaellig haeufig liefern D7 und D6 eine 1 statt einer

> 0. Schreibe ich die Bitmuster per Monitor-Software rein, stimmt der

> Inhalt und die Daten bleiben erhalten. Per Code-Schleife aendern sich
> dagegen die Daten.

Was macht die Monitor-Software anders? Wie genau schreibt sie die Daten?
Haben alle Schreibbefehle des 6802 dasselbe Timing? Oder wird bei Zugriff
auf das EPROM das 6802-Gegenstueck zu /WAIT Zyklen eingefuegt, und bleibt
Schreiben von Speicher faelschlich wirksam?

--

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_bor...@despammed.com>

[Dieter Wiedmann]

Am 05.05.2016 09:48, schrieb Andreas Graebe:

> für mich hört sich das so an, als ob irgendetwas mir der
> Adressdecodierung nicht korrekt ist.

Da kann ein NOP-Adapter für die CPU recht hilfreich sein.



Gruß Dieter

[Ralf Kiefer]

Andreas Graebe wrote:

> für mich hört sich das so an, als ob irgendetwas mir der
> Adressdecodierung nicht korrekt ist. Wenn ich mich recht erinnere, muß
> die Adressfreigabe beim 6802 mit dem VMA-Signal verknüpft werden, wogegen
> die Datenfreigabe (hier wohl insbesondere das /WRITE am Ram) mit dem E
> der CPU.

Die Dekodierung funktioniert auf der Eurocom 1 (CPU-Karte) lokal über
NAND-Gatter (LS10), bei dem E, VMA und die Adreßleitungen verknüpft
werden. Dahinter ist ein 7442. Das funktioniert. Bei der alten
Eltec-RAM-Karte (SHE) wurden LS26, LS38 und LS139 sowie ein Pullup
(grauslig!) genommen, siehe unten. Mit zwei Gattern aus einem LS10 habe
ich das bei meinem SRAM gemacht. Das E sieht sowohl am CPU-Beinchen wie
auch am Beinchen vom 74LS26 auf der Eltec-RAM-Karte so aus (1V/cm und
jetzt 0,2usec/cm):
www.ralf-kiefer.de/hist/EltecE1/E_CPU.JPG
www.ralf-kiefer.de/hist/EltecE1/E_SHE.JPG
IMHO brauchbar und insbesondere keine Verluste auf der Backplane.

VMA an der CPU (jetzt 0,5usec/cm):
www.ralf-kiefer.de/hist/EltecE1/VMA_CPU.JPG
Pegel bei knapp 4,0V, aber die Flanken sehen IMHO auch gut aus. Bei
Zweifel: sagt's mir :-)

> Manche alten Designs haben sich wohl auf die Langsamkeit der Bausteine
> verlassen, da störte ein Glich auf der /Write-Leitung nicht.

Wie finden? Die Adreßdekodierung auf meiner Karte mit dem einen SRAM ist
E NAND VMA NAND /A15
wobei ich nebenan das /A15 aus einem 3fach NAND aus dem A15 bastle. Ich
hielt das für ausreichend. Mein SRAM hat eine Zugriffszeit von 120nsec.
Die alten SRAMs von Eltec sollten laut Handbuch 350nsec haben, eingebaut
auf der Karte waren 200nsec. Die jetzt eingebaute Ersatzbank hat
tatsächlich 350nsec.

Bei meinem SRAM habe ich zwei LS-Gatter-Durchlaufzeiten fürs CS und gar
keine für die Daten, die alte Eltec-Karte hat 4 LS-Gatter-Laufzeiten
sowohl für die CS wie auch für die Daten an den RAM-Chips.

> Neuere
> Bausteine reagieren möglicherweise auf solche Glitches. Es fällt ja auf,
> dass der RAM-Inhalt direkt nach dem Schreiben korrekt ist, sich aber nach
> einiger Zeit verändert. Ist eventuell ein Hinweis auf "versehentliche"
> Schreibzugriffe. Versuche doch bitte mal, die Erzeugung des Write-Signals
> nachzuvollziehen, dort direkt die R/W der CPU anzuschließen ist
> möglicherweise problematisch.

Bei meinem SRAM liegt R/W direkt an. Bei der Eltec-Karte geht R/W genau
nur durch ein LS139 durch. Direkt anschließen geht nicht, weil das ein
paar Lasten zuviel sein könnten. BTW auf der Eltec-RAM-Karte sind außer
den RAMs alles 74LS-Typen, kein CMOS, kein 74-ohne-Buchstabe.

> Weiterhin sollte die Freigabe der Bausteine
> unbedingt mit VMA verknüpft sein, wenn ich mich recht erinnere, gibt es
> beim 6802 Befehle, bei denen eine Information auf der Adressleitung
> anliegt, ohne dass VMA high wird.

Ist überall so gelöst.

> Die Datenleitungen sehen meiner Meinung nach gut aus. Die langsamen
> Anstiege sind wohl während der Tristate-Phasen, also unkritisch.

Genau das kann ich gerade nicht prüfen, weil:

> Wenn
> Dein Oszi einen Fremdtrigger hat, versuche doch mal, mit der steigenden
> Flanke von E zu triggern.

2. Kanal gerade kaputt, werde ich mich wohl ASAP drum kümmern müssen.

> Ganz wichtig ist natürlich die Stabilität der Versorgungsspannung, hier
> können gar nicht genug keramische Kondensatoren zwischen GND und VCC
> liegen.

Das schien zunächst ein Problem zu sein, denn Leiterbahnen auf der
Eurocom 1 sind nicht so toll. Ich habe im 3. Layer einen Draht ergänzt
und etliche Tantals an dafür vorgesehenen Plätzen, die nicht bestückt
waren. Auf der Eltec-RAM-Karte ist neben jedem Sockel ein (vermutlich)
100nF sowie im vorderen Bereich über die gesamte Platinenbreite ein
"Kapazitäts-Array". So was habe ich vorher noch nicht gesehen. Das sieht
danach aus, wie wenn einerseits die 5V wie auch GND ordentlich von
rechts nach links durchverbunden sind, und außerdem irgendwelche
Kondensatoren eingebaut sind.

Habe gerade eine kurze Schleife geschrieben, um das RAM auf der alten
Eltec-Karte zu beschreiben. So sieht's an einem RAM-Chip an Vcc aus:
www.ralf-kiefer.de/hist/EltecE1/V_RAM.JPG
Bei 1V/cm (diesmal nach unten verschoben) und 2usec/cm. Und es paßt:
10Zyklen laut CPU-Handbuch. Das Spannungseinbrüchle sieht mir vertretbar
aus (das Oszi soll 10MHz können).

> Wenn Du irgendwie die Schaltung der Karte auftreiben könntest, wäre das
> sicher hilfreich, so ist alles nur Vermutung. Im Netz finde ich nur die
> Version mit einer 6809-CPU.

Mit 6809 ist's die Eurocom 2. Diese Karte ich reichhaltig bestückt.

Der relevante Ausschnitt von der RAM-Karte:
www.ralf-kiefer.de/hist/EltecE1/SHE_Ausschnitt.jpg
Das Gepfusche zur (hier: Nicht-)Erzeugung vom MR-Signal braucht man
nicht berücksichtigen, aber ganz unten der C26 stimmt mich jetzt gerade
etwas bedenklich.

Der relevante Ausschnitt einer Eurocom 1, aber der Vorgängerversion von
meiner, die noch zwei 2708 hat. Meine hat zwei 2716 und demzufolge eine
andere Adreßdekodierung für die Sockel. Es wurde ein 74LS266 ergänzt:
www.ralf-kiefer.de/hist/EltecE1/E1_1k_Ausschnitt.jpg
Von der Logik auffällig ist die Dekodierung mit Hilfe vom 7442.

BTW meine Kopie ist schon schlecht. Was Besseres habe ich nicht.


Gruß, Ralf

[Ralf Kiefer]

MaWin wrote:

> Eigentlich sind die Verbindungen zum Eurokartenstecker auch auf der
> Vorderseite der Platine. Er hat also irgendwie den ruiniert und dann
> hinten geflickt.

Ja.

> D.h. ohne Speicherkarte funktioniert der Einplatinencomputer mit
> seinem lokalen RAM und ROM.

Ja.

> sieht: Der 0-Pegel steigt über 0.8V. Es sieht ein wenig so aus, als ob
> der Datenbus freigegeben wird (Tri-State, die CPU macht also einen Lese-
> Zugriff und der Speicher antwortet nicht weil er nicht glaubt daß
> gelesen werden soll) und dann langsam die Spannung ansteigt. Das spricht
> für ein gestörtes R/W oder Adressignal.

In diese Ecke könnte das Problem liege. Nur hat mein SRAM schöne Pegel
und funktioniert bei gleichem Fehlerbild genausowenig.

> Früher hatte man keine Erfahrung in ordentlicher Masseführung und guter
> Abblockung, die Schaltungen liefen oft nur auf Gut Glück.
> Deine Backplane macht es noch viel schlimmer.

Da habe ich bereits "investiert": Draht im 3. Layer auf der CPU-Karte
sowie einige Kapazitäten ergänzt. Die Eltec-Speicherkarte sieht gut aus,
siehe Hinweis in meiner Antwort an Andreas Graebe. Die hatte bei meiner
Übernahme bereits etliche 100nF, ergänzt habe ich einen Tantal mit 10uF
(oder so) an einer bisher nicht bestückten Stelle.

> Genau so problematisch ist aber das Messen mit dem Oszilloskop, ohne
> 1:10 Teiler und kurze Masseclips misst man eher nur Schrott und nicht
> die realen Spannungsverläufe.

Ich habe momentan kein besseres Oszi als dieses historische Gerät mit
nur einem funktionierenden Kanal. Leider. Ich will das in mittlerer
Zukunft ändern, aber das wird ein anderes Thema.

> Ich vermute, es wird funktionieren, wenn du deine gefädelte Speicherkarte
> mit dem 62256 mit einem VG-Stecker so baust, daß sie direkt in die
> DIN41612 VG-Buchse der Eltec-Karte passt, ohne Backplane.

Dagegen spricht, daß die exemplarisch rausgepickten Signale auf der
Backplane keine Verluste erleiden, siehe z.B. das E-Signal mit 1MHz.

> Insgesamt ist der Weg über die Backplane doch schon ziemlich weit ohne
> Treiber für die alten NMOS-Ausgänge.

8cm zusätzliche Leitungslänge.

> Du hast sie abgesägt. Was passiert
> wenn du alle Karten bestückst ?

Kann ich gar nicht, da ich weder weitere Karten für den Prozessorbus
habe noch mir weitere überhaupt bekannt wären. Ich habe bisher eine
weitere gebaut, um die auf der c-Reihe liegenden GPIOs nutzen zu können.
Die steckt während dieser Tests nicht drin, sie verschlechtert
allerdings auch nicht die Prozessorsignale.

> Dann hast du nämlich Dämpfung und
> Terminierung. Kannst du zwischen Karten jeweils an den GND-Anschlüssen
> der Chips mit dem Oszi Potentialunterschiede messen ? Das würde für
> schlechte Masseführung sprechen.

Die Masseführung ist sicher nicht das Optimum auf der Eurocom 1. Ich
hatte da schon etwas nachgebessert. Ich sehe mit dem Multimeter rund
30mV Differenz zwischen der entferntesten Stelle der Speicherkarte und
der miesesten Stelle auf der CPU-Karte. Auf dem Oszi erkenne ich keine
Einbrüche. Ich glaube, daß eine Apple-2-Platine schlechter war.


Gruß, Ralf

[Ralf Kiefer]

Volker Borchert wrote:

> Was macht die Monitor-Software anders?

Die Befehle aus der Monitor-Software exakt mit diesem Ablauf:

FE A7BC LDX <Zieladresse>
A7 00 STAA X
A1 00 CMPA X
26 ED BNE <Fehlerausgang>
39 RTS

Ich habe gerade diese Schleife in meinem EPROM:
F080 CE 00 80 ldx $0080
F083 DF 10 $1 stx L10
F085 96 11 ldaa L11
F087 A7 00 staa 0,x
F089 E6 00 ldab 0,x
F08B 11 cba
F08C 26 0B bne $2
F08E 08 inx
F08F 8C 10 00 cpx $1000
F092 26 EF bne $1
F094 C6 30 ldab #'0' fehlerfrei
F096 7E F0 A0 jmp F0A0
F099 D7 12 $2 stab L12 Fehlerausgang
F09B C6 31 ldab #'1'
F09D 7E F9 CF jmp ERROR

Die Adressen $0000 bis $007F sind prozessorinternes RAM (in diesem
Bereich wird externer Speicher nicht angesprochen), ab $0080 liegt
entweder die Eltec- oder meine RAM-Karte. Die Eltec-Karte kann ich auf
die Basisadresse $4000 einstellen, was nichts am Fehlerbild ändert. In
$0010 bis $0012 kann ich nach Abbruch reinschauen, wie weit die Schleife
gelaufen ist.

Wer mit dem 680x nicht vertraut ist: es gibt zwei Akkus A und B mit je
8bit Breite sowie das Indexregister X mit 16bit Breite. Das war's.

> Wie genau schreibt sie die Daten?

-v plz

> Haben alle Schreibbefehle des 6802 dasselbe Timing? Oder wird bei Zugriff
> auf das EPROM das 6802-Gegenstueck zu /WAIT Zyklen eingefuegt, und bleibt
> Schreiben von Speicher faelschlich wirksam?

Es gibt keine Wait states oder Handshake in dieser Hardware. Ein 6802
könnte das prinzipiell, um mit noch langsamerem Speicher zu
funktionieren, weswegen es die MR-Leitung gibt. D.h. hier laufen alle
Speicherzugriffe nach demselben Schema, egal ob I/O-Chip, EPROM oder
RAM.

Gruß, Ralf

[Ralf Kiefer]

Hans-Peter Diettrich wrote:

> BTW meine Rechner kamen bis 4 MHz ganz ohne Bustreiber aus.

Der hier läuft mit 1MHz. Z.B. E und VMA sehen über die Backplane ganz
brauchbar aus.

> Eine Speicherzelle in Schleife auslesen, Signale mit Oszi prüfen. Oder
> zwei Speicherzellen mit komplementärem Inhalt.

Das werde ich heute Abend noch ein bißchen vertiefen.

Gruß, Ralf

[Ralf Kiefer]

Rafael Deliano wrote:

> > www.ralf-kiefer.de/hist/EltecE1/E1BSklein.JPG
>
> Der scheint ja schon ordentliche Sockel zu haben.
> Trotzdem hätte ich mich da mit Reinungsspray versucht.

Die RAMs inkl. Sockel habe ich momentan nicht in Verdacht. Denn der
initiale Fehler mit dem einen Chip, den ich ganz am Anfang als defekt
erkannte, zog sich zuverlässig durch. D.h. der Bitfehler wanderte mit
dem Tausch durch die Sockel mit. Danach habe ich in die Sockel die
"neuen" RAMs reingesetzt. Außerdem funktioniert das Beschreiben in der
Monitor-Software soweit fehlerfrei, wie ich das mit ein paar dutzend
Schreibaktionen ausprobiert habe.

> http://www.embeddedFORTH.de/temp/4040.pdf
> Bei dem 4040 den ich hier rumliegen habe mit seinen
> schlechten Sockeln wird das absehbar problematischer.

Das sind also schlechte Sockel? BTW bei der Eltec-Hardware sind alle
Logik-Chips gelötet. Nur die "Höherwertigen" stecken in Sockeln.

> > www.ralf-kiefer.de/hist/EltecE1/D2_mit_SHE_passiv.JPG
>
> Die Lowpulse sind ja da. Daß das Signal bei tristate
> floated würde mich nicht stören.

Auffällig war für mich der Unterschied zwischen der Eltec-RAM-Karte und
meiner, denn der ist signifikant. Bei meiner Hardware lauscht ein 62256
am Datenbus, bei der Eltec-Hardware ein 74LS245. Exakt das macht den
Unterschied für die Signalen.

> Die Grundaussage ist ja wohl daß das unerweiterte Board
> nach groben Tests funktioniert, aber mit Speicher-
> erweiterung nichtmehr.

Genau. Die Eurocom 1 (CPU-Karte) funktioniert mit allen lokalen Teilen,
aber die Speichererweiterungen über die Backplane funktionieren beide
nur sehr merkwürdig. In der Monitor-Software wie gewünscht, beim
vollumfänglichen Code-Zugriff nicht.

> Die zynische Einschätzung ist aber wohl auch daß die
> 8 Bit Systeme damals ohnehin nur marginal funktioniert
> haben. D.h. 1MHz CPU konnte schon mit 450nsec Speichern
> fast auflaufen.

Der Apple ][ konnte im Jahr 1977 erst so gebaut werden, nachdem
450nsec-RAMs verfügbar waren. Und die liefen zuverlässig, AFAIK. Die
Eltec-Speicherkarte ist für 450nsec-RAMs ausgelegt. Eingebaut waren bei
meiner teils 200nsec-Typen.

> Das beisst sich eben mit was am
> Wochenende auf der VCFe auch wieder diskutiert wurde
> "Hardware im Originalzustand restauriert" vs. moderne
> Bauteile reinklatschen bis es stabil läuft.

Bei Reichelt habe ich mir schon mal die CD40xx besorgt, falls ich mal
tauschen muß, und solange die noch verfügbar sind. Manche 74LS werden
auch schon knapp, z.B. 74LS154 (braucht der Apple //e).

> Den 74LS245 würde ich als kanonisches Bauteil für design
> reviews ansehen. Nach den (langsamen) S100 Boards mit
> ihren 2114 Feldern war der eher nicht nötig und
> stört oft nur.
> Das Ding sockeln und erstmal durch Drahtbrücken-
> Stecker ersetzen.

Hm, dann muß die CPU ziemlich viel treiben. Wieviel zählen diese
5257/4104/4404 in LS-Gattern? Ein LS245 weniger, aber 8 RAMs mehr, und
mehr Leitungslänge. Genau das halte ich eher für kontraproduktiv, aber
ich lasse mich gerne vom Gegenteil überzeugen :-) Schaltungsdesign ist
zugegebenermaßen nicht meine Stärke.

Gruß, Ralf

[Rafael Deliano]

>> Den 74LS245 ... sockeln und erstmal durch Drahtbrücken-

>> Stecker ersetzen.

> Hm, dann muß die CPU ziemlich viel treiben.

Die bidirektionalen Treiber sind nicht so transparent wie
man hofft. Mir haben die oft die Hold-Zeiten weggeschnitten.
Wenn man Sockel hat kann man auch mal 74HCT245 reinstecken,
war oft schneller.

MfG JRD

[Marc Santhoff]

R.Kiefe...@gmx.de (Ralf Kiefer) schrieb:

> > Die Grundaussage ist ja wohl daß das unerweiterte Board
> > nach groben Tests funktioniert, aber mit Speicher-
> > erweiterung nichtmehr.
>
> Genau. Die Eurocom 1 (CPU-Karte) funktioniert mit allen lokalen
> Teilen, aber die Speichererweiterungen über die Backplane
> funktionieren beide nur sehr merkwürdig. In der Monitor-Software wie
> gewünscht, beim vollumfänglichen Code-Zugriff nicht.

Ähem, vielleicht ist das angeschlossenen Netzteil an seiner
Leistungsgrenze, die zusätzliche Belastung bringt es (zu sehr) ins
Schwitzen? Wenn das auch 30 Jahre alt ist...

Meinjanur,
Marc

[Gerrit Heitsch]

Ja, trockene Elkos kommen vor. Nicht nur im Netzteil sondern auch auf
den Karten selber.

Wenn die Karte im Monitor, also nur mit sporadischen Zugriffen,
funktioniert aber nicht mehr wenn der Code im dortigen Speicher zu
finden ist deutet sowas auf Probleme mit der Stromversorgung oder
Terminierung hin.

Ich hatte mal ein Problem in einem anderen Rechner. Der Austausch der
verbauten 74HCT245 gegen 74F245 brachte eine Verbesserung, aber gelöst
war das Problem erst nachdem ich Pulldowns (!) mit ein paar kOhm an die
Datenleitungen gehängt hatte.

Gerrit

[Marc Santhoff]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> schrieb:

> Ja, trockene Elkos kommen vor. Nicht nur im Netzteil sondern auch auf
> den Karten selber.

Wie ist das eigentlich mit den bedrahteten Tantalperlen auf dem Brettl?

Ich erinnere mich, daß die mal nach langer Lagerung beim Anlegen
einer Spannung gern explodiert sind, aber über Alterung weiß ich nichts.

Marc

[Ralf Kiefer]

Marc Santhoff wrote:

> Ähem, vielleicht ist das angeschlossenen Netzteil an seiner
> Leistungsgrenze, die zusätzliche Belastung bringt es (zu sehr) ins
> Schwitzen? Wenn das auch 30 Jahre alt ist...

Es ist ebenfalls 35 Jahre alt, aber ich habe es überprüft[1] und
verbessert, außerdem die Spannungen mit dem Oszi angeschaut. Bei den
aktuellen Tests nehme ich trotzdem ein Labornetzteil, das 3A liefern
kann. Damit bin ich weit genug vom max. Verbrauch meines Aufbaus
entfernt. Soll heißen: da liegt das Problem sicher nicht.

Gruß, Ralf

[1] Habe die großen Elkos ausgelötet und deren "Dichtigkeit" überprüft:
am Labornetzteil langsam bis knapp unter Nennspannung gefüllt,
hingelegt, nach einer Stunde nachgeschaut, wieviel Spannung noch drin,
für gut befunden und reingelötet.

[Ralf Kiefer]

Marc Santhoff wrote:

> Ich erinnere mich, daß die mal nach langer Lagerung beim Anlegen
> einer Spannung gern explodiert sind, aber über Alterung weiß ich nichts.

Mein Kenntnisstand und auch meine Erfahrung mit ungewöhnlichen
Rauchzeichen verbunden mit Lichteffekt und Geräusch beim Einschalten von
Hardware: entweder bleibt der Rauch in den Tantals drin und sie
funktionieren, oder der Rauch kommt raus und sie sind kaputt ;-) Dazu
brauchen die übrigens nicht unbedingt eine jahrelange Lagerung. Wochen
reichen ggf. schon. Andrerseits habe ich schon Tantals erlebt, die
verkehrt herum eingelötet waren, die daraufhin kurzfristig recht viel
Strom verheizt haben, aber nach richtig herum reinlöten pudelmunter
weitermachten. *flöt* ich war mal Student und brauchte das Geld für
wichtigeres ;-)

Gruß, Ralf

[Ralf Kiefer]

Gerrit Heitsch wrote:

> Ja, trockene Elkos kommen vor. Nicht nur im Netzteil sondern auch auf
> den Karten selber.

Auf den Karten ist kein einziger Elko, stattdessen Keramik oder Tantal.
Nur im Netzteil sind die großen Kapazitäten in der >=1000uF-Klasse
Elkos.

> Wenn die Karte im Monitor, also nur mit sporadischen Zugriffen,
> funktioniert aber nicht mehr wenn der Code im dortigen Speicher zu
> finden ist deutet sowas auf Probleme mit der Stromversorgung oder
> Terminierung hin.

Ich werde weiterhin in diese Richtung suchen.

> Ich hatte mal ein Problem in einem anderen Rechner. Der Austausch der
> verbauten 74HCT245 gegen 74F245 brachte eine Verbesserung, aber gelöst
> war das Problem erst nachdem ich Pulldowns (!) mit ein paar kOhm an die
> Datenleitungen gehängt hatte.

Gut, daß Du die Idee mit Pulldowns bringst. Sowas war auch schon mein
Gedanke, nur dachte ich, daß ich sowas noch nie gesehen habe, es also
eher eine sehr ungewöhnliche Maßnahme wäre.

Ich schaue mir jetzt erstmal die ganze Dekodierung an, ob da nicht
irgendwo ein Wurm drin ist (Glitches).

Gruß, Ralf

[Ralf Kiefer]

</ingrid> wrote:

> Die Dekodierung funktioniert auf der Eurocom 1 (CPU-Karte) lokal über
> NAND-Gatter (LS10), bei dem E, VMA und die Adreßleitungen verknüpft
> werden. Dahinter ist ein 7442.

Und dahinter ist ein 74LS266 mit o.K. für die /OE der EPROMS. Das steht
im alten Stromlaufplan nicht drin, denn das ist die Änderung von der
2708- zur 2716-Variante.

Die /CE der EPROMs liegen dauerhaft auf GND.

Mit einem (serienmäßigen) Pullup von 3k3 sieht das /OE so aus:
www.ralf-kiefer.de/hist/EltecE1/EPROM20ok.JPG
(1usec/cm)
Mit etwas weniger R an dieser Stelle (testweise um die 700Ohm):
www.ralf-kiefer.de/hist/EltecE1/EPROM20_1kOhmA.JPG
Oder mit 0,2usec/cm:
www.ralf-kiefer.de/hist/EltecE1/EPROM20_1kOhmB.JPG

Meinungen dazu? Sind die originalen 3k3 zu wenig?
Wäre es vorteilhaft die /CE der EPROMs mit E, /VMA oder /OE zu
versorgen, damit die EPROMS nicht ständig in Habachtstellung mitspielen?


Der Haken: die Zugriffe auf die externe Karte funktionieren immer noch
nicht besser.

Gruß, Ralf

[Hans-Peter Diettrich]

Ralf Kiefer schrieb:

> Gerrit Heitsch wrote:

>> Ich hatte mal ein Problem in einem anderen Rechner. Der Austausch der
>> verbauten 74HCT245 gegen 74F245 brachte eine Verbesserung, aber gelöst
>> war das Problem erst nachdem ich Pulldowns (!) mit ein paar kOhm an die
>> Datenleitungen gehängt hatte.
>
> Gut, daß Du die Idee mit Pulldowns bringst. Sowas war auch schon mein
> Gedanke, nur dachte ich, daß ich sowas noch nie gesehen habe, es also
> eher eine sehr ungewöhnliche Maßnahme wäre.

TTL Eingänge ziehen bei LOW wesentlich mehr Strom als bei HIGH, deshalb
legt man offene *Eingänge* (externe Schalter...) gerne mit Pullups auf
HIGH. Bei Bus-Leitungen hingegen kann man für ausgewogeneren Strombedarf
die Eingänge mit Pulldowns etwas runterziehen. Das sorgt dann allerdings
für einen undefinierten/verbotenen Pegel auf den Leitungen, wenn alle
Treiber abgeschaltet sind. Im regulären Betrieb, wenn immer ein Treiber
aktiv ist, macht das keine Probleme, man muß nur beim Messen aufpassen.

DoDi

[Andreas Graebe]

Am Thu, 05 May 2016 13:43:06 +0200 schrieb Ralf Kiefer:


> Der relevante Ausschnitt von der RAM-Karte:
> www.ralf-kiefer.de/hist/EltecE1/SHE_Ausschnitt.jpg Das Gepfusche zur
> (hier: Nicht-)Erzeugung vom MR-Signal braucht man nicht berücksichtigen,
> aber ganz unten der C26 stimmt mich jetzt gerade etwas bedenklich.

Nicht nur Dich. Die Schaltung ist nicht so toll. Was mir zunächst mal
auffällt, das E-Signal wird hier über I35 - R5 verzögert, das (früher
anstehende) VMA jedoch nicht. Eventuell bringt es etwas, diese beiden zu
tauschen (ausserdem verbessert das die Abschaltung um eine
Gatterlaufzeit). Wenn die RAMs langsam sind, kann das helfen. Weiterhin
ist R9 verdächtig, wenn der zu groß ist, verzögert sich die Abschaltung
vom Chipselect unnötig. Warum haben die da bloß überall open-Collector
benutzt? Grauenhaft. Wie groß sind denn R4, R5, R9 und C26?

Ganz drollig wird es dann bei der Beschaltung von I33 - I36. Pin 11 von
I33 ist immer High, da ja dessen Eingang A1 (Pin 13) ständig auf High
liegt. Warum also wird das an Pin 10 - I36 gelegt? Hat wohl keinen Sinn.

C26 würde ich mal einseitig ablöten.

Die Geschichte mit den Pulldowns ist eventuell auch eine Lösung, da ja
TTL-Gatter einen Eingangsstrom nach High ziehen. Eventuell hilft es auch,
die Bustreiber gegen 74HC(T) zu tauschen. Wenn die nicht eingelötet wären.

[Bernd Laschner]

Ralf Kiefer schrieb:

> [1] Habe die großen Elkos ausgelötet und deren "Dichtigkeit" überprüft:
> am Labornetzteil langsam bis knapp unter Nennspannung gefüllt,
> hingelegt, nach einer Stunde nachgeschaut, wieviel Spannung noch drin,
> für gut befunden und reingelötet.

Es wäre eine gute Idee gewesen, auch den ESR zu messen. Alternativ
kannst Du auch während des Betriebes die Spannung am Elko
oszillographieren und nachsehen, wie sauber die Spannung ist.




Bernd


--
Haie am Hafen - Kein E-Center am Hansaring!

https://www.facebook.com/haie.am.hafen/?fref=ts

[Ralf Kiefer]

Andreas Graebe wrote:

> Nicht nur Dich. Die Schaltung ist nicht so toll. Was mir zunächst mal
> auffällt, das E-Signal wird hier über I35 - R5 verzögert, das (früher
> anstehende) VMA jedoch nicht.

E wird invertiert. Mit den o.K.-Ausgängen und R5 sparen die sich ein
3fach-Gatter (NOR). Vermuteter Grund: fehlende Platinenfläche.

> Eventuell bringt es etwas, diese beiden zu
> tauschen (ausserdem verbessert das die Abschaltung um eine
> Gatterlaufzeit).

Muß ich mir als Kurve zeichnen und die Polaritäten beachten. VMA ist
tatsächlich VMA und kein /VMA.

> Weiterhin
> ist R9 verdächtig, wenn der zu groß ist, verzögert sich die Abschaltung
> vom Chipselect unnötig.

R9 ist uninteressant. Der kümmert sich um die Erzeugung vom /RDY-Signal
(sorry, oben hatte ich das als MR bezeichnet, wie es an der CPU heißt).
Und das wird hier nicht verwendet. J1 ist offen. Ich vermute, daß diese
Karte auch an der Eurocom 2 mit einem 6809 betrieben werden konnte, und
bei dem ein langsamer Speicher mit 350nsec eingebremst werden mußte.

> Warum haben die da bloß überall open-Collector
> benutzt? Grauenhaft.

ACK. Das ist nunmal der Aspekt bei der Archäologie, daß man frühere
Entwicklungsstufen anders beurteilen kann als die unmittelbar
Involvierten :-)

Oder vielleicht waren die gerade als Sonderangebot bei Bürklin im
Schaufenster ;-)

> Wie groß sind denn R4, R5, R9 und C26?

R5: 820Ohm
R4: 470Ohm
R9: 470Ohm
Ich sehe gerade, daß Du bessere Augen als ich hast. Ich hatte die
Kreuzung zwischen R9 und IC36,2 nicht als Verbindung gesehen. Ist es
aber, mit Durchklingeln bestätigt.
C26: 470pF

> Ganz drollig wird es dann bei der Beschaltung von I33 - I36. Pin 11 von
> I33 ist immer High, da ja dessen Eingang A1 (Pin 13) ständig auf High
> liegt. Warum also wird das an Pin 10 - I36 gelegt? Hat wohl keinen Sinn.

Hoppla! Ich hatte mir gestern dieses /WRITE-Signal für die RAMs
angeschaut: sieht schön und plausibel aus :-)

Ich habe mir jetzt, so wie Du, die Logik in eine Tabelle eingetragen.
Hm, krasser Widerspruch. Beim Durchklingeln zeigt sich, daß der Plan zu
stimmen scheint.

Das muß ich später in aller Ruhe nochmal machen. Es sieht verdächtig
aus.

> C26 würde ich mal einseitig ablöten.

Ich muß mir wohl erst den 2. Kanal vom Oszi reparieren, um so Sachen wie
den zeitlichen Zusammenhang am LS245 mit DIR und /OE anzuschauen.

> Die Geschichte mit den Pulldowns ist eventuell auch eine Lösung, da ja
> TTL-Gatter einen Eingangsstrom nach High ziehen. Eventuell hilft es auch,
> die Bustreiber gegen 74HC(T) zu tauschen. Wenn die nicht eingelötet wären.

74LS245 habe ich natürlich vorrätig, Sockel ditto. Bei HC(T) müßte ich
erst schauen. Vielleicht hätte ich noch ein paar ALS vorrätig um zu
schauen, ob die Gegenseite in Flammen aufgeht ;-)

Gruß, Ralf

[Ralf Kiefer]

Bernd Laschner wrote:

> Es wäre eine gute Idee gewesen, auch den ESR zu messen. Alternativ
> kannst Du auch während des Betriebes die Spannung am Elko
> oszillographieren und nachsehen, wie sauber die Spannung ist.

BTW das Netzteil ist ein ganz klassisches mit 50Hz-Trafo, 4 unabhängigen
Wicklungen, 4 Brückengleichrichtern und 4 Längsreglern:
www.ralf-kiefer.de/hist/EltecE1/E1NTBSklein.jpg

Nachdem ich anfangs Probleme mit der Spannungsversorgung vermutete,
hatte ich mit dem Oszi auch ins Netzteil geschaut. Primär wollte ich
natürlich wissen, wie weit die Spannung in den 100Hz-"Dellen" sinkt, und
ob die Spannung für den Längsregler noch reicht. Es sah gut aus. Zu gut
:-( Im Mittel rund 12V mit min. 10,5V liegen am 5V-Längsregler an.
Entsprechend heiß wird der Kühlkörper. Eine Optimierungsmaßnahme ist in
Vorbereitung.

Der Längsregler hat allerdings ein kleines Problem: der regelt bei
leichter Last sowieso nur auf 4,90V, und die Spannung bricht etwas ein,
wenn er im Bereich über 1A liefern muß und heiß ist. Abhilfe mit einer
Schottky-Diode im GND vom Längsregler ist eingebaut. Jetzt regelt der
auf 5,10 bis 5,20V je nach Last und Temperatur.

Daher teste ich das alles momentan am Labornetzteil.

Gruß, Ralf

[Holger]

Martin Gerdes schrieb:

> "Memory mapped" nannte man das Konzept damals. Es blieb für Z80-Jünger
> auf ewig unverstanden :-)


Allmählich lichten sich die Nebel um deinen Verstand. Jetzt kapiere ich
auch das Geheule wegen des 6502. Schon länger wundere ich mich über die
Dummheit der Computerianer, denen man sogar anschnacken kann, der
Computer auf der Paramountschüssel Entensteiß sei "überlichtschnell".

Ja, wenn es im Hirn nicht einmal dazu langt, Adressdecoder zu verstehen,
dann ist der Rest sowieso nicht kapierbar. Man kann übrigens auch mit
dem Z80 sehr wunderbar "memory mapped" seine Peripherie aufbauen. Und
man kann mit dem IO-Ports den Arbeitsspeicher nochmal nett erweitern,
ohne viel Aufwand zu treiben. Aber was solls: Wer sowas baut, braucht
heutzutage wenigstens Pfefferspray, um wenigstens zu verhindern,
totgeschlagen zu werden.

Holger

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Gerrit Heitsch]

Wenn man _CE eines ROM/EPROM fest auf GND legt kann man langsamere
EPROMs verwenden da die Laufzeit der Select-Logik nicht mehr
interessiert. _OE schaltet nur die Ausgangstreiber frei, das ist
deutlich schneller als wenn man über _CE steuert. Nachteil ist dann
eben, daß die Dinger dann die ganze Zeit vollen Strom brauchen.

Bevor du also _CE von GND entfernst stell sicher, daß die EPROMs schnell
genug sind.

Gerrit

[Gerrit Heitsch]

On 05/06/2016 05:42 AM, Hans-Peter Diettrich wrote:

> TTL Eingänge ziehen bei LOW wesentlich mehr Strom als bei HIGH, deshalb
> legt man offene *Eingänge* (externe Schalter...) gerne mit Pullups auf
> HIGH. Bei Bus-Leitungen hingegen kann man für ausgewogeneren Strombedarf
> die Eingänge mit Pulldowns etwas runterziehen. Das sorgt dann allerdings
> für einen undefinierten/verbotenen Pegel auf den Leitungen, wenn alle
> Treiber abgeschaltet sind.

Äh? Wieso? Wenn alle Treiber abgeschaltet sind ziehen die Pulldowns den
Eingang nach GND, da man einen Eingang direkt an GND hängen darf muss
das legal sein.

Einen illegalen Pegel schafft man nur, wenn man eine Art aktiver
Terminierung verwendet, die Widerstände also nicht an +5V oder GND
hängen sondern an einer weiteren Spannungsquelle zwischen beiden.

Gerrit

[Myn Seudop]

Holger:

> Dummheit der Computerianer
[...]

> Computer auf der Paramountschüssel Entensteiß

[...]

> Ja, wenn es im Hirn nicht einmal dazu langt

>[...]

> Wer sowas baut, braucht
> heutzutage wenigstens Pfefferspray, um wenigstens zu verhindern,
> totgeschlagen zu werden.

Na toll, jetzt habt ihr wieder den Holger-Bot getriggert. Dieser
Thread ist damit dem Untergang geweiht. Man kann hier echt nicht mehr
in Ruhe über Retroelektronik quatschen ohne dass sowas passiert. Es
hat schon einen Grund warum ich meine 6502-Diskussionen lieber in
einem Webforum führe.

Myn

[Holger]

Gerrit Heitsch schrieb:

> Bevor du also _CE von GND entfernst stell sicher, daß die EPROMs schnell
> genug sind.

Bei einem Megahertz Taktfrequenz sind die EPROMS in aller Regel schnell
genug, selbst wenn sie 450 ns für einen Zugriff brauchen.

[Holger]

Myn Seudop schrieb:

Genau, Mein Saudoof. Berichte doch bitte noch, was Radio Bremen von
meinen langsamen EPROMs hält, und warum ich dafür live und im
Regionalfernsehen öffentlich geteert und gefedert werde, mit launigen
Kommentaren auf Qualitätsstationen wie Bremen Vier und Bremen Eins, wo
man mich nie und nimmer als Redakteur haben will, was mich gefälligst zu
wurmen und mit einem ARD-Schock zu versehen hat!

[Hans-Peter Diettrich]

Gerrit Heitsch schrieb:

> On 05/06/2016 05:42 AM, Hans-Peter Diettrich wrote:
>
>> TTL Eingänge ziehen bei LOW wesentlich mehr Strom als bei HIGH, deshalb
>> legt man offene *Eingänge* (externe Schalter...) gerne mit Pullups auf
>> HIGH. Bei Bus-Leitungen hingegen kann man für ausgewogeneren Strombedarf
>> die Eingänge mit Pulldowns etwas runterziehen. Das sorgt dann allerdings
>> für einen undefinierten/verbotenen Pegel auf den Leitungen, wenn alle
>> Treiber abgeschaltet sind.
>
> Äh? Wieso? Wenn alle Treiber abgeschaltet sind ziehen die Pulldowns den
> Eingang nach GND, da man einen Eingang direkt an GND hängen darf muss
> das legal sein.

Kommt drauf an, wie nahe man an Gnd kommt. Hast Du Dir schon mal die
Schaltschwellen und zugehörige Eingangsströme der verschiedenen
Logik-Techniken angeschaut? Dir scheint nicht klar zu sein, daß TTL
Eingänge lang nicht so hochohmig sind wie MOS Eingänge.

Wenn der Pulldown so klein ist, daß der Bus (alle Eingänge!) unter 0,7V
liegt, dann wird der Strom riesig, mit dem später HIGH (2,7V) erreicht
wird. Rechne die erforderlichen Ströme einfach mal nach, und vergleiche
sie mit dem, was ein Treiber liefern kann.

DoDi

[Gerrit Heitsch]

On 05/06/2016 06:54 PM, Holger wrote:
> Gerrit Heitsch schrieb:
>
>> Bevor du also _CE von GND entfernst stell sicher, daß die EPROMs
>> schnell genug sind.
>
> Bei einem Megahertz Taktfrequenz sind die EPROMS in aller Regel schnell
> genug, selbst wenn sie 450 ns für einen Zugriff brauchen.

Nicht bei einem 65xx oder 68xx der sich den Bus mit etwas anderem teilt
(Videologik z.B.), dann hast du bei 1 MHz auf einmal nur noch 500ns pro
Zyklus und da werden EPROMs mit 450ns knapp wenn du den Trick mit _OE
nicht verwendest.

Gerrit

[Gerrit Heitsch]

Bei meinem Problem damals habe ich, der Erinnerung nach, Pulldowns mit
3,3 KOhm verwendet. Danach war das Problem mit kaputten Daten gelöst.
Auf der einen Seite war der Treiber ein 74F245 und auf der anderen
zuerst ein NS16550AF und dann ein ST16C650. Beides lief problemlos über
lange Zeit.


Gerrit

[Holger]

Martin Gerdes schrieb:
> Holger <hol...@invalid.invalid> schrieb:

>
>>> "Memory mapped" nannte man das Konzept damals. Es blieb für Z80-Jünger
>>> auf ewig unverstanden :-)
>
>> Allmählich lichten sich die Nebel um deinen Verstand. Jetzt kapiere ich
>> auch das Geheule wegen des 6502.
>

> Eher nicht. Du hast noch nie etwas verstanden und Geheule ist
> normalerweise Dein Panier.
>
> Die Opcodes des 6502 (hex!) kann ich noch heute, mittlerweile
> überflüssiges Wissen, aber gezielt löschen kann man Erinnerungen ja
> nicht.


Du lebst in einer Welt voller Widersprüche. Gut, dein Bier, aber immer
nur das Neueste zu predigen, Instandsetzungen scheiße zu finden, "alte"
Prozessoren sowieso, damit bist du mir aufgefallen, aber gut: Mir soll
das eins sein. Dann kennst du eben noch die Maschinensprache des 6502,
ich wäre damit ein "Korbflechter und Hufschmied", solle Spüli trinken
und Rabäh sagen, wie ich hier zu lesen bekam. Nee, ich finde das ja
nett, wenn hier jemand Adressdekoder für solche Prozessoren nachfragt,
vor allem vor genau diesem Hintergrund. Und wenn dann wer wie du antanzt
und meint, in der Welt der Z80-Anwender würde man so gar nicht
verstehen, daß man mit dem 74LS154 und dem 74LS138 und dem 74LS139 und
anderen Binärdekodern den Adressraum aufteilen kann, dann schlage ich
die Hände über dem Kopf zusammen. Als wenn jemand, der seine Peripherie
mit IORQ (Pin 20) adressiert, nicht kapieren könnte, daß man dasselbe
mit MREQ (Pin19) machen könnte, wobei man dann allerdings auf die
IO-Befehle verzichten und die Bausteine wie Speicher ansprechen müßte.

Gut, Fans sind was anderes als Schaltungsentwickler, aber nachdem der
Apple II klargemacht hat, daß Z80 und 6502 in einem System arbeiten
können, sollte doch der "memory mapped"-Zugriff auch in der Z80-Welt
populär genug geworden sein.

[Ralf Kiefer]

Gerrit Heitsch wrote:

> Bevor du also _CE von GND entfernst stell sicher, daß die EPROMs schnell
> genug sind.

Argl! Ich habe jetzt nachgeschaut, was in den Stangen drin ist:
450nsec-Typen. Damit hat sich das mit dem /CE zur Sicherheit mit was
anderem belegen und irgendwelche Spikes ausbremsen erledigt.

Gruß, Ralf

[Gerrit Heitsch]

On 05/07/2016 08:38 AM, Martin Gerdes wrote:
>
> Ansonsten: Ich habe mal einen Rechner gebaut, bei dem ein 6502 und ein
> 6809 auf den gleichen RAM-Speicher zugegriffen haben (der 6809 als
> Hauptprozessor, der 6502 vorwiegend zum Multiplexen der Anzeigeplatine
> aus 5x7-Matrizen). Die beiden Prozessoren haben mit dem gleichen Takt
> gearbeitet, aber halt gegenphasig. EPROM-Zugriffszeit hat keine Rolle
> gespielt, weil die EPROMS (logischerweise) separat in den Adreßraum
> eingeblendet waren, das (statische) RAM war damals schon schnell genug
> für den doppelten Takt.

Ist immer eine Frage wie das im Detail aufgebaut ist. Die grossen
Commodore-Floppies haben den gleichen Trick benutzt damit die CPUs
untereinander Daten austauschen konnten.

Man sollte es auf jeden Fall im Auge behalten, es kann einen Grund haben
warum _CE fest auf GND liegt und über _OE gesteuert wird.

Gerrit

[Guido Grohmann]

Martin Gerdes schrieb:

> Das eher nicht, aber ich will zugeben, daß es mir einen gewissen Spaß
> bereitet, Dich aus dem Kästchen hüpfen zu lassen.

Was für ein mieser Charakter du doch bist.

Guido

[Heinz Schmitz]

Guido Grohmann wrote:

>> Das eher nicht, aber ich will zugeben, daß es mir einen gewissen Spaß
>> bereitet, Dich aus dem Kästchen hüpfen zu lassen.

>Was für ein mieser Charakter du doch bist.

Noch ein Böhmermann?

Grüße,
H.

[Holger]

Martin Gerdes schrieb:
> Holger <hol...@invalid.invalid> schrieb:
>

>> Du lebst in einer Welt voller Widersprüche.
>

> Das eher nicht, aber ich will zugeben, daß es mir einen gewissen Spaß
> bereitet, Dich aus dem Kästchen hüpfen zu lassen.

Du schreibst Schrott. Deine neoliberale Propagandashow hier ist einfach
Dreck und steht jedem Gedankenaustausch massiv im Wege, weil man sich
aufgrund deiner Propaganda und aufgrund deiner sachlich unbegründeten
Angriffe schon sehr überlegen muß, ob man sich wirklich zu technischen
Themen äußern will, die stolze Besitzer neuester Jubelelektronik für
"veraltet" halten, so wie deine dummen Bemerkungen über den Z80 zeigen,
den du von der Sache her nicht begreifst, den du nur als Schlagwort benutzt.

> Und Du tust es ja reproduzierbar. Als Wadenbeißer bist Du gewissermaßen
> ein "Old Faithful".

Was abermals zeigt, daß man hier eben *nicht* über EPROMs und deren
technische Verwendung in Mikrocomputern schreiben sollte. So gerne ich
weitergebe, was ich über solche Bauteile weiß, aber bei Typen wie dir
ist das der Wurf von Perlen vor die Säue. Deine Fachkunde kann man so
zusammenfassen: Alt = Wegschmeißen. Neu = Kaufen! Und das ist hohl.

Holger

[Ralf Kiefer]

Gerrit Heitsch wrote:

> Man sollte es auf jeden Fall im Auge behalten, es kann einen Grund haben
> warum _CE fest auf GND liegt und über _OE gesteuert wird.

Die Eurocom-1-Platine wurde 1978/1979 (für 2708) entwickelt. Zu dieser
Zeit waren schnellere EPROMs als die mit 450nsec rar und teuer, AFAIK.
Beim kurzen Nachdenken über E-Takt bei 1MHz sowie die Gatterlaufzeiten
zur Dekodierung denke ich mir, daß das der Grund für das Festnageln vom
/CE ist.

BTW beim nächtlichen "Herumstochern" in den Platinen fiel mir was Neues
auf: auf der Eltec-RAM-Karte ist zwar für jeden SRAM-Sockel ein
Blockkondensator vorgesehen und bestückt, aber beim Oszi-Angucken sah
die Spannungsversorgung an den RAMs in der Schleife mit ständigen
Zugriffen nicht sonderlich gut aus. Dünne Leiterbahnen sind das Eine,
aber das andere sind die Kondensatoren mit 10nF. Ich habe die eine Reihe
gleich rausgelötet und 100nF rein. Sieht schon etwas besser aus. Die
Peaks machten in Summe >500mV aus, jetzt um die 200mV (mit dem
Uralt-Oszi abgeschätzt).

Die Karte geht trotzdem noch nicht, was logisch ist, denn mein einzelnes
SRAM hat genausowenig Lust. Aber ich habe eine Idee dem mit etwas
Software beizukommen :-)

Gruß, Ralf

[Ralf Kiefer]

Martin Gerdes wrote:

> Es geht hier aktuell ja nur um eine hobbymäßige Wiederinbetriebnahme
> eines 6802-Einplatinensystems. Wenn das wieder sicher läuft, ist der OP
> sicherlich zufrieden.

Ja.


> Eine historisch "korrekte" Wiederherstellung ist
> nicht geplant, das zeigt schon die Näherei mit dem Fädeldraht.

Zumal ich immer mehr zweifle, ob das jemals zuverlässig funktioniert
haben kann. Nicht nur meine Platine mit dem Schaden, der durch
Fädeldraht repariert werden mußte. Daher: nein, einen originalgetreuen
Aufbau mit Funktion halte ich mittlerweile für ausgeschlossen.


Gruß, Ralf

[Gerhard Hoffmann]

Am 07.05.2016 um 08:48 schrieb Gerrit Heitsch:

> Man sollte es auf jeden Fall im Auge behalten, es kann einen Grund haben
> warum _CE fest auf GND liegt und über _OE gesteuert wird.

Es gab auch 2708-Versionen bei denen genau das nicht funktioniert hat.
Dynamisches N-MOS. Ich kannte mal einen, der hat einen
Ascii/Baudot-Converter gebaut mit einem 2708 zum Mappen.
Da kamen durchaus erst mal die richtigen Daten raus, aber nach
ein paar usec sind sie vergammelt weil das nächste
precharge überfällig war, und das hing am /CE.

[Gerhard Hoffmann]

Am 06.05.2016 um 12:10 schrieb Martin Gerdes:

> "Memory mapped" nannte man das Konzept damals. Es blieb für Z80-Jünger
> auf ewig unverstanden :-)
>

Ja, der war ja auch so schnell, dass er den opcode-fetch
mit langsamen Proms dehnen musste. Und für I/o gab's einen
funktionsfähigen DMA.

;-) Gerhard

[Marc Haber]

Holger <m...@privacy.org> wrote:
>Du schreibst Schrott. Deine neoliberale Propagandashow hier ist einfach
>Dreck und steht jedem Gedankenaustausch massiv im Wege, weil man sich
>aufgrund deiner Propaganda und aufgrund deiner sachlich unbegründeten
>Angriffe schon sehr überlegen muß, ob man sich wirklich zu technischen
>Themen äußern will, die stolze Besitzer neuester Jubelelektronik für
>"veraltet" halten, so wie deine dummen Bemerkungen über den Z80 zeigen,
>den du von der Sache her nicht begreifst, den du nur als Schlagwort benutzt.

Und Du sagst Du wirst angepöbelt.

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Gerrit Heitsch]

On 05/07/2016 01:28 PM, Ralf Kiefer wrote:
> Gerrit Heitsch wrote:
>
>> Man sollte es auf jeden Fall im Auge behalten, es kann einen Grund haben
>> warum _CE fest auf GND liegt und über _OE gesteuert wird.
>
> Die Eurocom-1-Platine wurde 1978/1979 (für 2708) entwickelt. Zu dieser
> Zeit waren schnellere EPROMs als die mit 450nsec rar und teuer, AFAIK.
> Beim kurzen Nachdenken über E-Takt bei 1MHz sowie die Gatterlaufzeiten
> zur Dekodierung denke ich mir, daß das der Grund für das Festnageln vom
> /CE ist.
>
> BTW beim nächtlichen "Herumstochern" in den Platinen fiel mir was Neues
> auf: auf der Eltec-RAM-Karte ist zwar für jeden SRAM-Sockel ein
> Blockkondensator vorgesehen und bestückt, aber beim Oszi-Angucken sah
> die Spannungsversorgung an den RAMs in der Schleife mit ständigen
> Zugriffen nicht sonderlich gut aus. Dünne Leiterbahnen sind das Eine,
> aber das andere sind die Kondensatoren mit 10nF. Ich habe die eine Reihe
> gleich rausgelötet und 100nF rein. Sieht schon etwas besser aus. Die
> Peaks machten in Summe >500mV aus, jetzt um die 200mV (mit dem
> Uralt-Oszi abgeschätzt).

Versuch mal 200nF für die RAMs. Eigentlich sind SRAMs nicht so das
Problem, eher DRAMs, aber ich kenne Platinen bei denen die RAMs mehr als
die 100nF haben

> Die Karte geht trotzdem noch nicht, was logisch ist, denn mein einzelnes
> SRAM hat genausowenig Lust. Aber ich habe eine Idee dem mit etwas
> Software beizukommen :-)

Nix, Hardwarefehler löst man mit Hardware. :)

Gerrit

[Gerrit Heitsch]

Solche Exoten gibt es leider... Ich habe hier eine Ladung 2114-Clones
aus DDR-Produktion liegen (UL224) bei denen die fallende Flanke an _CE
die anliegende Adresse in einem Latch festhält. Das klappt meist... Aber
nicht im C64, der VIC liest nur Müll weil die Logik bei dessen
(Lese-)Zyklus _CE aktiv schaltet bevor die Adressen korrekt anliegen.
Ein normales 2114 stört das nicht. Da hilft nur ein OR von _CE mit _RAS,
dann klappt es auch mit dem UL224.

Gerrit

[Rafael Deliano]

> Bei meinem SRAM habe ich zwei LS-Gatter-Durchlaufzeiten fürs CS

Primitiver Test war auch immer daß man Quarz versuchsweise
wechselt. D.h. 20% langsamer oder 50% langsamer falls das Board
nicht funktioniert und man zu langsamen Speicher vermutet.
Oder 20% schneller um zu sehen ob es nur knapp funktioniert.

MfG JRD

[Holger]

Marc Haber schrieb:

> Holger <m...@privacy.org> wrote:
>> Du schreibst Schrott. Deine neoliberale Propagandashow hier ist einfach
>> Dreck und steht jedem Gedankenaustausch massiv im Wege, weil man sich
>> aufgrund deiner Propaganda und aufgrund deiner sachlich unbegründeten
>> Angriffe schon sehr überlegen muß, ob man sich wirklich zu technischen
>> Themen äußern will, die stolze Besitzer neuester Jubelelektronik für
>> "veraltet" halten, so wie deine dummen Bemerkungen über den Z80 zeigen,
>> den du von der Sache her nicht begreifst, den du nur als Schlagwort benutzt.
>
> Und Du sagst Du wirst angepöbelt.

Der soziale Faktor ist auch alles, was dich hier interessiert, denn nur
dort und ausschließlich nur dazu kannst du sagen, man würde pöbeln.

Nein: Mich stört es, wenn jemand offenen Blödsinn über den Z80 schreibt
und glaubt, man könne da als Benutzer, Z80-verblödet, kein "memory
mapping" mit schalten, und wenn ich dann nur noch neoliberalen Quatsch
zu lesen bekomme, mit dem offenen Ziel, mich zum Zwecke der Unterhaltung
zum Widerspruch anzustacheln, und das wiederum alles nur, weil ich hier
ein paar Fragen zum Betrieb von EPORMs am Z80-Bus geschrieben habe.
Allein der Stuß aus neoliberaler Schnauze, Z80-Anwender, er nennt sie
Jünger, als wäre das ein Gott, wären nie und ewig nicht in der Lage,
einen Adressdecoder für den Hauptspeicher zu verstehen, geht mir gegen
den Strich. Als wenn die Pins 19 und 20 am Gehäuse der CPU einen
Menschen automatisch zum Idioten machen würden, da kann ich nur mit dem
Kopf schütteln.

Und dann man liest hier nur so ein social-media-Geschwafel, von Leuten
wie dir ja auch, die mit praktischer Elektronik völlig überfodert sind,
aber ansonsten gut erzählen können.

Mann, so gerne ich den Leuten bei ihren technischen Fragen helfe, aber
dieses Geschwafel geht mir schlicht auf den Geist. Wenn du wenigstens
wissen könntest, was das eigentliche Problem war, aber das wirst du
genauso gut verstehen wie eine Kuh die Botanik, die sie behaglich frißt.

Also lassen wir das.

H.

[Ralf Kiefer]

Rafael Deliano wrote:

> Primitiver Test war auch immer daß man Quarz versuchsweise
> wechselt.

Gute Idee! Die CPU lebt mit einem 4MHz-Quarz. Da müßte ich mindestens
den üblichen um die 3,6-MHz herumfliegen haben, und einen 4,9irgendwas
wohl auch.

Gruß, Ralf

[Gerhard Hoffmann]

ein halber 74x74 möglicherweise? 3.6 MHz macht das Kraut nicht fett.

Wenn damals(r) Rechner nicht zuverlässig liefen, waren das meist
Speicherfehler weil man das noch nicht verinnerlicht hatte, dass
Speicher-Arrays wenigstens ein 2D-Massenetz brauchten, wenn man
schon mit 2 Lagen auskommen musste. Ein paar Drähte senkrecht
zur Haupt-Masserichtung des Arrays bewirkten oft Wunder.


Ok, ich kenne auch einen Fall, wo das Speichertestprogramm als einziges
ewig fehlerfrei lief, und sonst nix.

Das war ein Z80 mit 7 Bit-Refreshzähler und Siemens-64K-Chips, die
einen 8Bit-Zähler gebraucht haben. Der gute Mann war nicht froh, als
ich ihm das erklärt habe. Er hatte schon ziemlich viel Material gekauft.

Gruß, Gerhard

[Ralf Kiefer]

Martin Gerdes wrote:

> R.Kiefe...@gmx.de (Ralf Kiefer) schrieb:

>
> >Die Eurocom-1-Platine wurde 1978/1979 (für 2708) entwickelt. Zu dieser
> >Zeit waren schnellere EPROMs als die mit 450nsec rar und teuer, AFAIK.
>

> Klar. Aber es lag schon in der Luft, daß man die dreifache
> Spannungsversorgung, die der 2708 noch brauchte, wegrationalisieren
> wollte. Der Nachfolgetyp 2716 hatte dann ja auch nur noch eine
> Spannungsversorgung von 5V.

Meine ist sozusagen die V2.0-Platine: keine 2708, ausschließlich +5V und
zwei Sockel für je einen 2716. Das Timing wurde durch die Änderung der
Adreßdekodierung verschlechtert. Der Weitblick hin um 2732 fehlte den
Entwicklern allerdings.

Gruß, Ralf

[Ralf Kiefer]

Gerrit Heitsch wrote:

> Versuch mal 200nF für die RAMs. Eigentlich sind SRAMs nicht so das
> Problem, eher DRAMs, aber ich kenne Platinen bei denen die RAMs mehr als
> die 100nF haben

Haben Tantals an dieser Stelle Vor- oder Nachteile? Die Frage deswegen,
weil ich ein paar kleine Tantalperlen mit 0,33uF habe und unter die
100nF KerKo löten könnte.

> > Die Karte geht trotzdem noch nicht, was logisch ist, denn mein einzelnes
> > SRAM hat genausowenig Lust. Aber ich habe eine Idee dem mit etwas
> > Software beizukommen :-)
>
> Nix, Hardwarefehler löst man mit Hardware. :)

Ich will ein paar Assemblerbefehle *nur* für die *unterstützende*
Hardware-Fehlersuche nehmen :-)

Gruß, Ralf

[Ralf Kiefer]

Gerhard Hoffmann wrote:

> Wenn damals(r) Rechner nicht zuverlässig liefen, waren das meist
> Speicherfehler weil man das noch nicht verinnerlicht hatte, dass
> Speicher-Arrays wenigstens ein 2D-Massenetz brauchten, wenn man
> schon mit 2 Lagen auskommen musste. Ein paar Drähte senkrecht
> zur Haupt-Masserichtung des Arrays bewirkten oft Wunder.

Das ist sicher ein Gesichtspunkt. Allerdings habe ich den Fehler auch
bei meiner kleinen Fädelkarte mit einem 62256 und einem 74LS10, wo ich
die Spannungsversorgung mit fetten Drähten gebastelt habe. Das Teil ist
mit <10mA dabei und hat ausreichend Kapazitäten drauf.

> Ok, ich kenne auch einen Fall, wo das Speichertestprogramm als einziges
> ewig fehlerfrei lief, und sonst nix.

Mit solch einer Aufgabe war ich irgendwann in den späten 1980er Jahren
als Praktikant beschäftigt, als ich initiale Testroutinen für frisch
gelötete VMEbus-Hardware schrieb. Da hatte ich u.a. geeignete Bitmuster
schreiben und lesen lassen, und dabei nach Übersprechen, Spiegelungen
(Kurzschlüsse zwischen Adreßleitungen oder Unterbrechungen von
Adreßleitungen), u.ä. suchen lassen. Das war etwas aufwendiger, weil
32bit breiter Speicher, mehrere bestückte Bänke möglich, "ungerade"
Zugriffe wg. 68k-CPU, Cache, usw. Das jetzige Problem mit 8bit breitem
Speicher ist dagegen vergleichsweise einfach.

Mein Bauchgefühl sagt mir momentan, daß ich hier ein Problem im Timing
der Dekodierung habe, wo mir durch bisher unbekannte und gesuchte
Effekte nicht nur die externe Speicherkarte dekodiert und aktiv wird,
sondern zusätzlich noch ein anderer Chip.


Gruß, Ralf

[Holm Tiffe]

On 07.05.2016 17:06, Gerrit Heitsch wrote:
> On 05/07/2016 01:42 PM, Gerhard Hoffmann wrote:
>> Am 07.05.2016 um 08:48 schrieb Gerrit Heitsch:
>>
>>> Man sollte es auf jeden Fall im Auge behalten, es kann einen Grund haben
>>> warum _CE fest auf GND liegt und über _OE gesteuert wird.
>>
>> Es gab auch 2708-Versionen bei denen genau das nicht funktioniert hat.
>> Dynamisches N-MOS. Ich kannte mal einen, der hat einen
>> Ascii/Baudot-Converter gebaut mit einem 2708 zum Mappen.
>> Da kamen durchaus erst mal die richtigen Daten raus, aber nach
>> ein paar usec sind sie vergammelt weil das nächste
>> precharge überfällig war, und das hing am /CE.
>
> Solche Exoten gibt es leider... Ich habe hier eine Ladung 2114-Clones
> aus DDR-Produktion liegen (UL224)
> bei denen die fallende Flanke an _CE
> die anliegende Adresse in einem Latch festhält.

..muß es denn bei Allem was aus der DDR kommt ein Clone sein?
Es gab aus der DDR den U214 in NMOS, nenne den von mir aus 2114
Clone,aber der CMOS RAM U224 ist ganz einfach kein Clone und das da ein
Adreßlatch implementiert ist war von Anfang an dokumentiert.
Zwangsläufig ist das halt kein Clone, sondern eine Eigenentwicklung.

[..]
>
> Gerrit
>

Sorry, aber solcherlei Geschwafel geht mir ganz einfach auf den Wecker.

Gruß,

Holm

[Holm Tiffe]

On 06.05.2016 12:10, Martin Gerdes wrote:
> R.Kiefe...@gmx.de (Ralf Kiefer) schrieb:
>

>>> Haben alle Schreibbefehle des 6802 dasselbe Timing? Oder wird bei Zugriff
>>> auf das EPROM das 6802-Gegenstueck zu /WAIT Zyklen eingefuegt, und bleibt
>>> Schreiben von Speicher faelschlich wirksam?
>
>> Es gibt keine Wait states oder Handshake in dieser Hardware. Ein 6802
>> könnte das prinzipiell, um mit noch langsamerem Speicher zu
>> funktionieren, weswegen es die MR-Leitung gibt. D.h. hier laufen alle
>> Speicherzugriffe nach demselben Schema, egal ob I/O-Chip, EPROM oder
>> RAM.

>
> "Memory mapped" nannte man das Konzept damals. Es blieb für Z80-Jünger
> auf ewig unverstanden :-)
>

Ich bin durchaus als gelernter Ossi auch "Z80 Jünger", kann Deine
Aussage nicht nachvollziehen und wüßte nicht was mich daran hindern
sollte einen Z80 Rechner mit Memory mapped IO aufzubauen, höchstens die
Tatsache das ein großer Teil der attraktiven Features der Z80
Peripherie-ICs nicht mehr nutzbar ist und der lineare Adreßraum für den
Speicher durch das IO löchrig wird. Nur Nachteile auf dieser Architektur
also.

Das ist wohl das was die 6x0x Jünger Niemals verstanden haben.

Gruß,

Holm

[Peter Heitzer]

Memory mapped I/O ist sinnvoll, wenn man z.B. 16 Bit ausgeben will, wie
für eine IDE Schnittstelle oder wenn die Peripherie RAM ähnlich
ansprechbar ist und man mit Read-Modify-Write Befehlen arbeiten kann.
Auch wenn mehr als 256 Bytes mit einem Blockbefehl ausgegeben werden
sollen, ist memory mapped I/O sinnvoll.
Für "klassische" I/O mit Interrupts ist allerdings die Z80 Architektur
um einiges eleganter.


--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[Holger]

Holm Tiffe schrieb:

> Das ist wohl das was die 6x0x Jünger Niemals verstanden haben.

Ich habe durchaus Schaltungen mit dem 6502 aufgebaut und auch
verstanden, daß der 6502 seine Prozessorregister für die indirekte
Addressierung im Arbeitsspeicher ablegt (Zeropage), und auch die Sache
mit dem I/O, dessen Bausteine wie Speicherchips angesprochen werden
müssen, weil es keine speziellen Befehle für die Ein- und Ausgabe gibt,
und weil es auch keine spezielle Leitung wie IORQ gibt.

Kann man alles machen. Solange man nicht drüber redet. Erzählt man
dieses, löst man religiöse Glaubenskriege aus. Sogar heute noch, rund 40
Jahre nach dem erstmaligen Erscheinen dieser Schaltkreise.

Heute betreibt man mit 4- und 8-Bit-CPUs sogemanntes "embedded
computing". Und also heißen die Rechner auf deren Basis auch nicht mehr
"Computer", sondern Waschmaschine und Kühlschrank, Automotor und
Cassettendeck, Fernseher und mobiles Telefon, und so weiter, und so
fort; sogar Medizintechnik gibt es auf deren Basis.

Nein, was mich an der Propaganda von Martin Gerdes so stört, ist diese
bleischwere Dummheit und das völlige Unverständnis für einen
pragmatischen Umgang mit diesen Bauteilen, ob sie nun von Atmel oder von
Microchip, von Zilog oder dem Western Design Center, Intel oder AMD,
Infinion oder Thomson, von Texas Instruments oder Freescale oder aus der
Zeit stammen, wo diese Firma noch Motorola hieß. Was zählt, ist einzig
die Funktion der Produkte auf deren Basis, und deren Betriebssicherheit
in den Umgebungen, für die sie entwickelt worden sind.

Das genau wird hier nicht verstanden, und von daher stellt sich durchaus
die Frage, wie sinnvoll ist das Diskutieren hier eigentlich noch? Wenn
die ganze Fachkunde hier nur aus der Werbung stammt, aber nicht aus den
Datenblättern, den sogenannten Application Notes und der Fachliteratur?
Es gibt doch den Knuth für die Programmierung und den Horowitz für die
Schaltungstechnik? Liest das denn keiner mehr?

Was es hingegen braucht, sind Ideen. Wenn sich jemand zum Beispiel mit
dem Arduino eine automatische Gitarre baut, hat er sofort meine volle
Sympathie dafür. Aber wenn man ihm am Ende noch die Zähne ausschlägt
oder sozial ausgrenzt, weil der den jeweiligen Lieblingsprozessor nicht
einsetzt, dann schlägt meine Uhr dreizehn. Und deshalb setze ich mich
lieber mit zum Beispiel ein paar Bauteilen aus der Z80-Welt hin und
mache mir damit was Feines, während ich im Usenet für die Leute ein
geprügelter Idiot bin, wegen meiner angeblichen 6502-Versessenheit.

Und dir antworte ich auch nur, weil ich dich für einen hilfsbereiten und
netten Menschen halte. Dein EPROG funktioniert übrigens noch. Er hat nur
ein ansprechenderes Gehäuse und ein Netzteil bekommen.

Holger

[Gerhard Hoffmann]

Am 09.05.2016 um 10:28 schrieb Peter Heitzer:

>> Das ist wohl das was die 6x0x Jünger Niemals verstanden haben.
> Memory mapped I/O ist sinnvoll, wenn man z.B. 16 Bit ausgeben will, wie
> für eine IDE Schnittstelle oder wenn die Peripherie RAM ähnlich
> ansprechbar ist und man mit Read-Modify-Write Befehlen arbeiten kann.
> Auch wenn mehr als 256 Bytes mit einem Blockbefehl ausgegeben werden
> sollen, ist memory mapped I/O sinnvoll.
> Für "klassische" I/O mit Interrupts ist allerdings die Z80 Architektur
> um einiges eleganter.

Für mapped IO auch, weil der DMA das Adressieren von Speicher und device
sogar gleichzeitig erledigen konnte. Und das ging auch für 16 Bit und
Blocktransfers, wenn Speicher und Devices das unterstützt haben.
Die CPU hat die Daten nie lesen & schreiben müssen, die flossen einfach
an ihr vorbei.

Gruß, Gerhard

[Holm Tiffe]

Ich diskutiere nicht über Sinn/Unsinn von memory mapped IO, wenn das aus
irgend einem Grunde günstiger ist, warum nicht?

Du kannst mir aber mal erklären wieso für 16 Bit Ausgaben ausgerechnet
das sinnvoller sein soll, genau da hält nämlich die Z80 Architektur mit
der Ausgabe über Register C ein Schmankerl bereit und 16 Bit am Stück
werde ich bei memory mapped auch nicht los, es sei denn ich verwurste
die Adresse..


Gruß,

Holm

[Holm Tiffe]

On 09.05.2016 11:01, Holger wrote:
> Holm Tiffe schrieb:
>
>> Das ist wohl das was die 6x0x Jünger Niemals verstanden haben.
>
> Ich habe durchaus Schaltungen mit dem 6502 aufgebaut und auch
> verstanden, daß der 6502 seine Prozessorregister für die indirekte
> Addressierung im Arbeitsspeicher ablegt (Zeropage), und auch die Sache
> mit dem I/O, dessen Bausteine wie Speicherchips angesprochen werden
> müssen, weil es keine speziellen Befehle für die Ein- und Ausgabe gibt,
> und weil es auch keine spezielle Leitung wie IORQ gibt.
>
> Kann man alles machen. Solange man nicht drüber redet. Erzählt man
> dieses, löst man religiöse Glaubenskriege aus. Sogar heute noch, rund 40
> Jahre nach dem erstmaligen Erscheinen dieser Schaltkreise.
>

Ach Gottchen, Du warst ja nun gerade nicht angesprochen :-)

Wir hatten doch noch nie ein Problem miteinander Holger. Ich mag den
6502 nicht so besonders, das liegt aber weniger daran das der nichts
taugen würde, sondern das ich mich mit ihm erst viel später mal befaßt
habe als mit dem Z80. Ich verurteile ihn aber nicht. wenn man mit dem
Ding was basteln möchte, warum nicht? Für mich ist heutiges Z80 basteln
auch eher Erholung als Arbeit, das mach ich aus Lust und Laune wenn ich
Zeit habe. Es ist doch völlig Banane mit welchem veralteten Prozessor
man so rumwerkelt..nett finde ich z.B. den 6809 (netter den 6309).

...ja der Eprog..diese Krücke :-)

Klar, wenn man den lansgam genug über die serielle Schnittstelle füttert
dann tut er, beim kopieren klappts ja auch.
Mit unverzögerter (zwischen den Zeichen) RS232 wird das aber Brühe..

Gruß,

Holm

[Peter Heitzer]

Holm Tiffe <ho...@freibergnet.de> wrote:
>Ich diskutiere nicht über Sinn/Unsinn von memory mapped IO, wenn das aus
>irgend einem Grunde günstiger ist, warum nicht?

>Du kannst mir aber mal erklären wieso für 16 Bit Ausgaben ausgerechnet
>das sinnvoller sein soll, genau da hält nämlich die Z80 Architektur mit
>der Ausgabe über Register C ein Schmankerl bereit und 16 Bit am Stück
>werde ich bei memory mapped auch nicht los, es sei denn ich verwurste
>die Adresse..

Die IO-Befehle sind AFAIR langsamer als Befehle für den Speicher und
weniger universell. Ein INC oder DEC auf einen I/O Port geht damit nur
über mehrere Befehle. Ein ld (nn),hl ist außerdem eine atomare Anweisung,
was u.U. bei Multitaskern ein Geschwindigkeitsvorteil sein kann.

[Hans-Peter Diettrich]

Holm Tiffe schrieb:

> ....ja der Eprog..diese Krücke :-)

>
> Klar, wenn man den lansgam genug über die serielle Schnittstelle füttert
> dann tut er, beim kopieren klappts ja auch.
> Mit unverzögerter (zwischen den Zeichen) RS232 wird das aber Brühe..

Ich habe mir seinerzeit eine Flush-Karte für meine EPROMS gebaut. Beim
Schreiben wurde der Prozessor angehalten, bis die Daten programmiert
waren. Schreibschutz für alle EPROMS durch Abklemmen der zusätzlichen
Programmierspannungen. Mit den kleinen EPROMS, die ich damals hatte,
ohne ausgeklügelte Schreibfunktionen, war das die einfachste Lösung, und
hat beim Eintippen der HEX Codes auch nicht weiter gestört :-)

DoDi

[Hans-Peter Diettrich]

Holm Tiffe schrieb:

Da bahnt sich schon wieder ein Krieg der Welten an :-(

Die Idee hinter der Trennung von Speicher und I/O war die einfache
Dekodierung von Adressen, und die volle Ausnutzung des kostbaren RAM.
Das geht aber nur auf Kosten des Befehlssatzes (zusätzliche I/O Befehle)
und zusätzlicher Prozessor-Pins, die heute besser für Adressleitungen
genutzt werden könnten. Die wirklich attraktive Z80 Periperie war
absichtlich an dieses Konzept gebunden, um diesen speziellen Prozessor
zu pushen.

DMA hat mit beiden Konzepten nichts zu tun, solange nur ein einziger
Adressbus verfügbar ist. Entweder muß der DMA Controller byteweise lesen
und dann schreiben, oder spezielle Signale an den angesprochenen
Baustein schicken, wenn die Daten in einem Rutsch übertragen werden
sollen. Da bleibt als einziges Argument gegen MM I/O übrig, daß die
Adressen für die Peripherie mehr Adressbits im DMA Controller erfordern.
Wenn aber gleichzeitig Speicher-zu-Speicher Transfer gewünscht wird,
oder mehr I/O Kanäle als der Controller handhaben kann, fällt dieses
Argument wieder weg.

Eine "beste" Lösung wurde bis heute nicht gefunden, speziell bei der
Behandlung des Bildwiederholspeichers für Displays. Derzeit wird die
Peripherie über eigene (serielle) Bus-Systeme angesprochen (SATA, USB,
I2C, CAN...), was HP mit HP-IL auch schon vor sehr langer Zeit erfunden
hatte. Preisfrage: welche Mikroprozessoren hatten schon solche serielle
Hardwareunterstützung an Bord?

DoDi

[Ralf Kiefer]

Hans-Peter Diettrich wrote:

> Eine "beste" Lösung wurde bis heute nicht gefunden, speziell bei der
> Behandlung des Bildwiederholspeichers für Displays.

Es gab eine Zeit, in der es VRAMs gab, d.h. die waren dual ported und
hatten auf der Videoseite ein riesiges Schieberegister.

> Preisfrage: welche Mikroprozessoren hatten schon solche serielle
> Hardwareunterstützung an Bord?

Bekomme ich für die richtige Antwort ein nagelneues Transputer Board?

Gruß, Ralf

[Holger]

Holm Tiffe schrieb:

> Wir hatten doch noch nie ein Problem miteinander Holger. Ich mag den
> 6502 nicht so besonders, das liegt aber weniger daran das der nichts
> taugen würde, sondern das ich mich mit ihm erst viel später mal befaßt
> habe als mit dem Z80. Ich verurteile ihn aber nicht. wenn man mit dem
> Ding was basteln möchte, warum nicht? Für mich ist heutiges Z80 basteln
> auch eher Erholung als Arbeit, das mach ich aus Lust und Laune wenn ich
> Zeit habe. Es ist doch völlig Banane mit welchem veralteten Prozessor
> man so rumwerkelt..nett finde ich z.B. den 6809 (netter den 6309).

Ich hingegen flippe auf digitale Signalprozessoren ab. Hier reagiere ich
ein bißchen angefressen, was diese Diskussionen betrifft; insbesondere
wenn irgendwelche Nutzung technischer Bauteile mit persönlichen
Werturteilen einhergeht, die in aller Regel beleidigend sind. Was den
Z80 betrifft, von dem Ding habe ich auch noch einige liegen, die ich für
Hobbyzwecke in Erwägung ziehe.

> ...ja der Eprog..diese Krücke :-)

Man kann sowas besser machen, ich weiß.

> Klar, wenn man den lansgam genug über die serielle Schnittstelle füttert
> dann tut er, beim kopieren klappts ja auch.
> Mit unverzögerter (zwischen den Zeichen) RS232 wird das aber Brühe..

Das war ein Problem mit dem Ding, ja. Ich habe einfach Zeitverzögerungen
programmiert, und seitdem kann ich mit meinem auch via Sorceforge
veröffentlichten Kommandozeilendings das Teil benutzen.

Grüße, Holger

[Holm Tiffe]

...völlig andere Baustelle.

Holger hat von mir einen "EPROG 27011" bekommen der mal über Unrad
vertrieben worden ist. Das Teil stammt von Auerswald, kann Eproms
dublizieren und ist auch über eine seirielle Schnittstelle ansteuerbar.
Das Problem ist, das das Teil einen 8748 Prozessot verwendet der die
RS232 auch noch in Software implementieren muß, das ist zu langsam um
hinter einander weg eintreffende Zeichen zu behandeln so da das Ding
überfahren wird wenn ein Rechner schneller als ein 386/33 ist und was
anderes als Basic zur Ansteuerung verwendet wird :-|

Gruß,

Holm

[Holm Tiffe]

On 10.05.2016 02:06, Holger wrote:
> Holm Tiffe schrieb:
>
>> Wir hatten doch noch nie ein Problem miteinander Holger. Ich mag den
>> 6502 nicht so besonders, das liegt aber weniger daran das der nichts
>> taugen würde, sondern das ich mich mit ihm erst viel später mal befaßt
>> habe als mit dem Z80. Ich verurteile ihn aber nicht. wenn man mit dem
>> Ding was basteln möchte, warum nicht? Für mich ist heutiges Z80
>> basteln auch eher Erholung als Arbeit, das mach ich aus Lust und Laune
>> wenn ich Zeit habe. Es ist doch völlig Banane mit welchem veralteten
>> Prozessor man so rumwerkelt..nett finde ich z.B. den 6809 (netter den
>> 6309).
>
> Ich hingegen flippe auf digitale Signalprozessoren ab. Hier reagiere ich
> ein bißchen angefressen, was diese Diskussionen betrifft; insbesondere
> wenn irgendwelche Nutzung technischer Bauteile mit persönlichen
> Werturteilen einhergeht, die in aller Regel beleidigend sind. Was den
> Z80 betrifft, von dem Ding habe ich auch noch einige liegen, die ich für
> Hobbyzwecke in Erwägung ziehe.

Naja, Hardware ist sehr schwer zu beleidigen Holger, Du nimmst das zu
persönlich. :-)

>
>> ...ja der Eprog..diese Krücke :-)
>
> Man kann sowas besser machen, ich weiß.
>
>> Klar, wenn man den lansgam genug über die serielle Schnittstelle
>> füttert dann tut er, beim kopieren klappts ja auch.
>> Mit unverzögerter (zwischen den Zeichen) RS232 wird das aber Brühe..
>
> Das war ein Problem mit dem Ding, ja. Ich habe einfach Zeitverzögerungen
> programmiert, und seitdem kann ich mit meinem auch via Sorceforge
> veröffentlichten Kommandozeilendings das Teil benutzen.
>
> Grüße, Holger
>
>
> --- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

Ich arbeite täglich unter Unix und hatte auch ein spezielles Programm um
das Ding zu füttern. Unzuverlässig war es trotzdem.

Ich habe einige selbst gebaute Promer (u.A. für 27C291 und 2708), einen
ALL07, einen GALEPIII und auch noch einen UP95/2000 von ELV.
Davon steht das manches die ganze Zeit rum (UP2000), anderes benutze ich
aber ständig.
Der "Verlust" des EPROG macht mich nicht ärmer..

Gruß,

Holm

[Holm Tiffe]

On 09.05.2016 22:58, Hans-Peter Diettrich wrote:
> Holm Tiffe schrieb:
>> On 06.05.2016 12:10, Martin Gerdes wrote:
>
>>>> Es gibt keine Wait states oder Handshake in dieser Hardware. Ein 6802
>>>> könnte das prinzipiell, um mit noch langsamerem Speicher zu
>>>> funktionieren, weswegen es die MR-Leitung gibt. D.h. hier laufen alle
>>>> Speicherzugriffe nach demselben Schema, egal ob I/O-Chip, EPROM oder
>>>> RAM.
>>>
>>> "Memory mapped" nannte man das Konzept damals. Es blieb für Z80-Jünger
>>> auf ewig unverstanden :-)
>>>
>> Ich bin durchaus als gelernter Ossi auch "Z80 Jünger", kann Deine
>> Aussage nicht nachvollziehen und wüßte nicht was mich daran hindern
>> sollte einen Z80 Rechner mit Memory mapped IO aufzubauen, höchstens
>> die Tatsache das ein großer Teil der attraktiven Features der Z80
>> Peripherie-ICs nicht mehr nutzbar ist und der lineare Adreßraum für den
>> Speicher durch das IO löchrig wird. Nur Nachteile auf dieser
>> Architektur also.
>>
>> Das ist wohl das was die 6x0x Jünger Niemals verstanden haben.
>
> Da bahnt sich schon wieder ein Krieg der Welten an :-(

Wenn Du Krieg spielen willst: bitte.
Ich hatte nur argumentiert.

>
> Die Idee hinter der Trennung von Speicher und I/O war die einfache
> Dekodierung von Adressen, und die volle Ausnutzung des kostbaren RAM.
> Das geht aber nur auf Kosten des Befehlssatzes (zusätzliche I/O Befehle)
> und zusätzlicher Prozessor-Pins, die heute besser für Adressleitungen
> genutzt werden könnten. Die wirklich attraktive Z80 Periperie war
> absichtlich an dieses Konzept gebunden, um diesen speziellen Prozessor
> zu pushen.

Gähn.

>
> DMA hat mit beiden Konzepten nichts zu tun, solange nur ein einziger
> Adressbus verfügbar ist. Entweder muß der DMA Controller byteweise lesen
> und dann schreiben, oder spezielle Signale an den angesprochenen
> Baustein schicken, wenn die Daten in einem Rutsch übertragen werden
> sollen. Da bleibt als einziges Argument gegen MM I/O übrig, daß die
> Adressen für die Peripherie mehr Adressbits im DMA Controller erfordern.
> Wenn aber gleichzeitig Speicher-zu-Speicher Transfer gewünscht wird,
> oder mehr I/O Kanäle als der Controller handhaben kann, fällt dieses
> Argument wieder weg.

Quatsch. RTFM Z80 DMA.

>
> Eine "beste" Lösung wurde bis heute nicht gefunden, speziell bei der
> Behandlung des Bildwiederholspeichers für Displays. Derzeit wird die
> Peripherie über eigene (serielle) Bus-Systeme angesprochen (SATA, USB,
> I2C, CAN...), was HP mit HP-IL auch schon vor sehr langer Zeit erfunden
> hatte. Preisfrage: welche Mikroprozessoren hatten schon solche serielle
> Hardwareunterstützung an Bord?
>
> DoDi
>

Mikroprozessoren haben üblicherweise _keine_ Peripherie on Board,
deswegen sind es Prozessoren und keine Controller.

Und? Was soll das Ganze? Wen willst Du beeindrucken? Microsoft oder DR?

Gruß,

Holm

[Holm Tiffe]

Ich wollte erklärt haben warum für 16bit Ausgaben memory mapped besser
sein soll, der Bus ist auch nur 8 Bit breit. Ich wollte nicht erklärt
haben ob inc oder dec auf IO-Ports funktioniert.

Gruß,

Holm

[horst-d.winzler]

Am 10.05.2016 um 07:57 schrieb Holm Tiffe:

> Naja, Hardware ist sehr schwer zu beleidigen...

Manchesmal könnte man was anderes glauben.

--
---hdw---

[Gerrit Heitsch]

On 05/10/2016 02:06 AM, Holger wrote:
>
> Das war ein Problem mit dem Ding, ja. Ich habe einfach Zeitverzögerungen
> programmiert, und seitdem kann ich mit meinem auch via Sorceforge
> veröffentlichten Kommandozeilendings das Teil benutzen.

Es gibt noch von jemand anderem Software für das Teil:

http://www.tklinux.de/eprog.html

Ich hab damit nie ein EPROM programmieren können (wahrscheinlich
Bedienungsfehler), aber beim Auslesen ist sie hübsch schnell. Also
benutze ich beide.

Gerrit

[Gerrit Heitsch]

On 05/10/2016 07:57 AM, Holm Tiffe wrote:
>
> Ich arbeite täglich unter Unix und hatte auch ein spezielles Programm um
> das Ding zu füttern. Unzuverlässig war es trotzdem.
>
> Ich habe einige selbst gebaute Promer (u.A. für 27C291 und 2708), einen
> ALL07, einen GALEPIII und auch noch einen UP95/2000 von ELV.
> Davon steht das manches die ganze Zeit rum (UP2000), anderes benutze ich
> aber ständig.
> Der "Verlust" des EPROG macht mich nicht ärmer..

Welcher taugliche Programmer funktioniert denn unter Linux brauchbar?

Gerrit

[Hans-Peter Diettrich]

Holm Tiffe schrieb:

> ....völlig andere Baustelle.

Klar.

> Holger hat von mir einen "EPROG 27011" bekommen der mal über Unrad
> vertrieben worden ist. Das Teil stammt von Auerswald, kann Eproms
> dublizieren und ist auch über eine seirielle Schnittstelle ansteuerbar.

Das dachte ich mir schon.

> Das Problem ist, das das Teil einen 8748 Prozessot verwendet der die
> RS232 auch noch in Software implementieren muß, das ist zu langsam um
> hinter einander weg eintreffende Zeichen zu behandeln so da das Ding
> überfahren wird wenn ein Rechner schneller als ein 386/33 ist und was
> anderes als Basic zur Ansteuerung verwendet wird :-|

Dagegen gibt's doch Hardware-Handshake, wenn's schon RS-232 sein soll.

DoDi

[Hans-Peter Diettrich]

Ralf Kiefer schrieb:

Für unvollständige Antworten gibt's nichts :-(

Gibt's denn überhaupt *gebrauchte* Transputer-Boards? ;-)

DoDi

[Holm Tiffe]

..weiß nicht, hab kein Linux und ich habe mir abgewöhnt nach
Linux/Unixunterstützung zu fragen, ich verwende FreeBSD.
Ich habe alte Laptops mit irgendwelchen alten Windowsversonen, teilweise
virtualisiert die da Epromer zu Netzwerk Adapter spielen.
Den ALL07 betreibe ich mit einem Win98 in einem Microsoft Virtual PC
unter XP, unter XP native ist die DOS Software nicht zu vernünftiger
Arbeit zu überreden.

Auf einem modernem Windows kann man sich das gleich ganz abschminken,
moderne Hardware hat auch keinen Parallelport mehr, also hechele ich
nicht irgendwelchen Treibern hinterher sondern nehme das was nötig ist
und funktioniert. Mikeysoft begreift ja auch nicht das der Wert eines
solchen alten Gerätes wie ein Epromer nicht mit der Windowsunterstützung
steht oder fällt. Modernes Windows wird einfach nur untauglicher..

Gruß,

Holm

[Hanno Foest]

Am 10.05.2016 08:36 schrieb Gerrit Heitsch:

> Welcher taugliche Programmer funktioniert denn unter Linux brauchbar?

Gute Frage. Bei mir nur mittelbar: Der GALEPIII unter WINE und der c't
EPROP unter DOSEMU. Bei letzterem ist mir nicht ganz wohl, weil ich
nicht weiß, wie gut die DOSEMU das Timing abbildet.

Hanno

[Holm Tiffe]

Du Plinse!!!

(Entschuldigung, ist mir nur so rausgerutscht...)

Ich habe erstens kein Linux und zweitens ..

Du kannst das C-File auf der Seite runterladen, evtl. tust Du das mal
und liest die obersten 4 Zeilen wer das Ding gemacht hat...


Gruß,

Holm

[Holm Tiffe]

Die Antwort wäre sowieso falsch, da Transputer mehr als einen Prozessor
enthalten und dadurch streng genommen aus der Definition "Mikroprozesor"
schon raus fallen..


Gruß,

Holm

[Holm Tiffe]

Du bist ja ein gaanz Schlauer, Kompliment!

Die konkrete Hardware hat allerdings das Problem das sie nicht mal das
Handshake sauber handeln kann und trotzdem überfahren wird. Wenn es
anders gewesen wäre hätte ich das Ding vielleicht noch im Zoo.

Gruß,

Holm

[Gerhard Hoffmann]

Am 10.05.2016 um 08:36 schrieb Gerrit Heitsch:

> Welcher taugliche Programmer funktioniert denn unter Linux brauchbar?

Ich habe einen All-11. Der scheint unter Linux Mint mit VMware und
XP zu funktionieren. Für das V.24 Interface habe ich ein USB-Kabel
von Hama. Getestet mit Dell Precision "portable workstation".
portable , ha!

Gruß, Gerhard

[Holm Tiffe]

Der hat offensichtlich eine RS232 was das Problem stark vereinfacht
(wenn diese ordentlich funktioniert was nicht immer gegeben ist).

Damit ist er unabhängig von Port Timings auf der Parallelschnittstelle
die bei anderen Brennern mehr oder weniger direkt zum Schalten der
Programmierspannungen/Pintreiber/whatever verwendet wird und keine
eigene Intelligenz im Promer erfordern.

Der GALEPIII ist z.B. so ein Ding, da lauert direkt am Parallelport ein
FPGA das direkt "on the fly" von der Software passend programmiert wird,
Timings kommen dann wohl auch aus dem PC...

Gruß,

Holm

[Gerhard Hoffmann]

Am 10.05.2016 um 10:03 schrieb Hans-Peter Diettrich:

>> Bekomme ich für die richtige Antwort ein nagelneues Transputer Board?
>
> Für unvollständige Antworten gibt's nichts
>

> Gibt's denn überhaupt *gebrauchte* Transputer-Boards?

Ich hab' mal ein paar verliehen um testhalber einen fetten Cluster
aufzubauen, so als Gruppenleistung. Keine Ahnung, ob der Typ noch lebt,
der das damals organisiert hat.

Während der Wendezeit bin ich mal gefragt worden, ob ich ein
richtig grosses System nach Ostberlin verschieben würde oder
wenigstens hosten...
Ich hab' mich nicht getraut Wäre DAS Geschäft gewesen
und hätte ein Jahr später kein Schwein mehr interessiert.

Gruß, Gerhard

[Gerrit Heitsch]

On 05/10/2016 10:16 AM, Holm Tiffe wrote:
>
> Ich habe erstens kein Linux und zweitens ..
>
> Du kannst das C-File auf der Seite runterladen, evtl. tust Du das mal
> und liest die obersten 4 Zeilen wer das Ding gemacht hat...

Ich hab das vor Jaaaahren mal runtergeladen, kompiliert und benutze es
seitdem unter Linux.

Danke das du dir damals die Arbeit gemacht hast.

Gerrit

[Holm Tiffe]

..hatte ich ja in erster Linie für mich selber gemacht, nichts zu danken
also..

deine Probleme mit der Programmiererei werden genau mit dem von mir
angesprochenen Problem bei der Datenübertragung vom Host zum Promer
zusammen hängen. So lange Du nur lesen willst hält sich der Prozessor
noch über Wasser weil nur kurze Steuerbefehle kommen, wenn Du aber Daten
sendest geht er sang und klanglos unter obwohl ich damals da schon
Verzögerungen versucht habe einzubauen die wohl nun aber nicht mehr
reichen werden. Zuverlässig war damals schon was Anderes..

Holger wird das Ding noch weiter ausgebremst haben was erklärt warum das
noch langsamer ist. Die Hardware ist so einfach Stuß.

Der Promer ist aber auch schon uralt, al der von Conrad vertrieben wurde
(ich hatte einen Bausatz, Platine und Gehäuse) haben wir festgestellt
das das Ding mit em mitgelieferten Basic Programm unter DOS und GWbasic
ab 386/40 nicht mehr funktionierte..die Rechner wurden einfach zu
schnell und warfen nicht mehr jedes Zeichen einzeln aus.
der 8048 auf dem Promer schafft es halt nicht CTS inaktiv zu schalten
ohne sich zu verschlucken, der hat ja keine Hardware-Uart..


Gruß,

Holm

[horst-d.winzler]

Wurde doch damals alles über Wien abgewickelt. Hat sich damals überhaupt
jemand, außer einigen Bürokraten vielleicht, darum gekümmert?
Und die vom Westen gelieferten Halbleiter bekamen eine Zahl mehr
aufgedruckt, wurde mir erzählt.
--
---hdw---

[Gerrit Heitsch]

On 05/10/2016 12:14 PM, Holm Tiffe wrote:
>
> Der Promer ist aber auch schon uralt, al der von Conrad vertrieben wurde
> (ich hatte einen Bausatz, Platine und Gehäuse) haben wir festgestellt
> das das Ding mit em mitgelieferten Basic Programm unter DOS und GWbasic
> ab 386/40 nicht mehr funktionierte..die Rechner wurden einfach zu
> schnell und warfen nicht mehr jedes Zeichen einzeln aus.
> der 8048 auf dem Promer schafft es halt nicht CTS inaktiv zu schalten
> ohne sich zu verschlucken, der hat ja keine Hardware-Uart..

Es gibt wenige echte Hardware-UARTs die RTS/CTS in Hardware erledigen.
Und manche die es tun haben kleine Fehler. Wie z.B. der 6551, wenn du
dem CTS wegnimmst hört er auf zu senden. Leider sofort, also u.U. mitten
im Byte. Steht auch im Datenblatt, aber nur implizit, kann man leicht
überlesen. Der 65C51 macht es richtig.

Gerrit

[Holm Tiffe]

Ja, ich weiß.

Die Z80 SIO ist da auch ein Bisschen doof, auch wenn sie so an sich
keine Fehler hat.
Die kann z.B. in Hardware sofort auf ein fehlendes CTS des Gegenübers
reagieren (und macht dann auch richtig das Zeichen zu ende), hat aber
keinen in Hardware implementierten "Selbstschutz", d.h. man muß mit der
Software (in einer ISR) Bescheid geben das der Puffer voll ist und CTS
wegnehmen.

RTS wertet die SIO auch völlig anders aus als man erwartet, z.B. wird
das Bit extern nur inaktiv wenn der Senderpuffer leer, also die SIO idle
ist, selbst wenn man es softwaremäßig abschaltet.


Mir ging es aber oben darum, dass der 8048 Prozessor nicht mal das
Schieberegister für Empfang und Senden implementiert hat, man muß das
also mit Bitbanging machen, zusätzlich die Modem Control Signale
bedienen und um den Eprom muß man sich auch noch kümmern, der Controller
hat ja so gut wie keinen RAM (64 Bytes) und einen Puffer für die Daten
gibts auch nicht, die CPU ist (Intel üblich) vergriesgnaddelt und eine
Wurschtpelle bekommt man damit auch nicht vom Teller gezogen...

Gruß,

Holm

[Holm Tiffe]

On 10.05.2016 12:23, horst-d.winzler wrote:

> Und die vom Westen gelieferten Halbleiter bekamen eine Zahl mehr
> aufgedruckt, wurde mir erzählt.

..das ist Quatsch.

Je älter die DDR wurde desto mehr ähnelten die eigenen Bezeichnugnen den
international üblichen und Importbauelemente waren halt Solche, da wurde
nix umgekennzeichnet, weder bei russischen noch bei Intel oder
Mitsubishi, Nec, SGS etc..

Gruß,

Holm

[Ralf Kiefer]

Holm Tiffe wrote:

> Je älter die DDR wurde desto mehr ähnelten die eigenen Bezeichnugnen den
> international üblichen und Importbauelemente waren halt Solche, da wurde
> nix umgekennzeichnet, weder bei russischen noch bei Intel oder
> Mitsubishi, Nec, SGS etc..

Bei Pollin gab's dieser Tage wieder sowjetische EPROMs: KC573RF2. Das
sollen 2716-Ähnliche sein. Daten zum Programmieren fand ich irgendwo im
Web: Programmierspannung 24V +/-0,5V. Im Rest der Welt waren 25V üblich.
BTW meine haben einen Datecode "8905". "Zufällig" hatte ich mir gerade
vorgenommen die alten mc-EPROMmer wieder herzurichten, denn da kann ich
die Programmierspannung per Poti justieren.

Gruß, Ralf

[Holm Tiffe]

Die Dinger gehen problemlos als "Intel 2716" durch und machen eigentlich
keine Probleme. Das mit den 24,5V kannst Du getrost in der Pfeife rauchen.

Welche Art Gehäuse ist das? Es gibt braun, rotbraun und weiß mit
Metallaufsatz am Fenster...gehen aber eigentlich alle gleich.

Gruß,

Holm

[Gerrit Heitsch]

On 05/10/2016 01:02 PM, Holm Tiffe wrote:
>
> Mir ging es aber oben darum, dass der 8048 Prozessor nicht mal das
> Schieberegister für Empfang und Senden implementiert hat, man muß das
> also mit Bitbanging machen, zusätzlich die Modem Control Signale
> bedienen und um den Eprom muß man sich auch noch kümmern, der Controller
> hat ja so gut wie keinen RAM (64 Bytes) und einen Puffer für die Daten
> gibts auch nicht, die CPU ist (Intel üblich) vergriesgnaddelt und eine
> Wurschtpelle bekommt man damit auch nicht vom Teller gezogen...

Man darf nicht vergessen wie alt das Teil ist. Später hat INTeL auch
halbwegs brauchbare Controller gebaut. Den 8051 benutzt man schliesslich
immer noch, auch wenn er heute in irgendeinem Eck des ASICs zu finden
ist und nicht mehr diskret verbaut wird. Ist auch deutlich schneller
geworden.

Das Design des 27011 ist alt und nicht besonders gut. Man kann ihn aber
benutzbar machen, Programmierung dauert dann aber eben 'etwas' länger.
Dafür kann er die 2532 programmieren, viele aktuell erhältliche Prommer
können die nicht mehr.

Gerrit

[Hans-Peter Diettrich]

Holm Tiffe schrieb:

AFAIK enthält ein Transputer (Baustein) nur einen Prozessor, die
Parallelverarbeitung erfolgt im Team mit weiteren Transputern. Insofern
lasse ich die Antwort gelten. Mir ging es aber mehr um 08/15
Prozessoren, wie den 8085.

DoDi

[Gerhard Hoffmann]

Am 10.05.2016 um 13:57 schrieb Holm Tiffe:

> Die Dinger gehen problemlos als "Intel 2716" durch und machen eigentlich
> keine Probleme. Das mit den 24,5V kannst Du getrost in der Pfeife rauchen.

Ich hatte damals auf meinem Programmer einen großen Aufkleber

"NICHT für TI", und das hatte seinen Grund.

Gerhard

[Hauke Fath]

Martin Gerdes <martin...@gmx.de> wrote:

> "Memory mapped" nannte man das Konzept damals. Es blieb für Z80-Jünger
> auf ewig unverstanden :-)

Ein klassischer Troll, der auch nach dreißig Jahren seine Wirkung nicht
verfehlt.

Beim Zerfall von d.t.l habe ich gelernt, daß es die gelangweilten
Stammgäste sind, die am nachhaltigsten das Mobiliar einer Gruppe
zertrümmern.

hauke

--
Now without signature.

[Ralf Kiefer]

Holm Tiffe wrote:

> Die Antwort wäre sowieso falsch, da Transputer mehr als einen Prozessor
> enthalten und dadurch streng genommen aus der Definition "Mikroprozesor"
> schon raus fallen..

Ich habe die Zeit der T414 und T800 insofern miterlebt, als daß die
Kollegen in den Nachbarzimmern Hard- und Software (VMEbus-Boards, Occam,
Farmalgorithmen, u.ä.) dafür entwickelten. Die vier Links auf jedem Chip
habe ich als spezielle, enge Kopplung der Prozessoren verstanden, die
mit einer herkömmlichen seriellen Schnittstelle (im Sinne von V.24) aber
so was von überhaupt nichts zu tun hat.

Die Links waren in Occam abstrakt abgebildet, die tatsächliche
Verknüpfung in der Schicht drunter real. Und sie waren essentieller
Bestandteil des Konzepts, das recht massiv mit (damals) bekannten
Strukturen und Definitionen brach.

Gruß, Ralf

[Ralf Kiefer]

Holm Tiffe wrote:

> Die Dinger gehen problemlos als "Intel 2716" durch und machen eigentlich
> keine Probleme. Das mit den 24,5V kannst Du getrost in der Pfeife rauchen.

Ok, na dann :-)

> Welche Art Gehäuse ist das? Es gibt braun, rotbraun und weiß mit
> Metallaufsatz am Fenster...gehen aber eigentlich alle gleich.

Die sehen aus wie rotbraun, ein Farbton, wie ich ihn bei westlichen
Gehäusen bisher nicht sah.

Gruß, Ralf

[Ralf Kiefer]

Gerhard Hoffmann wrote:

> Ich hatte damals auf meinem Programmer einen großen Aufkleber
>
> "NICHT für TI", und das hatte seinen Grund.

Welchen?

Programmierspannung (beim 2716 keine 25V, sondern weniger)?
Programmieralgorithmus? Belegung der Beinchen?

Gruß, Ralf