Forum: FPGA, VHDL & Co. C64 auf Cyclone II


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Peter G. (peter_geher)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von ... (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man C64 (insbesondere das vorzuegliche Commodore Basic)
spielen will, nimmt man einen C128D.

Der Cyclone II kann sicher noch wo anders recycled werden.

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Peter G. (peter_geher)


Bewertung
-1 lesenswert
nicht lesenswert
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:
Youtube-Video "Commodore 64 On FPGA"

Also scheint das ja prinzipiell zu laufen.

von FPGA zum Spass (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Bla (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Der C64 ist ja kein Hexenwerk: der besteht nur aus ein paar Tausend 
Transistoren.

Man müsste den 1:1 nachbauen ...

von FPGA zum Spass (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Bla (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Peter Bierbach (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Schau dir diesen Core an für den MiSTer :

https://github.com/MiSTer-devel/C64_MiSTer

gruss

von Bla (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von FPGA zum Spass (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von DCF 7. (dcf77)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Tipp.
Das interessiert mich auch sehr.

von Elbi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Muss es ein c64 sein? Wir basteln aus diesem Board gerade einen kleinen 
Computer mit vga Ausgang,  Tastatur Eingang, SD Karte usw

von Neugierig (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas R. schrieb:
> Wir basteln aus diesem Board gerade einen kleinen Computer

Magst du dazu mehr erzählen?

von Elbi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Elbi schrieb:
> Die Plände sind da und bekannt.
"Pläne" war gemeint!

Neugierig schrieb:
> Magst du dazu mehr erzählen?

+1

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
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
von Robert P. (fpgazumspass) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sigint 1. (sigint)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gegeg J. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
... 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
Youtube-Video "C64 Basic Kurs - Teil 1 - Grundlagen"

von Frickel F. (frickelfritze)


Bewertung
0 lesenswert
nicht lesenswert
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
> Youtube-Video "C64 Basic Kurs - Teil 1 - Grundlagen"

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ß

von Bonzo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frickel F. (frickelfritze)


Bewertung
0 lesenswert
nicht lesenswert
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ß

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von C. A. Rotwang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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:
Youtube-Video "C64 Rob Hubbard's International Karate oscilloscope view"

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frickel F. (frickelfritze)


Bewertung
0 lesenswert
nicht lesenswert
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ß

von C. A. Rotwang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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:
Youtube-Video "Red Sector Inc - CeBIT 90 - Amiga Demo"

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von C. A. Rotwang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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
von Bildverarbeiter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Elbi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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...

von C. A. Rotwang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Frickel F. (frickelfritze)


Bewertung
0 lesenswert
nicht lesenswert
> 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
von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Auf forum64.de gibt es paar Leute, die an solchen Sachen arbeiten. 
Sowohl 6502 als auch vic2 auf FPGA.

von Frickel F. (frickelfritze)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
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

von Frickel F. (frickelfritze)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas P. (wellnestom)


Bewertung
0 lesenswert
nicht lesenswert
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

von Rayne (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Rayne: wir binden im f64 Thread gerade 512 kb SRAM an. Das ist viel 
einfacher anzusteuern und müsste Dir doch auch reichen?

von Bla (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 
?

von Rayne (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Beware of the Charge of the Knallchargen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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."

von Josef (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas R. schrieb:
> im f64 Thread

Bitte um einen Link zu dem Thread.

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rayne (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias N. (technick2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias N. (technick2)


Bewertung
0 lesenswert
nicht lesenswert
Bin nicht sicher. Können die Cyclone PLLs nicht umkonfiguriert werden?

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
-1 lesenswert
nicht lesenswert
Einen Christian gibt's da

https://www.trenz-electronic.de/de/Impressum-Disclaimer

Aber wer ist Martin?

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.