Hallo,

beide Karten laufen jetzt so wie sie sollen. Wie so oft saß der Fehler 2m vor dem Bildschirm. Andis Rat mit dem nach Löten war völlig richtig, nur hatte ich dazu eine Heißluft Station verwendet. Hat bei den RAM aber nicht ausgereicht, habe die gestern von Hand noch einmal gelötet. Ist bei dem Gehäuse und den Pads die nicht über die Pins hinaus reichen nicht so einfach. Aber nun ist alles ok.
Bei der XP6 Version handelt es sich um einen exakten Nachbau, da ich die Gerberdaten aus dem Archiv von Hans-Werners Website.



Bei der XP2 Version habe ich einen 1,2V Spannungsregler eingefügt und die Pin Zuweisung teilweise geändert. Ebenso musste ich den VHDL Code für den PS/2 Anschluss etwas ändern, da der XP2 einige der XP6 Funktionen nicht unterstützt.

@Andi: Wenn Du mit der VGA2 diese Karte meinst, dann hätte ich noch 4 Platinen da.



Die würde ich für 5€ plus Porto abgeben. Versand kann etwas dauern, da ich in der Schweiz wohne und die Platinen aus Deutschland verschicke. Da ist das Porto nicht so hoch. Ebenso habe ich von der 68020 Karte von Torsten noch 4 Platinen da. Die würde ich auch für 5€ das Stück abgeben.

@Torsten: Dein System läuft noch nicht richtig. Die CPU Karte arbeitet, aber die GDP zeigt nichts an. Nun meine Frage ob ich die GDP mit 8 Bit auch an ein klassisches NKC System anschließen kann. Kann ich an die CPU Karte auch eine 8 Bit GDP z.B. die GDP-FPGA anschließen. Das würde das Testen etwas vereinfachen.

Tschüß
Uwe

Hallo,
Ja an einer Platine wär ich definitiv interessiert. Genau diese hab ich gemeint!
Würde dir gerne eine Platine abkaufen. Schick mir bitte eine E-Mail damit wir die Details klären können: andreas_v@gmx.at
PN funktionieren hier leider nicht.
LG Andi

Hallo Uwe,

Die HW-Revision, die du aufgebaut hast ist meine mit bereinigten Layoutfehlern, sollte also eigentlich "clean" sein - ich checke das aber gerne auch nochmal, brauche nur ein bisschen, das iss nun doch auch schon 10 Jahre her ;-)

Grundsätzlich habe ich habe das in etwa immer so iB genommen:


Check:
- Lötbrücken, Lötstellen -> ein kleines Mikroskop oder eine gute Lupe sind da hilfreich, evtl. mit einem kleinen Schraubenzieher oder einer Spitze mechanisch an den Beinchen "wackeln", manchmal sehen die nur gut gelötet aus.

- alle Spannungen
- Frequenz des OSCs
- erkennt das Prog den Baustein ?
- kleines VHDL-Prog laden um ein Beinchen zu toggeln, z.B. JP10
- evtl. VHDL-Prog bauen um einen Zähler auf Address- und Datenleitungen laufen zu lassen => check Lötstellen
- CSs und sonstige Steuersignale toggeln lassen
- VHDL-Prog bauen, um den Speicherzugriff zu testen
a) lokal: -> ein Fehler toggelt JP10, ansonsten für jeden Test JP11 toggeln
b) via CPU/BUS: VHDL-Prog nur für Zugriff aus Speicher bauen
- man kann sich noch allerhand kleine Mini-VHDL-Schnipsel überlegen, um lokal was zu machen, z.B. auch zwischen IC6 und IC7

Die Checks im Grunde für beide Bausteine Lattice/Xilinx durchführen

Wenn das alles erfolgreich war, sollte die Gesamtfunktion kein großes Problem mehr sein.



Du kannst mit der CPU Karte auch alle 8Bit Karten verwenden, und natürlich auch die GDP von Andreas. Das ist, bis auf den Bus, alles kompatibel. Auch die Ansteuerung meiner Karte über einen 8-Bit Bus sollte sofort funktionieren.

LG
Torsten

Hallo Torsten,

vielen Dank für die Tipps, die helfen mir sicherlich weiter. Besonders die Tatsache, dass ich die Karten auch mit einem klassischen System verwenden kann. Ich habe heute Deine GDP mal an mein 68020 System gehängt und die GDP funktionierte auf Anhieb. Bleibt nur noch die CPU, dort vermute ich einmal, dass der EEPROM Inhalt nicht zu meinem Minimalsystem passt. Von Deinem System habe ich bis jetzt nur die CPU und die GDP. Da werde ich mir wohl einen eigenen Inhalt erstellen müssen.

Tschüß
Uwe

Hallo,

so die CPU Karte läuft nun endlich auch. Aber den Fehler zu finden war gar nicht so einfach. Es gab ein normales Signalspiel auf den Adress- und Datenleitungen. Aber auf IORQ, MREQ, RD und WR sah es nicht so gut aus. Also habe ich das Bootprogramm mit den seriellen Meldungen verwendet, nur kamen bei mir keine Meldungen an. Die Karte arbeitet also nicht richtig. Dann habe ich beim CPLD mit einem kleinen Programm jeden einzelnen PIN auf Funktion überprüft. Dabei blieb der PIN B_RD ständig auf L. Dieser geht neben dem BUS auch auf beide RAM IC. Ich habe dann die entsprechenden Pins auf Schlüsse untersucht und konnte nichts sehen und habe daher auch Leiterbahnen getrennt um den IC herauszufinden welcher für den Schluss nach L verantwortlich ist. Den habe ich schlussendlich mit der Heißluftstation bearbeitet. Das hat geholfen, der Schluss war weg. Er lag unter dem IC und war von außen nicht zu sehen.

Die Karte lief dann, aber ich konnte keine Programme assemblieren. Ich vermutete erst einen Speicherfehler, aber ein RAM-Test brachte keine Fehler. Das Bootimage läuft auf dem Klassik-System aber ohne Probleme. Also beide Systeme noch einmal verglichen und siehe da, im Klassik-System werden 512KB vom BOOT-EPROM eingeblendet Auf Torsten seiner Karte aber nur 128kb. Das Image ist aber etwas größer als 128kb und der Assembler befindet sich am Ende des GP. Es wurde also etwas vom GP abgeschnitten und so funktionierte der Assembler nicht mehr richtig. Zur Behebung des Problems habe ich das Programm der CPLD angepasst. Nun funktioniert alles wie es soll.

Nun noch die GDP fertig aufbauen und auf der CPU noch die FPU und RTC einbauen. Die SD Karte funktioniert schon ohne Probleme, nur die CF-Karte zickt noch etwas rumm. Hat aber schon einmal funktioniert. Meine Backplane muss auch noch einmal überarbeiten und dort einen passenden Stecker für die Stromversorgung einfügen.

Muss noch überlegen ob ich 24MB Speicherkarte und die FLO fertigen lasse.

@Torsten: Was muss ich im CPLD ändern, damit ich mit 16Bit Breite auf die GDP zugreifen kann?

Tschüß
Uwe

Hallo Uwe,

ich habe mal in den alten Unterlagen gewühlt und versucht mich zu erinnern , ich fasse mal zusammen:

1) Kompilieren/Anpassen des GP:
===============================
Wenn das GP kompiliert wird, wird es an der in VAREQU.ASM durch setadr festgelegten Stelle im RAM abgelegt
->

setadr equ $80000 * Zieladresse des Programms
* Anpassung muss an eigenes Ram erfolgen

Die obere Grenze des verfügbaren Speichers wird in der Variablen grenze festgelegt, das sind im Original 4MB:

cpu equ 4 * 68020 Grundprogramm
grenze equ 1024*1024*cpu-1024*cpu-1 * Obergrenze für Speicher

Das habe ich bei mir geändert in:

memsize 100* Obergrenze in MB
grenze equ 1024*1024*memsize-1024*memsize-1 * Obergrenze für Speicher

weil ich ja noch die Speichererweiterung mit 28MB verwende.

Ist das GP kompiliert, kann es prinzipiell direkt von $80424 gestartet werden.
Will man es später brennen, muss man es erst mal mit dsave speichern:

dsave (JADOS Handbuch externe Kommandos)
$80000 ($60000 bei 68000 - setadr Wert aus varequ.asm)
128 (bei 68020, 64 bei 68000) den letzten Wert musst du jetzt auf 512 ändern, damit 512K abgespeichert werden.

Damit hast du dann ein GP > 128K.

2) Unterschied des Ladevorgangs zum Original:
=============================================
In meiner Lösung wird das komplette GP aus dem EPROM/FLASH der CPU68020 ins RAM kopiert und das FLASH danach ausgeblendet. Im Original wird, soweit ich mich erinnere, nur der Lader ins RAM kopiert, das LADE-EPROM ausgeblendet, dann nach dem GP gesucht, welches sich auf der/den ROA Karten befindet und direkt (im EPROM) ausgeführt.
Damit hast du dann im Original das Problem eines GP > 128K erst mal nicht. Dafür wird das GP im RAM bei meiner Lösung schneller ausgeführt.
Nachteil in meiner Lösung ist, dass das kompilierte GP erst mal zusammen mit dem Lader ins FLASH gebrannt werden muss, da muss man ein bisschen mit den Offsets aufpassen. Dafür ist das dann aber auch schön kompakt in einem FLASH.

3) Anpassen der CPLDs/FPGAs für GP > 128K:
==========================================
Als ich die Karte 2010 gebaut hatte, waren 128K für das GP noch ausreichend, du kannst das aber anpassen:

Im CPLD (IC1) der 68020-Karte wird die EPROM Größe durch folgende Zeile definiert:

rom_cs_s <= local_mem_cs_s when (ADDR_HI_i(31 downto 17) = "000000000000000" and bank_s = '0') else '0'; -- wir brauchen 128 K !!

=> für 512K musst du das ändern in :
rom_cs_s <= local_mem_cs_s when (ADDR_HI_i(31 downto 18) = "00000000000000" and bank_s = '0') else '0'; -- wir brauchen 512 K !!

Der Loader muss das nachher natürlich auch beachten:


4MB der 68020 Karte => $3F.FFFF
Standardmäßig lädt MOVE20.ASM das GP nach 3C.0000 (gpzielequ$3C0000), bleiben also 250KB (128KB für das GP + 128KB Speicher dahinter)
Mit 'gpziel equ $3B0000' hättest du dann 512K dafür reserviert.
Mit 'gpsize equ $1FFFE' sagst du dem Loader noch, dass er jetzt 512KB laden soll.
Da gpsize jetzt > 16Bit ist funktioniert der "dbra d3,gpmove" nicht mehr, weil dbra nur die unteren 16Bit des Zählregisters verwendet, da musst du also eine 2fache Schleife bauen. Ist jetzt aber auch keine Raketentechnik :-) - irgendwie sowas:

move.w #gpsize,d3
move.l #gpsize,d4
lsr.l #16,d4
lea gpziel,a0
lea gpstart,a1 * Start Adresse des GPs im EPROM
gpmove:
move.w (a1)+,(a0)+
dbra d3,gpmove
dbra d4,gpmove


4) Zugriff auf die GDP-FPGA und Unterscheidung 68000/68020:
===========================================================
Mit 16Bit Zugriff auf die GDP meinst du den Zugriff auf den Speicher der Karte, alles andere ist IO und damit erst mal 8Bit.
Der Zugriff auf den GDP-Speicher erfolgt bereits mit 16Bit, es muss im CPLD der 68020 Karte die Basis des GDP Speichers angegeben werden, das sind (IC1.vhd)
die Zeilen:

constant GDPII_MEM_BASE_ADDR_c : std_ulogic_vector (31 downto 22) := "0000000111"; -- ==> 0x070.0000 (range x100000 == 1MB, start at 28MB)
gdpii_mem_cs_s <= ext_mem_cs_s when ADDR_HI_i(31 downto 22) = GDPII_MEM_BASE_ADDR_c else '0';

Das steht auch so als Info in https://github.com/THemmecke/GDPFPGAII/blob/master/CPU68K20/ReadMe.txt, mit passendem JED-File.

Das RAM der GDP wird also 16Bit breit bei 28MB eingeblendet (hinter die RAM Speichererweiterung). Das muss in der GDP in IC1 (GDP-FPGA-IC1.vhd) natürlich entsprechend dekodiert werden:

constant MEM_BASE_c : std_logic_vector (29 downto 20) := "0000000111"; -- => 0x070.0000 * cpu (68020: range 0x100000 == 1MB, start at 28MB)

Die Unterscheidung, ob eine 68000 oder eine 68020 CPU im System ist habe ich nur eingebaut, weil die 68000-CPU standardmäßig die Adressleitungen A23-A31 nicht sauber setzt (sind offen). Man kann die also entweder nachträglich auf 0 legen, oder wir hier gemacht über ein "Flag" die Anwesenheit des 68000 signalisieren und dann A23..A31 ignorieren. Dazu habe ich das Signal F_NMI "missbraucht". Im LFXP wird dazu das NMI Signal fest auf 1 gezogen und dem Adressdekoder (XILINX IC1) die Anwesenheit eines 68000 mitgeteilt:
--nNMI_o <= '1'; (-> hier auskommentiert, weil ich einen 68020 verwende) das könnte man sich auch mal auf einen Jumper legen, oder eine andere elegantere Lösung bauen (z.B. die nicht verwendeten Adressleitungen des 68000 auf '0' legen).


Ich hoffe, dir damit weitergeholfen zu haben. Ich habe bei meinen Erinnerungsversuchen gemerkt, dass ich mich mal dringend wieder näher mit dem Thema beschäftigen muss

Grüße
Torsten

Hallo Torsten,

vielen Dank für Deine wieder sehr ausführliche Beschreibung. Einiges hatten wir ja schon weiter oben in diesem Thread geklärt.

So nutze ich auf meinem 68020 Nachbau auch Dein Bootprogramm und kopiere damit das GP auch vom EPROM in den RAM. Nun ist mir gerade aufgefallen, dass in Deinem Bootprogramm nicht 128KB kopiert werden, sondern 256KB. Denn move.w kopiert 16 Bit und nicht nur 8 Bit.

Das mit dem 16Bit Zugriff auf die GDP habe ich dann wohl missverstanden, ich dachte eher an 16Bit I/O Zugriffe.

Nun doch noch eine Frage, zeigt das GP auch RAM über 4MB mit dem Menüpunkt Q an?

Tschüß
Uwe

Du hast natürlich recht, ich habe da 2x128K kopiert (ganz großartig :-o). Das GP in der Version 710R5 war nur 128K groß, dahinter braucht es dann noch ein bisschen Speicher, sodas die Aufteilung wie im Menüpunkt Q ersichtlich die Folgende ist:

Adressbereich 4MB:

00.0000 - 3F.FFFF
Ladeadresse des GP im Loader 3C.0000 =>

GP: 3C.0000 - 3D.FFFF 128K GP (710R5)
3E.0000 - 3F.EFFF 124K Variablen, Symboltabellen (laut Doku)
3F.F000 - 3F.FFFF 4K Stack ?

Ob hier grundsätzlich auch mehr angezeigt wird, weiß ich gerade nicht, ich meine, dass das auch mit der im GP definierten Obergrenze zusammenhängt (VAREQU.ASM).


Der Zugriff auf I/O ist 8-Bit, weil ja alles 100% kompatibel zum Original ist, man könnte sich jetzt natürlich noch ganz andere Sachen einfallen lassen, das FPGA böte ja Möglichkeiten ....

Hier ein Bild der Speicheraufteilung meines Systems:
(ich versuch's mal ...)



LG
Torsten

Moin Moin,

das GP-Menü Q ist nicht in der Lage Speicher über 4MB anzuzeigen. Mit soviel RAM hatte wohl nie jemand gerechnet. (640 kB sollten eigentlich genug für jeden sein.)

Der Wert für die Konstante grenze kann gerne den absoluten oberen Wert des RAMs enthalten (solange unter 2GB). Der Abzug des einen kB (wie oben beschrieben) ist nur für den 68008 nötig.
grenze dient vorallendingen dazu, das der RAM-Test nicht in den IO-Bereich läuft.

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

Hallo Torsten, Jens,

vielen Dank für die Infos. Dann bleibt einem nur ein eigener RAM-Test. Hintergrund der Frage war, dass ich für Torstens System die FLOHD und die SRAM24 fertigen lassen habe. Eine Backplane habe ich auch fertigen lassen, nur sind die Bohrungen für den Stecker der Stromversorgung zu klein. Die kann man aber aufbohren. Aber ich wollte die Backplane in ein 19" Rackeinschub einbauen, leider hat die Backplane nicht das nötige Format dafür. Da werde ich wohl noch einen 3. Versuch machen müssen. Zum Glück sind die Fertigungskosten nicht so hoch.

@Torsten: Welche Frequenz muss eigentlich der Oszi auf der SRAM24 haben? Ich habe den Unterlagen leider Keinen Wert entnehmen können.

Doch nun zurück zum Classic-System:



Hier ist der Entwurf für eine neue GDP nach Andreas mit dem XP2. Der Audioconnector hat jetzt die richtigen Bohrdurchmesser und ich habe 2 SD-Kartenhalter am linken Rand vorgesehen. Einer auf der Vorderseite und einer auf der Rückseite. Man kann die auch auf die rechte Seite machen, nur muss dort erst Platz geschaffen werden. Zum einen kann man wie Torsten eine Kombination aus VGA und PS/2 Anschlüssen verwenden und der serielle Anschluss kann auch auf eine Pfostenleiste geführt werden.

Für Anregungen wäre ich Euch sehr dankbar.

Tschüß
Uwe

Ist es nötig, dass die Karte so hoch ist? Im originalen NKC sind die Karten eher niedrig und so passt das System noch in ein Rackmount-Gehäuse.

Michael

Hallo Uwe,

den OSZI auf der SRAM24 habe ich nie verwendet. Der ist nur drauf, falls man ihn mal brauchen sollte.
Der Zugriff erfolgt im Moment rein statisch.

LG
Torsten

Hallo Michael, Torsten,

wieso soll die Karte zu hoch sein? Die hat Eurokartenformat, 160x100 mm. Es gibt noch andere NKC Karten in dem Format und die Maße stammen nicht von mir sondern von Andreas. Ich habe die nur etwas an den besser erhältlichen FPGA angepasst. Sicher geht die noch niedriger, aber dann müssen Anschlüsse an der linken Seite weg fallen. Dann möchte ich auch ern sehen wie Du ein 68020 System mit 2 Bus3 Platinen in einen 19" Rackeinschub bekommst.

@Torsten:
Besten Dank für die Info, dann lasse ich den Oszi erst einmal weg.

Tschüß
Uwe

Ursprünglich hatte der NKC eher 8 cm hohe Karten mit Stiftleisten an der Oberseite, die zu Steckern im Gehäuse führen (Z80, ROA, BANKBOOT, 68008, SER). Leider kamen im Laufe der Zeit in der Tat höhere Karten dazu. Vermutlich wurden die meisten Systeme nie in Gehäuse eingebaut. Wenn möglich, versuche ich Karten im alten Format zu halten. Meistens hat man ja genug Platz auf dem Board.

Es ist schade, dass RDK keine mechanischen Vorgaben für die Karten machte.

Michael

Moin Michael,

es war tatsächlich so, das die Karten zuerst nur so gross waren wie sein musten. Allerdings hatte sich zum Schluß die so genannte GES-Norm durchgesetzt. Da waren alee Karten im Europa-Formart und hatte neben dem NKC-Bus auch noch einen ECB-Anschluss.

Allerdings gab es auch vorher schon div. Karten die höher Waren z.B. die IOE, GDP, COL256, SBC3...
Die höchste Karte (die ich kenne) ist übrigens diese: https://hschuetz.selfhost.eu/ndr/hardware/neu/mspeicher/sdio/index.html

PS: Die höheren Karten passten ohne Probleme in das (NKC-)Gehäuse. Das sah so aus: https://hschuetz.selfhost.eu/ndr/usertreffen/thomas/index.php?cmd=image&sfpg=KmJpbGQxMy5qcGcqN2M1YzIyZDI2MThiMWQ2YmViMDkyMTk2ZTcxZGVlOWE

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

Hallo Jens,

das Layout der SDIO überraschte mich auch, als ich die Platine bekam. Ich überlegte schon, den Schaltplan mal in Kicad neu zu zeichnen, denn meine gefädelte Version ist erheblich kleiner. Dann den Code in m68k umschreiben inkl. MBR mit dem Ziel, OS/9 von SD Card zu booten... allein die Zeit ist ein Problem.

Michael

Hallo,

da ja keine Verbesserungsvorschläge kamen, habe ich 5 Platinen und auch Stensil fertigen lassen. Davon habe ich nun 2 bestückt. Mit den Stencil Lötpaste auftragen und die SMD Bauelement bestücken. Dann ab in mein neues Spielzeug, einen Reflow-Ofen und zwar einen T962-A. Der taugt zwar eigentlich nicht viel, aber mit ein paar Modifikationen kann man gute Ergebnisse erzielen.





Ich war überrascht, wie gut ich den FPGA platzieren konnte. Beim ersten Versuch hatte ich mit der Lötpaste etwas Probleme, die ist mir beim abnehmen des Stencils verschmiert. Dadurch hatte ich ein paar Zinnbrücken beim FPGA. Liessen sich aber mit Entlötlitze gut entfernen. Die 2. Platine ist mir dann besser gelungen. Einzig die beiden Spannungsregler, der Kartenfassung und der C2 wurden im Ofen nicht gelötet. Weis bis jetzt noch nicht woran es gelegen hat. Auf der Rückseite habe ich auch per Stencil Lötpaste aufgetragen, die Bauteile aber dann per Hand verlötet.

Funktioniert haben beide Karten dann ohne Probleme.

Tschüß
Uwe

Hallo Uwe,

sieht sehr gut aus! Ich hätte ja auch gern endlich eine funktionierende GSP-FPGA. Aber nach den bisherigen Mißerfolgen liegt meine Hemmschwelle da gerade etwas höher.

Gruß, Rene

Hallo René,

Du kannst die zweite aufgebaute Karte bekommen. Die hat aber einen kleinen Schönheitsfehler, bei der seriellen Schnittstelle habe ich aus Versehen statt einem Stecker ein Buchse eingelötet. Ansonsten geht die auch ohne Probleme. Bin dieses Wochenende mal wieder in Deutschland und könnte Dir die Karte zu senden.

Tschüß
Uwe

Hallo Uwe,

die würde ich sehr gern nehmen!

Gruß, Rene