Hallo,

flomon cg testet die Existenz der KEY, indem es von Port 0x69 liest. Kommt 0xff zurück, ist keine KEY da. Bei Hans Werner funktioniert das so, bei mir kommt immer 0x69 zurück. Offenbar reicht die Kapazität der Busleitungen aus, bei mir die zuletzt gelesene Adresse des Befehls solange zu halten, bis der IN Zyklus läuft.

Ok, da fehlt ein Pullup auf der CPU Karte, was auch RDK im Buch anspricht. Also habe ich einen 22k Pullup eingebaut und nun bekomme ich 0x7f. Ich hab's nachgemessen, der Pullup für das oberste Bit funktioniert. Aber warum verhält sich Bit 7 anders als 0-6?

Ideen?

Michael

Michael

Moin Michael,

das Verhalten ist schon etwas seltsam. Wie sieht es denn aus, wenn du andere (nicht belegte) Ports abfragst?

-----------------------
Gruß
-=jens=-

Sehr gute Frage! Ich habe 0xff und 0x69 im Wechsel probiert. Bei 0xff bekomme ich immer 0xff zurueck. Bei 0x69 bekomme ich im Dauertest meist 0x7f, manchmal aber auch 0xff zurueck.

Vielleicht ist 22k als Pullup zu schwach. Ich haette nicht gedacht, dass das nicht reicht, um die Busleitungen zu entladen (2x BUS, Z80 CPU, ROA64, BANKBOOT, SET, IOE).

Ich werde also bei der naechsten Bestellung ein 10k Widerstandsnetz ordern.

Michael

Moin Michael,

ich hab es gerade mal auf meinen 68k NKCs durchgetestet.
Mein 68020 liefert auch je nach (nicht belegter) Adresse 7f oder ff.
Mein 68008 liefert 00!
Keine Ahnung woher das kommt, aber da die Kisten problemlos laufen, mach ich mir darüber keine großen Gedanken

-----------------------
Gruß
-=jens=-

Interessant! Es liegt also an irgendeiner Karte oder am Bus selbst, aber eher nicht an der CPU. Gibt es beim 68020 und beim 68008 Pullup oder Pulldown Widerstaende am Datenbus?

Es ist halt bloed, wenn man Hardware automatisch erkennen möchte und das ist in flomon wichtig, wenn man nicht für jede Konfiguration eine Version flashen will.

Ich werde bei Gelegenheit mal ein Testprogramm machen, was abwechselnd Adressen mit und ohne gesetztem Bit 7 abfragt, auf /IORQ triggern und mir den Datenbus auf dem Oszilloskop ansehen. Hoffentlich versteht man dann, was passiert.

Michael

Nö, Pullups sind bei mir auch nicht vorhanden (der 68008 irritiert mich allerdings auch ein klein wenig).

Da wir wohl keine Karte als Übletäter lokalisieren können, bleibt nur der Bus! Und siehe da neben D7 liegt -RD. Ich gehe daher von einem Übersprechen aus.

Welche Komponenten willst du denn automatisch erkennen? Normalerweise schreibt man dazu ja ein Register (z.B mit AA oder 55) und liest es dann wieder aus. Für diverse Teile findet man schon im FLOMONCG Routinen, Einige dürfte ich auch noch (für die 68k's) haben.

-----------------------
Gruß
-=jens=-

Klar, /RD ist im Moment des Lesens low. Neben D0 liegt Ground, allerdings statisch. Uebersprechen klingt logisch.

Dass 22k nicht reichen, kommt mir trotzdem seltsam vor.

Hat der 68008 vielleicht interne Pulldowns? Manche CPUs haben sowas.

Ich möchte wenigstens KEY erkennen und die Hardware ist leider sehr spartanisch. Das haette man besser bauen koennen, aber nun ist es halt so.

Flomon CG geht davon aus, dass 0xff gelesen wird, d.h. das wurde nicht getestet oder lief nur beim Autor. Der SER Code in Flomon CG hatte ja auch einen Bug, wurde also definitiv nicht getestet.

Wenn die Leitungen floaten, koennte man irgendwas lesen, d.h. mit Pech auch das geschriebene Muster. Spaetestens beim Einsatz von 74HCT sind Probleme garantiert. Darum halte ich den Einbau von Pullups fuer einen definierten Buszustand sowieso fuer eine noetige Revision.

Leider ist die Dokumentation beim NKC etwas schwach und beschreibt die Revisionen der Karten nicht. Eigentlich muesste es da eine Liste von Aenderungen geben, um Nachbauern zu ermoeglichen, die Revision nachzuvollziehen. Es steht uns aber frei, das ab jetzt so zu machen.

Michael

Gerade die Key zu testen ist natürlich problematisch.
Du hast ja nur das Strob-Bit (auf D7) das nach einem Schreibzugriff auf 69h auf 0 sein sollte.

Wäre es nicht günstiger auf die GDP zu testen? Denn ne Key ohne GDP macht ja nicht wirklich Sinn.

-----------------------
Gruß
-=jens=-

Das waere für die Erkennung der Konsole brauchbar, aber um zu wissen mit welcher Geschwindigkeit die SER betrieben wird, leider nicht. Bisher musste man eine KEY haben, um das festzulegen, weil dort die Konfigurationsschalter sind. Das ist eine unsinnige Huerde für seriell betriebene NKCs (und Stromverschwendung). Ich weiss nicht, wieso RDK die Schalter nicht auf die SER gebaut hat.

Der NKC ist ein herrlich modulares System. Die Software sollte damit klarkommen, welche Module vorhanden sind, und keine Annahmen ueber Kombinationen machen.

Davon abgesehen bin ich mittlerweile neugierig, wieso es nicht so funktioniert wie erwartet. :-)

Danke fuer die Dokumentation der SER r3!

Michael

Ich hab gerade mal 10k Pulups an die Datenleitungen meines 68020 gelegt.
Das Ergebnis --- genau der gleiche Müll wie vorher

Dann schmeiß doch die DIP-Key Einstellungen raus. Stell die SER auf 9k6,8,N,1 oder 19k2,8,N,1 wenn man etwas anderes will, muss man es eben per Software machen.

-----------------------
Gruß
-=jens=-

Es ist Sonntag und draussen schneit es: Zeit, der Sache auf den Grund zu gehen, so wie RDK es einst tat. Folgendes Testprogramm im Flomon hilft mir:

st5:

in a,(069h)
in a,(0ffh)
jp st5

Ich habe keine KEY im System und laut Tabelle sollte 0xff von keiner Karte benutzt werden. Ich habe einen 22k Pullup auf dem Bus (Busseitig auf der CPU Karte). Mangels Trenntrafo liess ich die Masse der Tastkoepfe offen. Ich habe drei Messungen gemacht, wobei /IORQ triggerte und jeweils ein anderer Kanal benutzt wurde, um D6, D7 und /RD aufzuzeichnen. Dann habe ich D7 und /RD aus den Messungen ins erste Bild kopiert, damit man alle im Vergleich sieht:



Uebersprechen stelle ich mir anders vor. Man sieht, wie D7 waehrend des /RD darunter minimal ansteigt, aber wirklich nur minimal. Es ist einsichtig, dass 10k statt 22k sicher nicht helfen. Ich frage mich auch, was die Spikes bei D7 sind.

Was passiert da?

Michael

Moin Michael,

das auf D7 ist ja ein richtig schönes Signal

Um die Quelle des Signals einzukeisen, könntest du ja nur dein Testprogramm in ein EPROM brennen. Dann nur die CPU und die ROA (evtl. erstmal nur mit dem EPROM) zusammenstecken und durchmessen. Falls dann noch alles OK ist nach und nach die anderen Karten einstecken.

Die Spikes könnten vom Umschalten der '245er kommen, ganz böse ists, wenn man '645 drinn hat.

-----------------------
Gruß
-=jens=-

Ja, sieht toll aus, was? "Wenn ich gross bin, werde ich ein high." :-)

Ich habe etwas gerechnet: Bei 50 pF Buskapazitaet und 22k Pullup hat man 0,14 MHz Grenzfrequenz. Mit 1k sind es 3 MHz.

Auf den Karten sind die Datenleitungen nicht immer direkt an einen busnahen Treiber gefuehrt, sondern gehen haeufig zu einem Treiber und einem anderen Baustein. Die Loetpunkte des Bussteckers auf den Karten sind ganz schoen gross. Die Abschirmung zwischen den Leitungen auf der Oberseite der Busplatine ist sicher gut gemeint, wird aber extra Kapazitaeten bringen. Wenn man dann noch zwei Backplanes hat, wird es noch mehr.

Ich habe das Bild um D4 ergaenzt. Das ist bei 0x69 auch low, wie D7. Seltsamerweise wird es als high gelesen. Das muss recht knapp sein, d.h. es sieht nur zuverlaessig aus, ist es aber nicht.

Die Umschaltvorgaenge der 245er sind ein guter Punkt. Da sind teilweise ganz schoen viele Gatter im DIR Weg. Wenn dann noch fehlende Abblockkondensatoren alles langsamer machen, koennte das in der Tat ein Grund sein.

Ich habe langsam eine Ahnung, wieso 8 MHz Takt bei NKC Aerger machen koennen. Wie schlecht mag /RD da wohl aussehen?

Michael

Hallo,
die Signale sehen eher so aus als wenn Reflexionen drauf wären, vor allem auf /RD. Da wird nur eine Busterminierung helfen, am Besten eine aktive Terminierung. War bei ECB Systemen üblich.
Gruß
Hans-Werner

-----------------------
Ob 8bit oder 16 oder 32 ist doch egal, Haupsache selbstgebaut!

Da stimme ich zu, fuer 8 MHz sollte der Bus terminiert werden.

Die Sache mit den Spikes liess mir keine Ruhe und so ruestete ich den 245 fuer die Steuersignale und den 00 auf der CPU mit Sockeln mit eingebauten Abblockkondensatoren aus. Im Bild seht ihr /IORQ und D4 vor und nach dem Umbau. Ich kann's nicht erklaeren, aber offenbar schaltet da nun etwas um, was vorher nicht dazu kam. Ausserdem ist die ansteigende Flanke vom ersten /IORQ nun etwas hoeher:





Michael

http://schuetz.thtec.org/down/image.png

Aktive Busterminierung Schaltbild
Gruß
Hans-Werner

-----------------------
Ob 8bit oder 16 oder 32 ist doch egal, Haupsache selbstgebaut!

Ich meine, so eine Schaltung wurde mal in der mc publiziert. Sind der Op und der Transistor schnell genug, um die Terminierungsspannung zu regeln? Hast Du vorher-nachher Bilder der Signale? Terminiert man ein oder beide Enden des Busses?

Die Tatsache, dass der Abblockkondensator beim 00 ein Signal derartig beschleunigt, sagt mir, dass die CPU Karte eher nur durch Glueck laeuft. Vielleicht liegt es auch daran, dass der Taktgenerator in der Naehe liegt und ebenfalls keinen Abblockkondensator hat.

Zum eigentlichen Thema: Die Sache mit dem Pullup hat sich wohl erledigt, den Bus kriegt man offenbar nur mit 1k high und das verschwendet mir erheblich zu viel Strom. Da muss also eine andere Loesung her.

Michael

Hallo Michael,
jup ist die Schaltung aus der MC...
Habe ich noch nicht life gesehen... bei der MyCPU (Netzteil) ist auch eine aktive Terminierung (Netzteil) des Datenbusses... allerdings etwas merkwürdig mit einem 74AC541 und 1k Widerständen. Aber ist das denn unbedingt nötig... es sind doch massenhaft NKC Systeme gelaufen. OK über 100nF Abblockkondensatoren kann man reden. Wenn man das ganze System neu designen will... ist das dann noch ein NKC?
Gruß Hans-Werner
Hans-Werner

-----------------------
Ob 8bit oder 16 oder 32 ist doch egal, Haupsache selbstgebaut!

Moin,

die tollen Signale von Michael haben mir irgendwie keine Ruhe gelassen

Hier mal meine Messung nur mit Z80-CPU und ROA64 mit einem EPROM mit Michaels Programm:



oben ist D7 unten /IORQ

Wie man sieht ist D7 bei jedem 2. /IORQ auf low.
Ach ja, das ganze ist mit meinen selbstgefädelten Karten auf einen (gefädelten) ECB-Bus. Von daher dürfte der NKC-Bus für dieses Problem ausscheiden.

-----------------------
Gruß
-=jens=-

Naja, solange keine Daten verfaelscht werden, spricht man halt von "laufen", egal wie knapp die Stoersicherheit und Bauteiltoleranz ist. ;-)

Wenn es um Reflektionen geht, spielen 4 oder 8 MHz keine Rolle. Die Signale dauern halb so lang, aber dadurch werden die Flanken nicht steiler. Ich finde die Signale noch nicht kritisch und man muss auch sehen, dass eine Messung mit offener Masse nur bedingt aussagekraeftig ist. Das wuerde ich mir also bei 8 MHz nochmal genau anschauen. Kann sein, dass es ok ist, kann aber auch nicht sein. Man koennte eine Terminierung auf das Ende der Busplatine stecken.

Der Takt wird uebrigens nicht durch einen Bustreiber auf den Bus gegeben, sondern nur durch ein Gatter. In der c't war mal eine genaue Beschreibung der Probleme, einen korrekten Takt fuer den Z80 zu erzeugen und die Antwort war letztlich ein Transistor. Der Umbau waere fuer 8 MHz sicher besser.

RDK hat in spaeteren Designs ueberall ausreichend Abblockkondensatoren benutzt (mc CP/M, SBC3 usw.). Faktisch braucht man nicht an jedem Chip welche, nur kosten sie halt wenig und ersparen viel Fehlersuche.

Meiner Meinung nach sollten die 245er alle einen in der Naehe haben, weil die beim Umschalten schon mal viel Strom brauchen, wie man an der hoeheren Flanke von /IORQ sieht. Bausteine in timingkritischen Signalpfaden brauchen ebenfalls einen, wie man sieht.

Das sind minimale Modifikationen. Fuer den Moment halte ich mal fuer die Z80 Vollausbau CPU fest: Abblockkondensatoren fuer die CPU, IC 2, IC 6 und IC 4. Ich bin sehr sicher, dass es bei IC 1 und 3 auch sinnvoll waere. Das mit dem Pullup ist dagegen Unsinn, das wird am NKC Bus vermutlich nur mit 1k was. Wenn ich mir /WAIT und Freunde anschaue, dann weiss ich nun, wieso man da auch 1k benutzt hat.

Michael