Demo-Probleme mit dem Pi-Zero (O/T aus "Wäre jemand an einem kleinen C64 interessiert?")

Es gibt 247 Antworten in diesem Thema, welches 25.075 mal aufgerufen wurde. Der letzte Beitrag (27. Oktober 2020 um 11:05) ist von Kosmas.

  • Bevor ich den C Test mache, habe ich nochmal ein Positiv/Negativ Test gemacht:

    C64C (250469)

    ===========

    Pi1541 3A+

    ----------

    Wintergames.g64 - läuft

    Asylum.D64 - läuft

    Demo - läuft nicht bis zum Ende

    Pi1541 Zero

    -----------

    Wintergames.g64 - läuft

    Asylum.D64 - läuft

    Demo - läuft nicht bis zum Ende

    1541 (1983)

    -----------

    Demo - läuft bis zum Ende

    _____________________________________________________________

    Modular64

    =========

    Pi1541 3A+

    ----------

    Wintergames.g64 - läuft

    Asylum.D64 - läuft

    Demo - läuft nicht bis zum Ende

    Pi1541 Zero

    -----------

    Wintergames.g64 - läuft

    Asylum.D64 - läuft

    Demo - läuft nicht bis zum Ende

    1541 (1983)

    -----------

    Demo - läuft bis zum Ende

  • Es wurde ja festgestellt, dass beim Austausch des 7406 die Demo dann zumindest je nach verwendetem 7406, wenigstens bis zur Hälfte durchläuft.

    das kann ich mir irgendwie nicht vorstellen.
    das es bei den verschiedenen 7406 probleme geben sollte.

    auch nicht mit dem zusätzlichem timing von nur 10 bis 20nS durch einen 7406 / 7407 dazwischen.
    der bus funktioniert doch tausendfach langsammer, der kann doch keine probleme mit ein paar nS haben.

    der bus funktioniert ja über handshake. den kann man problemlos bis zum einzellschritt bremsen.
    egal wieviele geräte da am bus angeschlossen sind und ob da parallel ganz schnelle geräte mit ganz langsammen
    zusammen betrieben werden, es muss immer funktionieren.

    da stimmt wohl etwas mit den routinen im rpi für den iec bus nicht.
    man muss den bus sofort blokieren. wenn man intern beschäftigt ist.
    und ihn nur frei geben, wenn man nun genug zeit hat ihn auf daten abzufragen.
    das alles aber nur, wenn man auch vorher angesprochen wurde.
    damit kein bit oder byte einem entgeht oder viel schlimmer, man die anderen geräte am bus auch noch behindert.

    die einzige zeitkritische sache ist die atn routine, entweder man blokiert den bus, per hardware sofort.
    dann kann man ihn auch solange anhalten, bis man auswerten kann ob man als gerät gemeint war.

    oder man macht es ohne zusatzhardware, commodore hat es aber immer mit einer zusatzschaltung gemacht.
    nur per software und dann muss man zuerst den bus auch anhalten. wie es die hardware macht.
    besonders wenn man ja intern mit etwas anderem beschäftigt ist.

    den bus kann man herunter bremsen. so habe ich es damals gemacht um probleme zu untersuchen.
    oder um eine übertragung am bus mit leds (und schieberegister) zu demonstrieren.
    dazwischen hatte ich damals die 1540, die 1541 und den c64 gab es noch nicht.
    so konnte man von der floppy auch problemlos etwas herunterladen,
    obwohl der bus nur noch im sekundentakt funktionierte. das laden dauerte dann problemlos stunden.

    gruß
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

    2 Mal editiert, zuletzt von axorp (1. Oktober 2020 um 00:41)

  • Ja, ganz verstehen tue ich das auch nicht, jedenfalls ist es so wie es ist :smile:

    Ich habe mir mal den C Schaltplan angesehen, und er ist ziemlich ....verwirrend was die Optik angeht :smile: Denn da gehen gefühlt 20 Leitungen kreuz und quer... deshalb eh ich damit anfange werd ich zunächst mal eine eigene Zeichnung mit einem 7406 machen. Dann kann ich das nachher auf dem Steckbrett besser stecken :wink:

  • bitte bedenken, der 1520 plotter, ist sehr sehr langsamm.
    die 6500 cpu hat nur ein paar byte und das ganze benötigt für alles,
    also den iec bus und das plotten usw. nur 1kbyte. (es kann auch sein das es 2kbyte sind, ist lange her)

    aber 1 oder 2kb für den zeichensatz, die kompletten routinen und den iec bus ist sehr wenig.

    die komplette iec bus routine im vc1520 ist nur ein paar bytes groß.

    gruß
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • gibt es irgendwo ein listing von dem 1520?
    dann könnte man ja da sehen wie es commodore da gemacht hat.

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • Ich habe mir mal den C Schaltplan angesehen, und er ist ziemlich ....verwirrend was die Optik angeht :smile: Denn da gehen gefühlt 20 Leitungen kreuz und quer... deshalb eh ich damit anfange werd ich zunächst mal eine eigene Zeichnung mit einem 7406 machen.

    die vorhandene output schaltung zum bus hin, mit den 7406 hat er gelassen.

    und anstatt dem level shifter, für die leitungen die vom bus zu den rpi inputs gehen,
    dafür hat er die restlichen 7406 mit den orangenen pull ups genommen.

    lg
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • 1kbyte. (es kann auch sein das es 2kbyte sind, ist lange her)

    Der 1520 hat 2 kB ROM, in dem sich auch noch der Zeichensatz befindet - zusätzlich zu den Busroutinen und der Ansteuerung der Mechanik. Das ist alles innerhalb des 6500-Microcontrollers.

    gibt es irgendwo ein listing von dem 1520?

    Das ROM wurde vor einiger Zeit gedumpt, bei Google solltest du fündig werden.

    Ich habe mir mal den C Schaltplan angesehen, und er ist ziemlich ....verwirrend was die Optik angeht

    Das liegt daran, dass die Schaltpläne für A und B schon sehr gewöhnungsbedürftig sind und ich einfach in den "B" reingeschmiert habe. :biggrin:

  • Das ROM wurde vor einiger Zeit gedumpt, bei Google solltest du fündig werden.

    danke kinzi,

    das sollten sich die programmierer aber mal ansehen.
    um daraus zu lernen und die iec bus routine so korrekt und schön klein zu machen, meinte ich.

    lg
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • Nach aussen 5V... nach innen 3.3V

    ja, bitte aber innen (an den 3,3V) 10kohm benutzen. da verbratest du mit den 1kohm unnötige 14mA.

    nur am bus die 1kohm.

    leider muss ja auch die rpi software geändert werden, die macht wohl die ganzen probleme.
    aber bitte mal mit deinem board testen, warum es da bei einem probleme geben soll.

    lg
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

    3 Mal editiert, zuletzt von axorp (1. Oktober 2020 um 01:30)

  • Obwohl im Schaltplan des 250469er auf Data und Clock auch 1K wirken.

    ja da gehören die 1k auch hin. die am bus.

    an den data und clk inputs gibt es keine extra widerstände.
    das geht doch alles direkt an die cia?

    hier aber hat der kinzi die restlichen freinen 7406 treiber als level shifter von 5V auf 3,3V benutzt.
    und da die 7406 open collector sind und er wohl nicht wusste ober der rpi programmierer da die internen
    pull ups auch eingeschaltet hat, hat er die externen pull ups zur sicherheit dazu gemacht.

    so würde ich es aber auch bei einem rpi machen, siehe oben in dem link, da wird es auch empfohlen.

    lg
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • an den data und clk inputs gibt es keine extra widerstände.

    Laut C64 Schaltplan hängen PA6 und PA7 (Eingänge) an 1K, also am Ausgang des 7406.

    Einmal editiert, zuletzt von Matthias (1. Oktober 2020 um 02:02)

  • bitte mal auch testen, die proble mit dem rpi haben.

    1. die led mit 1000 ohm ansteuern, damit der arme rpi nicht da die 17mA treiben muss.
    wenn er nur an allen ios insgesammt 50mA treiben kann, dann ist es doch schon ein drittel.
    dann kann es doch sein, das er intern irgendwie drucheinander kommt.

    nun kann es auch sein, das ihm die interne spannung nicht mehr ausreicht
    um einen echten ttl pegel immer und stabil hinzubekommen.
    die ja immer und jederzeit für die korrekte ansteuerung für den 7406 benötigt wird.
    wenn der rpi highpegel da nur ganz kurz zusammen bricht oder den high pegel nicht rechtzeitig erreicht,
    dann macht der 7406 daraus ja ein low signal am bus.

    bitte an out_data und dem out_clk, dem signal aus dem rpi, um den 7406 anzusteuern.
    zusätzliche pull ups zu machen. damit der rpi 3,3V high pegel zusätzlich angehoben wird.
    so wird der rpi port ja auch bei high zusätzlich intern entlastet.
    ich würde da einen 10 kohm mal nehmen, wenn es nichts bringt dann mal es mit 4,7kohm testen.
    aber keine 1kohm, denn dann hat der rpi, bei low, ein unnötiges treiber problem.
    nur wenn es mit 10k, 4,7k nichts bringt, dann würde ich es da mit 1kohm probieren.

    diesen trick, am eingang, mit einem zusätzlichen pull up, kann man auch an den 74hc ics anwenden,
    wenn man keinen 74hct hat. so bekommt der nicht ttl kompatibler 74hc eingang durch den pull up
    eine höhere spannung und auch schneller von einem ttl ausgang.

    so hoffe ich nun, das dieses komische verhalten hier, bei manchen leuten,
    mit den beiden zusätzlichen pull ups an out_data und out_clock, eine abhilfe bringt.

    gruß
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • nur wenn es mit 10k, 4,7k nichts bringt, dann würde ich es da mit 1kohm probieren.

    Ja, mal schauen :smile:

    Wäre insofern nicht schlecht, weil man dann ein 1K widerstandsnetzwerk nutzen könnte, anstatt die ganzen Einzelwiderstände :wink:

  • Laut C64 Schaltplan hängen PA6 und PA7 (Eingänge) an 1K, also am Ausgang des 7406.

    die 1k sind ja für den 7406 gedacht, weil er ja open collector ist.

    da der 7406 ausgang gleichzeitig mit dem cia eingang verbunden ist, ist es so.

    bei der rpi schaltung geht aber ja der 7406 ausgang nicht direkt an den rpi eingang sondern
    über weitere 7406 oder dem level shifter und dann muss da ein pull up zusätzlich vorhanden sein.
    oder der im rpi aktiviert sein. darauf würde ich mich aber nicht verlassen.

    lg
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • So, ich musste noch das hier in der options.txt ändern:

    //invertIECInputs = 1

    in

    invertIECInputs = 1

    Dann funktionierte der Pi1541 Zero

    Ich mache jetzt die Tests erneut mit der neuen Schaltung.

  • Wäre insofern nicht schlecht, weil man dann ein 1K widerstandsnetzwerk nutzen könnte, anstatt die ganzen Einzelwiderstände :wink:

    bitte nicht machen, der arme rpi.

    du hast mich da wohl nicht verstanden.
    nur erstmal zum testen sollte es einer machen ob es dann funktioniert oder einen unterschied im verhalten gibt.

    der arme, wriklich der ganz arme sehr schwacher und gebrächlicher rpi schafft doch nur 50mA
    für alle ports zusammen zu treiben, für alle funktionen zusammen.

    da sollte man keine unnötigen mA verbraten. das kann nur probleme geben.

    nur der softwareersteller hat da überblick darüber, was der da macht.

    ich kenne nicht den rpi, aber man muss sich nur vorstellen der programmierer schaltet irgendwo
    mal die inputs auf output und dann noch ein ganzes io port, mit 8 oder 16 usw. bits.
    dann knallt es in der internen 3,3v versorgung immer. man kann dann nur hoffen, die entwickler haben
    da eine schutzschaltung intern vorgesehen. damit der ic sich nicht selbst zerstört.

    das geht aber doch nur dann mit einer internen schutzschaltung die doch den strom und somit den
    io output pegel begrenzt. dann kann es aber sein, das dann der high pegel nicht mehr ttl kompatibel ist!
    und so probleme auftauchen, an die man garnicht denken würde.

    so hoffe ich nun, das der programmierer da keine bus programmier fehler gemacht hat.
    zwischen der a und der b version. sondern das der rpi da probleme intern hat.
    dann müsste es aber mit dem trick und den zusätzlichen pull ups, sichtbar besser werden.

    ich würde dann auch zum testen einen 74hc05 oder einen 74hct05 nehmen.
    dann müsste es auch besser werden, da sie ja cmos eingänge haben. und so den rpi kaum belasten.
    aber bitte nur zum testen, den der 74hc(t) schafft es nicht mehrere geräte am bus zu treiben!
    da gibt es dann wieder ganz andere probleme.

    lg
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • ich möchte keinen hier unnötig mit meinen erklärungen, wiso und warum, verunsichern.
    der es mit der schaltungstechnik nicht versteht.

    aber bitte, bei der version b und der version c,
    zusätzliche pull ups löten. z.b. auf den 7406 pins.

    laut zeichnung von kinzi die version c und da ja auch genauso beschaltet wie bei der version b.

    an den pin 1 und dem pin 3 von dem 7406 oder an die leitungen die dahin gehen,
    jeweils einen pull up (10k oder 4,7k oder 1K) an die 3,3v zum testen löten. ACHTUNG NUR AN DIE 3,3V!
    ob sich das ganze verhalten dann ändert.

    gruß
    helmut

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp

  • ich habe die beiden widerstände mal schnell eingezeichnet.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Helmut Proxa @axorp (HP.)

    proxa computer

    ultra electronic Helmut Proxa GmbH & Co. Computer Systeme Hardware Software KG - Telex 888 66 27 uehp