Posts by captain_buck_rogers

    Ich tippe hier immer noch auf meinem MacBookPro aus dem Jahr 2007 4MB Hauptspeicher... einfach nicht kaputtzukriegen ... Performancemäßig keine Probleme nur der Lüfter geht manchmal öfter an als früher... mach aber auch kein Blender oder sowas damit ...


    Ich meine, wenn sich das bei meinem alten Rechner mit der Haltbarkeit/Nutzungsdauer schon so verhält , wie ist das denn erst bei neuen Rechnern mit dem M1 aus 2021 ?


    ich meine bis wann halten die denn eigentlich... und wenn man dann noch alle Komponenten davon billigst um die Ecke tauschen könnte, wenn was defekt ginge ... ich wette dann würde so ein Rechner für viele Leute der Letzte sein... Und dann könnte man diesen Rechner auch an seine Enkel und so weiter vererben und die würden das wieder weitervererben ... weil die würden dann auch noch in 140 Jahren gut funkionieren ...


    Stellt das nicht auch ein Problem dar für Computerhersteller ? Jeder hat so ein Teil und keiner kauft neue mehr ... weil die Kisten allen alltäglichen Anforderungen performancemäßig gewachsen sind ? Der Repariermarkt würde einen immensen Aufschwung bekommen ... es wird nicht mehr neugekauft sondern nur noch zusammengeflickt und repariert... coole Welt eigentlich…


    Wenn dann mal einer wegen Wasserschaden abraucht und keiner kanns reparieren weil sie an die heiligen verdongelten Chips nicht rankommen ... wirds natürlich teuer ... aber insgesamt gesehen also in Summe gibt man heute viel viel weniger für die Rechner aus als noch vor 20 Jahren wo die Leute alle 4 Jahre einen neuen kaufen mussten ... C64 von 1982 - 1996 also 14 Jahre Nutzung wie mein macbook pro von 2007 da konnte der C64er in 1996 für die tägliche Arbeit nicht mehr mithalten weil die Softwareanforderungen schon ganz andere waren...


    Wie lange kann ich meinen Opa-Mac eigentlich noch verwenden ? Chrome und Firefox liefern noch ständig Updates ..

    Und jetzt haut mir mein ursprünglicher Grund ab ...

    hast du so ein Modell ?


    https://everymac.com/systems/a…2-unibody-usb3-specs.html


    da steht dann kannst du noch bis 10.15 upgraden...


    Warum ist das keine Option für dich ? Haben deine anderen Programme ein Problem mit 10.14 ? Mojave war ziemlich cool, es ha den Darkmode ins OS gebracht. Das ist für die Augen wesentlich angenehmer anzuschauen und glaube ich auch gesünder ... jedenfalls abends wenn es schon dunkel ist.

    tulan in diesem Fall eher was mit der Anzahl der Register des Prozessors. Die neueste Compilergeneration macht aggressivstes Function inlining per Default. D.h. er eliminiert Funkionsaufrufe, wo sinnvoll. Die Mother der schnellen geinlinedten funktionen hat dann keine JSR und RTS (jump to subroutine und return from subroutine) mehr und wird schneller ausgeführt. 🤤Aber anscheinend steigt damit der Bedarf an Registern. 🤭 dafür scheint die alte x64 Architektur nicht sonderlich geeignet zu sein. Der M1 kann hier von seiner überlegenen Anzahl an Registern profitieren.

    M1 - FUNFACT :emojiSmiley-06:: C64-Emulator-WebASM Code auf nativem Intel x64 Code jetzt mit massiven Slowdowns, wenn die aktuelleste LLVM Compiler-Toolchain verwendet wird...:grab1: der M1 ist dagegen immun -> auf den neuen M1 Macs wird der Code hingegen sogar mit leichten Geschwindigkeitssteigerungen ausgeführt...:thumbsup:


    Die Firefoxentwickler vermuten ein Problem bei der Registerallokation der Firefox WASM->Intel/AMDx64 Übersetzung in ihrer Browser-Engine...


    Ich habe mal im Internet recherchiert der M1 scheint 31 general purpose 64-Bit Register zu haben, Intel x64 hat hingegen hat nur 16 Register. Zu wenig für die moderne aggressiv optimierende LLVM Compiler-Toolchain :emojiSmiley-51:? Kommt die x64 Architektur langsam in die Jahre ?


    FUN-FACT2: der 68k in meinem A1000 hat auch 16 register so wie der Intel x64, ok allerdings nur 32Bit große.



    betroffen ist Firefox auf Linux, Mac und Windowssystemen mit Intelprozessor


    Ein Mitarbeiter von Mozilla Firefox hat dazu einen neuen Bug-Eintrag aufgemacht bezüglich der WASM-Ausführung von der Commodore 64 Emulation, die mit der extrem optimierenden LLVM Compiler Toolchain emscripten gebaut wurde.


    https://bugzilla.mozilla.org/show_bug.cgi?id=1708381

    Tremendous slowdown for C64 emulator with emscripten 2.0.17 due to more aggressive inlining

    This does not appear to be a problem on the M1 MacBook Pro, suggesting that it is a problem related to code generation or register allocation on x64.It is also a problem on Windows 10 x64, which is not totally surprising, though Windows has a different ABI so there are differences to how register allocation is done.


    PS: es gibt Flags, die die Defaulteinstellung der emscripten Toolchain wieder etwas zurückpfeifen/drosseln können, damit das Problem mit der Registerallokation nicht auftritt...

    Es gibt jetzt ein "symbolic mapping" switch ... in den Settings


    wenn aktiviert schaltet das Keyboard auf symbolisches Mapping, das heißt z.B. das ein + oder ein = auf der echten modernen Tastatur auch ein + bzw. = auf dem C64er tippt.


    wenn nicht aktiv dann ist es wie gehabt positional, das heißt die ungefähre Position der modernen Tastatur wird gemapped zum der Position auf dem C64er Keyboard.


    das symbolische Mapping ist noch etwas experimentell, es fehlen noch ein paar Zeichen. Kommt noch ...


    Außerdem sind im positional Mapping nun auch die Cursor Links und Up symbolisch gemapped... (Idee von Retrofan ) diese Tasten gab es nämlich auf dem C64er gar nicht ...;( ... das heißt die konnten positional gar nicht gemapped werden ... aber mit dem "Mix" kann man nun im positional Mapping auch alle vier Cursortasten gut bedienen... Damit kann man jetzt in Lutz G seinem Dir-Listing gut manövrieren... :thumbsup:

    Retrofan ja einstellbar glaube ich dann auch


    macht bei c64er-Piano-Apps Sinn ich glaube da gab es eine ... als Kind hatte ich auf der c64 Tastatur Klavier bzw. Synthi gespielt... wie hieß die App nur ???


    und zusätzlich bei positional die Cursortasten aber immer symbolisch wie du gesagt hast ..


    Defaulteinstellung des Settings: symbolisch ?

    kam nur bei einem ein "ist aber keine .de Tastatur"

    stimmt jetzt fällt mir es auch wieder auf ... ich habe da ein positional Mapping gemacht. Warum eigentlich?


    d.h. wie auf einem echten c64er kommt z.B.

    rechts neben der P Taste ein @ und ein *

    rechts neben der L Taste ein : und ein ;


    die deutsche Tastatur meines Macs hat aber ein ganz anderes Mapping, da kommt rechts neben L ein Ö und ein Ä
    und : ist da SHIFT + . und ; ist da SHIFT + ,



    Der C64er hat auch keine extra Tasten für Cursor hoch und Cursor links, die erreicht man nur per

    SHIFT+hoch und SHIFT+links


    sollte ich vielleicht optional ein symbolisches Mapping einbauen ?

    Vielen vielen Dank an Dirk für das umfangreiche Anpassen + Support punkto Emu für das Einbauen in eigene Seiten

    Gerne geschehen ;) , das war auch gut für den vc64web, er ist durch unsere Entwickler-Session noch offener und vielseitiger zu verwenden geworden. Aber du hast die ganze Zeit nicht mit "Dirk" geredet... :D


    Dirk ist der Vorname des Entwicklers des Emulator-Kerns er heißt hier im Forum dirkwhoffmann . Ich habe in Kollaboration mit dirkwhoffmann um den Emulator-Kern eine web-UI gebaut und auch das gesamte Skriptinginterface.



    Retrofan den Fehler von kann ich auch nicht nachvollziehen ... mit keiner meiner Rechner/Browser iphones/iPads ... wie machst du das ? Er kann halt seine lokale Browser-db nicht öffnen, hast du das mit private browsing angesurfed? Vielleicht mal shift reload?

    Also wie das bei dem geht weiß ich nicht.


    Ich weiß wie ich es beim vc64web machen würde...


    1. detektieren ob auf touchscreen gestartet


    siehe Sektion

    But but but what about my iPhone? And what about touchscreen devices ?

    im


    Tutorial https://github.com/dirkwhoffma…c64web/wiki/vc64webplayer


    2. wenn auf touchscreen gestartet, dann ein Actionbutton "Keyboard" z.B. links unten einblenden


    dazu einfach beim Starten einen prekonfigurierten actionbutton mitgeben


    Code
    1. https://dirkwhoffmann.github.io/virtualc64web/#{"openROMS":true,"buttons":[{"position":"bottom:0vh;left:0vw","title":"tastatur","script":"action('keyboard')"}]}




    3. bei Klick kommt die spezielle C64-Tastatur und man kann auf dem Touchscreen load"$",8 tippen

    Lutz G habe vc64web für dich angepasst


    Man kann jetzt beliebige roms auch die originalen beim Aufruf preloaden lassen. Und außerdem habe ich ein neues preconfig setting eingeführt, damit der Benutzer wirklich auch manuell load"$",8 etc... tippen muss.



    für uns habe ich auch das folgende Tutorial geschrieben...


    https://github.com/dirkwhoffma…b/wiki/vc64webplayer_roms



    melde dich wenn etwas unklar ist, oder wenn du nicht weiterkommst. Ich helfe dir gerne weiter das bei dir einzubauen. :thumbup:

    Endurion :thumbup: Ich schreib uns ein kleines Tutorial, welches den build prozess genauer beschreibt. Eine ganz rudimentäre Kurz-Anleitung steht zwar schon im Wiki unter summary->how to build and run it in a web browser


    https://github.com/dirkwhoffmann/virtualc64web/wiki/summary


    aber die ist schon sehr minimal ... das geht besser ! Ich muss nur Lutz G noch grad mit dem automatischen preloaden von ROMS versorgen ... bei mir lokal läuft es schon , ... noch ein bisschen testen und dann kann ich es deployen .... danach ist dann das Tutorial für das selber bauen dran.:)

    Endurion ich habe nochmal überlegt aus welchen Gründen es vielleicht eine "Unsitte" sein könnte Javascript cross origin zu nutzen, und was du damit meinst ... und mir sind jetzt doch zwei Aspekte eingefallen


    1. Abhängigkeit von einer anderen Domäne hier github pages...

    könnte mal irgendwann abgeschaltet werden ... sehr unwahrscheinlich ... aber trotzdem, dann wäre deine Seite kaputt


    2. Ich könnte irgendwas in den Emulator einbauen was da nicht reingehört und auf irgendeine andere Seite weglinken oder so ... Hmm sehr sehr unwahrscheinlich ... ich meine ich könnte es auch so machen, wer schaut schon tausende Zeilen code danach durch .... aber trotzdem


    das sind die zwei Aspekte die mir einfallen, die gegen das cross resource sharing uter Umständen sprechen könnten...


    daher kommt bald noch ein Tutorial wie man seinen eigenen vc64web builded und deployed:)



    für cross resource sharing spricht jedoch, dass

    1. sich der Emulator automatisch updaten kann... kann sich automatisch an neuere Browser anpassen...

    2. mit weniger Aufwand in die eigene Seite einzubetten...




    Fazit: Beides ist möglich und es wird ein Tutorial für beides geben ...

    Endurion


    klar du darfst :) einfach die wesentlichen Dateien https://dirkwhoffmann.github.io/virtualc64web/ von kopieren und auf deinen eigenen Webserver legen... alles ist frei schau auch hier https://github.com/dirkwhoffma…64web/blob/master/LICENSE



    Ein javascript von irgend einem anderen Server ziehen ist IMHO nicht sauber und eine Unsitte, die unbedingt abgeschafft gehört.


    das wird aber überall so praktiziert... oder ? Nehme zum Beispiel das alte jquery.js oder andere modernere JS-Frameworks, die kommen auch alle in einer CDN Version daher.


    siehe auch https://en.wikipedia.org/wiki/Content_delivery_network


    Das machen die hauptsächlich um ihre Frameworks auf starke international verteilte Server zu legen und somit kleinere individual Server die in irgendeiner Ecke der Welt stehen zu entlasten.


    Was die aber empfehlen ist beim Einbetten einen Integritätscheck zu machen ... also ob da was verändert wurde an der Datei...


    Für unseren vc64web müsste man dann noch folgende Attribute mit dazugeben.

    Code
    1. <script src="https://dirkwhoffmann.github.io/virtualc64web/js/vc64web_player.js" integrity="sha384-G5drlFfSQ3paMVjiv7Cryo5c+PlkTqUQd/afxguL9N9NOraQhEma14b8mRw3C5WP" crossorigin="anonymous"></script>


    aber das hieße jedoch, das ich diese Datei selber auch nicht mehr updaten (fehlerbereinigen) könnte ohne den Integrity-Schlüssel zu brechen...


    Hmm dann müsste ich mit Versionsnummern arbeiten...


    Wie Retrofan sagt ... hatte ich mir das ganze eher so vorgestellt, dass ich nach und nach noch Verbesserungen einbringe. Diejenigen, die das Script crossreferenzieren würden dann automatisch in den Genuss der Verbesserungen kommen. (Aber wie gesagt, einfach die wesentlichen Dateien kopieren und bei dir auf den Webserver packen ist auch völlig Ok für mich.)



    Kann man Deine Lösung möglichst plain nutzen - ohne Schaltflächen, die sich auf meiner sehr rudimentären Seite nicht so gut machen

    würden? Kann man da vielleicht was hiden?


    :) da gibt gibt es bereits ein preconfig flag für navbar=hidden


    https://dirkwhoffmann.github.i…enROMS=true#navbar=hidden



    hier eine Auflistung der bisherigen preconfigs

    https://github.com/dirkwhoffma…web/wiki/simple_preconfig



    prinzipiell kannst du jede Datei einbinden ... aber eine .d64 erfordert das 1541.rom file. Ich schau mal heute nachmittag nach wie du das Commodore-Romfile automatisch von deinem Server in den vc64web reinladen kannst. Alternativ bau einfach ein .prg, oder .t64 oder .crt das läuft auch ohne 1541 und du kannst die openRoms nutzen. Ich melde mich dazu in Kürze nochmal, wie du originale ROMS preloaden kannst anstelle der openRoms ...

    ich habe ein ausführliches Tutorial geschrieben, wie man den vc64web sehr einfach auf seine eigene Webseite einbindet.


    Ich beschreibe anhand verschiedener Usecases, Codefragmente und echten Beispielseiten zum Austesten, was man alles konfigurieren kann.


    Unter anderem:

    - wie Joysticks vorkonfiguriert werden können, und wie man eine automatische Weiche für Joystickemulation per Keyboard oder per virtuellem Touchjoystick vorkonfigurieren kann.

    - wie man Tasten umbelegt

    - wie man Buttons einblendet


    Ich glaube das passt hier in diesen Thread ganz gut hin :rolleyes:


    Tutorial:


    https://github.com/dirkwhoffma…c64web/wiki/vc64webplayer

    Gibt es den Emulator eigentlich auch als kleines Komplettpaket für eigenes Embedden? Ich möchte gerne einige C64-Spiele im Browser spielbar haben, und da alles, wie es sich gehört, von meinem Webspace laden.


    Endurion

    guter Punkt :thumbup:


    ich habe ein ausführliches Tutorial geschrieben, wie man den Emulator sehr einfach auf seine eigene Webseite einbindet.


    https://github.com/dirkwhoffma…c64web/wiki/vc64webplayer

    ich beschreibe anhand verschiedenen Usecases, Codefragmenten und echten Beispielseiten zum Austesten, was man alles so machen kann.


    Auch wie Joysticks vorkonfiguriert werden können, und wie man eine automatische Weiche für Joystickemulation per Keyboard oder per virtuellem Touchjoystick vorkonfigurieren kann.


    Falls etwas nicht ganz so klappt einfach oder du Verbesserungsvorschläge hast, oder auch einfach nur eine Frage, dann einfach melden... Dann kann ich das Tutorial anpassen:whistling:...


    Hier eine Beispielseite wo verschiedene C64Programme nach dem Rezept aus dem Tutorial eingebunden wurden https://dirkwhoffmann.github.io/virtualc64web/doc/about.html