Guten Abend, ich hatte mir vor Ewigkeiten bei Amazon einen Cyclone II FGPA-Kit gekauft. Also so einen: https://smile.amazon.de/dp/B07BVN2R7X/ (Inkl. USB-Blaster) Da das angedachte Projekt nicht umgesetzt wurde, liegt das dingen hier rum und staubt ein. Jetzt kam mir beim Googlen die Idee, darauf einen C64 zu machen. http://searle.hostei.com/grant/Multicomp/index.html#HardwareWiring Leider finde ich dazu keine wirklichen Berichte/Videos, wie gut oder wie schlecht das so läuft. Hat da einer von euch Erfahrung zu sammeln können? Bevor ich mir jetzt den Ram und alles weitere besorge, aufbaue und dann feststelle: Alles Mist... Gefordert wird nicht viel, bin kein Spieler. Vielleicht mal eine runde Kaiser oder Gianna Sisters. Ansonsten reicht es mir, wenn ich ein wenig Basic "Programmieren" kann und es läuft :-)
Wenn man C64 (insbesondere das vorzuegliche Commodore Basic) spielen will, nimmt man einen C128D. Der Cyclone II kann sicher noch wo anders recycled werden.
Peter G. schrieb: > Gefordert wird nicht viel, bin kein Spieler. Vielleicht mal eine runde > Kaiser oder Gianna Sisters. Ansonsten reicht es mir, wenn ich ein wenig > Basic "Programmieren" kann und es läuft :-) Letzteres funktioniert (habe ich mit der Z80-Version ausprobiert). Der Cyclone II schafft den Z80 mit 50 MHz ;). Ersteres kannst Du vergessen (oder musst noch einiges selbst machen). Bloß, weil die CPU dieselbe ist, wird aus dem Ding längst kein C64 - da ist ein bißchen mehr notwendig. Die Maschine realisiert einen BASIC-Rechner mit ASCII-Terminal. Mehr nicht.
Markus F. schrieb: > Ersteres kannst Du vergessen (oder musst noch einiges selbst machen). > Bloß, weil die CPU dieselbe ist, wird aus dem Ding längst kein C64 - da > ist ein bißchen mehr notwendig. > > Die Maschine realisiert einen BASIC-Rechner mit ASCII-Terminal. Mehr > nicht. Nicht das selbe Board, aber gleicher FPGA: https://www.youtube.com/watch?v=Ua-OMIwNcNs Also scheint das ja prinzipiell zu laufen.
a) Das ist ein DE1 und hat schon alles drauf was man für einen "vollständigen" Computer braucht und 18000 Luts. b) Dein Board hat nur Pins und einen C2 mit 5000 Luts. Grober Vergleich: mein Gameboy Color im FPGA braucht rund 10000 Luts. Fairerweise muss ich zugeben auch nicht auf minimalen Verbrauch geachtet zu haben, z.b. läuft mein Z80 deswegen auch auf 100 MHz. Trotzdem mal als Größenordnung. Dein Vorhaben KANN gut gehen, ist aber hart, gerade als Anfänger wo man noch nicht so gut einschätzen kann wie man LUTs spart. Dann musst du alles selbst dran basteln. Unterschätze bitte auch den Aufwand nicht. Ein fertiger Core ist eine Sache, aber wenn du wirklich etwas selbst machen willst da dran, dann sind schnell ein paar Monate weg. Das soll nicht den Spaß nehmen, denn den kann man damit definitiv haben. Nur klingt dein Beitrag nicht so als wärst du übermäßig motiviert, sondern eher als willst du mal kurz etwas zusammen basteln was noch in der Ecke liegt.
Der C64 ist ja kein Hexenwerk: der besteht nur aus ein paar Tausend Transistoren. Man müsste den 1:1 nachbauen ...
Naja Hexenwerk... hart wird es schon das in 5000 LE zu packen. - CPU - RAM - Graphic (Backgroundlayer + Sprites + Collision) - Videoausgabe(VGA oder so) - Eingabegeräte (Tastatur + Joystick) - Soundausgabe ... 1:1 Nachbau würde bedeuten mit Laufwerk, das will aber keiner, also kommt noch Massenspeicher dazu. Nur ein Beispiel: allein die 47 Grafikregister(noch ohne jegliche Funktion) anzubinden führt bei einer 1:1 Implementierung bereits zu ~500LE.
Kann man den C64 nicht auf einzelner Transistor/Gatter-Ebene nachbauen ? Gibt ein FPGA das nicht her ? Natürlich vorausgesetzt man hat die Pläne des C64...
Bla schrieb: > Kann man den C64 nicht auf einzelner Transistor/Gatter-Ebene nachbauen ? > Gibt ein FPGA das nicht her ? Natürlich vorausgesetzt man hat die Pläne > des C64... Ja klar. Aber nicht auf einem Cyclone II. Hier: http://www.fpgasid.de/documentation wird **nur** der SID implementiert. Auf einem MAX10. Und der ist voll...
Peter Bierbach schrieb: > Schau dir diesen Core an für den MiSTer : > > https://github.com/MiSTer-devel/C64_MiSTer Interessant ... ich wüsste nichtmal wie man das Boot-Dings irgendwo auf die SD-Karte bekommt :-) Das wird da sehr oberflächlich, also nur für Vollstudierte erklärt.
Beim Mister wird leider fast nirgends irgend etwas erklärt, das ist immer für Anwender geschrieben die von FPGAs eh keiner Ahnung haben. Das "Boot-Dings" ist ein rbf das von dem integrierten ARM im Mister-FPGA den FPGA-Teil konfiguriert, so eine Art JTAG Player. Das hilft hierfür garnix, weil es ein Binary für das Cyclone 5 FPGA ist. Man muss dann also den Core neu bauen. Die sourcen sind da, sollte prinzipiell gehen. Dann kommt leider die zweite Schwachstelle beim Mister auf, die wieder den gleichen Grund hat: die interessiert einfach nicht der Core selbst, sondern nur das er auf dem Mister läuft. Dementsprechend sind FPGA-Typ(Cyclone 5) spezifische Konstrukte im Code. Instantierungen statt Inferierungen usw. Hier geht das noch einigermaßen, weil man wenigstens bei Altera bleibt. Beschäftigen muss man sich damit trotzdem bevor man überhaupt einmal bauen kann um zu sehen ob es reinpasst.
Bla schrieb: > Kann man den C64 nicht auf einzelner Transistor/Gatter-Ebene nachbauen ? > Gibt ein FPGA das nicht her ? Natürlich vorausgesetzt man hat die Pläne > des C64... Die Plände sind da und bekannt. Aber ein FPGA ist eine digitale Schaltung mit der man keine Transistoren nachbauen kann. Höchstens Gleichungen die deren Funktionen beschreiben. Das ist aber auch gar nicht nötig. alles was den C64 zu einem Computer macht, ist digital und damit nachbildbar. Ist nur eine Frage, der FPGA-Grösse. In einen mittleren ARIA müsste ein C64 reingehen. Inklusive Bildschirmspeicher.
Muss es ein c64 sein? Wir basteln aus diesem Board gerade einen kleinen Computer mit vga Ausgang, Tastatur Eingang, SD Karte usw
Andreas R. schrieb: > Wir basteln aus diesem Board gerade einen kleinen Computer Magst du dazu mehr erzählen?
Elbi schrieb: > Die Plände sind da und bekannt. "Pläne" war gemeint! Neugierig schrieb: > Magst du dazu mehr erzählen? +1
Ist nix dolles. Wir sind paar Computerbastler, die sich aus verschiedenen Gründen ins Thema fpga einarbeiten wollen. Ein Teilprojekt war also das Schreiben einer CPU z.B. Ein anderes war das Schreiben eines vga Controllers. Usw. Um die Einstiegsalhürde niedrig zu halten (= billiges Board), aber andererseits ein Board zu haben, welches leicht zu programmieren ist (Quartus und USB Blaster), fiel die Wahl auf diese billigen cyc2 Boards von eBay und Co. Da ihnen ja aber viele Anschlüsse fehlen, ist eine der ersten Aufgaben das Basteln eines Shields (wie ein Arduino Shield halt), welcher die Anschlüsse sowie noch etwas Ram enthält. Das war es schon. Edit: einer der 2 ersten Prototypen: https://m.imgur.com/a/E8h6NLE
:
Bearbeitet durch User
Wenn ihr Spaß am Basteln habt, dann nur zu. Ansonsten kann ich auch die PMOD Boards von Digilent empfehlen. Sind jetzt nicht so teuer und eigentlich für jede Anschlussmöglichkeit (PS2, SDCard, Seriell) die ihr nutzt verfügbar. Besonders interessant natürlich zum Einstieg, wenn man Fehlerquellen ausschließen will. Eine eigene CPU ist ein guter Einstieg, weil mal viel über FPGAs dabei lernen kann und auch über die Umwelt -> Peripherie anschließen, Daten rein und raus bekommen, Timings einhalten, Ressourcenbedarf, Blockrams, DPS Blöcke, Memory Controller.... Außerdem macht es einfach Spaß sich seinen eigenen Rechner zu bauen! Das erste Pong(oder was auch immer) auf der eigenen CPU, mit eigener Grafikausgabe fühlt sich großartig an.
Nur so ne Idee: Wenn man mehrer der Boards hat, könnte man die vielleicht zusammenschalten. Dann könnte das mit dem C64 funktionieren. Mit 5000LUTs wird das wahrscheinlich nicht funktionieren... der 6502 benötigt schon ca. 1200LUTs. An den VIC möchte ich garnicht denken.
... schrieb: > (insbesondere das vorzuegliche Commodore Basic) Ist das ein Scherz? Das Schneider CPC Basic war super..aber das vom C64? würg Alleine diese Beispiele..das C64 BAsic war ein Witz..leider https://www.youtube.com/watch?v=w573z3qiyoU
Gegeg J. schrieb: > ... schrieb: >> (insbesondere das vorzuegliche Commodore Basic) > > Ist das ein Scherz? > Das Schneider CPC Basic war super..aber das vom C64? würg > > Alleine diese Beispiele..das C64 BAsic war ein Witz..leider > https://www.youtube.com/watch?v=w573z3qiyoU Da gebe ich dir vollkommen recht, ABER... wäre dieses 64er Basic besser gewesen, dann hätte so manch einer nie mit Assembler angefangen. So gesehen bin ich aus heutiger Sicht Commodore dankbar das dieses Basic so Sch... war und die einen mehr oder weniger dazu getrieben haben tiefer unter die Haube zu Glotzen. ;) Gruß
Frickel F. schrieb: > oder weniger dazu getrieben haben tiefer > unter die Haube zu Glotzen. Wäre durchaus interessant, das zu untersuchen! --- ob z.B die Nutzer des Sinclair Spektrum oder des ZX81 mehr (oder weniger) in ASM eingestiegen sind. Was ich sagen kann, ist, dass die Apalle 2e-Nutzer in der Richtung wenig gemacht haben. Gegeg J. schrieb: > Das Schneider CPC Basic war super..aber das vom C64? würg Ich erinnere an das legendäre Simon's Basic! Läuft das eigentlich auch auf den FPGA-C64-Clones? Ich hätte da noch (auf dem Matrixdrucker ausgedruckte!!) Algorithmen dafür.
Bonzo schrieb: > > Wäre durchaus interessant, das zu untersuchen! --- ob z.B die Nutzer des > Sinclair Spektrum oder des ZX81 mehr (oder weniger) in ASM eingestiegen > sind. Weiß nicht, könnte man das eventuell an den Verkaufszahlen oder an der verfügbaren Software bewerten? Wäre wirklich interessant zu wissen. So genau habe ich mir dazu noch keine Gedanken gemacht. > Was ich sagen kann, ist, dass die Apalle 2e-Nutzer in der Richtung wenig > gemacht haben. Kann ich nicht beurteilen, dazu hatte ich nie Kontakt. > Ich erinnere an das legendäre Simon's Basic! > > Läuft das eigentlich auch auf den FPGA-C64-Clones? Da gehe ich ganz stark von aus, alles was ich biss heute an Emus und FPGA Implementationen gesehen habe waren sehr sehr kompatibel, wen es bei FPGA Cores Probleme gab, dann zu einem großen teil beim VIC oder SID. Und ich sag mal so, die eigentliche Herausforderung ist nicht den Core 100% nach Buch korrekt zu Implementieren, sondern die Bugs und Nadelöhre von der originalen Hardware hin zu bekommen. Gruß
Bei einem Basic würde ich mir da wenig Sorgen machen, zumindest solange man die Programme neu schreibt. Schwierig sind eher Spiele, die "Features" ausnutzen die nicht dokumentiert sind, z.b. mit Tricks außerhalb der Ränder zu arbeiten. Mit Abstand der schwierigste Teil ist aber das "Beam Racing": cyclengenaue Programmierung, die genau dann klappt, wenn man auf den Takt genau zum richtigen Zeitpunkt ein Register schreibt, z.b. um ein Sprite umzusetzen oder Farben zu ändern. Wenn man hier auch nur minimale Unterschiede im Emulator/Nachbau hat, dann gibt es mindestens Grafik- oder Soundfehler, teilweise crashen die Spiele aber auch, weil genau mit diesem Timing gerechnet wurde. Das im Emulator nach zubauen ist der schwierigste Teil, weil man alle Eigenheiten, die eventuell eine Verzögerung oder auch eine Beschleunigung mit sich bringen können, nachbauen muss. Beim C64 habe ich aktuell keine Zahlen, aber mal welche zum Gameboy Advance. Dort gibt es eine Testsuite, welche mit der Original Hardware entwickelt wurde. Enthalten sind alleine 1560(!) Tests nur für Timing. Der aktuell genaueste Emulator erfüllt davon "nur" 1474.
Robert P. schrieb: > Mit Abstand der schwierigste Teil ist aber das "Beam Racing": > cyclengenaue Programmierung, die genau dann klappt, wenn man auf den > Takt genau zum richtigen Zeitpunkt ein Register schreibt, z.b. um ein > Sprite umzusetzen oder Farben zu ändern. > Beim C64 habe ich aktuell keine Zahlen, aber mal welche zum Gameboy > Advance. Dort gibt es eine Testsuite, welche mit der Original Hardware > entwickelt wurde. Enthalten sind alleine 1560(!) Tests nur für Timing. > Der aktuell genaueste Emulator erfüllt davon "nur" 1474. Jajaja, beim GameBoy ist Beam Racing besonders tricky, weil es beim Gameboy als Gerät mit LCD-Display keinen Beam gibt ... Und das C64 PAL/NTSC Display timing baut auch kein Emulator nach, weil heutzutage keine Displays mit diesen Timings arbeiten, bzw keiner mit dem 50 Hz Geflimmre spielen oder gar arbeiten will. http://hitmen.c02.at/temp/palstuff/ Beim Sound mag das anders sein: https://www.youtube.com/watch?v=dvmSpZWW45k
C. A. Rotwang schrieb: > Jajaja, beim GameBoy ist Beam Racing besonders tricky, weil es beim > Gameboy als Gerät mit LCD-Display keinen Beam gibt ... > > Und das C64 PAL/NTSC Display timing baut auch kein Emulator nach, weil > heutzutage keine Displays mit diesen Timings arbeiten, bzw keiner mit > dem 50 Hz Geflimmre spielen oder gar arbeiten will. Das Timing muss ein Emulator nachbauen (selbst wenn der 'echte' Bildschirm nicht mit 35 kHz angesteuert wird), sonst läuft die meiste Software nicht. Im ST beispielsweise hat Atari (wohl unbeabsichtigt) einen 'Hardwarefehler' eingebaut, der es erlaubt, in die Overscan-Ränder zu zeichnen, wenn man zum geeigneten Zeitpunkt innerhalb der Bildschirmzeile die Bildschirmauflösung umschaltet. Es gibt etliche Software, die das nutzt - ein Emulator, der das nicht weiss und beherrscht, ist nicht ernst zu nehmen. Mittlerweile gibt es Emulatoren, die selbst die Röhrenverzerrung und Nachleuchten von CRTs auf TFTs abbilden.
Markus F. schrieb: > Das Timing muss ein Emulator nachbauen (selbst wenn der 'echte' > Bildschirm nicht mit 35 kHz angesteuert wird), sonst läuft die meiste > Software nicht. Genau so ist es auch mit FPGA Cores, der Minimig (Amiga500) zum Bleistift hat einen VGA-Out und das Bild muss erst durch einen Framebuffer wo das Timing angepasst wird. Ansonsten gäbe es so gut wie keine Glozte mehr mit dem man sich was anschauen könnte. Mir ist auch biss heute kein Core untergekommen bei dem das anders wäre. Gruß
Markus F. schrieb: > Mittlerweile gibt es Emulatoren, die selbst die Röhrenverzerrung und > Nachleuchten von CRTs auf TFTs abbilden. Ja, das ist ein Beispiel wo das ganze Retrocomputing-Zeuchs in die falsche weil Anwender-feindlicher Richtung abdriftet. Retrocomputing, wie C64 Nachbau, meint die Usererfahrung aus alten Tagen durch Laufenlassen originaler binaries auf moderner Hardware weitgehend oder besser zurück zu bringen. Komplettes Wiederholen der Jugenderfahrung geht ohnehin nicht, weil der User von heute 50 ist und so nicht mehr derselbe 15 Jährige vor dem C64 damals. Und Ladezeiten vom Tape von 10 Minuten+ braucht auch heute keiner mehr, die alten binaries sollen gefälligst flott von SDCard o.ä. geladen werden. Und ich frag mich grad, ob ein Actiongame, das auf 50 fps ausgelegt ist, also höchsten aller 20 ms eine neue Spielsituation präsentiert, genaus gesteuert werden kann, wie eine Emulation die 60 fps, und damit alle 17 ms eine neue Situation darstellt. Dieses Nutzererlebniss durch sklavisches Nachprogrammieren, resp. Emulieren der Kathodenstrahlmonitortechnik mit seinem Timings in moderner Hardware nachzustellen ist IMHO die falsche Herausforderung. Man kann die selbe Darstellung (oder sogar eine bessere, augenschonendere) der "Grafiktricks" auch anders erreichen, bspw. in dem man einen neuen Graphikmodus einbaut, dessen erweiterte Möglichkeiten (bspw. der erwähnte Overscanbereich) nicht aktiv sind, wenn der Trick ausgeführt wird. Dazu muss man lediglich die FSM um eine Transition erweitern, die testet ob auf das Steuerregisterzugriffen wird, wenn der Zeitpunkt hsync+xpos erreicht wird. Und wenn ich mir grad auf youtube ein Amiga-demo von damals reinziehe, dann kommt das dem Erleben von 1990 sehr nahe auch wenns ein Video auf einem TFT-Monitor von 2019 ist: https://www.youtube.com/watch?v=sg3luHPd_1g
C. A. Rotwang schrieb: > Jajaja, beim GameBoy ist Beam Racing besonders tricky, weil es beim > Gameboy als Gerät mit LCD-Display keinen Beam gibt ... Ob du das nun Beam nennst oder sonstwie ist doch egal. Auch auf dem LCD wird alle paar µs ein Pixel ausgegeben in der gleichen Art und Weise wie man das für ein CRT machen würde: Immer eine Zeile, HBlank, nächste Zeile, am Ende VBlank. Und ja, das MUSST du möglichst genau nachbauen, weil die Spiele die aktuelle VPos prüfen, teilweise einen Interrupt auf HBlank nutzen und dann z.b. ein paar zig Takte Zeit haben die Sprites für die nächste Zeile zu setzen. Meistens gibt es ohnehin einen direkten Zusammenhang zwischen CPU Takt und Pixeltakt, d.h. die Prozessoren sind extra so getaktet um genau solche Tricks zu erlauben. Hast du dann im Nachbau auch nur kleinste Abweichungen kann sonstwas passieren. Z.b. wenn ein Spiel einen Interrupt in einem bestimmten Takt erwartet und natürlich NICHT die Register im Interrupt adäquat sichert, weil man ja garantiert immer in GENAU diesem Cycle den IRQ bekommt und deswegen weiß, das man Register xy nicht sichern muss.
Robert P. schrieb: > Z.b. wenn ein Spiel einen Interrupt in einem bestimmten Takt erwartet > und natürlich NICHT die Register im Interrupt adäquat sichert, weil man > ja garantiert immer in GENAU diesem Cycle den IRQ bekommt und deswegen > weiß, das man Register xy nicht sichern muss. Abgesehen von den Inhaltlichen Widerspruchen wie "Warten auf Interrupt" (IRQ ist geread der Antagonist zum Pollen/Warten, und wenn man nicht Inteterupten will dann disabled man diesen partikulären I-Vector) interessieren bei einem Nachbau der Hardware auf einem FPGA Programierdetails eher nicht. Die Hardware ist bei Sichern/nichtsichern der Regs dieselbe.
C. A. Rotwang schrieb: > Abgesehen von den Inhaltlichen Widerspruchen wie "Warten auf Interrupt" > (IRQ ist geread der Antagonist zum Pollen/Warten, und wenn man nicht > Inteterupten will dann disabled man diesen partikulären I-Vector) Das ist wohl unglücklich ausgedrückt. Die oben angesprochenen Routinen machen trotzdem ziemlich genau das: mit abgezählten Taktzyklen warten, um genau zum richtigen Zeitpunkt vor dem horizontal blank Interrupt irgendwas zu tun. Wollte man das nicht, bräuchte man einen zum HBL synchronen Timer-Interrupt, der in der Lage sein müsste, zum passenden Zeitpunkt mit der passenden Priorität auszulösen.
:
Bearbeitet durch User
C. A. Rotwang schrieb: > Und ich frag mich grad, ob ein Actiongame, das auf 50 fps ausgelegt ist, > also höchsten aller 20 ms eine neue Spielsituation präsentiert, genaus > gesteuert werden kann, wie eine Emulation die 60 fps, und damit alle 17 > ms eine neue Situation darstellt. Man lässt eben im Emu alles 20% schneller laufen und spielt etwas schneller, wobei es wohl zweckmäßiger wäre, wenn für den 50-jährigen, den du zitierst, alles 20% langsamer liefe :-) Vlt wäre ein tunarer C64 auch eine Option? Aber mal im Ernst: Wo ist das Problem, einen 320x200 Bildausschnitt mit einer Verfünffachung auf 1600x1000 zu bringen und in ein HD-Bild mit 50Hz einzupassen? Soweit ich recherchiert habe, lag der Videotakt beim C-64 bei 7,88MHz. Es braucht also einen Taktfrequenz von 39,4MHz. Die kriegt man auf einem Videotaktsystem für HDMI (27,000 MHz) mit 54 / 37 recht gut hin. Doe PLL muss dann eben 1,5GHz machen. Wenn der Cylcone das nicht kann, dann mit etwas mehr Platzverschwendung auch gerne 1:4 und Taktfrequenz 31,52. Zu erzielen mit 27MHz x 7/6. Oder, man steuert einen alten 4:3 an, z.B. 1600x1200 mit 200 Leerzeilen. Takt 162 MHz x 9 = 1458 / 37 = 39,400xx. Pixel x 5 -> 1600 x 1000. Bzw. die 162MHz aus einer 27er mit parallelem Pfad.
C. A. Rotwang schrieb: > Abgesehen von den Inhaltlichen Widerspruchen wie "Warten auf Interrupt" Ein Widerspruch ist es nur, wenn man das Wort nicht ausschreibt. Ich schrieb "erwarten" und nicht warten. Der Programmierer des Spiels erwartet, durch taktgenaue Programmierung, das seine Routine bis Zeitpunkt X fertig ist, weil im Zeitpunkt x+1 der Interrupt kommt. Das weiß er schon. Und weil er das weiß, sichert er in der Interrupt Routine nicht alle Register, die er im Interrupt nutzt, weil er weiß das diese nicht erhalten werden müssen. Womit er nicht gerechnet hat: 20 Jahre später will jemand die gleiche Software auf anderer Hardware ausführen. Und er rechnet auch nicht damit, das z.b. sein Speicherzugriff exakte Timings hatte, der Nachbau aber nicht. Den Prozessor einzeln nachzubauen mit exaktem Timing ist schon eine Nummer für sich. Mag beim 6502 noch gehen. Nur muss man auch nachbauen wie lange Zugriffe auf Speicher, Register usw brauchen. Teilweise z.b. auch abhängig davon ob der Grafikchip auch gerade auf den Speicher zugreift oder andere Feinheiten. Das hat halt die Programmierer damals nicht interessiert, die haben sich auf ihre Hardware verlassen. Ist ja auch ok. Trotzdem führt es dazu, dass in einem Nachbau die Software teilweise falsch rechnet wenn man nicht 100%ig taktgenau nachbaut. Für den C64 kenne ich keine Details, beim Gameboy(Z80) sieht es z.b. so aus, das die Original Dokumente zum Timing nicht genau genug sind, weil sie nur auf Vielfache von 4 eingehen (NOP = 4 Takte, usw). Die wirklich genauen Emulatoren ohne Fehler aber auch noch intern nachbilden müssen was genau in den Einzeltakten passiert, weil z.b. ein Schreibzugriff der 8 Takte braucht, auf den Speicher je nach sonstigen Umständen während des 6ten oder 7ten der 8 Takte zugreift. Glaub mir, ich hätte bei meinem Emulator/Nachbau liebend gerne auf solche Feinheiten verzichtet, nur funktioniert die Software dann halt nicht wie Original. Ich tue das also nicht aus Nostalgie, sondern weil es sein muss, obwohl ich es hasse wie die Pest, weil es Unmengen an Zeit frisst und es keine vernünftige Doku dazu gibt. Bildverarbeiter schrieb: > Man lässt eben im Emu alles 20% schneller laufen und spielt etwas > schneller, wobei es wohl zweckmäßiger wäre, wenn für den 50-jährigen, > den du zitierst, alles 20% langsamer liefe Das ist auch eine der wenigen Optionen. Alternativ kann man auch auf 30 FPS runter gehen und jedes Bild doppelt anzeigen. Besser wäre aber gleich 50 Hz auszugeben, machen viele TFTs auch mit. Einfach asynchron laufen lassen wird definitiv beim C64 oder vergleichbar alten Computern/Konsolen nix. So richtig gut klappt das erst mit CPUs mit Pipeline und DRAM, wo sich die Programmierer nicht mehr auf Ausführungszeiten verlassen konnten. Bestes Beispiel sind die X86 Nachbauten. Hier war von jeher fast jedem klar, das man sich nicht auf zyklengenaue Programmierung verlassen kann. Die Folge ist, das ein Nachbau ungenau werden kann, was das Timing angeht, solange er nur richtig rechnet.
Robert P. schrieb: > Einfach asynchron laufen lassen wird definitiv beim C64 oder > vergleichbar alten Computern/Konsolen nix. Wo du davon sprichst, dass Programmierer Taktgenauigkeit vorausgesetzt hatten: Ja, das hatte ich auch. ASM-Routinen genau so lange, dass sie rechtzeit fertig wurden, NOPs ohne Ende reingestopft, dass Schüsse und Spieler gleichmässig vorwaert kamen, Szenen gerade so eben ruckelfrei liefen und Bildschirmupdates immer zur Szene passten. Dazu musste der Zeileninterrupt mit dem loop passen, immer irgenwie 3 INT per Game-Loop. Ich glaube, dass man ohne einen Vergleichs-C64 zum Testen es kaum schafft, den sample-genau nachzubauen.
Naja, das Problem hat wohl vor allem der Erste der es macht. Sobald es einen funktionierenden (opensource) Emulator gibt kann man davon abkucken. Eine Methode ist z.b. den Zustand des Systems(alle CPU Register, ProgramCounter, Pixelposition, abgelaufene Cycles usw) einmal pro CPU Instruktion in eine Zeile einer Datei raus zu schreiben. Das selbe macht man dann für seinen Nachbau und kann hinterher ein Diff machen und schauen ob man einen Fehler gemacht hat und weiß sofort wo und wie es richtig sein muss. Wenn man das Konsequent macht und alle Dinge die man sich nicht erklären kann erstmal einbaut, sich aber aufschreibt für später, dann wird der eigene Emulator erstmal genauso gut, weil cyclegenau identisch. Hinterher kann man dann alle Unstimmigkeiten nochmal anschauen und ggf. war eine davon ja ein Fehler. So wird es nicht nur eine billige Kopie, sondern hat tatsächlich einen Gewinn für alle. --- Ansonsten gibt es noch Testroms, welche geprüft auf der Originalhardware richtig rechnen und gegen die man Testen kann. Z.b. hier http://visual6502.org/wiki/index.php?title=6502TestPrograms --- Wenn wir hier schon solange reden: wir können gerne einen Community C64 Nachbau in VHDL zusammen machen. Ich würde mich für den 6502 Nachbau oder den VIC-2 Nachbau zur Verfügung stellen, die beiden Teile würde ich mir zutrauen. Wenn sich noch 2-3 andere finden...
Robert P. schrieb: > Wenn wir hier schon solange reden: wir können gerne einen Community C64 > Nachbau in VHDL zusammen machen. > Ich würde mich für den 6502 Nachbau oder den VIC-2 Nachbau zur Verfügung > stellen, die beiden Teile würde ich mir zutrauen. Naja das ist der billigste Teil der Arbeit, der 6502 ist so oft nachgebaut worden, da genügt ein wrapper und fertig ist. Und da man nur wenig ressourcen braucht für diese Spar-CPU braucht muss man sich auch nicht besonders Anstrengen das ganze in einen kleinen FPGA zu quetschen. Wenn man sich an einen Nachbau macht, dann IMHO an einem für den es auch produktive Anwendungen gab/gibt wie ein 68020 (und Brüder) den es nicht nur in Daddelkisten sondern auch für Workstations (SUN) und embedded gab. Damit könnte man auch einiges An teurer Geräten mit neuen und dank FPGA-technik erweitbaren Prozessorboards versehen. Ich hab da hier einen alten Logicanalyzer mit so einem aus dieser Prozessorfamilie rumzustehen. https://en.wikipedia.org/wiki/Motorola_68020#Usage Oder wie wärs es mit einer Amiga basierenden Video-effekt Maschine, wie den Newtek videotoaster https://en.wikipedia.org/wiki/Video_Toaster das wäre was für timing masochisten.. Oder eine SUN-1 workstation mit 68000 und propietärer CPU. Bei so einer UNIX-Kiste ist die Wahrscheinlichkeitwohl auch höher ,das man das Graphiksystem Kopfschmerzärmer an heutige Monitore angepasst bekommt, als beispielsweise beim Commodore-Amiga mit seiner UMA-Architektur https://de.wikipedia.org/wiki/Unified_Memory_Architecture
Robert P. schrieb: > Womit er nicht gerechnet hat: 20 Jahre später will jemand die gleiche > Software auf anderer Hardware ausführen. Und er rechnet auch nicht > damit, das z.b. sein Speicherzugriff exakte Timings hatte, der Nachbau > aber nicht. Nich erst 20 Jahre später, das Problem gab es schon zwischen den selben Computertypen für den USA- (NTSC) und europäischen (PAL) Markt: http://unusedino.de/ec64/technical/misc/vic656x/pal-ntsc.html > Den Prozessor einzeln nachzubauen mit exaktem Timing ist schon eine > Nummer für sich. Mag beim 6502 noch gehen. Nur muss man auch nachbauen > wie lange Zugriffe auf Speicher, Register usw brauchen. Nein muss man nicht, beim Minimic wird beispielsweise ein MC68SEC000 eingesetzt der mit SRAMS statt mit den originalen DRAMS (?) arbeitet. Cyclegenaue Nachbildung genügt und selbst das ist in vielen bereichen unnötig (Tastaturcontroller CIA 6526, erst recht wenn man ohnehin keine originale Tastatur anklemmt, sondern eine heute verfügbare: https://8bit-museum.de/das-mist-board-klassische-computer-per-fpga-neu-implementiert/
C. A. Rotwang schrieb: > Nein muss man nicht, beim Minimic wird beispielsweise ein MC68SEC000 > eingesetzt der mit SRAMS statt mit den originalen DRAMS (?) arbeitet. Und ich setze beim VHDL Gameboy auf 100Mhz SDRAM statt des originalen 1 Mhz SRAMs und es ist trotzdem Cyclegenau. PC Emulatoren haben teilweise Latenzen von Millisekunden wenn das OS mal wieder was will und können trotzdem cyclegenau sein. Ja wie soll das nur gehen? Bitte schau dir erstmal an wie man einen Emulator cyclegenau macht und was das wirklich bedeutet....dann kannst du auch mitmachen bei diesem Punkt: C. A. Rotwang schrieb: > Naja das ist der billigste Teil der Arbeit, der 6502 ist so oft > nachgebaut worden, da genügt ein wrapper und fertig ist. Perfekt, dann liefer du doch bitte den 6502 als royalty free VHDL code. Ich hätte gerne eine Variante die 100 MHz in einem Cyclone/Spartan schafft. Dann bau ich den VIC-2 nach und wir haben schon 30-40% fertig.
Robert P. schrieb: > C. A. Rotwang schrieb: >> Naja das ist der billigste Teil der Arbeit, der 6502 ist so oft >> nachgebaut worden, da genügt ein wrapper und fertig ist. > > Perfekt, dann liefer du doch bitte den 6502 als royalty free VHDL code. > Ich hätte gerne eine Variante die 100 MHz in einem Cyclone/Spartan > schafft. > > Dann bau ich den VIC-2 nach und wir haben schon 30-40% fertig. Wie bereits oben gesagt, 8bit ist für mich nicht interessant weil ich keine technische Herausforderung mehr darin sehe. VHDL für die CPU findet sich dort: https://github.com/bernardo-andreeti/6502 Eine FPGA-Implementierung für den VIC II wird dort ausführlich besprochen: http://c64onfpga.blogspot.com/2018/01/designing-vic-ii-core.html Its zwar Verilog, aber wenn man darunter liegende Hardware-Interface verstanden hat (RAM-Interface, logische Verknüpfung von Pixel) ist es ein leichtes Code auf RTL-Ebene (Register-Transfer-Level) in einer beliebigen RTL dafür zu schreiben; Jeri Ellsworth hat viel vor über einen Jahrzehnt einiges auf CPLD (ABEL,AHDL) für den Brotkasten gemacht aber leider die Codes verschmissen. Stichwort C-One, im Umfeld dieser FPGA-Retrokiste ist auch einiges zu finden das für Privatanwender kostenfrei ist. https://www.syntiac.com/c_one.html
> C. A. Rotwang schrieb: > Perfekt, dann liefer du doch bitte den 6502 als royalty free VHDL code. > Ich hätte gerne eine Variante die 100 MHz in einem Cyclone/Spartan > schafft. Ich hatte seiner zeit einen 6502 von OpenCores benutzt, der war cyclegenau hat aber keine Illegalen OP-Codes unterstützt. > Dann bau ich den VIC-2 nach und wir haben schon 30-40% fertig. Dein Optimismus in allen ehren, aber dagegen ist die CPU ein totaler klaks. Der olle VIC hat es echt in sich, alleine immer wieder Domos und Intros zu Starten um zu schauen ob alles 100% passt, dafür geht wesentlich mehr zeit drauf als den Code zu Pinseln. Beim Minimig und auch beim C64 Core die ich verfolgt hatte, waren sehr sehr viel Leute dran beteiligt die Bugs meldeten, das ging über viele Jahre und die Fix-Listen sind ewig lang. Alleine das wird hier im Forum schon scheitern weil es hier nicht genug Retro Freaks gibt. Kannst ja mal als Vorgeschmack in die Quellen vom Minimig oder Mist schauen was da im laufe der zeit gefixt wurde, ich bin mir sicher das wird dein Optimismus drastisch bremsen. ;) Damit keine Missverständnisse aufkommen, der Minimig oder der Mist sind eigentlich für Amigas gedacht, aber es gab/gibt da auch einige C64 Cores für. Gruß
:
Bearbeitet durch User
Auf forum64.de gibt es paar Leute, die an solchen Sachen arbeiten. Sowohl 6502 als auch vic2 auf FPGA.
Andreas R. schrieb: > Auf forum64.de gibt es paar Leute, die an solchen Sachen arbeiten. > Sowohl 6502 als auch vic2 auf FPGA. Oder auch auf a1k.org oder im minimig.net.
Klar gibt es fertige Cores/Systeme. Das heißt aber nicht, das man deswegen nicht neu anfangen sollte. Im Gegensatz zum Job kann man sich im Hobby den Luxus erlauben ein altes Projekt einfach liegen zu lassen und völlig frisch zu starten. Das kann durchaus von Vorteil sein. Sagt ja keiner das sofort jede noch so verrückte Demo ohne Grafikfehler laufen MUSS. Eine Kompatibilität für den "Basic-Modus" und die wichtigsten Spiele wäre doch schon mal ein Anfang und sicher nicht so kompliziert wenn man mit anderen Emulatoren schon Erfahrung gesammelt hat. Ich sehe aber dass das Interesse eher gering ist, also werden wir wohl kein Team aufbringen.
Robert P. schrieb: > Ich sehe aber dass das Interesse eher gering ist, also werden wir wohl > kein Team aufbringen. Viele erfolgreiche Projekte haben als One-Man-Show angefangen. Fang' an, befolge publish early, publish often, stell' deine Fragen hier rein mit dem Code, dann hast du eine Chance, dass jemand mit macht. Kann natürlich auch im Sand verlaufen ;-)
Robert P. schrieb: > Ich sehe aber dass das Interesse eher gering ist, also werden wir wohl > kein Team aufbringen. Wir diskutieren in einer forum64 Konversation jeden Tag ein Projekt um einen Shield auf ein cyclone 2 Board zu bringen. Da wurden jetzt schon 3 CPUs gebaut, VGA out uvm. Also Interesse an FPGA-Bastelei ist durchaus da. Wenn Du Dir das anschauen magst, sag Bescheid. Ciao, Andreas
Robert P. schrieb: > Klar gibt es fertige Cores/Systeme. Das heißt aber nicht, das man > deswegen nicht neu anfangen sollte. > Im Gegensatz zum Job kann man sich im Hobby den Luxus erlauben ein altes > Projekt einfach liegen zu lassen und völlig frisch zu starten. Das kann > durchaus von Vorteil sein. > > Sagt ja keiner das sofort jede noch so verrückte Demo ohne Grafikfehler > laufen MUSS. Eine Kompatibilität für den "Basic-Modus" und die > wichtigsten Spiele wäre doch schon mal ein Anfang und sicher nicht so > kompliziert wenn man mit anderen Emulatoren schon Erfahrung gesammelt > hat. BITTE, lass dich wegen mir davon bloß nicht abringen!!! > Ich sehe aber dass das Interesse eher gering ist, also werden wir wohl > kein Team aufbringen. 2⁵ schrieb: > Viele erfolgreiche Projekte haben als One-Man-Show angefangen. Bingo!
Ich habe den Thread nicht aufgemacht, habe mich nur angeboten zu unterstützen mit den Teilen die ich mir zutraue. Mit Floppy/Tape und Sound kann ich gar nichts anfangen und habe auch keine Lust mich da einzuarbeiten, deswegen nicht als Einzelner.
Hi, der komplette C64 auf einem FPGA geht sogar als ein-Mann Projekt. Gideon hat das mit dem Ultimate64 bewiesen. Der steht bei mir und spielt alle Demos und Spiele ab die ich für den C64 kenne. Mit HDMI und DualSID. Nur auf einem Cyclone II wird das nix. Der ist aber gut um einfach mal in den 6502 drauf zu schreiben, 8KB Ram und 4KB Rom haben auch noch drauf Platz. Sowas kann sehr interessant und lehrreich sein. Ich hab auch so angefangen. ;) Gruß Tom
Also falls der Cyclone II genug LE's hat, bekommt man dort locker einen C64 rein. Jeri Ellsworth's Prototyp für dn C64DTV besaß sogar nur einen Cyclone I, und selbst der reichte für einen halbwegs funktionierenden C64 Clone samt DMA, Blitter, 256 Farben, Burst Mode etc.. Den FPGA64 hatte ich schon auf dem Altera DE1 am laufen, momentan arbeite ich aber an einer eigenen Implementation. CIA (viele Timing Tests funktionieren schon), CPU (plus alle undokumentierten Opcodes) und SID (8580R5 plus digitaler State Variable Filter) sind schon soweit, es fehlen lediglich noch der VIC-II und die ganze Logik drumherum. Achja, und natürlich muss ich noch einen SDRAM Controller entwickeln, in der Richtung habe ich derzeit noch nicht viel gemacht, wird aber auch noch denke ich.
Rayne: wir binden im f64 Thread gerade 512 kb SRAM an. Das ist viel einfacher anzusteuern und müsste Dir doch auch reichen?
Da läuft viel Sch... auf den Crowdfunding-Plattformen. Jetzt ist wohl auch das Atari VCS gescheitert, mit 3Mio investiertem Kapital. Und 15000 Interessierte sollen es gewesen sein - zu wenig sagen sie. Ist die 8-Bit-Generation schon ausgestorben oder gab es damals nur so wenige Idioten die stundenlang vor der Glotze hockten und etwas killten ?
Andreas R. schrieb: > Rayne: wir binden im f64 Thread gerade 512 kb SRAM an. Das ist viel > einfacher anzusteuern und müsste Dir doch auch reichen? Wie weit seid ihr inzwischen mit eurem Projekt? Mit SRAM zu arbeiten ist in der Tat einfacher, aber die meisten FPGA Boards bringen leider nur SDRAM mit sich, daher ist es doch bestimmt von Vorteil einen funktionierenden SDRAM Controller zu haben. Mal davon abgesehen, wie sieht es mit der Geschwindigkeit aus? Liege ich da richtig dass SRAM immer schneller als SDRAM ist, wenn man DDR RAM jetzt mal ignoriert?
Bei gleichem Takt wohl auf jeden Fall. Trotz Tricks wie Burst-Mode usw. Maik macht gerade schon die Platine für den Shield wo schon das Ram drauf sitzt. VGA-Out, ps/2 In, Sound out und ein Teil des SD Zugriffs läuft. An dem Ram sind wir gerade dran. Für das de0 Nano Board müsste ich mal irgendwann an das SD Ram gehen. Aber das brennt nicht.
Bla schrieb: > Da läuft viel Sch... auf den Crowdfunding-Plattformen. Jetzt ist > wohl > auch das Atari VCS gescheitert, mit 3Mio investiertem Kapital. Und 15000 > Interessierte sollen es gewesen sein - zu wenig sagen sie. > > Ist die 8-Bit-Generation schon ausgestorben oder gab es damals nur so > wenige Idioten die stundenlang vor der Glotze hockten und etwas killten > ? Zitiert doch den originalen Bericht, anstatt hier Zusammenhänge neu zu erfinden: https://www.heise.de/newsticker/meldung/Atari-VCS-Schwarmfinanzierte-Retro-Gaming-Konsole-steht-vor-dem-Aus-4550420.html Die Hardwareentwicklung ist nicht an zuwenig Interessanten gescheitert, sondern die Softwareneuentwicklung. Die Hardwareentwicklung scheiterte weil es in diesem Bereich meist blutige Amateure und Möchtegern/Zampanos tummeln. Oder heuchlerisch ausgedrückt "[stellt] Unerfahrenheit in der Konsolenentwicklung den Kern der Probleme dar."
Für das DE1 kann ich einen SDRam Controller anbieten der auf 100 Mhz mit geringer Latenz (CL2) läuft. Ob das auch auf einem De0 geht weiß ich nicht, aber im Normalfall lässt sich das recht gut anpassen. Basiert ursprünglich auf dem hier: http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller Das DE1(18000 LE) reicht für einen C64, nur der Anfangs erwähnte 5000 LE Cyclone 2 wird halt sehr knapp.
Josef schrieb: > Andreas R. schrieb: >> im f64 Thread > > Bitte um einen Link zu dem Thread. Das geht leider nicht, da das eine private Konversation ist. Ist nur mit Einladung sichtbar.
Das Ziel wäre erst mal einen Controller für den SDRAM auf dem CYC1000 zu entwickeln. Kann man den Controller hinterher ganz einfach mit einem anderen SDRAM verwenden oder gibt's da größere Unterschiede die man berücksichtigen muss?
Ich glaub, Du kannst den Controller noch nicht mal mit dem gleichen Ram auf einem anderen Board verwenden. Ich weiss von dem de0 Nano Controller, dass man da extra einen Takt braucht, der um ein paar ns phasenverschoben ist.
Na ganz so schlimm ist es auch nicht. Den Controller kannst du typischerweise für alle SDRams mit gleicher Busbreite und gleichen Timings wieder einsetzen. Der Wechsel auf andere Größen ist aber auch nicht so dramatisch. Hatte meinen vom DE1 (16 Bit Breite) auf das DE2-115 (2 RAMs mit je 16 Bit Breite) nach wenigen Stunden portiert. Ja, man braucht meistens einen zusätzlichen Takt der phasenverschoben ist. Ist aber auch kein Hexenwerk. Leider hat das DE1 keine programmierbaren IO-Delays, so dass man zum testen jedes mal synthetisieren muss. Für mein DE1 Board habe ich so ein Auge bei 67.5 - 165° Verschiebung "ausgemessen", mit dem das RAM bei 100 MHz und CL2 läuft. Die Grenzwerte sind dabei natürlich nicht empfehlenswert, wegen Temperatureffekten. Trotzdem ist das weit genug, das ich davon ausgehe es klappt mit ~110° Verschiebung auch auf anderen DE1.
Robert P. schrieb: > Für mein DE1 Board habe ich so ein Auge bei 67.5 - 165° Verschiebung Das kriegt man doch eigentlich mit einer PLL und einem zweiten Takt hin, den man schiebt. Das geht auch zur Laufzeit.
Habe ich auch so gemacht. Mir ist aber nicht bewusst das ein Cyclone 2 das zur Laufzeit verschieben könnte. Das PLL Datenblatt sagt dazu nichts oder ich bin blind.
Robert P. schrieb: > Habe ich auch so gemacht. > > Mir ist aber nicht bewusst das ein Cyclone 2 das zur Laufzeit > verschieben könnte. > Das PLL Datenblatt sagt dazu nichts oder ich bin blind. ALTPLL_RECONFIG https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altpll_reconfig.pdf
Markus F. schrieb: > Robert P. schrieb: >> Habe ich auch so gemacht. >> >> Mir ist aber nicht bewusst das ein Cyclone 2 das zur Laufzeit >> verschieben könnte. >> Das PLL Datenblatt sagt dazu nichts oder ich bin blind. > > ALTPLL_RECONFIG > > https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altpll_reconfig.pdf Nehme alles zurück und behaupte das Gegenteil: ALTPLL_RECONFIG scheint für den Cyclone II nicht verfügbar.
Man sollte immer aktuelle FPGAs verwenden, also Cyclone2 ist uralt. Nimmt Cyclone10 LP oder MAX10 von Intel (ex Altera)... Es gibt auch super Boards, wie das MAX1000 oder CYC1000 Board. Da ist auch schon SDRAM mti drauf. Dann kannst du gleich copy&paste machen. Viel Spaß damit.
Einen Christian gibt's da https://www.trenz-electronic.de/de/Impressum-Disclaimer Aber wer ist Martin?
Aha. Dann gibt's also noch den, der die Minuspunkte vergibt? Um das klar zu stellen: ich hab' nix gegen Trenz. Aber wenn ich so was (sinnentleertes) lese: Martin schrieb: > Da ist > auch schon SDRAM mti drauf. Dann kannst du gleich copy&paste machen. kommt mir die Galle hoch.
:
Bearbeitet durch User
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.