Posts by 1570

Ah, ich hatte gar nicht die genauen Specs nachgesehen. Okok!

Das ist schon klar, ich meinte nicht "Hat schon jemand diese Hardware", sondern "Hat schon jemand (Teile von MiST) darauf portiert".

Aber andererseits fehlt dem EasyFPGA auch gerade der HDMI-Ausgang, das ist auf jeden Fall ein Haar in der Suppe.

ZeHa Ja und? Inwiefern spielt das eine Rolle? Also ich bin ja allemal für FPGAs, aber Deine Argumentation ist schräg. FPGAs haben ja nichtmal 5V-TTL an den I/O-Pins, wie sollen die da "original" sein? Und warum sollte die Im-Browser-Emu des 6502 weniger exakt sein, obwohl sie potenziell z.B. sogar Leckströme oder kosmische Strahlung oder Temperaturänderungen recht sauber nachbilden könnte, was der FPGA ganz sicher nicht kann (sofern man es nicht mit Extra-Logik eben emuliert)?

Quote from ZeHa

Und das geht mit Software-Emulation einfach prinzipbedingt nicht.

Ach? Was ist denn http://www.visual6502.org/JSSim/ ?

Z.B. das Rz-Easy FPGA A2.2 (Cyclone IV EP4CE6E22C8N, 16Mbit EPCS16N serial configuration, 64Mbit SDRAM, VGA out) gibt's für rund 30€ auf AliExpress. Wär doch für MiST ganz schick (oder?), hat da jemand schon was?

Quote from Freddy

Postscript 'beschreibt' die Seite (das Aussehen etc.) ist aber nicht den Inhalt der Seite.

Und welche Sprache würde dann den Inhalt einer Seite eines Dokuments (sagen wir mal eine Seite aus "Moby Dick") beschreiben?

(Postscript ist übrigens ein schlechtes Beispiel, weil das eine ausgewachsene Turing-komplette Programmiersprache ist, ähnlich wie HTML+CSS, auch wenn das glücklicherweise selten so benutzt wird. Für Deine Zwecke ist vermutlich reines HTML das, was Du meinst)

Quote from sparhawk

Kann ich als einen "alten" FPGA nehmen und das drauf anwenden? Dachte das wäre stark an die Hardware gebunden.

VHDL ist schon relativ portabel. Man kann halt nicht erwarten, VHDL-Sourcen (oder gar die Binaries) von Projekt A einfach in einem anderen Projekt (mit anderem FPGA und anderer Anbindung des FPGA etc.) ungeändert benutzen zu können. Schau' Dir die MiSTer-Sourcen einfach mal an. Z.B. ein Großteil des C64-Cores ist schon ziemlich alt und wurde ursprünglich für andere FPGA-Varianten entwickelt.

Wenn VHDL/FPGA lediglich "Emulation" und "Software" sind, wird's dann magisch Hardware, wenn man das VHDL einer Foundry gibt, die dann ASICs draus presst? An welcher Stelle genau passiert denn die Magie?

@EgonOlsen der Spaß mit "Interface-Hardware" ist, dass sie Timingprobleme nicht wegzaubern kann. Nehmen wir an, Du hast ein Steckmodul, dass nach einem Schreibzugriff (das kann auf C64-Seite ein simples STA sein) für drei Mikrosekunden an einer bestimmten Speicherstelle eine Antwort verfügbar macht (und nicht länger). Im Emulator auf dem PC wird das STA ausgeführt und das Signal über irgendeine Interface-Hardware an das Steckmodul gelegt. Das Steckmodul hält jetzt für 3µS das Ergebnis vor. Der Emulator ist gerade preempted, weil der MP3-Player ein paar Zyklen will, und läuft erst nach 100µS wieder weiter. In dem Moment ist das Ergebnis des Steckmoduls schon nicht mehr verfügbar, egal, was der Emulator macht. Selbst "intelligente" Interface-Hardware hilft da nichts, es sei denn, sie bringt spezielles Wissen über das angesteckte Modul mit ("nach diesem einen speziellen STA muss das-und-das Register gesichert werden") - de facto müsste die Interface-Hardware also einen Teil der C64-Software mit striktem Timing emulieren bzw. nachbauen (genau das ist das, was z.B. sd2iec macht). Das ist dann aber nicht mehr generisch, sondern die Interface-Hardware bräuchte auf die jeweiligen Module zugeschnittene Firmware (so wie sd2iec für jeden neu unterstützten Fastloader neue Firmware braucht). Will man das Problem lösen, hat man am Schluss einen FPGA in der Interface-Hardware, der die komplette Emulation des C64 macht und den PC nur noch als Monitor/Tastatur benutzt. (wobei eventuell auch mehrere Mikrocontroller statt einem FPGA funktionieren könnten; es gibt Sachen wie Pi1541, eventuell ginge auch sowas wie Pi6510. Ist halt irrer Aufwand gegenüber einem FPGA.).

Wie schaut's denn mit der Emulation des Hardware-Expansionsports aus, EgonOlsen? Gibt es *irgendeinen* Software-Emulator, der selbst mit Extra-Hardware den C64-Expansionsport tatsächlich emulieren kann? Nein. Da braucht man Latenzen im Sub-Mikrosekundenbereich, und das bringt nunmal kein PC mit normalem Betriebssystem. Mit FPGAs wiederum ist das kein Problem, sie sind quasi dafür gebaut.

Wie das evtl. in 10 Jahren und mit absurdem Hardware-/Softwareaufwand aussieht, ist vermutlich in diesem Thread kein Thema. Klar könnte man ggf. auf einem 20GHz-PC mit einem latenzarmen Betriebssystem (DOS...) ggf. was in der Richtung machen.

Ich hab jetzt nur kurz drübergeschaut, aber es wurde anscheinend noch gar nicht erwähnt, dass FPGA-basierte Emulatoren wenigstens prinzipiell timingkritische Original-Hardware (Floppy, Steckmodule) "ganz normal" unterstützen können (Floppy anschließen, fertig).

Software-Emulatoren müssen da passen, können aber natürlich auch ggf. diese Hardware komplett in Software emulieren, wobei das Handling und die Möglichkeiten aber natürlich andere sind. Diskette "in echt" bekommen, in PC einlegen und in VICE "LOAD" tippen ist halt nicht.

Ich deute das mal so, dass er eine Render-Pipeline für Doom in seiner eigenen Sprache implementiert hat (die Verilog-nah ist). Die eigentliche Spielelogik oder Interaktivität gibt's bisher nicht, sondern nur das Rendern des Bilds in einen Framebuffer (den die FPGA-eigene GPU wiederum per HDMI ausgibt). Er hat also eine Art sehr spezialisierte GPU gebaut (mit einer Fixed Pipeline speziell für Doom).

Die MT3608 sind auch die Dinger, die echt mit Fingerspitzengefühl eingestellt werden müssen, auf gar keinen Fall ohne Last betrieben werden dürfen und sonst gerne mal Feuer fangen. Gibt's auf Youtube spaßige Videos zu.

Was ist das für ein PC/Mainboard? Wenn das ein UEFI-fähiges System ist, kann man die Betriebssysteme einfach im UEFI-Modus installieren und dann das zu bootende System direkt im UEFI auswählen, das dann u.a. als Bootmanager fungiert. Sozusagen ein direkt im Mainboard-ROM eingebrannter Grub, der sich selbst zusammensucht, was da wo startbar ist.

Bei sowas kann man auch eine 0,8mm-Düse nehmen, dann geht das richtig fix.

Ach, der Autor des Buchs ist jetzt kein Statistik-Anfänger: https://en.wikipedia.org/wiki/Steven_Levitt . Das Buch ist lesenswert und auch unterhaltsam.

Quote from whodan

Außerdem wird da sicherlich auch ein wenig übertriene. Es ist nichts bekannt, dass die Leute der älteren Generation wie ich durch Löten mit PbSn-Loten

große Schäden erlitten haben.

Es gibt ja nicht nur akute Vergiftungen, sondern auch schleichende Schäden. So wird verbleites Benzin verdächtigt, u.a. an der Aggressivitäts-/Kriminalitätswelle in den 80ern/90ern beteiligt gewesen zu sein.

Ist statistisch ganz spannend, das Problem hat sich damals relativ plötzlich von alleine gelegt, und u.a. wird vermutet, dass die Kombi aus der Einführung von bleifreiem Benzin und dem Legalisieren der Abtreibung zum Abebben der Kriminalitätsrate geführt hat...

https://en.wikipedia.org/wiki/…E2%80%93crime_correlation

https://en.wikipedia.org/wiki/Freakonomics

Aber ich sage jetzt NICHT, dass alle Hobbylöter unnatürlich aggressiv sind.

Der C64Maxi ist doch nur MiniPC+VICE? VICE emuliert den Expansionsport nicht. Wie auch; da müssten ein Haufen Signale mit einer Genauigkeit von unter einer Mikrosekunde gelesen/geschrieben werden. Also nicht reine Geschwindigkeit, sondern Latenz, also im Zweifelsfall "Lesen+in VICE/auf dem MiniPC verarbeiten+ausgeben".

"Voll funktionsfähig" wird sowas heißen wie "Voll funktionsfähig: Stellt 5V Versorgungsspannung zur Verfügung" oder sowas...

Wenn der Slicer G-Code produziert hat, bei dem beim Drucken niemals mehr als ca. 12kBytes/Sekunde an Befehlen übermittelt werden müssen, passt das. Je nach Slicer(-Settings) und 3D-Modell und am Drucker eingestellter Flow Rate klappt das also ohne Pausen. Hat mit Octopi/Raspberry also bestenfalls mittelbar was zu tun. Wie auch - die können auch nicht die USB2Serial-Krücke beim Arduino wegzaubern.

Quote from scuba

Das liegt eher am Protokoll das die FW verwendet.

Bei den normalen Arduinos wird ein ATmega 2560 benutzt, der kein USB kann. USB wird dort so realisiert, dass ein weiterer Chip das Interfacing mit USB übernimmt und auch den ATmega über serielle Schnittstelle programmieren kann. Über USB eingehende Daten sind also auf die rund 115200 bps = ca. 12kBytes/Sekunde der internen Seriellen limitiert, WEIT unterhalb dessen, was USB schafft.

Das merke ich hier schon beim Unterschied "Drucken von SD-Karte" vs. "Drucken vom PC via USB": Von SD-Karte geht alles fluffig (denn die SD-Karte ist fix per SDIO am Microcontroller angeschlossen), aber via USB muss der Drucker bei komplexen Modellen ab und zu Pausen machen, während er auf Daten wartet (das gibt dann kleine "Nasen" im Druck, ganz toll).

Ja klar, so argumentiere ich ja durchaus auch. "Unix-Philosophie: Kleine Tools werden zu großen Anwendungen kombiniert" ist da nur etwas irreführend, denn aus cp/find/tar und Konsorten baut man schließlich keine ernsthaften Anwendungen, sondern eben nur praktische (handgeklöppelte) Skripte; und das man daraus irgendwas mit GUI macht, dürfte auch eher die absolute Ausnahme sein...

Du hast völlig recht, dass das alles angenehm stabil über die Jahre ist: Z.B. ist mir ein bash-Skript zum Einrichten eines neuen Servers allemal lieber als ein hippes Puppet- oder Ansible-Skript, bei dem man fest davon ausgehen kann, dass sich die Semantik einiger Konstrukte beim nächsten Release der Plattform mal wieder leicht geändert hat.

Was Skripte angeht, soll bei Windows wohl u.a. WSL und PowerShell in die Bresche springen. Wobei sich Windows mit dem Defizit grundsätzlich in "guter" Gesellschaft befindet, denn auch macOS oder sogar Solaris etc. ist ja nur mit den mitgelieferten Tools eher nicht zu gebrauchen (= niemand, der ernsthaft die Konsole benutzen will, gibt sich mit dem zufrieden, was man da von Haus aus vorfindet)...