Zum Inhalt springen

LISY35 Bug: Sound vs. Solenoid Select (Star Trek)


Erebos

Empfohlene Beiträge

Ich habe meinen Bally Star Trek mit der aktuellen Version (5.26-19) von LISY35 aufgerüstet.

Es hat wirklich gut geklappt, ich konnte sofort regulär spielen.

 

Was bei Beginn nicht tat, war zum einen Sound, zum anderen das Kugelauswurfloch (Photon Phaser). Ersteres ließ sich auf einen defekten U7 (LM555) auf dem Soundboard zurückführen. Jetzt funktioniert auch Ton.

Kommen wir zum Kugelauswurfloch. Zum einen hat im Thread LISY35 Bug: Sound ( Geräte ab Xenon) der Nutzer ichbinsrene schon dieses Problem erwähnt. Zum anderen ist es ein Fehler, der wirklich nur beim Spielen auftritt.

Der Switch wird korrekt gelesen, es gibt Punkte. Und die Melodie spielt. Dann aber schlägt die Spule nicht.

Ist man im Menü-Zustand, schlägt die Spule sofort, wenn man den Switch schließt (so auch in der PinMAME ROM vorgesehen, wurde am PC getestet). Sowohl im Selbsttest als auch über LISY-Control können Switch und Spule korrekt gesteuert werden.

 

Aber im Spiel klappt es nicht.

 

Im Debug Modus bekomme ich diesen dazugehörigen Output:  (warum schreibt er auch LISY80 Output?)

[916.635475][4.282902] LISY80 Switch_reader: Switch37, action:1
[916.635830][0.000355] LISY35_SWITCH_READER Switch#:32 strobe:3 return:7 action:1
[916.738242][0.102412] LISY80 Switch_reader: Switch37, action:0
[916.738584][0.000342] LISY35_SWITCH_READER Switch#:32 strobe:3 return:7 action:0

[916.795199][0.056615] switch sound E line to:0
[916.795568][0.000369] sound interrupt occured
[916.796122][0.000554] sound data(standard sb): 0x02)
...
... viele viele Sound interrupts und Outputs ...
...
[918.067199][0.009551] sound interrupt occured
[918.067854][0.000655] sound data(standard sb): 0x0d)

[918.177916][0.110062] momentary solenoids: 7
[918.309105][0.131189] momentary solenoids: 15

Switch#:32 ist der richtige Kontakt, und Spule 7 ist die korrekte Spule. Sie feuert aber nicht. Stattdessen kann man einen seltsamen Ton hören, den ich so zumindest nicht in Erinnerung hatte.

Da die Spulen und Sound Adressen ja die selben Lines verwenden, schätze ich, dass der PIC diese eine Line zu spät schaltet. Kann das sein?

Da Ton ja zu Beginn nicht tat, hat es eine Weile gedauert, bis ich das identifiziert hatte. Mit dieser Annahme lassen sich auch noch zwei weitere Ereignisse erklären:

  • Beim Einschalten (nachdem LISY+PinMAME gestartet sind) werden auch mehrere Spulen geschaltet und gleichzeitig erklingt Ton. Das klingt nicht so, wie es mit der original MPU war.
  • Beim Testen des Kontakt #32 habe ich durch häufiges, schnelles Drücken es einmal geschafft, dass die Spule danach ausgeschlagen hat. Da fiel es wohl in eine Pause der Soundausgabe.

Ich hoffe, das lässt sich einfach fixen, @bontango.

 

 

Weitere Anmerkung: Beim ausführlichen Durchforsten der LISY Config Dateien ist mir aufgefallen, dass lisy35games.csv der Star Trek Maschine (#13) das Soundboard AS-2518-50 zuordnet. Bei mir ist allerdings die Version -32 eingebaut, und bei ipdb.org ist das auch so vermerkt. Kommt das daher, dass im Thread LISY35 Bug: Sound ( Geräte ab Xenon) das so von PinWiki übernommen wurde? Vielleicht scheint es einfach mehrere Ausführungen zu geben. Vermutlich ist der Unterschied aber auch nicht relevant.

 

 

Vielen Dank,

Jakob

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 16 Minuten schrieb Erebos:

Da die Spulen und Sound Adressen ja die selben Lines verwenden, schätze ich, dass der PIC diese eine Line zu spät schaltet. Kann das sein?

Damit meine ich die A4J4-10 Line, die laut Datenblatt LOW für Solenoid Bank Select ist, und vermutlich HIGH um Ton aszugeben.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ja, das ist noch ein Bug im 'Solenoid PIC' der unter bestimmten Konstellationen auftritt, und zwar wenn

direkt nach spielen eines Sounds eine Spule betätigt wird.

Hintergund ist, dass das PIC den Sound eigenständig bspielt, bzw. die Soundkarte selber ansteuert und von LISY/pinmame nur die Anweisung erhält 'Spiele sound No. X'.

In dieser Konstellation ist der pIC noch mit dem Sound beschäftigt wenn der Spulenbefehl reinkommt.

Der Befehl wird zwar zwischengespeichert und nachträglich ausgeführt, aber dann kommt auch schon der Befehl zum abschalten der Spule rein,

was dazu führt dass die Spule viel zu kurz angesteuert wird.

Ich kann derzeit nur eine Umgehungslösung anbieten, wenn der Sound auf 'raw mode' umgeschaltet wird, sollte es beim Startrek klappen.

(ich dachte beim aktuellen Image haette ich das schon gemacht? )

Schau bitte mal auf der Sd Karte in die Datei \lisy\lisy35\cfg\lisy35games.csv, da muss der Parametr #special cfg' auf 8 gestellt werden für den Raw Mode.

Debug meldet dann auch:

This is LISY (Lisy35) by bontango, Version 526 19
loading rom 0: 745-11_1.716
loading rom 1: 745-12_2.716
loading rom 2: 720-30_6.716
done
[141.814886][0.326948] Info: LISY35 will use soundboard variant 1 (standard SB in RAW Mode)

grafik.png

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ja, mega. Danke!

Die Special Cfg auf 8 zu setzen hat geholfen. Sie stand standardmäßig auf 0.

Jetzt würde ich zwar sagen, dass an und an seltsame Töne kommen, aber das erklärt sich dann ja vermutlich dadurch, dass LISY selber mixt.

 

Ist denn ein richtiger Fix dafür möglich? Ich stelle mir das so vor, dass der PIC während er in der Sound-Schleife ist die vorgespeicherten Befehle auf "Dringlichkeit" untersucht, und dann eventuell direkt ausführt (oder passenden Interrupt startet...). Der Code für die PICs ist nicht öffentlich, oder? Sonst würde ich mich da einfach selber mal dran versuchen.

 

Jetzt werde ich dann mich mal mit dem MPF auseinandersetzen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Stunde schrieb Erebos:

Jetzt würde ich zwar sagen, dass an und an seltsame Töne kommen, aber das erklärt sich dann ja vermutlich dadurch, dass LISY selber mixt.

eher pinmame, LISY reicht das nur durch. Obwohl ich denke dass der raw Mode eher am Original ist als der 'cooked' Mode

vor 1 Stunde schrieb Erebos:

Ist denn ein richtiger Fix dafür möglich? Ich stelle mir das so vor, dass der PIC während er in der Sound-Schleife ist die vorgespeicherten Befehle auf "Dringlichkeit" untersucht, und dann eventuell direkt ausführt (oder passenden Interrupt startet...)

Ich dachte eher daran beim zwischenspeichern auch die zeitliche Abfolge mit abzuspeichern und dann den Pulse nachzuliefern. Ansonsten wird das timing für die Soundkarte u.U. gestört, nicht so schlimm bei den 'altebn' Soundboards, aber z.B. das S&T braucht schon ein sauberes timing

 

vor 1 Stunde schrieb Erebos:

Der Code für die PICs ist nicht öffentlich, oder? Sonst würde ich mich da einfach selber mal dran versuchen.

habs mal auf github gelegt, tob dich aus .. 😉

https://github.com/bontango/LISY-PIC-code

Link zu diesem Kommentar
Auf anderen Seiten teilen

Mit dem Code habe ich jetzt einiges mehr verstanden. Was ich für die Ursache von Soundproblemen im RAW-Mode halte, ist, dass pinmame/lisy nicht immer im passenden Rhythmus den LISY35_COIL_SOUNDSELECT Befehl und den dazugehörigen LISY_STANDARD_SOUND Befehl senden. Ich hatte jedenfalls häufig falsche Töne.

Der 'cooked' Modus scheint ersteren ja überflüssig zu machen, da er selbst für eine ausreichende Vorbereitung des Soundbefehls sorgt.

Ich habe mir ausführlich debug Logs angeschaut, und gesehen, dass die Pausen zwischen Sound und Solenoid Befehlen meist über den 18 ms liegen, die als Haltezeit für Standard-Sound vorgesehen sind (Zeile 517). Nur halt gerade bei dem Photon-Phaser nicht.

 

Was ich geändert habe, ist diese Verzögerung mit Timer2 zu steuern, der bei Ankunft eines neuen Befehls gestoppt wird. Damit funktionieren Ton und Spulen wunderbar.

 

Das sollte im Normalfall auch nichts bei Timings für S&T etc. ändern. Wobei ich nicht ganz verstehe, warum es einen ähnlichen Delay nicht auch in der Funktion sound_data_extended gibt.

 

Nur scheint der Code, den du da veröffentlicht hast, Probleme mit den Feature Lamps zu haben. Auch ohne, dass ich irgendetwas verändert habe (hoffentlich), werden nur vier Lampen korrekt angesprochen, die restlichen sind aus. Diese vier sind die mit Adresse 0.

Ich habe MPLAB Xpress zum kompilieren genutzt, und meine .hex Datei ist auch nur 11 KB groß, im Vergleich zu den 16 KB des originalen. Hab ich da etwas anders/falsch gemacht, oder fehlt irgendetwas am Code?

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 17 Stunden schrieb Erebos:

Ich habe MPLAB Xpress zum kompilieren genutzt, und meine .hex Datei ist auch nur 11 KB groß, im Vergleich zu den 16 KB des originalen. Hab ich da etwas anders/falsch gemacht, oder fehlt irgendetwas am Code?

Der Code sollte eigentlich stimmen.

Die Microlab compiler sind aber mitweilen etwas merkwürdig, ich hatte da schon unterschiedliche Effekte.

Welche Version hast Du eingesetzt? Das 16K hex file sollte noch aus der 1.x Serie stammen.

Ich werde mal sehen dass ich nächste Woche mit der aktuellen Compilerversion einen Test mache.

Hats du den Code irgendwo im Netz stehen oder kannst ihn mir schicken?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Habe gerade mal kurz mit XC8 Version 2.2 getestet, da kommt auch ein 11KB grosses hex raus.

Was ich gesehen habe ist, dass ich obwohl der PLL eingeschaltet ist, er also mit 64MHz laufen sollte,  den delay wert auf 16MHz eingestellt habe.

Ich erinnere mich jetzt dass es mit der 1.x version von XC8 Probleme damit gab und er immer mit 16MHz lief.

d.h. das könnte ein  Timingproblem sein, dass er den Lampentreiber zu schnell anspricht.

Du könntest Testweise mal Zeile 737:

OSCTUNEbits.PLLEN = 1;      // turn on the PLL 16*4

in

OSCTUNEbits.PLLEN = 0;      // turn off the PLL 16*4

abändern.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Zum einen habe ich einen Pullrequest mit meinen Veränderungen hochgeladen, damit siehst du alle meine Änderungen. Ich habe immer die XC8 2.05 Toolchain genutzt.

Dann habe ich mit verschiedenen PLL Einstellungen experimentiert, konnte das Problem aber nicht lösen. Auch die delays in lamp_refresh zu erhöhen hat nichts gebracht.

 

Bemerkenswert ist auch, dass der MPLAB Code Configurator einen vor Problemen mit PLL warnt, wenn man Oscillator Source Select auf Internal anstatt FOSC setzt, auch wenn FOSC ja ebenso der Internal Oscillator Block ist. Aber auch da Änderungen vorzunehmen scheint nichts zu bewirken. Ebenso wird _XTAL_FREQUENCY weiterhin auf 16 MHz anstelle von 64 MHz gesetzt, was ich irgendwie erwartet hätte.

 

Ich bin momentan mit Ideen am Ende, vielleicht probiere ich tatsächlich mal mein Glück mit der alten Version von XC8.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hab gerade meinen hex file mal getestet, meine Mata Hari hat damit auch keine gesteuerten Lampen mehr, kann das also zumindest jetzt nachvollziehen.

Downgrade solltest Du nicht machen, muss ja auch mit der neuen Compilerversion funktionieren, Ich schau mir das Mitte nächster Woche mal mit meinem Logicanalyzer an was da bei den Lamps ankommt.

Eventuell hat es auch nicht mit den delays sondern mit den Zero Cross Interrupt zu tun ...

Link zu diesem Kommentar
Auf anderen Seiten teilen

@Erebos

Finde ich übrigens sehr gut deinen 'interruptable delay', wird mir sicher bei dem einen oder anderen Projekt noch nützlich sein 😀

Machst Du viel mit dem Code Configurator? Habe das bislang immer alles von Hand erledigt.

 

Neue Erkenntnisse zum Lampdriverproblem:

Die Refresh Interruptroutine wird korrekt aufegrufen und ich sehe auch wie er in der loop die ICs auf dem Lampdriver nacheinander adressiert,

timing dazu sieht auch gut aus, ABER: die vier 'Lamp Data' Bits sind immer high. (Das sind die Daten in meinem 'inhibit' Array Konstrukt)

Entweder werden die mit XC8 2.x im 'lamp set' nicht sauber gesetzt oder die Interruptroutine kann die (globalen) Daten nicht sauber lesen.

Vielleicht fällt Dir ja dazu was ein? ...

 

Gruesse

Ralf

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 4 Stunden schrieb bontango:

Machst Du viel mit dem Code Configurator? Habe das bislang immer alles von Hand erledigt.

Ich habe vorher noch nie etwas mit den PICs gemacht, deswegen habe ich den Code Configurator genutzt und das Ergebnis dann mit dem Datenblatt abgeglichen. Aber bei anderer Hardware ist es sehr empfehlenswert, sich auf so eine Unterstützung zu verlassen, weil es ja auch schnell noch komplizierter wird.

 

 

Deine Messungen waren hilfreich, damit konnte ich das Problem identifizieren und lösen! Es liegt tatsächlich an lamp_set und dem neuen Compiler.

Es gibt einige Warnungen beim kompilieren, die ich als unwichtig abgetan hatte. Er warnt vor binary integer literals und case ranges. Ersteres scheint zwar zu funktionieren, aber die switch cases in lamp_set werden nicht korrekt ausgeführt. Das erklärt auch, warum er die Lampen mit Adresse 0 bei mir noch korrekt steuern konnte, ein case 0 ... 14:  wurde wohl zu case 0: ohne dass eine Fehlermeldung kam. Ärgerlich.

Aber auch schnell behoben. Natürlich würden passende if-Bedingungen es an dieser Stelle auch tun, ich war aber so frei es wesentlich kürzer zu formulieren (ersetzt switch(lamp) in Zeile 356):

    // avoid usage of case ranges
    if (action)
    {
        // Clear the bit to turn lamp off
        inhibit[lamp % 15].byte &= ~(1 << (4 + lamp / 15));
    }
    else
    {
        // Set the bit to turn lamp on
        inhibit[lamp % 15].byte |= 1 << (4 + lamp / 15);
    }

Das muss natürlich auch für die zusätzlichen Lampdriver implementiert werden.

 

Damit tut es jetzt. Ganz glücklich bin ich noch nicht, eine kurze Testrunde ergab, dass zuweilen Töne abgeschnitten werden wenn gleichzeitig viele Lampen geändert werden (vermutlich leicht zu reparieren) und die Kugelauswurfspule feuerte mehrmals zu kurz.. Vielleicht passe ich das delay noch ein bisschen weiter an, mal schauen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Stunde schrieb Erebos:

Es liegt tatsächlich an lamp_set und dem neuen Compiler.

Gut dass Du es so schnell gefunden hast, habe mal ein wenig gegoogelt, ist wohl ein Bug im XC8 compiler.

Ich habe mit dem 2.20 noch nicht mal Warnungen bekommen 😐

vor 2 Stunden schrieb Erebos:

Vielleicht passe ich das delay noch ein bisschen weiter an, mal schauen.

wie wäre es denn damit die 'momentary Solenoids' Befehle direkt in der High priority interrupt routine abzufackeln und gar nicht erst in die Befehlsqueu zu geben.

Das sollte auch dem ansprechverhalten der Bumper und Slingshots zugute kommen

in etwa so:

 

   union isr_two {
    unsigned char byte;
    struct {
    unsigned COMMAND:3, b0:1, b1:1, b2:1, b3:1, IS_CMD:1;
        } bitv;  
    } isr_data;

.

.

.

          if(SSPSTATbits.D_nA)                // last byte was data (D_nA = 1)
            {
                //check if we have a solenoid cmd which has to be executed immidiatly
                isr_data.byte = SSP1BUF;
                if (( isr_data.bitv.IS_CMD == 1 ) & ( (isr_data.bitv.COMMAND) == LS35COIL_MOM_SOL ))
                {
                    SOUNDSELECT = SOLENOIDS_SELECTED;
                    //in 'solenoid' mode just pass data   
                    MOM_SOL_SOUND_DATA_A = isr_data.bitv.b0;
                    MOM_SOL_SOUND_DATA_B = isr_data.bitv.b1;
                    MOM_SOL_SOUND_DATA_C = isr_data.bitv.b2;
                    MOM_SOL_SOUND_DATA_D = isr_data.bitv.b3;    
                    interrupt_delay(); //cancel a possible running sound command
                }
                else //put byte from master to Buffer, interpret in main                                
                BufferIn ( isr_data.byte );
                
                if(SSPCON1bits.WCOL)        // Did a write collision occur?
                {

 

 

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Wichtige Information

Datenschutzerklärung und Registrierungsbedingungen