Naja, es ist erst ein Entwurf, es handelt sich hierbei um die in meinem anderen Thread besprochene CPU-Karte für den 68000/68010, die mit einem 16bit-ECB-Bus arbeitet, die Steuersignale wurden allerdings gegenüber der Kontron-Belegung vereinfacht und entsprechen nun den Signalen die auch der echte NKC benutzt.





Für Leute mit EAGLE hier noch die Dateien:

Schaltplan
Layout

Der nächste Schritt ist die Programmierung des CPLD-Inhaltes.

Gruß,
Christian

Was genau hast Du vereinfacht? Ich sehe auf Anhieb BANKEN, was NKC-spezifisch ist.

Würde es das Layout einfacher machen, den 68000 im PLCC-Gehäuse zu verwenden?

Soweit ich weiß, kann der 68000 durch ein Signal dazu gebracht werden, nur einen 8-Bit Datenbus zu verwenden. Ein entsprechender Jumper wäre sehr nützlich, damit nicht jeder direkt auch 16-bit Speicher bauen muss, der die Karte nachbauen möchte.

Michael

Die ursprüngliche Kontron-Belegung benutzt für 16bit die Steuersignal:

IOWR - IO Write
IORC - IO Read Control
MRDC - Memory Read control
MWRC - Memory Write Control
DS[0..1] - Data size

ich hab diese einfach durch

RDH - Read high byte
WRH - Write high byte

Ansonsten entsprichen die Reihen a+c der NKC-Belegung des ECB-Busses (im Forum gefunden).

Eine 16bit Speicherkarte soll als nächstes Entworfen werden, meine erste Idee sagte 4 MB pro Karte mit 4 MBit-RAM-Chips und und 4 MBit-Flashroms. Wenn das zu viel ist, gerne auch 1 MB.

Auf 8bit umschalten lässt sich nur der 68EC000, diesen benutze ich nicht. Ich habe die DIL-Version gewählt, da ich diese gerade da habe. Es könnte einfacher gehen mit der PLCC-Version, ja .. tu dir keinen Zwang an

Gruß,
Christian

Zitat: Die ursprüngliche Kontron-Belegung benutzt für 16bit die Steuersignal: IOWR - IO Write IORC - IO Read Control MRDC - Memory Read control MWRC - Memory Write Control DS[0..1] - Data size ich hab diese einfach durch RDH - Read high byte WRH - Write high byte

Das könnte sich nicht als Vereinfachung herausstellen, wenn eine 16-bit-Karte auch 8-bit-Zugriffe erlauben soll, weil es auf einmal mehr als ein Lesesignal gibt, statt einer Maske, welches Byte gefragt ist.

Die kombinierten Signale nicht anzubieten, kann ich schon verstehen, weil ihre Verwendung verbietet, eine Karte auch in 8-bit-Systeme zu nutzen. Deine geplante RAM-Karte könnte z.B. für 8-bit-Systeme einfach nur jeweils im unteren Byte bestückt werden und mit einem leicht geänderten CE dann auch nutzbar sein - solange die kombinierten Signale nicht benutzt werden. Aber warum bietest Du sie nicht trotzdem an? Kostet nur ein TTL, wenn im CPLD kein Platz mehr ist.

Liegt /INT nicht auf C21? Du hast es auf A liegen.

Wie ich sehe, hast Du /M1 nicht beschaltet. Ich habe die Details vergessen, aber in der mc hatte sich in den 80ern mal jemand was ausgedacht, wie er sowas beim mc68000 simuliert, um den Vektorinterrupt von Z80 SIOs nutzen zu können. Dazu gehörte noch etwas, um ihnen ein RETI vorzugaukeln. Ich weiß aber nicht mehr, wieviel Aufwand das war. Ich würde es aber wenigstens auf high ziehen, wenn das CPLD keinen Spielraum mehr bietet.

IEO sollte auf high gezogen werden, sonst funktioniert die Kette evtl. nicht.

Schließlich vermisse ich irgendwie einen Reset-Taster? Wird das beim NKC nicht auf der CPU-Karte geregelt?

Michael

>Das könnte sich nicht als Vereinfachung herausstellen, wenn
>eine 16-bit-Karte auch 8-bit-Zugriffe erlauben soll, weil es
>auf einmal mehr als ein Lesesignal gibt, statt einer Maske,
>welches Byte gefragt ist.

Ist beim Original-NKC nicht anders gelöst, auch der 68000er ist entsprechend organisiert.. bei dieser Beschaltung ist es problemlos möglich, auf das untere Byte zuzugreifen um 8bit Peripherie anzusprechen, praktisch ist es ja nichts anderes als die kombinierten signal, da man ja mit 2xRD und 2xWR beide Bytes einzeln und auch 16bit gemeinsam ansprechen kann.

Die RAM-Karte kann man ohne weiteres nur halb bestücken und in 8bit System stecken, RDH und WRH werden dann schlichtweg ignoriert..

Im CPLD löse ich das so, das IORQ und MREQ mit AS verknüpfe (wobei mir peinlicherweise auffällt das ich ja noch die oberen 4bit der Adresse an das CPLD legen muss, argh).. und die Schreib/Lese Signale mit UDS/LDS.

>Schließlich vermisse ich irgendwie einen Reset-Taster? Wird >das beim NKC nicht auf der CPU-Karte geregelt?

Danke für den Hinweis, den Power-On-Reset hätte ich glatt vergessen, den Taster auch.

>Wie ich sehe, hast Du /M1 nicht beschaltet. Ich habe die
>Details vergessen, aber in der mc hatte sich in den 80ern >mal jemand was ausgedacht, wie er sowas beim mc68000
>simuliert, um den Vektorinterrupt von Z80 SIOs nutzen zu
>können. Dazu gehörte noch etwas, um ihnen ein RETI
>vorzugaukeln. Ich weiß aber nicht mehr, wieviel Aufwand das
>war. Ich würde es aber wenigstens auf high ziehen, wenn das
>CPLD keinen Spielraum mehr bietet.

Über die M1 Problematik hab ich mir bereits Gedanken gemacht, und bin zu dem Schluss gekommen das es nicht wirklich nötig ist, da die Leitung im NKC meines Wissens nicht verwendet wird, und auch auf den originalen 68000er Karten einfach offen ist.

Zur Interruptkette, ich hab diese mal mit eingezeichnet, denke aber nicht das ich eine entsprechend verschaltete VG-Backplane bekomme. Momentan finde ich nur 1:1 Versionen mit verstärkten VCC und GND Leitungen, daher fällt das ohnehin flach.

Ein Problem ist auch .. ich habe doch Routingprobleme, wenn ich nicht auf Quadlayer gehen will..

Gruß,
Christian

EDIT: Adressen liegen jetzt korrekt an, Reset usw. kommt morgen bzw. eher "nachher".

Zitat: Ist beim Original-NKC nicht anders gelöst, auch der 68000er ist entsprechend organisiert.. bei dieser Beschaltung ist es problemlos möglich, auf das untere Byte zuzugreifen um 8bit Peripherie anzusprechen, praktisch ist es ja nichts anderes als die kombinierten signal, da man ja mit 2xRD und 2xWR beide Bytes einzeln und auch 16bit gemeinsam ansprechen kann.

Klar geht das mit beiden Verfahren. Mir scheint DS nur etwas einfacher für die IO-Karten zu sein und meistens bereut man Abweichungen von Standards, auch wenn sie exotisch sind, irgendwann, besonders, weil es halt nur minimaler Mehraufwand für die CPU-Karte ist.

Zitat: Die RAM-Karte kann man ohne weiteres nur halb bestücken und in 8bit System stecken, RDH und WRH werden dann schlichtweg ignoriert..

Nicht unmodifiziert, weil sonst Anfragen nach ungeraden Bytes ins Leere laufen. Aber eine kleine Änderung von CE kann da Abhilfe schaffen, um die Karte für 8-bit oder 16-bit Betrieb per Jumper zu konfigurieren.

Zitat: Über die M1 Problematik hab ich mir bereits Gedanken gemacht, und bin zu dem Schluss gekommen das es nicht wirklich nötig ist.

Wenn noch ein Pin am CPLD frei ist, kannst Du M1 ja dahin führen, mit high konfigurieren und sollte später jemand noch was schlaues einfallen, wäre es machbar. Ich würde es aber auch erstmal ignorieren.

Insgesamt finde ich das Projekt ziemlich cool, muss ich sagen, weil es eine neue Generation Karten ist. Der 16-bit-Aspekt macht die Sache sehr interessant. SMD und CPLD erschweren den Nachbau natürlich enorm, aber gerade zur Entwicklung ist das CPLD sicher sehr dienlich. Es wäre später immer noch möglich, den finalen Entwurf in TTL nachzubauen und den 68000 im PLCC-Gehäuse zu nehmen, um mehr Platz zu bekommen, und dafür dann ohne SMDs zu arbeiten.

Michael

Nunja, ich finde:

SOICs sind wirklich absolut kein Problem, das schafft man eigentlich auf Anhieb. Das CPLD ist ein Xilinx XC9572, das ISE Webpack ist vollkommen ausreichend und kostenlos verfügbar, die Programmierung kann über einen simplen Parallelport-Adapter erfolgen. Ich sehe hier keine Schwierigkeiten im Nachbau.

>Nicht unmodifiziert, weil sonst Anfragen nach ungeraden >Bytes ins Leere laufen. Aber eine kleine Änderung von CE >kann da Abhilfe schaffen, um die Karte für 8-bit oder
>16-bit Betrieb per Jumper zu konfigurieren.

Doch das funktioniert.. beim 16bit System liegt die Adresse des Wortes auf dem Bus, die "A0" ist in RD,WR,RDH,RDL kodiert. Wenn du meinen Schaltplan genau betrachtest, wirst du erkennen das A0 auf dem Bus A1 des 68000 ist.

Ein 8bit system greift jedoch immer nur auf die Untere Bank zu, die Adressen sind dennoch fortlaufend. Man muss natürlich das ROM entsprechend beschreiben. Ein RAM-Karte könnte man auch vollbestückt in das System stecken, sie funktioniert dann problemlos (mit halber Kapazität allerdings).

Ist schwer in Worten zu vermitteln, denke einmal darüber nach.

Ein weiterer Grund warum ich RDL/RDH usw. nutze ist, damit die bereits entwickelten 8bit ECB-Bus-Karten ohne weiteres funktionieren (von Speicher mal abgesehen)..

Gruß,
Christian

Ah, so interpretierst Du das. Aber wie meint die ECB-"Spezifikation" das nun?

Es hiesse, dass man in IO-Code für 8-bit Systeme alle Adressen verdoppeln muss, damit er auf einem 16-bit System läuft. Bleibt man bei ECB-A0=CPU-A0, hat man das blöde Problem, was ich ansprach, aber Code bleibt kompatibel und 8-bit RAM-Karten sind auch weiter nutzbar. Effektiv würde A0 von 16-bit Hardware einfach ignoriert werden, die dann erwartet, dass auf ungerade Adressen byteweise zugegriffen wird, indem A0=0, DS0=0 und DS1=1 ist, während bei 8-bit Hardware auf ungerade Adressen mit A0=1, DS0=1 und DS1=0 zugegriffen wird. Eindeutig weniger elegant als Deine Interpretation, nur um kompatibel zu sein - bei PCs wäre das so gemacht worden, weil Code für einen 8085 nach maschineller Übersetzung auch auf einem 8088 und unverändert auch auf einem 8086 liefe. Hmm, ich beginne zu ahnen, warum es auf dem 8086 keinen Bus Error gibt.

Ein wenig mehr Dokumentation als nur das Pinout wäre hilfreich. Ob Kontron oder sonst jemand noch irgendwas darüber weiß? Elzet gibt es noch und die bauen auch immer noch ECB-Hardware, vielleicht lohnt sich eine Anfrage da.

Michael

Der 68000 hat garkeine Adressleitung A0, da die Adressen bytebezogen sind, das mit den verdoppelten Adressen ist korrekt, ist aber beim original NKC (und daher auch im Grundprogramm) genauso ..

UPDATE: Es kam eine Resetschaltung hinzu, und ein Jumper zur Einstellung der Waitstates, der CPLD Code steht bereits im Grundgerüst und wird gerade von mir auf korrektes Verhalten geprüft. Die Steuerung der direkten Zugriffe funktioniert im Simulator bereits, Interrupt und DMA bedürfen noch der Prüfung. M1 liegt noch statisch auf High. Bis jetzt ist das CPLD zu 50% belegt.

Gruß,
Christian

Moin Moin,

das Projekt nimmt ja schöne Formen an

Ich hab mal einen Teil aus dem anderen Thread rübergeholt, passt hier besser hin

Ich bin momentan noch an der Entwicklung der Schaltung, dort kommen dann die Erfordernisse für das CPLD auf, ich hoffe das es ausreicht. Kopfzerbrechen bereitet mir z.B. die Anpassung von BUSRQ/BUSAK auf BG/BR/BGACK. Momentane Idee ist eine State-Machine (ich skizziere mal):


Status: 1 - IDLE
Signal: BR = 1, BGACK = 1, BUSACK = 1
Übergänge: BUSRQ = 0 -> 2

Status: 2 - BUS REQUESTED
Signal: BR = 0, BGACK = 1, BUSACK = 1
Übergänge: BUSRQ = 1 -> 1
BG = 0 -> 3

Status: 3 - BUS GRANTED
Signal: BR = 1, BGACK = 0, BUSACK = 0
Übergänge: BUSRQ = 1 -> 1

Prinzipiell sieht das schon ganz gut aus, aber...
Nach dem Übergang von BG auf 0 must du auch noch warten, das /AS=0 wird! erst dann darf der Bus von der anfordernden Einheit benutzt werden.

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

Gut, das korrigiere ich (ja, CPLDs sind schon was feines, in TTL wäre das jetzt böse geworden..)

Da im CPLD noch Platz ist, wäre ich am Thema "M1-Emulation" doch interessiert.

Gruß,
Christian

Hi,

warum das DIL Gehäuse ? Wird doch gar nicht mehr geliefert !
Wenn neu, dann 68HC001. Der ist nach wie vor aktiv und kann über einen PIN zwischen 8/16 Bit Datenbus umschalten.
Beziehen kann man den 68HC001 über verschiedene Distries allerdings immer nur in Mengen zu 18 Stück. Aber bei einer Sammelbestellung wäre das ja kein Problem...

Als Speicherkarte existiert bereits eine 3MB FLASH/RAM Karte (habe ich hier noch nicht veröffentlich) mit ECB Bus. Die hat den 16Bit Bus (Kontron/RDK).

Als Software schlage ich zunächst die vorhandene RDK Software vor. Später sollte es möglich sein mit uCLinux was anzurichten (benötigt keine MMU oder FPU).

Grüsse
Torsten H.

Hallo,

Das DIL Gehäuse ganz einfach weil ich ein paar 68000er im DIL Gehäuse da habe, "später mal" werde ich ev. auch eine Platine für das PLCC-Gehäuse entwerfen, an der Schaltung ändert sich ja nichts, das Layout muss ich jedoch zumindest in der rechten Hälfte komplett neu entwickeln.

Gruß,
Christian

Zitat: Hi, Als Speicherkarte existiert bereits eine 3MB FLASH/RAM Karte (habe ich hier noch nicht veröffentlich) mit ECB Bus. Die hat den 16Bit Bus (Kontron/RDK).

Und da ist schon der Punkt, an dem es sich lohnt, den Bus unmodifiziert zu verwenden.

Für welche Interpretation der 16-bit-Erweiterung hast Du Dich entschieden? Ignorierst Du A0 oder verwendest Du A0 als A1, d.h. A0 selektiert nicht mehr Bytes, sondern 16-bit Wortadressen?

Michael

Ich bleibe bei A0 = A1.. dies entspricht auch dem original NKC und vorallem der Architektur des MC68000. Außerdem steht die Schaltung, und mein gesamtes Konzept fußt hierrauf.

Es geht mir vorallem darum, das die bereits entworfenen 8bit-ECB-Karten ohne weiteres funktionieren, und dies mit dem originalen RDK-Grundprogramm (verbessert von Jens).

Die Tage werde ich mich auch nochmals an einer Version mit PLCC68 für den 68000er beschäftigen, aber ich denke das hat erst dann richtig Sinn wenn die DIL-Variante, welche ich mit meinem vorhanden MC68010 testen kann, einwandfrei funktioniert.

Gerne darf dies auch jemand anderes übernehmen, ich bitte allerdings vor Schaltungsänderungen um Rücksprache, damit nicht -zig Versionen entstehen die inkompatibel sind und somit das Projekt zum erliegen kommt.

Gruß,
Christian

Zu M1: Der Z80 bestätigt einen Interrupt damit, dass M1 und IORQ für zwei (Wait-)Zyklen beide low sind. Die Interruptquelle sieht das und legt bei M1 und IORQ low den Wert ihres Interrupt-Registers auf den Datenbus. Hier hängt die Richtung des Datenbuspuffers also nicht von RD/WR ab. Das ist der erste Teil der Geschichte. Evtl. funktioniert es, wenn Du einen IO Read von einem nicht belegten Port machst und das CPLD bei so einem Read M1 steuert. Man müsste sich das Timing mal genau anschauen.

Teil 2: Die Interruptquelle schaut zu, bis sie ein instruction fetch (m1, mreq, rd low) sieht, was ein RETI holt. Die analoge Idee wäre ein Read eines bestimmten Speicherplatzes mit dem Opcode von RETI, der ebenfalls M1 triggert.

Ich hoffe, das stimmt so halbwegs, meine Z80-Zeiten über 20 Jahre her. Ich meine, dass es zwei verschiedene Vektorinterruptmodi gibt, aber ich weiß nicht, ob die sich im Bustiming unterscheiden oder nur in der CPU, und auch nicht, welche Details ist sonst noch vergaß.

Was die Bedeutung von A0 angeht: Ich weiß es wirklich nicht. Vielleicht hat Torsten ja noch mehr Quellen. Ein A0 wäre recht leicht zu generieren, wenn Du die Bytesignale zum CPLD bringst, aber die Verschaltung der Adressleitungen kann man so natürlich nicht korrigieren.

Die Beschreibung im Pinout legt nahe, dass DS0 und DS1 active low sind, obwohl es nicht dransteht. Bei den kombinierten Zugriffssignalen würde ich es auch erwarten, es steht aber ebenfalls nicht dran. Ansonsten fand ich im Internet rein gar nichts dazu.

Michael

Nunja, ich werde beim Konzept A0 = A1 und RDL,RDH,WRL,WRH bleiben. Ich haber nur eben gesehen das beim Original-16bit-NKC die normale IO an D15-D8 hängt, dies ist kein Problem normalerweise, man muss nur im Grundprogramm die Adressen um 1 erhöhen, denke das ist kein großes Problem, da ja sämtliche Adressen in der varequ.asm stehen.

Gruß,
Christian

Moin Moin,

die Adressen im GP zu ändern ist wirklich kein Problem, aber es gibt auch ne Menge Programme, die die Peripherie selbst ansteuern und dort würdest du aufbrettern

Leg doch einfach die Prozessor-Datenleitungen D8-D15 auf die Busleitungen BusD0-BusD7 und D0-D7 auf BusD8-BusD15.

Bei dieser Anordnung muss man nur bei den EPROMs drauf achten, auf welche Seite des Busses man sie anstöpselt.
Zwar könnte es bei 16Bit Peripherie auch zu Problemen kommen, aber ich glaube da gibt es (noch) nicht so viel

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

>Leg doch einfach die Prozessor-Datenleitungen D8-D15 auf die >Busleitungen BusD0-BusD7 und D0-D7 auf BusD8-BusD15

Es wäre zwar schon eine Idee, aber irgendwie ist das Pfusch...

.. welche Programme wären das denn?

Gruß,
Christian

Hallo Michael,

Für welche Interpretation der 16-bit-Erweiterung hast Du Dich entschieden? Ignorierst Du A0 oder verwendest Du A0 als A1, d.h. A0 selektiert nicht mehr Bytes, sondern 16-bit Wortadressen?

Bei mir ist A0 = A0. Damit kann ich die Karte auch in meinem Z80 System einsetzen. Ausserdem verwende ich kein RDH / WRH sondern codiere die DS0 DS1 Leitungen (B28 und B29) aus.

Die RDH WRH kann ich natürlich bei Bedarf mal mit auf´s CPLD legen...





Grüsse
Torsten H.
(habe mal ein H. dahintergeschrieben, da es hier noch einen Torsten gibt :-) )