Jump to content

Recommended Posts

Bin gerade dabei, die Displaysteuerung laut Lisy zu implementieren und jetzt stellt sich wieder die Frage der Nummerierung.

Was ist z.B. Display 0, das Credit Display (wenn es denn eins gibt) oder das für Player 1?

Und was mache ich bei den späteren Sys11ern, die nur noch zwei Zeilen mit je 16 Zeichen haben, sind das dann die Displays 0 und 1?

Erleuchtet mich doch bitte mal.

Frank

 

Link to post
Share on other sites
  • Replies 1.4k
  • Created
  • Last Reply

Top Posters In This Topic

Gute Frage 🙄 musste gerade in meiner source nachschauen ..

Display 0 ist das Creditdisplay, Display 1 dann Player1 , usw.

Bei den groesseren ( Gottlieb 80B hat 2 Anzeigen a 20 Character) sind das Display 1 und 2

 

Auf den PI kommst Du  einfachsten via ssh und LAN bzw. WLAN.

WLAN Credentials lassen sich im LISY Image in der DOS Partition konfigurieren, LAN macht DHCP.

Der PI 3B+ hat nen LAN Anschluss, beim PI Zero brauchst Du dafür nen Adapter

Link to post
Share on other sites

Wenn du sowieso gerade im Sourcecode steckst habe ich gleich noch einen:

Bei 'get changes switches' steht als Rückgabe nur 1 Byte. Ich nehme an, das stimmt nicht und stattdessen werden alle seit der letzten Abfrage betätigten Schalter übertragen. Sonst müsste ja für jeden betätigten Schalter eine neue Abfrage gestartet werden.

Fragen über Fragen ...

Link to post
Share on other sites

Das ist 'stumpfes polling', in 99,9% der Fälle liefert das '127' bzw 0x7F zurück, das heisst dass sich nichts getan hat, seit dem letzten Poll,

andere switchänderungen kommen dann beim nächsten poll. Die Pollingfrequenz kann man im MPF einstellen

Besser wäre wohl wenn Du melden könntest: 'es hat sich was getan', das haben wir 'damals' aber nicht implementiert,

könnte ich in LISY einbauen aber ob das MPF kann .. @jabdoa ginge dass von polling auf eventgesteuert umzuschalten?

 

Link to post
Share on other sites
24 minutes ago, bontango said:

Besser wäre wohl wenn Du melden könntest: 'es hat sich was getan', das haben wir 'damals' aber nicht implementiert,

Das wäre für mich das einfachste, da es in meiner Software genau so gemacht ist. Momentan speichere ich diese Meldungen halt zwischen und haue sie raus, wenn über USB der Poll Befehl kommt.

Jetzt fehlt nur noch Sound, aber da lasse ich das mit den Nummern erst mal weg, weil das ja auch noch ein offener Punkt ist. Der Rest läuft schon.:juhu:

Die Boards sind übrigens wohl schon in der Post.

 

Link to post
Share on other sites

Vielleicht ist es doch besser, weiterhin zu pollen. Auf diese Weise ist zumindest der Zusammenhang zwischen Anfrage und Antwort immer gegeben. Ansonsten müsste der Master nach jeder Anfrage entscheiden, ob das was er gerade empfängt, die Antwort auf seine Anfrage ist oder ob inzwischen ein Schalter betätigt worden ist und der Slave gerade dazwischenquatscht.

 

Link to post
Share on other sites

Ja, lassen wir es erst einmal so.

Arduino hab ich geordert, ist auch bereits auf dem Weg.

Würde der denn mit deinem Programm grundsätzlich auch ohne 'Hardware drumherum' schon mal auf Befehle am seriellen Port reagieren?

Link to post
Share on other sites

Ja, der würde schon reagieren, aber ohne die passende Hardware kannst du kaum bewerten, was er da tut. Ohne Logikanalyzer kann man noch nicht einmal feststellen, was das Display gerade anzeigt.

Letztendlich führt meiner Meinung nach kein Weg daran vorbei, das Zeug in einen Flipper zu packen und auszuprobieren. Am Anfang könntest du mir z.B. Byte Sequenzen schicken, die ich dann über USB an den Flipper schicke, so mache ich das auch gerade um meine Implementierung der Lisy API zu testen. Allerdings sollten wir damit warten, bis ich fertig bin und das Zeug grob mit dem MPF getestet habe, dann sind meine Fehler hoffentlich schon mal raus.

Bisher habe ich ja auch die rein numerischen Displays von den alten Systemen ignoriert, das sollte ich vorher auch noch ändern.

Link to post
Share on other sites

Ich könnte dann aber schon mal die USB-serial kommunikation testen und z.b. die Anzahl displays, ... abfragen, dann wissen wir dass das schon mal grundsätzlich läuft.

 

Pinmame habe ich jetzt soweit dass er ein Spiel started (derzeit fix: Jungle Lord) und Display Ausgaben im Log macht. Bislang habe ich das immer sehr Hardwarenah

gemacht, da ich die HW gut kannte, bei Williams wollte ich mal schauen ob ich mit den Segmentdaten in pinmame weiterkomme.

Für System7 speichert Pinmame Segmentdaten in einem Array mit jeweils 16-Bit. da muss ich noch aus der Codesequenz rausfieseln wo was gespeichert wird.

So wie das aussieht benutzt er nur jeweils ein Byte, wobei da auch über bit7 verdrahtet ist ob das Komma an ist, oder nicht.

Wie machen wir das am besten, jeweils den BCD Code plus Kommastatus in bit7? Oder einfach den internen Wert von pinmame und du fieselst das auf deiner Seite raus?

 

btw: zwei Dinge sind mir aufgefallen die noch in der LISY_API fehlen ( nur für LISY relevant, nicht für MPF):

1) Dip Switches: Pinmame braucht die DIP-Switcheinstellungen, werden beim Start eingelesen

2) NVRAM Data ( Highscores, usw, ..) Auch hier muss pinmame  am Anfang die Daten einlesen, UND am Ende zurückschreiben können

hast Du da jeweils etwas vorgesehen?

Link to post
Share on other sites
vor 21 Minuten schrieb bontango:

1) Dip Switches: Pinmame braucht die DIP-Switcheinstellungen, werden beim Start eingelesen 

Macht in MPF auch Sinn. Dann kann man darüber Sprache aussuchen und co.

vor 22 Minuten schrieb bontango:

2) NVRAM Data ( Highscores, usw, ..) Auch hier muss pinmame  am Anfang die Daten einlesen, UND am Ende zurückschreiben können 

Theoretisch für High Scores aber MPF kann das aktuell noch nicht. Würde langfristig aber auch Sinn machen.

 

vor 23 Minuten schrieb bontango:

Wie machen wir das am besten, jeweils den BCD Code plus Kommastatus in bit7? Oder einfach den internen Wert von pinmame und du fieselst das auf deiner Seite raus? 

Ich würde BCD gut finden (ggf BCD + zusätzliche Elemente). Also vermutlich 16Bit pro Zeichen. Gibt's da irgendeinen Standard?

 

Jan

Link to post
Share on other sites
1 hour ago, bontango said:

Ich könnte dann aber schon mal die USB-serial kommunikation testen und z.b. die Anzahl displays, ... abfragen, dann wissen wir dass das schon mal grundsätzlich läuft.

Das wird schon laufen, da ich das ja gerade mit einem Terminalprogramm teste. Wir können uns auch mal per Skype oder so treffen, dann kannst du live dabei sein, wenn ich deine Bytesequenz an den Flipper schicke.

Falls du es allerdings alleine ohne Hardware machen möchtest, müsstest du noch ein Setting ändern, damit das System im USB Modus hoch kommt. Wenn die Settings auf der SD Karte nichts anderes sagen kommt der APC nämlich standardmäßig mit dem Base Code hoch, da der für jeden Flipper die Grundfunktionen zur Verfügung stellt. Man kann dann in den Einstellungen auf USB Kontrolle umschalten, was für dich allerdings schwierig ist, weil du ja weder Schalter noch Displays hast. Wenn du soweit bist, sage ich dir was du ändern musst.

1 hour ago, bontango said:

Für System7 speichert Pinmame Segmentdaten in einem Array mit jeweils 16-Bit. da muss ich noch aus der Codesequenz rausfieseln wo was gespeichert wird.

Vermutlich sind es 16Bit um kompatibel mit späteren Maschinen zu sein. Da gibt es nämlich Displays mit alphanumerischen Displays und dann brauchst du für jedes Zeichen 16Bit. Bei Sys7 und früher brauchst du eigentlich nur 4Bit für BCD und eins für's Komma. BCD Code + Kommastatus in Bit 7 wäre für mich also OK.

1 hour ago, bontango said:

1) Dip Switches: Pinmame braucht die DIP-Switcheinstellungen, werden beim Start eingelesen

Was für Informationen sind denn da drin? Das müsste beim APC dann aus den Settings generiert werden.

1 hour ago, bontango said:

2) NVRAM Data ( Highscores, usw, ..) Auch hier muss pinmame  am Anfang die Daten einlesen, UND am Ende zurückschreiben können

Kann man das nicht lieber in einem File auf dem Rechner speichern anstatt im Flipper? 

Ich habe übrigens auch noch ein paar Dinge, die ich noch gerne in der API haben würde:

Die Befehle 50, 51 und 52 müsste es nochmal für Musik geben. Wie die Sys11er kann auch der APC zwei Soundfiles simultan abspielen und unterscheidet daher zwischen Musik und Sound (ist eigentlich dasselbe aber man muss die beide Tonspuren ja irgendwie unterscheiden können).

Außerdem brauchen wir vermutlich noch die Möglichkeit Special Solenoids zu definieren, also einen Schalter, der automatisch eine Spule auslöst ohne den Umweg über USB. Das wäre dann also ein 3 Byte Befehl: Kommando, Schalter und Spule und man würde das für jede Kombination senden.

 

Link to post
Share on other sites
vor 3 Stunden schrieb Black Knight:

Außerdem brauchen wir vermutlich noch die Möglichkeit Special Solenoids zu definieren, also einen Schalter, der automatisch eine Spule auslöst ohne den Umweg über USB. Das wäre dann also ein 3 Byte Befehl: Kommando, Schalter und Spule und man würde das für jede Kombination senden. 

Warum braucht das ein spezielles Command? In Snux (System 11 mit P-Roc) ist das auch nur eine normale Coil. Oder ist das eine Hardware Rule? Dafür brauchen wir auf jeden Fall ein Command. Könnte sich vermutlich an OPP/FAST orientieren (switch, coil, pulse time, hold time und hold power, ggf pulse power).

Link to post
Share on other sites

Bis irgendwann in Sys11b war das eine HW rule (spezielle Schalter zusätzlich zur Switch Matrix, die über eine HW Logik direkt die entsprechenden Spulen betätigt haben), danach waren die Special Solenoids normale Spulen und die Schalter Bestandteil der Switch Matrix.

8 hours ago, jabdoa said:

(switch, coil, pulse time, hold time und hold power, ggf pulse power).

Zum Setzen der Pulse time gibt es ja schon ein Kommando, daher würden meiner Meinung nach Schalter und Spule ausreichen.

Der Rest klingt eher, als wäre er für Flipperspulen, bei denen es eine High- und eine Low-power Wicklung gibt.

Link to post
Share on other sites
vor 2 Minuten schrieb Black Knight:

Zum Setzen der Pulse time gibt es ja schon ein Kommando, daher würden meiner Meinung nach Schalter und Spule ausreichen.

Erfahrungsgemäß ist das schwierig. OPP macht das so und wir hatten da diverse Probleme mit. Bsp kann es sein dass ein Software Pulse Command stärker ist beim ball search als in der Hardware Rule. Geht aber auch so.

 

vor 3 Minuten schrieb Black Knight:

Der Rest klingt eher, als wäre er für Flipperspulen, bei denen es eine High- und eine Low-power Wicklung gibt.

Das ist so das etablierte Standard Rule Format von allen Controllern. Braucht man sobald man Spule  nicht permanent enabled sondern mit PWM + initialer Pulse. Das hat man in System11 vermutlich noch nicht gemacht sondern erst später. Aber braucht man dann auch für einfache Flipperspulen.

Hardware rules sind für MPF (und andere Frameworks) der Weg um dem Controllern zu sagen dass Spule A durch Switch B für X ms gepulst werden soll und danach ggf mit PWM aktiviert solang der Switch aktiv bleibt.

Link to post
Share on other sites
2 hours ago, jabdoa said:

Erfahrungsgemäß ist das schwierig. OPP macht das so und wir hatten da diverse Probleme mit. Bsp kann es sein dass ein Software Pulse Command stärker ist beim ball search als in der Hardware Rule. Geht aber auch so

Ist OK, ich war nur neugierig. Wenn ihr das immer so macht dann will ich da keine Sonderlocken einführen. Ist bei mir auch kein Problem, in meiner Software gibt man jeder Spulenaktivierung sowieso immer eine Aktivierungszeit mit. Nur wenn die Null ist, dann schaut sie in eine Liste und nimmt die Standardzeit für diese Spule.

3 hours ago, jabdoa said:

Das ist so das etablierte Standard Rule Format von allen Controllern. Braucht man sobald man Spule  nicht permanent enabled sondern mit PWM + initialer Pulse. Das hat man in System11 vermutlich noch nicht gemacht sondern erst später. Aber braucht man dann auch für einfache Flipperspulen.

Das kenn ich in der Tat noch nicht und ich wüsste auch nicht, dass sowas in Sys11 schon verwendet worden wäre. Von daher würde ich nur Switch, Coil und Pulse Time verwenden und den Rest ignorieren.

Wie ist denn eure Erfahrung mit diesen Hardware Rules? Braucht man die überhaupt? Wird die Reaktionszeit wirklich zu groß, wenn die Befehle erst über den USB Bus müssen?

Welche serielle Bitrate verwendet ihr eigentlich? Ich habe jetzt 115200 Baud eingestellt.

Link to post
Share on other sites

Feedback zu den einzelnen Punkten:

- Display System7, BCD Code: mach ich dann so, sobald ichs lauffähig habe, passe ich dann die API an und schick sie rum. ich denke ich werde auf Steuerung einzelner Digits umstellen, oder sollen wir wie gehabt immer den kompletten Dispalyimnhalt schicken sobald sich eine Stelle ändert?

- DIP Switches: Hatte nur gesehen dass auf der Williams MPU zwei 8er Bänke DIP switches drauf sind, konnte aber jetzt im Manual nicht finden was mit denen eingestellt wird. Wenn wir die brauchen kann ich die auch auf der Mini LISY unterbringen kein Thema. Die Gamesettimngs werden bei Williams nur über das Menü gemacht? Brauchen wir die DIP Bänke?

- NVRAM: Kann ich dann auch auf der LISY machen, habe ich bislang auf dem eeprom der PICs, dass wird aber spätestens bei System11 wohl nicht ausreichen ( 4K anstatt der sonst üblichen 256Byte, richtig?), überleg ich mir dann wenn wir zu System11 kommen. LISY ist bislang read/only, das würde ich auch gerne so lassen. Linux mag es nicht wenn es einfach so ausgeschaltet wird ...

- API plus Musik: würde ich dann auch in der nächsten Version als Erweiterung aufnehmen

- Hardware rules: Müssten dann ja über LISY 'eingestellt' werden, hab ich keine Erfahrung mit ... welche Williams Pins verwenden sowas? wenn das geht würde ich dafür stimmen dass so zu machen, also auf dein Board auszulagern. Zeitkritische Funktionen über Linux vermeide ich wo geht ...

- ich hoffe ich hab nichts vergessen?

 

Link to post
Share on other sites

Mit den Dips programmierst du die alten Sys 3 und Sys 4. Später ging das von der Kassentür aus. Wenn du es natürlich hinbekommst die Software (Eproms) so zu ändern das such Sys 3/4 über die Kassentür zu programmieren wären wäre das genial!

Link to post
Share on other sites
vor 12 Stunden schrieb Black Knight:

Wie ist denn eure Erfahrung mit diesen Hardware Rules? Braucht man die überhaupt? Wird die Reaktionszeit wirklich zu groß, wenn die Befehle erst über den USB Bus müssen? 

Für Flipper und Pops ist das essential. Ansonsten fühlt es sich super komisch an. Das Problem ist nicht mal die Latenz sondern hauptsächlich der Jitter.

vor 12 Stunden schrieb Black Knight:

Welche serielle Bitrate verwendet ihr eigentlich? Ich habe jetzt 115200 Baud eingestellt. 

Das reicht für Switches plus Segment Displays. DMDs o.ä. brauchen deutlich mehr.

vor 12 Stunden schrieb bontango:

- NVRAM: Kann ich dann auch auf der LISY machen, habe ich bislang auf dem eeprom der PICs, dass wird aber spätestens bei System11 wohl nicht ausreichen ( 4K anstatt der sonst üblichen 256Byte, richtig?), überleg ich mir dann wenn wir zu System11 kommen. LISY ist bislang read/only, das würde ich auch gerne so lassen. Linux mag es nicht wenn es einfach so ausgeschaltet wird ... 

Genau deshalb wären eine Highscore Option auf EEPROM cool. Aber kann auch im V2 sein.

 

vor 12 Stunden schrieb Black Knight:

Das kenn ich in der Tat noch nicht und ich wüsste auch nicht, dass sowas in Sys11 schon verwendet worden wäre. Von daher würde ich nur Switch, Coil und Pulse Time verwenden und den Rest ignorieren

Für die lower power/hold coil brauchen wir aber auch permanent Enable in der Rule oder? Hold power kann man vermutlich weglassen auf alten Kisten.

vor 12 Stunden schrieb bontango:

- Display System7, BCD Code: mach ich dann so, sobald ichs lauffähig habe, passe ich dann die API an und schick sie rum. ich denke ich werde auf Steuerung einzelner Digits umstellen, oder sollen wir wie gehabt immer den kompletten Dispalyimnhalt schicken sobald sich eine Stelle ändert? 

Ich würde immer den ganzen Inhalt schicken. So viele Bytes sparen wir vermutlich nicht und bei 115kBaud ist das locker drin.

Link to post
Share on other sites
23 hours ago, bontango said:

welche Williams Pins verwenden sowas? wenn das geht würde ich dafür stimmen dass so zu machen, also auf dein Board auszulagern.

Das wird von allen Williams bis irgendwann in Sys11b verwendet. Bei diesen Geräten ist auch fest verdrahtet, welcher Schalter welche Spule auslöst, dafür bräuchte man also noch nicht einmal eine HW-Rule zu definieren, da die sowieso immer gleich wäre. Die Schalter sind auch extra und nicht Bestandteil der SW-Matrix.

Das Problem sind die jüngeren Geräte, da werden Schalter aus der SW-Matrix genommen und die Software löst die Spulen aus. Bei denen können also auch andere Schalter und Spulen beteiligt sein. Außerdem war die Anzahl vorher auf 6 limitiert und jetzt können es auch mehr sein. D.h. wegen dieser Geräte brauchen wir HW rules.

12 hours ago, jabdoa said:

Genau deshalb wären eine Highscore Option auf EEPROM cool. Aber kann auch im V2 sein.

Meine Software speichert alle Highscores und Settings sowieso auf der SD Karte ab. Das Problem ist, das der APC im USB Betrieb nicht weiß, welcher Flipper da gerade emuliert wird und daher auch nicht unterscheiden kann, welche Settings/Highscores dazu gehören. Für den APC ist USBcontrol jetzt einfach ein Spiel, wie alle anderen auch. Er wird daher ein Highscore und ein Settings File für dieses Spiel auf der SD Karte anlegen. Wir müssten uns halt überlegen, ob das genug ist, denn wenn man den APC und Lisy in ein anderes Gerät umzieht, müsste man dann auch die SD Karte wechseln, da sonst die Settings vom Vorgänger wieder geladen würden. Stellt sich die Frage, ob das wirklich eine Einschränkung ist - wie viele Leute werden die HW in ein anderes Gerät umziehen und wenn, dann wäre es vermutlich sowieso nicht schlecht, wenn man dann auch eine andere SD Karte einlegen würde, auf der dann auch die Sounds des neuen Gerätes drauf sind. Was meint ihr, reichen ein Highscore und Settings File aus? 

12 hours ago, jabdoa said:

Für die lower power/hold coil brauchen wir aber auch permanent Enable in der Rule oder?

Meines Wissens nach gibt es keine Special Solenoids, die permanent eingeschaltet werden. Das sind eigentlich immer Slingshots, Jet bumper oder Kick backs, also Spulen, die mit wenig Latenz aber nur kurz aktiviert werden sollen.

12 hours ago, jabdoa said:

Ich würde immer den ganzen Inhalt schicken. So viele Bytes sparen wir vermutlich nicht und bei 115kBaud ist das locker drin.

Ich bin mir gar nicht sicher, ob wir dadurch überhaupt was sparen würden. Man stelle sich nur eine Laufschrift oder sowas vor, da würde sicher immer der gesamte Displayinhalt ändern und wir bräuchten für jede Stelle zwei Byte.

Link to post
Share on other sites

So, die erste Version ist auf Github.

Die Lisy-relevanten Teile stehen in USBcontrol.ino

Bei den Displays wird sich noch etwas ändern, da ich als nächstes die Unterstützung für die alten numerischen Displays einbauen werde, aber so wie es jetzt ist funktioniert es schon mal für die anderen.

Link to post
Share on other sites

Sehr schön

Ich bin jetzt auch soweit dass ein Raspberry PI plus ein 10K-Widerstand zum testen mit deinem APC schon ausreicht.

Wenn ein bestimmter GPIO auf high gezogen wird, merkt LISY beim booten dass es auf einer 'LISY_mini' läuft und startet die Jungle Lord emulation.

Ich mach das jetzt mal auf einer Lochrasterplatine.

Derzeit funktionieren nur die Displays, die abwechselnd '00' und den default Highscore '2.000.000' anzeigen.

Das 'nvram' Problem hab ich glaub ich auch gelöst. Ich nehme jetzt eine read/write Partition für die pinmame daten die ohne buffer direkt

auf die SD schreibt. So die durch Ausschalten zum falschen Zeitpunkt fritte ist, kann man das dann recht schnell beheben und verliert nur die Einstellungen.

 

Ich warte jetzt auf meinen Arduino für einen 'final Test', dann könntest Du, so Du nen Pi hast,  auf deiner Seite auch schon loslegen ..

Gruesse

Ralf

Link to post
Share on other sites

Ein Raspi 3A+ müsste doch eigentlich auch reichen, oder braucht man das zusätzliche RAM?

Wenn ich das richtig sehe, unterscheiden die sich doch nur durch die RAM Größe und ein paar Schnittstellen, die ich aber alle nicht brauche.

Versorgt werden die Dinger über MicroUSB, oder?

Und wie groß sollte die MicroSD Karte sein?

Schönen Sonntag

Frank

 

Edited by Black Knight
Link to post
Share on other sites

Morgen Frank,

ja, Unterschiede in den Schnittstellen, RAM, Prozessor, Takt, sind aber alle Binärkompatibel und für LISY alle OK.

https://www.datenreise.de/raspberry-pi-unterschiede-zwischen-den-modellen/

bei Preis/Leistung schneidet IMHO der A+ am schlechtesten ab. Bei Reichelt 22,50 gegenüber 26,50 für den 3B+

Wenn es billig sein soll, dann den Zero WH ( evt. plus Adapter), Empfehlung meinerseits ist klar der 3B+

SD Karte reicht ne 8GB aus. https://www.reichelt.de/microsdhc-speicherkarte-8gb-intenso-class-10-intenso-3413460-p126586.html?

Hier ein Foto vom LISY_Mini Prototypen 'im Gespräch' mit einer LISY80 über USB, ich poste Anfang der Woche mal den Schaltplan und einen LInk auf das Image.

Gruesse

Ralf

LISY_mini.jpg

Link to post
Share on other sites

Hallo Ralf,

das sieht ja schon gut aus.

Das mit dem Raspi muss ein Sonderangebot gewesen sein, ich finde den 3B+ bei Reichelt nur für 32,50€, aber dann bin ich wenigstens für alles gerüstet.

Ein Bild habe ich auch. Da kann man sehen, dass die Unterstützung der späteren Sys11 Displays und auch die Steuerung via USB funktioniert.

Jetzt muss noch das alte Sys7 Displays rein.

Frank

 

IMG_0120.JPG

Edited by Black Knight
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Privacy Policy and Community Guidelines