Ihr Lieben, nachdem ich die letzten Wochen mit einer Hardware-Idee für die alte Atari-Computer-Serie (8-Bit, nicht »ST«, bitte nicht so laut lachen) herum spiele und bei meinen Recherchen immer und immer wieder auf dieses Forum und diese Website gestoßen bin, wage ich jetzt mal eine Frage direkt ins Forum zu stellen. Zunächst: Es geht um den Bau eines Spiele-Moduls für die alten Computer. Im Zuge des im Moment unter Spielern grassierenden Retro-Fiebers - von dem ich auch angesteckt bin - kam mir die Idee nicht nur Spiele für die Atari-8-Bit-Computer zu programmieren, sondern diese auch wirklich richtig »zum anfassen« herzustellen. Und zu verkaufen. Das folgende ist im Moment nur eine recht wilde Idee, die ich aber so spannend finde, dass ich die letzten zwei Wochen immer mal wieder recherchiert habe. Der Speicher für so ein Modul schreit geradezu nach einem Flash-ROM-Chip. 512 Kbyte von zum Beispiel Microchip (SST39LF040) kosten so um die EUR 1,00. Mit Blick auf die Preise für 32 Kbyte OTP-ROMs ist das einfach unschlagbar günstig. Das ist sogar so günstig, dass man den Baustein selbst dann verbaut, wenn das enthaltene Spiel nur 16 oder 32 Kbyte groß ist. Um diese Menge an Speicher im Atari ansprechen zu können - das Modul belegt »nur« 16 Kbyte des Atari-Speicherbereichs - muss wiederum eine Bank-Switch-Logik her. Bliebe man bei EPROMs wären das jetzt noch zwei bis drei zusätzliche TTL-Bausteine und gut ist. Erprobte Schaltungen für so etwas gibt es zuhauf im Internet. Aber ich will ja ein Flash-ROM haben. Erste Hürde: Spannungsversorgung. Die ist im Atari 5 Volt, alle halbwegs modernen Flash-ROMs arbeiten aber mit maximal 3,3 Volt. Also muss schon mal eine Spannungswandlung sowie eine Pegel-Wandlung für die Signale auf die Platine. Dann will das Flash-ROM ja auch mal mit Inhalt versorgt werden. Da schwebt mir eine Programmierung im Atari vor. Das kann man entweder komplett per Software machen oder mit Hilfe einer State-Machine. Das alles zusammen schreit wiederum nach einem CPLD. Nach einigem Suchen bin ich auf die »ispMACH 4000«-Serie von Lattice gestoßen. Vor allem auch deshalb weil auch die aktuellsten Bausteine - »ZE« - immer noch 5-Volt-tolerante Anschlüsse haben. Und so ein »4032« mit 32 Logikelementen kostet gerade mal EUR 1,50. Außerdem ist die Software »ispLEVER Classic« umsonst zu haben. Jetzt kommt die zweite Hürde: Wie programmiert man so einen Baustein? Ich meine nicht Verilog oder VHDL oder so. Sondern ganz direkt, ganz praktisch die Hardware, den Baustein selber. Welches - logischerweise günstige - Programmiergerät benutzt man? Oder setzt man lieber auf ISP? Aber auch dafür benötigt man eine passende Software und eine wie auch immer geartete Hardware. Ich bin da ein wenig ratlos und deswegen um jeden Tipp und Link dankbar. Grüße, Henrik (Island2Live)
Henrik F. schrieb: > im Moment nur eine recht wilde Idee, die ich aber so spannend finde, Finde ich jetzt nicht so wild. Wild fand ich ein 16 MByte grosses Demo das auf einem C64 lief... Henrik F. schrieb: > Das alles zusammen schreit wiederum nach einem CPLD. Nach einigem Suchen > bin ich auf die »ispMACH 4000«-Serie von Lattice gestoßen. Vor allem > auch deshalb weil auch die aktuellsten Bausteine - »ZE« - immer noch > 5-Volt-tolerante Anschlüsse haben. Tönt durchaus vernünftig. Die werden von Lattice auch aktiv gepflegt. Die Signale vom Atari in den CPLD sind damit gegessen. Was du sehr genau ansehen musst, sind die Signale vom CPLD zum Atari, da der ispMACH4000 zwar 5 V Tolerant ist, aber keine 5 V ausgeben kann. Einfach Pull-Up Widerstände können reichen, kommt aber auf das Timing drauf an, das erreicht werden muss. Henrik F. schrieb: > Jetzt kommt die zweite Hürde: Wie programmiert man so einen Baustein? > [...] Welches - logischerweise > günstige - Programmiergerät benutzt man? Oder setzt man lieber auf ISP? > Aber auch dafür benötigt man eine passende Software und eine wie auch > immer geartete Hardware. Du könntest den Baustein vor dem Löten programmieren, würdest aber genau das gleiche Interface benutzen wie mit der In-System-Programmierung: JTAG nach IEEE 1532-Compliant In-System Programming (Datenblatt Seite 13). Zusammen mit ISPLever bietet Lattice auch eine Programmiersoftware (ispVM System) an, mit der alle Lattice Bausteine programmiert werden können zusammen mit den Programierkabeln von Lattice (Gibt es bei Lattice im online Shop). Mit ispVM kannst du auch genormte SVF Dateien (seriell-vector-format) erstellen und diese mit einem anderen JTAG Tool und entsprechend mit einem anderen, günstigeren, JTAG Kabel programmieren. Das JTAG Tool braucht dazu eine "SVF Player" Funktion. UrJTAG und OpenOCD (beide OpenSource) können das sicher. Gut möglich dass du schon ein Kabel besitzt das von denen unterstützt wird.
Christoph Z. schrieb: > Finde ich jetzt nicht so wild. Wild fand ich ein 16 MByte grosses Demo > das auf einem C64 lief... ~prust~ Ich weiß schon, warum ich die Retro-Szene so liebe. :-) Christoph Z. schrieb: > ... Was du sehr genau > ansehen musst, sind die Signale vom CPLD zum Atari, da der ispMACH4000 > zwar 5 V Tolerant ist, aber keine 5 V ausgeben kann. Einfach Pull-Up > Widerstände können reichen, kommt aber auf das Timing drauf an, das > erreicht werden muss. Hoppla, danke für den Tipp. Daran hatte ich noch gar nicht gedacht. Stimmt, die Datenleitungen vom Flash-ROM müssen ja auch noch bidirektional mit dem Atari-Port verbunden werden. ~stöhn~ Noch ein Chip mehr ... ! Christoph Z. schrieb: > ... würdest aber genau > das gleiche Interface benutzen wie mit der In-System-Programmierung: ... > > ... Zusammen mit ISPLever bietet Lattice auch eine Programmiersoftware > (ispVM System) an ... > > Mit ispVM kannst du auch genormte SVF Dateien (seriell-vector-format) > erstellen ... > > Das JTAG Tool braucht dazu eine "SVF Player" Funktion. UrJTAG und > OpenOCD (beide OpenSource) können das sicher. Gut möglich dass du schon > ein Kabel besitzt das von denen unterstützt wird. Klasse, vielen Dank für diese Hinweise. Da werde ich mal weiter forschen. Grüße, Henrik (Island2Live)
Christoph Z. schrieb: > > Das JTAG Tool braucht dazu eine "SVF Player" Funktion. UrJTAG und > OpenOCD (beide OpenSource) können das sicher. Gut möglich dass du schon > ein Kabel besitzt das von denen unterstützt wird. Vorsicht, Lattice hat dem SVF Befehlssatz einen LOOP Befehl spendiert, der dürtfte von gängigen SVF Playern nicht unterstützt sein.
Die alten 8 Bitter waren ja wirklich nicht schnell, ich glaube das was so um 1MHz. Da können die Speichertimings ja auch noch nicht so problematisch gewesen sein. Ich würde das da mal mit einem 5V PIC als Anbindung an den Adress-Datenbus probieren und an den PIC ein serielles SPI Flash anschliesen. Der Pic macht die Umsetzung, das Bankselect und das schreiben in den Speicher. Alternativ könnte man ja auch das Flash durch einen SD Karten Slot ersetzen
Jürgen D. schrieb: > Die alten 8 Bitter waren ja wirklich nicht schnell, ich glaube das > was so um 1MHz. Die 8-Bit Atari-Computer sind etwas flotter getaktet, als damals so üblich. Bei der NTSC-Version des Ataris liegt der Prozessortakt bei ziemlich genau 1,79 MHz. > Ich würde das da mal mit einem 5V PIC als Anbindung an den > Adress-Datenbus probieren und an den PIC ein serielles SPI Flash > anschliesen. > Der Pic macht die Umsetzung, das Bankselect und das schreiben in den > Speicher. Ich habe mir auch schon überlegt, anstelle eines Hardware-Interfaces für die Speicher-Logik einen Mikrocontroller einzusetzen, der die Bus-Signale des Atari einfach als Eingangs-Signale sieht und diese dann per Programm interpretiert. Allerdings muss ein PIC - oder was auch immer - trotzdem recht flott unterwegs sein. Die aktuellen Chips der 18er-Serie fangen bei 32 MHz an. Außerdem sehe ich auf die Schnelle, dass man mit denen zwar LCDs ansteuern kann, aber dedizierte I/O-Pins haben die nicht. Und davon bräuchte ich nun eine ganze Menge. Ich bin mir nicht sicher, ob man damit zurande kommt. Allerdings ist diese Aussage bezüglich der I/O-Pins natürlich auch wirklich nur auf die Schnelle getätigt; gut möglich, dass ich da etwas übersehen habe. Die ATMegas wären mir von den I/Os her deutlich sympathischer (ATMega64: 53), sind aber noch langsamer als die PICs (16 MHz). Der Vorteil wäre bei dieser Lösung, dass man den PIC/ATMega/WAI (Was Auch Immer) auch als eine Art Co-Prozessor einsetzen könnte. Sprich: Er kann Berechnungen durchführen oder ganze Datensätze für das Spiel aufbereiten - zum Beispiel Sprite-Bewegungen und so weiter - die der 6502 im Atari nicht in der Geschwindigkeit zustande bringen würde. Die Idee hat auf jeden Fall ihren Reiz. Grüße, Henrik (Island2Live)
Henrik F. schrieb: > > Die Idee hat auf jeden Fall ihren Reiz. > Hat sie, aber auch ein dickes Problem. Um einen 8 bit Wert von einer zufälligen Addresse eines seriellen SPI Flashes zu lesen braucht man 40 Takte. ( 8 bit Command, 24 bit Addresse, 8 Bit Daten), d.h. ausgehend von den 1.79 MHz einen SPI Takt von mindestens 72 MHz. Dazu muss man dann aber den Fastread benutzen, da kommt dann noch ein Dummybyte zwischen Addresse und Daten hinzu. D.h. einen SPI Takt von 86 MHz. Was eventuell ginge, wäre die 16 bzw 32 kB in den internen RAM des PIC/ATMega zu laden, und dann von dort zu bedienen. Vorrausgesetzt dieser hat genügend RAM.
Lattice User schrieb: > Henrik F. schrieb: >> >> Die Idee hat auf jeden Fall ihren Reiz. >> > > Hat sie, aber auch ein dickes Problem. > > Um einen 8 bit Wert von einer zufälligen Addresse eines seriellen SPI > Flashes zu lesen braucht man 40 Takte. ( 8 bit Command, 24 bit > Addresse, 8 Bit Daten), d.h. ausgehend von den 1.79 MHz einen SPI Takt > von mindestens 72 Mhz. ... Ich würde in dem Fall kein externes Flash-ROM verwenden, sondern den internen Speicher eines PIC/ATMega verwenden. Dann kann ich mich zwar von der Idee der 512 Kbyte verabschieden, aber 64/128 Kbyte wären immer noch drin. Und das ist für ein Spiel auf Modul für einen der alten Atari-Computer immer noch sehr üppig. Bleibt aber trotzdem noch das Problem der Taktfrequenz und der Anzahl der I/O-Pins. Ein PIC mit 40 MHz hätte pro Takt an dem Anschlussport des Ataris 22 Takte Zeit (40 / 1,79). Aber (ganz groß geschrieben): Der 6502 des Ataris teilt seinen Takt in zwei Phasen auf. Ich habe das nicht genau im Kopf, aber in der ersten Hälfte des Taktes liegen die Adressen an und in der zweiten Hälfte müssen die Daten bitteschön bereit stehen. Damit würde sich die Taktzahl noch einmal halbieren. Und nur 11 Takte um die ca. 20 Signalleitungen des Ataris aufzudröseln ... das ist trotzdem immer noch arg wenig. Die Idee mit dem Coprozessor bliebe wohl einer Lösung mit einem FPGA plus Softcore vorbehalten. Aber da sind wir schon in Sphären, die ich im Moment gar nicht so im Sinn habe. Interessant ist es natürlich trotzdem. Grüße, Henrik (Island2Live)
Henrik F. schrieb: >.., die Datenleitungen vom Flash-ROM müssen ja auch noch >bidirektional mit dem Atari-Port verbunden werden. .. In den "alten" Modulen waren idR alle Leitungen unidirektional. Ausnahme waren SRAMs auf einigen Modulen. Die kenne ich nur von z.B. Atari 2600. 5V-Toleranz: Deine Modul-Chips müssen ja nur 5V vertragen, aber bei den MOS-Bausteinen reichen 3.3V TTL/etc. zur Ansteuerung. Meinen C64/C128 steuere ich z.B. mit einem Xilinx XC9572XL an. Funktioniert problemlos.
Sigi schrieb: > Henrik F. schrieb: >>.., die Datenleitungen vom Flash-ROM müssen ja auch noch >>bidirektional mit dem Atari-Port verbunden werden. .. > > In den "alten" Modulen waren idR alle Leitungen unidirektional. > Ausnahme waren SRAMs auf einigen Modulen. Die kenne ich nur > von z.B. Atari 2600. Nope, bei meinem angedachten Modul für den Atari 800 müssen die Datenleitungen bidirektional sein. Man muss ja in das Bankumschaltungs-Register schreiben können. Also: Lesen aus dem Flash-ROM aber schreiben in das Bank-Register. Letzteres ist im Modul selbst realisiert (in meinem Fall im CPLD), aber Atari stellt an seinem Modul-Anschluss genau dafür ein Eingangs-Signal zur Verfügung (was übrigens ausgelöst wird, wenn man den im Atari ungenutzten Adressraum zwischen $D500 und $D5FF anspricht). > 5V-Toleranz: Deine Modul-Chips müssen ja nur 5V vertragen, > aber bei den MOS-Bausteinen reichen 3.3V TTL/etc. zur > Ansteuerung. Meinen C64/C128 steuere ich z.B. mit einem > Xilinx XC9572XL an. Funktioniert problemlos. Das habe ich - glaube ich - nicht ganz verstanden. Die Adressen-Leitungen für das Flash-ROM müssen doch schon mal im Pegel gewandelt werden (Flash-ROM 3,3 Volt, der Atari liefert aber 5 Volt). Oder meinst Du die Ausgangssignale, die vom Modul zurück in den Atari gehen? Die allerersten Ataris (400/800) waren noch mit TTL-Schaltkreisen aufgebaut. Ich glaube, da reichen 3,3 Volt nicht aus. Bei den späteren Geräten bin ich mir nicht sicher. Grüße, Henrik (Island2Live)
Henrik F. schrieb: > >> 5V-Toleranz: Deine Modul-Chips müssen ja nur 5V vertragen, >> aber bei den MOS-Bausteinen reichen 3.3V TTL/etc. zur >> Ansteuerung. Meinen C64/C128 steuere ich z.B. mit einem >> Xilinx XC9572XL an. Funktioniert problemlos. > > Das habe ich - glaube ich - nicht ganz verstanden. Die > Adressen-Leitungen für das Flash-ROM müssen doch schon mal im Pegel > gewandelt werden (Flash-ROM 3,3 Volt, der Atari liefert aber 5 Volt). > Oder meinst Du die Ausgangssignale, die vom Modul zurück in den Atari > gehen? Die allerersten Ataris (400/800) waren noch mit TTL-Schaltkreisen > aufgebaut. Ich glaube, da reichen 3,3 Volt nicht aus. Doch, TTL ist stark asymetrisch, der garantierte Highpegel eines TTL Bausteins bei maximaler Last ist nur 2.4V D.h. Modernes 3.3V (LVCMOS33) ist weitesgehend kompatibel mit TTL. Das Problem ist dass die Bauteile keine 5V an den Pins vertragen und dir TTL keinswegs verspricht dass bei 3.6V Schluss ist.
Henrik F. schrieb: >Das habe ich - glaube ich - nicht ganz verstanden. Die >Adressen-Leitungen für das Flash-ROM müssen doch ... Ganz einfach: im Atari sind MOS-Chips, bei denen alle IOs idR 5V TTL/oÄ sind. Deine ROMs sind dagegen 3.3V TTL/oÄ. Der CPLD wandelt also alle 5V-MOS-Outputs (ADR,RW etc.) in 3.3V-ROM-Inputs ("Durchschleifen") und die 3.3V-ROM-Outputs (DATA) werden durch den CPLD zu 3.3V-MOS-Inputs (was ja ausreicht). Zusätzlich übernimmt der CPLD die ganze Address-Logik plus von dir gewünschte Konfigurationslogik. Sowas kriegt man in einen XC9572XL bzw. MACH4064. Achtung: bei meinen C64/C128 greift der 6510 bzw. 74LS245 (Buffer) auf die Modulschnittstelle. Diese Bausteine "akzeptieren" 3.3V-Logik. Es gibt aber auch MOS-Bausteine, denen 3.3V-Logik zuwenig sind!!!
Sigi schrieb: > Es gibt aber auch MOS-Bausteine, denen 3.3V-Logik zuwenig sind!!! Das sind die CMOS Bausteine der Reihen 4000, C74, HC74, bei NMOS wie dem 6502 ist mir das noch nicht begegnet.
Sigi schrieb: > Henrik F. schrieb: >>Das habe ich - glaube ich - nicht ganz verstanden. Die >>Adressen-Leitungen für das Flash-ROM müssen doch ... > > ... und die 3.3V-ROM-Outputs (DATA) werden durch > den CPLD zu 3.3V-MOS-Inputs (was ja ausreicht). ... > > Achtung: bei meinen C64/C128 greift der 6510 bzw. 74LS245 (Buffer) > auf die Modulschnittstelle. Diese Bausteine "akzeptieren" 3.3V-Logik. > Es gibt aber auch MOS-Bausteine, denen 3.3V-Logik zuwenig sind!!! Da müsste ich wirklich mal die Datenblätter vom Atari durchsehen (die ich zum Glück noch habe) oder zur Not mal meinen alten Atari 800 aufschrauben. Immerhin ist der Computer 1978 designet worden. Der ist halt noch mal ein paar Jahre älter als der C64. Gut möglich, dass da noch 74er ohne »LS« drin sind. Bei den späteren Modellen (XL/XE/XEGS) sind aber mit Sicherheit 74LS-Bausteine drin. Grüße, Henrik (Island2Live)
Ich weiss jetzt nicht, welches Model du hast, ich habe aber mal in die Schematics eines alten 800-PAL geschaut: Der Paralelport (ich hoffer das ist der richtige) ist direkt mit dem 6502C verbunden. Datenblätter zum 6502 sagen, 3.3V ist ausreichend, der Unterschied zum 6502C ist ein zusätzliches HALT-Signal. Ob aber auch die 3.3V beim 6502C ausreicht, weiss ich jetzt nicht. Such mal nach einem PDF zur C-Version.
Sigi schrieb: > Ich weiss jetzt nicht, welches Model du hast, ich habe aber mal > in die Schematics eines alten 800-PAL geschaut: Der Paralelport > (ich hoffer das ist der richtige) ist direkt mit dem 6502C > verbunden. Datenblätter zum 6502 sagen, 3.3V ist ausreichend, > der Unterschied zum 6502C ist ein zusätzliches HALT-Signal. > Ob aber auch die 3.3V beim 6502C ausreicht, weiss ich jetzt > nicht. Such mal nach einem PDF zur C-Version. Wenn dort ein »6502C« verbaut wurde, dann ist das kein »Atari 800« sondern ein »Atari 800 XL«, also schon die Generation von mindestens 1982. Der 6502C hat eben jenen HALT-Eingang, der den Prozessor anhält und alle Pins hochohmig schaltet. Im alten Atari 800 von 1978 - ohne »XL« im Namen - wurde genau diese Logik mit jede Menge ICs um den damals verbauten 6502A (»A« für 2 MHz) nachgebildet. Dafür spricht übrigens auch, dass Du einen Parallel-Port nennst. Den gibt es im ganz alten »Atari 800« nämlich nicht. Erst der »Atari 800 XL« hatte ein »Parallel Bus Interface«, welcher alle Prozessor-Signale nach außen geführt hat. Den »6502C« sollte man übrigens auch nicht verwechseln mit der völlig anders aufgebauten CMOS-Version »65C02«. Kleiner aber entscheidender Wanderer des Buchstabens. ;-) Grüße, Henrik (Island2Live)
:
Bearbeitet durch User
Ich habe jetzt in die hoffentlich richtigen Schematics geschaut: Zwischen CPU und den beiden Game-Slots sind für Data-IOs zwei 4-Bit-Trisate-Buffer (ist schwer zu entziffern, glaube 74LS243??). In den Specs zum 74LS243 ist VI_min=2.0V, d.h. 3.3V-kompatibel, VO_typ=3.4V, ein nicht-5V-toleranter Baustein hält das sicher nicht aus. Mach4000 ist also eine gute Wahl. Ob allerdings ein 4032 gross genug ist?? Aber am Besten öffnest du mal das Gehäuse und schaust dir die Platine an. Aus Bildern im Netz schauen die Platinen nach 2-Lagigen aus. Dürfte also nicht so schwer sein. Und noch ein kleiner Tipp: für Atari2600 gibt's etliche Nachbauten von Modulen, auch welche mit SD-Card. Vlt. kannst du dir da was abschauen. Viel Spass
Lattice User schrieb: > Christoph Z. schrieb: > >> >> Das JTAG Tool braucht dazu eine "SVF Player" Funktion. UrJTAG und >> OpenOCD (beide OpenSource) können das sicher. Gut möglich dass du schon >> ein Kabel besitzt das von denen unterstützt wird. > > Vorsicht, Lattice hat dem SVF Befehlssatz einen LOOP Befehl spendiert, > der dürtfte von gängigen SVF Playern nicht unterstützt sein. Ja, das ist richtig und kann eine üble Sucherei auslösen. Hätte ich erwähnen müssen. ispVM kann aber dazu überreded werden, auf diese Erweiterung zu verzichten: "However if it's not currently supported, we suggest clicking the [Advanced] button and checking the 'Write Rev D Standard SVF file' box when generating SVF file from ispVM. This will produce a standard but slow SVF file which will work with your boundary scan devices." http://www.latticesemi.com/en/Support/AnswerDatabase/1/3/0/1307.aspx Oder in der Kommandozeile mit der Option "-revd"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.