Posts by emulaThor

    Was mir jetzt klar geworden ist: Bestandteil von Teensyduino 1.54 ist ein kleines Tool namens teensy_size.exe (exe unter Windows).

    Dieses schaut sich die *.ino.elf-Datei an, wenn der Build fertig ist, und schlägt Alarm, wenn darauf basierend eine unpassende RAM-Nutzung erkannt wird. Das eigentliche Kompilieren und Linken ist aber erfolgreich durchgelaufen und das Binary SIDKick.ino.hex liegt auch vor und man könnte dieses auch einfach mal auf den Teensy flashen und schauen, was passiert. :)


    "C:\\Program Files (x86)\\Arduino\\hardware\\teensy/../tools/teensy_size" "C:\\Users\\username\\AppData\\Local\\Temp\\arduino_build_547696/SIDKick.ino.elf"


    Mit Teensyduino 1.53 gab es dieses Checktool noch nicht, ist mein Verständnis, also müsste man mal manuell ein *.ino.elf, welches mit Arduino IDE 1.8.13 und Teensyduino 1.53 kompiliert worden ist, mit teensy_size checken lassen, um zu sehen, ob dort ggf. auch die gleichen Warnungen sichtbar werden, wenn man "Optimize: Fastest" auswählt.


    https://github.com/PaulStoffregen/teensy_size

    Update: Hatte vergessen, "Optimize: Fastest" einzustellen und dann bekomme ich auch Probleme:


    pasted-from-clipboard.png


    Ich kompiliere in der Arduino IDE normal unter Linux, wegen des beschriebenen Problems habe ich eben nochmal den Quellcode von SIDKick kompiliert unter Windows 10 mit Arduino 1.8.15 + Teensyduino 1.54 und den nach Frenetic modifizierten Dateien in der Audio-Lib von Teensyduino. Und hier hat es erfolgreich durchkompiliert, so wie auch unter Linux gewohnt.


    EDIT: Ich hatte "Optimize: Faster" belassen, damit geht es, aber "Fastest" ist problematisch, siehe nächstes Posting.

    Code
    1. Opening Teensy Loader...
    2. Memory Usage on Teensy 4.1:
    3. FLASH: code:95156, data:6351424, headers:8712 free for files:1671172
    4. RAM1: variables:406208, code:92216, padding:6088 free for local variables:19776
    5. RAM2: variables:147552 free for malloc/new:376736

    Zu 1: Hört sich nach einem Wackelkontakt im Sockel an, dass SIDKick den Reset nicht mitbekommt. Der Wackelkontakt könnte ja zwischen Teensy und der SIDKick-Platine bestehen. Wird denn ein Reset gemacht, wenn man ins Ultimate-Menü geht? Ich habe kein Ultimate. Der SID-Klang sollte sauber stoppen mit SIDKick bei einem Reset des C64.

    Ich stelle mich gerne als Tester zur Verfügung, allerdings hab ich nur einen 3A+ und leider auch keine Möglichkeit hier eine LAN Verkabelung herzustellen, selbst wenn ich mir einen 3B+ besorgen würde ...

    Danke, Du bist vorgemerkt. Ich melde mich bei Dir, wenn ich Tester brauche für WLAN, sobald ich den Fokus auf dem WLAN-Kernel habe! Ich versuche es etwas zu sortieren, weil es mir sonst selbst zu viel wird bei der verfügbaren Freizeit. (Ich bin derzeit parallel auch noch Tester für neue SIDKick-Features bei Meister Frenetic und das braucht alles seine Zeit.)

    ich hab ein SideKick64 mit Raspi 3B+ und stehe für Netz-Test´s gerne zur Verfügung.

    Danke für Dein Interesse znarF, ich lade Dich in unsere kleine Netzwerktest-Gruppe ein.

    - Networking (ist ja wohl schon in Arbeit wenn ich einige Videos richtig deute :D )

    Für die von mir in Übermut an Sidekick64 angeflanschten Netzwerk-Features habe ich ja einen experimentellen Kernel in Entwicklung, und da habe ich eine kleine Testergruppe gegründet mit ILAH und call286. Tester bekommen von mir experimentelle Netzwerk-Kernels für Sidekick64, um gemeinsam die noch verbliebenen Fehler einkreisen zu können.


    Ich würde mich noch über weitere Tester freuen :), weil es möglicherweise manchmal Kompatibilitätsprobleme mit bestimmten Heimnetz-Router-Konfigs geben könnte (derzeit unklar). Dabei wäre es für das Testen ein klarer Vorteil, wenn ein Raspberry Pi 3B+ vorhanden wäre, weil man damit sowohl Ethernet kabelbasiert als auch WLAN testen kann. Mein Plan war bisher immer, zuerst den Kernel für's kabelbasierte Ethernet zu stabilisieren und danach den WLAN-Kernel zu stabilisieren.

    Leider habe ich keinen Plan von Bare Metal Programmierung für den PI also kann ich auch nicht einschätzen ob solche Sachen umsetzbar sind und wieviel Aufwand so etwas bedeuten würde

    Wenn Du reinschnuppern willst in Bare-Metal-Programmierung, wäre dies eine Möglichkeit.

    Wieviel Luft ist noch nach oben ?

    Ich glaube, diese Frage treibt Frenetic bei seinem Projekt von Anfang an an - und mein Eindruck ist, bei Bare Metal Programmierung muss man es selbst in der Praxis ausprobieren, ob ein neues Feature läuft bzw. welche anderen Features es destabilisieren könnte. Wenn man da mal angefangen hat herumzuprobieren, dann wird die Aussage...


    :Pi:

    für einige Zeit erstmal nur "Das könnte auch mit 'nem Raspberry Pi gehen." sein. :)


    Beispiel: Wenn im Netzwerk-Kernel der Webserver aktiviert wird, geht danach die SID-Emulation nicht mehr korrekt bis zu einem Sidekick-Reboot (weil der Webserver sich in den Circle-Scheduler einhängt, damit er regelmäßig gerufen wird, und dort auch die SID-Emu-Audioausgabe drinhängt).


    In einer aktiven EasyFlash-Emu bzw. Freezer-Emu - ist es timingmäßig so eng, dass die Emulation nicht mehr stabil klappt, sobald ich versuche, den Webserver parallel aktiv zu halten. Glücklicherweise kann dort ein Webserver einfach einschlafen, bis der User wieder im Hauptmenü ist, so dass nichts crasht. Und sobald das Hauptmenü aktiv ist, ist der Webserver wieder zurück. Allerdings muss der Benutzer dafür auch Verständnis haben, das nicht alles parallel laufen kann.


    Und für manche Kombinationen aus Features wird es vielleicht keine stabile Lösung geben, sodass man nicht alle Features gleichzeitig miteinander mischen kann. Wenn man den Webserver aktiv haben will, muss man halt danach auf manche Features verzichten bis zu einem Reboot von Sidekick.

    Je mehr Retro-Hardware man ansammelt, desto mehr geht tatsächlich hin und wieder kaputt - bei mir sind das derzeit leider vor allem Röhrenmonitore. In der Realität hat man irgendwann soviel tatsächlich kaputte Komponenten zu versorgen, dass die genug Aufmerksamkeit brauchen, so dass man sein Misstrauen bzgl. einer vermeintlich insgeheim kaputten, aber effektiv völlig normal funktionierenden 1541-Floppy schnell vergessen hat.


    Oder kurz: Die Feuerwehr fährt zuerst zum größten Feuer.

    Das Posting von Markus64 dazu punkto Vice ist nur ein Joke?

    :nixwiss: Das muss Markus64 beantworten. Ich habe sein Posting so verstanden, dass er zuerst mit Vice rumprobiert hat und danach mit realer Hardware.


    Um mit welchem Emu hat Matthias Kramm dann das Emulator-Capture-Video gemacht?

    Quiss muss sich seinen eigenen Emulator programmiert haben oder einen bestehenden erweitert haben.

    Wenn er so eine Demo erstellt, hat Quiss ja keine Wahl, er braucht er ja seinen eigenen Emulator, damit er sich die Show bei Code-Änderungen schnell ansehen kann. Oder er hat zehn Jahre dran gearbeitet. ;)

    Dass es irgendwie in nem Emu funzen muss, sieht man ja auch auf der Website...

    Ein C64-Emulator emuliert für ein Videobild den VIC-II. In dieser Demo ist kein VIC-II involviert. Und eigentlich auch kein C64, wenn man es vereinfacht sagt. Deshalb kann ein Vice-Emulator (Stand heute) das nicht emulieren, weil die 1541 bisher noch nie Bilder ausgegeben hat.


    :bgdev:bgdevDieses von Jack Tramiel erdachte Feature blieb 40 Jahre lang von allen Commodore-Usern unentdeckt. Grund: Sonst hätten die Leute den teuren C64 nicht noch zur teuren 1541 dazugekauft. :bgdev:bgdev


    Quiss muss sich seinen eigenen Emulator programmiert haben oder einen bestehenden erweitert haben.


    Pi1541 wäre als Standalone-Floppy-Emulator eigentlich prädestiniert dafür, diese Demo zu emulieren.

    Das finde ich sehr pfiffig mit der Einschränkung, dass das Bild auf Deinem Miniatur-Screen farblich an einen Aura-Borealis-Remix des intendierten Bildsignals erinnert. :)


    Wobei ich sagen muss, dass der visuelle Teil der Demo bei mir auch nur auf einem meiner beiden derzeit funktionierenden Commodore-CRTs gut dargestellt wird. Auf dem anderen kommen an einigen Stellen Kurven rein in die Linien, die nicht da sein sollten.

    Ich habe die Demo ja wahrscheinlich in den letzten Tagen 25 mal laufen lassen. Dabei habe ich erstmal festgestellt, dass bisher noch keine Hardware kaputt gegangen ist, glücklicherweise. :) Die zweite Erfahrung war: Wenn die Demo "springt", vergleichbar mit einer Schallplatte früher, war das bei mir an zwei Stellen bisher - einmal ganz am Anfang und einmal vor dem "Ende". Verantwortlich dafür waren immer die Disketten und deren Inhalt. Hier ist meine Erfahrung: Ein mehrmaliges Neuschreiben des D64 Disketten-Images (auch auf die gleiche Diskette) kann irgendwann zum Erfolg führen. Ich habe sowohl mit OpenCBM+xum1541 als auch mit Fluxengine+PC-Laufwerk die Bilder auf die Diskette geschrieben. Und ich habe mit 3 verschiedenen 1541 II getestet gestern Abend. Verantwortlich für Sprünge war immer die Diskette, nie das Laufwerk.


    Ich muss mir im Blog von Quiss mal die Seite durchlesen über das Diskettenformat. Evtl. wird dort eben ein "raw"-GCR-Sektor-Format genutzt, wo mehr "Raum" für Daten genutzt wird als im normalen GCR-Format, also mehr Netto-Bits pro Sektor oder so. EDIT: Quatsch, da es ja als D64-Image kommt, ist es ein Standard-Sektor-Format. Es könnte höchstens sein, dass die Checksummen-Prüfung einfach nicht gemacht wird?


    Das andere Interessante war: Ich hatte gestern auch eine offene 1541 II ohne Oberschale am Start und habe zugeschaut während der Demo. Es ist viel weniger Schrittmotor-Bewegung sichtbar als man sich in der Fantasie ausmalt, wenn man den Sounds zuhört.

    Gestern Abend hat mich Quiss kontaktiert und ausgeholfen - in meinem Video der Demo fehlt ja das Ende der Demo, die letzten 10-20 Sekunden. Nach einigen Versuchen und mehrmaligem Neu-Beschreiben der Diskette(n) hatte ich am Ende dann eine Diskette in der Hand, von der auch das Ende der Demo korrekt gelesen wird. Das führte dann unweigerlich zu einer weiteren Aufnahme, so dass ich momentan vier Video-Versionen in meinem Youtube-Channel habe und die vierte Version zeigt nun auch das Ende der Demo korrekt an. Um nicht mit meinen vielen Videos zu nerven, diesmal versteckt im Spoiler.


    Ich habe die Demo-Diskette nochmal neu beschrieben, Dinge optimiert, alles nochmal neu aufgenommen.... Jetzt ist mein einziges Problem, dass bei mir die letzten 20 Sekunden der Demo nicht kommen. Irgendwann vor dem Ende der Demo loopt es bei mir an eine falsche Stelle der Demo und sie setzt sich endlos fort, ohne ans Ende zu kommen. Das ging auch nicht nach dem Neuschreiben der Diskette weg. Aber ich kann momentan nicht noch mehr Zeit reinstecken.


    So: Soundexperten vor! Bei welchem Video klingt der Sound am besten? Ich habe bei mir nur die Mikrophon-Position verändert, ich habe nichts nachbearbeitet / normalisiert.


    Und ob ein 8580 oder ein 6581 drinsteckt, müsst Ihr selbst rausfinden. :bgdev


    [External Media: https://youtu.be/JKBqIVgbWag]

    Es ist kompliziert, diese Demo aufzuzeichnen. :cursing:


    Ich habe einen neuen Versuch gemacht, da stimmt aber der Ablauf der Videosequenzen nicht mehr 100%ig mit der Originaldemo bei quiss.org überein, das heißt, ich werde die Diskette nochmal neu schreiben in der Hoffnung, dass es dann klappt, und dass ich mir meine 1541 durch das dauernde Freespinning noch nicht kaputtgeschossen habe.


    Das folgende Video hier ist mein dritter Versuch, diesmal liegt das Mikrofon unter der Vorderblende der 1541. Mal anhören, wie das klingt. Weil ich mit dem Video noch nicht zufrieden bin, habe ich es auf nicht öffentlich gesetzt auf Youtube.


    [External Media: https://youtu.be/7VrZKKjnSVY]