Hallo,
ich habe am WE für meinen Sohn einen "Geschichtenbär" geschenkt
bekommen. Der hat die Möglichkeit, weitere Geschichten von Cartridges
abzuspielen.
Nun wird das Teil schon ewig nicht mehr hergestellt. Die Cartridges
gibts nur noch selten bei Ebay zu exorbitanten Preisen. Auswahl fällt
demnach auch sehr klein aus.
Der Plan ist, das ding mit neuen Daten (Hörbücher etc.) zu versorgen
damit der Teddy nicht im Container landet.
Da hab ich mir gedacht, besorgst dir mal eine und schaust mal drüber.
Aufgeflext, eingescant. Kann mir jemand sagen was das für speicher sein
könnten? Evtl SPI da die Leiterbahnen wie ein Bus aussehen?
Gruß, Christian
(Alternativ "operiere" ich Bruno und bau ihm ein Raspberry ein :p)
Ganz links ist GND, dann kommt VCC, ganz rechts ist auch VCC.
Den Rest wirst du dir im Betrieb mittels Oszi/Logic Analyzer anschauen
müssen.
Ich zähle 7 Leitungen, daher würde ich einen 4-Bit Bus vermuten.
Clk + 4 Data + ALE + CS?
Kaffeesatzleserei.
RPi fände ich doof. Reverse die Leitungen/Protokoll und setz' 'nen µC
(ggf. mit Mikro-SD) in deine Kassette.
Pin 5 und 6 sind die CS Leitungen für die Chips, da jede Leitung nur zu
einem Chip geht, die restlichen 5 dann vermutlich Clock + Data.
Wie hast du die Einfärbung im Bild gemacht?
Bei zehn benutzten Anschlüssen bleiben acht für Inhalte übrig
(Versorgungsspannung und Masse abziehen).
Das kann also irgendwas sein, Speicher mit 4-Bit-Datenbus, SPI, I²C
oder auch analoger Kram, der in den ICs unter den Klecksen erzeugt
wird.
Da die Innenbeschaltung Deines "Geschichtenbärs" vermutlich ebenso aus
irgendwelchen Klecksen besteht, wird man entweder die Dinger röntgen
müssen, oder aber mit einem Logikanalysator die Verbindungen zwischen
Steckkärtchen und Bär abhorchen.
Der Aufwand dürfte erheblich sein; des Bären Elektronik durch einen Pi
o.ä. zu ersetzen und einen SD-Karten-Leser einzubauen, über den dann
einfach mp3-Files geladen und abgespielt werden, dürfte einfacher sein.
Ein Pi ist hier schon überdimensioniert; sofern der Bär nichts weiter
macht als labern, reicht ein simples mp3-Modul.
Es kann natürlich sein, dass die Dinger jeweils parallel per SPI
angeschlossen sind, und sich nur eine Clock-Leitung teilen:
2 * CS + 2 * MISO + 2 * MOSI + CLK.
Rufus Τ. Firefly schrieb:> Bei zehn benutzten Anschlüssen bleiben acht für Inhalte übrig> (Versorgungsspannung und Masse abziehen).
Nein 7. VCC ist doppelt dabei.
Danke,
Wundert mich, das dort 2 chips drauf sind. vieleicht waren die ja
günstiger.
Einfärbungen sind mit GIMP gemacht, Leitungen mit Zauberstab markieren,
neue transparente Ebene in rot od. blau, Auswahl invertieren, markierung
löschen.
Dann bleiben nur die ausgewählten Bahnen.
Vorher noch die Beiden Bilder ausrichten und übereinander legen.
der RPi wärs nur geworden, wenn das mit dem Speicher nix wird, dann hätt
ich die interne elektronik komplett getauscht. Muss aber nicht sein, wär
mir lieber dort ne SD Karte oder sowas reinzuklemmen.
Ich werd an die Cardridge mal kabel anlöten und im Betrieb mal die Pegel
mitm oszi messen. Logic-Analyzer hab ich grad nicht parrat, wenn aber
3,3v dann kann ich das ding auch an den GPIO vom rasp. hängen oder an
nen parallelport oder an nen avr. Ich schau mal.
Gruß
Christian schrieb:> Einfärbungen sind mit GIMP gemacht, Leitungen mit Zauberstab markieren,> neue transparente Ebene in rot od. blau, Auswahl invertieren, markierung> löschen.> Dann bleiben nur die ausgewählten Bahnen.>> Vorher noch die Beiden Bilder ausrichten und übereinander legen.
Ok, also von Hand. Ich hatte auf eine automatisierte Lösung gehofft ;)
automatisch könnteste ja per Gimp-Script machen. Ebene nehmen, in 1 bit
wandeln und einfärben. War mir händisch aber schneller :)
Das Vieh zappelt übrigens auch mit Armen und Beinen, hat also ettliche
Servos drin, ich denk mal mit Analog is das nicht zu machen.
so, hab mal kurz durchgeklingelt
1 - gnd
2 - vcc 3,3v
3 - nc
4 - nc
5 - bei Modus1 clock 32khz 1,2us
6 - bei Modus2 clock 32khz 1,2us
7 - ???
8 - data
9 - data
10 - data
11 - data
12 - vcc 3,3v
alles 3.3v, müsste ich also mal irgendwie nen LogicAnalyzer
organisieren.
5,6 sind mMn das Clock signal des jeweiligen Chips (es gibt 2 Modi,
Märchen und Musik). 8-11 sieht verdächtig nach Daten aus.
Einzig die 7 macht micht stutzig. sieht wie ein regelmäßiger clock aus,
und sobald man ein neues Kapitel anspringt etc. sehe ich "daten". Werden
damit evtl. Speicherbereiche angesteuert? (daher so regelmäßig beim
normalen abspielen, unregelmäßig beim seek.)
Dann müsste ich aber alle servos ansteuern, musik, bewegung,
positionsabfrage etc. das halte ich für komplizierter als mit einfach
mal den speicher anzuschauen ... Vieleicht ist es ja auch garnicht allzu
komplex.
Wie klingt der 'Erklär-Bär' denn? Sind das eher sehr rauhe 4 bit, oder
schon saubere 8 bit?
Der Hersteller jedenfalls liefert keine Daten:
http://www.jetta.com.hk/
32kHz bei 4 Bit, macht 16kHZ bei 8 Bit, kann schon sein.
Das Chip Select ist demnach über die Clock realisiert.
7 könnte dann eine Art "address increment" sein.
Häng doch mal einen kleinen Mikrocontroller dran, der synchron zum Clock
die Nibbles eines 8Bit PCM raushaut. Wenn der Puffer leer ist, einfach
wieder von vorn. Wirst ja sehen, ob das geht. Gegebenenfalls Nibbles
tauschen.
Was macht das Ding denn, wenn der Track zu Ende ist? Das müsste doch
auch noch signalisiert werden. Geht das vielleicht mit über die 7?
Klingt für mich nach 8 bit Sound, evtl. mit aLaw oder µLaw noch etwas
aufgemöbelt. Was mich dabei wundert, sind die lediglich 4
Datenleitungen, denn irgendwoher müssen ja auch noch die Servosignale
für die Motoren kommen. Läuft beim Liedchen immer die gleiche
Motorsequenz oder ist das jedesmal anders?
Wenn das jedesmal anders ist, könnte ich mir vorstellen, das der Rechner
einfach das Audio ein wenig auswertet und mit den Ohren oder der
Schnauze wackelt.
ghls Vorschlag klingt gut, da könntest du dich mal ranmachen.
soo, hab ihn mir jetzt nochmal in aktion angeschaut.
also die bewegungen sind definitiv programmiert. Audio-Auswertung is das
nicht, da er gewisse bewegungen bereits macht, wenn er nichts sagt.
also bei "streck die hände in die höhe" hat er schon vor dem satz die
hände oben. Also definitiv gescriptet.
Ich werd morgen mal den analyzer drankleben und mir das mal
mitschneiden.
Kann es sein, das über pin 7 quasi die steuersignale kommen (track
anfang, ende, handpositionen)? Dann würde das ja bedeuten, das der IC in
der Cardridge nicht nur ein speicher ist sondern aufwändiger. Warum
sollte ein hersteller soviel logik in ein externes modul stecken wenn es
doch eigentlich nur den sinn eines speichers hat.
Nagut, danke erstmal, ich werd morgen mal berichten!
MFG Christian
Naja, du musst ja noch wissen wie groß der Speicher ist.
Woher soll der Player sonst wissen wieviele Samples er holen kann? Etwas
an Metadaten wird dann doch noch gebraucht.
Für den Hersteller könnte der "Sinn" durchaus darin bestehen, die ganze
Sache so unorthodox zu gestalten, daß er sich das lukrative
Folgegeschäft mit den Cartridges sichern wollte - während der "Bär"
sozusagen "unter Preis" verkauft wurde. Ist die Sache zu einfach zu
kopieren, stehen die Fremdanbieter sofort bei Fuss - und liefern "nur"
Cartridges. Der Bär selber ist dann evtl. Gebrauchsmuster/Copyright etc.
produktrechtlich einfacher zu schützen, nicht jedoch die Verwendung von
"Speichermodulen". Es dürfte also einfach "Absicht" gewesen sein...
Christian schrieb:> (Alternativ "operiere" ich Bruno und bau ihm ein Raspberry ein :p)
Wenn der arme Bruno unters Messer muss, dann würde ich zu einem
preiswerten MP3 Player und einem kleinen 0,5W Verstärker o.ä. greifen.
Hallo, CHristian,
schau mal da : http://elm-chan.org/works/sd8p/report.html
Wir haben das DIng damals in etwas abgewandelter Form (nur eine Datei
abspielbar) in unserer Relaisfunkstelle eingesetzt....
Plausibel wäre, das es sich hier einfach um "zwei Files in Hardware"
handelt.
Ich glaube kaum, dass sich der Entwickler hier mit Filesystemen und
komplizierten Strukturen aufgehalten hat. Sicherlich werden feste
Datenpakete mit z.B. entsprechender ID versandt. Bewegung und Sprache
kombiniert, Musik extra.
Pin 7 würde ich für eine Steuerleitung halten, z.B. R/W. Der Controller
muß erstmal sagen (schreiben), welche Adresse er lesen will, dann wird
auf Lesen umgeschaltet und es kommen Daten aus dem Speicherchip. Beim
Kapitelwechsel herrscht da natürlich Aktivität, weil der Controller im
Inhaltsverzeichnis herumsucht. Während des Abspielens muß nur
gelegentlich eine neue Blockadresse übermittelt werden, so daß das
Signal sehr regelmäßig aussieht.
Es wäre interessant zu sehen, in welche Richtung jeweils Daten
übertragen werden. Ein Widerstand in einer Datenleitung schafft da (am
Oszilloskop) Klarheit.
So, hab mal weiter gemacht.
Aktuell hab ich noch keinen Logic Analyzer zur Hand. Daher erstmal nur
das oszi.
Das bärchen wird langsam zum Cyborg, hab die Cardridge verlängert sodass
ich jetzt die Leitungen unterbrechen kann etc.
Wie messe ich denn die Datenrichtung? Ich hab einen Widerstand zwischen
Leitung.
Dann habe ich 2Messpunkte:
Leitung 1 - zum Bär : 3v
Leitung 2 - zur Cardridge: 2,8v
würde das nicht bedeuten, das die Signale vom Bär kommen?
Im übrigen hat das Tier auch eine Geschichte integriert, also ohne
Cartridge. Wenn die Läuft, habe ich auch Signale auf dem Slot.
MFG
Das ist ja wie bei der Modelleisenbahn.
Sollte nicht eigentlich der Junior .... ;-)
Falls Du einen Rechner mit Druckerport hast, hilft vielleicht das
weiter:
http://jwasys.home.xs4all.nl/old/diy2.html
Damit lässt sich sicher schon etwas anfangen bis der LA kommt.
ja den TFLA nutze ich hier, bekomm ich aber nix brauchbares raus...
Ich werd heut abend mal versuchen, meinen Raspberry zu nutzen, der
sollte mehr performance haben:
http://tuxbabe.eu/raspalyzer.html
Vieleicht kann ich das dann auch gleich aufzeichnen etc.
Kann mir eigentl. jmd. sagen wie ich die Flussrichtung der Daten
bestimme? Ich steh da n bissl aufm schlauch.
MFG Christian
@hp-freund
der Junior ist erst 1,5 Jahre alt, das gibt ärger wenn ich dem nen
Lötkolben in die Hand drücke. So hat der Papa aber auch noch viel Zeit
:)
Der kleine hat eh noch Angst vor Bruno.
Christian schrieb:> Kann mir eigentl. jmd. sagen wie ich die Flussrichtung der Daten> bestimme? Ich steh da n bissl aufm schlauch.
Interessante Frage. Oder ich weiss es einfach nicht besser :-)
Meine Idee:
1m Koaxkabel in die Datenleitung mit Abschlusswiderstand und dann mit
dem Oszi vorn und hinten messen. Sollte etwa 5ns Unterschied ergeben.
Oder gibt es eine bessere Lösung?
Die Richtung kann ja auch wechseln, also evtl. die Messung mit ext. Takt
triggern???
Könnte man die Datenrichtung bei Unidirektionaler verbindung nicht mit
einer Diode feststellen?
So mal kurz zum Status:
Logic Analyzer kann ich heute erst probieren, bis dato hab ich aber ein
bisschen mitm Raspberry und dessen GPIO rumgespielt.
Außerdem gabs einige englischsprachige Seiten, die mit dem Tier (TJ
Bearytales) rumgebastelt haben. Auch welche, die das Ding direkt
angesteuert haben.
Aufgrund dessen, werde ich wohl die interne Elektronik komplett
austauschen, denn ich habe Festgestellt, dass die Daten auf der
Cartridge doch nur ein teil vom eigentlichen Programm sind. Diverse
Texte wie z.B. die Kapitelansage sind auf dem Mainboard. So müsste ich
also, sollte ich die Cartridge "nachbauen", meine Daten in das selbe
Format bringen. Wer weis welche Beschränkungen man da noch feststellt.
Ich erhoffe mir vom direkten ansteuern, dass auch die Bewegungen
flüssiger werden und ich völlig frei beim steuern bin.
Ich behalte trotzdem das Reverse Engineering im Auge, spätestens wenn
ich einen geeigneten Logic analyzer habe.
Noch einige Infos die ich erlangt habe:
- Es handelt sich nicht um eine einfache SD-Card im 4-Bit Modus,
zumindest konnte ich sie an einem Kartenleser nicht zum reagieren
Bewegen. (Vermutung war SD-Card, da 4 Datenleitungen + clock + Command)
- Pin 7 scheint der gemeinsame Clock, Pin 5/6 scheint die Steuerleitung.
- das Teil scheint ziemlich komplex zu sein. Im inneren befindet sich
auch eine Antenne. Scheinbar hatte der Hersteller noch einiges vor.
- Ich vermute, auf der Cartridge befindet sich ein richtiges
Dateisystem.
- Wenn man die Cartridge stört (z.b. Data-Leitung im Betrieb auf GND),
so laufen die Bewegungen weiter, aber der Ton setzt aus.
Heut abend gehts dann weiter, Ich werd das Teil mit seinen
Spezialschrauben mal öffnen und werd mal die Hardware ausbauen.
So, da bin ich wieder.
mit dem Logic analyzer hat das auch alles ganz gut geklappt.
Im Anhang einige Dumps der Datenpakete.
In Kombination mit meinem Raspberry hab ich dann auch das Init
erfolgreich zur Karte senden können. Die Karte antwortet entsprechend.
Ist jemanden dieses Protokoll bekannt? Oder muss ich das alles händisch
nachbauen...
Das normale Datenpaket ist wie folgt aufgebaut (init_pressplay.png):
cs1-select (data 0b1111)
data 0b0010 (write to card)
cs1-release
cs1-select (data 0b1111)
data 0b0000 (write to card)
cs1-release
cs1-select (data 0b1111)
data 0b1001 (write to card)
data payload (write to card)
data payload (write to card)
data payload (write to card)
data payload (write to card)
data 0b1111 (write to card)
data 0b1000 (write to card)
cs1-release
cs1-select (data 0b1111)
data 0b0000 (write to card)
data payload (read from card)
.... .... ....
cs1-release
Ideen?
Ansonsten auch noch analysen vom audio-playback (play_??.png).
bestehend aus:
1 clock - write to card
1 clock - write to card
2 clocks - read from card (=8bit)
Ich glaube bei ca. 8khz, muss ich aber nochmal nachmessen.
