-
Hm naja, das ist eigentlich was leicht anderes. Likely und unlikely beeinflussen, welcher Code im RAM nachher "geradeaus" liegt (also ohne Sprung erreicht wird). Die Sprungvorhersage des Prozessors dagegen soll gerade dafür sorgen, dass auch eben Sprünge "kostenlos" (ohne Pipeline-Stalls) ablaufen, bzw. eben die vorhergesagte Sprungrichtung. Die Sprungvorhersage macht z.B. auch Schleifen (bzw. den impliziten Rücksprung darin) schnell, wofür es likely/unlikely gar nicht gibt.
Likely/unlikely legen die Dinge also passend hin, während die Sprungvorhersage den Raum krümmt. 
-
Ja, das mit Java habe ich auch schon mal gelesen. Ich habe mal gelesen, dass einige CPUs solche Dinge sogar können.
Viele neuere Sprachen mit JIT-Compiler/VM machen das, neben Java z.B. auch JavaScript (bzw. mindestens die besseren JavaScript-Runtimes wie z.B. Chromes V8). Merkt man u.a. daran, dass lange switch-Statements oder entsprechende if...then...else-Ketten "automatisch" in die optimale Reihenfolge gebracht werden, während man bei anderen Sprachen immer aufpassen sollte, im Quellcode auf den häufigsten Fall zuerst zu prüfen.
CPUs machen sowas aber nicht, Du meinst vielleicht Sprungvorhersage oder Speculative Execution, das ist nochmal andere Magie, für die es auf Compiler/Programmiersprachenebene keine rechte Entsprechung gibt.
-
Goodwell Es ist im Source verfügbar, Du darfst ihn herunterladen und kompilieren und benutzen. Das Kompilat weitergeben oder selbst Forken ist aber nicht erlaubt, es ist also nicht Open Source im Sinne der FSF (sondern mehr so eine Art "Source Available").
Ein paar Bibliotheken, auf die aseprite aufbaut, sind MIT-lizensiert. Ändert nichts daran, dass aseprite selbst eine andere einschränkendere Lizenz benutzt.
Dann sind noch "Educational Licenses" verfügbar, ich schätze das wird auf ein "Ihr dürft die EXE innerhalb der Schule kostenfrei weitergeben nach Nachfrage" hinauslaufen.
-
Zitat
Bisher ist aber nicht einmal ein Raspberry-Pi-Gegner mit RISC-V auf dem Markt.
Auf die Schnelle finde ich gleich drei:
- Banana Pi F3 (SpacemiT K1, 8 Kerne)
- OrangePi RV2 (Ky X1, 8 Kerne)
- VisionFive 2 (JH7110, 4 Kerne)
Ob die wirklich konkurrenzfähig sind, steht natürlich auf einem anderen Blatt, das ist aber schon alleine schwer, weil günstigere Preise in dem Segment nunmal durch hohe Stückzahlen erreicht werden und nicht durch besonders geschicktes Design, der Markt aber vom RPi geradezu monopolisiert ist.
-
Einen PAL-Filter kann man auch (irgendwann) per entsprechendem Postprocessing implementieren; es hält einen ja z.B. nichts davon ab, den Pixelstrom aus dem FPGA zu irgendwas mit "ernsthafter" GPU zu streamen (RPi oder sonstwas) und dort einen Shader drauf loszulassen (wie es auch die normalen PC-basierten Emulatoren machen). Irgendwann wird man sich auch den FPGA ganz sparen können, der ist eh gewissermaßen eine Krücke.
Bisschen witzig, dass es mit dem VICIIdizer, HD64 und dem ISEVIC jetzt drei Varianten des gleichen Ansatzes gibt, aber keiner erlaubt eben dieses Postprocessing. 
-
Wo ich vorhin das Chamäleon erwähnte, fällt mir jetzt ein: warum benötigt dieses als Modul keine zusätzlichen Strippen, um ein 1:1 Videosignal zu erzeugen?
Das Chameleon degradiert den C64 sozusagen zum Tastatur-Interface. Das ISEVIC dagegen lauscht nur passiv am C64-Bus; die zusätzlichen Leitungen braucht es, um zu erkennen, ob die Zugriffe, die es sieht, sich auf RAM, ROM, IO oder Farbram beziehen. Genaueres gab's schon in Posting 14: HDMI über den Cartridgeport
-
Klar wird ein Teil des VIC-II emuliert, aber der originale VIC-II bleibt auch im Rechner (und MUSS auch vorhanden sein). ISEVIC lauscht nur (wie HD64 und VICIIdizer auch) am Bus mit und sieht so, welche Daten sich der VIC-II wann holt, und erzeugt daraus das Videobild. Z.B. ist klar, dass Daten, die der VIC-II in Taktzyklus 58/59 einer Zeile holt (falls er dann welche holt und nicht idled), zu einem angeschalteten ersten Sprite gehören. Wo das Sprite ist, weiß das Modul, weil es die Registerzugriffe zum Positionieren des Sprites auch irgendwann auf dem Bus "gesehen" hat. Das Modul zieht also eine Teil-Emulation des VIC-II mit.
Aber das Modul muss anders als der originale VIC-II z.B. nicht berechnen, welche Speicheradressen wann angefordert werden müssen, weil es das Setzen des Adressbusses dem originalen VIC-II überlässt.
-
Blöderweise fallen diese VIC-II-Emulatoren immer wieder bei neuen und nicht so neuen Demo-Effekten auf die Nase. 
Das ist kein vollständiger Emulator, Adressgenerierung etc. wird wie auch beim HD64 und beim VICIIdizer dem originalen VIC-II überlassen (bin mir nicht ganz sicher, aber vermutlich braucht man mit diesem Ansatz z.B. nichtmal Sprite Crunch irgendwie nachimplementieren, weil sich das aus den Buszugriffen des VIC-II nunmal so ergibt).
Klar können trotzdem Bugs drin sein, aber dafür gibt es ja ggf. Firmware-Fixes.
-
Mit dem Tang Nano 20K könnte das auch billiger werden, wobei ich mich schon wundere warum ich bei Ali das scheinbar identische FPGA-Board für 4,69€ bis 71,69€ angeboten bekommen...
Nee, das normale Board kostet um die 30€. In der Suchliste werden gerne niedrige Preise angezeigt, aber wenn man dann auf die eigentliche Anzeige geht, ist das dann immer die Variante "Nur Gehäuse" oder "Nur Breadboard" oder sowas. Ältester Clickbait-Trick der Anbieter bei Aliexpress.
-
Das JiffyDOS-ROM macht das, der CBM-KERNAL aber nicht. Sieht man u.a. schon daran, dass unter http://unusedino.de/ec64/technical/aay/c64/vic21.htm keine Liste zu finden ist mit "Diese Speicherstelle wird referenziert von".
-
Kenne mich mit der Takterzeugung nicht gut aus, bei defektem U31/LS629 würde ich aber davon ausgehen, dass auch die Farbe weg wäre (da dort erstmal der Farbträger erzeugt wird). Also eher die anderen drei Chips (74LS74, 74LS193, MC4044). Beim LS193 stimmen die Spannungen an den Pins? Pins 16, 15, 10, 4, 1 müssen alle auf 5V sein.
-
blechtasse sd2iec unterstützt außerhalb von Images auch nicht alle Schnelllader (auch wenn das in der Praxis weniger auffällt).
-
Markus64 Das Zeug bröckelt und rieselt mit der Zeit. Ich hab schon Tastaturen gesehen, in denen sich Placken gelöst hatten und auf den Kontakten festhingen. Mag sein, dass das auch von der Marke des Sprays abhängt, aber das Zeug gehört einfach nicht dort hin.
Mit einem Blatt Papier bekommt man die Stempel sicherer und einfacherer wieder gängig. Probier's aus!
-
Easyprog benutzt doch einen Schnelllader, eventuell funktioniert der nicht mit dem Pi1541-Browser-Modus zusammen; im Gegensatz zum D64-Modus hat der nur eingeschränkte Kompatibilität, meine ich.
In sd2iec wurde Kompatibilität mit dem Easyprog-Schnelllader extra eingebaut.
(aber dass dann kein Absturz oder Fehlermeldung von Easyprog kommt, ist seltsam)
-
1541: Wartungs- und Einstellarbeiten hat die Sachen für ALPS, auch den restlichen Thread lesen am besten.
-
Der „Brotkasten“ funktioniert. 
(Bis auf einen Großteil der Tasten, aber ich werde die Tastatur auseinander nehmen und gründlich reinigen, das sollte genügen).
Siehe https://www.c64-wiki.de/wiki/Tastatur#Wartung . Finger weg von scharfen Reinigern oder Graphitspray, falls Du irgendwo davon lesen solltest.
-
Das Verfahren nennt sich übrigens "Sampling Profiler" (im Gegensatz zu "Tracing Profiler", bei dem der Code für den Profiler instrumentiert wird). Die deutsche Wikipedia redet von "Statistischem Profiler" hier.
-
arm2iec schafft wohl >50fach mit DolphinDOS und Parallelkabel: arm2iec [Neue Hardware]
...ist aber denke ich eher ein Armutszeugnis für den Dolphin-C64-Code, dass das trotz Parallelkabel so "langsam" ist.
Mit Modul im Expansionsport würde ich aber was ganz anderes machen, nämlich am Bus mitlauschen, was der C64 macht; bei Aufruf z.B. des KERNAL-LOADs einen NMI auslösen; CPU per Ultimax-Modus übernehmen (wie Freezer); Programm per DMA ins RAM schieben; direkt aus dem LOAD zurückspringen. (aber macht das KFF das nicht schon ziemlich genau so? Weiß ich nicht)
Dann hat man ein superschnelles LOAD ganz ohne neue Software auf C64-Seite.
Entsprechende Traps kann man natürlich auch noch für IECIN und ggf. auch andere Schnelllader schreiben (GEOS...).
-
Ah Professional Dos wird am Expansionsport vermutlich einfach eine weitere VIA/CIA/PIA o.ä. anbauen. Bisschen schade um IO1/IO2. Schneller wäre sicher DMA.
arm2iec und sd2iec haben übrigend beide auch Parallelkabel-Support, nur unterstützt das kaum eine existierende Hardware für diese Firmware. Das wird schon sehr schnell sein, eben weil das Nadelöhr C1541-CPU wegfällt.
-
