Hallo Michael,

ja, eine sollte bestimmt noch da sein. Möchtest Du auch noch einen SER Prototypen testen?

Gruß, Rene

Klar, mache ich gerne.

Michael

Hallo NKC-Fans,

falls jemand die kommende SRAM1024 von Creep mit Batteriepufferung nachbauen möchte und dafür noch 7432 sucht:

http://www.ebay.de/itm/10x-DM7432N-quad-2-input-OR-Gate-National-Semiconductor/282198015862?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649

Viele Grüße
netmercer

Kann mir jemand sagen, welche Anzahl von Waitstates man beim 68008 für welche Zyklenlänge braucht? Im Buch steht 1 für langsam EPROMs (was ist langsam?) und 2 Waitstates bei der FLO2, aber es werden keine Zeiten angegeben.

Ich werde nicht aus den Timingdiagrammen im Buch schlau. Wenn ich das Diagramm für zwei Zyklen auf Seite 351 anschaue, dann steht da: Scrn Intv 2.5 us. Ein /MREQ ist ca. 20%, also 500 ns. Das wäre ja schon sehr lang. Da das Schieberegister mit 8 MHz angetrieben wird, würden je Zyklus 125 ns dazukommen, richtig?

Michael

Nachtrag zur SER: Der Reset funktioniert nicht, aber das ist schon bei RDK nicht in Ordnung. Der Reset wird beim 6551 ähnlich wie die Datenübernahme durch Phi2 gesteuert und ist kein eigenständig wirksames Signal. Die Generierung von Phi2 erzeugt aber während eines Resets vom Z80 kein Signal. Die Verwendung von /RFSH war lieb gemeint, aber der Z80 erzeugt kein /RFSH beim Reset. Das Datenblatt sagt klar, dass Phi2 kein kontinuierlicher Takt ist, sondern die Datenübernahme steuert. Ansonsten würde die SER am 68k ja auch nicht laufen.

Ich frage mich, ob die Taktprobleme mancher 6551 in Wahrheit gar nicht vom Quarz kommen, sondern durch den fehlenden Reset verursacht werden.

Möglicherweise würde es helfen, statt /RFSH lieber /RESET zu verwenden, um während eines Resets Phi2 zu erzeugen. Das Ende des Resets könnte ein Problem geben, weil die Erzeugung von /RESET nicht zum Takt synchronisiert ist.

Wenn ich mir aber ansehe, dass Phi2 eigentlich auch vor dem Ende von /IORQ wieder enden soll, was es nicht tut, dann haben wir da vielleicht Glück.

Die Sache schreit nach ein paar Stunden am Logic Analyzer, aber da habe ich im Moment keine Zeit für. Wenn es hilft, könnte das eine wertvolle Revision für die neue SER sein.

Michael

Ich hatte gestern abend doch noch Zeit, aber ich habe den SER Prototypen nicht ans Laufen bekommen. Mit HCTs lief es minimal besser als mit LS, aber insgesamt sendet die Karte Müll, wenn man mehrere Zeichen hintereinander schickt. Also habe ich mich mit dem Timing befasst und verstanden, wie die originale SER eigentlich arbeitet. Ich sehe nur nicht den Unterschied, warum die geht und der Prototyp nicht. Der UART ist in der laufenden SER getestet. Hier meine Notizen, falls jemand eine Idee hat:

Unterschiede zwischen Z80 und 6502 Bus

Sowohl Z80 als auch 6502 legen bei einem Schreibzugriff erst Daten und Adresse auf den Bus.

Der Z80 führt den Transfer danach mit gleichzeitigem /IORQ und /WR durch.

Der 6502 legt zusätzlich zu Daten und Adresse noch R/W für die Richtung auf den Bus und führt den Transfer mit Phi2 durch. Phi2 ist zwar ein Takt, weil der 6502 ein festes Bustiming hat, und z.B. ein 6522 kann Phi2 auch als Takt benutzen, aber für die meisten Bausteine ist es nur ein Steuersignal.

Anforderungen an Phi2 beim 6551

Der Transfer beginnt mit der steigenden Flanke frühestens t_WCW = 70 ns (2 MHz Version des 6551) nach Gültigkeit von R/W. Zu diesem Zeitpunkt müssen noch keine Daten auf dem Bus liegen. Weiterhin müssen die Adressen bereits t_ACW = 70 ns gültig sein. Phi2 darf also erst 70 ns nach /WR erzeugt werden. Zu dem Zeitpunkt sind die Adressen schon länger stabil.

Die Daten werden mit der fallenden Flanke übernommen und müssen zu dem Zeitpunkt bereits t_DCW = 60 ns stabil sein und noch t_HW = 20 ns stabil bleiben. Weiterhin muss R/W noch t_CWH = 0 ns stabil bleiben. Phi2 muss also vor /WR enden und die Daten müssen danach noch stabil gehalten werden.

Phi2 muss wenigstens 200 ns aktiv sein.

Generierung von Phi2 bei der SER

RDK benutzt ein Flipflop, was mit der steigenden Flanke des Systemtakts getaktet wird und ein aktives /IORQ übernimmt. Wenn /IORQ inaktiv wird, wird das Flipflop sofort gelöscht. Das führt zu einem Signal, welches wie gefordert später als /WR beginnt. Leider endet es durch das Propagation Delay des Flipflops erst nach /WR (typ. 25 ns, max. 40 ns), statt vorher. Es sieht also so aus, als ob die Transferrichtung kurz vor Ende des Transfers umgeschaltet wird!

Weiterhin erzeugt /RFSH unregelmässige Phi2 Impulse. Der 6551 braucht sie nicht und bei einem 6522 kann man aufgrund der unbestimmten Frequenz nichts damit anfangen. Ein 68k erzeugt kein /RFSH, aber da es nicht gebraucht wird, läuft die SER auch dort.

Der 6551 braucht einen Phi2 Impuls während des Resets, der nicht erzeugt wird. Ein Software Reset ist nicht identisch mit dem nie stattfindenden Hardware Reset.

Michael

Moin Michael,
ich finde deine Analysen immer höchst interresant.
Dennoch scheint zumindes bei der deiner SER das Problem an anderer Stelle zu sein. Denn bei allen anderen, die diese Karte getestet haben (incl. mir) lief sie ohne Probleme am Z80 und am 68k.
Evtuell falsch gesetzte Jumper?

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

Die Jumper stimmen. Ich hatte gestern abend den Logicanalyzer am Board und alles wird korrekt angesprochen. Lasse ich das Testprogramm mit single stepping im Debugger laufen, schickt es auch brav korrekte Bytes, wie ich an Pin 10 vom UART sehe. RS232 Analyse vom Analyzer ist schon was Feines.

Aber sowie das Programm frei läuft, kommt nur noch Bitmüll mit weitgehend gesetzten Bits heraus. Ich habe mir das Bit 4 im Status Register im Analyzer angeschaut: In Abständen von jeweils etwas mehr als 1 ms wird es 1 und dann wird ein neues Byte ins Senderegister geschrieben. Das passt bei 9600 Baud. Unmittelbar danach ist das Bit wieder gut 1 ms low.

Übrigens ist das Senderegister nicht das Schieberegister: Der Baustein kann also immer ein Byte auf Vorrat speichern. Zum Glück ist der Code auch langsam genug, denn im Datenblatt steht, dass das Statusbit eine Verzögerung 1/16 der Baudrate hat, d.h. wenn man sehr schnell ist, könnte man beim Senden einen Überlauf verursachen. Passiert beim Z80 aber im Leben nicht.

Auf dem Datenbus gibt es auch keine Probleme, während /CS sieht der vor und hinter dem 245 gleich aus.

Was für Chips hast Du verwendet, LS oder HCT? Hast Du alle Pulls bestückt? MAX oder USB?

Michael

Moin Michael,
meine 6551 sind von Rockwell, bestückt habe ich komplett mit LS. Die Pullups zwischen '245 und 6551 hab ich nicht bestückt. USB und MAX funzen gleichermassen.

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

Hi,
ich hab den SX6551 drin und alles LS-Typen außer dem 688, der ist HCT. Pullups auch drin.
Lief seriell auf Anhieb.
Mehr kann ich auch nicht zu sagen.

Gruß
Eddi

Hier mal das Testprogramm (mit SLR assemblieren):

http://www.moria.de/~michael/tmp/sertx2.z80
http://www.moria.de/~michael/tmp/sertx2.com

Es sollte einen Strom von 'j' bei 9600 8N1 produzieren.

Michael

Moin,

abgesehen von der ersten Zeile (out (0f5h),a;reset) und einer anderen Basisadresse, hab ich exakt dieses Programm zum testen am Z80 genommen. Es hat wunderbar geklappt. Ach ja, die nops waren bei mir nicht mit drinn.

PS: Eingegeben habe ich das Programm über EZASS.

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

Wo ist der Schaltplan zur neuen SER? Ich habe nur eine ältere Version gefunden.

Vielleicht versuche ich demnächst, alle Daten am 6551 zu beobachten und mit meiner funktionierenden SER zu vergleichen.

Michael

Das müsste die letzte Version sein.
http://www.robotrontechnik.de/bilder/Upload_Forum/1rp_x05.jpg

Und das Layout:
http://www.robotrontechnik.de/bilder/Upload_Forum/1rp_v5p.jpg

Gruß
Eddi

Nicht ganz, für das letzte korrigierte Layout (v1.0a) hat mir Marcel noch die Daten geschickt. Da ist u.a. auch die Option drin, RTS/CTS 1:1 oder gekreuzt anzuschließen. Hab nur die KiCad-Daten und das Doku-PDF. Ich denke, Marcel hat sicher nichts dagegen, wenn ich das an H-W schicke, da auf der NKC-Page noch die Version 1.0 liegt.

Gruß, Rene

Da es bei Euch allen läuft, musste es eigentlich was Triviales sein.

Etwas googlen brachte die Antwort, auf die ich auch selbst hätte kommen können: 6551 UARTs lieben es gar nicht, wenn /CTS offen ist, und machen dann allen möglichen Unsinn.

Es ist wichtig, JMP1 korrekt zu setzen. Und dann läuft die neue SER auch und dank Oszillator gibt es auch keine Probleme mit dem Anschwingen des Takts mehr.

Michael

Hallo,

ich wollte mal fragen, ob Interesse an einem User-Treffen besteht. Bevor ich aber einen großen Thread aufmache würde ich mit per PN freuen, wenn ggf. Interesse unter Angabe der Stadt besteht.

Moin Moin,

mal wieder Zeit für was Neues

Ich hab Uhr3 etwas überarbeitet und Ingo aka. Deff hat wieder einmal ein super Layout dafür gemacht. Das Teil sieht nun so aus:



Über die Kosten kann ich noch nichts genaueres sagen, dürfte aber nicht so teuer werden ist ja recht klein.

Die Uhr3 wird übrigens vom 68k Grundprogramm direkt unterstützt.

Bei Intresse sagt bescheid.

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

Das passt ja gut, ich hätte das Ding sonst irgendwann auf Lochraster aufgebaut.

Sind noch Änderungen möglich? Die 100 nF sind in 2/10" wesentlich üblicher. C3 sitzt etwas blöd, wenn man IC3 ausbauen will. Pullups zwischen 245 und 12887 wären gut. Erlaubt JP1 den Interrupt vom 12887 zu nutzen? Damit würde man sich einen Timer sparen.

Ins CP/M 2.2 BIOS kriegt man die Uhr leider nicht eingebunden, ohne 1 KB Speicher zu opfern.

Michael

Moin Michael,

Die Platinen sind z.T. schon in Fertigung.

Zitat: Die 100 nF sind in 2/10" wesentlich üblicher

Das war vielleicht in den '80/90zigern so, aber heute nehmen wir eigentlich "alle" die 2,5mm Kerkos von z.B.Reichelt, die WIMAS sind einfach zu groß und zu teuer

Der JP1 ist für den Interrupt des 12887

Also bei mir läuft der Vorgänger (UHR3r3) seit 10 Jahren problemlos, auch one Pullups

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