Beiträge von VictorPhilipp

Hallo zusammen,

ich bräuchte einen Code für die Zulassungsnummer
203703706

Vielen Dank!

Kleines Update: Mein Flash-Leser ist endlich angekommen und ich konnte einen von zwei ausgelöteten Flashchips tatsächlich auslesen (den einen hat's wohl teilweise zerbröselt - kann aber sein, dass ich den schon vorher kaputt gemacht hatte).

Zwischenergebnis: Nein, da sind keine MP3-Dateien drauf. Die Audiodaten sind im 4-bit ADPCM-Format abgespeichert, mit ganz verschiedenen Abtastraten. Wenn man sich den Dump anschaut, starten die Audiodaten immer nach dem Keyword "data". Vorher stehen ein paar Metadaten und der Titel der Datei (z.B. "aussp_st" für "Ausspielung Start"). Bestimmt ist da auch irgendwo die Abtastrate versteckt.

Hat man sich einen Audioabschnitt rausgezogen, lässt er sich in Audacity über Datei > Importieren > Rohdaten importieren (Konfiguration siehe Screenshot; wie gesagt, die Abtastrate unterscheidet sich von Sample zu Sample).
So ganz perfekt ist das Ergebnis allerdings noch nicht - die Wellenform ist bei mir nicht an der Mittellinie ausgerichtet bzw. sie verschiebt sich teilweise. Mag vielleicht daran liegen, dass der Codec (VOX ADPCM) doch nicht ganz 100%ig passt.

Ich danke dir, Stephan.
Nein, ich wurde nicht nervös. Das Forum meinte nur, dass ich meinen Beitrag angeblich noch nicht gepostet hatte. Tja, wurde dann ein Doppelpost, den ich nicht mehr zurücknehmen konnte.

Bitte diesen Beitrag ignorieren. (Den darüber aber bitte nicht! ;[)

Hallo zusammen!
ich benötige einen Code für meinen Criss Cross.
Zulassungsnummer: 203703706
Danke!

Zitat von Rattenfänger

Ich bin gerade dabei, mir einen Tester für Flipperplatinen mit einem Arduine zu bauen. Die Idee auch einen Tester für Auszahleinheiten und vieleicht Laufwerke ist auch schon im Hintergrung gereift. Vieleicht darf ich dich mal für ein par Fragen in dem Zusammenhang kontakten.

Klar, gerne. Ich muss aber dazu sagen, dass ich mich bei der Münzeinheit zwar grundsätzlich an das Übertragungsprotokoll gehalten habe (Multi Drop Bus; die Münzeinheit und der Münzprüfer hängen am selben Bus, weswegen sie beide per MDB kommunizieren), aber bei den Geräteadressen, Befehlcodes und Parametern (zur Abfrage der Sensoren und zur Auszahlung) nicht der Spezifikation (siehe https://www.ccv.eu/wp-content/upl…ecification.pdf, ab Seite 237) gefolgt bin.

Ich bin gerade dabei, mir einen unmodizierten Criss Cross hinzustellen. Da könnte ich mal die Kommunikation analysieren und die Original-Befehle rausziehen. Danach könnte ich dich sicher noch besser unterstützen.

Hallo zusammen,

ich bin beruflich in der Software-Entwicklung tätig, dort aber leider nicht wirklich hardwarenah unterwegs. Deshalb (und weil es mich natürlich interessiert) wollte ich schon seit vielen Jahren ein privates Hardware-Projekt verwirklichen. Im Jahr 2019 war es schließlich soweit: Ich habe große Teile eines ADP Hot Cherry technisch analysiert und den Automaten mit meinem eigenen Herz (auf Arduino-Basis) ausgestattet. Das war zwar jede Menge Arbeit, es hat aber definitiv Spaß gemacht und ich konnte einiges dabei lernen. Letztes Jahr hatte ich dann ein Vorstellungsvideo aufgenommen, wobei ich jetzt erst dazu kam, es zu schneiden.

https://www.youtube.com/watch?v=FEawBuAyZmE

Ich überlege, ob ich in den nächsten Monaten daraus eine Videoserie mache. Vorher möchte ich aber noch mit ADP abklären, ob die damit fein sind, wenn ich etwas ins Detail gehe (auch wenn – soweit ich es verstanden habe – nach deutschem Recht grundsätzlich nichts gegen Reverse-Engineering spricht; der Knackpunkt wäre nur, wie und welche Informationen verbreitet werden dürfen).


Auch einen Merkur Multi Multi habe ich umgebaut, das ist aber eine Geschichte für ein anderes Mal.

Hallo Stephan,
anscheinend hatte ich beim ersten Aufbau noch einen Fehler drin. Ich hab das ganze jetzt erneut aufgebaut und die Sounds werden tatsächlich abgespielt.
Danke dir nochmals!
Gruß
Victor

Hallo Stephan,
vielen Dank für das Programm. Das hat jetzt natürlich mit meiner Soundkarte nicht hingehauen, weil die Identifizierung nicht übereinstimmt. Da ich mir jetzt nicht extra einen noch funktionsfähigen Automaten kaufen wollte, um mit einem Logic Analyzer die Signale zurückzuverfolgen, habe ich das Board noch etwas weiter analysiert. Die Ziele sind weiterhin:
1. die Sounds aus dem Flashspeicher rausziehen (ich bin echt gespannt ob das Werbeversprechen "MP3-Sound" wirklich stimmt) und
2. ggf. das Programm verstehen und eine native Ansteuerung basteln.
Mir ist aufgefallen, dass zwar der SPI-Port des DSPs nicht nach außen geführt wurde (mit Spulendraht könnte man das vielleicht provisorisch schaffen), eine JTAG-Schnittstelle ist aber über die Test-Pads erreichbar. Leider habe ich (noch) keinen JTAG-Adapter (lange Lieferzeit) und hab mit OpenOCD noch nicht gearbeitet, das würde ich aber irgendwann ausprobieren.
Parallel dazu habe ich in der Zwischenzeit eine Soundkarte geopfert und den Flashchip ausgelötet. Auch hier warte ich noch auf die Lieferung eines Flash-Programmers (FlashcatUSB), den ich über ebay ersteigert habe.

Derweil verbessere ich meine Reverse-Engineering-Skills mit der Analyse einer gelben DB, die hier noch rumfliegt...

Bei einem Update melde ich mich.

Hallo zusammen,
nachdem ich in diesem Forum schon seit einiger Zeit lesend unterwegs bin, schreibe ich heute mal meinen ersten Beitrag.
Ich versuche seit einigen Wochen, das Soundmodul einer ADP Profitech-3000-Kiste per serieller Ansteuerung zum Leben zu erwecken - leider bisher erfolgslos. Mein Ziele sind,
(1) die Sounds von einem ADP Criss Cross zu extrahieren und
ggf. (2) die Soundplatine für eine Rekonstruktion des Automaten zu nutzen (ich hatte letztes Jahr einen Hot Cherry auf eine Arduino-basierte Plattform umgebaut, dabei allerdings das Soundmodul durch zwei MP3-Player ersetzt).
Meine Hoffnung ist, dass mir vielleicht jemand den entscheidenen Tipp geben kann, wie ich dem Modul doch noch ein paar Sounds entlocken könnte.

Ich habe mich stark an die Beschreibungen von kuehlbox im Topic
https://www.automatenfreunde.de/index.php?page…d&threadID=3646

gehalten.Über ein Labornetzteil versorge ich das Soundmodul mit +12V (Pin 3 am 8-poligen Stecker und GND an Pin 5). Der Arduino ist mit dem 6-poligen Stecker wie folgt verbunden:

Pin Funktion	Arduino-Pin
1   REPLY	30
2   GND		GND
3   Audio In	-
4   DATA	22
5   CLOCK	23
6   +12V	-

Einige Erkenntnisse:

[*]Der DSP läuft mit 3,3V. Die Eingangs-Pins (DATA und CLOCK) haben jeweils einen Pull-Up-Widerstand gegen +3,3V. Um sie über den Arduino auf LOW zu schalten, reicht es also aus, den Arduino-Pin gegen Masse laufen zulassen (Open Collector: digitalWrite(X, LOW); pinMode(X, OUTPUT);). Ansonsten sind sie wegen der ext. Pull-Ups HIGH (pinMode(X, INPUT);).[*]Die PINs ~DATA, ~CLOCK und ~REPLY laufen über einen CMOS Hex-Schmitt-Inverter (74LCX14).
[*]CLOCK (= PINIT/NMI) schaltet bei steigender Flanke; demnach muss man über ~CLOCK eine fallende Flanke erzeugen, wenn DATA geschrieben werden soll.[*]Wie kuehlbox angemerkt hat, reagiert die Software auf dem DSP auf 8-Bit-Codes (Least-Significant-Bit First), wobei noch ein Start- und Stopp-Bit hinzukommen (START -> D0 -> D1 -> ... -> D7 -> STOPP). Ausgehend von DATA (nicht-invertiert) ist das Startbit immer 0 und das Stoppbit immer 1. Invertiert (~DATA, also das, was man physikalisch übertragen muss) eben umgekehrt.[*]Der DSP scheint das Programm direkt vom externen Flash zu laden. Ein Hinweis hierauf liefern die nach außen gelegten Brücken für MODA, MODB, MODD. Die Brücke für MODA würde zu GND (0) schließen, die Brücken für MODB und MODD zu 3,3V (1). Ich schließe deshalb, dass bei geöffneter Brücke MODA=1 und MODB=MODD=0 gilt. Laut DSP-Handbuch lädt der Chip das zu startende Programm bei dieser Konfiguration aus dem externen Speicher ("byte-wide memory").

Ein C++-Beispiel zur Ansteuerung habe ich angehängt (POWER_RELAY steuert bei mir ein Relais, das wiederrum die +12V Versorgungsspannung des Soundmoduls schaltet).
In meinen Versuchen konnte ich bisher durch Zufall einen Foul-Alarm auslösen. Leider geschah das mitten in der Nacht, während das Modul an einen Lautsprecher angeschlossen war. Ich musste den Versuch schnellstens abbrechen und konnte die Situation später nie mehr nachstellen. Einen anderen Sound konnte ich bisher nicht erzeugen.

Das Soundmodul reagiert bei mir auf insgesamt 2 Codes:

[*]Überträgt man DATA = 253 (logisch: 0x1111111010, physisch: 0x0000000101) und danach DATA = 0 bis (ich glaube) 127 scheint der DSP in einen Modus zur Übertragung von digitalen Audiosamples (über ESAI) zu gehen. Das zweite Wort gibt hierbei die Anzahl der zu übertragenden Audiosamples an. Nach Initiierung blinkt die "Takt"-LED auf dem Soundmodul wohl im Takt des "FRAME SYNC"-Signals und das Modul erwartet über AUDIO_IN Audiodaten. Da mich dieser Modus nicht wirklich interessiert, habe ich meine Analyse hier (noch) nicht weiter vertieft.

[*]Überträgt man DATA = 255 (logisch: 0x1111111110, physisch: 0x0000000001) wird es gefährlich (hiermit habe ich schon ein Soundmodul "kaputt" gemacht). Nach der Übertragung sehe ich in meinem Labornetzteil, dass das Soundmodul plötzlich etwas weniger Strom aufnimmt (etwa 0,18A statt 0,24A). Die "Takt"-LED hört auf zu blinken. Erst dachte ich, dass es sich hier um eine Art "Stand-By"-Modus handelte. Aber das Programm auf dem DSP scheint an dieser Stelle auf eine Eingabe zu warten. In meinen Tests hatte ich vermutlich direkt danach erneut eine 255 gesendet, was wohl zur Folge hatte, dass die "Takt"-LED nun nicht mehr blinkt. Eventuell habe ich hierdurch das Programm auf dem Flash gelöscht. Auf jeden Fall hatte ich eine bleibende Veränderung bewirkt, die ich danach auch durch einen Hard-Reset per Stromwegnahme nicht mehr rückgängig machen konnte.

Leider besitze ich keinen funktionierenden Automaten, der sich noch in seinem Grundzustand befindet, weswegen ich keine Möglichkeit habe, die Kommunikation der Datenbank mit dem Soundmodul abzuhören. Hat das von euch vielleicht schon jemand gemacht?

Bin für jeden Tipp dankbar.Gruß
Victor