Hallo Besucher, der Thread wurde 56k mal aufgerufen und enthält 219 Antworten

letzter Beitrag von WalkThatWay am

c64 Redesign (Mainboard)

    Zitat

    Und, hat die Installation geklappt?


    Juhuuu, er hat die letzten 3 Prozent auch geschafft! 97% = 1h, 3% = 2h - logisch. Werd's gleich mal starten. Vielleicht sollte ich einen separaten "FPGA für Dummies"-Tread aufmachen.


    Zitat

    hat 10000LCs (Logiczellen)


    Ah, danke. Scheint also die Größenordnung des XC3S400 zu sein, hier steht was von 8064 cells / 400000 gates.

    Zitat

    Oder kennt hier jemand einen Soft Core für nen FPGA der kostenlos ist, in C programmiert werden kann und bei dem Debugging möglich ist ?


    Entweder ich bin zu naiv oder ein blindes Huhn...: http://www.mikrocontroller.net/articles/FPGA_Soft_Core Da fallen mir einige auf, die Code vom GCC fressen und unter freien Lizenzen sind. Mit dem Debuggen weiß ich nicht, aber da hat mir fast immer UART gereicht. JTAG habe ich nur selten rausholen müssen.


    Mann, jetzt gibt's noch mehr Größenordnungswörter: Gates, Cells, Slices, Logikblöcke - Häh?


    Huaaahhh -- XilinxUpdate 10% ----- ich dachte, die Sache hat ein Ende ---- ich will schafen |-(


    Gruß,
    Thomas

    Hallo da Ihr hier alle so fleißig diskutiert kann ich ja auch mal ne Runde Infos dazu spenden und zwar hab Ihr ja schon mehrfach den SwinSID als SID Ersatz erwähnt, davon kann ich aber leider eher abraten da der SwinSID nur Sound macht (den sehr gut) jedoch leider keine Möglichkeit für Paddle-Anschlüsse (fehlender AD Wandler Code) sowie keine Register Abfrage der Daten der dritten Stimme bietet. Der SwinSID in seiner aktuellen Form ist als reiner Sound Ausgabe AVR programmiert. Deswegen habe ich meine Platine auch so gestaltet das der SwinSID immer als zusatz Soundchip dazu kommt und nicht alleine die Arbeit macht. Werde da auch in näherer Zeit mal wieder weiter an der Platine arbeiten und das Ergebnis im entsprechende Thread fortführen. Übrigens gibt es auch aktuell noch einen 6502 8Bit Prozessor zu erwerben von WDC hier in Deutschland durch DEMA Electronic AG München vertreten, habe einen W65C02S8PL-10 (10 MHz :roll2: ) als PLCC Muster geschenkt bekommen. Ergo muss man nicht unbedingt die CPU emulieren. Dann fällt mir da noch ein das es z.B. bei dem MIDIBOX SID (http://www.ucapps.de ) Projekt im Forum immer noch riesen Mengen an 6582 SIDs zu erwerben gibt (Forum User: Wilba) hier mal der link dazu. Bleibt also noch eine gescheite VIC-II Emulation mit 75 bzw 100Hz auf VGA damit es nicht Ruckelt und die CIAs :D

    Zitat

    Scheint also die Größenordnung des XC3S400 zu sein


    Könnte hinkommen.

    Zitat

    Eine Schwierigkeit bei Soft CPUs in FPGA ist die Toolchain fürs Programmieren.


    Das stimmt. Aber man kann sich auch anders behelfen. Bei dem ALTERA-Tool (Quartus II) gibt es den eingebauten Logikanalyser auch in der WEB-Version(kostenlos).
    Im Augenblick arbeite ich ja immernoch an der 1541-EMU für den C-One. Da sieht mein Workflow so aus: Ich nutze einen 6502-Core und den CC65. Da direktes debuggen nicht geht füge ich ein paar Ausgaben über RS232 ein. Den erzeugten Code lade ich in den Blockram des FPGA's. Wenn man "smart compilation" benutzt dauert das nur ein paar Sekunden. Dann kucke ich ob die Ausgaben über RS232 so sind wie erwartet und wenn nicht setze ich einen Trigger für Signal Tap (das ist der Loggikanalyser von Quartus für die ALTERA-FPGA's) und kann mir das Signalspiel im FPGA angucken.
    Ob das bei Xilinx oder Lattic auch so komfortalel geht weiss ich nicht. Aber es ist ja mein gutes Recht hier für ALTERA Partei zu ergreifen weil ich mich damit bestens auskenne.
    Viele Grüße
    TobiFlex

    Zitat von Crisp

    Bleibt also noch eine gescheite VIC-II Emulation mit 75 bzw 100Hz auf VGA damit es nicht Ruckelt


    Da habe ich auch schon drüber nachgedacht, wie man wenigstens ein normgerechtes PAL-Signal oder ein VGA-Signal erzeugen könnte. Ein Problem, das ich sehe, ist der Rasterzeilen-Interrupt. Es wird schwierig werden, den kompatibel hinzubekommen, wenn die Anzahl der dargestellten Zeilen verändert wird (und das ist bei normgerechtem PAL oder VGA nicht zu vermeiden. Mit SVGA-Auflösung könnte es dagegen relativ einfach klappen (312 Zeilen - VIC / 768 Zeilen - SVGA). Allerdings sind es dann @85Hz schon 66MHz Pixeltakt....

    Zitat von Computerbastler


    Da habe ich auch schon drüber nachgedacht, wie man wenigstens ein normgerechtes PAL-Signal oder ein VGA-Signal erzeugen könnte.


    Man kann einen Scandoubler implementieren, so wie bei Minimig. Das Signal hat dann 31 KHz Horizontalfrequenz und 50 Hz Bildwiederholrate. Das ruckelt nicht. Geht aber auch nur mit einem Teil der VGA-Monitoren.

    > C64 Core inclusive 6502 ca. 5000 LC's
    Andererseits wäre ein FPGA mit <= 10k cells mit C64 Core + SID schon ziemlich voll.


    > und natürlich die eigentliche Floppy-Emu (6503, VIAs, Disk rotation etc.) im FPGA zu haben
    Wenn man einen Controller benutzt, um den FPGA zu konfigurieren, sollte er vielleicht doch gleich das ganze 1541-Laufwerk mitmachen - was mir wieder die Motivation/Ausrede gibt, an meinem momentanen Projekt weiter zu machen. Das OSD könnte man je trotzdem realisieren, indem man den VIC so modifiziert, dass er noch einen Layer drüberblenden kann (quasi ein RiesenSprite). Den Text für's Menü könnte und die Steuerbefehle könnten sich ja die beiden Teile über einen Link != IEC zuschicken.


    tobiflex:
    Natürlich sollte die 1541-Emu im Controller funktionieren, _bevor_ man sie integriert und damit auf die Nase fällt ;-)


    > Soft Core für nen FPGA der kostenlos ist, in C programmiert werden kann und bei dem Debugging möglich ist ?
    Meine Antwort bezog sich auf das Debuggen des Codes der im SoftCore läuft, nicht das Debuggen des Cores selbst. Nur falls es doch anders gemeint war.


    > Das Signal hat dann 31 KHz Horizontalfrequenz und 50 Hz Bildwiederholrate.
    Kann man sich für den VIC im FPGA ein paar kBit DPR (4 bit breit) gönnen, sind ja auch ein paar Pixel weniger als im Amiga? Dann wären die 100 oder 75 Hz vielleicht möglich.


    > ein normgerechtes PAL-Signal
    Sehe ich für's richtige Wohnzimmercomputing auch als Pflicht an. Vielleicht könnte diese DPR-Sache helfen, auch das Problem zu lösen?


    > Wenn ich am Anfang eine Chance sehe das es Realisierbar ist, Ja !
    Mist, jetzt muss ich die Idee mit den Lego-Bausteinen doch selbst umsetzen ;-(

    zu sid/swinsid und cpu


    selbst wenn man noch viele SIDs und CPUs bekommt, wie lange noch? fpga werden wohl einfacher zu bekommen sein, zudem ließe sich das später eventuell mal auf neue systeme portieren.
    wenn ich jetzt bei einem solchen neuen projekt ALTE bauteile nehme, habe ich doch keinen vorteil mehr oder?


    ich denke wenn ein solches projekt angegangen wird, dann sollte wirklich alles umgesetzt werden (ich hab nur leider keine ahunng von den sachen hier :D )
    aber das wäre meine intention bei sowas.

    Zitat von Draco

    Man kann einen Scandoubler implementieren, so wie bei Minimig.

    Ist in Syntiacs FPGA-64 schon drin, siehe FPGA64_026/sources/rtl/fpga64_scandoubler.vhd .

    Zitat von skoe

    Ich hab immer Skrupel, Sachen wiederzuveröffentlichen, bei denen ein Copyright aber keine Lizenz drübersteht. Würden Peter Wendrich, Jan Derogee und Marco Groeneveld denn zustimmen, ihre Werke unter eine definierte Lizenz zu stellen, z.B. BSD, GPL oder so?

    Ich hab' die drei mal zum Thema angeschrieben.

    Zitat von skoe

    Aber bitte erst, wenn es einen C64-Nachbau-mit-FPGA-für-Wohnzimmer-Computing Thread gibt :-)


    Yep, da bin ich auch dafür. Ich hab' nämlich extra schon VHDL gelernt! (-;

    Zitat von Draco

    Man kann einen Scandoubler implementieren, so wie bei Minimig. Das Signal hat dann 31 KHz Horizontalfrequenz und 50 Hz Bildwiederholrate. Das ruckelt nicht. Geht aber auch nur mit einem Teil der VGA-Monitoren.


    Wenn man was Neues macht, sollte man meiner Meinung nach genau das vermeiden. Der Original-VIC ist an der Stelle schon nicht der Hit. Also sollte man dasselbe möglichst nicht wieder machen. PAL-Signal bedeutet meiner Meinung nach also, daß es jeder PAL-Fernseher darstellen kann (d.h. 625 Zeilen/ 2 Halbbilder), und VGA-Signal bedeutet demnach, daß es jeder VGA-Monitor darstellen können sollte (ebenfalls normgerechtes Timing).

    Hä? Da kommt EIN EINZIGES MAL bei einem von Ace's wir-spinnen-uns-Hardware-Threads was Produktives raus, und der Herr will dichtmachen? :shrug:


    *an-Anfang-zurückblätter* Mainboard-Redesign mit Ziel: kleinerer Formfaktor. Mit Originalchips: Lohnt nicht, weil Ergebnis bestenfalls 2/3 der C64-E-Platine wäre; wir müssen also doch an die Customchips ran. Programmierbare Logik: wenn, dann direkt alles in einen Chip (aus ökonomischen Gründen); Ersatz für einzelne ICs durch uCs *g* wird im Thread nebenan weitergepuzzelt, weils keinen Platzvorteil bringt.


    Und als Nebeneffekt gibts noch ein FPGA-Crashkurs obendrauf *zuTobiFlexrüberwink*


    Computerbastler: an PAL führt aber (zumindest timing-mäßig) kein Weg vorbei- erstens wird RGB mit PAL-Frequenz noch etliche Jahre an Heim-Glotzofonen zur Verfügung stehen, zweitens bekommt man mit einem Scan-Doubler nur 31kHz horizontal bei 50 Hz vertikal hin, was viele VGA's nicht mögen- Lösung wäre ein Framebuffer, der aber eklige Artefakte und Probleme mit Lightpen-Spielen brächte. (Auf der Commodoreone-Liste hatten wir das in grauer Vorzeit mal ausführlichst durchbalkinsiniert *dunkelerinner*)