Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. Black Knight
    Meinst du den HW rules Befehl? Da ist das Argument doch kein String, sondern eine feste Anzahl an Bytes. Wir könnten die MSBits dieses zusätzlichen Bytes nach dem 'Play Soundfile' Kommando auch noch für Zusatzfunktionen nutzen, z.B. Loop u.s.w. Alternativ könnte man auch einen Switch festlegen, der als aktiviert angezeigt werden soll, wenn das Soundfile durch ist o.ä Es kann halt ganz gut sein, zu wissen wann die Musik durch ist. Aber letztendlich müsst ihr das entscheiden, da ich nicht weiß wie PinMame uns MPF sowas handhaben.
  3. jabdoa
    Klar. Bei Rules ist das für Switch 0 und Coil 0 aber auch so.
  4. Black Knight
    Könnten wir 'Play Soundfile' (0x34) so ändern, dass 1 die Nummer des ersten Tracks ist und nicht Null? Bei mir markiert die Null bei den Befehlen mit Stringargumenten nämlich immer das Ende des Befehls und das würde ich nach Möglichkeit auch gerne so lassen.
  5. Black Knight
    Hallo Jan, jetzt läuft's. 0x19 habe ich bei mir schon drin, aber das mit der Track-Nummer in 'Play Soundfile' muss ich noch nachziehen - sollte aber schnell gehen. Da wird es vermutlich länger dauern, bis ich im MPF Tutorium bei den Sounds angekommen bin.
  6. jabdoa
    Das ist doof. Habe bisher nur die Rules für Flipper gestestet. In dev.42 habe ich mal Tests für Pops/Slings hinzugefügt und das ordentlich gehandelt. Es gilt mal wieder "If it ain't (unit) tested consider it broken". Hier ist die Config aus den Tests: https://github.com/missionpinball/mpf/blob/dev/mpf/tests/machine_files/apc/config/config.yaml#L51 Gruß Jan
  7. Black Knight
    Ich komme leider mit dem Config-File nicht klar, er erwartet wohl einen Power-Eintrag für die entsprechenden Spulen AttributeError: 'NoneType' object has no attribute 'power' aber wenn ich ein 'power' Attribut einfüge bricht er sofort ab und sagt so ein Attribut gäbe es nicht. default_pulse_power akzeptiert er zwar zunächst aber dann kommt wieder der obige Fehler. Leider kann ich in der Doku keine Liste der Einstellungen für Spulen finden...
  8. jabdoa
    0.53.0-dev.41 unterstützt Hardware Rules wie spezifiziert.Jetzt fehlen nur noch 0x1A und 0x19 in MPF. Jan
  9. Black Knight
    Jo, klappt. Ich kann jetzt schon fast sowas ähnliches wie spielen. Danke für die Info. Ich hoffe, das hilft dem Ralf, wenn er wieder da ist.
  10. Snux
    Ich habe ziemlich viel mit Pinmame fuer P-ROC gemacht, aber leider gar nix mit Sound. In "P-ROC Pinmame world" hat der PC ein Lautsprecher, so alles klappt "out of the box". Es ist etwas wie "Play Sound Number 1", "Play Music Number 2" etc. In snc_cmd.c sieht man vielleicht was nutzliches.... https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/wpc/snd_cmd.c und das ist denn "irgendwie" emuliert aber genau wo/wie weiss ich nicht....
  11. Snux
    War knapp...... Yup. Und ist UINT16, also doch 2 bytes / Stelle. Aber jetzt wird's zu kompliziert fuer mein Deutsch, also ein bisschen Englisch... This is the segment display handler in pinmame, routine is updateDisplay https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/wpc/core.c#l936 Normally, pinmame displays the segments on the computer screen. For P-ROC we add some code at screen drawing time to capture the segment data. At the end of updateDisplay we have 2 arrays of UINT16 called proc_top (for the first 16 displays) and proc_bottom (for the second 16 displays). Depending on the machine, some of the positions are unused. We then call procUpdateAlphaDisplay here https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/wpc/core.c#l1047 And the P-ROC will push out the raw data direct to the display. https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/p-roc/display.cpp#l405 I do not know exactly the format of the raw data, but there is a routine in the P-ROC code for displaying 2 lines of "text", it converts to the raw data and then called procUpdateAlphaDisplay. That routine is here... https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/p-roc/display.cpp#l311 I think if LISY-pinmame does a similar kind of thing like P-ROC it should be easy to get the data I think.
  12. jabdoa
    Mache ich am Wochenende. Jan
  13. Black Knight
    @jabdoa Hallo Jan, kann es sein, dass die HW rules noch nicht im MPF integriert sind? Ich bekomme den Fehler: AssertionError: Hardware rules are not support in LISY.
  14. Black Knight
    Sehr gut. Es war so ruhig bei dir, da habe ich schon gedacht, du hättest beim SMD löten vor Wut in die Platine gebissen.😉 Denk dran, den Stecker für den Lautstärkeregler abzuziehen, wenn du die digitale Lautstärkeeinstellung nutzt, sonst klappt das nicht richtig. Vielleicht hast du ja gesehen, dass wir gerade das USB-Protokoll für die Displays definieren. Weißt du, wie der PinMame bei Sys11 die Displaydaten überträgt? Es gibt ja auch Spiele, die 'Effekte' nutzen, also nicht unbedingt echte Buchstaben anzeigen, also muss der PinMame doch die Segmentdaten 'roh' übertragen, oder? Das wäre dann sowas wie: 14 Segmente + Punkt + Komma = 16Bit = 2Byte. Beim Sound könnten wir deine Hilfe auch gebrauchen, der Ralf hatte dazu einen eigenen neuen Thread gestartet.
  15. Snux
    Endlich ein bisschen Zeit gehabt. "Step 1" klappt - "Houston, we have sound". Hoffentlich Sonntag geht es weiter
  16. Black Knight
    Super, probiere ich morgen aus.
  17. jabdoa
    Hier ist ein Beispiel:http://docs.missionpinball.org/en/dev/hardware/lisy/flippers_slings_popbumpers.html . Vermutlich brauchst du type: driver für APC. Vielleicht sollten wir das im Tutorial auch noch hinzufügen für alle älteren Maschinen. Jan
  18. Black Knight
    Vielleicht sollten wir noch auf Ralfs Meinung warten, bevor wir anfangen zu implementieren? Ich habe übrigens das MPF Tutorium Schritt 11 mit APC am Laufen. Ich habe nur noch nicht kapiert, wie ich meine Flipperspulen aktivieren kann. Die ganzen Flipper-Devices scheinen immer auch die Flipperknöpfe abfragen zu wollen, dabei muss ich ja einfach nur eine Spule dauerhaft einschalten. Hast du da vielleicht einen Tipp für mich?
  19. jabdoa
    Das klingt sehr gut. Gefällt mir. Bytes sind gebongt. Ich update das dann in der Referenz und implementier es in MPF über das Wochenende. Jan
  20. Black Knight
    OK, das würde bedeuten, er fragt mit 0x06 die Anzahl der Displays ab und bestimmt dann mit 0x07 den Typ jedes Displays, korrekt? Ich würde wieder ein Byte bevorzugen, weil's einfacher zu handhaben ist und ich den Mehrwert eines Strings nicht sehe, aber für dich schicke ich auch Strings raus.😉 Auf Basis meiner oben genannten Williams-Displays fallen mir folgende Typendefinitionen ein. Ich schreibe mal einfach Byte und String, wir können uns ja noch entscheiden, was wir nehmen: 1 -> BCD7 (BCD Code für 7 Segment Displays -> ohne Komma) 2 -> BCD8 (BCD Code für 8 Segment Displays -> mit Komma) 3 -> SEG7 (7 Segment Displays + Komma mit direkter Ansteuerung -> Segmentmuster) 4 -> SEG14 (14 Segment Displays + Punkt + Komma mit direkter Ansteuerung -> Segmentmuster) Angenommen, wir hätten was ich oben als Displaytyp 2 bezeichnet habe, '2x 7 Digit Alphanumerical Display + 2x 7 Digit Numerical Display + 1x 4 Digit Numerical (Credit)' dann würde die Initialisierung also folgendermaßen ablaufen: MPF sendet 0x06 und bekommt eine 5 zurück. Dann fragt er mit 0x07 + 0 die Daten von Display 0 ab und bekommt als Antwort 4 + 3 (bzw. SEG7). Da er es mit 5 Displays zu tun hat wiederholt er das so lange, bis er für alle eine Definition bekommen hat, also in diesem Fall sendet er 0x07 + 1 für Display 1 und bekommt 7 + 4 (SEG14), die gleiche Antwort gibt's auf 0x07 +2. Dann kommt 0x07 + 3 und als Antwort kommt 7 + 3 (SEG7), dito für 0x07 +4. Das sollte doch passen, oder?
  21. Earlier
  22. Black Knight
    Super, denk dran die Displayeinstellungen jetzt auf 4Alpha + Credit zu ändern, sonst steuert er die Displays 3 und 4 als Numerische an. Eigentlich nicht, vielleicht doch eine wackelige Lötstelle?
  23. bontango
    Hab eben die Displays in Betrieb genommen, läuft 😃 sogar das Nachglimmen ist weg. Musste der Jumper evtl. für dein Display anders stehen? In die Displaydiskussion bzgl. Protokoll klinke ich mich nächste Woche ein, bin jetzt ein paar Tage weg.
  24. Black Knight
    Das stimmt, aber wenn wir ein generisches System zur Definition der Displays haben wollen, dann muss dieses auf alle möglichen Displayarten vorbereitet sein.
  25. jabdoa
    APC muss ja nicht alle Displays unterstützen die das Protokoll unterstützt. Aber wenn LISY universal bleibt können andere Hardware Lösungen das später. Jan
  26. Black Knight
    Wenn wir ein generisches System zur Displayansteuerung haben wollen, dann sollten wir erst mal sammeln, mit was für Displays wir es zu tun haben. Ich habe oben ja schon mal zusammengefasst, welche Williams Segmentdisplays mir bekannt sind, was fällt euch denn noch ein?
  27. Jsmall Jsmall joined the community
  28. Black Knight
    Jo, er läuft 👍 Keine Fehlermeldungen und kein Reset mehr am Anfang. Laut Log hat er, bis ich ihn abgewürgt habe, brav den Befehl 'Get changed switches (0x29)' gesendet und immer 127 zurück bekommen, da ich keine Schalter betätigt habe. Was mir noch aufgefallen ist: - Er startet seine Abfrage aller Schalter am Anfang bei Schalter 0, den gibt es bei Williams aber nicht. - Du hast in deinem Beispielconfig den Befehl 'Text to speech' benutzt, der läuft bei mir allerdings ins Leere. Ich wüsste auch nicht, wie ich das machen sollte. Aber zusammengefasst scheint es zu klappen, d.h. ich muss jetzt mal lernen, wie das mit den Config-Files beim MPF funktioniert und wir müssen nochmal an das Displayprotokoll ran. Das hat halt Vor- und Nachteile. Sicherlich wäre ein generisches System das alle Eventualitäten abdeckt optimal, wenn aber ein Fall auftaucht der nicht abgedeckt ist, kann das unangenehm werden. Es gibt z.B. Bally Flipper aus den 80ern, die ganz andere Segmente haben (so 'ne Art Spar-Alphanumerisch) und wenn unser generisches System dafür nicht vorbereitet ist und irgendwer so'n Display ansteuern will dann sind wir aufgeschmissen. Wenn man dagegen jedem Displaytyp eine Nummer zuordnet muss man jeden neuen Typ einmal definieren, dafür ist danach aber auch allen klar was Sache ist und dass ein Übertragungsmodus existiert, der auf dieses Display zugeschnitten ist. Letztendlich läuft es darauf hinaus, ob wir uns zutrauen ein System zu entwerfen, dass generisch genug ist um alles abzudecken, ansonsten wären wir vermutlich mit einer Typennummer besser dran. Ich werde da mal darüber nachdenken.
  1. Load more activity
×
×
  • Create New...

Important Information

Privacy Policy and Community Guidelines

  I accept