Beiträge von 1570

    64erGrufti Beim verlinkten Modul vom BTT ist das Rad sehr leichtgängig, wieso auch nicht, eine Lichtschranke macht ja keinen mechanischen Widerstand. Und wenn da irgendwas klemmt, dann erzeugt das Rad ja auch keine Impulse, also pausiert die ganze Sache. Weiß also nicht, von was Du da redest...

    Ist das gleiche, ob was drin steckt, leer ist oder wie auch immer, er erkennt es.

    Sorry, aber das glaube ich nicht. Das zu erkennen wäre nämlich recht schwierig.

    Wie bitte? Da kommt ggf. ein gummiertes Rad dran mit optischem Encoder, fertig. Falls sich das Filament nicht mehr bewegt, stoppt die Firmware dann.

    https://github.com/bigtreetech…filament-detection-module (V2)


    Kostet um die 10€ bei Ali.


    Bei Klipper heißt die entsprechende Konfigurationsoption "Motion Sensor":

    https://www.klipper3d.org/Conf…ml#filament_motion_sensor

    Sd2IEC könnte mir nie gefallen wegen der umständlichen Benutzung und es kann keine CRT, Easyflash Dateien benutzen.

    Ja ne echte 1541 ist auch scheiße, die kann ja keine CRTs. X/


    Klar hat sd2iec so seine Eigenheiten (insbesondere ist es eben bei Demos etc. nur beschränkt kompatibel zur 1541), dafür ist es im Rahmen von dem, was es kann, viel schneller als 1541 und 1541U, insbesondere im Zusammenhang mit JiffyDOS im C64. Die 1541U schneckt da mit 2,5k/Sek (6x) vor sich hin, sd2iec schafft währenddessen 8,6k/Sek (21x). Insofern finde ich die Kombi "echte 1541" (für das Feeling und Kompatiblität) plus sd2iec viel netter als eine relativ teure 1541U.


    Oh umbauen braucht man für einen JiffyDOS-KERNAL eigentlich im C64 nicht zwingend was, man kann im Zweifelsfall ein EF3 nehmen, das kann auch KERNALs ohne Umbauten einblenden.

    (warum kann das KFF2 eigentlich keinen externen KERNAL? Sollte eigentlich technisch zu machen sein...)

    Ich habe den RAM-Test des Dead Test 006 entsprechend etwas erweitert (schon witzig, der "RAM Test 4K" war da eigentlich unnötig, weil schon der vorgelagerte RAM-Test - noch ohne eingeschalteten Bildschirm - das Gleiche macht. Der Test 4K hat noch nichtmal den Charset wiederhergestellt, wenn ein Fehler aufgetreten ist - das wurde also vermutlich nie getestet...).


    Ich hab kinzi angeschrieben, wie er das mit Veröffentlichen davon hielte, mal abwarten. Falls nichts kommt, kippe ich das irgendwo mit entsprechenden Credits ab, steht ja auch so im README letztendlich drin.

    Hmja, danke, wobei man sich dann natürlich fragen kann, wieso niemand einfach Kondensatoren an die EPROM-Ausgänge rangepackt hat, wenn das das Problem doch löst.

    Ich frage mich auch, inwiefern eine langsame Slew Rate Probleme mit mehreren aktivierten Ausgangsleitungen beheben soll, die ja noch ein separates EPROM-immanentes Problem sein sollen, die nichts mit dem "Durchreichen" der Adress-Glitches am Input zu tun haben.

    Vielleicht hat Eslapion die Glitches auf ROML schlicht auf die Schnelle im Klassenzimmer nicht gesehen, hier traten die auch eher selten auf. Wieviel Speicher hatte wohl sein 1GS-LA von um die Jahrtausendwende? Und hatte er 2008 schon das Super Zaxxon-Modul auf dem Schirm?

    Naja egal eigentlich, ich denke, EPROMs exhumiert hier niemand mehr so oder so. Vielleicht schaue ich mit meinem LA nochmal, inwiefern man die Input-Glitches sichtbar machen kann, aber ohne Original-PLA ist das etwas zäh und so spannend insgesamt dann auch wieder nicht...

    Die größte Herausforderung bei der Entwicklung eines modernen PLA-Ersatzes besteht meiner Meinung nach darin, dass dessen Verhalten in allen Situationen so exakt wie irgend möglich dem Original entsprechen sollte. Auch dann, wenn sich das Original schon irgendwie "seltsam" verhalten hat.

    Ich bin mir nach etwas Überlegen gar nicht mehr sicher, dass der Widerstand ein Workaround in dieser Form ist. Wie schon in Posting #1 geschrieben ist die Eingangsimpedanz beim RP2040 höher als z.B. bei den sonst üblichen CPLDs; entsprechend ziehen letztere auch an den Adressleitungen stärker als der RP2040 hier. Möglich, dass dieses eigentlich bei den CPLDs unschöne Verhalten genau die Glitches an den Inputs maskiert (also zwei Fehlverhalten in Summe ein meist korrektes Ding ergeben). Der Widerstand macht dann auch nichts anderes.


    In dem Kontext scheint es mir auch möglich (wenn auch nicht unbedingt wahrscheinlich!), dass Eslapion einfach Mist gemessen hat mit den EPROM-Glitches. Insbesondere wundert mich auch, dass er in seinem Talk behauptet, dass es einige "gute" EPROMs ohne Glitches gäbe. Wie soll das gehen? Benutzen die magisch andere Technologie? Vielleicht machen deren Eingänge einfach mehr Last oder sonstwas und maskieren so das Problem.


    Buszugriffe (DMA, Sprite, Bad-Lines etc) müssen im genau identischen Taktfenster erfolgen wie beim echten C64

    Die komplette State Machine des VIC-II muss in der exakt richtigen Reihenfolge implementiert werden

    Der Raster Counter muss absolut syncron sein

    IRQ's müssen den absolut zeitgleichen C64 Effekt einschließlich der Side-Effects (mehr dazu gleich) unterstützen

    Jeder Lese und Schreibvorgang auf den VIC muss im selben Takt die selbe Wirkung wie auf dem C64 haben

    Ja, das ist alles viel Fleißarbeit bei der Implementierung, machen VICE und Denise und z.B. Kawari aber auch allesamt exakt, bzw. wenn Bugs gefunden werden, werden die halt gefixt. Kawari z.B. simuliert intern pro Takt mehrere Unterzyklen, damit bei Zeitkonflikten die originalen Prioritäten eingehalten werden.

    Der RP2040 zieht hier rund 80mA, das ist so an der unteren Grenze der alten PLAs. Ein CPLD verbraucht weniger, klar.


    Die digitalen GPIOs des RP2040 haben keine 5V-Zertifizierung, in der Praxis passt das schon (Info und Tests). Clamping-Dioden gibt's nur an GPIO26-29 (wegen der ADCs), die hier aber nicht benutzt werden.


    Das hier soll auch nicht die ultimative kommerzielle zertifizierte hochgelobte sinnhafte PLA-Ersatzlösung sein oder werden, mit der man dann den Kernreaktor-Zentral-C64 wieder instandsetzt...

    Man kann es auch als "Hey, beim letzten Projekt hatten wir schon nicht genug Ahnung, existierende FPGA-Sourcen so zu patchen, dass dabei was Sinnvolles rauskommt², da machen wir doch das nächste Projekt komplett als FPGA!!1!" interpretieren.


    ² Richtige dedizierte 240p-Modi? Vernünftiges Scanline-Blending? Bzw. genaugenommen könnte man vermutlich auch schauen, was man mit dem VERA-Modul alleine hinbekäme, wenn man mal die Axt ans VHDL anlegt. Aber dafür gibt's halt kein/wenig Geld.

    Markus64 Also bei "von sich aus glitchenden" EPROM-PLAs bringt das nichts, vielleicht bei anderen wackeligen CPLD-PLAs? Auf der einen Seite denke ich "eher nicht", auf der anderen Seite wundere ich mich wie gesagt, wieso man nicht mit der Original-PLA auch schon Glitches sieht, so wie das gebaut ist. Einfach ausprobieren. Sagen wir 6,8k sind ja fix testweise zwischen A15 und GND geklemmt.

    Mit Super Zaxxon schaue ich nochmal, hab kurz mit dem Scope geschaut, also Glitches sehe ich da keine. Schade, dass das bisher niemand wirklich analysiert und dokumentiert hat, selbst Eslapions Talk hat keine Signal-Traces drin. :/

    Tatsächlich glitcht ROML sehr selten, deswegen hatte ich das erst nicht gesehen. Und wenn man schonmal dabei ist, habe ich etwas weiter gesucht, denn wie gesagt KÖNNEN bei dem Ansatz hier die Ausgangleitungen gar nicht einfach so frei glitchen (anders als wohl bei einigen EPROMs).


    Also weiter mit dem Logic Analyzer nachgesehen und auch die Eingangleitungen der PLA angeschaut. Nun ist's ja so, dass A12-A15 bei Phi Low - wenn der VIC auf den Adressbus zugreift - über Widerstände auf High gezogen werden. Beim Übergang zu Phi High/AEC High übernimmt wieder die CPU die Kontrolle über den Adressbus, ggf. wechseln also die Adressbusleitungen den Zustand "gleichzeitig" zu dem Zeitpunkt. Tun sie aber natürlich nicht tatsächlich perfekt gleichzeitig, und meine Theorie ist, dass dann selten kurzzeitig $8xxx oder $9xxx vom Adressbus gelesen werden kann bei AEC aktiv/Lesezugriff/EXROM aktiv. Das ist aber eben auch Ansage an die PLA zum Aktivieren von ROML. (im Anhang ein Trace von einem Glitch und den Signalen im Steckmodul, wobei der aufgenommene Glitch an der Stelle kein Fehlverhalten im Steckmodul auslöst und die Sample-Rate zum Aufschlüsseln der "falschen" Adresse leider nicht reichte)


    Keine Ahnung, wieso die Original-PLAs in dem Fall nicht am Ausgang glitchen, vielleicht sind die einfach zu träge an den Eingängen oder haben so wenig Fan Out an den Ausgängen, dass die Leitungskapazitäten die Glitches maskieren oder die Glitches sind kurz genug, sodass das D-Flipflop im Zaxxon-Steckmodul nicht darauf reagiert.


    Jedenfalls gibt's hier einfachen Fix: Einen großzügig dimensionierten Widerstand zwischen A15 und GND, damit A15 etwas schneller als A14/A13/A12 Richtung Low geht, und schon geht das.


    Super Zaxxon läuft so auch mit p64oPLA. :)

    Das kostete 275 Dollar

    Vollbestückung und wenn man alle Teile einzeln (ohne Mengenrabatt) bestellt mag das sein.


    Wie man ein richtiges Community-Projekt macht, hat z.B. der Gigatron gezeigt (mit einer ähnlich großen BOM übrigens). Den gab es gar nicht anders als als DIY-Kit (um die 100€), und das hat auch geklappt.

    Ich habe heute in dem Video auch die zweite Generation gesehen. Ja, vom Standpunkt der Fertigung her ist diese Version wesentlich besser.

    Ja hat Murray und Co die eigene Lötstraße beim X16 (die höchstwahrscheinlich finanziell und vom Aufwand her Null Sinn gemacht hat, aber offensichtlich wollten sie mal mit sowas spielen) am Schluss doch nicht soviel Spaß gemacht? Warum haben sie dann eigentlich kein Selbstbau-Kit rausgebracht? Das teuerste Teil am X16 ist der FPGA für unter 10€. Was mögen die Bauteile insgesamt kosten? In Stückzahlen keine 100€ wette ich.