http://satellite-board.de

Hi,
die Nokia wird ja überall als die wunderbox gelobt, ein Freund hat nun eine mit AVIA500 zu mir zwecks Linuxumbau gebracht, Sie hat nur Probleme gemacht.
Mein Linux mit C64 EMU lief überhaupt nicht, war aber klar weil ich für meine Phillips und Sagem die GTX Treiber entfernt hatte (sind ja ENX), und die Nokia neben AVIA500 auch noch GTX hat. Hab die Treiber reinkopiert, lief aber dennoch nicht.
Selbst Alex-W Basisimage 1.6 lief nicht sauber, zumindest schlechter als auf der Philips, und das will ja was heissen.....
Ich hab zwar was gefunden das lief, nach ein paar stunden hängt die Box auf dem empfangen Sender fest und ist nicht mehr bedienbar.

Wer hat eine alte Nokia und ähnliche Probleme, und welches Image wird dafür genutzt? aber bitte eines ohne dem Federfieh!

Sepp

Hehehe D-Box 1 und AVIA 500. Nicht schlecht, wo haste denn die her? :D

Zur Sache:

Die aktuellen Releases ab dem 3. 10. haben irgendwie alle einen Schlag weg und machen bei den Nokias eigentlich nur Streß. Da hilft nur ein älteres Image oder auch Snapshot. Ich habe mir hier für meine Nokia 2xI AVIA 600 GTX selber ein Image zusammengebastelt. Das stellt wohl, was die Stabilität betrifft, die neuen Images locker in den Schatten. Zumindest bei den Nokias. Wie die Sagems und die Phillipskisten damit klarkommen weiß ich nicht. Das nutze ich mittlerweile seit einem Monat. Abstürze? Was ist denn das? Hänger? Kenn ich nicht? Streaming Resyncs? Gibt es sowas auch? Webinterface? Perfekt. Tuxvision? Perfekt.

Gruß Sci-Fi

D-box 2 ist ja eh klar.
nutzt Du echt tuxvision?

hast Du eventuell eine IR-Tatstatur mit Trackball drann, dann wäre das natürlich ne feine Sache, ich dachte die wäre noch nicht fertig???

Für meine Philips habe ich auch mittlerweile ein Drops gefunden welches super läuft, das Federvieh habe ich natürlich entfernt. Bei einem anderen Image ist ein C-64 Emu mit 8 Spielen dabei, bekomme den aber nicht in das drops rein weil unterschiedliche Kernel und C++ Libarys....

Hab probleme mit dem erstellen meiner tuxbox, weil cygwinn nicht will, hatte es aber auch auf einer FAT32 probiert und erst jetzt gelesen daß ich eine NTFS nehmen muß, wenn das nicht immer gleich einen Tag schlucken würde um mal "schnell" saugen und Compilieren......

Habe außerdem riesen Probleme mit NTBFT, kann zwar die 1.6er super bearbeiten, aber nach dem abspeichern ist die datei 7,00 MB und kann nicht geflasht werden, flashen mit TBFT geht auch nicht, und im Expertenmodus trau ich mich nicht... hast Du da eventuell eine Idee???

Grüße

Sepp

Moin

Also mit dem New Tuxbox Flashtool kannst Du immer nur eine Partition vom Flash bearbeiten. In diesem Fall das cramfs. Unter Service, Softwareaktualisierung, Expertenfunktionen, Einzelne Partition auslesen (root (cramfs)) und dann das mtd2.img mit dem New Tuxbox Flashtool vom Temp Ordner der Box auf den Rechner ziehen. Davon gleich eine Sicherheitskopie machen falls das Bearbeiten schief geht. Das New Tuxbox Flashtool ist noch sehr buggy. Gewünschte Änderung durchführen, erst als mtd2.img wieder speichern und dann wieder per FTP in den Temp Ordner auf die Box schieben. Unter Service, Softwareaktualisierung, Expertenfunktionen, Einzelne Partition einspielen (root (cramfs)) wieder flashen, Neustart, fertig.

Gruß Sci-Fi

Das mit den fehlenden Treibern für den C64 Emulator in den 1.6er Images stimmt nicht so ganz.

Wenn du den EMU mal in ein 1.6er Image eingebaut hast und den C64er EMU per Telnet startet wirst du höchstwahrscheinlich die Fehlermeldung bekommen, daß die libstdc++.so.3 fehlt.
Ist aber kein größeres Problem

Du fügst mit den New Tux Flash Tools im cdk.cramfs im Pfad /lib einen Link mit der Bezeihnung libstdc++.so.3 ein ,der auf die libstdc++.so.5.0.0 verweist. Dann klappts auch wieder mit dem C64er Emulator

Hatte zumindest zuletzt noch beim alexW 1.6.2 so geklappt und ich gehen davon aus, daß es eigentlich auch noch im aktuellen 1.6.3 noch so laufen müßte.
Im Zweifelsfall per Telnet prüfen was sonst noch fehlt und den entsprechenden Link im Image einfügen.

Thanks für den Tipp,
das hatte ich schon probiert. Der C64 EMU den ich wollte stammt aus einem 1.6er und sollte in ein 1.5er rein.
Habe zuerst das mit der LIB probiert, dann einfach Platz gemacht und die C++ LIB reinkopiert, es kam dann eine andere Fehlermeldung.

Da ich absoluter Linux NEWBEE bin ist das alles nicht so einfach.

Momentan compiliert Cygwin im Hintergrund, morgen weiß ich dann ob es diesmal geklappt hat.....
Ideal wäre es wahrscheinlich die Sourcen von diesem EMU zu haben, dann müßte es doch theoretisch überall laufen.
Diese EMU ist sowie genial gelöst, er ist komplett komprimiert gespeichert, und wird beim Aufruf im RAM entpackt, beinhaltet 2 Seiten mit Spielen und braucht nur 400K Speicher.

Falls jemand diese Source hat wäre ich sehr dankbar dafür. Der Ersteller hat sich leider nicht verewigt, weder im Prog noch in den Gamepacks.

Was hat eigentlich Telnet für einen Vorteil gegnüber der Seriellen Console?
Ich benutz derzeit immer die Serielle Schnitstelle zur Kontrolle.

Sepp

Wenn du den C64emu in ein 1.5er Image einbauen willst nimmst du am besten als Basis hierfür die C64emu aus dem Image von der C64 Emu Homepage selber, weil dies ein älteres Image ist. Prinzipiell hab ich aber in allen Images, die den C64emu drinne haben immer nur die gleiche c64emu Binary gefunden.

Was kontrollierst du denn über die serielle Schnittstelle?
Dort kommen doch nur hauptsächlich die Bootloadermeldungen und ein paar Debugmeldungen, die die Devs in ihre Programme bzw. GUIs mit integriert haben. Der C64 Emulator selber macht da keine Ausgaben drüber.

Wenn du den Maintenance Modus startest und dich über Telnet in die Box einloggst kannst du z.B. den den c64emu manuell mit dem entsprechenden C64 Disketten Image und der passenden KBD Datei aufrufen. Jetzt gibts 2 Möglichkeiten:
1.) Emulator starte ohne Probleme -> alles Paletti
2.) Emulator startet nicht -> Telnet zeigt die Fehler im Linux System an (wie z.B. Library nicht gefunden)

Über diese Methode kannst du auch testweise verschiedene D64 Images und KBDs antesten, ohne jedesmal das LCD Menü darauf anpassen zu müssen.