|
|
Deutschstunde...
Wie schon einmal, dachte ich, ich mach mal wieder Nachrichten mit deutschem Bezug. ;-)
Ich berichte also nicht von der PineBook Pro Portierung, nicht von Geminus, nicht von SatNav, nicht von SMB v2 und v3, nicht von PrivateEye, nicht von Bonfire Bonanza,...
Das die GAG News im April 30 Jahre alt geworden ist, hatte ich Letztens schon geschrieben. Trotzdem noch einmal einen herzlichen Dank an Herbert.
Toni hat begonnen mit rNTFS einen NTFS-Lese-Tool zu bauen. Hier und da ein wenig hakelig, funktioniert es aber doch schon sehr gut.
Thomas hat EtherUSB um die CDC ECM Unterstützung erweitert. Das hat für mich den Vorteil, dass ich nun zwei LTE Geräte habe, mit denen ich unter RISC OS mobil ins Internet kann.
Der Cloverleave Filer ist inzwischen bei V 0.79-13 angekommen, was aber jetzt, wo ich es schreibe, sicher schon wieder veraltet ist ;-)
Dann missbrauche ich gleich noch meine Macht in eigener Sache ;-) VideoED macht Fortschritte. Hier (mp4) und da (mpg... nicht für Android) liegt ein Beispielfilmchen.
Ich muss mich selbst mal etwas unter Druck setzen. Das Rohmaterial für youtube "gammelt" schon eine Weile auf meiner Platte rum.
Wie schnell die Zeit vergeht... ;-)
|
|
Raik, geändert 11. 11. 2022, 06:30 Uhr |
|
|
Wenn man jetzt wüßte, was CDC ECM ist, könnte man das besser 'einordnen', was das Neue daran ist. Allerdings findet sich im gitlab da keine Änderung
( https://gitlab.riscosopen.org/RiscOS/Sources/Networking/Ethernet/EtherUSB )
d.h. es ist wohl eh nur experimentell.
Macht das EtherUSB eigentlich auch die Bedienung der Hardware auf dem RaspberryPi - oder ist das da "hardwarenah dabei". Ich habe zumindest noch nie irgendwas mit EtherUSB zu tun gehabt, werde aber mal demnächst schauen, ob das tatsächlich mitläuft.
NTFS Lesetool ist vermutlich was Spannendes für viele Leute. Bin auch immer mal ganz froh, daß man alte Platten mit solchen Tools ausgelesen bekommt.
Ansonsten: Danke für die Stichworte, wo man dann doch mal genauer nachsehen kann, zumindest was da neu ist: Pinebook Pro und Geminus klingen am Geheimnisvollsten.
| |
| naitsabes (12.11.22, 13:35.47) | |
|
Ansonsten, 30 Jahre GAG News sind wirklich eine laaaaange Zeit ! Und vor allem in der Form, wie sie wohl entsteht schon ganz erstaunlich, daß jemand da so lange und mit immer wieder viel Elan dabei ist. Glückwunsch zum Jubiläum !
| |
| naitsabes (12.11.22, 13:39.10) | |
|
EtherUSB läuft bei fast allen Pis bis einschließlich 3B+, beim BeagleXM, Panda, OMAP5... weil die alle einen Chipsatz von SMSC verbaut haben und der USBzuEther bietet... die SMSC unterstützung von EtherUSB war initial damals auch von Thomas fürs xM. CDC erschien auch bei den älteren EtherUSB bis 0.42 immer in der Liste der unterstüzten Chipsätze, eine Unterstützung war aber nie umgesetzt und ist deshalb Teil der Bountys bei ROOL. ECM ist ein Teil der CDC Umsetzung. SM-Art-Phones bieten bei USB Tethering auch CDC aber ndis. Das ist noch nicht unterstützt.
Thomas ist mit ROOL in Kontakt.
RNTFS bietet mir Zugriff auf mein Windows Backup Laufwerk und auf die Einzellaufwerke meiner NAS, wenn ich die ziehe und extern anschließe... :-))
Pinebook Pro teste ich kommende Woche, Geminus hat Herbert in der aktuellen GAG News ausführlich beäugt.
| |
| Raik (12.11.22, 14:56.20) | |
|
Ah, OK. Beagleboard habe ich (leider?) nie gehabt. Und beim Pi war dann irgendwie von vorneherein klar, daß das Netz anschließbar ist. Ansonsten werd ich wohl bei Gelegenheit mal nach CDC, ECM, Tethering und ndis googeln müssen. ;)
Geminus sieht beeindruckend aus auf den Videos, die es auf der sendiri Webseite zu sehen gibt. Das ist ja locker ein Faktor 5x beim Speedup. Vielleicht liegt es zu einem Teil ja aber auch bißchen daran, daß sich heut' niemand mehr die Mühe macht einen WimpUpdate Loop korrekt mit Screenteilen zu machen, sondern i.a. wohl doch das komplette Fenster zugemalt wird - egal ob sichtbar oder nicht. Aber, das allein reicht bestimmt nicht als Begründung für diesen Speedschub.
PinebookPro - spannend wäre ja vor allem mal die 4+2 Core Unterstützung ... :) da glaubt man aber nicht mehr so recht dran. Das Ding ist aber trotz allem auch so ein schickes kleines Notebook. Der Vorgänger war es auch schon.
| |
| naitsabes (13.11.22, 14:25.08) | |
|
Der weiße Vorgänger war ist etwas kleiner und mit Kunststoffgehäuse.
Das Pro ist etwas "wertiger" und größer. Mattschwarzes Alugehäuse, besseres Display und bessere Tastatur...
Etwas zwiegespalten... die Größe von dem Kleinen gefällt mir besser, in Summe macht das Pro aber mehr her.
Beide sind keine "Bastellösung" wie das PiTop.
| |
| Raik (15.11.22, 18:13.03) | |
|
Neues Jahr - neues Glück. Frohen Mut, Spaß und gute Gesundheit an Alle, die hier immer mal vorbeischauen, respektive das Ding am Laufen halten.
| |
| naitsabes (02.01.23, 16:18.13) | |
|
Ich verwende seit 2014 die Programme vom Alexander !POP3S und !SMTPS (mit Anpassungen von mir) auf dem Risc PC mit RISC OS 3.70 und darin wohl GnuTLS. Seit gestern aber bräuchte ich - wegen Update des Mailservers - eine neuere TLS Version.
Hat jemand Vorschläge für mich, was ich installieren könnte? Umsteigen auf? etc.
Alternativ nutze ich jetzt einen Workaround Server der noch das ältere TLS unterstützt.
| |
| Markus (17.01.23, 12:11.10) | |
|
Ok das hier könnte meine Lösung sein denke ich:
https://web.archive.org/web/20181110004908/http://home.chiemgau-net.de/ausserstorfer/Computer/index.html
| |
| Markus (17.01.23, 13:00.06) | |
|
Mist. Beide Versionen schmieren voll ab.
POP3S - E-Mail-fetcher with TLS for RISC OS
Developer Version 16. April 2016
GnuTLS version 2.12.23
mailserver4-mx.webflow.de
+OK Dovecot ready.
+OK Begin TLS negotiation now.
Fatal signal received: Illegal Instruction
Stack backtrace:
Running thread 0x148ee4 (Main Thread)
( 5e3f30) pc: 11d940 lr: 11ddec sp: 5e3f34 __write_backtrace()
( 5e3fa0) pc: 11da60 lr: f854c sp: 5e3fa4 __unixlib_raise_signal()
( 5e3fb0) pc: f8450 lr: a673c sp: 5e1b70 __h_cback()
Register dump at 005e3fb4:
a1: 15f310 a2: 15d558 a3: 0 a4: 1f0a466b
v1: 13a28c v2: 15f2f0 v3: 15f120 v4: 15f0b4
v5: e1d335c3 v6: 15f048 sl: 5e01f8 fp: 5e1b94
ip: ac891c9d sp: 5e1b70 lr: 800a673c pc: 600a55cc
Mode USR, flags set: nZCvif
000a55b8 : .0#à : e023300c : EOR R3,R3,R12
000a55bc : .0Àä : e4c03001 : STRB R3,[R0],#1
000a55c0 : . Râ : e2522001 : SUBS R2,R2,#1
000a55c4 : ùÿÿ. : 1afffff9 : BNE &000A55B0
000a55c8 : .ÿ/á : e12fff1e : BX R14
000a55cc : .0Ñä : e4d13001 : LDRB R3,[R1],#1
000a55d0 : .ÀÐå : e5d0c000 : LDRB R12,[R0,#0]
000a55d4 : .0#à : e023300c : EOR R3,R3,R12
000a55d8 : .0Àä : e4c03001 : STRB R3,[R0],#1
( 5e1b94) pc: a66c4 lr: ef228 sp: 5e1b98 nettle_hmac_set_key()
( 5e1bac) pc: 950fc lr: 80008 sp: 5e1bb0 nettle_hmac_sha256_set_key()
( 5e1bbc) pc: 7ffe4 lr: 1c94c sp: 5e1bc0 wrap_nettle_hmac_setkey()
( 5e1be4) pc: 1c844 lr: 332b0 sp: 5e1be8 _gnutls_hmac_init()
( 5e1d70) pc: 3317c lr: 34644 sp: 5e1d74 _gnutls_P_hash.part.0()
( 5e23b4) pc: 34384 lr: 10658c sp: 5e23b8 _gnutls_PRF()
( 5e2634) pc: 19318 lr: 195a4 sp: 5e2638 generate_normal_master()
( 5e2644) pc: 19584 lr: 29180 sp: 5e2648 _gnutls_generate_master()
( 5e2658) pc: 29170 lr: 103a4 sp: 5e265c _gnutls_connection_state_init()
( 5e2690) pc: 10178 lr: 13e50 sp: 5e2694 _gnutls_send_handshake_final()
( 5e26a8) pc: 13e20 lr: 15894 sp: 5e26ac _gnutls_handshake_common()
( 5e26c8) pc: 1583c lr: 8e34 sp: 5e26cc gnutls_handshake()
( 5e2fec) pc: 8ae8 lr: 106064 sp: 5e2ff0 main()
| |
| Markus (18.01.23, 15:25.16) | |
|
Das etwas, nur weil eine Instruction nicht erkannt, gleich so rabiat "abschmiert", ist aber auch nicht nett.
Frag ihn doch mal direkt an, ob er Dir was baut, was als Binary mit der neuesten TLS Version läuft.
Langfristig wäre es aber wahrscheinlich eh gut, mal die Maschine zu wechseln und zu schaune, ob es da nicht unter RISCOS5 was passendes zum Thema gibt. Alternativ kann man noch einen kleinen FreeBSD Mailserver VOR den RiscPC hängen. Der hat dann wenigstens den ganzen Security Teil in "modern" an Board und kann mit dem RiscPC dann auf normale, herkömmlich Art Mails tauschen.
Das Problem wird ja immer wieder auftauchen. Und richtig spannend wird es, wenn das mal so komplex wird, daß es am RiscPC gar nicht mehr läuft oder gar übersetzbar ist (Stichwort Phyton oder so).
| |
| naitsabes (18.01.23, 16:07.38) | |
|
Ok dürfte der 32 Bit Compilierung geschuldet sein. Bräuchte ich halt für den "ollen" Risc PC. Kann das wer beantworten ob sich das für/auf dem Risc PC comilieren läßt?
| |
| Markus (18.01.23, 16:13.50) | |
|
Na ja die Lösungen sehen so aus:
- Raspberry PI mit RISC OS einrichten und voll umziehen
(brauche da aber zwingend den 26 Bit Mode für die alten Progs mit denen ich arbeite)
- anderes Betriebssystem zum Abholen und Versenden der Rohdaten einrichten
(Rohdaten gehen dann an !Marcel und kommen von !Marcel das weiterhin auf dem Risc PC bleibt)
- den Workaround eines Mailservers mit altem TLS dediziert für mich weiter laufen lassen
| |
| Markus (18.01.23, 16:24.33) | |
|
32Bit Code ist keine Schande ...
Soweit ich das in Erinnerung habe, compiliert die DDE die Programme so, daß sie sowohl unter 32Bit, wie auch unter 26 Bit laufen. WIe das bei dem GCC aussieht, weiß ich nicht. Wenn Assembler angepaßt wird, ist das vom Anpassenden abhängig.
| |
| Thomas Milius (18.01.23, 18:07.25) | |
|
...ist natürlich keine Schande.
Habe von !Squirrel (Datenbank) keine Sourcen und das ist zusammen mit !Marcel (E-Mail-Client) meine zentrale Hauptanwendung.
| |
| Markus (18.01.23, 19:22.38) | |
|
Ja ich verstehe jetzt erst. Du hast Dich direkt auf das !POP3S bezogen. Das ist mit dem GCC gemacht. Sourcen und Infos hat Alexander ja dabei im ZIP. Nur hab ich da so gar nix am Dampfen und müßte ganz von vorne beginnen. Zumal habe ich "nur" RISC OS ROM Version 3.70 mit sehr viel nachgeladenen Neuerungen.
| |
| Markus (18.01.23, 19:39.33) | |
|
Aha, da könnte ich doch vielleicht Hermes im Paket von NetFetch kaufen und das an !Marcel andocken.
https://www.rcomp.co.uk/r-comp/dialup/netf.html
| |
| Markus (19.01.23, 09:36.56) | |
|
Entschuldigung, bin etwas hinterher.
Ich hatte das Zeug von Alex vor einiger Zeit neu kompiliert und ich meine mit DDE, nicht mit GCC (nutze ich nicht). Bin aber gerade nicht sicher. Ich schau mal auf dem Emu. Ich meine ich hatte das mit den 4.39 ROMs laufen.
| |
| Raik (19.01.23, 09:46.50) | |
|
Hallo Raik,
das ließe sich doch einfach probieren.
pulse klammeraffe elmulab de
| |
| Markus (19.01.23, 11:41.30) | |
|
Auf meinem Dienstrechner habe ich nichts mehr. Ich suche mir das zu Hause noch einmal raus.
Schaffe ich aber heute nicht mehr.
| |
| Raik (19.01.23, 13:48.32) | |
|
Bei mir läuft aktuelles Hermes/Netfetch und neueres TLS tut (mit Telekom) . Der Verbindungsaufbau dauert dann rund 10 Sekunden auf dem Titanium.
| |
| Toni (21.01.23, 05:32.36) | |
|
Nun habe ich !Hermes aber so einfach ist das leider nicht zur Funktion zu bewegen. Das liegt nicht unbedingt an !Hermes sondern an dem benötigten Drumherum.
Bei mir läuft autarkt die Ant Internet Suite. !Hermes benützt AcornSSL. Das wiederrum braucht Infrastruktur. Und da weiß ich nicht was alles. Ich habe alle Module und alle Speicherorte also Pfade mit den Inhalten bereit gestellt. Aber da es 0,0 Konfiguration des RISC OS Internet Systems gibt könnte das die Hürde sein.
Letztlich ist es mir egal, ich kann die Ant Inet Suite verlassen. Aber wie bekomme ich den RISC OS Internet Kram auf RISC OS 3.7 ans Rennen? Was sind die rudimentärsten Dinge die laufen müssen?
| |
| Markus (21.01.23, 19:30.50) | |
|
Ich habe meine Kram durchsucht aber leider nicht das gefunden, was ich gehofft habe zu finden. Bin etwas verwirrt. Die Versionen die ich habe laufen auf dem Pi3+ und auf dem Pi4. Das was ich meinte, dass es auf dem RiscPC läuft tut nicht. Ich finde auch die Sorces nicht mehr aus denen ich kompiliert habe. Sehr seltsam das.
Ich habe auf dem Emu 3.71 drehen, mit Internet. Hermes kann man auch über die Kommandozeile nutzen, das habe ich schon getan. Ich könnte ein paar Dinge probieren, nur schnell bin ich aktuell nicht.
| |
| Raik (22.01.23, 13:14.57) | |
|
Diese Tage fällt mir auf, daß von
https://www.freelists.org/list/archimedes
gar nix mehr kommt.
Insgesamt stelle ich mir die Frage, wo ist es denn nun am besten die wenigen RISC OS "Narren" noch zu erreichen?
Ist https://forum.acorn.de/ "aktiver"?
Die Fragen resultieren daraus, weil ich erst gestern das https://forum.classic-computing.de/forum/index.php?board/114-acorn/ bemerkt habe.
Ich repariere Akku und Batterieschäden von Platinen. Weniger SMD, aber auch da geht was. Aber insbesondere habe ich auch alte Acorn VLSI ICs in Stangen hier, eine Menge Podules, Risc PC Gehäuseteile bzw. Risc PCs zumeist mit Akkuschaden versteht sich. Und da hätte ich eventuell dem ein oder anderen schon helfen können und wollen. Insofern schade, daß ich da erst jetzt drüber stolpere. Alles natürlich wegen meiner eigenen Miesere, einen neuen Acorn Internet Stack bzw. das AcornSSL Module auf einem Risc PC ohne Bootsequenz zum Laufen zu bekomen.
Ich habe diese Tage viel überlegt, weil es so Aussagen gibt, die in etwa lauten, man solle sich gefälligst mal neue Hardware anschaffen und nicht auf dem alten Kram mit selbstgekochtem Graffel rumackern.
Ich habe nix gegen den sportlichen Flitzer. Aber ich habe nun mal seit bald 30 Jahren meinen Milchlaster, mit dem ich Milch ausfahre. Dafür ist der speziell eingerichtet und ausgestattet. Nur weil der Sprit sich ändert, muss ich halt meinen Motor anpassen, der Milchlaster als solches ist nämlich unverzichtbar für meine Arbeit. Auf der Suche wie ich den alten Motor an den neuen Sprit anpasse, dann zu lesen man solle sich mal überlegen einen neuen Flitzer anzuschaffen finde ich in vielerlei Hinsicht doof.
Ich werde nun folgendes machen, die Raspberry Pi's, von denen ich längst mehrere hier habe, nerven mich ein wenig in der Handhabung. Ich kaufe einen Raspberry Pi 400, starte dort RISC OS und Hermes und habe dann mehrere Möglichkeiten die ich wahrscheinlich parellel mache. Ich baue das neue System zum Milchlaster um (das ist echt viel zu tun!) und ich nehme ebenso das neue System als funktionierende Vorlage, um das auf meinem Risc PC mit 3.7 - ohne original !Boot Struktur - zum Laufen zu bekommen.
| |
| Markus Huber (22.01.23, 15:07.28) | |
|
Na ja, die RISCOS Aktivität hat sich mittlerweile ziemlich komplett ins (englischsprachige) ROOL Forum verschoben. https://www.riscosopen.org/forum/
Dort passiert noch was, und auch den alten Acorn Usenet Gruppen, sind noch ein paar Mitleser. Das deutsche Acorn Forum habe ich immer mal probiert mit Neuigkeiten oder interssanten ARM nahen Sachen "zu bespielen", da kommt aber relativ wenig Rückmeldung. Manchmal könnte man denken der P. ist der einzige und manchmal kommen noch ein paar externe Anfragen, meist von Leuten, die kleinere Problemchen mit dem Rechner haben, und die dann aber vmtl woanders gelöst bekommen und nie wieder dort auftauchen.
Das Classic-Computing Forum ist so eine Sache für sich ... Da ist zum einen die Acorn Abteilung sowieso recht "still" und das Hauptaugenmerk liegt eh mittlerweile bißchen auf Labern (Lustige Bilder, Ebay Auktionen, Preise) und dann v.a. viel auf Commodore PET und Co. Es ist über alles deutlich mehr 8Bit dort zu finden. Auch Amiga ist sehr schlecht repräsentiert. Und: Die meisten da sind auch eher nicht unbedingt Leute, die noch was mit den Rechner machen wollen - die meisten sind eher Sammler und Leute die in Erinnerungen schwelgen und gern mal was altes aufbauen und für ein Wochenende sich treffen. Daneben gibt es ein paar kleine, aber sehr feine, Computerbasteleien (C64 SPS, Modellbahnsteuerung, Junior Computer II usf.). Ich wäre mir nicht sicher, ob Du z.B. Deine Sachen dort wirklich "gut" loswerden würdest, oder ob sie nicht einfach bei einem "Horter" landen, oder gar bei einem reinem Wiederverkäufer, der sie dann zum Faktor x5 beim Ebay einstellt. Ausnahmen bestätigen natürlich die Regel. Komplette Acorns sind dort natürlich aber sicherlich gut zu verkaufen, zumal wenn sie intakt sind und/oder repariert. Als Sammler sind viele Leute dort auch bereit für seltenes Gerät gut zu zahlen. Dann aber sicherlich am Besten in Originalverpackung und mit Handbüchern etc.
Podules und ICs kannst Du sicherlich auch hier mal anbieten, oder in der - freelist Archimedes Mailliste.
Am Besten wären die ICs natürlich bei jemandem aufgehoben, der noch aktiv im deutschen Bereich (oder zumindest einfach erreichbaren) tatsächlich Reparaturen solcher Geräte macht. Ich wüßte aber nicht, wer das sein sollte ...
Zum eMail Thema. Wenn Du eh Raspberries hast, warum willst Du dann einen 400er holen ?. Am Ende scheitert der für den Alltagsgebrauch doch schonmal am Keyboard, was vermutlich nicht so sonderlich viel taugt (rein der Optik nach, hab es noch nie probieren können). Und der Massenspeicher ist auch da prmär eine unzuverlässige SD-Card.
Setz doch einfach erstmal eine reine Bastelvariante mit einem RPi, der da ist, und einem aktuellen 5er RISCOS (5.28?) auf und schau mal wie weit Du dort mit dem Thema eMail Abrufen etc. kommst. Wenn das vernünfitg hinzubekommen ist, weißt Du doch schonmal in welche Richtung das geht.
Eine Alternative dazu wäre das Gleiche - also mal eine neue Platte neu aufsetzen mit komplett neuem OS - auf dem RiscPC zu machen. Sollte das schön laufen kann man doch nachträglich da die alte Platte wieder reinhängen und Stück für Stück die Software umziehen.
Ich würde ja vmtl. - wenn ich unbedingt den RiscPC weiterbenutzen wollen würde - einen Mailserver davor setzen, der dann eben die eMail Sachen immer auf dem aktuellen Level kann. Da spart man sich das "Gezerre". Für sowas taugt z.B. ein SiemensFujitsu Futro MinPC (S200 o.ä.). Ein Pi würde es sicher auch tun. Das hätte den Charme, daß man RiscPC gar nicht anfassen muß - aber man braucht natürlich bißchen Zeit, um sich mal einzulesen, wie man einen "Proxy" aufsetzt.
Ich habe sowas ähnliches mal eine Zeit lang benutzt. War ein RPi mit 5.24 und dazu ein großer Server mit 4 großen, schnellen Platten und DualProzessor (jeweils 2-Core). War auf dieser Seite bißchen overkill, und er hat auch primär für den RPi nur NAS gespielt, aber mit so einer Sache hast Du quasi die Vorteile beider Welten. (man muß aber dazu sagen, daß ich den Server auch eher als Rechner von einer LinuxBox aus benutzt habe; da hat man dann auch die Rechenpower von dem Ding auf dem Desktop gehabt (mit der Einschränkung, daß BitmapGrafik langsam wird, weil übers Netz)). Fand das aber eine schöne und durchaus überzeugende Kombination (Dateien über NFS mit !Sunfish/!Moonfish). Sowas läßt sich bestimmt auch mit einem RPi und einem MacMini o.ä. aufbauen. Da wirds dann noch im "userfreundlich" und man kann wahrscheinlich den zusätzlichen Mailserver einfach per Klick anschalten. Mit einem Mini M1 ist es dann auch noch schnell (und ARM basiert ;) )- und mit einem alten DualCore Mini wird es günstiger (die älteren kosten mittlerweile teils so um 50EUR) - man hat also die Wahl, bei ziemlich gleicher Optik und Formfaktor.
| |
| naitsabes (22.01.23, 17:16.59) | |
|
https://denkrobat.de/doku.php?id=mailserver_einrichten
https://www.davd.io/posts/2021-12-18-freebsd-mail-server-part-1/
Guck mal da. V.a. das erste. Damit lassen sich dann auch die Mails sogar per POP abholen, wenn man das mag (!Tapir Mail).
Ist jetzt nicht hyperkomplex - und es gibt auch noch jede Menge andere Anleitungen dafür.
| |
| naitsabes (22.01.23, 18:01.47) | |
|
Na ja zum Raspberry PI brauche ich halt noch mehr drumherum wie viele Kabel, Netzteile, Festplatte, Tastatur und das müßte ich erst mühsam zusammentragen.
Ich muss eh erst mal einen Monitor anschaffen. Ich habe hier fast 10 gute Monitore aber absichtlich nur die mit 1600 x 1200 Auflösungen. Ich habe keine USB Tastatur (oder wenn dann unsäglichen Mist mit zusätzlichen Tastenspielereien - so was hasse ich), weil wenn ich einen PC aufsetze (4 habe ich am Laufen) beschaffe ich die Erweiterungen um die vielen hervorragenden PS/2 Tastaturen die ich hier habe zu nutzen. Aus den PS/2 Tastaturen entferne ich die Windows-Tasten und schlachte dazu aus anderen identischen Tastaturen blinde/flache Abdeckungen.
Ich brauchte neulich eine weitere Funktastatur mit eingebauter Maus um eine PC Software ohne Kabel im Stehen ohne Tisch! bedienen zu können. Ich glaube ich habe bestimmt 2 Wochen recherchiert bis ich was passendes gefunden habe. Früher vor 15 Jahren war so was noch einfach zu bekommen. Ich wurde bei einem Autozubehörhändler fündig der noch kleine Funktastaturen fürs Auto hat. Nun muss ich aber schauen wie ich Bluetooth an dem PC aktivieren kann um darüber die Tastatur laufen zu lassen. Wird hoffentlich mit einem Bluetooth USB Stick funktionieren.
Lange Rede kurzer Sinn, ich dachte halt mit dem 400er den Kabelverhau und den Beschaffungswahnsinn etwas zu mildern. Zumal ich nicht vorhabe den 400er dauerhaft einzusetzen. Wenn ich später tatsächlich RISC OS auf dem Raspberry PI nutze, so würde ich den Raspberry PI in den Monitor einbauen bzw. zumindst dahinter andocken und dessen Netzteil anzapfen.
| |
| Markus (22.01.23, 18:22.25) | |
|
Danke. Das ist theoretisch schon richtig aber in der Praxis erst mal die Hardware dafür bereit stellen (kaufen) und dann das FreeBSD einrichten und daruf dann noch mal den mailserver zu installieren das überfordert mich mindestens zeitlich.
| |
| Markus (22.01.23, 18:32.10) | |
|
Ich habe den ganze Kram nun wieder beisammen inkl. ANT und versuche mal unter 3.71. Wenn GCC dort tut...
Hermes/Hermetic kann AcornSSL nur in relativ aktueller Version. Davor hat Andrew immer noch SecureD "mitgeschleppt".
Ich hatte Marcel unter Aemulor laufen. Ging aber nur empfangend.
Schauen wir mal.
| |
| Raik (23.01.23, 05:58.07) | |
|
Auch wenn ich hier nichts schreibe sollte, ich arbeite sozusagen akut weiter an der Problemlösung.
Nach reiflich Überlegung und Recherche wird es wie ich geschrieben habe, ein RPI 400. Die Vorteile in der Praxis finde ich enorm.
Könnte den PPI 400 auch nach Hause mitnehmen aber da habe ich nur WLAN. Gibt's da nen funktionierenden Adapter?
| |
| Markus (23.01.23, 08:06.03) | |
|
Im ersten Step habe ich MPro9 + AcornSSL unter RPCEmu mit 3.71 und 4.39 am laufen. Das scheint erst einmal zu funktionieren. Etwas langsam aber tut.
| |
| Raik (23.01.23, 08:08.54) | |
|
WLAN: Beim RPI 400 fällt Elesars Pi-Hat für WLAN wohl weg. Unter USB wüßte ich z.Z. keinen Adapater. Es gab mal ältere Modelle die evt. mit meiner neuen EtherUSB Version laufen könnten. Was gehen sollte, sind Ethernet/WLAN Adapter. Ich habe so ein Ding von Netgear. Ob der WLAN Empfang ausreichend ist, muß man sehen.
| |
| Thomas Milius (23.01.23, 19:39.26) | |
|
Pi400 geht schon mit Wifi Hat. Hochkant passt ... http://riscos.openpandora.org/Diverses/Pi400/P400_WiFi.JPG oder mit entsprechendem Hat-Expander z.B. von Pimeroni...
| |
| Raik (23.01.23, 19:58.54) | |
|
Meine Lösung WLAN mit dem Raspberry PI 400 ist aufgrund meiner Rahmenbedingungen anders geworden. WLANs Aufgabe bei mir ist ja nicht um in mein WLAN zu kommen, sondern um ins Internet zu kommen. Da ich einen 60 GByte Vertrag habe und eh immer das Smartphone dabei ist, gibt's für 15 Euro ein USB-C stellt Ethernet bereit Adapter. Das mach ich, wenn ich nicht in der Werkstatt bin. In der Werkstatt gibt es den Router unterm Tisch mit Ethernet Kabel für den 400er. Und da muss ich auch ins lokale Netz wegen der NAS und vermutlich auch um die Drucker zu erreichen.
| |
| Markus (23.01.23, 22:13.49) | |
|
Da hängt dann der USB-C auf Ethernet am Adapter am Smartphone - und das liefert dann das Ethernet für den RPi400, der per Kabel an dem Smartphone angeschlossen ist - habe ich richtig so verstanden ??
Klingt nach einer ziemlich modernen und irgendwie auch coolen (weil u.a. extrem portablen) Lösung. (ein Monitor findet sich ja mittlerweile fast überall; RISCOS-2-GO sozusagen)
Das der Pi-Hat aus dem Bild schön funktioniert, ist wirklich hübsch. Allerdings optisch macht das so gar nichts her. Mit einem 90Grad Winkeladapter und einem selbstgedruckten (3D Druck) Plastikgehäuse in der Farbgebung weiß-himbeerrosa wie der RPi400 könnte es aber evtl. sogar ein echtes Produkt werden, was auch Leute "anflanschen" würden. Muß nur eben dann nach hinten "längs" rausgehen, nicht hochkant - das macht doch die ganze Geäteoptik kaputt.
So was in der Art hätte mir auch als "Lösung" vorgeschwebt, weil ja mittlerweile dieser ESP32xx Chip so verbreitet ist, daß es da bestimmt auch schon direkt benutzbare Bastellösungen auf github etc. gibt, die man auch nutzen könnte. Daß es das schon als Fix-und-Fertig-Lösung zu kaufen gibt, die auch noch anscheinend direkt funktioniert - umso besser.
Der Chip klingt auch ganz interessant
https://www.microchip.com/en-us/product/ATWILC1000
https://ww1.microchip.com/downloads/en/DeviceDoc/ATWILC1000-MR110XB-IEEE-802.11-b-g-n-Link-Controller-Module-DS70005326E.pdf
Ich frage mich nur gerade, ob da gemeint war, daß der Adapter "rein prinzipiell" und unter Linux an dem RPi400 läuft, oder ob das tatsächlich auch unter RISCOS klappt. Irgendwie braucht es da ja doch auch eine "Ansteuersoftware", die man vmtl auch nicht in BASIC schreiben kann(?).
| |
| naitsabes (24.01.23, 16:25.05) | |
|
PS: ganz anderes Thema. Der P.M. vom forum (forum.acorn.de) überlegt, ob er nicht demnächst mal den FTP Zugang umstellt auf ein HTML Webinterface. Wäre schön, wenn sich das mal ein paar Leute im Hinblick auf Benutzbarkeit ansehen könnte (evtl. auch mit "altem Gerät") und auch mal einen Kommentar(!!) dort dalassen, damit er weiß, was minimal noch vorhanden sein muß und was noch nicht so "flutscht". Adresse ist dort im Thread direkt verlinkt, Zugangsdaten finden sich auf Seite 1. Gewissermaßen als Belohnung fürs Antworten gibt es, neu, die gesammelten Werke von einer wiedergefundenen Fetplatte mit allerlei hübschen Sachen. V.a. natürlich PD und Freeware und Demos. Aber auch bißchen Sounds, B+H Disks etc. Alles "old-school" und vieles läuft natürlich, wenn überhaupt, nur noch mit Emulation oder Kompatibilitätslayer auf modernem RISCOS. Hamsters+ etwa ...
Riskiert doch mal einen Blick, wenns mal zeitlich gut paßt.
| |
| naitsabes (24.01.23, 16:37.05) | |
|
RISC OS-2-GO muss ich gleich zweimal lesen, weil mir damit zuerst RISC OS 2 in den Sinn kommt.
Smartphone mit USB-C und Sim-Karte für LTE und reichlich GB Vertrag.
Daran mit kurzem Kabel der Adapter der eine Ethernet Buchse bereit stellt. Und da mit kurzem Ethernet Kabel der RPi400 angeschlossen.
Dazu kaufte ich noch einen portablen Monitor. Immer noch 4 Kabel am RPi400. Ich versuche dünne, bewegliche Kabel zu beschaffen.
Zustimmung zu den Ausführungen zum Pi-Hat. In der Art eine blanke Platine anstecken, um eine dauerhaft genutzte Funktion zu erhalten, zerstört ja alles was einen schicken RPi400 auszeichnet.
| |
| Markus (24.01.23, 21:06.53) | |
|
Na "zerstört ja alles" ... würde ich mal so nicht sagen, es sieht halt seltsam aus. Aber ich glaube den "Herrn Seitenbetreiber" stört sowas sowieso nicht sonderlich. Da ist wohl einfach wichtiger, daß es geht - und das klang ja so, als würde es.
Habe das Kärtchen aber gestern nicht mehr woanders gefunden, dabei sieht es schon nach "Produkt" aus und nicht wie "selbstgefädelt".
RISCOS-2 ... da habe ich gar nicht dran gedacht, aber stimmt: mit dem Hinweis ist das schonmal kein guter Name. Da müßte es dann evtl. besser RISCOS-for-Forerunner oder vielleicht auch RISCOS-for-Runaways heißen. Auf alle Fälle finde ich mal die Lösung mit dem Handy sehr schick. Wird wohl auch die Zukunft der Netzanbindung werden - nachdem nun in den letzten beiden Jahren überall Glasfaser vergraben worden ist und man bereits jetzt feststellt, daß die Leute das gar nicht haben wollen / Verträge abschließen, weil sie - eben - das schnelle Netz eher am "Phone" brauchen.
Gibt es evtl. Unterstützung von RISCOS Seite für solche USB-Ethernaet Adapter ? Die sehen ja aus, als würde man die ziemlich hardwareunabhängig (USB) anbinden können, und daher sollte es eigentlich im Rahmen des Möglichen sein, da Software dafür zu bauen, die das ermöglicht. Denn wahrscheinlich gibt es solche "Kabelchen" dann ja auch beretis jetzt schon direkt mit WLAN. Und langsamer als die RPi Netzbuchse würde es wohl auch nicht, da die ja letztlich genauso angebunden ist.
Der Mann, der bei ROOL in der Entwicklungsabteilung die Fäden in der Hand hält, hat zumindest vor paar Tagen in einem Interview mal angedeutet, daß man langfristig sowieso mal am Netzwerkstack diesbezüglich (WLAN) was tun will. Da würde das ja dann schön dazu passen (und benutzbar wäre es - mit den üblichen Quirks - schon vorher).
| |
| naitsabes (25.01.23, 15:43.52) | |
|
Da
https://www.theregister.com/2023/01/17/retro_tech_week_rool
noch der Link zum Interview mit Steve Revill.
| |
| naitsabes (25.01.23, 15:45.50) | |
|
Habs mittlerweile auch gefunden (richtige Stichwörter machen sowas deutlich schneller)
https://www.riscository.com/2019/elesar-pi-hat-wifi-solution/
https://www.iconbar.com/articles/Elesar_bring_Wifi_networking_to_your_RISC_OS_Pi/index1498.html
http://shop.elesar.co.uk/index.php?route=product/product&path=20_46&product_id=83
| |
| naitsabes (25.01.23, 15:52.45) | |
|
Der "Seitenbetreiber" nutzt das HAT natürlich nicht am Pi400. Da ging es wirklich nur ums gehen ;-)
Meine werkeln im PiTopV1 mit Pi4 und PiTopV2 mit Pi3B+ und sind im Gehäuse versteckt.
@Markus
Hast Du meine Mail gesehen und die Anhänge probiert? Ich habe leider keine richtige Hardware auf der ich sofort probieren könnte. Mein Risc PC ist weit weg von Netzwerk.
| |
| Raik (25.01.23, 17:47.43) | |
|
Das Interview mit Steve Revill habe ich gestern Abend angehört. Fand ich überraschend interessant.
Ich las dann auf The Register noch etwas mehr und wer https://www.theregister.com/2022/06/23/how_risc_os_happened/ als RISC OS Nerd nicht kennt, dem möchte ich es empfehlen.
Ich habe den Anspruch an die für mich neue Raspberry Pi 400 Nutzung, daß es einfach (z.B. im Sinne von möglichst wenig Adapter, Kabel, Netzteile...), komfortabel (am besten nur ein Multifunktionales Steckernetzteil, wenig Platzbedarf...), robust (keine fetten Stecker in klobige Adapter oder gar offene Platinen...) und sehr funktional (Ethernetkabel in der Firma um die NAS und die Netzwerkdrucker zu erreichen, WLAN zu Hause, LTE Unterwegs) ist.
Inzwischen bezweifle ich stark, daß diese USB-C liefert Ethernet funktioniert. Ich denke das ist gedacht für flache Geräte die keine Ethernet-Buchse haben. Bestellt habe ich es trotzdem, weil es nur ~12 Euro kostet. Mal testen.
Optisch passend und bestimmt funktionierend ist das hier aber nicht mehr LTE sondern WLAN Anbindung:
https://www.google.de/search?q=VONETS+VAR11N-300
Wahrscheinlich besser aber wäre so ein Teil https://www.amazon.de/dp/B00634PLTW/ welches dann zwei Aufgaben in einem leistet. 1. WLAN nach Ethernet und 2. mit 3G/4G Modem Stick direkt online.
Lernen mußte ich heute, daß es drei HDMI Steckerformate gibt. Der Raspberry Pi hat nun alle Formate durch. Denn die ersten haben eine "normale" HDMI Buchse, der Zero hat Mini-HDMI und der RPi400 Micro-HDMI. Und so ein schicker portabler Monitor hat üblicherweise Mini-HDMI. Nun braucht es ein teures, weil exotischeres Kabel: Micro-HDMI an Mini-HDMI. Leider gibts da nicht viel Auswahl.
| |
| Markus (25.01.23, 17:55.50) | |
|
Hallo Raik, ich habe auf die erste Deiner beiden E-Mails mit einer E-Mail geantwortet. Schicke ich gleich noch mal. Schau mal in den Spam ob ich da drin stecke.
| |
| Markus (25.01.23, 17:58.04) | |
|
@Markus
Im Spam ist nix, das "nochmal" ist angekommen.
Ich antworte mal hier. Vielleicht hat jemand eine Idee.
Inzwischen habe ich festgestellt...
POP3S mit der 2'er GNUTLS Version funktioniert auf keiner meiner Möglichkeiten.
POP3S mit der 3'er GNUTLS Version kompiliert am Pi oder Ti funktioniert an allen "neuen" Boards mindestens vom xM aufwärts aber nicht mit RPCEmu.
Gleiche Version unter RPCEmu mit 4.39 kompiliert tut nirgendwo.
Der Versuch unter 3.71 zu kompilieren schlug fehl mit sowas wie "Buildstring to long".
Ideen gern genommen.
HDMI... richtig, teilweise sinnfrei aber vermutlich der benötigten Baugröße geschuldet.
Ich habe diverse Adapter-Stecker in fast allen Kombinationen. Die kosten nicht viel und ich kann dann ein normales HDMI Kabel verwenden.
Auch eine Möglichkeit sind Flachbandkabel mit geklippten Steckern (gibt es im Modellbauladen für Drohnen bzw. deren Kameras).
Leider funktionieren die mobilen Dingens nicht alle unter RISC OS. Ob EtherUSB mit Deinem Link umgehen kann, wäre noch zu prüfen.
| |
| Raik (26.01.23, 07:53.26) | |
|
Vergesst meinen letzten Absatz. Der ist Unsinn. Hab nicht richtig hingesehen.
| |
| Raik (26.01.23, 08:37.52) | |
|
"Buildstring to long" klingt irgendwie, als hätte jemand alle -l Libs Commandos direkt an das cc (oder gcc oder ...) drangehängt und versucht das so zu übergebn. Wenn man rausbekommt, was das zum Anfahren des Compilers zu zusammengstückelt worden ist und als String dann vielleicht auch generell ziemlich lang ist, dann kann man da ja evtl einfach ein Makefile basteln und dann sollte es loslaufen. Sowas passiert z.B., wenn jemand da volle Pfade automatisch einträgt.
Ich finde ja schonmal die Info, daß das prinzipiell auf allem Neueren läuft (POP3S + 3 GNUTLS auf Pi und Ti und xM), ist doch gar nicht so schlecht. Das ist doch vmtl schon der halbe Umzug zum RPi400. Damit sollte Mail ja schonmal prinzipiell machbar sein.
| |
| naitsabes (26.01.23, 21:39.22) | |
|
Der "Einzeiler". Tut unter 4.39 und höher aber nicht unter 3.71
gcc -O3 -static POP3S16April2016.c -o!RunImagePOP3S -ILibGNUTLS: -LLibGMP: -lgmp -LLibGNUTLS: -lgnutls -LLibGPGError: -lgpg-error -LLibNettle: -lhogweed -lnettle -LLibTASN1: -ltasn1 -LZlib1g: -lz -LLibGetText: -lintl
elf2aif !RunImagePOP3S
| |
| Raik (26.01.23, 22:28.24) | |
|
Die ersten Sachen sind eingetroffen.
Was für Stümper am Design des Raspberry Pi 400 gearbeitet haben?
Oder waren das alles Linkshänder? Denn der einfache USB-Anschluss für die Maus ist sehr weit links außen und vergeudet somit unnötig viel Mauskabel.
Keinerlei Beschriftung am Gehäuse welche Funktion welche Buchse hat. HDMI 1 und 2 oder A und B... Nichts dergleichen! USB Beschriftung welcher USB Standard an welcher Buchse geboten wird. Nichts.
Immerhin positiv, die Tastatur hat volle Standardgröße. Keine Umgewöhnung was den Tastenabstand betrifft.
Hat jemand schon Erfahrung eine alte 3-Tasten-Maus ohne Scrollrad aber mit echter Kugel anzuschließen? PS/2 Maus am besten. Die braucht man sonst eh zu nix. Die optischen Mäuse haben sehr viele Untergrundprobleme.
| |
| Markus (27.01.23, 13:46.56) | |
|
Stolpere eben über meinen Fehlkauf 1TB Festplatte HDD für den RPi400 mit RISC OS scheint nicht nutzbar zu sein. Bisher war 128 GB HDD mit dem Risc PC meine Grenze, die ich aber mit LanFS und dem 2 TB NAS nichtig mache. So ist diese Kapazität von einem Drive fürs RISC OS ken Problem.
Nun ist booten von SD Card angesagt (CMOS RAM) und erst !Boot dann von USB. Ich entschied mich für HDD. Und es soll nur ein Laufwerk angeschlossen sein, damit !Boot sicher gefunden wird. Was aber ist dann das nutzbare Limit? 256 GB?
Partitionen möglich? Praktikabel oder nur gemurkst? Dann kaufe ich eine HDD die nur die max. nutzbare Kapazität hat.
| |
| Markus (27.01.23, 21:30.44) | |
|
Ok ADFS max 256 GB spotbillig als USB HDD kommt an den RPi400.
| |
| Markus (27.01.23, 21:51.32) | |
|
Für USB-nach-PS/2 gibt es zumindest Bastellösungen, wo Leute solche Adapter gabaut haben bzw. das vorhaben. Und andersherum gibt es das auch - z.B. USB Keyboard an C64 Matrixanschluß. z.B.
https://bitbucket.org/100prozent/universalkeyboardadapter/src/master/
Nützt Dir aber nix. Wenn Deine PS/2 Maus erkannt wird, könnte evtl sowas da passen
https://www.ebay.de/itm/190867434123
Es gab das auch mal in bißchen "dicker" von Fuji als Produktnummer S26391-F5100-V100 . Das funktioniert zumindest am PC gut. Am RPi hatte ich es noch nicht dran, da es aber aktiv umsetzt (Chip), sollte es eigtlich passen. Keine Ahnung, ob man die noch irgendwo bekommt. Electromyne ist ein Händler in der Nähe von Leipzig, der immer mal total alten "Stuff" noch hat.
Zur HDD. Wie wäre es mit einem USB Stick zum Booten - wenn das NAS sowieso dran hängt ? Eigentlich will man doch nur das Schreiben auf die SD-Card aushebeln. Und wenn das NAS dann per NFS läuft, ist doch eh klar, was benutzt wird.
Limits würde ich bei ROOL mal zum Thema !HDForm suchen, das ist da ja immer mal überarbeitet worden. Verläßlich findet man diese Info wahrscheinlich eh nirgendwo anders - es sein denn jemand hier weiß sie sicher.
| |
| naitsabes (27.01.23, 22:24.58) | |
|
Ich nutze am Ti u.a. eine 1TB SSD die als erste Partition 256 GB FileCore und als Rest FAT32 formatiert ist (mit Antons PartiFC). Beides unter RISC OS sehr gut nutzbar.
Da ich mit SD Karten auf Dauer nicht die besten Erfahrungen gemacht habe, boote ich auf dem xM nur ROM und CMOS von einer FAT32 formatierten kleinen SD. Der Rest inkl. !Boot befindet sich auf einer 256GB SSD in FileCore..
| |
| Raik (27.01.23, 22:28.53) | |
|
https://www.partsdata.de/USB-PS2-Adapter-fuer-PS2-Tastatur-PS2-Maus/USB-0606
da ...
| |
| naitsabes (27.01.23, 22:28.55) | |
|
Sehr sehr gut! Danke.
PS/2 aktiver Adapter das ist den Versuch Wert! Wird bestellt. Das ermöglicht letztlich sogar dann die Überlegung - wenn der RPi400 im Einsatz ist - eine zweite Lösung zu bauen: Den RaspberryPi 4 direkt an den Monitor anzuflanschen, mechanisch und elektrisch.
Und das mit den zwei Partitionen ist überlegenswert. Welches FS ermöglicht den Zugriff auf die FAT32? Eine USB HDD die mit zwei Partitionen zugleich als ADFS und mit FAT32 angebunden ist? Irgendwie ein komisches Gefühl habe ich damit.
| |
| Markus (27.01.23, 23:45.35) | |
|
FileCore/Fat32 nutzen die Systemkarten auch... etwas anders zwar aber doch in trauter Zweisamkeit.
FAT32FS ermöglicht den Zugriff auf die FAT Partition(en).
Für mich bester Weg: Erst Platte FileCore auf 256GB formatieren (das macht HForm mit den "defaults" von alleine) und dann den FAT32-Teil mit PartiFC und FAT32Formater. Alles unter RISC OS.
| |
| Raik (28.01.23, 10:40.14) | |
|
Ich hatte malnein Board hinter meine Fernseher geschraubt. Funktastatur mit "Joystick" (war mir schöner als ein Touchpad oder extra Mouse), WiFi-Bridge... Die USB Spannung des Fernsehers reichte auch "gedoppelt" nicht um das Board sicher zu bestromen. Ich habe mich dann für Netzteil an Funksteckdose entschieden und konnte dann alles vom Sofa...
Ich musste eine kleine Warteschleife vor Netzwerk einbauen, damit die Bridge bereit war und das Tor öffnete, wenn RISC OS anklopft.
Viel Spaß.
| |
| Raik (28.01.23, 11:58.35) | |
|
FileCore/Fat32 bei den Systemkarten ist aber doch für mich trotzdem nur *ein* "großer" aktiver Bereich. Ein kleiner zweiter Teil ist sozusagen passiv nur zum Booten und im aktiven Bereich ist dann !Boot usw.
Offensichtlich muss man streng zwischen Booten der Hardware (ROMs einlesen, CMOS RAM etc.) und Booten des Systems mit !Boot unterscheiden.
Für meine Denkweise komisch ist aber dann, daß ich eben zwei Laufwerke auf einem Speichermedium so nutzen muss, daß ich nur wegen ADFS Daten auf das zweite Laufwerk verschiebe obwohl beides auf dem selben Speichermedium sitz. Das ist für mich als Begründung etwas ganz anderes als immer schon sinnvolle Partitionen auf Festplatten. Partitionen lege ich aus ganz anderen Gründen an und so werden grundsätzlich schon die Daten anders darauf angelegt und verteilt. Niemals würde ich doch dann eine Partition so klein halten und auf dem selben Speichermedium eine andere Partition als Entlastung für die zu kleine nutzen. Das wäre ja verrückt! Genau das aber passiert dann, wenn ich ADFS entlaste, um FAT32 auf dem selben Speichermedium zu nutzen.
| |
| Markus (28.01.23, 17:30.49) | |
|
Jain bzw. anderer Ansatz...
Die bezahlbaren Platten werden immer größer bzw. die kleinen Platten im Verhältnis immer teurer. Da es kein Partitionierungtool für RISC OS mehr gibt, sind nur 256GB nutzbar. Warum man den EADFS Ansatz nicht weiter verfolgt ist mir nicht ganz klar.
Fat32fs ist nutzbar und ermöglicht so die Nutzung der ganzen Platte.
Du kannst RISC OS auch komplett von FAT32 laufen lassen, die Plattenzugriffe sind nur etwas langsamer.
Ich nutze die Platten am Titanium. Für mich hat der FAT32 Teil den Charm einfachen Datenaustausch zwischen RISC OS und Liniux zu ermöglichen. Ich nutze Ti-Linux auch für Sachen, wo RISC OS untauglich ist. Auf FAT32 kann ich von beiden Seiten zugreifen. Slles was ich sowohl als auch brauchen könnte liegt auf FAT und einige Backups als zip. Falls mal was Krachen geht ist FAT einfacher wieder herzustellen bzw. fremd auszulesen.
| |
| Raik (29.01.23, 12:19.59) | |
|
Das ist eine nachvollziehbare, sinnvolle Begründung für die große Festplatte mit zwei Partitionen in zwei Formaten.
Bei mir ist aber die eine Festplatte dauerhaft nur am RPi400 angeschlossen und der Datenaustausch findet übers lokale Netzwerk statt. Da ist dann der NAS oder die freigegebene Festplatte etc. Für die RISC OS Daten scheint mir das sicherer. Die Festplatte entzieht sich insgesamt besser dem Zugriff durch andere OSs. Auch deswegen bleibe ich da bei ADFS und komme mit den 256 GB locker zurecht.
Aus vielen Gründen sind große Datenmengen eh auf anderen Computern um dort die besseren Programme zu nutzen. Bildbetrachter samt Organisation, ebenso wie Musikdateien, da gibt es nichts so leistungsfähiges unter RISC OS.
| |
| Markus (30.01.23, 08:03.53) | |
|
Ich möchte meine Lösung, um FileCore Platten mit > 256 GiB zu nutzen ein wenig erläutern:
Bei FAT32FS ist es so, daß ich für die Platte nur ein Icon habe, und je nachdem ob mit Select oder Adjust geklickt, FileCore oder FAT32 zu sehen ist. Das hat mich gestört. (o.k., man kann das auch mit Obey's lösen.)
Raik hat mich auf PartMan aufmerksam gemacht: ist beim iMX6 dabei. Da ist SCSIFS auch das Default-Filesystem, das mit PartMan klarkommt; das SCSIFS im ROM des Titanium kann das z.B. nicht.
PartMan nutzt GPT Partitionierung. Ich habe meiner PartMan-Variante dann MBR Partitionen beigebracht und lade ein SCSIFS nach, das mit PartMan spricht.
partiFC dient zum Vorbereiten der Platte; es erkennt die FileCore Formatierung und legt eine MBR Partitionstabelle an, bei der dann der Bereich > FileCore als FAT32 formatiert werden kann.
Die Kombination SCSIFS/PartMan liefert dann zwei Icons für die gleich Platte (vorausgesetzt, daß noch eine weitere Laufwerksnummer 'übrig' ist).
Dann braucht es noch ein angepasstes FAT32FS, das die Select/Adjust Klick Unterscheidung wieder aushebelt.
Es braucht also drei zusammenpassende Komponenten mit einer passend formatierten Platte. Das funktioniert bei mir einwandfrei, ist aber nichts für jeden. Deshalb habe ich diese Lösung auch nicht allgemein publiziert.
Wer trotzdem Interesse hat ;-) anton-reiser et t-online punkt de
| |
| Toni (30.01.23, 21:41.42) | |
|
GPT nutzen ich am MX6. 512GB SSD hat zwei FileCore Partitionen. Partman und ein passendes SCSIFS sind da ja schon dabei. Wobei SATA hier via SCSIFS tut. Was mich stört ist, dass es kein Fallback gibt. Die Partitionen sind nur mit den passenden Komponeneten nutzbar. Mal schnell die Platte an einen anderen RISC OS Rechner stecken tut nur, wenn ein passendes partman/SCSIFS vorhanden ist.
Das alte EADFS hatte den Vorteil, dass die erste Partition immer nutzbar blieb auch wenn EADFS nicht gesehen wurde. Toni kennt das Format besser, lesend funktioniert mit seiner Anpassung schon. ;-)
Mir ist nicht ganz klar, warum der Ansatz nicht weiter genutzt wird. Schade.
Im "Normalbetrieb" am Ti nutze ich die Standardkomponenten von RISC OS, mounte die FAT Partitionen via FAT32FS und packe mir passende Laufwerksicons per AddTinyDir auf die Iconbar das bei klick das Filer-Fenster öffnet. Wobei via ADFS (SATA beim Ti) Select/Adjust Klick keinen Unterschied macht und immer FileCore öffnet.
| |
| Raik (31.01.23, 09:06.00) | |
|
Nun sind fast alle sachen eingetroffen und nach und nach habe ich einen ersten angenehmen Aufbau eingerichtet.
https://yadi.sk/d/oQhEYJBXtg3c2g
Einges an Hürden gab es zu nehmen, aber jetzt läuft RISC OS Direct.
Warum soll man eine 32 GB SD Karte nehmen und nun werden nur 7 GB insgesamt als SD Kapazität unter RISC OS gegeben?
Ich habe keinen DHCP Server. Nach dem Einschalten des RPi400 sehe ich am Switch, daß das Netzwerkkabel vom RPi400 erkannt wird. Nun kommt die Info auf dem RPi400, daß er den DHCP Server sucht. Findet er nicht und jetzt schaltet er irgendwie um (evnetuell auf EtherUSB) und damit schaltet er das Ethernet-Kabel ab! Der Switch sagt plötzlich, daß Gerät wurde ausgeschaltet! Da komme ich nicht mehr weiter. Kann mir da bitte jemand helfen?
| |
| Markus (01.02.23, 19:15.24) | |
|
Gib doch einfach die Adresse vor. Die wird sich ja vermutlich im lokalen Netz nicht ändern, oder wenn dann, spätestens beim Routerwechsel. Einfach fix eintragen und gut ist.
| |
| naitsabes (01.02.23, 20:11.36) | |
|
Ich hatte das schon probiert, die IP address, Netmask auf manually gesetzt und selbst eingetragen. Ebenso Routing -> Gateway.
Beim Restart wird Ethernet erst wieder eingeschaltet, dann mit dem Computer "ausgeschaltet", dann beim Hochfahren ist Ethernet wieder aktiv. Da ich die Netztwerkkonfig fest eingetragen habe, entsteht keine DHCP Wartezeit (gefühlt ca. 15 Sekunden), sondern direkter Durchstart ins Desktop.
In beiden Varianten (DHCP und vorgegebene Netwerkkonfig) erscheint unten rechts im Desktop ein kleines weißes Infotext-Fenster: "A network cable is unplugged".
| |
| Markus (02.02.23, 08:26.54) | |
|
Ok inzwischen weiß ich wer das Infotext-Fenster macht: !ReDHCP
Das wird in "Boot sequence"->"Run"->"Run at startup" gestartet. !ReDHCP ich von dort mal entfernt. Änderte nix.
Habe dann Netzwerkkonfig auf DHCP zurückgesetzt. Ändert auch nix.
Immer schaltet irgendwas in der Boot-Sequenz das Ethernetkabel aus.
| |
| Markus (02.02.23, 09:06.11) | |
|
Eigentlich ist es einfach ;-)
-Haken bei Enable TCP/IP
-Interface manuell einrichten
-Routing nichts
-Hosts
Hostname hab ich was sinnfrei eingetragen
Primary name server ... IP des Routers
Set/Save/Reset...
| |
| Raik (02.02.23, 09:53.58) | |
|
Ich bin gerade nicht sicher wie aktuell "Direct" jetzt ist. Ich habe das mal probiert, aber war nichts für mich ;-)
Pi4 und 400 brauchen EtherGENET (sowohl als Modul als auch als auch als Basic in !InetSetup.Autosense) um zu funktionieren. Das war als ich mein ersten Pi4 gekauft habe da noch nicht mit drin. Musse ich mir erst besorgen.
Direct ist ein Image und das was Du bekommst, ist das, von was der Autor erstellt hat. ;-)
32GB Karte kannst Du nutzen, brauchst aber !SystemDisc als Tool um Dir die Karte selbst vorzubereiten. Dann musst Du den Inhalt der "Partitionen" manuell an die richtige Stelle kopieren...
| |
| Raik (02.02.23, 10:43.29) | |
|
Eingentlich... Aber genau das habe ich doch schon längst gemacht wie oben beschrieben.
EtherUSB ist nicht aktiv. EtherGENET wird als ok und aktiv angezeigt aber das Modul behauptet ich hätte gar kein Ethernet-Kabel angeschlossen. Daher kommt sicher auch die Ableitung z.B. für den Infotext.
Bleibt mir nur die Überlegung, Risc OS *Direct* (frisch geholt) kommt mit dem RPi4 und 400 Ethernet nicht zurecht.
Es gibt da ein Update auf www.riscosdev.com TCP/IP Stack v7.03
Und dann gibts da noch was ganz böses:
Boot-up stalls at “Contacting DHCP server”
Hier zu lesen:
https://www.riscosopen.org/wiki/documentation/show/RISC%20OS%20bugs%20specific%20to%20the%20Raspberry%20Pi
Mit dem extrem ernüchternden Fazit:
Pi 4: At present the only workaround is to disable networking
| |
| Markus (02.02.23, 10:44.39) | |
|
Pi4 und 400 brauchen EtherGENET (sowohl als Modul als auch als auch als Basic in !InetSetup.Autosense) um zu funktionieren
Drum ist das alles auch so in RISC OS Direct vorhanden. Da mußte ich nix nachträglich einpflegen. Ob aber alles richtig ausgeführt wird, kann zurecht bezweifelt werden. Denn so einen Verhau und Unfug wie dieses RISC OS unstrukturiert ist, habe ich noch nie gesehen. das aber wäre ein eigenes Monster-Kapitel. Da will ich mich nicht selbst ablenken und greife derzeit so wenig wie es geht ein. Es ist alles noch immer original wie es kam.
Ich forsche weiter, Info folgt. Vor vielen Jahren mit dem USB Ethernet Adapter und einem der ersten RaspberryPI war es viel einfacher RISC OS an den Start zu bekommen als heute. Das ist doch irre! Damals hatte ich schon alles am Laufen !Squirrel, !Marcel usw. Doch es gab keinen Sinn umzusteigen, wenn daneben der zum Arbeiten überlegene Risc PC steht.
| |
| Markus (02.02.23, 11:11.20) | |
|
Bei mir funktioniert das Netzwerk klaglos auf dem Pi4 und Pi400...
Stell mal alles auf DHCP und versuche mal bitte mein NetCheck...
http://www.riscos.berlin/download/netcheck_V160.zip
Damit kannst Du das Netz auch anschubsen...
Vielleicht tut das ja. Ich weiß nur gerade nicht ob die Version mit fester IP klarkommt.
| |
| Raik (02.02.23, 11:22.14) | |
|
Select auf das Iconbaricon öffnet das Statuswindow, Adjust versucht das Netz zu treten...
| |
| Raik (02.02.23, 11:44.58) | |
|
Select auf das Iconbaricon öffnet das Statuswindow, Adjust versucht das Netz zu treten...
| |
| Raik (02.02.23, 12:16.57) | |
|
Netz schlecht macht Unsinn ;-)
Das update ist der neue IPv6 stack. Der ist noch experimentell und keine Lösung, meine ich.
Die von Dir verlinkte bug-doku kenne ich nicht, deshalb funktioniert es wohl auf all meinen Geräten ;-)
| |
| Raik (02.02.23, 13:25.05) | |
|
Bitter, das alles, verdammt bitter.
!StrongEd kommt laufend mit "Not enough memory" Fehlermeldungen. Kleinste Dateien, wenn ich in Obey Dateien einen Zeile einfüge und O geht noch beim b (ich will Obey tippen) dann "Not enough...
NetCheck gestartet bringt:
Message from NetCheck
File name '.Templates' not recognised at line 559
Und vieles andere, was einen als eingefleischtester RISC OS 3.7 Kenner den Boden unter den Füssen weghaut. Unzählige Dinge wie z.B. keine sofortige Wirkung bei Änderungen in den Configs z.B. der Mausgeschwindigkeit.
| |
| Markus (02.02.23, 13:33.34) | |
|
Templates kann !NetCheck nicht finden.
Die basic Variable app_dir$ wird nur einmal verwendet um den Weg auf die ".Templates" Datei zu zeigen. app_dir$ ist aber leer!
| |
| Markus (02.02.23, 13:41.06) | |
|
Ich raste aus! Nun will ich das Basic Programm schnell ergänzen und dann kommt StrongEd mit ner Meldung die mir das verbietet!
Unauthorised action: "Prozess" in mode... blah blah...
Das ist ja schlimmer als unter jedem anderen OS weswegen ich die allesamt *hasse*!
| |
| Markus (02.02.23, 13:43.58) | |
|
Jetzt geht kein Kopieren von <NetCheck$Dir> aus der Obey Datei -> "Not enough memory". Dachte ich ok hat wohl ein Bug in der Obey Definition. Dann wollte ich in der Basic Datei schreiben. app_dir$="" konnte ich noch schreiben, jetzt kommt auch da schon wieder "Not enough memory"
Ich bin echt geschockt! Neue Benutzer die RISC OS mal ausprobieren wollen müssen das zurecht für eines der beschissensten OS ever halten.
| |
| Markus braucht dringend Beruhigungsmittel! (02.02.23, 13:49.54) | |
|
Ich weiß mir als RISC OS Freak ja ständig irgendwie zu helfen, aber selbst ein Computer-Nerd der von anderen OSs richtig viel Ahnung hat, müßte hier die Flinte ins Korn werfen.
Also NetCheck läuft längst wie es soll.
Select:
https://yadi.sk/i/7elkgGclgrLRVw
Adjust:
Message from Message from NetCheck
Looks like defaukt Etherdecice is not working e.g. cable unplugged. Please check connection!
| |
| Markus (02.02.23, 14:05.40) | |
|
Erstmal nur um Mißverständnisse vorzubeugen...
Du trägst nichs bei Routing / Gateway ein und die IP Deines Routers steht bei Hosts Primary Nameserver...
Die Direct StrongED Version funktioniert leider nicht mit Rechnern mit mehr als 2GB Speicher. Ist früher nie aufgefallen ;-). Fred hat das längst gefixed...
http://www.stronged.iconbar.com/archives/misc/se470a14.zip sollte tun und vermutlich auch http://stronged.iconbar.com/archives/releases/se470a15.zip
Da StrongED auch TaskWindow usw. übernimmt, kann das Kreise ziehen.
Bei mir auf dem Emu tut die verlinkte NetCheck Version klaglos...
| |
| Raik (02.02.23, 14:17.57) | |
|
Du trägst nichs bei Routing / Gateway ein und die IP Deines Routers steht bei Hosts Primary Nameserver...
Ja ganz genau so ist es.
Danke für den Hinweis mit StrongEd und schwerer Vorwurf an die RISC OS Direct Zusammenstellung. Frage mich nur eben welche Version das RISC OS Image von RISC OS Open mitliefert. Ich entschied mich für RISC OS Direct, weil ich dachte da ist gleich mehr Software up-to-date dabei. Es ist nun bald an der Zeit, weil mir wenig anderes bleibt, das Image von RISC OS Open zu starten und dann zu sehen ob ich damit weiter komme.
NetCheck kann ".Templates" finden, wenn an Default-Pfaden bzw. Fallback-Dirs die Template-Datei vorhanden ist. NetCheck hat aber den eingebauten Fehler eine leere Variable als Directory der ".Templates" Datei voranzustellen.
| |
| Markus (02.02.23, 14:38.00) | |
|
Mmm, sehr seltsam das mit NetCheck. Ich lese die app$dir am Anfang des RunImage aus. Normalerweise funktionierte das bisher immer.
Leider ist es bei der Masse der Programm einer solchen Sammlung schwierig das aktuell zu halten. Wenn die zum testen eine 2GB Maschine haben, fällt das nie auf.
Das von riccosopen ist nur ein 2GB Image.
Netzwerk versucht sich beim Erststart via DHCP zu aktivieren (wenn sich nichts geändert hat).
Ich würde mir das HDImage ziehen und das nutzen und den Directkram "wegschieben" aber Achtung: !Boot.Loader muss so bleiben wie es ist... Du kannst alles aus !Boot rausverschieben und das Boot aus dem HDImage reinkopieren aber Loader + Inhalt muss da bleiben wo es ist. Das isst die DOS Bootpartition, das unter RISC OS als Image zu sehen und befummeln ist. Das muss aber genau an der Stelle der Karte liegen bleiben.
| |
| Raik (02.02.23, 15:36.33) | |
|
Um die dünmmsten Effekte zu vermeiden, habe ich inzwischen drei verschiedene Ethernet-Kabel durch und den RPi400 auch mal direkt an den Router angeschlossen. Das Protokoll des Routers zeigt keine Anfrage bzw. keinen Anmeldeversuch!
Und das Spiel zuerst mit DHCP und dann mit vorgegebenen Daten habe ich nun auch mit der Distri 5.28 von RISC OS Open durchgespielt. Keinerlei Weiterkommen. Das Verhalten - es sei angeblich gar kein Ethernet-kabel angeschlossen - ist sehr stabil seit Anfang an identisch.
Ich habe übersehen, daß sogar die "List of Found" Funktion von !StrongEd kaputt ist. Mit dieser suchte ich nach app_dir$ und fand nur eines. In der Tat wird app_dir$ von !NetCheck gesetzt. Warum er mir allerdings dann die Fehlermeldung brachte, wird ein Rätsel bleiben. ich bitte Dich um Nachsicht.
Jetzt mit RISC OS Open 5.28 bleibt allerdings auch das !NetCheck Ergebnis identisch: Connected -> device unplugged.
| |
| Markus (02.02.23, 16:29.02) | |
|
Und wegen Kabelmeldung - vielleicht wirklich mal das Kabel prüfen. Schlecht gesteckt ist das schnell mal.
| |
| naitsabes (02.02.23, 16:31.50) | |
|
Um mal Luft aus der Sache zu nehmen, daß wir hier gar nix dafür können, habe ich nun das scheußlichste zum Schluss gemacht. Ich habe den USB nach Ethernet Adapter verwendet und in der Internet-Config nur auf USB umgeschaltet, Reset und "ich bin drin".
Es liegt nicht an "uns". Weder am Kabel, Switch, noch am Router. Auch nicht an der Ethernet-Konfiguration des Risc OS. ich werde den Verdacht nicht los, daß ich hier genau in diese Falle gatappt bin aus der es noch keinen Ausweg gibt.
Hier zu lesen:
https://www.riscosopen.org/wiki/documentation/show/RISC%20OS%20bugs%20specific%20to%20the%20Raspberry%20Pi
Mit dem extrem ernüchternden Fazit:
Pi 4: At present the only workaround is to disable networking
| |
| Markus (02.02.23, 16:56.42) | |
|
Ich stöpsel nachher mal mein Pi400 an. Ist aktuell verpackt, weil ich meine Kammer umräume.
Den Kabelcheck kann ich vielleicht ausblenden (oder Du) und das Teil trotzdem kicken lassen. Vielleicht ist die Abfrage nicht aktuell.
| |
| Raik (02.02.23, 17:01.48) | |
|
USB2Ether wäre einer der nächsten Vorschläge gewesen. ;-)
Ich bin mir aber sicher, dass mein Pi400 netzen tat.
| |
| Raik (02.02.23, 17:05.56) | |
|
RISC OS Open schreibt "Pi 4 model B, Pi 400 rev 1.0" und im Bug steht "You will also see this message on a Pi 4B or Pi 400 if it is one of the newest hardware revisions that have a different Ethernet interface."
ich lese daraus, das die einen funktionieren und die anderen eben nicht. Zufall was man bekommt? Ist eine Rev. irgendwo zu lesen? Wurde umgestellt und die neuen funktionieren alle nicht mehr?
| |
| Markus (02.02.23, 17:16.55) | |
|
Manchmal fällt der Groschen pfennigweise...
Dein Link bezieht sich auf 5.28 und kann nicht sauber funktionieren, weil das schon raus war als Pi4 und Co. unterstützt wurden.
02/2020 ist das 5.28 ROM, 03/2020 gab es die ersten Netzwerktreiber für das Pi4 aber noch nicht im ROM sondern testweise...
Vor diesem Hintergrund macht es vielleicht Sinn ein aktuelles 5.29 ROM zu probieren.
Ich bin mir sicher, bei mir dreht 5.29 und ich meine sogar ein ROM, dass ich selbst "gebacken" habe.
Mein Pi400 ist mit DE Tastatur also keines der Ersten.
| |
| Raik (02.02.23, 17:52.44) | |
|
Verzeihung ich steige bei dem was Du schreibst nicht ganz durch.
Bugs in the current stable release (RISC OS 5.28) berücksichtigt auch 5.29 Versionen - würde ich rauslesen -, weil Zusatzinformationen mit Bezug auf 5.29 eingepflegt werden. Und was würde denn bedeuten "Versions affected: All" wenn es in dieser Liste explizit nur um die 5.28er Version ginge? Hier steht auch wann was behoben wurde.
| |
| Markus (02.02.23, 18:09.54) | |
|
ROM 5.29 habe ich installiert. Jetzt bleibt die direkte Ethernetverbindung (Ethernetkabel im RPi400) am Switch aktiv. Das wars aber auch schon an Veränderungen und wieder habe ich reichlich Varianten durchgeprüft.
| |
| Markus (02.02.23, 18:46.16) | |
|
Mal abgesehen davon, dass das Dokument von März 22 ist...
HDImage mit eingemischt?
Lass mich mal schauen...
| |
| Raik (02.02.23, 19:20.47) | |
|
RISC OS Direct 5.28 im Video gezeigt im Januar 21 direkt per Ethernet Kabel verbunden. Allerdings ist die Frage ob er da trickst. Denn im Bootprozess PreDesk ist Ethernet über USB zu lesen. Er zeigt jedoch weiter hinten beim VNC Server die direkte Kabelverbindung. Na auf was will ich hinaus. Ich behaupte das ging schon im Januar 21 direkt Ethernet an der RPi4.
Ich versuche nun je einen älteren/gebrauchten RPi400 und RPi4 zu beschaffen.
| |
| Markus (02.02.23, 20:22.25) | |
|
EtherUSB ging immer mit einem externen Adapter seit das ROM vom März 20 den Pi4 unterstützte.
Ethernet 01/21 wiederspricht meiner Aussage nicht. Im ROM vom März 2020 war noch kein Netzwerktreiber für den Pi4 vorhanden...
z.B. https://www.riscosopen.org/forum/forums/5/topics/14571?page=10#posts-99750 ...
Ich bekomme das aus dem Gedächtnis nicht mehr komplett zusammen, weiß aber, daß DHCP relativ lange am Pi4 nicht ging. Man musste den ganzen Quatsch manuell konfigurieren...
Ich habe gerade das...
https://www.riscosopen.org/forum/forums/11/topics/17067?page=3#posts-135208 ...
... gefunden und Sprow mal angeschrieben.
| |
| Raik (02.02.23, 21:10.59) | |
|
Das ist der Grund:
It seems there is a Microchip 9131rnxc instead of a Broadcom BCM54213PE, that may be the source of my problems.
Es wird unterschieden zw. RPi400 V 1.0 und V 1.1 mit unterschiedlichen Ethernet Chips!
Ausführlichst hier mit weiterführenden Links:
https://www.riscosopen.org/forum/forums/11/topics/17067
| |
| Markus (02.02.23, 21:25.05) | |
|
Ja da hast Du es auch gefunden. Da war ich noch am Lesen des Threads bevor ich es hier schrieb und danach Deine Nachricht gelesen habe bzw. genauer Deine Links öffnete.
Wir kommen voran.
| |
| Markus (02.02.23, 21:28.36) | |
|
Ja da hast Du es auch gefunden. Da war ich noch am Lesen des Threads bevor ich es hier schrieb und danach Deine Nachricht gelesen habe bzw. genauer Deine Links öffnete.
Wir kommen voran. Aber es liegt bei meinem RPi400 nicht an den ROMs bzw. an RISC OS Direct und auch nicht am 5.28. Das passt schon. Die V1.0er funzen damit!
| |
| Markus (02.02.23, 21:31.06) | |
|
Konnte vorher nichts finden weil ich nicht gesucht habe ;-)
Mein Pi400 wird unter Linux tatsächlich als Rev 1.0 angezeigt. Ich poste gerade von selbigen mit "Direktkabel" (RISC OS 5.29 14-Nov-20).
Ich schicke Dir mal ein kleines "Basic" zur Hardwareerkennung. Kannst Du das bitte mal laufen lassen und mir die Ausgabe schicken. Vielleicht kann ich das "verfeinern". Hilft Dir nicht weiter aber mir ;-)
Sprow hat sich schon gemeldet. Er ist dran an dem Problem aber erst als Nummer 3 auf seiner "Dringlichkeitsliste". Das entsprechende Gerät hat er wohl inzwischen.
Ich bin noch immer der Meinung das 5.28 "einfach so" nicht geht aber es ist natürlich kein Problem Module bei Bedarf nachzuladen. Für die LTE Unterstützung lade ich Thomas EtherUSB auch nach, weil das im ROM nicht geht...
Sch...ade.
| |
| Raik (03.02.23, 05:53.03) | |
|
Soll das jetzt heißen, daß weder der RPi400 in Version Ethernet-Broadcom-BCM noch in der Variante Ethernet-Microchip-9131 sofort unter RISCOS netzwerkfähig ist ?? Kann ich mir irgendwie nicht vorstellen, damit würde man sich doch sofort alle potentiellen Neuinteressenten abgraben, die das erstmal nur ausprobieren wollen, weil sie einen Pi400 geholt haben und nur mal schauen woll(t)en.
Irgendwie hatte ich die Youtube Berichte über den Pi400 unter RISCOS durchgängig als "positiv" und "klappt gut" in Erinnerung.
Sowas wie 'kein Netz' wäre doch bestimmt wenigstens erwähnt worden. Das MUSS doch heute funktionieren, und zwar vor allem möglichen Anderem (Stichwort SATA Platte, RTC o.ä.).
| |
| naitsabes (03.02.23, 15:05.10) | |
|
Sie wie es aussieht wurde bei den neuen Revisionen des Pi4 und des Pi400 der Ethernetchip getauscht und beide verhalten sich nicht gleich. Auch in den Linuxforen ist das zu lesen. Alte Karte neues Board... Netzwerk tut nicht. Bei Linux hilft dann aber ein upgrade...
Die alte Version Rev 1.0 beim Pi400 ist seit langem sofort netzwerkfähig. Sowohl mit dem Direct als auch mit dem ROOL Image. Wenn man sich selbst was baut, muss man aufpassen. Wer nur mal schnell schauen will nimmt sowieso ein fertiges Image.
Die ersten Infos bei ROOL, dass Rev. 1.1 nicht "netzt" gab es Ende September... Ein EtherUSB-Adapter, das WiFi-Hat und LTE tun aber auch hier ;-)
| |
| Raik (03.02.23, 21:04.22) | |
|
OK, hätte mich jetzt auc gewundert, wenn es so gar nicht ginge. Und in den Videos sah es auch immer so aus, als ginge das "out of the box" - aber klar, das war dann auch immer die Rev 1.0
Ist schon immer interessant, was man da alles beachten muß ;) ; ich hätte auch einfach einen aktuellen genommen und dann schlicht erwartet, daß das geht. Und hätte wahrscheinlich ebenso komisch geschaut, wie das hier wohl gerade passiert ist.
| |
| naitsabes (04.02.23, 16:45.45) | |
|
Die Datenbank !Squirrel läuft schon. Gegenüber dem Risc PC ein extremer Geschwindigkeitszuwachs.
Das E-Mail Programm !Marcel läuft auch schon, auch mit das Auswahl der E-Mail-Konten bzw. Benutzer. Aber das ist noch schwierig, weil das aktive Anmelden und damit Öffnen der E-Mail-Listen noch nicht klappt und das liegt an eimem schwierig zu durchschauend Obey in welchem ein Aktiv laufendes Modul (eigentlich nicht RMKillbar) eben doch RMGekillt wird um es dann neu zu starten.
| |
| Markus (04.02.23, 21:37.24) | |
|
Raik: "Ein EtherUSB-Adapter, das WiFi-Hat und LTE tun aber auch hier ;-)"
Kannst Du das bitte für mich etwas aufdröseln? Das sind auf die schnelle gelseen, drei Möglichkeiten um RISC OS ans Internet zu bekommen. Nun kenne ich den Ethernet-USB Adapter. Das zweite ist dann er WiFi-Hat hinten auf die Pfostenstiftleiste. Was ist und wie aber funktioniert die LTE Anbindung?
| |
| Markus (05.02.23, 15:16.06) | |
|
Hat jemand eine Idee zu folgendem Problem?
Ein Modul wird mit RISC OS 5.28 zwar ohne Fehlermeldung geladen, denn die Hilfen *help InternetServer des Moduls werden ausgegeben, aber die Funktionen des Moduls sind nicht erreichbar, denn es ist gar nicht als nutzbares Modul angemeldet. Einfach zu erkennen, weil es in der RAM Modules Liste von StrongEd nicht auftaucht.
Habe es mit und ohne Aemulor probiert. Das Modul ist das einzige was Marcel noch braucht.
| |
| Markus (05.02.23, 15:23.54) | |
|
Kontrollier mal die Versionsnummer - von dem was Du (vermutlich per Doppelklick ?) lädst und dem was im Speicher steht. Wäre für mich die einzige Erklärung wie soetwas passieren kann: daß man ein Modul gleichen Namens lädt, aber ein neueres schon im Speicher /ROM liegt, weshalb das neu geladene sich ohne Fehler wieder abmeldet - und das neuere hat eben evtl. keine Kommandos mehr, z.B. weil das modularisiert worden ist oder so.
| |
| naitsabes (05.02.23, 16:05.55) | |
|
Das Modul mit dem Namen "Internet Server" bzw. InetServer gibt es bei mir noch nicht. Daher kommt kein Konflikt.
Das Modul kann die Hilfetexte an RISC OS noch abgeben, aber selbst startet es danach nicht weiter sondern ist wieder weg.
| |
| Markus (05.02.23, 16:35.30) | |
|
Ich bitte um weitere Nachsicht wenn ich hier so zuballere. Ich denke hier sind so wenige und so wenig ist hier los, da mache ich jetzt mit meinem Zeug nix kaputt oder?
Denn ich habe es geschafft! Marcel läuft auf dem Raspberry Pi. Alles noch im katastrophalen Probiersaustall, aber rein technisch reicht das, um den Elan es aufgeräumt zu machen mit Erfolg zu krönen. Denn es läuft.
Denn Versand und die Abholung machte ich eh schon seit Jahren vorbei an der Ant Suite mit !SMTPS und !POP3S von daher steht dann noch die neue Anbindung an Hermes als Aufgabe vor mir.
| |
| Markus (05.02.23, 16:49.07) | |
|
LTE siehe gaanz oben.
POP3S und SMTPS laufen auf dem Pi4... zumindest die Versionen die ich habe und mit t-online.
Könnte Inetserver Abhängigkeiten haben, die RISC OS 5 nicht bietet.
Ich muss mal nachsehen... morgen früh.
| |
| Raik (05.02.23, 18:13.27) | |
|
LTE, wer lesen kann ist klar im Vorteil.
!POP3S und !SMTPS in einer Version die kein neueres TLS können, waren ja mein Knackpunkt. Nun könnte ich der Einfachheit halber die neueren Versionen der beiden einsetzen. Ebenso wie !Hermes. Ich gehe davo aus, daß ich mit !Hermes längerfristig mit den Protokolerwartungen mithalten kann. Was meint ihr?
Raik, kannst Du mir die beiden auf dem Pi4 lauffähigen Versionen per E-Mail bitte schicken?
| |
| Markus (05.02.23, 18:27.16) | |
|
Raik: LTE siehe gaanz oben.
Hmmm...der Klick/Link vom Bild führt ins Dummy-Nirvana.
Und was der folgende Satz von oben bdeutet, verstehe ich nicht.
Thomas hat EtherUSB um die CDC ECM Unterstützung erweitert. Das hat für mich den Vorteil, dass ich nun zwei LTE Geräte habe, mit denen ich unter RISC OS mobil ins Internet kann.
| |
| Markus (05.02.23, 18:42.41) | |
|
POP3S... Da ich nicht mehr genau weiß was ich gemacht habe ;-) ... gerade noch einmal probiert auf dem Pi4... läuft mit t-online.
GMail geht nicht aber mit Hermees auch nur nicht. Hermes nutzt AcornSSL in den letzten Versionen. Das wird gepflegt aber die Briten sind immer etwas hinterher, weil sie das oft nicht brauchen.
Vielleicht kompiliere ich POP3S noch einmal mit dem aktuellsten GNUTLS...
Ich schicke erstmal die mit GNUTLS3.4 ... Den Altes war auf 2.7 Basis, meine ich.
LTE... Das Bild gaanz oben ist nur ein Bild ;-)
Der Satz heißt genau das. Thomas hat EtherUSB um einen teilweisen CDC support erweitert. CDC ECM Geräte funktionieren damit, quasi vergleichbar wie Dein EtherUSB Adapter. Ich habe einen HUAWEI E3372 und Vodafone Mobile WiFi R216-z die damit über USB tun. Letzterer bietet dann noch WiFi für Geräte die das können.
Thomas sein EtherUSB ist noch nicht in den offiziellen builds enthalten. Falls Interesse besteht...
| |
| Raik (06.02.23, 06:43.01) | |
|
Aha, danke. Jetzt anhand der Gerätebezeichnungen kann ich es erst verstehen.
Das Gerät bzw. der Stick (Hardware aus der allgemeinen Massenproduktion) empfängt selbst LTE und stellt das über USB zur Verfügung. Und das EtherUSB Modul (Software, spezielles RISC OS Modul in "privater" Entwicklung und nicht öffentlich verfügbar) wird benötigt um die Funktionalität fürs RISC OS verfügbar zu machen.
Warum schreibe ich - leicht übertrieben - in Klammern die Info dazu. Weil das die Hürden sind, über die ich anhand Deiner Kurzinfo nicht springen kann.
Was CDC und ECM bedeutet weiß ich noch nicht. Das kann ich aber wohl einfach selbst suchen. Für mich ist ECM zuerst mal ein sehr renommierter Musikverlag von dem ich seit Jahrzenten Schallplatten und CDs habe.
| |
| Markus (06.02.23, 08:18.23) | |
|
Abgeschrieben ohne Hintergrundwissen... USB Communications Device Class – Ethernet Control Module subclass (CDC-ECM)...
Android Sticks und Handys nutzen leider (meist?) was anderes (ndis?).
EtherUSB ist inzwischen Bestandteil von RISC OS. Thomas hat seinerzeit (2011) EtherUSB von James Peacock schon einmal erweitert um den SMSC Treiber der für BeagleXM, Panda, Pi bis 3B+ Basis des Internetzuganges war. Nun hat er CDC, das schon immer als unterstützt angezeigt wurde, aber nie funktionierte, befummelt. ROOL komm leider nicht aus der Hüfte und Thomas hat bisher auch nicht den ihm zustehenden "Teilbounty" erhalten :-(
| |
| Raik (06.02.23, 09:42.15) | |
|
Habt ihr / er denn mal nachgefragt, ob ihm nicht evtl ein Bountyteil zukommen könnte ? Vielleicht muß man da einfach nur ein bißchen "anschubsen". Wäre ja eigentlich genau die Idee hinter diesem System, daß der eigentliche Entwickler da was bekommt, wenn es eben fertig ist.
Kann mich daran irgendwie sogar erinnern - obwohl ich nie einen BeagleXM oder Panda Bären hatte. Wieso jetzt da SMSC für den Pi auftaucht, ist auch nicht direkt selbsterklärend. CDC ... klingt mit der Erklärung (Comunnications Device Class) schwer nach dem, wo man an einem Linux auch ständig an irgendwelchen dev-rules noch irgendwas händisch umstellen muß, bis es dann endlich mal geht. Aber es klingt auch nach einer ganzen neuen Welt an potentieller Hardware -sollte also eigentlich auch für noch vorhandene Firmen ganz spannend sein.
| |
| naitsabes (07.02.23, 13:16.57) | |
|
Bei ROOL hat Thomas angefragt und auch den Code übermittelt, nachdem Sprow (Elesar) ihn darauf hingewiesen hat, das er die Bedingungen für den Erhalt eines Teilbountys erüllt. ROOL prüft seit November und forderte die Daten von 5 aktuelle Geräten, die tun. Das ist locker eingehalten... ich habe 4 ... 2x LTE, 2x USB2Ether als CDC. Thomas hat zwei andere, Toni eins, Andy Marks eins... Bei ROOL im Forum gibt es einige Rüchmeldungen, dass es tut aus "aller Herren Länder"... ROOL kommt trotzdem nicht aus der Hüfte oder will nicht...
| |
| Raik (07.02.23, 13:50.38) | |
|
Die Pi bis einschl. Pi3B+ haben für USB und Ethernet alle einen SMSC Chipsatz verbaut.
Sprow hat sich noch einmal kurz gemeldet. Ihm ist eingefallen was das Problem bei Rev. 1.1 ist. Nun muss er "nur" noch dazu kommen...
... und ich muss nur noch dazu kommen das nächste Kapitel zu eröffnen. ;-)
| |
| Raik (07.02.23, 14:04.51) | |
|
Bzgl. ROOL:
Scheint wie immer manches unglücklich gelaufen zu sein. Zum einen wollten sie es wohl selbst testen, was ich verstehen kann. Sie haben aber beim Kauf der entsprechenden Konverter mindestens zweimal das falsche Modell bestellt. In UK ist es ähnlich, wie bei uns. Inflation hoch, Gehalt reicht nicht mehr, da streikt denn zusätzlich auch nochmal die Post (neben dem Gesundheitswesen usw.). Nebenbei war Weihnachten. Und zu guter Letzt wollen sie wohl auch letztlich RISC OS 5.30 endlich mal fertigstellen. Schließlich machen sie das alles unendgeltlich nebenbei und der Tag hat nur 24 Stunden ...
Ist ärgerlich, aber nicht zu ändern. Die Versorgung der RISC OS Community mit dem Ding ist ja Dank Raik erstmal sichergestellt ;-). Ich vermute und hoffe, daß ROOL mein EtherUSB Thema angeht, wenn sie 5.30 fertig haben.
| |
| Thomas Milius (07.02.23, 16:49.03) | |
|
Irre diese Bootsequenz. Nur ein Beispiel.
Aemulor läuft, aber! Man soll es in PreDesk ablegen, damit es Programme lauffähig macht, die es schon in der Bootsequenz brauchen. PreDesk dachte ich ist vor dem Desktop. Ist es aber nicht. PreDesk ist längst im Desktop.
Dann braucht Aemulor aber auch noch Choices. Die sind aber werden eben erst kurz vor dem Abarbeiten von PreDesk initialisiert, also auch schon längst im Desktop. Ergo ist Aemulor so erst extrem spät nutzbar. Dabei könnte Choices schon lange vor dem Desktop initialisiert werden.
Und welch Irrsinn da insgesamt mitgeschleppt wird. Ich habe heute 12 Stunden daran gearbeitet und werde noch viel mehr Zeit brauchen um da nach meinen Vorstellungen aufzuräumen.
| |
| Markus (07.02.23, 21:50.21) | |
|
PreDesk... mmM, wo fängt bei Dir der Desktop an und welches PreDesk meinst Du ;-)
!Boot.Choices.Boot.PreDesk ist bei mir irgendwie vor dem Desktop, denke ich aber es gibt Stellen, die sind noch etwas vorher musste ich beim befummeln der Territories feststellen.
| |
| Raik (07.02.23, 23:16.29) | |
|
Fehler von mir, die Desktop Zuordnung vom PreDesk Obey File.
Ja Raik Du hast Recht. Die !Boot.Choices.Boot.PreDesk ist bei mir auch vor dem Desktop Kommando das in PreDesk unten kommt.
| |
| Markus (08.02.23, 08:31.36) | |
|
Es gibt noch PreDesks in dem "Versions-Hooks". Da doppelt sich Einiges, was ich nicht sehr elegant finde.
Es gibt noch einen Ordner Bootcmd (oder so ähnlich) der ist noch früher.
| |
| Raik (08.02.23, 09:04.30) | |
|
Interessante Einblick in ROOL Abläufe. Das mit den Konvertern ist natürlich dann einfach Pech; hätte man evtl hinschicken sollen zum Testen (Rückporto inkl.) Schade.
Das mit den vielen Hooks und PreDesks und Task und Configures finde ich ja auch immer maximal verwirrend. DAS war mal so schön einfach ... eine Desktopstart-Datei und gut ... aber auch da gab es schon komische Sachen, wie z.B. dieses Savefile unterm TaskmanagerIcon. Ich könnte mir sogar vorstellen, daß es alles ein bißchen einfacher würde, wenn man das wieder rückabwickeln würde - aber da es nun einmal läuft und ja letztlich auch so funktioniert, wird es eh niemand anfassen wollen; auch weil man gar nicht weiß, was dann wieder nicht geht. Ich fand auch die Ordner !Fonts und !System im Root deutlich übersichtlicher - aber das ist halt a.) Geschmacksfrage und mußte b.) in den 90er Jahren vorm User versteckt werden, weil der ja das einfach nur "usen" sollte. Keine Ahung seit wann es die Hooks gibt, aber im Modul-Ordner bestimmt seit RISCOS 3.5. Man kann sich nur damit trösten, daß es woanders genausu unordentlich zugeht. Ich bin immer wieder fasziniert, wie so ein Unix sein Zeug quer über irgendwelche Ordner verteilt und dann da zusammensammelt - und da jedes zweite Programm einen anderen Ordner erwartet (und zwar absolute Pfade) möchte man die auch alle da haben, sowas wie /usr/share/icon und /usr/share/pixmap und ~/.icons/ und ~/.local/icons/ und neuerdings auch noch ~/.config und ~/.cache und außerdem noch die ganzen old-school Sachen, die dort auch kein neuer Desktop mehr benutzt. Schaue gerade so bißchen halbamusiert Tcl/Tk an - das ist was, was für RISCOS eigentlich auch mal hübsch wäre, aber es ist auch so ein schönes Beispiel dafür, wie man wegen einem Programm, was man nutzen will die Platte mit anderem Zeug vollmüllen muß. So gesehen, at Markus, nimms nicht so schwer ... es ist woanders nicht besser, nur anders ... :)
Das choices-boot-PreDesk ist definitiv VOR dem Desktop. Ich habe da eine selbstgebastelte Tastaturabfrage drin und die greift i.P. gleich nach der Einschaltmeldung und das funktioniert sehr gut.
| |
| naitsabes (08.02.23, 15:25.43) | |
|
Ich hatte mich vor vielen Jahren entschlossen den chaotischen Weg der RISC OS "Weiterentwicklung" zu verlassen und mein RISC OS sozusagen auf Version 3.70 eingefroren. Damit war dann der Schritt erlaubt, alles für mich erreichbare so zu machen wie ich es mir vorstelle. Was ich nicht erreiche, war dann - über den vielleicht genialsten Kniff aller Zeiten - mit dem vorangestellten ! eben eine Black-Box. Sauber auf eine elegante Weise.
Ich habe zwar alles umgebaut, aber dadurch, daß auch in der RISC OS "Weiterentwicklung" weiterhin konsequent gesagt wurde, wie man offiziell mit allem in !Boot umgeht, weil es sich ja mal ändern könnte, habe ich mich genau daran gehalten. Immer habe ich alle notwendigen Systemvariablen und die erst davon abhängigen Verzeichnisse bereit gestellt. Bis heute ist es daher bei gut bzw. sauber gemachten Programmen kein Problem gewesen, diese auch bei mir zu starten.
Erst Programme die es theoretisch leichter machen sollten, andere Programme und deren Infrastruktur ins RISC OS automatisch einzumischen, haben wertvolle Vorgaben einfach nicht mehr berücksichtigt. Sie vermüllen !Boot, sie stürzen ab, laufen nicht durch und ich blicke nicht mehr warum, weil mir dafür meine Zeit zu schade ist. Mit der Zeit kammen immer mehr Programme, die fest verdrahtet waren und so nicht funktionieren konnten. Mitverantwortlich ist hier auch dieser Hook Wahnsinn.
Nun aber holte mich halt alles ein. Und da inzwischen die Hardware für RISC OS und nun auch die Kernunterstützungen wie Ethernet, USB etc. vorhanden sind, muss (TLS zwingt mich) und will ich nun auch den Sprung machen. D.h. Raspberry Pi 4 oder 400, da drauf das aktuelle RISC OS bzw. !Boot und mein !Boot.
Jetzt bin ich dabei das originale !Boot wegzuarbeiten in dem ich es funktional in mein !Boot aufsauge. Zeitgleich kann ich mein !Boot radikal entschlacken; alles was eben ein Risc PC so an zusätzlichem Ergänzungs-Kram brauchte und das ist viel, fliegt raus.
Es wird dann zwei !Boot geben. Das neue !Boot für den Raspberry Pi, läuft niemals auf den alten Rechnern und das alte vom Risc PC, läuft niemals auf anderen Computern. Als übelste Fehlentscheidung vom offiziellen RISC OS, sehe ich diesen aufgeblähten Wahnsinn , das theoretisch verschiedene RISC OS Computer übers Netzwerk das selbe !Boot verwenden können sollen. Eben Universal Boot. Damit werden Computer/Programmier-Nerds - vielleicht gerade von denen die besseren - total abgeschreckt.
Ich verwende jetzt eh viel Zeit für diesen Schritt und bleibe dann gleich bei meinen alten Regeln. Was interessiert mich deutsches RISC OS? Null! Territories? Die können mich mal. Themes? Ich habe mein "Theme" aber nach altem einfachen Schema und fertig - das läßt sich ja trotzdem alles anpassen wie man will. Ich habe das dumpfe Gefühl zu viele meinen RISC OS würde profitieren, wenn es einen auf Show macht. Das sehe ich ganz anders. Wer sich einen Raspberry Pi mit RISC OS einrichtet, sollte beeindruckt sein, daß er plötzlich versteht was wo und warum in einem OS passiert.
Ich räume weiter...
| |
| Markus (08.02.23, 16:41.26) | |
|
Immer wieder brauche ich auch Hilfe. Ich verwende ja seit Jahren auf RISC OS im Wimp den Font Frutiger Medium Oblique. Ich habe den mit RISC OS 5.28 nur mit Mühe in die Wimp Darstellung gebracht. Aber viele Zeichen sind falsch. Spitze Klammern, Dollarzeichen und viele weitere. Wie Übersetzt man einen "alten" RISC OS Font der bis RISC OS 3.71 noch nie Schwierigkeiten machte in die neue Umgebung?
| |
| Markus (08.02.23, 18:20.18) | |
|
Hier ist so ein Beispiel. Ein Vollzerstörer an Systemvariablen ist !Boot.Utils.SetChoices
Es nimmt <Boot$Dir> und setzt davon ausgehend hartverdrahtet einfach <BootResources$Dir> und <BootResources$Path> knallhart neu. Egal was da vorher schon da war! Und dabei wurde die Systemvariable <BootResources$Dir> längst vorher schon zwingend genutzt z.B. um !Internet zu initialisieren.
<Boot$Dir>.Resources wird hiermit zwingend gemacht obwohl jeder Zugriff darauf über <BootResources$Dir> und <BootResources$Path> zu erfolgen hat. Schrott das ist schlicht Vollschrott!
| |
| Markus (08.02.23, 18:54.08) | |
|
Wenn Du den Font schicken könntest...
Ich hatte bisher nicht wirklich Probleme mit alten Fonts. Ich habe meine A5000 Sammlung einfach eingemischt und teilweise auch im Desktop probiert...
Das setzen der Systemvariablen ist tatsächlich manchmal etwas fragwürdig, einige Sachen doppelt... Ein "Entwanzen" wäre nicht schlecht...
Irgendwie fehlt mir aber der Antrieb. Ich habe ein paar Sachen "reduziert" ohne Probleme zu bemerken aber das ist abgestimmt auf mich. Keine Ahnung was bei Anderen passiert.
| |
| Raik (08.02.23, 23:28.27) | |
|
Aus einem mir "unbekannten" Grund funktiniert die Schrift Frutiger nun so gut wie immer schon auch mit RISC OS 5.28.
Es wird an dem Horror des Bootvorgangs liegen. Wer da tiefergehend eingreift der braucht echt Nerven. Doch heute kam ich vorwärts bis zu einer sehr guten Basis.
Der gesamte Pre-Desktop Vorgang (wird in RISC OS commands genannt) ist nun durchgearbiet und komplett in möglichst wenige Pseudo-Apps aufgelößt. Als Pseudo-Apps bezeichne ich !Scrap, !System usw. insgesamt schon 15 davon. Diese Pseudo-Apps übernehmen konsequent das Setzen ihrer jeweils eigenen Systemvariablen.
Naiv ist es allerdings zu glauben, man könne das wie früher machen und jede davon autark und verrüclkterweise sogar alleinig leben lassen. Es gibt da schon einiges an Abhängigkeiten.. Wenn beispielsweise Aemulor zwingend die !Choices braucht kann es eben ohne nicht funktionieren. Da aber Aemulor selbst Teil einer Bootsequenz ist, muss ja !Choices da sein bevor Aemulor gestartet wird. Das ist ein einfaches Beispiel. Ich stand tatsächlich an manchen Stellen vor der Frage was ist denn zuerst da, die Henne oder das Ei? Und genau darum sind in der offiziellen RISC OS Bootsequenz auch diese schmutzen "Lösungen", die vorab schon mal was machen was dann eigentlich erst später richtig gemacht wird.
| |
| Markus (09.02.23, 17:35.34) | |
|
Vielleicht lag ein "Neustart" dazwischen oder Du hast "aus Versehen" eine Komponente entfernt, die bei manueller Änderung "durch gerutscht" ist.
Ich mache an der Stelle wenig manuell sondern nutze das Themesetup. Ausnahme, ich setze -NoIconBoxesInTransWindows in Choices.ThemeSetup, weil das beim Setzen immer wieder verschwindet in einer "extra Obey" aber ignoriert wird.
Ich habe gerade "ein" Verständnisproblem und nicht die Zeit da tiefer einzusteigen. Soweit ich meine zu wissen...
Choices ist nur ein Verzeichnis und keine App "!Choices", in dem die persönlichen Starteinstellungen für Programme, die das benötigen, hinterlegt sind.
Das "wo" wird in Choices$Dir, Choices$Path und Choices$Write hinterlegt. In einem "regulärem" !Boot wird Choices aber auch gefunden, wenn die Variablen nicht gesetzt sind, meine ich. Mit "regulär" meine ich "keine Sonderlocken" in der Bootstruktur.
Die meisten Programme die das zwingend benötigen, so auch Aemulor, schauen beim Erststart ob was in Choices vorhanden ist und kopieren, wenn nicht, ihre Grundeinstellung da hin. Da ist jetzt wenig "Henne und Ei". Aemulor wird empfohlen ins PreDesk zu kopieren. Predesk ist Teil von Choices...
Auch Dein Problem mit den Pseudo-Apps kann ich nur schwer nachvollziehen. Ok, einige Stelle könnte man "straffen" aber so generell ...
Aber wie geschrieben, sooo tief bin ich dann doch nicht eingestiegen.
| |
| Raik (10.02.23, 05:51.58) | |
|
@Raik Missverständnis.
Ich habe das Choices Beispiel nur gebracht, um aufzuzeigen, daß es naiv wäre zu denken man könnte es wie früher machen und die !Scrap, !System usw. einfach lose und unabhängig im Root halten. Die Vorstellung habe ich hier im ArcSite Forum des öfteren gelesen. Man kann es schon ins Root stellen, aber man wird immer für Grundstrukturen eine Reihenfolge einhalten müssen und dann braucht es jemand von außen der diese Reihenfolge festlegt. Nur darum drehte sich mein Beispiel.
Zu den Henne und Ei Problemtiken habe ich kein Beispiel genannt.
| |
| Markus (10.02.23, 08:22.29) | |
|
So wie Du das geschrieben hast, stand das für mich im Zusammenhang.
Im Prinzip ist es, von unsauberen Details mal abgesehen, reine Geschmackssache.
Ich finde die Lösung, alles ins !Boot, nicht schlecht. Für eine "Singlemaschine" könnte man da sicher noch reduzieren. 4.39 usw. ist aus meiner Sicht aber noch unübersichtlicher.
Bei meinem A5000 hat es mich tatsächlich immer etwas gestört, daß so viel Kram im Root lag.
Aber wenn man will, kann man sich das hinbiegen und deutlich einfacher als bei anderen BS.
| |
| Raik (10.02.23, 08:53.30) | |
|
Ja, das stimmt. Den Charme hat es tatsächlich, daß man das auch mit wenigen Schritten auf eigene Bequemlichkeiten umbauen kann. Richtig interessant wird die Bootstruktur übrigens unter dem RISC OS 6 (?), wo es noch Userprofile gibt. Das ist dort aber auch alles eher mit Boardmitteln gelöst, was schon spannend ist.
Die HenneEi Problematik wie oben mal angedeutet ließe sich sicherlich auch durch ein einfaches Defaultscript lösen, was erstmal alle Variablenwerte auf Standards setzt und das als !App verpackt wird, die dann ganz am Anfang (Predesk) durchläuft. Am Ende macht aber dieses BootUtils genau das, wenn auch bißchen später. Der Aemulor sollte eigentlich nicht meckern, wenn er in Predesk liegt. Mal den !Help Text lesen, da ist das beschrieben, wie es sein soll. Gibt zwei Varianten das zu starten.
Wenn Du da viel drin rumbaust, solltest Du am Ende von dem !Boot, was Du dann designt hast auf jeden Fall eine Kopie anlegen, weil man eigentlich nicht weiß, was - wenn Du später doch mal was automatisch einmischen solltest - evtl dabei davon überschrieben werden könnte.
Die ganzen Sachen im Rootordner ... das war dann wohl ich ... irgendwie finde ich das sehr unintuitiv, daß man z.B. die Fonts und Library und Themes Ordner irgendwo in so einer "Substruktur" aufsuchen muß. Ich mach sowas (da was dazukopieren), aus Tradition, eben auch noch händisch. Es ist aber schon klar, daß das nicht so gedacht ist, und man das evtl. sogar als "archaisch" / "paläozän" ansehen würde, wenn man das OS heute (d.h. > 1995) kennenlernt und das immer noch funktionieren würde.
| |
| naitsabes (10.02.23, 14:12.49) | |
|
Komisch, ich bekomme keine voreingestellte RAM Disc mit !Configuration -> Discs -> RAM Disc Enable On
Wenn ich die setze und danach auch noch selbst das CMOS speichere, so bringt das nix, weil *stat. zeigt RamFSSize 0K.
Funktioniert bei euch sicher. Aber was fehlt bei mir? Tips sind willkommen.
| |
| Markus (10.02.23, 15:36.39) | |
|
Ha, interessant. Hier geht die RAMdisc bestens. Aber das RAMFSSize steht tatsächlich auch auf 0K. Bleibt auch so, wenn man den Wert im Dialogfenster ändert. Die RAMdisc selbst wird aber schon größer (Free). Vielleicht solltest Du einfach mal einen Wert im ConfigDialog eintragen und auf Set drücken.
| |
| naitsabes (10.02.23, 18:30.18) | |
|
Bist Du noch immer bei Direct?
Die machen ein paar Sachen anders on das damit zusammenhängt weiß ich nicht.
Manchmal heben sich zwei Einträge auf, weil mal was geändert wurde une ein alter Eintrag nicht zurückgenomme wurde...
Ich kann gerade nicht nachsehen...
Es gibt eine Obey in Predesk oder Tasks die das setzt und einen zweiten, wenn der Desktop mal gespeichert wurde in Choices.Boot.Desktop oder Choices.Tasks.!Boot (die TaskObey) mit jeweils einer Zeile ziemlich weit oben...
Ich schaue nachher noch einmal...
| |
| Raik (10.02.23, 18:38.26) | |
|
In PreDesk gibt es ein DiskSetup mit (bei mir) ...
ChangeDynamicArea -RamFsSize 65536K
Der Wert muss größer 0 sein, sonst wird keine Disc geöffnet.
Das gilt auch für den Eintrag in Configuration / Discs. Nur der Haken bei Enable reicht nicht aber ich sehe gerade 0 dort öffnet eine 100k Disc.
Früher gab den Eintrag in Choices.Boot.Desktop bzw. wenn vorhanden in Choices.Boot.Tasks.!Boot ...
Die beide Einträge werden aktuell nicht mehr generiert, wenn die Basis von Direct(?) hinreichend alt ist, könnte da aber noch was stehe. Ich weiß nicht, wann das geändert wurde, bin nur irgendwann mal darüber gestolpert, weil meine RAMDisc nicht so tat, wie ich dachte.
| |
| Raik (10.02.23, 20:36.45) | |
|
Danke. So was in der Art dachte ich mir schon. Ein sehr fragiles Teilchen das PreDesk. Config fügt nix ein, wenn nicht schon der passende Eintrag vorhanden ist. Es gibt auch keinen Hinweis, da er die passende Position nicht findet. Grottenschlecht gemacht! Denn eigentlich sollte Config in der Lage sein sogar ein fehlendes PreDesk wieder komplett hinzustellen.
| |
| Markus (10.02.23, 22:00.29) | |
|
Und der Grund warum es kein Setzen der RamFSSize im CMOS RAM gibt, ist damit auch klar. Die jetzige RAM DISK ist damit in der Dynamic Area. Das war und ist die RamFSSize nicht.
| |
| Markus (10.02.23, 22:09.27) | |
|
Danke! Es funktioniert. Ihr habt mich richtig geschubst. Ich habe falsch gedacht und wieder zu Unrecht gelästert.
So wie Raik es schreibt ist es und dank ihm habe ich es dann auch bei mir gefunden. Wurde immer gespeichert! Nur beim Booten nicht ausgeführt.
Irritiert mich aber, das ein Teil in der PreDesktop gespeichert wird z.B. Keyboard Germany, andere Dinge aber daneben im Verzeichnis PreDesk als kleine Obey Dateien mit dedizierten Aufgaben. Letzteres wäre meiner Ansicht nach der bessere alleinige Weg statt diesem Mischbetrieb.
Ich bin sehr weit gekommen. Als nächstes steht die Aufgabe an Hermes an den Start zu bringen und mit Marcel zu verbinden. Marcel läuft inzwischen stabil Stand-Alone mit dem RISC OS !Internet.
| |
| Markus (11.02.23, 00:50.36) | |
|
Die Aussage, dass configure nicht schreibt wenn nichts vorhanden ist bzw. Vorhandenes in PreDesk nicht ausgeführt wird, wundert mich doch sehr.
Wenn ich ein System neu auufsetze ist Grundlage das reguläre HDImage von ROOL als Startpunkt. Image meint das selbstentpackende oder das zip. Ist kein Kartenimage, sondern gepacktes "root" einer minimalistischen Konfiguration. In Boot ist so ziemich nichts gesetzt. Choices und somit auch PreDesk sind komplett leer.
Der Erststart funktioniert klaglos, wenn EDID für die Monitorerkennung funktioniert oder der Monitor das "fallback" 800x600 kann. Die nachtragliche Konfiguration über !Boot Doppelklick funktioniert dann bei mir problemlos. Im ersten Schritt tue ich aber auch nichts am System vorbei... !Boot, !System, !Fonts etc. werden regulär eingemischt. RamDisc über Discs festgelegt, CDRom auch, wenn vorhanden...
Ich vermute mal es ist einfacher, wenn jedes config-tool seine Obey anlegt, als eine komplette zu generieren. Verzeichnisse mit !Run, wie z.B. bei Configure für den Monitor gibt es immer dann, wenn vorher noch was gesetzt werden muss. Vermutlich kann man das auch zusammenfassen, zumindest wenn es um zwei Obeys geht aber mir persönlich sind da andere Baustellen wichtiger und die Abwärtskompatibilität bleibt erhalten.
| |
| Raik (11.02.23, 12:31.12) | |
|
Wenn PreDesktop als Datei nicht vorhanden ist, kommt beim Einstellen (Set) der Tastatur (Tastatur nur als Beispiel für eine triviale Aufgabe) eine Fehlermeldung. Doch so weit würde ich ja eh gar nicht gehen und stelle ihm also ein leeres PreDesktop bereit. Dann kommt die Fehlermeldung PreDesktop does not appear to be suitable structured.
Das nenne ich fragil. So eine Anforderung, mich nun damit zu Beschäftigen wie eine minimal suitable structure aussieht, würde ein durchdachtes System nicht einfordern. Ist meine Ansicht. Und selbst wenn ich diese suitable structure kennen würde, macht es das fragile System nicht besser.
Es würde mir Spaß machen sich darüber mehr auszutauschen, aber auf so einem Weg wie hier, ist es kritisch, weil zu viel Missverständnisse auftreten und um praziser zu werden, zu viel (letztlich auch überflüssige) Schreiberei dazu notwendig ist.
| |
| Markus (11.02.23, 15:07.36) | |
|
Die Frage ist, was war Deine Basis.
Wenn Du eine fertige Distro nimmst, wie Direct, dann sind vermutlich Sachen gesetzt, die beim "Urimage" nicht gesetzt sind. Löschst Du bei einem fertigen Image PreDesk (nicht ~top), kann das schon Probleme machen. Baust Du das über das "Urimage" von unten auf, vielleicht nicht. Nur eine Idee...
| |
| Raik (11.02.23, 15:53.48) | |
|
Marcel läuft inzwischen Stand-Alone auf RISC OS 5.28 ohne die Ant Suite.
Hermes habe ich auch gut einrichten können. Pfade Choices, Logs, Mail In-Out usw. soll man offiziell im !Run ändern. Funktioniert.
Voila! E-Mail Empfang hat sofort geklappt.
Dann kam die Frage ob das vorhandene Basic-Programm die Konvertierung inkl. Transfer schafft, vom MessengerPro Format aus dem Hermes Eingansverzeichnis rüber direkt an den dazugehörenden Local User von Marcel?
Voila! Klappt. Die E-Mails sind in Marcel.
Nächster Schritt, E-Mails von Marcel abschicken.
| |
| Markus (11.02.23, 17:32.27) | |
|
Klingt doch schonmal gut.
| |
| naitsabes (12.02.23, 16:35.22) | |
|
!PhotoDesk soll eine Neuauflage erhalten, habe ich gerade gelesen. Vorgestellt wird auf der RISCOS Show am (nächsten?) Wochenende.
| |
| naitsabes (22.02.23, 15:20.57) | |
|
Zur Feier, daß der Umzug auf den Raspberry Pi 400 nun praktisch gelungen ist, habe ich mir eine Steige original englisches Raspberry Joghurt gekauft.
http://e.pc.cd/EweotalK
| |
| Markus (06.03.23, 09:54.45) | |
|
Kopiert von der internen Risc PC Festplatte auf den NAS
8759 Dateien in 12593 Ordnern mit 5,13 GB
Dauerte ca. 5 Stunden
Kopiert mit LanManFS Omni vom NAS auf die "SCSI" Festplatte am Raspebrry Pi 400
Nach ~8 Minuten und ca. ~6500 Dateien (entsprchende Ordner Anzahl - siehe Verhältnis oben) hat Omni einen schweren internen Fehler gebracht.
Nun LanMan98 mit eigenem Filer (kein Omni Task und LanManFS vorhanden) genutzt. Vorher alles vom ersten Kopierprozess gelöscht. Nun läuft der ansonsten identische zweite Kopierdurchgang... ~7500 Dateien haben wir schon... Fertig! Fehlerfrei!
Es entstand zum Glück keine ADFS Dateileiche. Es gibt mit ADFS sehr selten mal Dateileichen, die sich nicht einfach löschen lassen. Die muss man so im Ordner belassen und den Ordner als Gift markieren.
Natürlich ist das kein Beweis für einen Fehler von Omni oder LanManFS. Umgekehrt auch kein Beweis, daß LanMan98 nicht in den Fehler reingerauscht wäre. Hab ja keine Ahnung wer bzw. was da tatsächlich versagt hat oder ob es nur eine Netzwerk "Störung" war die Omni rausgeworfen hat. Egal.
Aber ist es ist möglich, daß LanManFS mit Omni dafür verantwortlich ist. Von daher muss ich die Entscheidung gegen LanManFS und für die weitere Nutzung von LanMan98 treffen.
| |
| Markus (09.03.23, 11:22.35) | |
|
Das mit LanManFS und LanMan98 ist so eine Sache. Früher war LanManFS klar unterlegen, mittlerweile würde ich sagen, ist das in etwa gleich gut oder schlecht. Ich habe mit beiden Modulen schon teils derbe und auch reproduzierbare "Klopper" gehabt. Bei LanManFS hast Du das Problem, daß bestimmte Dateinamen nicht sichtbar sind. Lockprobleme/Zugriffsrechte setzen. Ich bin da bei beiden schonmal reingefallen, wobei ich nicht mehr genau sagen kann, wer wo i.d.R. patzt.
| |
| Thomas MIlius (09.03.23, 20:46.02) |
|
|
|
