letzter Beitrag von MiCv2 am
5Volt tolerant bedeutet nicht, dass es auch langfristig hält.
Halten tut das und TTL-kompatibel ist es normalerweise auch. Ist halt die Frage ob sich der Rest der Schaltung an die TTL-Specs hält. Wenn ich was von Cs in den Leitungen lese, habe ich so meine Zweifel.
Es sollte IMHO schon innerhalb der Spezifikation laufen [...]
5Volt tolerant bedeutet nicht, dass es auch langfristig hält.
Wenn ein Chip 5V-tolerant ist, ist das doch bereits Teil seiner Spezifikation: das Attribut "5V-tolerant" wird vom Hersteller vergeben.
Easyflash 3 und Chameleon verwenden übrigens beide einen 5V-toleranten CPLD als Interface zwischen dem Expansionsport und ihrern 3V-Komponenten.
Notiz am Rande: Man könnte GAL-Pins sparen, wenn man das Register im Adreßraum des Coprozessors in den gesamten 16K ab $4000 einblendet- oder, alternatibv, könnte man ein 32K-RAM verwenden, das man von $0 bis $7eff einblendet. Das _sollte_ mit der bestehenden Software verträglich sein, böte aber einiges Potential für neue Projekte.
Mein erster Gedanke war das RAM von $0000-$3FFF zu legen (16kByte) und die nächsten 16kByte ($4000-$7FFF) mit dem Transfer-Register zu belegen. ROM dann ab $8000.
So einfach ist das aber nicht:
Es gibt tatsächlich im ROM2 einen kleinen Speichertest (ab Adresse $FF78), welcher zwischen 8kByte und 32kByte unterscheidet. Also wenn mehr RAM, dann fast volle 32kByte bis $7EFF. Und ab $7F00 das Transfer-Register. Keine Ahnung, ob das eigentliche Schachprogramm aber auch mit dem mehr an Speicher zurecht kommt. (Vielleicht wäre ein Jumper/DIP-Schalter für 8k/32k auch hier von Vorteil...)
Ich habe mir auch mal flüchtig das Listing meines 6502-Disassemblers in Hinsicht auf verwendete illegale Opcodes angeschaut: Es werden (soweit ich das Überblicken kann) nur "neue" Opcodes des 65SC02 verwendet, speziell PHX, PHY, PLX und PLY in der NMI-Routine ab Adresse $FDF1.
Die SMD-CPU von Western Digital sollte damit aber klar kommen...
Gruß,
Thomas
Wenn ich die EF3 aus dem Ofen nehme, programmiere ich auch den cpld.
Schon allein um alles zu testen.
Sowas sollte mir hier auch gelingen, um sicher zu gehen, daß alles funktioniert.
Und hier ist meine Version des Schaltplans...
...aber leider nicht fehlerfrei...
Bei Anpassen des Schaltplans an die neuen Gegebenheiten habe ich mich über meine komische Nummerierung der SRAM-Adressleitungen gewundert. Auf meinem Papierentwurf war noch alles in Ordnung, im Schaltplan habe ich alles verwürfelt... 
Deshalb ist hier ein Update des PDFs und des ZIP-Archivs.
Gruß,
Thomas
Nebenbei bemerkt:
1) Normalerweise sollten Speicherzugriffe beim 6502 nur erfolgen, wenn PHI2 HIGH-Pegel hat, also 1 ist. Die FCC hat dies nicht berücksichtigt, ich denke aber die neue Karte sollte diese Eigenschaft aufweisen.
2) Ich denke im Moment über eine Möglichkeit nach, ein Flash-ROM auf der C64-Seite zu verwenden. Wenn man die /GAME- und /EXROM-Leitungen über einen Schalter trennbar macht, dann könnte man die Karte hardwaremäßig abschalten. Dann könnte man ein "Brennprogramm" laden, dies starten, dann die Karte wieder einschalten ($8000-$BFFF wird dann durch das Flash-ROM belegt) und das Programm könnte den Inhalt vom ROM1 flashen. Auf der C64-Seite mag das klappen, auf der 6502-Seite wird es wohl beim steckbaren Eprom bleiben. Oder ich verwerfe diese Idee und versuche zwei Eproms unterzukriegen...
Weiterhin schöne Ostertage,
Thomas
Die Logik könnte man gegebenenfalls auch mit einem GAL erschlagen. Wäre das sinnvoll?
Ich beantworte die Frage mal selbst (zumindest für den 6502-Teil):
Zuerst bräuchte man etwas Logik für das Ansprechen der Speicher und Register nur während der Zeiten, wo PHI2=1 ist:
Zwei Gatter und ein Inverter, macht zwei Bausteine (vielleicht LS04 und LS00, im Bild sind fälschlicherweise AND-Gatter statt NAND-Gatter gezeichnet)).
Dann käme die Ansteuerung des EProms:
Hier wird nur ein weiterer Inverter benötigt. Dies erhöht also nicht die Gesamtzahl der ICs.
Als nächstes folgt die Ansteuerung der Register:
Hier kämen nochmal zwei Bausteine hinzu: Ein großes NAND-Gatter sowie zwei OR-Gatter. Sind jetzt also schon vier ICs: LS30, LS32, LS04 und LS00.
Fehlt aber noch die Ansteuerung des RAMs (aktuell nur mit 8kByte):
Diese Dekodierung kann mit den übrigen OR-Gattern realisiert werden. Wir bleiben bei vier ICs. Wenn jetzt allerdings noch eine Ausweitung des RAM-Bereichs bis $7EFF erfolgen soll (also fast volle 32kByte RAM) dann kommt mindestens noch ein IC dazu. Ich rechne also mit fünf ICs für die Dekoderlogik auf der 6502-Seite.
Dem gegenüber stände ein einziges IC (ein GAL16V8), das die gesamte obige Logik zum Dekodieren in sich vereinen würde:
Das obige Bild ist bereits ein Ausschnitt aus meinem aktuellen Entwurf. Alle benötigten Signale liegen auf den GAL-Eingängen, inklusive dem Signal zum Umschalten der Speichergröße. Die sechs Ausgänge steuern dann die Speicher- und Register-ICs direkt ohne weitere Logik-ICs an.
Ich finde diese Lösung wesentlich zeitgemäßer, eleganter und vor allem platzsparender...
Gruß,
Thomas
Ich finde diese Lösung wesentlich zeitgemäßer, eleganter und vor allem platzsparender...
Ja, finde ich inzwischen auch. Allerdings sind GALs ja selbst schon retro... aber es scheint sie noch zu geben.
Mit einem CPLD wäre es evtl. möglich, die restlichen 74er ICs auch noch einzusparen, wenn man schon dabei ist.
Ich denke im Moment über eine Möglichkeit nach, ein Flash-ROM auf der C64-Seite zu verwenden.
Wäre nicht schlecht, aber so richtig elegant wäre es halt nur, wenn man auch das CPU-ROM flashen könnte, ansonsten braucht man doch wieder einen EPROM Brenner, sollte man jemals andere Firmware haben.
Wenn beide Flash-ROMs gesockelt wären, könnte man zuerst das eine flashen, dann umstecken und dann das andere, Nicht sonderlich elegant, aber vielleicht besser als nix.
Wäre nicht schlecht, aber so richtig elegant wäre es halt nur, wenn man auch das CPU-ROM flashen könnte, ansonsten braucht man doch wieder einen EPROM Brenner, sollte man jemals andere Firmware haben.
Wenn beide Flash-ROMs gesockelt wären, könnte man zuerst das eine flashen, dann umstecken und dann das andere, Nicht sonderlich elegant, aber vielleicht besser als nix.
Ich sehe keine Chance, dass 6502-ROM onboard zu flashen, ohne massiven Aufwand zu betreiben. Das wäre aber ja wieder kontraproduktiv. Also wahrscheinlich doch einfach zwei 28polige 27C256 in DIL (und als OTP (sind günstiger und es gibt ja eh nur die eine Software...)).
Mit einem CPLD wäre es evtl. möglich, die restlichen 74er ICs auch noch einzusparen, wenn man schon dabei ist.
Ich habe bei Mouser mal nach 5V-CPLDs gesucht. Neben GALs gibt es ebenfalls von Atmel/Microchip für eine Versorgung mit 5 Volt den ATF1502AS. Überschlagsmäßig sollte der passen. Der hat auch genügend (unabhängig taktbare) FlipFlops, so dass neben der Logik auf der 6502-Seite die beiden Transfer-Register (16 Bit), das Konfig-Register (3 Bit) und die Dekodierlogik auf der C64-Seite (plus der eventuell notwendige zusätzliche Aufwand um die 1nF-Kondensatoren loszuwerden) reinpasst. Also eigentlich ein idealer Kandidat, zudem es ihn auch in TQFP und mit einer JTAG-Schnittstelle gibt.
Dann wären auf dem Modul nur noch:
* ein Eprom 27C256 (mit der C64-Software ROM1)
* ein Eprom 27C256 (mit der 6502-Software ROM2)
* eine 6502-CPU (von Western Digital)
* ein 32kByte RAM (von dem wahlweise nur 8kByte benutzt werden)
* ein Taktoszillator-IC ICS525-01 (plus 12MHz-Quarz; erzeugt: 5MHz, 7MHz, 10MHz und 14MHz)
* ein Reset-IC (plus Batterie)
* ein Glue-Logik-Chip (der besagte ATF1502AS)
Probleme sehe ich hier nur auf der Softwareseite vom Atmel: Ich habe mit denen noch nichts gemacht. Es wird wohl WinCUPL (alt und buggy) benötigt. Und zum Brennen (evtl. mit dem Altera USB-Blaster?) die Software ATMISP. Das wäre aber alles Neuland für mich. Würde aber insgesamt auf der C64-Seite nochmal 5 TTL-ICs einsparen (und das GAL auf der 6502-Seite dazu...).
Gruß,
Thomas
Würde evtl. auch ein 5V-toleranter 3V CPLD gehen ohne dass man einen Haufen 3V-5V-Pegelwandler verbauen muss? Da wäre die Auswahl vermutlich höher.
Der ICS525-01 scheint mit auch schon etwas betagt zu sein, ist aber wohl einer der wenigen mit parallelem Interface. Aber könnte man nicht auch das den CPLD machen lassen, also z.B. einen 20 MHz Oszillator nehmen und den CPLD den Takt herunterteilen lassen? Ist ein CPLD dafür schnell genug?
Würde evtl. auch ein 5V-toleranter 3V CPLD gehen ohne dass man einen Haufen 3V-5V-Pegelwandler verbauen muss? Da wäre die Auswahl vermutlich höher.
Der ICS525-01 scheint mit auch schon etwas betagt zu sein, ist aber wohl einer der wenigen mit parallelem Interface. Aber könnte man nicht auch das den CPLD machen lassen, also z.B. einen 20 MHz Oszillator nehmen und den CPLD den Takt herunterteilen lassen? Ist ein CPLD dafür schnell genug?
Ich hatte auch darüber nachgedacht, die gesamte 6502-Seite auf 3,3V zu legen, aber dann kommst Du um ein paar Pegelwandler nicht rum. Und Du hast auch noch den Spannungsregler. Von daher hielt ich ein 5V-Design für einfacher zu realisieren.
Der ICS525-01 ist klasse! Sicher wäre es möglich, zwischen 5MHz und 10MHz mit einem CPLD umzuschalten. Ich wollte aber auch noch die vollen 14MHz Taktfrequenz mir generieren lassen. Unabhängig davon, ob das später verwendet werden kann...
EDIT: Und betagt sind doch so ziemlich alle Bauteile auf dem Modul. Solange es sie noch zu kaufen gibt und nicht abgekündigt werden, sehe ich keine Probleme...
Gruß,
Thomas
Ich hatte auch darüber nachgedacht, die gesamte 6502-Seite auf 3,3V zu legen, aber dann kommst Du um ein paar Pegelwandler nicht rum.
Deswegen hat das ja auch niemand vorgeschlagen - auch wenn die Pegelwandlung in diesem speziellen Fall wohl auch vom CPLD nebenbei erledigt werden könnte.
ZitatUnd Du hast auch noch den Spannungsregler.
Es muss ja nicht gleich ein Regler im TO-3-Gehäuse sein, für die paar mA reicht auch was in SOT-223 oder evtl. noch weniger. Man könnte zB mal im Easyflash 3-Schaltplan spicken.
Wie flasht man eigentlich so einen GAL? Ist das problemtischer als einen CPLD? Mit Sicherheit können die wenigstens GAL und / oder CPLD flashen. Ich denke aber, CPLD ist die Option mit mehr Möglichkeiten!??
GAL kannst z,B, mit nem billigen TL866CS Eprommer brennen.
Für die Xilinx 9536 gibt es auch billige Parallelkabel und die freie ISE Software.
Noch interessanter wäre vielleicht gleich ein FPGA, wo Du die CPU mit rein packst. Siehe die 13,- Cyclone 2 Boards bei ebay. Oder das 20,- USB Board von trentz,
Noch interessanter wäre vielleicht gleich ein FPGA, wo Du die CPU mit rein packst. Siehe die 13,- Cyclone 2 Boards bei ebay. Oder das 20,- USB Board von trentz,
FPGA-Projekte habe ich im Moment genug. Zwar nicht eigene, aber da kommt nicht noch eins dazu. Man könnte das ansonsten so weit treiben, dass alles (also auch die ROMs) im FPGA zu finden ist und das FPGA einfach an den Expansionport angebunden wird (evtl. über Pegelwandler wegen 3,3V-Versorgung). Aber das gänge mir dann doch zu weit. Da wäre ich raus... (Eine Batteriepufferung für das SRAM gäbe es dann auch nicht mehr...)
Für die Xilinx 9536 gibt es auch billige Parallelkabel und die freie ISE Software.
Habe nur noch USB, keinen Parallelport mehr. Die 9536 gibts als 5V-Variante auch nicht mehr, nur noch als 5V-tolerante 3,3V-Version.
Probleme sehe ich hier nur auf der Softwareseite vom Atmel: Ich habe mit denen noch nichts gemacht. Es wird wohl WinCUPL (alt und buggy) benötigt. Und zum Brennen (evtl. mit dem Altera USB-Blaster?) die Software ATMISP. Das wäre aber alles Neuland für mich. Würde aber insgesamt auf der C64-Seite nochmal 5 TTL-ICs einsparen (und das GAL auf der 6502-Seite dazu...).
Ich habe vorhin mal nach einer WinCUPL-Version gesucht und auch gefunden. Ist bereits auf meinem alten Laptop installiert, plus eine Win7-Version von ATMISP. Die konnte zwar mit dem Altera-USB-Blaster rein gar nichts anfangen und will ein "Atmel ATDH1150USB"-Cable vorgesetzt bekommen. Das ist ein FT2232D-basiertes Design. Das Programm lässt sich aber austricksen, wenn man die String-Diskriptoren im 93C56-EEProm vom FT2232D nach "AtmelISP" und "ATDH1150USB" ändert. Nicht einmal die PID/VID habe ich geändert und ATMISP beschwert sich nicht mehr über ein fehlendes Kabel.
Ich denke, das ist ein guter Anfang.
In den nächsten Tagen werde ich mal die Tool-Kette mit einem kleinen Design füttern und auch mal an den FT2232-Pins messen, ob ATMISP auch wirklich was sendet und nicht nur so tut... (Habe hier ein FT2232H-Mini Module zum Testen, das kann leider nur 3,3V an den I/Os und keine 5V, die ein ATF1502AS aber fürs JTAG braucht). Aber auch kleine Schritte führen irgendwann zum Ziel...
Gruß,
Thomas
Gerade beim Aufräumen gefunden, vielleicht hat ja jemand Interesse an historischen Artefakten...
Deshalb ist hier ein Update des PDFs und des ZIP-Archivs.
Kannst Du beim nächsten Update die FCC-cache.lib mit in das ZIP nehmen? Ich hatte in meinen Bauteilbibliotheken den Reset-Taster (SW_PUSH_SMALL_H) nicht. Wenn man die Projektname-cache.lib mitsichert, ist das aber egal, weil da eine Kopie aller verwendeten Bauteile mit drin ist.
Ich habe diese cache-Dateien bei meinen Projekten sogar mit in mein Subversion genommen (zugegebenermaßen aus Bequemlichkeit, weil ich wechselseitig unter Windows und Linux arbeite und oft die Bibliotheken noch unterschiedlich sind, bis ich da einen guten und stabilen Ablauf habe).
Hallo,
sehr ruhig hier geworden...
Kannst Du beim nächsten Update die FCC-cache.lib mit in das ZIP nehmen? Ich hatte in meinen Bauteilbibliotheken den Reset-Taster (SW_PUSH_SMALL_H) nicht. Wenn man die Projektname-cache.lib mitsichert, ist das aber egal, weil da eine Kopie aller verwendeten Bauteile mit drin ist.
Ok, werde ich mir merken und die Datei dann entsprechend mit ins Archiv packen. Danke für den Hinweis...
Mit einem CPLD wäre es evtl. möglich, die restlichen 74er ICs auch noch einzusparen, wenn man schon dabei ist.
So soll es denn sein!
Ich habe in den letzten Tagen den Schaltplan für meine Version vervollständigt und alle 74er-TTLs rausgeworfen. Das wird jetzt alles mit einem ATF1504AS erledigt. Ist gar nicht mehr so viel übrig geblieben. Der angehängte Schaltplan ist vorläufig, da werden beim Routen der Platine garantiert noch Signale an den Pins vom CLPD getauscht werden, damit entweder das Routen einfacher wird oder der Compiler fürs CPLD keine Errors oder Warnungen ausspuckt.
In den nächsten Tagen werde ich mal die Tool-Kette mit einem kleinen Design füttern und auch mal an den FT2232-Pins messen, ob ATMISP auch wirklich was sendet und nicht nur so tut... (Habe hier ein FT2232H-Mini Module zum Testen, das kann leider nur 3,3V an den I/Os und keine 5V, die ein ATF1502AS aber fürs JTAG braucht). Aber auch kleine Schritte führen irgendwann zum Ziel...
Meine Tool-Kette funktioniert auch inzwischen, auch wenn ich im Moment nur mit dem kleinen Bruder, dem ATF1502AS spiele. Aber so ein Minimaldesign, wie ein UND-Gatter lässt sich hiermit schon sehr gut realisieren. Deswegen bin ich zuversichtlich, dass auch der ATF1504AS funktionieren wird. Ich klöppel mir nebenbei schon die ersten Zeilen für die Logik für die neue FCC zusammen und bis jetzt wird auch fehlerfrei übersetzt. Wobei ich in CUPL noch nie ein Logikdesign beschrieben habe. Das dauert also noch etwas...
Inzwischen weiss ich auch was es mit den 1nF-Kondensatoren an den I/O1- und I/O2-Leitungen auf sich hat. Schon mal ein Scope drangehängt? Da gibt es jede Menge kurzer Impulse nach Low, so dass diese ausreichen, Fehltriggerungen an den Übergabe-FlipFlops auszulösen. Ein Kondensator erhöht die Umladezeit und sorgt dafür, dass bevor ein Low-Pegel erreicht wird, der I/O-Pin schon wieder High ist. Mal sehen, vielleicht schreib ich das nochmal ausführlicher und mit Scope-Bildern als visuelle Unterstützung. Ich habe im CPLD vor, diese Signale digital zu entprellen...
Gruß,
Thomas
Weil’s gerade passt, im folgenden Post habe ich die Diskette zum FC angehängt:
The Final Chesscard disketten und anleitung gesucht
Ich habe eine Wiki gefunden die andeutet dass auf PC ein nachfolger von der Final Chesscard erschienen war mit der nahme ChessMachine. Fuer die PC version von der Final Chesscard gab es disketten mit beispielen, druckertreiber, usw. lautens eine Hollandische user. Diese wurden nicht mitgeliefert fuer die C64 version.
https://chessprogramming.wikispaces.com/ChessMachine
und auf https://www.schach-computer.in…p?title=Tasc_ChessMachine wird erwahnt das es eine anderen externen version gab fuer die parallele schnitstelle https://www.schach-computer.in…Machine_-_PC_Adapterkabel
Dass wurde der druckertreiber erklaren 
