Posts by Henning

    Brauchst nen GAL Assembler und nen Eprom Brenner, der halt GALs kann. Der tl866cs kann einige Typen, macht aber mit bestimmten Herstellern Probleme.

    Mit dem tl866 kriegst du auf jeden Fall die originalen GAL16V8B von Lattice (werden allerdings nicht mehr hergestellt) oder diese 16v8B-kompatblen GALs von Atmel programmiert.


    Eine mögliche Alternative dazu ist, ein Eprom als Logik-Baustein zu verwenden, wie es zum Beispiel mit den Eprom-PLAs gemacht wird. Ob das vom Timing her dann praktikabel ist, müsste man genauer prüfen. Aber schließlich ist ein Eprom auch nur ein Logik-Baustein, der auf einen bestimmten Zustand der Eingänge mit einer definierten Ausgabe antwortet.

    Bin als Europäer nach China, um dort die Prototypen eines Nutzfahrzeugs (mit einer blauen Pflaume vorne dran) zu verkabeln.
    Wollte gleich wieder abreisen...nicht wegen dem Auto, sondern wegen der Wechselstrom-Orgie an Straßen, Masten, Gebäuden.

    Ja, kann ich nur bestätigen, das ist wirklich abenteuerlich, was da so an Verkabelung zu sehen ist.


    Ich habe mal mit meinem Kumpel in Peking in einem "Restaurant" (also einer Garküche mit Sitzplätzen) gesessen, als uns auffiel, dass sich vor dem Restaurant eine Menschenmenge sammelte, die interessiert nach oben schaute... wir sind dann lieber mal raus, um zu sehen, was da los ist. Auf dem Dach stand ein Typ und schlug tatsächlich mit einem nassen Lappen auf einen brennenden Kabelknoten ein. Nachdem er den Brand tatsächlich gelöscht hatte, ohne dabei zu sterben, zerstreuten sich auch die Menschen und gingen offenbar unbeeindruckt wieder ihrer Wege. Essen war allerdings lecker.

    Auf dem C128 kann man aktuell die Adresse D500 nicht nutzen, da sie von der MMU des C128 belegt wird. Dies gilt leider auch fuer den C64 Modus des C128. Mit der Spezialfunktion und einem Extrakabel wird dieses Problem fuer den C64 Modus behoben.

    Könntest du deine Lösung kurz beschreiben? Würde die auch ohne FPGA funktionieren? Ich habe zwar eine generelle Lösung gefunden, allerdings muss dabei U3 auf dem C128-Board durch einen GAL ersetzt werden.

    1.) MIXSID ist offensichtlich nur für den C64 konzipiert. Ich finde auf der MIXSID-Seite jedenfalls keine einzige Erwähnung zur Boardkompatiblität für C128 (D/DCR). Sollte man nicht unerwähnt lassen.

    Ja, auf der Website steht dazu (noch) nichts. Der MixSID läuft mittlerweile allerdings auch erfolgreich im C128, bis auf das hier beschriebene Problem samt der dazugehörigen Lösung:


    https://github.com/hbekel/MixSID/tree/master/firmware/c128


    Ich zitiere mal: "Es wurde kein Versuch unternommen den Benutzer von derVerantwortung für die korrekte Konfiguration seiner SIDs zubefreien. Der Benutzer, und nur er selbst, konfiguriert dieVersorgungsspannung, die Filterkondensatoren und Ausgangswiderständemit Hilfe von Jumpern." Hmm...,

    Ja genau, so ist es :) Da man schon ziemlich weit gehen muss (siehe SIDFX), um ein verlässliches Rundum-Sorglos-Paket zu schnüren, habe ich mich für das andere Extrem entschieden. Allerdings schreibe ich weiter:


    "Um dem Benutzer hierbei bestmöglich zu unterstützen wurde aufumfangreiche und erschöpfende Dokumentation Wert gelegt."


    Die SIDFX Dokumentation sagt:


    "In manual mode the user may set the SID type to 6581, 8580 or NONE, forcing SIDFX to detect and report a different type. This is only recommended for expert users, because an incorrect setting may cause damage to you SID chip.



    Note: Manual SID Type configuration is currently disabled."


    Die manuelle Einstellung des SID-Models ist kurz vor der Fertigstellung noch deaktiviert worden. Nicht, weil man selbst Experten diese Möglichkeit verwehren wollte, sondern nachdem wir die Enwickler darauf hingewiesen haben, dass es vielleicht keine gute Idee ist, das SID-Model über eine öffentlich zugängliche Software-Schnittstelle hart einstellen zu können, wenn es keine physische Möglichkeit gibt, diese Funktion nach erfolgter Konfiguration wieder zu deaktivieren.


    Denn als böswilliger Programmierer hätte ich aus jedem beliebigen C64-Programm heraus über die Schnittstelle einfach mal alle als 8580 erkannten SIDs auf 6581 stellen können und dann mal schauen können, wie lange so ein 8580 eigentlich 12V überlebt.


    Und so wäre der Mythos vom Killer-Poke zumindest für SIDs beinahe doch noch wahr geworden... ;)

    Kann man sicher machen, wäre allerdings a) eine recht spezialisierte Lösung und b) müssten Drehencoder und Display wieder irgendwo eingebaut werden.


    Gibt es einen bestimmten Grund, warum du zur Kontrolle und Anzeige nicht meinen Keyman und mein Overlay verwenden willst? Das Reprom ist unter anderem auch deshalb so simpel gehalten weil Kontrolle und Anzeige (wenigstens im Rahmen meiner "Produktpalette") modular von Keyman und Overlay übernommen werden können, ohne dass externe Schalter, Drehregler oder Displays im Gehäuse verbaut werden müssten.


    Soweit ich sehe schalten die Jumper für die Geräteadresse des SD2IEC einfach auf GND, ließen sich also ebenfalls über den Keyman mittels Tastenkombination schalten.

    Ja, damit sollte es auch gehen, Hauptsache ist ISP. Allerdings hat es bei mir sowohl mit meinem TL866 mit ISP als auch mit meiner alten Parallelportlösung nicht geklappt, in beiden Fällen wurde der Atmel nicht erkannt, obwohl alle nötigen Verbindungen da waren. Frag doch mal den Entwickler, wie/womit er das macht.

    Hallo Henning, es sollte auch nie so rüber kommen, dass der MixSID daran schuld sei.

    Habe ich auch nicht so genommen, hätte ja aber durchaus auch so sein können :)

    Um den Faden hier nochmal zum Abschluss zu bringen:


    Das beobachtete Verhalten resultierte tatsächlich aus der zu konservativen Einstellung des Schwellenwertes des Brown-Out-Detectors des Atmels auf dem Joystickswitcher selbst. Stellt man dessen Schwellenwert nicht auf 4.3V sondern auf 1.8V gibt es keine Startschwierigkeiten mehr, egal ob mit oder ohne Hardware-Erweiterungen.


    Die Beobachtung "Wenn ich A wegnehme, funktioniert B" berechtigt also nicht notwendigerweise auch zu der Annahme, dass A die Ursache für das Versagen von B ist.


    Siehe auch https://xkcd.com/552/ :)

    http://henning-bekel.de/keyman64/#binaries


    Der link von dukestah war der Release-Post.


    Von welcher Version aus willst du updaten? Am einfachsten ist es, das kombinierte Image aus bootloader und application mit einem externen Programmiergerät (z.b. TL866) auf den Atmel zu schreiben. Zu Fuß sollte aber eigentlich auch gehen.


    keyman64 boot bittet die Anwendung, in den Bootloader zu wechseln. Wenn du schon im Bootloader bist, sollte der client das eigentlich erkennen.


    Warum sucht das aktuelle AVRdude eigentlich immer nach dem vendor fischl.de ???


    Weil der USBasp im Original von Herrn Fischl ist.

    Das liegt daran, dass du aus irgendeinem Grund immer wieder einen neuen Screen definierst.


    Jeder Screen hat eine eigene Kopie aller Zeilen. Welche Zeile am Ende aus welchem Screen tatsächlich angezeigt wird, hängt davon ab, welcher Screen der bei der sukzessiven Auswertung der Kriterien und Screen-Modi zuerst als aktiviert erkannt wird und die Zeile für sich beansprucht.


    In diesem Fall beansprucht dein Kernal-Screen die erste Zeile zuerst. Lösche mal alle "screen always" bis auf die erste Zeile, dann sollte es dem entsprechen, was du erwartest.


    Siehe auch https://github.com/hbekel/over…lob/master/overlay64.conf als Beispiel für die Verwendung von screens.

    In einem nachträglich bearbeiteten Beitrag auf die nachträgliche Bearbeitung eines früheren Beitrags verweisen?


    Relevant ist außerdem eher die Zeile zuvor:


    E: [pulseaudio] pid.c: Daemon already running.


    Stichworte: /dev/dsp, snd_pcm_oss oder alternativ ./configure --with-pulse

    Wie gesagt, vice scheint zumindest mit --without-pulse kompiliert worden zu sein. Das solltest du verifizieren und falls nötig vice selbst bauen. Keine relevanten Meldungen von vice auf der Konsole?

    ich hab jetzt alles probiert, geht nicht (außer `dummy`).
    pulse und alsa habe ich gar nicht, sondern uss, dummy, ..

    Dann wurde vice für deine Distribution wohl ohne alsa und pulse gebaut... du solltest herausfinden, warum.


    Läuft denn nun bei dir pulse-audio oder nicht?

    "sound: error initializing `uss' " ?

    Settings -> Sound Settings -> Sound device name ...


    Entweder "pulse" oder "alsa" wählen, je nachdem, ob deine Distribution pulse audio verwendet oder nicht. Dann nochmal Settings -> Sound Settings -> Enable sound playback anhaken.